When browsing through the OGC Web Feature Service (WFS) version 2.0 standard the first time back in 2011 I remember wondering how close the API it defined was to a generic database access: all the basic CRUD (create, read, update, delete) operations, data query with filtering, and no fixed definition for the data model of the information the service provides. In a way it seemed like a neat generic solution to publishing various kinds of spatial “feature” data using a single set of defined operations, but on the other hand building a client application to work with such a generic API seemed, and still is, a challenge.
In a way the API in WFS standard was only defined half way: there had to be a predefined agreement, in addition to agreeing on using WFS, between the client and the service on the data content and structure for interoperable data exchange. Gradually I’ve also started to wonder what all this technical agreeing and coding has to do with handling geospatial data, and shouldn’t we use the same solutions for defining interoperable APIs as everyone else in the Web world is using, and as it turns out, I’m certainly not alone thinking along these lines.
The idea of using mainstream API technologies, resource-oriented data access patterns for spatial data and generally making the browsing the data both more web-browser and web-developer friendly has been pioneered in the development of the OGC WFS 3.0 standard now officially called “OGC API – Features: Part 1 – Core”. This new standard has been written entirely from scratch, and it’s really a completely different beast compared to its predecessor WFS 2.0: It embraces (although does not mandate) defining the service API using OpenAPI specification (previously known as Swagger) with wide industry and tool support outside the geospatial domain. It also introduces JavaScript Object Notation (JSON) format as a first class citizen for both the service and the data encoding, although XML encoding is still a viable option.
In addition to making adopting a spatial data API more straightforward to developers, the OGC API – Features standard also encourages server software implementers to make the services speak the native language of the Web: HTML service landing page as well as web browser accessible feature collection metadata and data content browsing rises the accessibility of a service on the completely new level compared to having the traditional OGC Web Service capabilities XML document.
The OGC WFS/FES working group responsible for defining the new OGC API – Features: Part 1 – Core standard is currently working with the first release candidate version of the specification to be submitted into the official OGC and ISO / TC 211 approval process. The core standard in intentionally stripped down what comes to functionality: even the pretty common place functionality such as support for coordinate reference systems additional to WGS84, query filtering beyond bounding box, time, and explicit feature property value matching, and updating feature collections, will be defined as extensions to the core standard. This allows implementing only the subset of the functionality really required for particular use cases and environments. Considering fact that this new standard is a galaxy away from being backwards-compatible with WFS 2.0, and the considerable existing investment made in the WFS 2.0 technology, it’s clear that both standards will be actively used for quite a while.
The working method for getting up to this point has been open and transparent with the first draft version made publicly available in April 2018. The ideas and the requirements have been properly wetted in hackathons, various software implementation projects and using the project’s open Github repository. The group members have strongly expressed that the final standard should be a technically mature, stable basis for building feature based spatial data web access APIs. No wonder there has been considerable interest within the OGC membership to follow the path set by the WFS/FES standards working group and widening the scope of the new kind of spatial data APIs outside feature data.
We at Spatineo have had the opportunity to be one of the early implementers of the OGC APIs – Features / WFS3 specification as we have worked together with the Vaisala and the Finnish Meteorological Institute technical people in the Simple Observation Features Pilot project (SOFP). The idea has been to create a proof-of-concept for testing out two sides of the same coin:
- How well does the well OGC API – Features specification fit for delivering dynamic data such as near real-time weather and air quality observation data?
- How the draft Simple Feature profile for Observations and measurements (OMSF) data model with JSON and XML encodings really work with real-world environmental observation and forecast data?
- How well does the combination of WFS3 API and OMSF GeoJSON encoding work with existing GIS and web map applications with as QGIS, OpenLayers, Leaflet?
The project started in August 2018 and it’s expected to end in October 2019. The front-end server component developed during the project (sofp-core server) is based on Node.js server engine and delegates the data requests to one of the configured backend modules. A few notable links on the project for those interested in more details:
- FMI demo service using the sofp-core and existing SmartMet Server backend
- Code project for the sofp-core managed by Vaisala is licensed with the MIT OpenSource license
- FMI SmartMet server backend integration project is also licensed with the MIT license
- OMSF data model with the GML and GeoJSON encodings
