WFS 3.0 — Get Excited? Yes!

Well, get excited if you’re deep in to geospatial and open standards — I’m pretty sure a majority of the world would find this booooring.

But that’s ok. In this post I want to bring attention to the great work being done on WFS 3.0 specification from the Open Geospatial Consortium (OGC). The first awesome thing you’ll notice is that link goes to a GitHub repo, where the specification is being actively worked on, and anyone can join in and contribute. In general the core standard so far gets a whole lot right, and I believe has potential to bring much more interoperability to the geospatial world. Though I’ve been pretty vocally negative on WFS for a number of years I think the core team has made a really clean break and is embracing many of the right principles to build a really impactful specification.

So I’ve started this post a couple times, and each time I veered towards being more negative than I’d like, since I truly am quite excited by the potential of WFS 3.0. So I’m going to save more of the backstory of the evolution of WFS 3.0 and what I felt earlier versions got wrong, and stick with the things I’m excited about.

A clean break

REST + JSON in a simple core


The WFS 3.0 specification in an online OpenAPI 3.0 editor.

OpenAPI also is able to power many code generation tools that give a developer the main interfaces of the specification in their language. OpenAPI 3.0 does not yet have wide code generation support, but there is a OpenAPI 2.0 / Swagger version of the specification (it just doesn’t support XML — a huge loss ;)

Embracing the Web

The direct inspiration of the working group is a really great document called Spatial Data on the Web Best Practices, which articulates 14 solid practices. WFS 3.0 is consciously trying to follow as many as possible, which I believe will be a huge step forward — particularly having canonical HTML versions of everything, being indexable by search engines, and using lots of links to represent relationships. It also properly aligns with good REST principles, like HTTP error codes and making everything cacheable (which should help with the scalability and reliability of implementations).

A Collaborative Standard

While GitHub has been in use by the OGC for several years, there are few working groups who have migrated their standards creation workflow to make maximum use of the tools, following the best practices that open source projects have pioneered. It was used to store artifacts, but not used to get real work done. I believe the WFS standards working group is starting to make full use of the power of GitHub. Specifying the standard in OpenAPI makes collaboration even likelier — conversations about changes should be in Pull Requests, where everyone can participate, instead of phone calls that few can attend.

Always great to see an active issue tracker

I’ve been heartened by the activity in the issue tracker, and I still personally need to report on some of the feedback that people had in trying to make the SpatioTemporal Asset Catalog API be based on WFS 3.0. We ended up simplifying a couple things even more, to make implementation easier. I also am encouraged that the two main editors of the specification are still very much software developers and are making working implementations of everything they are putting in the spec.

Making WFS and OGC Better Together

Opening such a key, core specification to feedback on GitHub is a huge step forward. I hope that the wider community of developers more fluent in open source and web open standards can meet halfway. That they willtake the time to look at the specifications and give feedback, and to try to implement and really interoperate. I’m sure the process won’t be perfect, but I do believe the time is right to make our geospatial world much more accessible to the wider world, in a truly multi-vendor interoperable way.

I’ve got more to say on the evolution of this next generation of standards, as I believe WFS 3.0 is just the beginning. Indeed to me the real power will be not in a single WFS specification, but in breaking out a handful of core components (querying, filtering, linking, syncing, caching, etc) that any modern API can use to make their data more interoperable with a wider geospatial world. But I’ll save those thoughts for another post. In the meantime I encourage everyone to check out the WFS GitHub repo, give feedback, implement and contribute. The best way to make things better is to work together.

Update: I’ve published additional thoughts thoughts on potential WFS directions towards granular components and static data.

Map in Carto, my favorite cloud feature service — which does not implement WFS, but does use GeoJSON + REST. My hope is that WFS 3.0 will be something the Carto team will want to implement. (interactive link)

Product Architect @ Planet, Board Member @ Open Geospatial Consortium, Technical Fellow @ Radiant.Earth