GeoCat was present at the OGC API hackathon in London. The event inspired our software developer Paul van Genuchten to step back and look at the latest developments. Do the standards meet the day-to-day needs of GIS professionals? And how can existing providers of Open API’s benefit from OGC API’s? He formulates alternative approaches and a warning.
Three years ago, Geonovum organized a Geo4Web Testbed in the scope of the Spatial data on the Web OGC/W3C joined working group, in which GeoCat participated. The main finding was that, due to the high level of standardization, it was quite feasible to set up a generic proxy layer to communicate with other communities on the web (open data, linked data, search engines). One can also read this as: a proxy layer is apparently needed to communicate with other communities, our standards are not compatible with the web.
In 2018, with the best practices of the spatial data on the web working group published, OGC started the WFS3 initiative. A full rewrite of WFS based on web best practices started with a hackathon in Fort Collins. Our colleague Jorge Jesus de Mendes participated in this hackathon and returned very enthusiastic, which related to his contributions to the new born project ‘pygeoapi’, a Python server implementation of the emerging OGC WFS 3.0 standard.
From then onwards, developments around WFS3 went extremely fast. Spring 2019 the OGC board announced OWS Common, a base framework for all new OGC API’s; WFS3 was renamed to OGC API Features. New initiatives are now arriving, such as OGC API Tiles, OGC API Coverage, OGC API Processes and OGC API Catalogue.
Our team members Antonio and Jorge joined the OGC API hackathon in London (20-21 June) and experienced the vibrant energy at the venue.
Photo: David Dibert on Unsplash
Who benefits from the OGC API’s?
This is also a good moment to step back and consider the developments from some distance. Two questions appear relevant. One, we have seen a lot of activity on the data serving side, web standards have been adopted, simplifications have been applied to satisfy web developers. But are the standards capable to meet day-to-day needs of the GIS professional? And two, how can existing providers of Open API’s benefit from OGC API’s?
The standard currently focuses solely on the common lat long projection, the GeoJSON encoding and limited filtering options. This focus for sure provides serious challenges to the GIS professional. It is expected new conformance classes for alternative encodings (GeoPackage, GML, JSON-LD), alternative projections and filtering options will be crafted over time.
An alternative approach is to be found in the current renaming of the OGC API’s. Since these API’s do not follow the OGC web services (W*S) naming conventions, it could be an escape route to keep maintaining the W*S standards for the GIS professional and keep the simplified OCG API’s for a more general audience. My expectation is that this is an unlikely scenario, the OGC API’s are so easy to use, many GIS professionals will switch anyway and over time will push for inclusion of advanced features.
In the Netherlands we’ve recently seen a lot of activity around Open API’s in general. The standard has been adopted by a new software framework around an upcoming environmental law (Omgevingswet). Organizations are setting up Open API’s to meet the law’s goals. Up till now there was no guidance on how these API’s should be consumed by traditional GIS software. In theory, organizations can now, by adopting OGC API, use existing tooling (GeoServer, pygeoapi) to meet requirements of the environmental law.
However, for those organizations that have already put API’s in place, a challenge arises in the quite specific conventions that OGC API requires, having a serious impact on existing implementations. Paths like /collections and /conformance are hardcoded by the specification.
An alternative approach in which these paths would not have been hardcoded but dynamically specified in a ‘capabilities’ type of document, would have been much more friendly to existing implementations. For sure it complicates the standard a bit, but also gives it a lot more flexibility.
Users will arrive via search engines
At the FOSS4GNL on June 20 at the Delft University of Technology I was able to present some of our work in this domain. My final slides warned people that this is not a far-in-the-future development, it will happen soon. In one of the next GeoServer versions, OGC API Features will be default functionality and you should be ready to receive extra visibility of your data. Users will not arrive incidentally via QGIS, OpenLayers or a GeoNetwork, but via search engines. Make sure they don’t need to experience fairly useless information snippets like this:
A feature from one of the test datasets used in the OGC API hackathon 20-21 June in London. Image: PvG – GeoCat.
Do you want to know more about alternative approaches for the new OGC API’s? Please contact Paul van Genuchten at email@example.com.