Published

OGC Engineering Report

2023 Open Standards Code Sprint Summary Engineering Report
Gobe Hobona Editor Joana Simoes Editor
OGC Engineering Report

Published

Document number:23-059
Document type:OGC Engineering Report
Document subtype:Implementation
Document stage:Published
Document language:English

License Agreement

Use of this document is subject to the license agreement at https://www.ogc.org/license



I.  Executive Summary

Advances in computing, storage, sensing, and other technology areas continue to find a place in the geospatial ecosystem that makes location information findable, accessible, interoperable, and reusable. To enable geospatial standards to meet the likely interoperability needs of future technologies, it is necessary for Standards Development Organizations (SDOs) such as OGC to continue to innovate. Such innovation relies on the ability to develop new standards and improve existing ones to better address emerging interoperability challenges. Code sprints are one of a number of initiative types that OGC conducts to accelerate such innovation. 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 candidate standards.

The focus of this Engineering Report (ER) is a code sprint that was held from October 30th to November 1st, 2023. The code sprint was organized by the Open Geospatial Consortium (OGC) and hosted by Geovation in London, England. The code sprint was sponsored by Ordnance Survey (OS) at the Gold-level, as well as the European Union Satellite Centre (SatCen), US National Geospatial Intelligence Agency (NGA), and the UK Defence Science and Technology Laboratory (Dstl) at the Silver-level. As with previous OGC Code Sprints, a key goal of the October 2023 Open Standards Code Sprint was the acceleration of the development of OGC Standards and their implementation in software products.

Standards in focus for this code sprint included several OGC API, data model, and encoding standards. In addition to OGC Standards, the code sprint also included a thread focusing on the “GEOINT Imagery Media for ISR” (GIMI) profile of the ISO Base Media File Format (ISOBMFF) and the High Efficiency Image Format (HEIF). The engineering report concludes that the code sprint met all of its objectives and achieved its goal of accelerating the development of OGC Standards and their implementation in software products.

In relation to emerging extensions to OGC API Standards, the engineering report concludes that the Publish/Subscribe (PubSub), Security, and Schemas capabilities examined in this code sprint could potentially support other OGC API Standards. Regarding GIMI, the engineering report concludes that with minor changes to popular open-source base libraries a wide range of software can quickly make use of GIMI capabilities.

Regarding the Model for Underground Data Definition and Integration (MUDDI), the engineering report concludes that the MUDDI Conceptual Model is implementable and could easily be used as the basis for a logical model that can be encoded in a variety of formats including GML, GeoJSON, and Geopackage. As for JSON-FG, the engineering report concludes that due to the evident increase in adoption across the developer community, there is an increasing need to offer validators so that developers can check for compliance more easily.

The sprint participants made the following recommendations for future work items on OGC API Standards.

The sprint participants made the following recommendations for future work items on OGC Encoding Standards.

The sprint participants made the following recommendations for future work items on GIMI.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, API, openapi, html, underground, json-fg, nuar, gimi, heif, muddi

III.  Submitters

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

Table — Submitters

NameOrganizationRole
Gobe HobonaOGCEditor
Joana SimoesOGCEditor
Tom KralidisMeteorological Service of CanadaEditor
Andreas MatheusSecure DimensionsContributor
Iván Sánchez OrtegaOSGeoContributor
Florent GravinCamptocampContributor
Clemens Porteleinteractive instruments GmbHContributor
Johannes Echterhoffinteractive instruments GmbHContributor
Jérôme Jacovella-St-LouisEcere CorporationContributor
Brad HardsContributor
Sine KellyEsri UK LtdContributor
Rebecca AspinOrdnance SurveyContributor
Miles AustenOrdnance SurveyContributor
Nikita DabizhaVOLTQUANTContributor
George KolokotronisVOLTQUANTContributor
Mete Ercan PakdilMott MacDonaldContributor
Núria Julià SelvasCREAFContributor
Satish SankaranEsriContributor
Jonathan BatesGeoPlace LLPContributor
Conor LambertOrdnance SurveyContributor
Ricardo SilvaGeobeyondContributor
Arnoud de BoerGeonovumContributor
Goncalo LopesNeuroGEARS LtdContributor
Joe GuyattOrdnance SurveyContributor
Rob SmithAway Team SoftwareContributor
James ClarkeOrdnance SurveyContributor
Richard HargreavesOrdnance SurveyContributor
Neil KirkEnvitia LtdContributor
Alex Scott-JohnsEnvitia LtdContributor
Dave RoweOrdnance SurveyContributor
Carsten RoensdorfOrdnance SurveyContributor
Simon SmithOrdnance SurveyContributor
Chris PopplestoneOrdnance SurveyContributor
Neil BrammallGeospatial CommissionContributor
Gareth BoyesMGISSContributor
Michael GordonOrdnance SurveyContributor
Colin SawkinsCadent Gas LimitedContributor
Matthew LewisEsri UKContributor
Sumit SenGISE Hub, IIT BombayContributor
Paul HannEsri UKContributor
Joost FarlaGeonovumContributor
Samantha LavenderPixalytics LtdContributor
Panagiotis (Peter) VretanosMariaDB / CubeWerxContributor
Lucio ColaiacomoEU Satellite CentreContributor
Scott SimmonsOGCContributor
Chris LittleMet OfficeContributor
Michael LeedahlMaxarContributor
Ashiraf KyabainzeAT HAUSE LIMITEDContributor
Linda van den BrinkGeonovumContributor
Ingo SimonisOGCContributor
Thomas HodsonECMWFContributor
Steven McDanielHexagonContributor
Charla HarbinHexagonContributor
Joan MasoUAB-CREAFContributor
Iain BurnellDstlContributor
Bryan SeedsDstlContributor
Christopher BudasDstlContributor
Simon KnightDstlContributor
Amy BakerDstlContributor
Devon SookhooTRAX International CorporationContributor
Joe StufflebeamTRAX International CorporationContributor
Dean HintzSafe SoftwareContributor
Ryan FranzFlightSafety InternationalContributor
Hylke van der SchaafFraunhofer GesellschaftContributor

IV.  Abstract

The subject of this Engineering Report (ER) is a code sprint that was held from October 30th to November 1st, 2023 to advance the support and development of open standards within the developer community. The code sprint was organized by the Open Geospatial Consortium (OGC) and hosted by Geovation in London, England. The code sprint was sponsored by Ordnance Survey (OS), the European Union Satellite Centre (SatCen), US National Geospatial Intelligence Agency (NGA), and the UK Defence Science and Technology Laboratory (Dstl).

1.  Introduction

Code sprints are one of a number of initiative types that OGC holds during the course of each year. Other types of initiatives are design experiments, pilots, plugfests, operational exercises, interoperability experiments, and testbeds. OGC Code sprints can be either ‘universal’ or ‘focused’. All OGC working groups are invited and encouraged to set up a thread in a universal code sprint, whereas a focused code sprint is tailored to limit the number of standards in-focus to approximately three.

The October 2023 Open Standards Code Sprint was held as a universal code sprint meaning that all OGC working groups were encouraged to participate. As a result, several OGC Standards Working Groups (SWGs) set up teams of developers to collaborate during the three-day event. Whilst individual developers work on specific standards during the code sprint, these developers also get the opportunity to interact and discuss with other developers working on other standards. This makes code sprints a rich environment for knowledge transfer across teams, as well as for nurturing cross-functional teams.

This ER presents the high-level architecture of the code sprint and describes each of the standards and software packages that were deployed in support of the code sprint. The ER also discusses the results and presents a set of conclusions and recommendations. The recommendations identify ideas for future work, some of which may be more appropriate for testbeds, pilots, or other types of OGC initiatives. Therefore, the reader is encouraged to consider the recommended future work within the context of all OGC Standards development, collaborative solutions, and innovation activities.

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

2.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).

2.2. coordinate reference system

A coordinate system that is related to the real world by a datum term name (source: ISO 19111).

2.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).

2.4. Web API

An API using an architectural style that is founded on the technologies of the Web [source: OGC API — Features — Part 1: Core].

2.5.  Abbreviated terms

API

Application Programming Interface

CITE

Compliance Interoperability & Testing Evaluation

CRS

Coordinate Reference System

EDR

Environmental Data Retrieval

GIMI

GEOINT Imagery Media for ISR (GIMI)

GIS

Geographic Information System

MUDDI

Model for Underground Data Definition and Integration

NGIIS

Next Generation ISR Imagery Standards

OGC

Open Geospatial Consortium

OWS

OGC Web Services

REST

Representational State Transfer

TEAM

Test, Evaluation, And Measurement Engine

3.  High-Level Architecture

The focus of the code sprint was on the support of implementations of open geospatial standards across various software projects. Implementations of approved and candidate OGC Standards were deployed in participants’ own infrastructure in order to build an environment with the architecture shown below in Figure 1. As illustrated, the sprint architecture was designed to enable client applications to connect to different servers that implement a variety of standards. The architecture also included several different software libraries that support open geospatial standards and enable the extraction, transformation, and loading of geospatial data.

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.

3.1.  Approved OGC Standards

3.1.1.  OGC SensorThings API

The OGC SensorThings API Standard provides an open and harmonized way to interconnect devices, applications, and data over the web and on the Internet of Things (IoT) (OGC 18-088). At a high level the SensorThings API provides two main parts, namely Part I — Sensing, and Part II — Tasking. The Sensing part of the Standard provides a way to manage and retrieve observations and metadata from different sensor systems. The Tasking part of the Standard provides a way for tasking IoT devices, such as actuators and sensors. The SensorThings API follows REST principles and uses JSON for encoding messages as well as Message Queuing Telemetry Transport (MQTT) for publish/subscribe operations.

3.1.2.  OGC STAplus — an extension of the OGC SensorThings API

STAplus is an extension to the OGC SensorThings data model (OGC 22-022r1). Inspired by Citizen Science applications, STAplus supports the ‘ownership concept’ whereby observations collected by sensors are owned by (different) users that may express the license for re-use. In addition to the ownership and license abilities, the extension specified by STAplus supports the expression of explicit relations between observations and the creation of group(s) of observations.

3.1.3.  OGC API — Features

The OGC API — Features Standard offers the capability to create, manage, and query spatial data on the Web. The Standard specifies requirements and recommendations for Web APIs that are designed to facilitate the sharing of feature data. The specification is a multi-part standard. Part 1, labelled the Core, describes the mandatory capabilities that every implementing service has to support and is restricted to read-access to spatial data that is referenced to the World Geodetic System 1984 (WGS 84) Coordinate Reference System (CRS) (OGC 17-069r4). Part 2 enables the use of different CRSs, in addition to the WGS 84 (OGC 18-058r1). Additional capabilities that address specific needs will be specified in additional parts. Envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, and richer queries.

3.1.4.  OGC API — Tiles

OGC API — Tiles specifies a Standard for Web APIs that provide tiles of geospatial information (OGC 20-057). The Standard supports different forms of geospatial data, such as tiles of vector features (colloquially called “vector tiles”), coverages, maps (or imagery), and potentially eventually additional types of tiles of geospatial data.

Vector data represents geospatial objects such as points, lines, and polygons. Tiles of vector feature data (i.e., ‘vector tiles’) represent partitions of vector data covering an area (e.g., lines representing rivers in a country).

In this context, a map is essentially an image representing at least one type of geospatial information. Tiles of maps (i.e., map tiles) represent subsets of maps covering an area.

3.1.5.  OGC API — Environmental Data Retrieval

The OGC API — Environmental Data Retrieval (EDR) Standard provides a family of lightweight interfaces to access Environmental Data resources. Each resource addressed by an EDR API maps to a defined query pattern. This Standard identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval API’s. This Standard addresses both discovery and query operations. Discovery operations enable the API to be interrogated to determine its capabilities and retrieve metadata about the published resource. Query operations allow Environmental Data resources to be retrieved from the underlying data store based upon simple selection criteria, defined by this standard and selected by the client.

Version 1.1 of OGC API — EDR has recently been published (OGC 19-086r6). The EDR API Standards Working Group (SWG) has since commenced work on Part 2 of the Standard, which is tentatively titled “OGC API — Environmental Data Retrieval — Part 2: Publish-Subscribe workflow” (OGC 23-057). The focus of the EDR API-related work in this code sprint was therefore on Part 2 of the Standard.

3.1.6.  OGC API — Processes

The OGC API — Processes Standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application (OGC 18-062r2). The standard enables the execution of computing processes and the retrieval of metadata describing the purpose and functionality of the processes. Typically, these processes execute well-defined algorithms that ingest vector and/or coverage data to produce new datasets.

3.1.7.  OGC CityGML

The CityGML Standard specifies a conceptual model and encoding format for the representation, exchange, and storage of virtual 3D city models (OGC 21-006r2). The standard facilitates the integration of urban geodata for a variety of use cases, for example Urban Digital Twins, Smart Cities, Building Information Modeling (BIM), transportation, and environmental management.

3.1.8.  OGC CDB

The CDB Standard defines a standardized model and structure for a single virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. The CDB Standard defines an open format for the storage, access, and modification of a database, typically, but not exclusively, a synthetic environment database used for computer simulation.

3.1.9.  OGC GeoPackage

The GeoPackage Encoding Standard specifies the rules and requirements for an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information (OGC 12-128r18). The GeoPackage standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints.

3.1.10.  OGC GML in JPEG 2000 (GMLJP2)

The OGC’s GML in JPEG 2000 for Geographic Imagery Encoding Standard (GMLJP2) defines the means by which the Geography Markup Language (GML) Standard is used within JPEG 2000 images for geographically referenced imagery (OGC 08-085r8). The primary role of GMLJP2 is to geographically reference imagery placed in JPEG 2000 files which is achieved through description of the image geometry (domainSet) and radiometry (rangeType) by using the OGC’s Coverage Implementation Schema (CIS) Standard. GMLJP2 makes use of a built-in ability of JPEG 2000 files to include XML data for description of an image within a JPEG 2000 data file.

3.2.  Candidate OGC Standards

3.2.1.  Model for Underground Data Definition and Integration (MUDDI)

The Model for Underground Data Definition and Integration (MUDDI) candidate Standard serves as a framework to make datasets that utilize different information for underground objects interoperable, exchangeable, and more easily manageable.

The MUDDI Conceptual Model represents real-world objects found underground. It was designed as a common basis to create implementations that make different types of subsurface data — such as those relating to utilities, transport infrastructure, soils, ground water, or environmental parameters — interoperable in support of a variety of use cases and in different jurisdictions and user communities.

3.2.2.  OGC API — Records

The OGC API — Records candidate Standard provides discovery and access to metadata records that describe resources such as features, coverages, tiles / maps, models, assets, datasets, services, or widgets (OGC 20-004). 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.

3.2.3.  OGC API — Coverages

The OGC API — Coverages candidate standard establishes an access mechanism for coverages as defined by the OGC Abstract Specification Topic 6 Schema for coverage geometry and functions (OGC 20-058). The mechanism is established through a Web API which can be described by an API description language such as the OpenAPI specification. Arguably the most popular type of coverage is that of a gridded coverage. Gridded coverages, such as raster imagery, have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid.

3.2.4.  OGC Publish/Subscribe extension of OGC API Standards

OGC Web APIs provide capabilities that are typically based on HTTP requests initiated by clients. Clients have to poll APIs for collection resource updates (new features/records items, coverages, maps, etc.). Depending on a collection’s temporal resolution or frequency of updates, an event-driven / Publish-Subscribe architecture provides a timely, efficient, and low latency approach for delivery of data updates.

3.2.5.  OGC Features and Geometries JSON (JSON-FG)

The draft OGC Features and Geometries JSON (JSON-FG) Standard extends the GeoJSON format 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 (OGC 21-045). In particular, the JSON-FG Standard specifies the following extensions to the GeoJSON format:

  • the ability to use Coordinate Reference Systems (CRSs) other than WGS 84;

  • support for solids and prisms as geometry types;

  • the ability to encode temporal characteristics of a feature; and

  • the ability to declare the type and the schema of a feature.

3.3.  Specifications from the Community

3.3.1.  NGIIS GIMI

Next Generation ISR Imagery Standards (NGIIS) is a program of work to modernize Intelligence, Surveillance, and Reconnaissance (ISR) for still and motion imagery standards. Key priorities are:

  • leverage open commercial media standards to integrate still and motion imagery into a single container;

  • harmonization of still and motion imagery metadata through development of an imagery domain ontology;

  • address a broad range of use cases with a common, integrated suite of capabilities;

  • enable automation; and

  • support to disadvantaged and remote users.

NGA Standard 0076 (NGA.STND.0076) “GEOINT Imagery Media for ISR” (GIMI), currently in draft, defines a profile of the International Standards Organization / International Electrotechnical Commission (ISO/IEC) 14496-12 ISO Base Media File Format (ISOBMFF) video/audio standard and the ISO/IEC 23008-12 High Efficiently Image File Format (HEIF) Still Imagery standard. The GIMI Profile is a central element of the NGIIS program. GIMI is expected to replace the National Imagery Transmission Format (NITF) that is widely used within the US Department of Defense for ISR. It is also the likely replacement for STANAG 4545 NATO Secondary Imagery Format (NSIF) with NATO, given the close ties between NITF and NSIF.

GIMI is also expected to replace use of MPEG-2 Transport Stream in most applications using motion imagery.

GIMI builds on top of the HEIF and ISOBMFF standards. Key additions include security metadata, geopositioning and other per-image metadata and a globally-unique content identifier.

The security metadata provides a way to label the file with overall security classification, security caveats, countries to which the data may be released, and declassification information. This would typically be in the form of a US Intelligence Community marking standard known as Information Security Marking (ISM), which makes use of XML. NATO marking may use STANAG 4774 and STANAG 4778 standards. Other countries may choose a different data model and encoding, depending on national policies. For the purpose of the sprint, an indicative but imaginary format was used. Use of fake markings avoided any possible perception that test files were actually security classified data.

The final general-purpose metadata for GIMI is still in development, but is likely to be a form of Resource Description Format (RDF), likely encoded in SMTPE ST 336 Key-Length-Value (KLV) for efficiency. For the purpose of the sprint, the MISB ST 0601 UAS KLV standard was used to provide this metadata. The primary metadata was the geospatial location of the corner points of each image. There is no expectation that ST 0601 will form part of the final GIMI metadata solution, but ST 0601 KLV is possibly the best known and most widely implemented KLV encoding and provided enough information to support image geopositioning.

The Content ID was provided as a UUID encoded as a URN.

3.3.2.  AsyncAPI

AsyncAPI is a specification by the Linux Foundation for describing and documenting message-driven APIs in a machine-readable and protocol-agnostic format. The specification defines a set of files required to describe a message-driven API. The files describing an API in accordance with the AsyncAPI Specification may be encoded in JSON or YAML.

3.4.  Software Projects and Products

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

3.4.2.  OSGeo pycsw

pycsw is an implementation of the OGC API — Records candidate Standard and the OGC’s Catalog Service for the Web (CSW) Standard 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 catalog 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 the OGC API — Records — Part 1: Core, version 1.0 candidate Standard and its associated specifications. The official documentation provides an overview of all supported standards.

3.4.3.  ldproxy

ldproxy is an implementation of the OGC API family of Standards, available under the MPL 2.0 open source license. ldproxy is developed by interactive instruments GmbH, written in Java, and is deployed using Docker containers. ldproxy implements all parts of OGC API — Features, OGC API — Tiles, OGC API — Styles, OGC API — 3D GeoVolumes, and OGC API — Routes. ldproxy is an OGC Reference Implementation for Parts 1 and 2 of OGC API — Features.

3.4.4.  MariaDB Geospatial Data Server

The MariaDB Geospatial Data Server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.

  • Multiple conformance classes and recommendations of the OGC API — Tiles — Part 1: Core Standard

  • Multiple conformance classes and recommendations of the OGC API — Maps — Part 1: Core candidate Standard

  • 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, for example, Geography Markup Language (GML), GeoJSON, Mapbox Vector Tiles, MapMP, as well as several coordinate reference systems.

3.4.5.  GNOSIS Map Server

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API Standards. GNOSIS Map Server supports multiple encodings including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds, or 3D meshes), Mapbox Vector Tiles, GeoJSON, GeoTIFF, GML, and MapML. An experimental server is available online at https://maps.gnosis.earth/ogcapi and has been used in multiple OGC Innovation Program initiatives.

3.4.6.  web-gimi-viewer

web-gimi-viewer is a proof-of-concept viewer for NGIIS GIMI imagery. It is designed to run entirely in a web browser, and is intended to be a stepping stone towards more refined web client implementations as well as a testing platform for the integration of all the components needed to consume GIMI imagery.

It leverages:

4.  Results

The code sprint included multiple software applications and experimented with several standards. This section presents the key results from the code sprint.

4.1.  Approved and Candidate OGC API Standards

4.1.1.  OGC API — Records

The OGC API — Records team held two breakout sessions which focused on advancing the specification for review by the OGC Architecture Board (OAB).

Discussions included the following.

  • Target of December 2023 for OGC API — Records — Part 1: Core document submission for OAB:

    • issue sweep;

    • requirements refactoring (shared query parameters);

    • resulting ATS refactoring;

    • update on templating links (allowing for using one of variables or varBase);

    • clarification on …​/items q parameter; and

    • clean-up and validation of example JSON documents; agreement to tidy up YAML schemas and build CI workflow to ensure schemas are always valid, a bundle is built, and examples are schema valid.

  • Proposal for facets:

    • advertising facets and their types (options: separate endpoints, addition of facet: true properties in (…​/queryables);

    • specifying facets on …​/items requests;

    • agreement to review / approve proposed Pull Request (PR) and move forward as an extension; and

    • A detailed description of the proposal is presented in Clause 4.1.1.1.

  • Discussion on federation/distributed search as follows.

    • How to address live / distributed search (without metadata harvesting/metadata aggregation).

    • Current issues such as:

      • how to present results (multipart, single document with ‘grouped’ records [would break GeoJSON interoperability]); and

      • how to sort results; this could be accomplished by a front-end client (in Python or JavaScript, for example).

    • Some organizations want to provide a unified single catalog that streamlines the search experience for users.

    • Could also be put forth as a best practice on implementation.

    • Way forward could be to put forth a proposal for discussion on requirements.

4.1.1.1.  Facets extension of OGC API — Records

The code sprint was an excellent opportunity for developers to meet in person and advance the momentum on the facets proposal, which was initiated at the last OGC Code Sprint in Bussigny.

This subsection describes a proposal that aims to introduce a new extension to the OGC API — Records candidate Standard, facilitating a more straightforward understanding of dataset distribution across various criteria.

The term “Facet” here refers to a high-level piece of information computed over a set of records in a collection.

4.1.1.1.1.  Work Achieved

The team successfully prepared a proposal for integrating the facets feature into the OGC API — Records candidate Standard. This proposal includes the following.

  • Adding a new entry point /facets that returns predefined facets for the record. The concept is that the server administrator predefines a pool of facets that the client can use to represent the dataset distribution over certain fields.

  • Specifying the different types of facets, their characteristics, and settings, including adding new parameters to the /items entry point to fetch facets alongside search results.

4.1.1.1.2.  Definition of a Facet

A facet can be of several types as follows.

  • Terms facet: A terms facet can be applied to any text property and produces a list of values appearing for a specific property across all matching records, as well as the count of records containing each value.

A terms facet based on keyword countries might return a list of buckets like so:

 Greece (24 records)
 Germany (12 records)
 England (5 records)
  • Histogram facet: A histogram facet can be applied to any temporal or numeric property to distribute item values over ranges or intervals.

The facet createDate will return a list of buckets like so:

2020-01-01 to 2020-02-01: 18 records
2020-02-01 to 2020-03-01: 22 records
2020-03-01 to 2020-04-01: 43 records
  • Filters facets: A filters facets produces a count of matching records for one or several predefined queries. This essentially lets the user run “sub-queries” cheaply to have a better understanding of the composition of the search results like so.

hasDownloads : 2051 records
hasMaps : 11495 records
4.1.1.1.3.  Discussions included
  • Seeking validation from the OGC API — Records SWG to accept this new feature.

  • Technical considerations

  • Roadmap planning

4.1.1.1.4.  Roadmap
  • Subject to approval by the SWG, the proposal’s PR should be finalized, reviewed, and merged.

  • Subsequently, the team will focus on creating the extension definition resources.

  • Simultaneously, an initial implementation will be carried out in GeoNetwork and pygeopi.

4.1.2.  OGC API — Environmental Data Retrieval

The OGC API — Environmental Data Retrieval (EDR) team and PubSub enthusiasts provided two 5-minute pitch presentations, one mentor session, one breakout which focused on Publish-Subscribe workflows for EDR, and other OGC API specifications.

The 5-minute pitch presentations focused on Part 1: Core and Part 2: Publish-Subscribe capabilities to help position the subsequent mentor and breakout sessions.

The EDR PubSub mentor session included demonstrations from the joint Open Software and Open Standards Code Sprint between OGC/OSGeo/ASF that was held in Lausanne during the month of April 2023 (OGC 23-025), as well as a demo from NOAA demonstrating PubSub integration with EDR.

A breakout session was also held, focusing on technical details of EDR Part 2.

An ldproxy PubSub demo was given connecting to the WMO WIS2 Global Broker, triggering notification observations into an OGC API — Features collection as well as an additional ldproxy broker. Observations were made available using the OGC API endpoint structure with a prefix for a given server and suffix for a specific observed property. Security was also demonstrated by way of using OpenID Connect.

Discussions included the following.

  • Links requirements as discussed in Issue 451.

  • Adding a channel property to a link object is valuable for efficient binding capabilities for PubSub aware clients. Non-aware clients would simply be presented a link to a PubSub broker without further context, this is what the AsyncAPI document is there for (at the landing page, etc.).

  • Addition of the ability to cross-reference collection identifiers from an AsyncAPI document, channels.*.x-ogc-api-collection.url, for example.

  • Update link requirement to be a permission to facilitate PubSub aware client interoperability done in Pull Request 464.

  • Channels requirements as discussed in Issue 452.

  • Is the OGC API endpoint topic structure enough?

  • The Testbed-19 ldproxy demonstration prefixed topics with tokens to help make the topics unique, which is valuable in the context of broker message aggregation.

  • Consideration of filters as part of a topic, could be advanced functionality.

  • Turn channels requirement into separate conformance class, done in Pull Request 465.

  • Message payload: should make clear that if the message payload is an item, then the id property should persist. Else, if a notification, then the id property would be a GUID.

  • Cross SWG engagement and longer-term PubSub SWG activities. PubSub is a valuable capability for numerous OGC APIs:

    • Connected Systems

    • Features: feature transactions

    • Processes: subscribing to async jobs channels, new processes

    • Records: aggregation/metadata ingest/publication

    • Common: collections publishing data updates (e.g. publication of new NWP model run for EDR or Maps)

  • Engage with SWGs to determine PubSub approach to notify workflow/patterns on changes to resources.

A live demo was given which exemplified the capabilities of PubSub as a workflow for metadata catalogue management.

4.1.3.  OGC API — Features

The OGC API — Features team held a breakout to review the initial version of the new Part 5: Schemas.

The general approach taken by the new part was supported. Several proposals for changes were identified during the review as follows.

  • Change /req/schemas/logical-model into informative text (the requirement is not testable).

  • Add a “x-ogc-property-index” keyword in “Schemas” to express the sequence of the properties (in a coverage or for a feature encoding that is ordered, e.g. GML).

  • Only reference JSON Schema 2020-12 (latest version of JSON Schema).

  • In /rec/schemas/properties clarify that no other keywords should be used.

  • Add “x-ogc-unit” as a keyword in “Schemas” to declare the unit of measure of a numeric property.

  • Add “x-ogc-unit” in examples.

  • Additional ones, like the URI of a definition should be added in an extension, if needed.

  • Do not use “id” as the property name of an “id” property in the examples.

  • Improve the wording in some normative statements.

  • Consider adding a “primary-interval” role with a proper interval representation (array of two instants).

  • Fix a typo (“roadSegement” instead of “roadSegment”).

  • Remove broken dependency in Clause 13.

  • The data types of queryables should not be restricted. What is supported will depend on the filter language. Add a note that filter languages may not support data types.

A pull request was created during the sprint. The pull request was discussed, approved, and merged in the Features API SWG meeting after the sprint with the following changes.

  • Changed “x-ogc-property-index” to “x-ogc-property-seq.”

  • For the languages to specify units of measurement, a keyword “x-ogc-unit-lang” was added with the only value “UCUM” (the default). A note was added to clarify that communities or other standards can add more languages.

During the code sprint, ldproxy was updated to support the changes, notably the new “x-ogc-unit” keyword:

{
 
"$schema": "https://json-schema.org/draft/2020-12/schema",
 
"$id": "https://demo.ldproxy.net/strassen/collections/abschnitteaeste/schema",
 
"title": "Abschnitte und Äste",
 
"description": "Als Abschnitt wird ein gerichteter Teil des Straßennetzes bezeichnet, der zwischen zwei aufeinander folgenden Netzknoten liegt. Er wird durch die in den Netzknoten festgelegten Nullpunkte begrenzt.<br>Als Ast wird der Teil des Straßennetzes bezeichnet, der die Abschnitte untereinander verkehrlich verknüpft und deshalb Teil des Netzknotens ist. Er wird durch die im Netzknoten festgelegten Nullpunkte begrenzt. Eine Festlegung von Ästen erfolgt nur, wenn sie Bestandteil des aufzunehmenden Straßennetzes sind.",
 
"type": "object",
 
"properties": {
   
"kennung": {
     
"title": "Kennung",
     
"description": "16-stellige Kennung des Abschnittes oder Astes",
     
"x-ogc-role": "id",
     
"pattern": "^[0-9]{7}[A-Z][0-9]{7}[A-Z]$",
     
"type": "string"
   
},
   
...,
   
"laenge_m": {
     
"title": "Länge [m]",
     
"description": "Länge des Abschnittes oder Astes (m)",
     
"minimum": 0,
     
"x-ogc-unit": "m",
     
"type": "integer"
   
},
   
...,
   
"netzstand": {
     
"title": "Datum des Netzstichtages",
     
"x-ogc-role": "primary-instant",
     
"format": "date-time",
     
"type": "string"
   
},
   
"geometry": {
     
"x-ogc-role": "primary-geometry",
     
"format": "geometry-linestring"
   
}
 
}
}

4.1.4.  OGC API — Maps

Sprint participants from UAB-CREAF and Ecere that serve on the OGC API — Maps SWG as editors of the OGC API — Maps — Part 1: Core candidate standard worked on clarifying the candidate standard and also added an informative annex for examples. In addition, example requests were provided for an area of London, using Ordnance Survey OpenMapLocal and Copernicus Sentinel-2 data to include in the OGC API — Maps Example annex.

The Sprint participants also compared results of the GNOSIS Map Server vs. the CREAF MiraMon server including assessing recent changes for Subsetting and Scaling requirements classes and support for the scale-denominator, center, and mm-per-pixel query parameters.

4.1.5.  STAplus SensorThings API Extension

4.1.5.1.  Statement of the Challenge

The STAplus use case for the code sprint is the following: A bus company “X-Bus” operates diesel buses on different routes in the city. X-Bus has ordered some electric buses to replace diesel buses. But, because there are not enough electric buses to replace the diesel buses on all routes, X-Bus would like to replace those routes first where the air quality is the lowest. X-Bus heard that a parcel delivery service “Green Delivery” captures air quality in the city based on sensors mounted on their delivery vehicles. Green Delivery provides access to available observations via an implementation of the STAplus extension of the OGC SensorThings API Standard. Access Control is in place for the air quality data captured by Green Delivery that makes the observations readable for their users only. After coming to an agreement with X-Bus, Green Delivery allows X-Bus to read observations within the area of the city for the last 30 days.

The actual technical challenge is to protect access to the STAplus implementation. A STAplus implementation can be used to provide multiple users Create/Update/Delete/Read access to manage the users own air quality measurements. The business logic to be implemented has two aspects: Integrity and confidentiality of the uploaded observations; and the air quality measurements. As described in the OGC Best Practice for using SensorThings API with Citizen Science, the implementation of the concept of ownership is one possible solution towards integrity. The implementation of integrity can take place in the implementation itself, which allows the execution of a well-defined test harness.

Regarding the confidentiality of observations available via STAplus, there are many different use cases that would filter the requested observations differently. The following use cases are typical examples.

  • A First Responder may have access to air quality data near the incident location to determine a hazardous situation.

  • Air quality data for a given area may only be readable to users in the area.

  • Air quality data with extreme measurements may get blocked dynamically until validated.

  • Access may be limited to display of observations for a given duration into the past, e.g., last 48 hours.

  • Access may be limited over a given absolute time frame.

  • A user may declare all of the user’s data private which requires that all other users cannot access the observations of the user.

So, the challenging questions are:

  • what would an architecture look like; and

  • is it possible to implement a performant solution based on open standards?

4.1.5.2.  Purpose

The work on the challenge shall prove that a solution can be based on open standards from OGC, IETF, and OpenID Connect. Further, the sprint participants sought to prove that a solution could be implemented without having to modify the existing OGC SensorThings API nor STAplus standards. To enforce spatio-temporal access control conditions, the sprint participants also sought to prove that the combined use with the OGC GeoXACML 3 standard provided a flexible interoperable solution.

4.1.5.3.  Proposed Solution

The deployment of an OGC API implementation is described with OpenAPI providing the ability to enable authentication for endpoints of the deployed API. The available security schemes are listed on the OpenAPI Authentication page. Once the user’s identity is known, different access control rules can be enforced.

The sprint participants proposed to enable OAuth2/OpenID Connect authentication on a codesprint demo endpoint which was based on the STAplus implementation by Secure Dimensions and the SensorThings API implementation by Fraunhofer.