A WFS 3.0 prototype in GeoServer; are we getting it right?

Blog, News ‐ Posted on 12.03.2018 by simone giannecchini

WFS 3.0

Dear Reader,

Let us start with a word of caution, this is going to be a rather technical post on the new version of the OGC WFS protocol, so do not expect nice images but rather a technical discussion about protocols, formats and the like. Good news is that you will not see much XML which is 180 degrees change with respect to working with current OGC protocols; although “everybody loves XML” this will make a few people in the GIS community happy (hey JS developer… yes, I am talking to you…). So, if you still haven’t moved away from this post, let’s deep dive into this new creature we are growing.

Our GeoServer technical lead Andrea Aime joined the WFS 3.0 hackathon this week, together with a few well-known names in the OGC and FOSS4G community to build a WFS 3 core prototype for GeoServer, delivered as a community module and available to be tested online for the braves. In the following paragraphs we are going to give some quick feedback from this experience hoping that it will help others to understand where WFS is going as well as out OGC colleagues to keep pushing forward with this effort.

About WFS 3.0

The WFS3.0 core protocol is geared towards the web and simplicity: dominated by (Geo) JSON representations, only supports WGS84 in and out, it’s schema-less, and has limited filtering and paging abilities. Everything else you’re used to see in WFS 1.1 or WFS 2 will be delivered as extensions to the core, that implementors can decide to implement, or not.  The approach is similar to WCS, small core and various extensions, helps getting started implementing the protocol and it’s a lot of help when building custom servers.

Going back to core, the equivalent of a “capabilities” document is split into two, a “contents” document simply listing the available layers, and a “api” document, OpenAPI 3.0 in particular, describing the details of how calls should be made. Eventually, a last set of call can be made to get features, in one of the supported formats (GeoJSON, GML, HTML).

Implementing WFS 3.0 in GeoServer

We joined the hackathon with no previous preparation or code, everything was started from scratch in a new community module. Had it been a traditional OGC specification, implementing the required parts of the protocol would have been “mission impossible”.

Thankfully WFS 3.0 core is pretty simple, while still supporting the basic needs of web clients, and we could leverage some existing facility in terms of spatial filtering, paging and  GeoJSON encoding. Here are a few example links from the GeoServer prototype:

Mind you, those links should be only used to get a feeling, the community module is not a complete nor fully correct implementation of WFS 3.0 core. That said, a couple of experimental clients can already successfully extract data from GeoServer WFS 3.0, including the new GDAL/OGR experimental driver.

Conclusions and Feedback

Generally speaking, working on this WFS 3.0 prototype has been a learning experience (OpenAPI 3 wise, after documenting the GeoServer REST API with Swagger 2.0), and a useful change of pace that will help acceptance and usage of OGC protocols among the current generation of GIS developers, both client and server side.

As far as the protocol itself is concerned, we believe that in order to see this protocol performing in the real world there is still work to be done which might result into extensions to cover what follows:

  • Scalability towards thousands of layers or more, maybe with some way to filter the API document and paging support for the contents document
  • Sorting and random paging support. This is crucial to use this protocol with real world datasets from web clients.
  • CRS and reprojection support, for various reasons, such as relieving clients from reprojection (they could only be interested in web mercator), supporting national laws requiring published data in certain local CRSs, and making sure no un-necessary datum shifts are performed when high precision is required.
  • A CRS extension that clearly specifies axis order used by the server, without having to refer to an external database that may or may not be there. Also, bake that information in responses when possible.
  • Sophisticated filtering, but the easy way… can we propose Extended CQL (GeoServer‘s own variant) as a base for human friendly filtering? This is has been used and reviewed already in OGC TestBed 13 to implement seamless filtering across WMS, WFS and WCS services ad described in the Fit-for-Purpose Engineering Report.
  • Schema declaration for cases where data actually follows a fixed schema (a must have for build complex filters, too). An OpenAPI schema will do in most cases, but for more complex ones, provide allowance to use XSD (think INSPIRE schemas for example).

Long story short, WFS 3.0 is a step in the right direction that will help spread adoption of a service that has in the past been limited by its complexity. The OpenAPI approach, allowing quick and automatic generation of ad-hoc client libraries should also favour its usage and reduce time to market for solutions based on OGC protocols.

The rich functionality provided by previous WFS versions should however not be ignored, but properly managed into a set of clear and well known extensions. Also, the core should be kept supple and easy to extend, in order to favour the wide variety of vendor extensions out there, helping the best of them to be recognized and shared to the wider community, much like GeoPackage already does.

Last but not least, it is worth to point out that we will perform more work on WFS 3.0 implementation for GeoServer throughout 2018, including adding other extensions, so stay tuned and follow this blog for more info.

And now, since you have read so far, if you are interested in learning about how we can help you achieving your goals with open source products like GeoServer, MapStore, GeoNode and GeoNetwork through our Enterprise Support Services and GeoServer Deployment Warranty offerings, feel free to contact us!

The GeoSolutions team,

See also