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.

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.

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.

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.

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.

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).

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.

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.

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).

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.

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

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.

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.

• http://docs.geoserver.org/api/#/1.0.0/workspaces.yaml

• http://docs.geoserver.org/api/#/1.0.0/datastores.yaml

• http://docs.geoserver.org/api/#/1.0.0/coverages.yaml

• http://docs.geoserver.org/api/#/1.0.0/layers.yaml

• http://docs.geoserver.org/api/#/1.0.0/styles.yaml

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.

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.

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.

We are happy to announce the release of GeoServer 2.11.0. Downloads are available (zip, war, dmg and exe) along with docs and extensions.

This is the latest stable release of GeoSever recommended for production system. This release is made in conjunction with GeoTools.

This release is made by Andrea Aime and Alessandro Parma from the GeoSolutions team. We would like to thank these volunteers  and everyone who contributed features, fixes and time during the release process.

Change summary since RC1

If you already had a look at 2.11-RC1 announcement, here is an executive summary of changes since RC1:

• Fixed inability to edit layer groups after modifying a group layer order and layer default style

• Windows service installer now sets up enough memory for GeoServer to run (for production usage you might still want to tweak it)

• Fixed interactin between layer group and security that sometimes prevented GetMap from succeding

• Assorted JMS clustering fixes

See the full changelog for details. Continue reading for an extended presentation of all the new features in 2.11.0

Highlights

As this is a major release, GeoServer 2.11.0 contains a number of important changes, including both new features and compatibility requirements.

Improved loading and OGC request times for large installations

GeoServer has historically had issues with long startup times on installations having several thousands layers. A group of recent improvements significantly sped up these times making it possible to handle tends of thousands of layers with no particular headaches.

For reference, some tests were run on a Core i7 860, 16GB of memory, 2TB hybrid drive (spinning disk plus SSD cache), on two different data directories:

• “Many states”: 1 workspace, 1 store, 10k layers, 10k cached layers

• “Large”: 1001 workspaces, 11000 stores (a mix of shapefiles, postgis, directory of shapefile, single tiff, arcgrid, mosaics), 42000 layers and 42000 associated tile layers

Startup times have been measured in both “cold” and “warm” mode, “cold” means the operating system file system cache contains none of the configuration files and the startup has to actually read everything from the disk, “warm” means the data dir is fully cached in memory instead:

• Many states, cold startup: 30s

• Many states, warm startup: 21s

• Large, cold startup: 107s

• Large, warm startup: 45s

As you can see, worst case is loading in excess of 40 thousands layers in less than a minute and a half!

For reference, “Large” startup times with JDBCConfig are 290s for cold startup, and 120s for warm startup. This is mostly due to cached layers loading, if your configuration has none the startup time will be of around 20-30 seconds instead (no matter how many layers are configured, because JDBCConfig loads layers on a as-needed basis at runtime… for a cost, see below).

It is also interesting to compare the times needed to run a GetMap against one of the “topp:states” in the “many states” data directory.

More information can be found in the initial proposal, and on the latest mailing list thread about parallel catalog loading.

Thanks to Andrea Aime for this great result.

Improved lookup of EPSG codes

Ever been annoyed by some shapefile with a .prj declaration that GeoServer does not understand? If so, try this new release. We pulled some extra heuristics and smarts to figure out the equivalent EPSG code of thousands more cases. This will hopefully reduce guesswork when configuring new vector layers, not to mention significantly speeding up importing large directories of shapefiles in the “Importer” extension.

Thanks to Andrea Aime for this much appreciated usability improvement.

Underlying labels in SLD

A new vendor option allow to underline labels in SLD (and CSS). Just add:

<VendorOption name="underlineText">true</VendorOption>

Thanks to Nuno Oliveria and GeoSolutions for this new feature.

Opaque Container Layer Group Mode

A new layer group mode has been added, called “Opaque Container”. It’s similar to “single” in that you cannot see the layers contained in it, but it also prevents its layers from showing up at the root level of the capabilities document. This new mode is targeted to building “base maps” that the client is not allowed to take apart into their components.

You can read more about layer group modes in the GeoServer user guide.

Thanks to GeoSolutions and City of Helsinki for sponsoring this new feature.

Layer Group Security

The build-in data security can now secure layer groups too, for both global and workspace-specific groups. “Tree” mode groups (named tree, container tree, opaque container) will extend the security rules applied to them to the layers contained.

Thanks to GeoSolutions and City of Helsinki for sponsoring this new feature.

REST API Security Improvement

New REST call allowing a users to modify his/her password (no UI for it yet, sorry). Here is an example cURL command:

curl -i -XPUT -H "Content-type: text/xml" -d '<passwd><newPassword>qqq</newPassword></passwd>' -u userName:currentPassword http://host:8080/geoserver/rest/security/self/passwordInviato il:09:48Da:Emanuele Tajariol

Thanks to Emanuele Tajariol and GeoSolutions for this work.

Extensions

GeoServer extensions are available as optional downloads adding capabilities to the core application.

YSLD module graduated to supported

The YSLD styling language has been graduated to supported land, becoming an official extension. YSLD is a YAML based language which closely matches the structure of SLD, and the internal data model that GeoServer’s renderer uses. Here is an example from the YSLD Cook Book:

<span class="l-Scalar-Plain">title</span><span class="p-Indicator">:</span> <span class="s">'YSLD</span> <span class="s">Cook</span> <span class="s">Book:</span> <span class="s">Simple</span> <span class="s">Line'</span>
<span class="l-Scalar-Plain">feature-styles</span><span class="p-Indicator">:</span>
<span class="p-Indicator">-</span> <span class="l-Scalar-Plain">name</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">name</span>
  <span class="l-Scalar-Plain">rules</span><span class="p-Indicator">:</span>
  <span class="p-Indicator">-</span> <span class="l-Scalar-Plain">symbolizers</span><span class="p-Indicator">:</span>
    <span class="p-Indicator">-</span> <span class="l-Scalar-Plain">line</span><span class="p-Indicator">:</span>
        <span class="l-Scalar-Plain">stroke-color</span><span class="p-Indicator">:</span> <span class="s">'#000000'</span>
        <span class="l-Scalar-Plain">stroke-width</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">3
</span>

Compared to SLD it sports a similar structure, but in a more compact and readable syntax. High-level elements are optional, so the same example can be expressed in a more compact format:

<span class="l-Scalar-Plain">line</span><span class="p-Indicator">:</span>
<span class="l-Scalar-Plain">  stroke-color</span><span class="p-Indicator">:</span> <span class="s">'#000000'</span>
<span class="l-Scalar-Plain">  stroke-width</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">3</span>

Similarly to SLD and CSS, the user guide contains both a reference and a cookbook to get you started. There is also a styling workshop with both CSS and YSLD examples (including an important example for converting your SLD styles to YSLD).

Thanks to Boundless for contributing this module and pushing it to supported status.

Vector tiles module graduated to supported

The vector tiles community module has been graduated to extension status. The module allows generation of vector tiles out of WMS and WMTS requests, using SLD to filter the contents of the tile at the requested scale. Supported vector tiles formats are MVT (MapBox Vector Tile), GeoJSON vector tiles, and TopoJSON vector tiles.

This allow for much more compact data transfers, reduced tile caches thanks to overzooming support, and allows the client to control styling. Here is an example of the client rendering a world map as a vector tile, and highlighting a specific area by attribute:

Hop on the documentation to get more information about this extension, along with a couple of presentations highlighting vector tile usage.

Thanks to Boundless for contributing this module and pushing it to supported status.

Upgrade Notes

This section highlights functionality that has changed from prior releases.

SLD 1.0 LabelPlacement fix default AnchorPoint

An issue with SLD 1.0 rendering has been fixed, this may affect the appearance of you WMS GetMap results.

This issue occurs in the following TextSymbolizer example, where the anchorPoint for the label placement has not been defined.

<sld:TextSymbolizer>
 <sld:Label><ogc:PropertyName>name</ogc:PropertyName></sld:Label>
</sld:TextSymbolizer>

As shown below GeoServer 2.10 and earlier used the incorrect default anchor point. The default anchor point of of x=0.5 and y=0.5 generated a label at the geometry centroid which is more suitable to PolygonSymbolizers.

Prior TextSymbolizer anchor point default

For GeoServer 2.11 this mistake has been corrected, the default anchor point is x=0.0 and y=0.5 which is more suited to PointSymbolizers.

Correct TextSymbolizer anchor point default

Alternative: Provide a Label Placement

To avoid making use of the default anchor point we recommend defining an label placement. For PolygonSymbolizers the following example is appropriate:

<sld:TextSymbolizer>
 <sld:Label><ogc:PropertyName>name</ogc:PropertyName></sld:Label>
 <sld:LabelPlacement>
  <sld:PointPlacement>
   <sld:AnchorPoint>
    <sld:AnchorPointX>0.5</sld:AnchorPointX>
    <sld:AnchorPointY>0.5</sld:AnchorPointY>
   </sld:AnchorPoint>
  </sld:PointPlacement>
 </sld:LabelPlacement>
</sld:TextSymbolizer>

For PointSymbolizer we recommend both an anchor point and a displacement (to prevent overlap with the location graphic).

<sld:TextSymbolizer>
 <sld:Label><ogc:PropertyName>name</ogc:PropertyName></sld:Label>
 <sld:LabelPlacement>
  <sld:PointPlacement>
   <sld:AnchorPoint>
    <sld:AnchorPointX>0.0</sld:AnchorPointX>
    <sld:AnchorPointY>0.5</sld:AnchorPointY>
   </sld:AnchorPoint>
   <sld:Displacement>
    <sld:DisplacementX>8.0</sld:DisplacementX>
    <sld:DisplacementY>0.0</sld:DisplacementY>
   </sld:Displacement>
  </sld:PointPlacement>
 </sld:LabelPlacement>
</sld:TextSymbolizer>

These changes explicitly centre polygon labels, and offset point labels (with an appropriate displacement allowing their graphic to be visible).

TextSymbolizer with defined anchor point

Alternative: Restore the Previous Default

If you need to “restore” the previous incorrect default value, add the startup parameter:

 -Dorg.geotools.renderer.style.legacyAnchorPoint=true

This setting is provided as an alternative to ease the upgrading process.

And more …

There are many improvements to look at in the release notes, cherry picking a few here:

• Support JSON encoded exceptions for WFS 2.0 too (was already available for 1.0 and 1.1)

• Drastically reduced output size for WMS PDF output format, when using a graphic fill based on repeated marks or SVG symbols

• Improved scalability when using “advanced projection handling” thanks to a new implementation of SoftValueHashMap (used as a cache by the referencing subsystem)

• Better transparency handling of NODATA and ROI (Region Of Interest)

• Fixes in computation of global disk quota (if you find you have a negative number, upgrade, wipe out the quota database, and restart)

About GeoServer 2.11

Articles, docs, blog posts and presentations:

• OAuth2 for GeoServer (GeoSolutions)

• YSLD has graduated and is now available for download as a supported extension

• Vector tiles has graduate and is now available for download as an extension

• The rendering engine continues to improve with underlying labels now available as a vendor option

• A new “opaque container” layer group mode can be used to publish a basemap while completely restricting access to the individual layers.

• Layer group security restrictions are now available

• Latest in performance optimizations in GeoServer (GeoSolutions)

• Improved lookup of EPSG codes allows GeoServer to automatically match EPSG codes making shapefiles easier to import into a database (or publish individually).

We are happy to announce the release of GeoServer 2.11-RC1. Downloads are available (zip, war, dmg and exe) along with docs and extensions.

This is a release candidate of GeoServer not intended for production use. This release is made in conjunction with GeoTools 16-RC1 and GeoWebCache 1.11-RC1.

Thanks to everyone who provided feedback, bug reports and fixes. Here are some of the changes included in 2.11-RC1:

• Incompatibilities with GeoFence and Control-flow have been resolved

• Empty WFS Transactions (which perform no changes) no indicating everything has changed

• Improvements to WFS GetFeature support for 3D BBOX requests

• We have one known regression with the windows service installer (memory setting is incorrect)

• Please additional details see the release notes (2.11-RC1

  2.11-beta )

Release Candidate Testing

The 2.11 release is expected in March, this release candidate is a “dry run” where we confirm new functionality is working as expected and double check the packaging and release process.

Please note that GeoServer 2.9 has reached its end-0f-life. If your organization has not yet upgraded please give us hand by evaluating 2.11-RC1 and providing feedback and your experiences for the development team. This is a win/win situation where your participation can both assist the GeoServer team and reduce your risk when upgrading.

Corrected default AnchorPoint for LabelPlacement

An issue with SLD 1.0 rendering has been fixed - when a LabelPlacement did not include a AnchorPoint we were using the wrong default!

• BEFORE: default anchor point was X=0.5 and Y=0.5 - which is at the middle height and middle length of the label text.

• AFTER: default anchor point was X=0.0 and Y=0.5 - which is at the middle height of the lefthand side of the label text.

This is a long standing issue that was only just noticed in February. If you need to “restore” the incorrect behaviour please startup with -D_org.geotools.renderer.style.legacyAnchorPoint=true _system property.

Startup Performance

With extensive improvements to startup performance and OGC requests for large installations we are looking forward to feedback from your experience testing.

About GeoServer 2.11

GeoServer 2.11 is scheduled for March 2017 release. This puts GeoServer back on our six month “time boxed” release schedule.

• OAuth2 for GeoServer (GeoSolutions)

• YSLD has graduated and is now available for download as a supported extension

• Vector tiles has graduate and is now available for download as an extension

• The rendering engine continues to improve with underlying labels now available as a vendor option

• A new “opaque container” layer group mode can be used to publish a basemap while completely restricting access to the individual layers.

• Layer group security restrictions are now available

• Latest in performance optimizations in GeoServer (GeoSolutions)

• Improved lookup of EPSG codes allows GeoServer to automatically match EPSG codes making shapefiles easier to import into a database (or publish individually).

In our previous blog post we highlighted the GeoServer Code Sprint 2017 taking place at the of this month. We are all looking forward to GeoSolutions hosting us in beautiful Tuscany and have lots of work to do.

One of the secrets (and this comes as no surprise) to having a successful code sprint is being prepared. With this year’s REST API migration from restlet to spring model-view-controller we want to have all technical decisions made, and examples for the developers to work from, prior to any boots hitting the ground in Italy.

But before we get into the details …

Code Sprint Sponsors

We would like to thank our sprint sponsors - we are honoured that so many organizations have stepped up world wide to fund this activity.

Gaia3D is a professional software company in the field of geospatial information and Earth science technology. We would like to thank Gaia3D for their gold sponsorship.

Insurance Australia Group (IAG) is our second gold sponsor. This is a great example of open source being used, and supported, by an engineering team. Thanks to Hugh Saalmans and the Location Engineering team at IAG for your support.

Boundless is once again sponsoring the GeoServer team. Boundless provides a commercially supported open source GIS platform for desktop, server, mobile and cloud. Thanks to Quinn Scripter and the Boundless suite team for their gold sponsorship.

How 2 Map is pleased to support this year’s event with a bronze sponsorship.

I am overjoyed FOSSGIS (German local OSGeo chapter) is supporting us with a bronze sponsorship. This sponsorship means a lot to us as the local chapter program focuses on users and developers; taking the time to support our project directly is a kind gesture.

Sponsorship Still Needed

While we have a couple of verbal commitments to sponsor - we are still $1500 USD off the pace. If your organization has some capacity to financially support this activity we would dearly love your support.

This is an official OSGeo activity; any excess money is returned to the foundation to help the next open source sprint.  OSGeo sponsorship is cumulative. Check their website for details on how your helping out the geoserver team can be further recognized.

For sponsorship details visit the wiki page (or contact Jody Garnett for assistance).

Update: Since this post was published we are happy to announce new sponsor(s).

Thanks to Caroline Chanlon and the team at Atol Conseils et Développements for bronze sponsorship.

Update: Thanks to David Ghedini (acugis.com) and others donating smaller amounts via the OSGeo paypal button.

Getting Ready for REST

In this week’s GeoServer meeting we had a chance to sit down and plan out the steps needed to get ready.

The majority of prep will go into performing the restlet to spring mvc migration for a sample REST API end point to produce a “code example” for developers to follow. We have selected the rest/styles endpoint as one of the easier examples:

1. Preflight check: Before we start we want to have a good baseline of the current REST API responses. We would like to double check that each endpoint has a JUnit test case that checks the response against a reference file. Most of our tests just count the number of elements, or drill into the content to look for a specific value. The goal is to use these reference files as a quick “regression test” when performing the migration.

2. Migrate rest/styles from StyleResource (restlet) to StyleController (spring): This should be a bit of fun, part of why spring model-view-controller was selected. Our goal is to have one Controller per end-point, and configure the controller using annotations directly in the Java file. This ends up being quite readable with variable names being taken directly out of the URL path. It is also easier to follow since you do not have to keep switching between XML and Java files to figure out what is going on.  It is important that the example is “picture perfect” as it will be used as a template by the developers over the course of the sprint, and will be an example of the level of quality we expect during the activity.

3. Create StyleInfo bindings (using XStream for xml and json generation): The above method returns a StyleInfo data structure, our current restlet solutions publishes each “resource” using the XStream library. We think we can adapt our XStream work for use in spring model-view-controller by configuring a binding for StyleInfo and implementing in using XStream.  _This approach is the key reason we are confident in this migration being a success; existing clients that depend on exactly the same output from GeoServer - should get exactly the same output. _

4. StyleController path management: There is some work to configure each controller, while we have the option of doing some custom logic inside each controller we would like to keep this to a minimum.  _This step is the small bit of applicationContext.xml configuration work we need to do for each controller, we expect it to be less work then reslet given the use of annotations. _

5. Reference Documentation Generation: We are looking into a tool called swagger for documentation generation. Our current reference documentation only lists each end-point (and does not provide information on the request and response expected - leaving users to read the examples or try out the api in an ad-hoc fashion). See screen snap below, our initial experience is positive, but the amount of work required is intimidating.

6. Updated examples for cURL and Python: We would like to rewrite our examples in a more orderly fashion to make sure both XML and JSON sample requests and responses are provided. Ideally we will inline the “reference files” from the JUnit regression test in step 1 to ensure that the documentation is both accurate and up to date.

You can see a pretty even split in our priorities between performing the migration, and updating the documentation. We believe both of these goals need to be met for success.

Next stop Tuscany

Although this blog post focuses on the sponsorship/planning/logistics side of setting up a code sprint there is one group without whom this event could not happen - our sprint participants and in-kind sponsors (providing a venue & staff).

Thanks to GeoSolutions for hosting us, and to Astun, Boundless, GeoSolutions for the hands-on participation that makes this sprint possible

For more information:

• Java 2017 Code Sprint (OSGeo Wiki) used for planning and logistics

• REST API Refresh (GeoServer Wiki) code example and technical decisions

This is a special year because the Geoserver Brazilian Community celebrates 10 years. It all started in 2007 with an GeoServer’ Course at III ENUM (event focused on MapServer) in Brasilia, federal capital, and since then the community has approximately 600 members and more than 5,000 messages exchanged during those 10 years.

During this time, GeoServer has been widely disseminated both in education, government and corporate. There are reports that large banking institutions, telecommunications and information technology companies in addition to governmental sectors such as IBGE (Brazilian Institute of Geography and Statistics), Embrapa (Brazilian Agricultural Research Corporation), IBAMA (Brazilian Institute of Environment and Natural Resources Renewables), among others, has used GeoServer in its various projects.

However, the most notable among his many successes was the establishment of GeoServer as the official map server of INDE (Spatial Data Infrastructure), in 2008 by then President Lula.

We would like to thank everyone who has contributed to the growth of GeoServer in Brazil, whether writing articles, giving lectures or simply encouraging the use of GeoServer within its institutions. A special thanks to Andrea Aime who implemented the projection used by Brazil.