INSPIRE is a European directive on data sharing in the environmental domain. EU member states have invested almost 20 years of effort to harmonize data in the environmental domain and publish it using OGC standards. The directive is at the end of its lifetime, but the expectation is that conventions from the INSPIRE directive will be adopted by upcoming directives, such as green deal and open data directives.
Some of the recent and upcoming good practices focus on the developments in the OGC API domain. One good practice has already been adopted on providing download services using OGC API - Features and others are in preparation, such as the discovery service using OGC API - Records. These developments make pygeoapi an interesting option for providing INSPIRE services.
INSPIRE services and their OGC API alternative
INSPIRE services are typically categorized in view services, download services and discovery services. Download services are further devided in Vector sources, Coverage sources and Sensor sources. The OGC API initiative provides the related APIs for each service. The table below highlights for each service type the Technical Guidenace recommendation and the relevant Good Practices.
|Good practice status
|OGC API - Records
|OGC API - Maps / OGC API - Tiles
|Download service - Vector
|OGC API - Features
|Download service - Coverage
|OGC API - Coverages / STAC
|Download service - Sensor
|OGC API - EDR / Sensorthings API 1
When adopting Good Practices, consider that the documentation and tools for validation are still limited. Also the INSPIRE GeoPortal may not be ready to harvest records from an OGC API - Records endpoint yet.
Publish metadata documents as an INSPIRE discovery service
In this exercise we will import a folder of metadata documents into a TinyDB database and configure the database as an OGC API - Records endpoint.
Download the zipfile 'inspire-records.zip' from the repository. Expand the zipfile. The
/tests folder contains a script
load_tinydb_records.py. The script has 2 parameters:
python3 load_tinydb_records.py <path/to/xml-files> <output.db>
Now configure TinyDB as a provider for OGC API - Records. Restart the service and verify the result. Verify also the XML output of some of the records.
OGC API and the INSPIRE data models
Most of the INSPIRE data models have a hierarchical structure, which is not common in the GeoJSON oriented OGC API community. In theory it is possible to provide hierarchical GML from an OGC API endpoint, but there are not many experiences yet currently. Two initiatives may bring improvement to this aspect:
- pygeoapi facilitates to configure a JSON-LD encoding using an arbitrary ontology. The good practice on semantic web provides some of the data models in an RDF ontology
- The good practice on alternative encodings suggests an approach to publish datasets using a relational data model such as GeoPackage, which fits better with the OGC API community
OGC API as a codelist registry
A typical use case in INSPIRE is the option to extend an INSPIRE codelist to match a local requirement. For this use case the extended codelist has to be published in a registry. OGC API - Common provides mechanisms to publish lists of concepts as items in collections. pygeoapi also provides a mechanism to advertise the concepts using the SKOS ontology via its JSON-LD encoding. In the coincidence that a concept has a geometry property, the codelist can even be published as OGC API - Features (on a map).
Publish a codelist via OGC API
A German Soiltype codelist has been made available in CSV format in
workshop/exercises/data/bodenart.en.csv. Use the CSV provider to publish this dataset in pygeoapi. Which URL would you use to reference a concept in the published list?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Congratulations! You have worked with pygeoapi for INSPIRE compliance