OGC Engineering Report

Joint OGC and ISO Code Sprint 2022 Summary Engineering Report
Gobe Hobona Editor Joana Simoes Editor
OGC Engineering Report


Document number:22-043r1
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

I.  Executive Summary

Over the past two decades, standards such as ISO 19115:2003 and the OGC Catalogue Services for the Web (CSW) have been integrated into several Spatial Data Infrastructure (SDI) initiatives at national and international levels. These standards leveraged the Extensible Markup Language (XML) which, at the time, was the primary encoding for data exchange across much of Information Technology. In recent times, however, the increasing use of JavaScript Object Notation (JSON) and the uptake of Web Application Programming Interface (API) technologies has meant that modernization of metadata and catalogue approaches is necessary.

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:

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:

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:

This engineering report makes the following recommendations for future innovation work items:

The engineering report also makes the following recommendations for things that the Standards Working Groups should consider:

II.  Keywords

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.

IV.  Submitters

All questions regarding this document should be directed to the editor or the contributors:

Name Organization Role
Gobe Hobona Open Geospatial Consortium Editor
Joana Simoes Open Geospatial Consortium Editor
Panagiotis Vretanos CubeWerx Inc. Contributor
Núria Julià Selvas UAB-CREAF Contributor
Joan Maso UAB-CREAF Contributor
Moozhan Shakeri University of Manchester Contributor
Clemens Portele interactive instruments GmbH Contributor
Matthias Mohr WWU Münster Contributor
Jeroen Ticheler GeoCat Contributor
Tom Kralidis Meteorological Service of Canada Contributor
Byron Cochrane OpenWork Ltd Contributor
Andreas Matheus Secure Dimensions Contributor
Thijs Brentjens Geonovum Contributor

V.  Abstract

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

1.  Scope

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,

Berners-Lee, T., Fielding, R., Masinter, L: IETF RFC 3896, Uniform Resource Identifier (URI): Generic Syntax,

ISO: ISO 19115-1, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva

ISO: ISO 19115-2, Geographic information — Metadata — Part 2: Extensions for acquisition and processing. International Organization for Standardization, Geneva

ISO: ISO/TS 19115-3, Geographic information —  Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva

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.

3.1. API

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 (

3.4. Metadata

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.

4.1.2.  JSON-FG

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

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.

4.1.4.  STAC

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;

  • Collection Search;

  • 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

  • Look through the issue trackers, e.g., ecosystem, stac-utils, and stactools-packages.

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].

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.

4.2.2.  ldproxy

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.3.  dataset-tagger

The dataset-tagger open source software product offers an application for fetching metadata from a dataset. The metadata model is derived from that used by OGC API Records.

4.2.4.  gleo

The gleo library is an open-source JavaScript library for WebGL-powered geographic maps. The library supports the display of geographical maps and is intended to cover the same use cases as other libraries such as Leaflet, OpenLayers.

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

The Geonovum OGC API Testclient is a basic client to showcase the interaction with implementations of OGC API — Features and OGC API — Records. It is built with LeafletJS and jQuery, for simplicity.

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.

4.3.4.  GeM+

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=”. 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).

5.  Results

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.

5.1.  gleo

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.