GeoCat had an opportunity to sponsor an event that perfectly captures what we love to do as a company. In February 2021 the Open Geospatial Consortium (OGC) combined forces with two open source foundations, the Apache Software Foundation (ASF), and Open Source Geospatial Foundation (OSGeo), to work on the next generation of geospatial standards.
Structured as a code sprint, with enthusiasts from government, industry and the community setting aside time to work together. GeoCat attended with a large team contributing to the standards, along with the GeoServer, GeoNetwork, pygeoapi, OWSLib and QGIS projects.
This update reports some of our impressions and findings from the sprint.
About OGC API Family of Standards
OGC API is a new suite of standards under active development at the Open Geospatial Consortium. These standards are guided by web standards and best practices such as publishing resources using IANA Media Types, REST web services, defined using the OpenAPI specification. For ease of use web services provide HTML encoding for browser access, and JSON encodings for JavaScript clients.
Open Geospatial Consortium Code sprint
Adopting the open source “code-sprint” format to forward the standards is a new direction of OGC. This hands-on approach prevents creating a standard is a paper exercise, finding out right away challenges during implementation.
My personal experiences from this sprint confirmed the value of this approach. I worked on a plugin for QGIS, Metasearch, to enable OGC API Records discovery next to the existing Catalog Service for the Web. Client development requires different aspects from a standard than server development. For example, how do you bind to an OGC API Features service, after having discovered it in an OGC API Records resource. The client benefits if the record advertises binding details of the service in a standardised way.
Image: OGC API Records Search from within QGIS (Metasearch)
The opportunity for rapid feedback and revision is the real opportunity of these events. The GeoServer channel working on OGC API Records had the opportunity to ask questions which led to the standard changing the next day. On the other hand there is a feeling of unease with developers that are used to work with traditional OWS standards. Due to the fact that the standards are changed while implementation issues are raised, it is required to keep altering the software until the final standard is done.
With this in mind, it is hard to adopt the early access OGC API standards in our products. This is unfortunate as OGC API is already so much better, and the continual standard changes delays when these can be recommended for production use. The continual change also causes the development to be quite an investment for GeoCat before this can be included in our Enterprise products to generate revenue. Fortunately we’ve found a number of partners that co-fund these developments and accept an early-access implementation of the standard.
The Open Geospatial Consortium has provided an engineering report for the event and published a blogpost.
Image: Interactive documentation page of the OGC API Records implementation in GeoNetwork
Exploring Apache Software Foundation Technologies
This sprint was the first time that we worked with members from the Apache Software Foundation. The group was working on improving geospatial support in Jena Fuseki, their triple store implementation. They were looking for export options of geodata from QGIS to RDF and were happy to find out that GeoServer has a module to create GeoJSON-LD. They improved the GeoJSON-LD capabilities of Jena Fuseki during the sprint. That aspect added some interesting discussion topics to the sprint.
Personally I did some tests with the Jena Arq command line client to query the OGC API’s using SPARQL. Some implementations, like GeoServer, ldproxy and pygeoapi offer GeoJSON-LD support as part of the OGC API implementation, which in theory makes the API accessible to SPARQL engines. I got some interesting results. However, hopping from document to document was poor, due to the fact that many of the implementations do not yet include the link section in their LD-context. Introduction of the Hydra ontology would be an interesting direction to improve that aspect.
Working with Open Source Geospatial Foundation
For pygeoapi, GeoNetwork and QGIS, the main goal of the sprint was to introduce the OGC API Records standard in the software.
With such a large GeoCat team taking part we had an opportunity to advance the OGC API Records implementation quite a bit on each of the projects. Support for records has been merged into pygeoapi during the sprint, the GeoNetwork team made a big refactor of the already existing implementation, and a Pull Request to QGIS has been sent out.
Having a client implementation in QGIS helped in comparing and validating the various OGC API Records implementations.
Image: Locating the same data via QGIS and directly in the service (service provided by pygeoapi, data Nationaalgeoregister.nl and OpenStreetMap contributors)
The GeoServer team worked on OGC API Features and started looking at OGC API Maps. GeoCat staff worked on the user interface and documentation.
Image: GeoServer OGC API features
Plan for OGC API with GeoCat
We strongly invite you to talk to us to discuss what benefits OGC API will bring to your organisation and to help define the roadmap that allows OGC API’s to be introduced in your workflows. GeoCat offers services around OGC API via its products GeoCat Live (SAAS), GeoServer, GeoNetwork, pygeoapi and QGIS.
The post OGC API sprint – February 2021 appeared first on GeoCat bv.