OSGeo Planet

Free and Open Source GIS Ramblings: Straight and curved arrows with QGIS

OSGeo Planet - Sat, 2017-04-29 19:42

After my previous posts on flow maps, many people asked me how to create the curved arrows that you see in these maps.

Arrow symbol layers were introduced in QGIS 2.16.

The following quick screencast shows how it is done. Note how additional nodes are added to make the curved arrows:


Categories: OSGeo Planet

QGIS Blog: Logo Evolution – Call to User Groups

OSGeo Planet - Sat, 2017-04-29 11:44

With QGIS 3.0 moving closer, it is also time to get the new QGIS logo out there.

QGIS logo evolution

We are therefore asking all our user groups to join the project redesign efforts. Please have a look at your user group logo and bring it in line with the QGIS 3.0 design.

We have compiled a Visual Style Guide which provides all logo materials, including fonts that you can use for your own user group logo. Here is an example of how the Italian user group has updated their logo:

Italian user group redesigned

We are looking forward to seeing all your creative efforts!


Categories: OSGeo Planet

OSGeo.nl: Bestuursverfrissingen (en een vacature)

OSGeo Planet - Fri, 2017-04-28 14:45
Tijd om terug te treden

Zoals bij velen wellicht al bekend verlaten Marc Vloemans en Gert-Jan van der Weijden per 1 juli het OSGeo.nl bestuur. Marc heeft 1 termijn de PR-trom geroerd, Gert-Jan is dan 2 termijnen voorzitter geweest. Dat biedt ruimte voor vers bloed (ideeën, inzichten en werkwijzen) en het leidt tot wat verschuivingen in het stichtingsbestuur!

Om met dat eerste te beginnen: we zijn blij dat Paulo van Breugel zich als bestuurslid heeft aangemeld.

Paulo van Breugel stelt zich voor

Ik ben een freelance onderzoeker / consultant op het gebied van bos en landschapsecologie, natuurbehoud en duurzaam landgebruik. Een terugkerend thema in mijn werk is daarbij het in kaart brengen en analyseren van ruimtelijke patronen en processen, van populatie tot landschapsniveau. Eerder heb ik gewerkt in Syrië, Brazilië en in Kenia voor onder meer Bioversity International, het World Agroforestry Centre en het International Livestock Research Institute.

Ik ben sterke voorstander van het gebruik van open data en open source software omdat dit, in mijn ervaring, leidt tot meer transparant onderzoek en betere toegang tot relevante informatie en data voor alle belanghebbenden. Voor mijn eigen werk leunt ik om die reden dan ook met name sterk op open source tools zoals GRASS GIS, R en QGIS.

Als open source gebruiker wil ik graag een bijdrage leveren aan de open source community, en hoop dat nu ook via osgeo.nl te doen. Een van de aandachtspunten waar ik me daarbij op wil richten is het gebruik van open source software voor geo-informatie in de academische wereld en het onderwijs.

Omdat een stichting geen officiële leden kent kiest het oude bestuur zelf de nieuwe bestuursleden. We hebben Paulo met algemene stemmen in ons bestuur gekozen!

Per 1 juli neemt Paulo de rol van secretaris over van Just van den Broecke. Just volgt Gert-Jan op als voorzitter en wordt daarmee naar buiten het belangrijkste gezicht van de Stichting OSGeo.nl. Barend blijft als penningmeester de centjes onder zijn hoede houden.

Nog een plekje vrij

One’s a company, two’s a crowd, three’s a party (sprak Andy Warhol ooit). Maar zelfs met 3 bestuursposten ingevuld vinden we dat er nog ruimte is in het OSGeo.nl bestuur voor iemand die zich met name wil bezighouden met het bespelen van (sociale) media. Denk daarbij aan het via deze website, Meetup, Twitter etc. verspreiden van nieuws over aankomende events, zorgen dat er verslagen in woord en beeld van komen, en dat ook de schrijvende pers enthousiast over open source voor geo blijft berichten. Interesse? Meer weten? Laat het weten via info@osgeo.nl.

 

 

Categories: OSGeo Planet

Nyall Dawson: About label halos

OSGeo Planet - Fri, 2017-04-28 10:46

A lot of cartographers have a love/hate relationship with label halos. On one hand they can be an essential technique for improving label readability, especially against complex background layers. On the other hand they tend to dominate maps and draw unwanted attention to the map labels.

In this post I’m going to share my preferred techniques for using label halos. I personally find this technique is a good approach which minimises the negative effects of halos, while still providing a good boost to label readability. (I’m also going to share some related QGIS 3.0 news at the end of this post!)

Let’s start with some simple white labels over an aerial image:

These labels aren’t very effective. The complex background makes them hard to read, especially the “Winton Shire” label at the bottom of the image. A quick and nasty way to improve readability is to add a black halo around the labels:

Sure, it’s easy to read the labels now, but they stand out way too much and it’s difficult to see anything here except the labels!

We can improve this somewhat through a better choice of halo colour:

This is much better. We’ve got readable labels which aren’t too domineering. Unfortunately the halo effect is still very prominent, especially where the background image varies a lot. In this case it works well for the labels toward the middle of the map, but not so well for the labels at the top and bottom.

A good way to improve this is to take advantage of blending (or “composition”) modes (which QGIS has native support for). The white labels will be most readable when there’s a good contrast with the background map, i.e. when the background map is dark. That’s why we choose a halo colour which is darker than the text colour (or vice versa if you’ve got dark coloured labels). Unfortunately, by choosing the mid-toned brown colour to make the halos blend in more, we are actually lightening up parts of this background layer and both reducing the contrast with the label and also making the halo more visible. By using the “darken” blend mode, the brown halo will only be drawn for pixels were the brown is darker then the existing background. It will darken light areas of the image, but avoid lightening pixels which are already dark and providing good contrast. Here’s what this looks like:

The most noticeable differences are the labels shown above darker areas – the “Winton Shire” label at the bottom and the “Etheridge Shire” at the top. For both these labels the halo is almost imperceptible whilst still subtly doing it’s part to make the label readable. (If you had dark label text with a lighter halo color, you can use the “lighten” blend mode for the same result).

The only issue with this map is that the halo is still very obvious around “Shire” in “Richmond Shire” and “McKinlay” on the left of the map. This can be reduced by applying a light blur to the halo:

There’s almost no loss of readability by applying this blur, but it’s made those last prominent halos disappear into the map. At first glance you probably wouldn’t even notice that there’s any halos being used here. But if we compare back against the original map (which used no halos) we can see the huge difference in readability:

Compare especially the Winton Shire label at the bottom, and the Richmond Shire label in the middle. These are much clearer on our tweaked map versus the above image.

Now for the good news… when QGIS 3.0 is released you’ll no longer have to rely on an external illustration/editing application to get this effect with your maps. In fact, QGIS 3.0 is bringing native support for applying many types of live layer effects to label buffers and background shapes, including blur. This means it will be possible to reproduce this technique directly inside your GIS, no external editing or tweaking required!

Categories: OSGeo Planet

From GIS to Remote Sensing: SCP Questions of This Month: April

OSGeo Planet - Fri, 2017-04-28 09:00
This post is a collection of questions and answers about the Semi-Automatic Classification Plugin (SCP) and remote sensing which were discussed in the Facebook group and the Google+ Community this month.
These questions vary from supervised classification technique to software issues, and can be useful to the readers of this blog for solving issues about the use of SCP.

Categories: OSGeo Planet

GeoServer Team: GeoServer monthly bug stomp

OSGeo Planet - Thu, 2017-04-27 05:12

Our monthly GeoServer bug stomps are moving to the last Friday of each month.

bug_stomp

Previously these events were scheduled when people were available, making planning difficult. By choosing a set date each month it is easier to schedule a time to participate for all involved.

Tips for Participating

Thanks to Matt Kruszewski for the following notes on how to take part.

Before you start

Get ready:

  1. Join the gitter.im channel geoserver/geoserver, you can sign in with your github id.
  2. Sign up for Jira, so you can review and add to bugs.
  3. Join the geoserver-devel@lists.sourceforge.net and introduce yourself!  In your email, you can be asked to be added to the Jira development team (so you can volunteer to work on a bug during the sprint).
  4. Double check the contributing guidelines (you may need to sign a code license agreement prior to starting work.)

Git ready:

# GeoServer uses Fork & Branch GitFlow
# Fork the geoserver/geoserver project on github, then clone it locally and add the main
# project as an upstream.

git clone https://github.com/{you}/geotools.git

git remote add upstream https://github.com/geoserver/geoserver.git

git pull –rebase upstream

git checkout -b myBugfixBranch

# Before making a pull request, make sure you are up-to-date with upstream.

git pull –rebase upstream master

# (or, rebase)

For the bug stomp you should work on a branch from master.

Eclipse or InteliJ recommended:

  • If you are setting up GeoServer for the first time as developer Quickstart in the developers guide.

Stomping

If you get stuck or are unsure of how to proceed, ask on gitter!

To find an issue to work on:

  1. Ask on Gitter, and use the Jira triage list of good candidates (triage=sprint).
  2. At the start of the sprint we review new bugs.

Style:

  1. Make sure to follow the contribution guidelines
  2. Format your code using the eclipse formatter profile here. The same formatter is used for GeoTools and GeoServer.
  3. Make sure to add the license boilerplate
  4. Consult the GeoTools code conventions for common habits
  5. Documentation is required for a UI fix, javadocs for public classes appreciated.

Testing:

  1. Test your fix!
  2. See Testing in the GeoServer Developers Guide
  3. Since this is a bug stomp, look at how the code around yours is tested and build on that.

Pull Request

  1. Make a pull request from your branch on your fork to geoserver/geoserver master.
  2. Ask for a review on gitter
  3. Make revisions based on feedback and comments. Additional commits to the branch in your fork are automatically reflected in the PR.

Tips and Tricks

  • We work closely with the GeoTools library for data access, rendering and processing – you may need a checkout of the GeoTools library to be effective.
  • For the bug stomp, pick a bug you can fix, not one you need to fix.
    • Many older issues are already fixed, start by trying to reproduce the problem.
    • Many worth while bugs cannot be fixed in a day
  • Don’t get stuck. Timebox yourself and don’t be afraid to discuss the problem on gitter.
  • Use the code formatter!
  • Don’t worry about making mistakes!  You can run findbugs, or ask for a shared screen code review before submitting your pull request (or “relax and realize the internet is full of fail”.)

Follow-up

  • After the bug stomp, reply to the geoserver-devel email thread with a summary of your progress

Most of all welcome to GeoServer and thanks for taking part.

Categories: OSGeo Planet

gvSIG Team: gvSIG (de nuevo) en prensa generalista

OSGeo Planet - Wed, 2017-04-26 09:26

De nuevo la prensa se hace eco del premio recibido de mano de la Comisión Europea al mejor proyecto europeo de software libre.

En este caso el periódico Las Provincias ha dedicado un espacio a hablar de los logros del proyecto gvSIG. Particularmente me ha gustado que se destaque, más allá de la parte técnica, la componente económica que juega el proyecto y que aporta a un nuevo modelo de producción del software: “La Comisión ha premiado a gvSIG porque permite el desarrollo económico mediante la especialización tecnológica en un sector emergente como el de la Geolocalización.”

La noticia en digital la podéis consultar aquí.


Filed under: premios, software libre, spanish Tagged: prensa
Categories: OSGeo Planet

Paulo van Breugel: Plotting GRASS data in Python

OSGeo Planet - Mon, 2017-04-24 12:13
GRASS GIS offers some useful but basic plotting options for raster data. However, for plotting of data in attribute tables and for more advanced graphs, we need to use other software tools. In this tutorial I explore some of the possibilities offered by Pandas plot() and how we can further tune plots using matplotlib / …

Continue reading Plotting GRASS data in Python

Categories: OSGeo Planet

GeoServer Team: GeoServer 2.10.3 Released

OSGeo Planet - Mon, 2017-04-24 08:37

We are happy to announce the release of GeoServer 2.10.3. Downloads are available (zipwardmg and exe) along with docs and extensions.

This is the release of GeoServer of the 2.10 branch is now going into maintenance and is no longer recommended for new production system. This release is made in conjunction with GeoTools 16.3.

This release is made by Ian Turton from the Astun Technology team. We would like to thank these volunteers  and everyone who contributed features, fixes and time during the release process.

New Features and Improvements
  • [GEOS-7684] – Add rest endpoint for geofence admin rules
  • [GEOS-7763] – Add REST endpoint for a user to change their password
  • [GEOS-7957] – GeoFence: REST Rule DTO does not handle addressrange
  • [GEOS-8022] – Allow disabling usage of SLD and SLD_BODY in WMS requests (also for virtual services)
Bug Fixes

A large number of bugs were fixed for this release including several that affected JMS clustering, WFS with 3D data and using the Style Editor with non-SLD styles. See the release notes for more details of all the fixes.

Categories: OSGeo Planet

Equipo Geotux: Funcionalidad de Exportar/Importar para el plugin AutoFields

OSGeo Planet - Fri, 2017-04-21 14:06

Una de las funcionalidades más solicitadas para el plugin de QGIS 'AutoFields' ha sido implementada: la manera de exportar e importar AutoFields previamente configurados.

 

Si no conoces qué son los AutoFields, lee primero Plugin AutoFields para QGIS.

 

Piensa por ejemplo en entregar a tus clientes AutoFields configurados junto a datos geográficos; piensa en compartir AutoFields con tus compañeros de trabajo; o quizá solo trabajar en dos ambientes y mantener sincronizados tus datos y sus configuraciones. Todos esos escenarios son ahora posibles con AutoFields v0.5.0. En este post te muestro cómo.

 

Exportando AutoFields

Una vez que hayas configurado tus AutoFields en QGIS, puedes exportarlos a un archivo JSON. Para ello, dale click al botón "Export to JSON file" para abrir el siguiente diálogo:


Selecciona los AutoFields que te gustaría exportar, elige si quieres remover los AutoFields exportados de tu QGIS, define la ruta al archivo JSON, y has click en el botón OK.

Importando AutoFields

Para importar AutoFields deberías contar con un archivo JSON. Has click sobre el botón "Import AutoFields from a JSON file" y selecciona dicho archivo JSON. Si el archivo es válido (esto es, si contiene AutoFields), se abrirá este diálogo:

 

 

Como puedes observar, se listan todos los AutoFields que contiene el archivo JSON. Puedes asignar cada AutoField a una capa (y campo) ya cargada en QGIS. Para facilitar la importación, el plugin intenta emparejar AutoFields con capas/campos por ti.

 


Las flechas indican la manera en que los AutoFields son asignados a las capas/campos:

Gris Indica que el AutoField no será importado y será ignorado en el proceso de importación.
Naranja
Indica que el AutoField será importado, pero sobreescribirá un AutoField existente en la capa y…
Read more...
Categories: OSGeo Planet

GeoTools Team: GeoTools 16.3 Released

OSGeo Planet - Thu, 2017-04-20 10:33
The GeoTools team is pleased to announce the release of GeoTools 16.3:This release is also available from our maven repository.

This release is made in conjunction with GeoServer 2.10.3.

GeoTools 16.3 is the first maintenance release of the 16.x series and 17.0 is now recommended for all new projects. In future this branch will only receive bug fixes but no new features will be added.


The GeoTools team is grateful for Astun Technology for sponsoring this release.Features and ImprovementsFeatures & Improvements
  • gs:PointStacker now has an attribute that holds the bounding box of the clustered features 
  • TransparencyFill process has been added to the unsupported/process-raster module 
  • GeoTools now uses Java 7 Base64 Encoder / Decoders throughout. 
Bug
  • Shapefile attribute (DBF) DbaseFileReader reads numeric empty values as zero 
  • Mollweide projection misses parameter
  • PostGIS sql dialect fails to encode 3D bbox filters
  • GridCoveargeRenderer.renderImage may throw a NPE
  • ProjectionHandler.getQueryEnvelopes can return invalid envelopes for transverse mercator
  • Geometries not created when using WFS data store 2.0.0
  • Band selection via request param and RBG expansion are incompatible
  • ImageWorker should invalidate statistics after a Crop
  • Shapefile dumper throws a NPE on NULL geometry values
  • Crop and rescale to bytes fail to propagate nodata values
  • Incorrect validation when parsing XML schema element declaration with ref attribute
And more! For more information please see the release notes (16.316.2 | 16.1 | 16.0 | 16-RC1 | M0 | beta).
Categories: OSGeo Planet

From GIS to Remote Sensing: Mapping Urban Area with Sentinel-1 Data: a Tutorial Using SNAP and SCP for QGIS

OSGeo Planet - Wed, 2017-04-19 08:00
I am glad to post this tutorial about urban mapping developed by Laure Boudinaud, a satellite data scientist, during her work as Young Graduate Trainee at the European Space Agency (ESA), ESRIN. The developed method aims to create a binary map of Urban / Non-urban area through the supervised classification of a Sentinel-1 image stack.
I personally thank very much Laure Boudinaud for her valuable work and the kindness to share this innovative method with the SCP Community.


Before starting this tutorial, you should download and install the free software SNAP developed by ESA for processing Sentinel data from http://step.esa.int/main/download/.
You should download the following Sentinel-1 images (the study area is Rome, Italy) from the Copernicus Open Access Hub (after the free registration):
  • S1A_IW_GRDH_1SDV_20161008T051144_20161008T051209_013394_015602_7B4A
  • S1B_IW_GRDH_1SDV_20161008T170446_20161008T170511_002418_004147_C814
Also, you should download the following reference data:Finally, download a Sentinel-2 image of the same area, which will be the reference optical data, following this previous tutorial.

Following, the text of the tutorial that is organized in two main steps:
  1. Processing in SNAP of the image and extraction of the features to be used for the classification;
  2. Supervised classification in QGIS (using the Semi-Classification plugin SCP).
Categories: OSGeo Planet

gvSIG Team: gvSIG en prensa generalista

OSGeo Planet - Tue, 2017-04-18 12:37

No es la primera vez, pero cada vez que un proyecto como gvSIG sale en prensa generalista todos los que nos dedicamos a la geomática y al software libre debemos estar de enhorabuena. Pocas veces los medios se hacen eco de la importancia de apostar por tecnologías libres, que garanticen la independencia tecnológica. Pero desde luego, un hito como conseguir el premio recibido de mano de la Comisión Europea al mejor proyecto europeo de software libre lo merece.

Así que desde aquí felicitamos, en este caso al periódico Levante, por llevar tanto a su edición escrita como digital este acontecimiento y contribuir a dar a conocer el proyecto gvSIG a un ámbito mayor de ciudadanos.

La noticia en digital la podéis consultar aquí.


Filed under: gvSIG Suite, premios, press office, software libre, spanish Tagged: prensa
Categories: OSGeo Planet

Cameron Shorter: Reducing scope of OSGeo-Live for next 11.0 release

OSGeo Planet - Mon, 2017-04-17 22:07

For our next OSGeo-Live release, 11.0, we propose to reduce the number of packages included, and only support a 64 bit distribution, (32 bit will be built but not tested or officially supported).
Factors leading to this suggestion include:
  1. Some projects have dwindling communities and momentum.
  2. Increased OSGeo-Live scope has increased our core maintenance and testing.
  3. Reduced engagement from projects (partly due to less core time spent reaching out to projects)
  4. Missing our first release milestone in 9 years.
From our options of reduce quality, become more efficient, increase volunteer engagement, find a sponsor to support core activities, and reduce scope, reducing scope is our most viable and acceptable option. Other ideas are welcomed.

Questions we will ask in assessing which projects to keep include:
  1. Is there an ACTIVE OSGeo-Live liaison person/people for the project? See "Contact" column in our Package List.
  2. Has the Project Overview and Quickstart been reviewed and are they current and complete?
  3. Do OpenHub metrics reflect an active and healthy community: 
  4. Is the project being updated on OSGeo-Live with each release?
Key Milestones
  • 5-Jun-2017 OSGeo-Live Feature Freeze (final application versions installed)
  • 19-Jun-2017 OSGeo-Live delivered to UAT (final application versions installed - Beta stage)
  • 24-Jul-2017 OSGeo-Live Final ISO
  • 14-Aug-2017 FOSS4G 2017 Boston
... full schedule
Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Better river styles with tapered lines

OSGeo Planet - Mon, 2017-04-17 14:31

In 2012 I published a post on mapping the then newly released Tirol river dataset.

In the comments, reader Michal Zimmermann asked:

Do you think it would be possible to create a river stream which gains width along its way? I mean rivers are usually much narrower on their beginnings, then their width increases and the estuary should be the widest part, right?

For a long time, this kind of river style, also known as “tapered lines” could only be created in vector graphics software, such as Inkscape and Illustrator.

With the help of geometry generators, we can now achieve this look directly in QGIS:

Data cc-by Land Tirol

In the river dataset published by the state of Tirol, all rivers are digitized in upstream direction. For this styling to work, it is necessary that the line direction is consistent throughout the whole dataset.

We use a geometry generator symbol layer to split the river geometry into its individual segments:

 

Then we can use the information about the total number of segments (accessible via the expression variable @geometry_part_count) and the individual segment’s number (@geometry_part_num) to calculate the segment’s line width.

The stroke width expression furthermore uses the river category (GEW_GRKL) to vary the line width depending on the category:

CASE WHEN "GEW_GRKL" = '< 10 km2 Fluss' THEN 0.2 WHEN "GEW_GRKL" = '10 km2 Fluss' THEN 0.4 WHEN "GEW_GRKL" = '100 km2 Fluss' THEN 0.6 WHEN "GEW_GRKL" = '1.000 km2 Fluss' THEN 0.8 ELSE 1.0 END * ( 1- ( @geometry_part_num / @geometry_part_count ))

If the rivers are digitized in downstream direction, you can simply remove the 1- term.

Happy mapping!


Categories: OSGeo Planet

GeoServer Team: REST API Code Sprint Results

OSGeo Planet - Tue, 2017-04-11 20:24

After an epic week of work on the REST-API as a team we are happy to report back with both a pull request and this status update on the work performed.

Thanks again to the code sprint sponsors, we really appreciated the strong response – it was great going into the event knowing it was not going to lose money. We would also like to thank our in-kind sponsors including our hosts GeoSolutions.

Gaia3d   atol_logo  Boundless_Logo    How2map_logo     fossgis_logo  iag_logo  

Previously posts in this series are REST API Code Sprint Prep and GeoServer Code Sprint 2017.

Migration to Spring-MVC

Everyone worked hard:

  • 310 commits
  • 487 files changed
  • 33,896 lines of code modified
  • More than 500 person-hours over the course of one week.

We have a post on rest api code sprint prep – here is what that work looks like visually.

sprint-prep

When reading the above graphics pay attention to the number of lines changed, rather than the number of commits, since some developers commit more frequently than others. A big thanks to Devon Tucker  for doing the initial legwork,  porting over the /rest/styles end-point sorting out the initial base-controllers, converters and configuration for the spring-mvc approach. Torben Barsballe joined to tinker on html output, javadocs and path fixes so everyone could have a consistent example.

During the sprint itself we carried on this work, splitting up according to end-point. Here is what that looks like visually.

sprint-results

The base /rest end-point provides an HTML and JSON list of all the other endpoints. Torben was able to implement using by looking up path mapping at runtime, allowing us to list new rest-api end-points that are added by optional modules such as the backup-restore community module.

The/rest/workspaces and/rest/namespaces were ported by Ian Turton who joined us from the United Kingdom. These two end-points work in tandem, and are responsible for partitioning GeoServer’s configuration for ease of management, with each workspace being assigned an XML namespace (so their output will not conflict).

Next we have David Vick working on the /rest/{workspace}/datastores end-point. This end-point is responsible for managing vector data sources, this was especially challenging to document since the connection parameters are different for each kind of connection.

Andrea Aime drove down to the coast from to joint the sprint. Initially working on the the /rest/{workspace}/coveragestores end-points, responsible for managing raster data sources, including file upload. Andrea was the first to finish migration and move on to documentation with Mike Pumphrey. This was an especially comlicated end-point as it also covers index and granules management for structured coverages (such as image mosaic).

From Canada Jody Garnett helped with documentation builds, and porting the /rest/layers end-points. The layers end-point captures the WFS options and WMS styling required when publishing.

Nuno, joining us Portugal, worked on the /rest/{workspace}/coverages end-points. Each coverage represents a resource published as a layer. This makes it a tricky to work as both the coverages and layers end-point needs to be used together to effect change.

Matt Kruszewski, joining from St. Louis, provided technical experience to guide the documentation effort. For migration Matt worked on the /rest/{workspace}/featuretypes end-point. Each featuretype represents vector data that is published as a layer, once again requiring use of both the featuretypes and layers end-points together.

Kevin Smith, over from Canada, worked on the /rest/{workspaces}/wmsstores and /rest/{workspaces}/wmslayers end-points. These endpoints are responsible for managing cascaded WMS services, and shared many of the same challenges as the datastores and coverages endpoints.

Quinn Scriptor flew in from Washington District of Columbia, helping with the documentation publication and porting the /rest/layergroups end-points. This work was made more challenging due to an inital lack of test coverage, requiring Quinn to write tests prior to migration.

Several developers were able to go back for a second helping, porting the remaining end-points:

  • /rest/fonts was ported by Ian
  • /rest/about was ported by Matt
  • /rest (index) was ported by Torben
  • /rest/settings were ported by Quinn and Torben. Quinn had to dig into the settings for each of the OWS Services.
  • /rest/templates were ported by Jody
  • /rest/security was ported, at some cost to personal sanity, by Andrea.
  • /rest/resources was ported by Torben. This proved tricky as the end-point is willing to work with a wide range of mimetypes (as it is used to manage configuration files, icons and fonts).

After the core application was migrated we had a chance to work on the extensions.

  • The /rest/imports extension was a team effort with Ian David, Matt and Torben on task. Torben especially worked on the airplane ride home and far into the next week migrating the tasks section of this api (responsible for monitoring long running import activities).
  • The /rest/monitor extension was the work of Andrea. This proved difficult to migrate unchanged, as the original notification model was tied into the restlet life-cycle. This work was extensive requiring re-implementing all the dispatcher callbacks in core.
  • Finally Nuno migrated the /rest/services/wfs/transforms end-point used to define XSLT transformations on WFS output.

DSC04986

Documentation

One thing everyone we talked to was looking forward to was reference documentation for the rest api. We have mixed success to report.

We were unable to “auto generate” swagger documentation starting from our existing java codebase. The XStream library we use for XML/JSON output cannot be automatically scanned to produce a swagger file.

What we were able to do was form a documentation train,  as each developer completed the migration of a rest-api endpoint they would visit Mike Pumphrey and get started on producing a swagger document by hand. These text files explicitly document each end point, the path, the queries, and most importantly the data that can be edited.

Once the swagger document had been produced we then had a chance to look into publishing options.

From each rest api in the user documentation we link to the generated reference docs.

rest-sphinx

Static documentation for the user guide

Generation of static html files for the user guide was straight forward using the swagger-codegen-maven-plugin, but only used about 70% of the information we had so carefully written!

Our first issue with this approach is the generated documentation has a bad habit of sorting alphabetically each end point. So all the DELETE methods would be grouped, followed by GET, and then POST, and then PUT methods.

To address this we have broken up each end-point into a seperate file (rather than have a single reference for everything).

rest-static-docs_list

Looking at an individual reference we can start to see everything we have written, but the XML and JSON examples have been reduced to a single line.

rest-static-docs-reference

These results were disappointing after so much work. I expect we will need to improve this plugin if we continue to use it as is.

Generating dynamic documentation for the website

The swagger documentation that most people are familiar with is JavaScript based, showing a YAML or JSON api definition as an interactive dynamic reference. What is great about this approach is that the JavaScript documentation viewer can construct valid sample requests and run them against a reference GeoServer.

rest-dynamic-list

Opening up one of the operations we can see that it is much more readable.

For a GET method the response code are clearly listed, with an opportunity to provide an example value. There are still some glitches (the XML and JSON are not pretty printed).

rest-dynamic-get

Changing from example value to model we can start to reference information that has been written during the sprint. Since this model is common to both XML and JSON we have tried to strike a good compromise using link to document an atom:link in XML, and a href in JSON.

rest-dynamic-get-model

For PUT and POST methods attribute values (including path variables) are documented, along with the request body.

rest-dynamic-put

The model for the request body, drills down into the content expected. One nice feature is the ability to reuse definitions – as seen in the result of style for default and alternate elements below.

rest-dynamic-put-model

To share this with you today we have added docs.geoserver.org/api to the website, the documentation viewer is able to access the individual YAML files on that website.

For the GeoServer 2.12 release we would like to try repurposing this viewer for static html use, it will involve generating out a web page that includes each YAML file inline in addition to the documentation viewer.

DSC04918

Delivery

While the above work was accomplished during the sprint at GeoSolutions, the work was not in a fit state for a delivery.
Over the next week (and weekend for Andrea):

  • Integration testing (for geoserver-manager java library and part of gsconfig) from Andrea found a large number of issues. The bulk of these were regressions caused by not quite following the previous example. While this would not normally be a problem when creating a new API, we wanted to be sure to produce the same workflow and response codes so that downstream applications would continue to work unchanged.
  • Kevin Smith and Jody worked to double check the css and ysld extensions correctly worked with the migrated styles end-point. This resulted in some small improvements – css and ysld content can now be validated on upload.
  • Integration testing (for gsconfig and gsimporter python libraries) took up much of the next week as Torben first implemented the remaining “import tasks” and continued quality assurance work Andrea started.
  • Jody and Torben had the final consistency run, making sure converters were were being used consistently to handle mime types, and checking that path variables were named consistently across all endpoint controllers.
  • Torben had the honor of producing the final pull request on Friday (a full week after the sprint completed). These final checks for headers, code formatting, consistent use of path annotations provide us a firm codebase to work from in the future.
DSC04991 Thanks

We would like to thank our employers for a chance to work on this activity, the sponsors who made it possible to work together in person, and our hosts at GeoSolutions for their hospitality.

DSC04937

DSC04999

Categories: OSGeo Planet

OSGeo News: OSGeo-Live 10.5 Released

OSGeo Planet - Mon, 2017-04-10 21:57
Categories: OSGeo Planet

Petr Pridal: OpenMapTiles v3.5: From runways to mountain peaks

OSGeo Planet - Mon, 2017-04-10 17:47
New release of OpenMapTiles is here! Ready to take a look at major changes? Fasten your seatbelt, because we start at the airport!

The aeroway layer now contains runways and taxiways as linestrings starting at zoom level 11. Previously only aeroway polygons were available starting at zoom level 12, so now you can see more even at lower zoom level.
Attribute network of transportation_name layer is now filled-in for three major road networks of the USA, Transcanadian highway, and UK’s motorways and A roads. This change enables to display network-specific road shields in the map.

We also adjusted zoom levels of both transportation_name and transportation to show more roads and road numbers at lower zoom levels.


Our tiles now speak German! Together with name and name_en we added also name_de attribute that contains German name if available. This change is available for all layers having name attribute including place, poi, and waterway. Viel Spass!

Release 3.5 introduces also brand new layer mountain_peak with mountain peaks and their elevation in both meters and feets. Mountain peaks start at zoom level 7 with only the most important peaks, up to the zoom level 14, that contains all of them.

We hope you enjoyed the flight! More information available in release notes. Download prepared extracts from https://openmaptiles.com/downloads/.




Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Quick guide to geometry generator symbol layers

OSGeo Planet - Sat, 2017-04-08 16:17

Geometry generator symbol layers are a feature that has been added in QGIS 2.14. They allow using the expression engine to modify geometries or even create new geometries while rendering.

Geometry generator symbol layers make it possible to use expression syntax to generate a geometry on the fly during the rendering process. The resulting geometry does not have to match with the original geometry type and we can add several differently modified symbol layers on top of each other.

The latest version of the QGIS user manual provides some example expressions, which served as a basis for the following examples:

Rendering the centroid of a feature

To add a geometry layer representing feature centroids, we need to set the geometry type to Point / Multipoint and enter the following expression:

centroid( $geometry )

It is worth noting that the correct geometry type has to be set manually. If a wrong type is set, the symbol layer can not be rendered.

Drawing buffers around features

Buffers are an example of a polygon geometry generator layer. The second parameter of the buffer function defines if the buffer is generated outside (for positive values) or inside (for negative values) of the feature. The value has to be provided in the layer’s CRS units, in this case, that means an inner buffer of 0.005 degrees:

buffer( $geometry, -0.005 )

Creating a line between features in different layers

The following expression creates lines from all district centroids (as shown in the first example) and a feature from the Citybike layer where the STATION attribute value is ‘Millennium Tower’:

make_line( centroid( $geometry ), geometry( get_feature( 'Citybike', 'STATION', 'Millennium Tower' ) ) )

More advanced examples

Using these basic examples as a starting point, geometry generators open a wide field of advanced symbology options. For example, this sector light style presented on GIS.Stackexchange or my recently introduced conveyor belt flow style:


Categories: OSGeo Planet
Syndicate content