I. Executive Summary
In November 2021, OGC and ISO held their first joint code sprint. The success of that first joint code sprint provided the foundation for a second joint code sprint. This ER summarizes the main achievements of the second joint code sprint, conducted between September 14th and 16th, 2022. The second joint code sprint, named the 2022 Joint OGC and ISO Code Sprint — The Metadata Code Sprint, served to accelerate the support of open geospatial standards that relate to geospatial metadata and catalogues. The code sprint was sponsored by Ordnance Survey (OS) at the Gold-level and Geonovum at the Silver-level. The code sprint was held as a hybrid event, with the face-to-face element hosted at the Geovation Hub in London, United Kingdom.
The code sprint focused on the following group of specifications:
OGC Features and Geometries JSON (JSON-FG) candidate Standard 
Spatio-Temporal Asset Catalog (STAC), which leverages the OGC API — Features Standard 
The OGC is an international consortium of more than 500 businesses, government agencies, research organizations, and universities driven to make geospatial (location) information and services FAIR — Findable, Accessible, Interoperable, and Reusable. The consortium consists of Standards Working Groups (SWGs) that have responsibility for designing a candidate standard prior to approval as an OGC Standard and for making revisions to an existing OGC Standard. The sprint objectives for the SWGs were to:
Develop prototype implementations of OGC Standards, including implementations of draft OGC Application Programming Interface (API) Standards;
Test the prototype implementations;
Provide feedback to the Editor about what worked and what did not; and
Provide feedback about the specification document.
Technical Committee 211 (TC 211) of ISO is responsible for the development and publication of standards that relate to geographic information. As with other ISO committees, TC 211 consists of member nations, as well as liaison partner organizations. TC 211 and OGC have a liaison partnership that enables the organizations to participate in each other’s activities and also to collaborate on standards development initiatives. The sprint objectives for ISO/TC 211 were to:
Support the development of ISO Standards;
Fix open issues;
Develop new features; and
Encourage the implementation of ISO Standards.
This engineering report makes the following recommendations for future innovation work items:
Initiatives to facilitate implementation of JSON-FG (e.g., three-dimensional (3D) data, cadastral data, etc.);
Initiatives to facilitate implementation of catalogues; and
Prototyping of tools for creating metadata (e.g., the automated STAC metadata crawler demonstrated during the sprint).
The engineering report also makes the following recommendations for things that the Standards Working Groups should consider:
Outreach for promoting JSON-FG;
Code Sprint for designing profiles of JSON-FG for different communities of interest;
Documentation of the different roles of catalogues and API, as well as guidance on when to use them;
Code Sprint on versioning, possibly involving both OGC API — Records and OGC API — Features; and
Exploring how to move GeoDCAT forward within OGC.
The following are keywords to be used by search engines and document catalogues.
hackathon, metadata, code sprint, API, catalogue, record
III. Security considerations
No security considerations have been made for this document.
All questions regarding this document should be directed to the editor or the contributors:
|Gobe Hobona||Open Geospatial Consortium||Editor|
|Joana Simoes||Open Geospatial Consortium||Editor|
|Panagiotis Vretanos||CubeWerx Inc.||Contributor|
|Núria Julià Selvas||UAB-CREAF||Contributor|
|Moozhan Shakeri||University of Manchester||Contributor|
|Clemens Portele||interactive instruments GmbH||Contributor|
|Matthias Mohr||WWU Münster||Contributor|
|Tom Kralidis||Meteorological Service of Canada||Contributor|
|Byron Cochrane||OpenWork Ltd||Contributor|
|Andreas Matheus||Secure Dimensions||Contributor|
The subject of this Engineering Report (ER) is a code sprint that was held from the 14th to the 16th of September 2022 to advance open standards that relate to geospatial metadata and catalogues. The code sprint was hosted by the Open Geospatial Consortium (OGC) and the International Organization for Standardization (ISO). The code sprint was sponsored by Ordnance Survey (OS) and Geonovum, and held as a hybrid event with the face-to-face element hosted at the Geovation Hub in London, United Kingdom.
Joint OGC and ISO Code Sprint 2022 Summary Engineering Report
The code sprint described in this engineering report was organized to provide a collaborative environment that enables software developers, users, and architects to work together on open standards that relate to geospatial metadata and catalogues. The engineering report presents the sprint architecture, the results of the prototyping, and a discussion resulting from the prototyping.
A Code Sprint is a collaborative and inclusive event driven by innovative and rapid programming with minimal process and organization constraints to support the development of new applications and open standards. Code Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, and are used for building proofs of concept to support standards development activities and enhancement of software products.
2. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md
Berners-Lee, T., Fielding, R., Masinter, L: IETF RFC 3896, Uniform Resource Identifier (URI): Generic Syntax, https://tools.ietf.org/rfc/rfc3896.txt
ISO: ISO 19115-1, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva https://www.iso.org/standard/53798.html.
ISO: ISO 19115-2, Geographic information — Metadata — Part 2: Extensions for acquisition and processing. International Organization for Standardization, Geneva https://www.iso.org/standard/67039.html.
ISO: ISO/TS 19115-3, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva https://www.iso.org/standard/32579.html.
3. Terms, definitions and abbreviated terms
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
An Application Programming Interface (API) is a standard set of documented and supported functions and procedures that expose the capabilities or data of an operating system, application, or service to other applications [adapted from ISO/IEC TR 13066-2:2016].
3.2. coordinate reference system
A coordinate system that is related to the real world by a datum term name [source: ISO 19111]
3.3. OpenAPI Document
A document (or set of documents) that defines or describes an API. An OpenAPI definition uses and conforms to the OpenAPI Specification (https://www.openapis.org)
information about a resource [source: ISO 19115-1:2014, Amendment 2]
3.5. Web API
API using an architectural style that is founded on the technologies of the Web [source: OGC API — Features — Part 1: Core]
3.6. Abbreviated terms
Application Programming Interface
Coordinate Reference System
Geographic Information System
Open Geospatial Consortium
OGC Web Services
Representational State Transfer
4. High-Level Architecture
As illustrated in Figure 1, the sprint architecture was designed with the view of enabling client applications to connect to different servers that implement open geospatial standards that relate to metadata and catalogues. Implementations of JSON-FG, ISO 19115, STAC, and OGC API — Records were deployed in participants’ own infrastructure in order to build a solution with the architecture shown below in Figure 1.
Figure 1 — High Level Overview of the Sprint Architecture
The rest of this section describes the software deployed and standards implemented during the code sprint.
4.1. Approved and Draft Standards
This section describes the approved and draft standards implemented during the code sprint.
4.1.1. OGC API — Records
The OGC API — Records candidate standard provides discovery and access to catalogues of metadata records about resources such as features, coverages, tiles / maps, models, assets, services, or widgets. The candidate standard enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed. The candidate standard also enables the discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed. OGC API — Records can be considered the future successor to the widely implemented Catalogue Services for the Web (CSW) standard.
The candidate standard specifies the information content of a record. A record contains summary descriptive information about a resource that a provider wishes to make discoverable. Records are organized into collections. A record represents resource characteristics that can be presented for evaluation and further processing by both humans and software. Examples of resources include: a data collection, a service, a process, a style, a code list, an Earth observation asset, a machine learning model, a code list, and so on.
JSON-FG (Features and Geometry JSON) extends GeoJSON to support a limited set of additional capabilities that are out-of-scope for GeoJSON, but that are important for a variety of use cases involving feature data.
The following extensions to the GeoJSON Standard were, in particular, tested during the Code Sprint:
The ability to use Coordinate Reference Systems (CRSs) other than WGS 84;
Support for solids as geometry types; and
The ability to encode temporal characteristics of a feature.
A key design pattern of JSON-FG is that information that can be represented as GeoJSON is encoded as GeoJSON. Additional information is mainly encoded in additional members of the GeoJSON objects. The additional members use keys that do not conflict with GeoJSON or other known GeoJSON extensions. This is done so existing and future GeoJSON clients will continue to parse and understand GeoJSON content. JSON-FG enabled clients will also be able to parse and understand the additional members.
JSON Schema is used to formally specify the JSON-FG syntax.
The draft specification is available at https://docs.ogc.org/DRAFTS/21-045.html.
4.1.3. ISO 19115
ISO 19115 Standards define the schema required for describing geographic information and services by means of metadata. Metadata is information about a resource such as a dataset, web service, or API. This multi-part International Standard is applicable to the cataloguing of datasets, clearinghouse activities, geographic datasets, dataset series, individual geographic features, and feature properties.
The individual parts of ISO 19115 that each serve as an approved standard include:
ISO 19115-1:2014 defines the schema required for describing geographic information and services by means of metadata;
ISO 19115-2:2019 extends ISO 19115-1:2014 by defining the schema required for an enhanced description of the acquisition and processing of geographic information, including imagery; and
ISO/TS 19115-3:2016 defines an integrated XML implementation of ISO 19115‑1, ISO 19115‑2, and concepts from ISO/TS 19139.
The SpatioTemporal Asset Catalog (STAC) is a specification that offers a language for describing geospatial information, so it can be worked with, indexed, and discovered. The STAC API offers an interface that implements OGC API — Features. Although STAC has been developed outside of the OGC, in the long term it is envisaged that the STAC API specification will be developed into an OGC Community Standard that implements OGC API building blocks that are relevant for the STAC use cases.
The goals for the STAC part of the code sprint were:
Alignment with OGC API — Records — Content Model and/or Extensions;
Alignment with other standards, for example GeoDCAT and/or JSON-LD;
JSON-FG vs. STAC projection extension;
A possible push towards STAC API 1.0.0 release;
Advance the STAC ecosystem (e.g., PySTAC, QGIS plugin, …); and
STAC is a multi-part specification that includes the following constituent parts.
STAC Item is a representation of a single spatio-temporal asset, encoded as a GeoJSON feature with datetime and links properties.
STAC Catalog is a JSON-encoded representation of links that provides a structure for organizing and browsing STAC Items.
STAC Collection extends the STAC Catalog to offer additional information such as the extents, keywords, license, providers, and other elements that describe STAC Items grouped within the Collection.
STAC API provides a RESTful interface that conforms to the OGC API — Features standard, described in an OpenAPI definition document, and supports search of STAC Items.
Each of the above-listed parts can be used on its own, however the parts have been designed to offer optimal capabilities when used together. An in-depth description of the relationship between the STAC API and Static STAC catalogs is provided in a blog post by Chris Holmes .
4.2. Open Source Software Projects
This section describes open source software products that were deployed during the code sprint.
4.2.1. OSGeo GeoNetwork
GeoNetwork is a catalog application for managing spatially referenced resources. It provides metadata editing and search functions as well as an interactive web map viewer.
GeoNetwork is used for (meta)-data management by governments, local communities and private sector. It is also used to discover geospatial (and other) (open) data supporting multiple metadata standards and multiple catalog interfaces.
OGC Standards have been core to the GeoNetwork project and the community is now working on the implementation of the OGC API — Records specification.
ldproxy is an implementation of the OGC API family of specifications, inspired by the W3C/OGC Spatial Data on the Web Best Practices. ldproxy is developed by interactive instruments GmbH, written in Java (Source Code), and is typically deployed using docker (DockerHub). In addition to supporting commonly used data formats for geospatial data, an emphasis is placed on an intuitive HTML representation.
The current version supports PostgreSQL/PostGIS databases, GeoPackages and WFS 2.0 instances as backends for feature data. MBTiles is supported for tilesets.
ldproxy implements all conformance classes and recommendations of “OGC API — Features — Part 1: Core” and “OGC API — Features — Part 2: Coordinate Reference Systems By Reference” and is an OGC Reference Implementation for the two standards. ldproxy also supports the OGC API Records draft as well as the draft extensions of OGC API — Features (that is Part 3, CQL2, Part 4 and most of the current proposals discussed by the Features API working group). It supports GeoJSON, JSON-FG, HTML, FlatGeoBuf, CityJSON, glTF 2.0 and GML as feature encodings.
ldproxy also has implementations for additional resource types: Vector and Map Tiles, Styles, Routes, 3D Tilesets.
ldproxy is distributed under the Mozilla Public License 2.0.
4.2.5. OSGeo pygeoapi
pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation.
pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.
4.2.6. OSGeo pycsw
pycsw is an OGC API — Records and OGC CSW server implementation written in Python. Started in 2010 (more formally announced in 2011), pycsw allows for the publishing and discovery of geospatial metadata via numerous APIs (CSW 2/CSW 3, OpenSearch, OAI-PMH, SRU), providing a standards-based metadata and catalogue component of spatial data infrastructures. pycsw is Open Source, released under an MIT license, and runs on all major platforms (Windows, Linux, Mac OS X). pycsw is an official OSGeo Project as well as an OGC Reference Implementation.
pycsw supports numerous metadata content and API standards, including OGC API — Records — Part 1.0: Core and its associated specifications. The official documentation provides an overview of all supported standards.
4.2.7. OSGeo pygeometa
pygeometa provides a lightweight and Pythonic approach for users to easily create geospatial metadata in standards-based formats using simple configuration files (affectionately called metadata control files (MCF)). The software has minimal dependencies (install is less than 50 kB), and provides a flexible extension mechanism leveraging the Jinja2 templating system. Leveraging the simple but powerful YAML format, pygeometa can generate metadata in numerous standards. Users can also create their own custom metadata formats which can be plugged into pygeometa for custom metadata format output. pygeometa is open source and released under an MIT license.
For developers, pygeometa provides a Pythonic API that allows developers to tightly couple metadata generation within their systems and integrate nicely into metadata production pipelines.
The project supports various metadata formats out of the box including ISO 19115, the WMO Core Metadata Profile, and the WIGOS Metadata Standard. The project also supports the OGC API — Records core record model as well as STAC (Item).
4.2.8. OSGeo OWSLib
OWSLib is a Python client for OGC Web Services and their related content models. The project is an OSGeo Community project and is released under a BSD 3-Clause License.
OWSLib supports numerous OGC standards, including increasing support for the OGC API suite of standards. The official documentation provides an overview of all supported standards.
4.3. Proprietary products
This section describes proprietary software products that were deployed during the code sprint.
4.3.1. MariaDB CubeWerx CubeServ
The CubeWerx server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.
All conformance classes and recommendations of the OGC API — Features — Part 1: Core Standard.
Multiple conformance classes and recommendations of the OGC API — Records — Part 1: Core candidate Standard.
Multiple conformance classes and recommendations of the OGC API — Coverages — Part 1: Core candidate Standard.
Multiple conformance classes and recommendations of the OGC API — Processes — Part 1: Core Standard.
Multiple versions of the Web Map Service (WMS), Web Processing Service (WPS), Web Map Tile Service (WMTS) and Web Feature Service (WFS) Standards.
A number of other “un-adopted” OGC Web Service draft specifications including the Testbed-12 Web Integration Service, OWS-7 Engineering Report — GeoSynchronization Service, and the Web Object Service prototype.
The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g., GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.
4.3.2. Geonovum OGC API Testclient
4.3.3. 3DGI CityJSON and JSON-FG Viewer
Participants from 3DGI and Geonovum worked on an extension of a CityJSON viewer to enable support for JSON-FG. CityJSON is an OGC Community Standard for a JSON-based encoding for a well-documented subset of the OGC CityGML data model (version 2.0.0). CityJSON defines how to store digital 3D models of cities and landscapes.
GeM+ is an application built for the MS Windows environment. It enables users to create, manage and edit metadata from a variety of geographic data. GeM+ is able to read some of the most common formats, and to dynamically transfer to the metadata some information extracted from the data itself. Note that GeM+ is the metadata editor of the MiraMon product suite from UAB-CREAF.
4.4. Other solutions
This section describes other solutions that were deployed for the code sprint.
4.4.1. Secure and Asynchronous Catalogue
There are many factors that influence the response time of a server when it receives a request from a client application. Socket timeouts can occur while the client application waits for a response from the server. To avoid losing the response for requests that require a processing time that is longer than socket timeout, the communication to the client application may continue ‘asynchronously.’ That means that the service to client application communication does not take part on the original sockets; it happens somehow else.
The proposed solution from the OGC Testbed-18 Secure & Asynchronous Catalogue team was to leverage the HTTP Prefer header (as defined in IETF RFC 7240) that enables the client application to indicates to the server about the response preferences. For example, a Prefer header with the value “respond-async, wait=10” indicates that the client application is able (willing) to wait 10 seconds for a response and that an asynchronous response is preferred. To control a generic carry-on for OGC APIs via asynchronous follow-up communication, the Testbed 18 team recommended definition of OGC specific Prefer header parameters. One example is to define the parameter subscription which links to an existing subscription that defines a particular way of carrying-on. For example, the following Prefer header extends the previous example indicating the service to use a particular subscription identified via the URI: “Prefer: respond-async, wait=10, subscription=https://ogc.demo.secure-dimensions.de/sms/subscriptions/4711”. In case the service honors the indicated client application preference, the HTTP response must contain the HTTP Header Preference-Applied including the parameter that was accepted. For the previous example, the acceptance of the subscription option is expressed with the HTTP Response header “Preference-Accepted: subscription”.
This proposed solution requires however that a generic Subscription Management Service (SMS) exists and that the OGC API implementation introspects the HTTP Request headers and checks for the Prefer header. This checking can be achieved in a generic OGC API gateway for example. For the Code Sprint, the Testbed-18 team sought to extend the SMS prototype implemented during Testbed-18 with an additional “carry-on” communication: WebPush as defined by W3C Push API. This required a client and a service implementation. The code sprint provided an opportunity for the Testbed-18 team to explore the proposed solution in collaboration with other sprint participants. The proposed solution leveraged the Authenix product, an OAuth2 / OpenID Connect compliant authorization server based on federated identity management.
4.4.2. University of Manchester Natural Language Processing for Spatial Analysis
Participants from the University of Manchester implemented a Natural Language Processing (NLP) toolkit for conducting spatial analysis. The toolkit takes as input a statement such as “I want to see parks in Westminster” and then displays the locations of the requested features (parks) in the location of interest (Westminster).
The code sprint included multiple software products and implementations of OGC and ISO Standards. This section presents some of the results from the code sprint.
One of the contributors of gleo implemented support for JSON-FG in the code sprint. Support for JSON-FG was implemented to enable anyone to integrate the JSON-FG files into a gleo application.