Second Time Around – WFS v3 and pygeoapi

May 31, 2019 · 5 min read · ogc OSgeo python wfs  ·
Share on:

TLDR;

About 10 years ago, working on my first serious geospatial contract at Dutch Kadaster , I was asked to investigate an emerging OGC standard called “WFS”, Web Feature Service . Providing a matrix of client-server interoperability was one of the expected outcomes. That is: which WFS-clients will happily fetch data from WFS server-products. I don’t have the actual outcome anymore, but I can recall: it was a very empty table: there were a few WFS server-implementations at the time: GeoServer, MapServer and deegree and some WFS clients, both Open Source and proprietary. In my recollection, only OpenLayers would interwork with the above three WFS servers. The rest had various interworking issues: around EPSG -encoding (three possible encodings!) and other vague GML issues. In short, it was a mess: remember, all we wanted to exchange were flat, table-like Simple Features: records with attributes and a single geometry (Point, Line, Polygon).

Later on, things became even worse: multiple WFS and GML versions. And not to mention GML Application Schemas like for INSPIRE . Plenty of work for WFS/GML experts, which I was considered one, but I felt cynical at some point. From my background as a software engineer at AT&T/Lucent/Bell Labs , where I developed embedded software for the public 5ESS telephone exchange , over-engineering was considered bad practice.

Also from the perspective of the emerging Agile movement : “make the simplest thing that could possibly work”, this WFS/GML ‘beast’ seemed untamable, driven by theoreticians who modeled the geospatial world from behind UML tools like Enterprise Architect . I attended numerous meetings between Dutch government organizations that had WFS/GML interworking problems. At some point I gave up: the intellectual challenges (and contracts!) were alluring, but the (geospatial) world wouldn’t progress like this. Though I used WFS and GML in many of my apps, I had a love-hate relationship with them, as a rule-of-thumb only the lowest denominator, WFS v1 and GLM2 had the most chances to interwork.

Until…back to the title of this blog. I grew up in the 70-s/80-s, so want to introduce this song. I hope the YouTube video below is embedded ok. Otherwise check out this link from Shalamar, The Second Time Around .

Fast forward to 2019: we live in an API-world: REST, Swagger , OpenApi. OGC became wiser: both in process and technology. Folks from the OSGeo Community, I must mention Chris Holmes here, advocated/pushed for a more collaborative/development-like standardization process, e.g. using GitHub over Word documents. A landmark OGC/W3C study called “Spatial Data on the Web Best Practices” recommended a more web-friendly approach.

Fast-fast forward, the above issues resulted in a brand new WFS version 3 standard under development: using both GitHub and the latest REST (Open)API technologies. Forget about WFS v1 and v2, GML v.whatever, and OWS in general with their tired GetCapabilities, this is a new road taken. Kudos to Chris Holmes, he words this better than me in this Medium Article on WFS3 .

So yes, what about this Second Time Around? Well I got attracted to WFS again (“in love” is not really appropriate for technology IMHO), for two reasons:

  1. the WFS spec and the folks/energy around it
  2. Open Source implementation of this standard in Python: pygeoapi

Python IMHO makes much much sense within the Open Source geospatial domain. For similar reasons as described above, like over-engineering (and Oracle!), I abandoned Java about 8 years ago.

So I joined the pygeoapi project. Not out of any commercial interest, but mainly out of an developer’s itch: this is useful, let’s see how this works out, a now small, but great community, several from my country, to work with.

About pygeoapi : currently the project is focused on WFS v3, but in general we attempt to implement multiple OGC REST APIs. Also, the project provides a plugin architecture: via Providers, where data can be fetched from any backend: remote services or local files. Check out our demo server which is updated constantly via the pygeoapi GitHub repo and DockerHub .

Diving a bit deeper, one of my first contributions to this project was to add an OGRProvider that would fetch from any GDAL/OGR Vector source , in particular a backend WFS. Partly from a vision: “Let’s free all those tired WFS-es out there”, but also practically: the Python GDAL/OGR bindings are so powerful, performant and reusable, saving lots of development time over developing specific Providers for GeoJSON, GeoPackage, SpatialLite, PostGIS, and even ESRI Shapefiles and FeatureServers. In theory, any OGR (Vector) Source can now be exposed via WFS v3 in pygeoapi .

There’s lots of movement around WFS v3 and OGC REST APIs in general, where both standards makers and implementors interact. Like the OGC API Hackathon in June 2019, London (sold out now!). If you ever abandoned WFS v1/v2 it is time to reconcile now!