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.

In this code sprint, activity related to the OGC SensorThings API focused on a WebSub extension to the OGC SensorThings API Standard. The OGC SensorThings API Extension WebSub prototype is based on the W3C WebSub Recommendation. The prototype supports subscribe/unsubscribe and opaque discovery capabilities that are offered by implementations of OGC SensorThings API.

3.1.2.  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.3.  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.4.  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 been published (OGC 19-086r6). The EDR API Standards Working Group (SWG) has recently obtained approval to publish Part 2 of the Standard: “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 is therefore on the use of Part 2 of the Standard. Work continues on defining improvements to Part 1: Core Version 1.1 to be known as Version 1.2.

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

The OGC API — Processes — Part 2: Deploy, Replace, Undeploy candidate Standard extends the core capabilities specified in the OGC API — Processes — Part 1: Core (OGC 18-062r2) with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

3.1.6.  Training Data Markup Language for Artificial Intelligence

The Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) is a Standard for describing Machine Learning Training Datasets and their quality, as well as how they have been developed. Version 1.0 of the Part 1: Conceptual Model Standard has been published. Parts 2 & 3 with JSON and XML encodings have been submitted to OGC.

3.1.7.  OGC CoverageJSON

CoverageJSON is a format for encoding coverage data such as grids, time series, and vertical profiles, each distinguished by the geometry of their spatiotemporal domain. A CoverageJSON document is serialized in JavaScipt Object Notation (JSON). A CoverageJSON object represents a domain, a range, a coverage, or a collection of coverages. A range in CoverageJSON represents coverage values. A coverage in CoverageJSON is the combination of a domain, parameters, ranges, and additional metadata. A coverage collection represents a list of coverages.

3.2.1.  OGC API — Connected Systems

The OGC API — Connected Systems candidate Standard specifies the fundamental API building blocks for interacting with Connected Systems and associated resources (OGC 20-058). A Connected System represents any kind of system that can either directly transmit data via communication networks (being connected to them in a permanent or temporary fashion), or whose data is made available in one form or another via such networks. This definition encompasses systems of all kinds, including in-situ and remote sensors, actuators, fixed and mobile platforms, airborne and space-borne systems, robots and drones, and even humans who collect data or execute specific tasks.

3.2.2.  OGC API — Maps

The OGC API — Maps candidate Standard describes an API that can serve spatially referenced and dynamically rendered electronic maps (OGC 20-058). The specification describes the discovery and query operations of an API that provides access to electronic maps in a manner independent of the underlying data store. The query operations allow dynamically rendered maps to be retrieved from the underlying data store based upon simple selection criteria as defined by the client.

3.2.3.  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.4.  OGC API — Discrete Global Grid Systems

The OGC API — Discrete Global Grid Systems candidate Standard defines building blocks which can be used as part of a Web API to retrieve geospatial data for a specific area, time and resolution of interest, based on a specific Discrete Global Grid System (DGGS) and indexing scheme (OGC 21-038). The candidate Standard also supports querying of the list of DGGS zones from which data is available.

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-045r1). In particular, the JSON-FG Standard specifies the following extensions to the GeoJSON format:

3.2.6.  DGGS-JSON and DGGS-UBJSON

The DGGS-JSON and DGGS-UBJSON (based on Universal Binary JSON) formats, defined as part of requirement classes for OGC API — DGGS, provide a compact and efficient way to retrieve data quantized to a particular Discrete Global Grid Reference System (DGGRS). By leveraging a shared knowledge of the DGGRS between the client and server (or the producer and consumer in the case of an offline file), the large majority of the payload is simply the data values associated with each sub-zone at a given relative depth of the parent zone for which data is being encoded. A fixed deterministic sub-zone order needs to be defined as part of the DGGRS in order to enable this.

A draft JSON schema for DGGS-JSON is available. See also the first implementation deployed in the GNOSIS Map Server during this code sprint.

3.2.7.  OGC Cartographic Symbology candidate Standard

The OGC Cartographic Symbology candidate Standard (CartoSym) defines a Conceptual Model, a Logical Model and Encodings for describing symbology rules for the portrayal of geographical data (OGC 18-067r4). The targets of this candidate Standard are symbology encodings and cartographic rendering engines. The candidate Standard is modularized into multiple requirements classes, with a minimal core describing an extensible framework, with clear extension points, for defining styles consisting of styling rules selected through expressions and applying symbolizers configured using properties. The candidate Standard defines two encodings for the logical model: one based on JSON which can be readily parsed by JSON parsers, as well as a more expressive encoding better suited for hand-editing inspired from Web Cartographic Styled Sheets (CSS) and related cartographic symbology encodings.

3.3.1.  MapML

3.3.1.2.  Structure

The MapML viewer is a media-like widget that can be controlled with attributes like other forms of media that can be embedded in a web page. The Map content is represented by the layer element and it comes in two flavors, inline and remote, shown in Figure 2 on the left and right respectively. Inline content is interactive and has a Document Object Model (DOM) footprint in the web browser. In contrast, remote content can be identified by the fact that the layer has a source src attribute pointing to a remote web service or OGC API. Remote content is essential to enabling mashups of ad hoc content from around the Web, and would be provided by OGC APIs directly.

Figure 2 — The structure of MapML

Inline content in MapML comes in the form of map-extent, map-feature, map-tile elements, as well as various forms of metadata, and all inline content is encoded according to the HTML syntax parser rules within layer- elements. Remote content is loaded via content fetched from the layer- src attribute, and is encoded in the XHTML namespace, and because XML parsing rules apply, it is naturally more rigid. However because it is XHTML, it can be readily incorporated into HTML pages.

Map extents (map-extent elements) represent templated tiled, feature, or image map content that is repeatedly fetched as needed, based on movement of the map viewer. Map features are of course OGC Simple Features and tiles are either feature- or image-based. Geospatial data can be viewed in a web page as one or more maps on the document canvas in a single or multi page web application, by using the MapML viewer element as many times as needed.

The viewer is conceptually like the video or audio element. It has a set of built-in controls that are exemplified in Figure 3, and they can be turned on or off as a group or individually. The default controls are keyboard accessible and are navigable with Tab and Shift+Tab keys. The default controls are not styleable, so if custom controls are needed, then a developer has to create their own. That is why the controls are toggleable.

Figure 3 — MapML Viewer

3.3.2.  ISO 19157-3 Data Quality Measures Register

Concepts around data quality have evolved over the past 20 or so years with the advent and proliferation of open sourced, non-authoritative data sources. Standards such as ISO 19115 Geospatial Metadata and ISO 19157 Geospatial Data Quality have been used and incorporated into metadata profiles to record the quality of geospatial datasets. One of the grounding concepts within the ISO standards is the universe of discourse which is poorly translated to ground truth or real world. In the early days of ISO concepts of data quality, the universe of discourse was much more simple to determine because the authoritative datasets were routinely ground truthed for accuracy. A salient example of this is aerial photography where flight paths were planned and a ground crew would lay out tie points on the ground to be captured by the imagery. Distances then could be physically measured to create an overall positional accuracy for the image. In the modern world of non-authoritative, crowdsourced or open source data, the universe of discourse concept does not apply in the same way. The data quality model reports on concepts such as:

To facilitate dataset comparisons, there is a need for evaluations and data quality reports (metadata or a quality evaluation report) to be expressed in a comparable way. Furthermore, it is necessary to have a common understanding of the data quality measures that have been used. An example of such common understanding of a standard quality measure is defined in ISO 19157-1:2023 Geographic information — Data quality — Part 1: General requirements (ISO 19157-1:2023). This standard defines the structure of a data quality measure as well as all additional attributes describing a data quality measure — see in Figure 4.

Figure 4 — Structure of a data quality measure as defined in ISO 19157-1:2023

To comply with current best practice for sharing data over the web, these measures have to reside in a machine-actionable data quality measures register. Such a register is currently under development at ISO/TC211 and OGC. ISO 19157-3 Geographic information — Data quality — Part 3: Data quality measures register will be the standard defining the components and content structure of a register for data quality measures, and the registration and maintenance procedure (ISO/AWI 19157-3). All of this is in compliance with ISO 19135 Geographic information — Registration and registration procedures, a governing standard for all ISO/TC211 registers (ISO 19135-1:2015). The measures will be published through the ISO 19157-3 register which will be hosted at OGC, the Registration Authority of ISO 19157-3. OGC will host the ISO 19157-3 register on OGC RAINBOW, a registry of terms and definitions. The full version of the ISO 19157-3 Data Quality measures register is expected to be published together with the ISO 19157-3 standard in early 2026.

3.4.1.  CREAF Miramon

The Centre for Ecological Research and Forestry Applications (CREAF) at the Autonomous University of Barcelona (UAB) deployed an instance of the MiraMon Map Server. The actual instance is available here and provides a single collection with a well known bathymetry dataset called ETopo2 as the single collection. The MiraMon Map Server is a CGI application that runs on IIS and supports several OGC standards including OGC API — Maps, OGC API — Tiles, Web Map Service (WMS), and Web Map Tile Service (WMTS). The CGI is developed in pure C language and available as a free software.

3.4.2.  QGIS

QGIS is a free and open-source cross-platform desktop GIS that supports viewing, editing, and analysis of geospatial data. The QGIS stable release V3.28.6-Firenze, and later versions, has a Time Slider/Controller added to the menu bar. It behaves like a video controller if relevant to the data being displayed. This and later versions also support the OGC API-EDR queries via a plugin.

Release V3.37 and later now supports a Vertical Slider for data and layers that have a vertical extent.

Figure 5 — Screenshot of QGIS Time Controller

Figure 6 — Screenshot of QGIS EDR Plugin menu

3.4.3.  Status of OGCAPI SourceType support in QGIS

QGIS supports adding a Raster or Vector Layer, using an OGC API Source Type. Under the hood, QGIS uses the OGCAPI GDAL driver. During this code sprint, this functionality was tested for different OGC APIs, in order to figure out what is working and to try to understand if the issue is on GDAL or QGIS.

An issue with relative links was identified on GDAL, which was affecting all the APIs. The issue was already fixed and is described here.

The current status (using QGIS version 3.39.0-Master QGIS code revision 399f7df1c7 and GDAL/OGR version 3.10.0dev-126a88523a) is:

Figure 7 — Screenshot an OGCAPI - Maps collection from Gnosis on QGIS

Figure 8 — Screenshot an OGCAPI - Maps collection from pygeoapi on QGIS

Figure 9 — Screenshot an OGCAPI - Tiles (raster) collection on QGIS

Figure 10 — Screenshot an OGCAPI - Coverages collection on QGIS

More details about the setup for testing this functionality can be found on this issue.

3.4.4.  Geonovum JSON Linter

The Geonovum JSON Linter is a validation tool that has been designed to support testing and checking of JSON-encoded files. The tool runs in a web browser and is implemented using NodeJS. The tool is extensible to enable it to validate conformance to different formats, as well as to support the checking of requests and responses from Web APIs.

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

3.4.6.  OSGeo pygeometa

pygeometa provides a lightweight and Pythonic approach for users to easily create geospatial metadata in standards-based formats using simple configuration files called Metadata Control Files (MCF). The software has minimal dependencies (the installation 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).

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

3.4.8.  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.9.  CubeWerx Geospatial Data Server

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

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.10.  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.11.  OpenSensorHub

OpenSensorHub is an open source software product for supporting web-enabled access to a variety of sensor systems (from the simple to the more complex). OpenSensorHub implements the OGC Sensor Web Enablement (SWE) Standards, as well as the OGC SensorThings API. OpenSensorHub also implements the OGC API — Connected Systems candidate Standard.

3.4.12.  OGC TEAM Engine

The Test, Evaluation, And Measurement (TEAM) Engine is a testing facility that executes test suites implemented using the TestNG framework or the OGC Compliance Test Language (CTL). It is typically used to verify specification compliance and is the official test harness of the OGC Compliance & Interoperability Testing & Evaluation (CITE) program. TEAM Engine is able to import Executable Test Suite (ETS) libraries that are implemented using the TestNG and CTL. Each ETS is implemented to execute source code that reflects the test methods specified in the Abstract Test Suite (ATS) that is specified in an associated OGC Standard. For the this code sprint, the TEAM Engine activity focused on implementing an initial ‘alpha’ version of the OGC Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) Part 2: JSON Encoding candidate Standard.

3.4.13.  OGC RAINBOW

OGC RAINBOW is a Web accessible source of information about things (’Concepts’) the OGC defines or that communities ask the OGC to host on their behalf. It applies FAIR principles to the key concepts that underpin interoperability in systems using OGC specifications. It can be accessed at https://www.opengis.net/def and holds definitions for terms defined by OGC processes, along with a range of ‘metamodel’ resources geospatial community uses to describe and interconnect these resources. There are a number of different types of resource (all linked together to support the ‘Findable’ principle of FAIR). In this code sprint, RAINBOW was specifically used in support of discovery and access to Coordinate Reference System (CRS) definitions and the prototype ISO 19157-3 Data Quality Measures Register.

4.1.1.  OGC CoverageJSON

CoverageJSON maintainers participated in the code sprint with a focus on identifying potential avenues for enhancing the CoverageJSON ecosystem. The code sprint offered a useful forum for discussion and experimentation across various working groups. Therefore, where one solution was found to be useful for one standard, there was a high likelihood that the same solution (or a modification of it) could be useful to another.

Some of the potential opportunities for CoverageJSON identified during the code sprint included:

4.1.2.  Training Data Markup Language for Artificial Intelligence

At the time of the code sprint, the Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) Conceptual Model was a fully approved OGC Standard. However, both the JSON and XML encodings of TrainingDML-AI were still candidate Standards. Therefore, several of the code sprint activities involved TrainingDML-AI data encodings. Furthermore, the TrainingDML-AI Standard was the focus of a mentoring session.

Another sprint activity involved configuring a training dataset as a pygeometa metadata control file and generating TrainingDataML-AI metadata from pygeometa. A more detailed description of the pygeometa activities is documented at Clause 4.4.2. This capability potentially makes it possible to conduct Extract-Transform-Load operations between other metadata formats supported by pygeometa and the JSON encoding on TrainingDML.

The feedback provided by sprint participants also enabled the SWG members from Wuhan University (WHU) to fix issues encountered in example files for the candidate Standard. Furthermore, the SWG members also participated in the discussions and supported the implementations by fellow sprint participants, which included:

Figure 11 — Screenshot of the TEAM Engine user interface with TrainingDML test results

4.2.1.  OGC SensorThings API WebSub Extension

One objective of the EU CitiObs project is to provide decision makers with fit-for-purpose information about air quality collected from different base systems. Currently, each system collects data from sensors using proprietary APIs but makes the data available (to project partners) and the CitiObs decision support system via STAplus. STAplus, the OGC SensorThings API PLUS extension defines additional entities in the data model that support the sensor data management for Citizen Science.

When building such a decision support system, two important functional requirements have to be considered:

This section of the Code Sprint Engineering Report introduces the WebSub extension and illustrates the current state of the implementation.

The SensorThings API WebSub Extension candidate Standard is currently in development. The idea of this extension was presented to the OGC membership during the 2024 Delft and Montreal meetings. There seems to be great interest in the functionality of the WebSub Extension which sparked the idea to contribute to the 2024 Code Sprint in London and improve the current prototype.

curl --head https://citiobs.demo.secure-dimensions.de/staplus/v1.1/Observations

HTTP/2 200
server: nginx/1.27.0
date: Mon, 15 Jul 2024 07:35:00 GMT
content-type: application/json;charset=UTF-8
content-length: 0
link: <https://hub.demo.secure-dimensions.de/>; rel="hub"
link: <https://citiobs.demo.secure-dimensions.de/staplus/v1.1/Observations>; rel="self"

curl --location 'https://hub.demo.secure-dimensions.de/' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'hub.mode=subscribe' \
--data-urlencode 'hub.topic=https://citiobs.demo.secure-dimensions.de/staplustest/v1.1/Observations' \
--data-urlencode 'hub.callback=	https://webhook.site/e40fa5de-239b-4dd6-a0dd-25e50f805d4e' \
--data-urlencode 'hub.secret=this is a good secret :)' \
--data-urlencode 'hub.callback.x_api_key=this is a good key :)'

let client = redis.createClient();
let key = md5(topic);
let value = JSON.stringify({'url': 'https://webhook.site/e40fa5de-239b-4dd6-a0dd-25e50f805d4e'})
client.set( key, value, function(err, result) {
    if (err) throw err; // do something here...

    result is 'OK'
});

let client = redis.createClient();

mqtt_client.on('message', function (topic, message, packet) {
    let key = md5(topic);
    callbacks = client.get(key);
    callbacks.foreach(callback) {
        url = JSON.parse(callback).url;
        request.post(
            'http://www.yoursite.com/formpage',
            { json: message },
            function (error, response, body) {
                ...
            }
        );
    }
}

if ('GET' == get('request.method')) {

    mode = get('request.query.hub_mode', null)
    topic = get('request.query.hub_topic', null)
    challenge = get('request.query.hub_challenge', null)
    lease_seconds = get('request.query.hub_lease_seconds', null)


    if (mode == null) {
		respond('hub.mode required', 400, ['Content-Type: text/plain'])
		return
    }
    if (topic == null) {
		respond('hub.topic required', 400, ['Content-Type: text/plain'])
		return
	}
	if (challenge == null) {
		respond('hub.challenge required', 400, ['Content-Type: text/plain'])
		return
	}

	console.log('topic: ' + topic)
	console.log('hub.topic: ' + get('hub.topic'))

	if (mode == 'unsubscribe') {
	    if (topic == get('hub.topic')) {
    	    respond(challenge, 200, ['Content-Type: text/plain'])
    	    return
	    } else {
	        respond('hub.topic unknown', 404, ['Content-Type: text/plain'])
            return
        }
	}

	if (mode == 'subscribe') {
	    if (lease_seconds == null) {
		    respond('hub.lease_seconds required', 400, ['Content-Type: text/plain'])
	    	return
    	}

	    if (topic == get('hub.topic')) {
    	    respond(challenge, 200, ['Content-Type: text/plain'])
    	    return
	    } else {
	        respond('hub.topic unknown', 404, ['Content-Type: text/plain'])
            return
        }
	}
}

$request.header.x-api-key$ 'is equal to' $hub.secret

crypto = require("crypto");

method = get('request.method')
secret = get('hub.secret')

if ('POST == method') {

    x_hub_signature = get('request.header.x-hub-signature', null)
    if (x_hub_signature == null) {
        respond('HTTP header x-hub-signature is required', 400, ['Content-Type: text/plain'])
        return
    }
    console.log("X-Hub-Signature: " + x_hub_signature)

    signature = x_hub_signature.split('=');
    if (signature.length != 2) {
        console.log("X-Hub-Signature has wrong format: " + x_hub_signature);
        console.log("Not sending message to client");
        respond('', 204, ['Content-Type: text/plain'])
        return
    }
    alg = signature[0];
    console.log("signature algorithm: " + alg)
    value = signature[1];
    console.log("signature value: " + value)

    data = get('request.content')
    hmac = crypto.createHmac(alg, secret).update(data).digest("hex");
    console.log("HMAC value computed from request: " + hmac)

    if (hmac !== value) {
        console.log("X-Hub-Signature validation failed. Not sending message to client");
        respond('', 204, ['Content-Type: text/plain'])
        return
    }

    console.log("processing data")
    respond('', 204, ['Content-Type: text/plain'])
}

const amqp = require("amqplib");
(async () => {
	try {
	  	var connection = await amqp.connect("amqp://localhost");
		var channel = await connection.createChannel();
		await channel.assertQueue("websub", {durable: false});
	}
	catch (err) {
		console.warn(err);
	}
})();

channel.sendToQueue("websub", Buffer.from(JSON.stringify(body)),
						{
							appId: callback,
							contentType: 'application/json',
							headers: headers,
							correlationId: secret
						});

const amqp = require("amqplib");
const request = require('request');
const crypto = require('crypto');
const log = require('loglevel');

log.setLevel(process.env.LOG_LEVEL || log.levels.DEBUG);

(async () => {
  try {
    const connection = await amqp.connect("amqp://localhost");
    const channel = await connection.createChannel();

    process.once("SIG---", async () => {
      await channel.close();
      await connection.close();
    });

    await channel.consume(
      "websub",
      (message) => {
        if (message) {
            let body = JSON.parse(message.content);
            let headers = message.properties.headers;
            let content_type = message.properties.contentType;
            let secret = message.properties.correlationId;
            let callback = message.properties.appId;
            log.debug(" [x] Received '%s'", body);
            log.debug(" [x] Headers '%s'", JSON.stringify(headers));
            log.debug(" [x] Content-Type '%s'", content_type);
            log.debug(" [x] secret '%s'", secret);
            log.debug(" [x] callback '%s'", callback);

            if (secret !== null) {
                log.debug("message: " + body);
                log.debug("secret: " + secret);
                var hmac = crypto.createHmac("sha256", secret).update(body).digest("hex");
                log.debug("hmac: " + hmac);
                headers['X-Hub-Signature'] = 'sha256=' + hmac;
            }

            request.post({
                headers: headers,
                url: callback,
                body: body
            }, function (error, response, body) {
                log.info("message sent with HMAC: " + hmac);
                if (error) {
                    log.debug(error);
                }
            });
        }
      },
      { noAck: true }
    );

    console.log(" [*] Waiting for messages. To exit press CTRL+C");
  } catch (err) {
    console.warn(err);
  }
})();

4.2.2.  OGC API — Records

Experimentation related to OGC API — Records included extension of pygeoapi to enable support for TrainingDataML-AI. A detailed summary is presented in Clause 4.4.1. The prototype potentially could lead to a TrainingDataML-AI profile of the Record Core model specified in OGC API — Records — Part 1: Core. The pygeoapi implementation mapped the common metadata constructs into the Record Core model, and encoded TrainingDataML-AI specifics accordingly.

4.2.3.  OGC Styles and Symbology

During this code sprint, the sprint participants worked on drafting the OGC Styles & Symbology candidate standard. The work included:

A number of GitHub issues were created as a result of this work. This included:

4.3.1.  MapML

Several participants worked on this MapML track.

4.3.1.1.  pygeoapi

Pygeoapi was used as the base for a prototype web application that is able to serve MapML remote content.

The original goal was to add MapML support by leveraging pygeoapi’s plugin framework. However, after inspection of the code this proved to not be possible — proper integration of MapML would require modifications to the core pygeoapi code, something which was deemed out of scope for the code sprint. As such, development efforts consisted of developing a thin wrapper around pygeoapi which would add the relevant bits of MapML-related code while still keeping pygeoapi as the main agent. This approach worked out well.

The prototype thus consisted of two-components:

• A pygeoapi plugin that defined a tile-based data provider which knew how to respond to requests with the Accept:text/mapml header

• A small middleware for pygeoapi’s Flask application which intercepted relevant requests and performed post-processing of the pygeoapi response in order to add support for MapML

In order to test the results, a simple web-based client was also implemented as a separate application. This web client featured the <mapml-viewer> element and configured remote layers that were being fetched from our prototype.

4.3.1.1.1.  pygeoapi MapML tile provider plugin

Taking advantage of pygeoapi’s extensibility the existing tile provider was subclassed in order to add support for responding with a MapML document to requests for tileset metadata. In the context of the code sprint, support was restricted to the WebMercatorQuad tileset. A sample request would be:

GET /collections/{collection-id}/tiles/WebMercatorQuad "Accept:text/mapml"

Listing 1 — Request

The custom tile provider was implemented as to recognize the MapML media type being requested in the request’s Accept header and to generate a suitable MapML document as the response. This allowed the pygeoapi-based prototype to serve as a server for OGC API Tiles, which generic clients would be able to use for requesting MapML data. The server thus generated a response like:

<mapml- xmlns="http://www.w3.org/1999/xhtml">
<map-head>
<map-title>Prevalence rates of mental health issues in London</map-title>
<map-meta http-equiv="Content-Type" content="text/mapml;projection=OSMTILE"></map-meta>
<map-meta charset="utf-8"></map-meta>
<map-meta name="extent" content="top-left-easting=-29028.26648413821, top-left-northing=6694074.574114459, bottom-right-easting=14106.427797324195, bottom-right-northing=6724542.93687513"></map-meta>
<map-link rel="license" href="" title=""></map-link>
</map-head>
<map-body>
<map-extent units="OSMTILE" checked="checked">
<map-input name="tileMatrix" type="zoom" value="0" min="0" max="18"></map-input>
<map-input name="tileCol" type="location" units="tilematrix" axis="column"></map-input>
<map-input name="tileRow" type="location" units="tilematrix" axis="row"></map-input>
<map-link rel="tile" tref="http://localhost:5000/collections/grid_mental/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=png"></map-link>
</map-extent>
</map-body>
</mapml->

Listing 2 — pygeoapi-based prototype response to tile metadata request

4.3.1.1.2.  pygeoapi wrapper code

The pygeoapi wrapper code, which was implemented as a Flask after_request() callback, dealt with adding support for the text/mapml media type for some endpoints and mostly with converting features encoded in GeoJSON to their respective MapML representations, thus making it possible to have support for remote MapML features.

http /collections/{collection-id}/items "Accept:text/mapml" limit==1

Listing 3 — Example request for features using the mapml media-type

With the prototype pygeoapi-based application generating the following response:

<mapml- xmlns="http://www.w3.org/1999/xhtml">
    <map-head>
        <map-title>Observations</map-title>
        <map-meta name="projection" content="OSMTILE"></map-meta>
        <map-meta http-equiv="Content-Type" content="text/mapml;projection=OSMTILE"></map-meta>
        <map-meta charset="utf-8"></map-meta>
        <map-meta name="cs" content="gcrs"></map-meta>
        <map-meta name="extent" content="top-left-longitude=-122, top-left-latitude=49, bottom-right-longitude=-75, bottom-right-latitude=43"></map-meta>
        <map-link rel="license" href="" title=""></map-link>
    </map-head>
    <map-body><map-feature>
            <map-properties>
                <table>
                    <tbody><tr>
                            <td>stn_id</td>
                            <td>35</td>
                        </tr><tr>
                            <td>datetime</td>
                            <td>2001-10-30T14:24:55Z</td>
                        </tr><tr>
                            <td>value</td>
                            <td>89.9</td>
                        </tr></tbody>
                </table>
            </map-properties>
            <map-geometry><map-point><map-coordinates>-75.00000000 45.00000000</map-coordinates></map-point></map-geometry>
        </map-feature></map-body>
</mapml->

Listing 4 — Response

4.3.1.1.3.  Simple MapML web client

In order to test how the pygeoapi-based prototype worked as a server of remote MapML data, a small web client was implemented, making use of the @maps4html/web-map-custom-element javascript library, which emulates support for MapML in the browser.

The client asked for a couple of remote layers, being served by the pygeoapi-based prototype application. One of these remote layers served image tiles, while the other served MapML features.

<mapml-viewer projection="OSMTILE" zoom="1" lat="0.0" lon="0.0" controls>
            <layer- label="OpenStreetMap" checked>
                <map-extent units="OSMTILE" checked>
                    <map-input name="z" type="zoom"  value="18" min="0" max="18"></map-input>
                    <map-input name="x" type="location" units="tilematrix" axis="column" min="0"  max="262144" ></map-input>
                    <map-input name="y" type="location" units="tilematrix" axis="row" min="0"  max="262144" ></map-input>
                    <map-link rel="tile" tref="https://a.tile.openstreetmap.org/{z}/{x}/{y}.png" ></map-link>
                </map-extent>
            </layer->
            <layer-
                    label="grid mental from pygeoapi"
                    src="https://da08-167-98-97-210.ngrok-free.app/collections/grid_mental/tiles/WebMercatorQuad"
                    checked
            ></layer->
            <layer-
                    label="obs from pygeoapi"
                    src="https://da08-167-98-97-210.ngrok-free.app/collections/obs/items"
                    checked
            ></layer->
        </mapml-viewer>

Listing 5 — Simple web based client for testing the MapML remote content being served by the pygeoapi-based prototype

Below is a sample image demonstrating the operation of this simple web client.

Figure 12 — Simple web client displaying a layer fetched from the remote pygeoapi-based prototype.

4.3.1.2.  CREAF Miramon

UAB-CREAF participated in the sprint by contributing their MiraMon Map Server. This application was adapted to OGC API Maps and Tiles during previous sprints. The OGC API Maps allow for requesting a map of a collection. If the request is done to this endpoint /collections/{collectionId}/map with no parameters, the server is free to respond with a “nice” map that represents the collection or a representative area of it. If the negotiated media type is static, the selection of the area is particularly important. In the case of MapML, the map is interactive, giving freedom to the user to correct the server decision by panning and zooming. In this particular sprint, two modifications were introduced in the MiraMon Map Server to include MapML support.

• A request to a /collections/{collectionId}/map with no extra parameters that negotiates HTML and results in the creation of an HTML page that includes some metadata about the collection and a MapML section to show the interactive map. This web page can be visualized in the map browser with the help of MapML common JavaScript libraries.

• A request to a /collections/{collectionId}/map with no extra parameters that negotiates MapML, and results in a MapML document that can be visualized in Chrome if an specific add-in has been previously setup.

Figure 13 — Contiguous tiles from different services and APIs sharing same WebMercatorQuad tile matrix set and the tile matrix identified as 15 (sometimes called "zoom")

Figure 14 — Contiguous tiles from different services and APIs sharing same WebMercatorQuad tile matrix set and the tile matrix identified as 15 (sometimes called "zoom")

In both cases the MiraMon Map Server implementing OGC API — Maps is used twice:

• It produces the initial response to the “minimalistic” map request (with no parameters) asking for the HTML or MapML representation of the collection.

• The MapML content uses the URL template mechanism to get an image map (in this case a PNG) of the current view and the subsequent views that the user will generate by panning and zooming into the map.

The following code is common to both MapML responses (HTML or MapML versions). Please note that the OGC API — Maps is used to generate the PNGs maps. The HTML element map-link contains a link to a URL template that once “resolved” with the right map-input values become a call that conforms to the OGC API maps. This demonstrates that the current specification of MapML can use the new OGC API Maps with no modification.

  <map-extent units="WGS84" label="etopo2" checked="checked">
    <map-input name="z" type="zoom" min="1" max="15"></map-input>
		<map-input name="w" type="width"></map-input>
		<map-input name="h" type="height"></map-input>
		<map-input name="xmin" type="location" units="pcrs" position="top-left" axis="easting" ></map-input>
		<map-input name="ymin" type="location" units="pcrs" position="bottom-left" axis="northing" ></map-input>
		<map-input name="xmax" type="location" units="pcrs" position="top-right" axis="easting" ></map-input>
		<map-input name="ymax" type="location" units="pcrs" position="top-left" axis="northing" ></map-input>
		<map-link rel="image" tref="https://www.ogc3.grumets.cat/cgi-bin/world/miramon.cgi/collections/etopo2/map?crs=http://www.opengis.net/def/crs/OGC/1.3/CRS84&amp;bbox-crs=http://www.opengis.net/def/crs/OGC/1.3/CRS84&amp;bbox={xmin},{ymin},{xmax},{ymax}&amp;width={w}&amp;height={h}&amp;f=PNG&amp;transparent=true"></map-link>
  </map-extent>

Listing 6

In case the API implementation supports MapML, it is convenient that the collection description page advertises a link to the map. The following figure illustrates how this looks like in the HTML representation of the response.

Figure 15 — Contiguous tiles from different services and APIs sharing same WebMercatorQuad tile matrix set and the tile matrix identified as 15 (sometimes called "zoom")

4.3.1.3.  GNOSIS Map Server

The official MapML client was tested with outputs from OGC API endpoints of the GNOSIS Map Server for multiple access mechanisms: OGC API — Maps, OGC API — Features and OGC API — Tiles (for both map tiles and vector tiles).

An HTML page was set up to demonstrate these capabilities, where the user can toggle the visibility of a map, map tiles, vector features and vector tiles.

For the features and vector tiles experiments, the client accessed a MapML representation of the vector tiles and features, including their geometry, which was previously implemented in the GNOSIS Map Server for OGC Testbed 15.

Figure 16 — Maps and features being accessed from the GNOSIS Map Server implementation of OGC API - Maps and OGC API - Features in the MapML client

Figure 17 — Vector tiles and map tiles being accessed from the GNOSIS Map Server implementation of OGC API - Tiles in the MapML client

Some rendering issues were noticed in the client with the vector features and vector tiles, with the vector tiles issues more significant. This is possibly caused by invalid geometry generated by the server, issues on the client side, or a combination of both. These issues should be investigated further and addressed.

Figure 18 — Visual artifacts visualizing vector tiles from the GNOSIS Map Server implementation of OGC API - Tiles in the MapML client

Figure 19 — Visual artifacts visualizing features from the GNOSIS Map Server implementation of OGC API - Features in the MapML client

A future version of the GNOSIS Map Server could support a MapML representation of the /map endpoint which automatically set up the MapML elements for the different layers available at that end-point. This representation would need to choose between the different possible access mechanisms, or offer all of them while only making one visible by default, allowing the user to access the same data in different ways.

4.3.2.  ISO 19157-3 Data Quality Measures Register

A current version of the ISO 19157-3 register that is available through OGC RAINBOW contains an initial set of more than 80 recognized standard data quality measures (e.g. such as the Root Mean Square Error used for evaluation positional accuracy, or the Misclassification Matrix used to evaluate the attribute accuracy). A screenshot of the register is shown in Figure 20. The data quality measures were used in the first few tests as part of the Code Sprint.

Figure 20 — A screenshot of the data quality measures register display on OGC RAINBOW

As one of the major focuses of the code sprint was the use, testing, and enhancement of data quality documentation in AI applications, the JSON encoding of the Training Data Markup Language for AI (TrainingDML-AI) Standard was used as the target for testing the potential use of the ISO 19157-3 data quality measures register in the context of AI. The example dataset is a simple, reduced and modified version of the dataset link. This is shown below:

{
    "type": "DataQuality",
    "scope": {
      "level": "dataset",
      "levelDescription": [
        {
          "dataset": "main.bld_fts_building"
        }
      ]
    },
    "report": [
      {
        "type": "PositionalAccuracy",
        "measure": {
            "measureIdentification": {
                "code": "FT28_2",
                "authority": "https://defs-dev.opengis.net/vocprez-hosted/object?uri=https%3A//standards.isotc211.org/19157/-3/1/dqc/content/formulaType/"
            },
            "nameOfMeasure": [
                "Absolute Value of mean error to the standard deviation",
                "Horizontal"
            ],
            "measureDescription": "Calculates the mean error of the standard deviation"
        },
        "evaluationMethod": {
          "evaluationMethodDescription": "Uses the standard mathematical formula"
        },
        "result": [
          {
            "quantitativeResult": {
              "value": [
                0.75643
              ],
              "valueUnit": "real"
            }
          }
        ]
      }
    ]
}

Listing 7

The test dataset contains the PositionalAccuracy element which implements the measureIdentification element that in turn includes the reference to the authority and a code that corresponds to the data quality formula expressed in MathML. The measureIdentification element in the listing above references a data quality measure that is defined through a mathematical formula. The URI reference leads to a page as shown in Figure 21 when displayed in a web browser.

Figure 21 — A screenshot of a mathematical formular from the data quality measures register

One of the objectives of the software developed in this part of the code sprint was to parse the MathML to make it machine readable, machine executable, and parsable. The output was successful to a point of making the formula machine readable, but it was not possible to inject new variables into the formula to execute the chain for another dataset.

4.4.1.  OSGeo pygeoapi

4.4.1.1.  Mentor stream: Adding a new OGC API to pygeoapi

Given recent updates to pygeoapi in support of API implementation modularity, a mentor stream was given, focusing on adding a new OGC API to pygeoapi. Developers were shown how to add and hook new API functionality / endpoints into the pygeoapi core, as well as exposing via pygeoapi’s OpenAPI functionality. A presentation and example application were demonstrated and made available as proof of concept.

Figure 22

4.4.1.1.1.  OGC API — Processes — Part 2 implementation

An initial prototype was implemented to support the OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft standard. Process creation was implemented by way of ingesting a Common Workflow Language (CWL) definition which referenced a Python application made available as a Docker image. The Python application implemented water body detection, which took as input Copernicus Sentinel-2 or USSG Landsat-9 data and detected water bodies by applying the Otsu thresholding technique on the Normalized Difference Water Index (NDWI)¹. This application was made available as an example in support of the OGC Best Practice for Earth Observation Application Package.

Figure 23

The CWL was published and made available as an OGC API Process. The process description included an executionUnit object providing the CWL definition.

Process execution then invoked the cwltool reference implementation to deploy and run the application in a portable manner, producing a manifest of a STAC Catalog of the NDWI outputs.

Figure 24

The architecture of the implementation can be found below, and the associated implementation on GitHub. Future work includes ‘process replace’ and ‘process delete’ functionality, as well as describing CWL inputs and outputs as part of the native process description model.

Figure 25

Special thanks is given to the Earth Observation Application Package resources and examples provided on GitHub as well as Gérald Fenoy of GeoLabs SARL for providing valuable explanation, advice and recommendation.

4.4.2.  OSGeo pygeometa

Upon participating in the special track and breakout session focused on Data Quality and Artificial Intelligence, an initial Training Data Markup Language for AI (TrainingDML-AI) encoder was implemented in pygeometa. This enabled configuring a training dataset as a pygeometa metadata control file (MCF) configuration and generating TrainingDataML-AI (or any other metadata format supported by pygeometa). Note that the MCF model was extended to support specifics of TrainingDataML-AI.

The initial exercise illustrated a number of intersections between TrainingDataML-AI and common metadata constructs (spatiotemporal extents, keywords, contacts, data quality, etc.) in support of discovery and documentation. As a result, an additional implementation was put forth to create a TrainingDataML-AI profile of the OGC API — Records — Part 1: Core, Record Core model. This implementation mapped the common metadata constructs into the Record Core model, and encoded TrainingDataML-AI specifics accordingly.

The result of this experiment was the encoding of a training dataset description as a metadata record that could then enable low barrier, broad interoperability via GeoJSON and OGC API — Records.

Figure 26

The resulting implementation can be found on GitHub.

4.4.3.  CubeWerx Geospatial Data Server

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf/schema",
  "type": "object",
  "title": "No Title Specified",
  "description": "No description provided.",
  "properties": {
    "cw_fid": {
      "readOnly": true,
      "x-ogc-role": "id",
      "type": "string",
      "format": "uuid",
      "x-ogc-propertySeq": 1
    },
    "geometry": {
      "format": "geometry-polygon",
      "x-ogc-role": "primary-geometry",
      "x-ogc-propertySeq": 2
    },
    "AOO": {
      "type": "number",
      "x-ogc-propertySeq": 3
    },
    "ARA": {
      "type": "number",
      "x-ogc-propertySeq": 4
    },
    "BAC": {
      "type": "integer",
      "x-ogc-propertySeq": 5
    },
    "BEN": {
      "type": "string",
      "x-ogc-propertySeq": 6
    },
    "CAA": {
      "type": "integer",
      "x-ogc-propertySeq": 7
    },
    "CCN": {
      "type": "string",
      "x-ogc-propertySeq": 8
    },
    "CDR": {
      "type": "string",
      "x-ogc-propertySeq": 9
    },
    "FFN": {
      "type": "integer",
      "x-ogc-propertySeq": 10
    },
    "FFN2": {
      "type": "integer",
      "x-ogc-propertySeq": 11
    },
    "FFN3": {
      "type": "integer",
      "x-ogc-propertySeq": 12
    },
    "F_CODE": {
      "type": "string",
      "x-ogc-propertySeq": 13
    },
    "HGT": {
      "type": "number",
      "x-ogc-propertySeq": 14
    },
    "LZN": {
      "type": "number",
      "x-ogc-propertySeq": 15
    },
    "OTH": {
      "type": "string",
      "x-ogc-propertySeq": 16
    },
    "PCF": {
      "type": "integer",
      "x-ogc-propertySeq": 17
    },
    "SAX_RS1": {
      "type": "string",
      "x-ogc-propertySeq": 18
    },
    "SAX_RS2": {
      "type": "string",
      "x-ogc-propertySeq": 19
    },
    "SAX_RS3": {
      "type": "string",
      "x-ogc-propertySeq": 20
    },
    "SAX_RS4": {
      "type": "string",
      "x-ogc-propertySeq": 21
    },
    "SAX_RS5": {
      "type": "string",
      "x-ogc-propertySeq": 22
    },
    "SAX_RS6": {
      "type": "string",
      "x-ogc-propertySeq": 23
    },
    "SAX_RS8": {
      "type": "string",
      "x-ogc-propertySeq": 24
    },
    "SAX_RS9": {
      "type": "string",
      "x-ogc-propertySeq": 25
    },
    "SAX_RX1": {
      "type": "string",
      "x-ogc-propertySeq": 26
    },
    "SAX_RX2": {
      "type": "string",
      "x-ogc-propertySeq": 27
    },
    "SAX_RX5": {
      "type": "string",
      "x-ogc-propertySeq": 28
    },
    "SAX_RX6": {
      "type": "string",
      "x-ogc-propertySeq": 29
    },
    "SAX_RX7": {
      "type": "string",
      "x-ogc-propertySeq": 30
    },
    "SAX_RX8": {
      "type": "string",
      "x-ogc-propertySeq": 31
    },
    "SAX_RX9": {
      "type": "string",
      "x-ogc-propertySeq": 32
    },
    "SAX_RY0": {
      "type": "string",
      "x-ogc-propertySeq": 33
    },
    "SAX_RY1": {
      "type": "string",
      "x-ogc-propertySeq": 34
    },
    "SAX_RY2": {
      "type": "string",
      "x-ogc-propertySeq": 35
    },
    "UFI": {
      "type": "string",
      "x-ogc-propertySeq": 36
    },
    "WID": {
      "type": "number",
      "x-ogc-propertySeq": 37
    },
    "WPI": {
      "type": "string",
      "x-ogc-propertySeq": 38
    },
    "ZI001_SDP": {
      "type": "string",
      "x-ogc-propertySeq": 39
    },
    "ZI001_SDV": {
      "type": "string",
      "x-ogc-propertySeq": 40
    },
    "ZI001_SPS": {
      "type": "integer",
      "x-ogc-propertySeq": 41
    },
    "ZI001_SRT": {
      "type": "string",
      "x-ogc-propertySeq": 42
    },
    "ZI001_VSC": {
      "type": "string",
      "x-ogc-propertySeq": 43
    },
    "ZI001_VSD": {
      "type": "string",
      "x-ogc-propertySeq": 44
    },
    "ZI001_VSN": {
      "type": "string",
      "x-ogc-propertySeq": 45
    },
    "ZI004_RCG": {
      "type": "string",
      "x-ogc-propertySeq": 46
    },
    "ZI005_FNA": {
      "type": "string",
      "x-ogc-propertySeq": 47
    },
    "ZI005_FNA2": {
      "type": "string",
      "x-ogc-propertySeq": 48
    },
    "ZI005_NFN": {
      "type": "string",
      "x-ogc-propertySeq": 49
    },
    "ZI005_NFN2": {
      "type": "string",
      "x-ogc-propertySeq": 50
    },
    "ZI006_MEM": {
      "type": "string",
      "x-ogc-propertySeq": 51
    },
    "ZI020_GE4": {
      "type": "string",
      "x-ogc-propertySeq": 52
    },
    "ZI026_CTUC": {
      "type": "integer",
      "x-ogc-propertySeq": 53
    },
    "ZI026_CTUL": {
      "type": "integer",
      "x-ogc-propertySeq": 54
    },
    "ZI026_CTUU": {
      "type": "integer",
      "x-ogc-propertySeq": 55
    },
    "ZSAX_RS0": {
      "type": "string",
      "x-ogc-propertySeq": 56
    },
    "ZSAX_RX0": {
      "type": "string",
      "x-ogc-propertySeq": 57
    },
    "ZSAX_RX3": {
      "type": "string",
      "x-ogc-propertySeq": 58
    },
    "ZSAX_RX4": {
      "type": "string",
      "x-ogc-propertySeq": 59
    },
    "ZVH": {
      "type": "number",
      "x-ogc-propertySeq": 60
    },
    "FCSUBTYPE": {
      "type": "integer",
      "x-ogc-propertySeq": 61
    },
    "ADR": {
      "type": "string",
      "x-ogc-propertySeq": 62
    },
    "LMC": {
      "type": "integer",
      "x-ogc-propertySeq": 63
    },
    "STL": {
      "type": "integer",
      "x-ogc-propertySeq": 64
    },
    "STL2": {
      "type": "integer",
      "x-ogc-propertySeq": 65
    },
    "STL3": {
      "type": "integer",
      "x-ogc-propertySeq": 66
    },
    "HHD": {
      "type": "integer",
      "x-ogc-propertySeq": 67
    }
  },
  "additionalProperties": false
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/schemas/collection",
  "$defs": {
    "bbox": {
      "type": "array",
      "minItems": 4,
      "items": {
        "type": "number"
      }
    },
    "link": {
      "type": "object",
      "required": [
        "href"
      ],
      "properties": {
        "href": {
          "type": "string",
          "format": "uri"
        },
        "rel": {
          "type": "string"
        },
        "type": {
          "type": "string"
        },
        "title": {
          "type": "string"
        }
      }
    },
    "Point": {
      "title": "GeoJSON Point",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "Point"
          ]
        },
        "coordinates": {
          "type": "array",
          "minItems": 2,
          "items": {
            "type": "number"
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "LineString": {
      "title": "GeoJSON LineString",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "LineString"
          ]
        },
        "coordinates": {
          "type": "array",
          "minItems": 2,
          "items": {
            "type": "array",
            "minItems": 2,
            "items": {
              "type": "number"
            }
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "Polygon": {
      "title": "GeoJSON Polygon",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "Polygon"
          ]
        },
        "coordinates": {
          "type": "array",
          "minItems": 4,
          "items": {
            "type": "array",
            "minItems": 2,
            "items": {
              "type": "number"
            }
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "MultiPoint": {
      "title": "GeoJSON MultiPoint",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "MultiPoint"
          ]
        },
        "coordinates": {
          "type": "array",
          "items": {
            "type": "array",
            "minItems": 2,
            "items": {
              "type": "number"
            }
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "MultiLineString": {
      "title": "GeoJSON MultiLineString",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "MultiLineString"
          ]
        },
        "coordinates": {
          "type": "array",
          "items": {
            "type": "array",
            "minItems": 2,
            "items": {
              "type": "array",
              "minItems": 2,
              "items": {
                "type": "number"
              }
            }
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "MultiPolygon": {
      "title": "GeoJSON MultiPolygon",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "MultiPolygon"
          ]
        },
        "coordinates": {
          "type": "array",
          "items": {
            "type": "array",
            "items": {
              "type": "array",
              "minItems": 4,
              "items": {
                "type": "array",
                "minItems": 2,
                "items": {
                  "type": "number"
                }
              }
            }
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "GeometryCollection": {
      "title": "GeoJSON Geometry Collection",
      "type": "object",
      "required": [
        "type",
        "geometries"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "GeometryCollection"
          ]
        },
        "geometries": {
          "type": "array",
          "items": {
            "oneOf": [
              {
                "type": "null"
              },
              {
                "$ref": "#/$defs/Point"
              },
              {
                "$ref": "#/$defs/MultiPoint"
              },
              {
                "$ref": "#/$defs/LineString"
              },
              {
                "$ref": "#/$defs/MultiLineString"
              },
              {
                "$ref": "#/$defs/Polygon"
              },
              {
                "$ref": "#/$defs/MultiPolygon"
              }
            ]
          }
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        }
      }
    },
    "SettlementSrf": {
      "featureType": "SettlementSrf",
      "type": "object",
      "required": [
        "type",
        "geometry",
        "properties"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "Feature"
          ]
        },
        "id": {
          "type": "string"
        },
        "bbox": {
          "$ref": "#/$defs/bbox"
        },
        "geometry": {
          "$ref": "#/$defs/Polygon"
        },
        "properties": {
          "oneOf": [
            {
              "type": "null"
            },
            {
              "type": "object",
              "required": [
              ],
              "properties": {
                "AOO": {
                  "type": "number"
                },
                "ARA": {
                  "type": "number"
                },
                "BAC": {
                  "type": "integer"
                },
                "BEN": {
                  "type": "string"
                },
                "CAA": {
                  "type": "integer"
                },
                "CCN": {
                  "type": "string"
                },
                "CDR": {
                  "type": "string"
                },
                "FFN": {
                  "type": "integer"
                },
                "FFN2": {
                  "type": "integer"
                },
                "FFN3": {
                  "type": "integer"
                },
                "F_CODE": {
                  "type": "string"
                },
                "HGT": {
                  "type": "number"
                },
                "LZN": {
                  "type": "number"
                },
                "OTH": {
                  "type": "string"
                },
                "PCF": {
                  "type": "integer"
                },
                "SAX_RS1": {
                  "type": "string"
                },
                "SAX_RS2": {
                  "type": "string"
                },
                "SAX_RS3": {
                  "type": "string"
                },
                "SAX_RS4": {
                  "type": "string"
                },
                "SAX_RS5": {
                  "type": "string"
                },
                "SAX_RS6": {
                  "type": "string"
                },
                "SAX_RS8": {
                  "type": "string"
                },
                "SAX_RS9": {
                  "type": "string"
                },
                "SAX_RX1": {
                  "type": "string"
                },
                "SAX_RX2": {
                  "type": "string"
                },
                "SAX_RX5": {
                  "type": "string"
                },
                "SAX_RX6": {
                  "type": "string"
                },
                "SAX_RX7": {
                  "type": "string"
                },
                "SAX_RX8": {
                  "type": "string"
                },
                "SAX_RX9": {
                  "type": "string"
                },
                "SAX_RY0": {
                  "type": "string"
                },
                "SAX_RY1": {
                  "type": "string"
                },
                "SAX_RY2": {
                  "type": "string"
                },
                "UFI": {
                  "type": "string"
                },
                "WID": {
                  "type": "number"
                },
                "WPI": {
                  "type": "string"
                },
                "ZI001_SDP": {
                  "type": "string"
                },
                "ZI001_SDV": {
                  "type": "string"
                },
                "ZI001_SPS": {
                  "type": "integer"
                },
                "ZI001_SRT": {
                  "type": "string"
                },
                "ZI001_VSC": {
                  "type": "string"
                },
                "ZI001_VSD": {
                  "type": "string"
                },
                "ZI001_VSN": {
                  "type": "string"
                },
                "ZI004_RCG": {
                  "type": "string"
                },
                "ZI005_FNA": {
                  "type": "string"
                },
                "ZI005_FNA2": {
                  "type": "string"
                },
                "ZI005_NFN": {
                  "type": "string"
                },
                "ZI005_NFN2": {
                  "type": "string"
                },
                "ZI006_MEM": {
                  "type": "string"
                },
                "ZI020_GE4": {
                  "type": "string"
                },
                "ZI026_CTUC": {
                  "type": "integer"
                },
                "ZI026_CTUL": {
                  "type": "integer"
                },
                "ZI026_CTUU": {
                  "type": "integer"
                },
                "ZSAX_RS0": {
                  "type": "string"
                },
                "ZSAX_RX0": {
                  "type": "string"
                },
                "ZSAX_RX3": {
                  "type": "string"
                },
                "ZSAX_RX4": {
                  "type": "string"
                },
                "ZVH": {
                  "type": "number"
                },
                "FCSUBTYPE": {
                  "type": "integer"
                },
                "ADR": {
                  "type": "string"
                },
                "LMC": {
                  "type": "integer"
                },
                "STL": {
                  "type": "integer"
                },
                "STL2": {
                  "type": "integer"
                },
                "STL3": {
                  "type": "integer"
                },
                "HHD": {
                  "type": "integer"
                }
              },
              "additionalProperties": false
            }
          ]
        },
        "links": {
          "type": "array",
          "items": {
            "type": "object",
            "required": [
              "href"
            ],
            "properties": {
              "href": {
                "type": "string",
                "format": "uri"
              },
              "rel": {
                "type": "string"
              },
              "type": {
                "type": "string"
              },
              "title": {
                "type": "string"
              }
            }
          }
        }
      }
    }
  },
  "title": "GeoJSON Feat Collection",
  "type": "object",
  "required": [
    "type",
    "features"
  ],
  "properties": {
    "type": {
      "type": "string",
      "enum": [
        "FeatureCollection"
      ]
    },
    "features": {
      "type": "array",
      "items": {
        "oneOf": [
          {
            "$ref": "#/$defs/SettlementSrf"
          }
        ]
      }
    },
    "bbox": {
      "type": "array",
      "minItems": 4,
      "items": {
        "type": "number"
      }
    }
  }
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf/schema",
  "type": "object",
  "required": [
    "type",
    "geometry",
    "properties"
  ],
  "properties": {
    "type": {
      "type": "string",
      "enum": [
        "Feature"
      ]
    },
    "id": {
      "type": "string"
    },
    "bbox": {
      "type": "array",
      "minItems": 4,
      "items": {
        "type": "number"
      }
    },
    "geometry": {
      "title": "GeoJSON Polygon",
      "type": "object",
      "required": [
        "type",
        "coordinates"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "Polygon"
          ]
        },
        "coordinates": {
          "type": "array",
          "minItems": 4,
          "items": {
            "type": "array",
            "minItems": 2,
            "items": {
              "type": "number"
            }
          }
        },
        "bbox": {
          "type": "array",
          "minItems": 4,
          "items": {
            "type": "number"
          }
        }
      }
    },
    "properties": {
      "oneOf": [
        {
          "type": "null"
        },
        {
          "type": "object",
          "required": [
          ],
          "properties": {
            "AOO": {
              "type": "number"
            },
            "ARA": {
              "type": "number"
            },
            "BAC": {
              "type": "integer"
            },
            "BEN": {
              "type": "string"
            },
            "CAA": {
              "type": "integer"
            },
            "CCN": {
              "type": "string"
            },
            "CDR": {
              "type": "string"
            },
            "FFN": {
              "type": "integer"
            },
            "FFN2": {
              "type": "integer"
            },
            "FFN3": {
              "type": "integer"
            },
            "F_CODE": {
              "type": "string"
            },
            "HGT": {
              "type": "number"
            },
            "LZN": {
              "type": "number"
            },
            "OTH": {
              "type": "string"
            },
            "PCF": {
              "type": "integer"
            },
            "SAX_RS1": {
              "type": "string"
            },
            "SAX_RS2": {
              "type": "string"
            },
            "SAX_RS3": {
              "type": "string"
            },
            "SAX_RS4": {
              "type": "string"
            },
            "SAX_RS5": {
              "type": "string"
            },
            "SAX_RS6": {
              "type": "string"
            },
            "SAX_RS8": {
              "type": "string"
            },
            "SAX_RS9": {
              "type": "string"
            },
            "SAX_RX1": {
              "type": "string"
            },
            "SAX_RX2": {
              "type": "string"
            },
            "SAX_RX5": {
              "type": "string"
            },
            "SAX_RX6": {
              "type": "string"
            },
            "SAX_RX7": {
              "type": "string"
            },
            "SAX_RX8": {
              "type": "string"
            },
            "SAX_RX9": {
              "type": "string"
            },
            "SAX_RY0": {
              "type": "string"
            },
            "SAX_RY1": {
              "type": "string"
            },
            "SAX_RY2": {
              "type": "string"
            },
            "UFI": {
              "type": "string"
            },
            "WID": {
              "type": "number"
            },
            "WPI": {
              "type": "string"
            },
            "ZI001_SDP": {
              "type": "string"
            },
            "ZI001_SDV": {
              "type": "string"
            },
            "ZI001_SPS": {
              "type": "integer"
            },
            "ZI001_SRT": {
              "type": "string"
            },
            "ZI001_VSC": {
              "type": "string"
            },
            "ZI001_VSD": {
              "type": "string"
            },
            "ZI001_VSN": {
              "type": "string"
            },
            "ZI004_RCG": {
              "type": "string"
            },
            "ZI005_FNA": {
              "type": "string"
            },
            "ZI005_FNA2": {
              "type": "string"
            },
            "ZI005_NFN": {
              "type": "string"
            },
            "ZI005_NFN2": {
              "type": "string"
            },
            "ZI006_MEM": {
              "type": "string"
            },
            "ZI020_GE4": {
              "type": "string"
            },
            "ZI026_CTUC": {
              "type": "integer"
            },
            "ZI026_CTUL": {
              "type": "integer"
            },
            "ZI026_CTUU": {
              "type": "integer"
            },
            "ZSAX_RS0": {
              "type": "string"
            },
            "ZSAX_RX0": {
              "type": "string"
            },
            "ZSAX_RX3": {
              "type": "string"
            },
            "ZSAX_RX4": {
              "type": "string"
            },
            "ZVH": {
              "type": "number"
            },
            "FCSUBTYPE": {
              "type": "integer"
            },
            "ADR": {
              "type": "string"
            },
            "LMC": {
              "type": "integer"
            },
            "STL": {
              "type": "integer"
            },
            "STL2": {
              "type": "integer"
            },
            "STL3": {
              "type": "integer"
            },
            "HHD": {
              "type": "integer"
            }
          },
          "additionalProperties": false
        }
      ]
    },
    "links": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "href"
        ],
        "properties": {
          "href": {
            "type": "string",
            "format": "uri"
          },
          "rel": {
            "type": "string"
          },
          "type": {
            "type": "string"
          },
          "title": {
            "type": "string"
          }
        }
      }
    }
  }
}

{
  "type": "Feature",
  "id": "CWFID.SETTLEMENTSRF.0.8",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [ 36.33295599, 32.2828885 ], [ 36.33580536, 32.28198786 ],
        [ 36.33954522, 32.280714 ], [ 36.3399218, 32.28064846 ],
        [ 36.34017809, 32.28070732 ], [ 36.34043842, 32.28088291
        ], [ 36.34077816, 32.28164959 ], [ 36.34109545, 32.28257287 ],
        [ 36.34149681, 32.28395917 ], [ 36.34184168, 32.28532761 ],
        [ 36.34209096, 32.2864909 ], [ 36.3422161, 32.28702197 ],
        [ 36.34225167, 32.28733591 ], [ 36.34233647, 32.28759259 ],
        [ 36.33597433, 32.2896979 ], [ 36.33518813, 32.28802212 ],
        [ 36.33513818, 32.28790676 ], [ 36.33418013, 32.28569608 ],
        [ 36.33295599, 32.2828885 ]
      ]
    ]
  },
  "properties": {
    "CCN": "No Information",
    "F_CODE": "AL020",
  },
  "links": [
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari",
      "rel": "service,"
    },
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf?f=application%2Fjson",
      "rel": "collection",
      "type": "application/json"
    },
    .
    .
    .
  ]
}

{
  "type": "Feature",
  "id": "CWFID.SETTLEMENTSRF.0.8",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [ 36.33295599, 32.2828885 ], [ 36.33580536, 32.28198786 ],
        [ 36.33954522, 32.280714 ], [ 36.3399218, 32.28064846 ],
        [ 36.34017809, 32.28070732 ], [ 36.34043842, 32.28088291 ],
        [ 36.34077816, 32.28164959 ], [ 36.34109545, 32.28257287 ],
        [ 36.34149681, 32.28395917 ], [ 36.34184168, 32.28532761 ],
        [ 36.34209096, 32.2864909 ], [ 36.3422161, 32.28702197 ],
        [ 36.34225167, 32.28733591 ], [ 36.34233647, 32.28759259 ],
        [ 36.33597433, 32.2896979 ], [ 36.33518813, 32.28802212 ],
        [ 36.33513818, 32.28790676 ], [ 36.33418013, 32.28569608 ],
        [ 36.33295599, 32.2828885 ]
      ]
    ]
  },
  "properties": {
  },
  "links": [
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari",
      "rel": "service,"
    },
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf?f=application%2Fjson",
      "rel": "collection",
      "type": "application/json"
    },
    .
    .
    .
  ]
}

{
  "type": "Feature",
  "id": "CWFID.SETTLEMENTSRF.0.8",
  geometry": {
    "type":"Polygon",
    "coordinates": [
      [
        [ 36.33295599, 32.2828885 ], [ 36.33513818, 32.28790676 ],
        [ 36.33418013, 32.28569608 ], [ 36.33295599, 32.2828885 ]
      ]
    ]
  },
  "properties": {
  },
  "links": [
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari",
      "rel": "service,"
    },
    {
      "href": "https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/SettlementSrf?f=application%2Fjson",
      "rel": "collection",
      "type": "application/json"
    },
    .
    .
    .
  ]
}

4.4.4.  GNOSIS Map Server

New capabilities were integrated in the GNOSIS Map Server during the code sprint, including support for CQL2 advanced spatial operators and WKT geometry, support for filtering map and coverage requests by geometry using CQL2 expressions including WKT geometry, as well as support for the DGGS-JSON data encoding and additional improvements to the implementation of OGC API — DGGS.

In order to support output of DGGS-JSON data, a deterministic ordering of sub-zones needs to be implemented. Progress on the initial design of this scanline based ordering was made at the previous code sprint in Evora, with progress on the implementation since then. During the code sprint, this initial support was deployed.

Figure 27 — Example ordering of ISEA3H sub-zones starting on a vertex for an odd relative depth

Figure 28 — Example ordering of ISEA3H sub-zones starting on an edge for an even relative depth

In addition to the ordering of sub-zones for polar pentagonal zones which was not yet implemented, issues were noticed with parent hexagonal zones crossing interruptions of the Icosahedral Snyder Equal Area planar projection. These issues were identified as new variations of problem which need to be taken into account by the sub-zone ordering algorithm, and work was undertaken to implement these cases correctly. Progress was also made on figuring out the correct sub-zone order of polar pentagonal parent zones.

Figure 29 — Proper ordering for ISEA3H sub-zones of a parent hexagonal zone crossing an ISEA interruption

Figure 30 — Visualization of a DGGS-JSON file generated from the GEBCO_2014 grid

A snippet extract of the DGGS-JSON file used to render this data follows, with the full version available from the OGC API — DGGS implementation at https://maps.gnosis.earth/ogcapi/collections/gebco/dggs/ISEA3H/zones/B2-1-A/data.json?zone-depth=7. The snippet illustrates how the bulk of the encoded data is a simple linearized one-dimensional array of the values associated with each zone, implying a particular order. There is no need to provide the coordinates of the zone geometry, of the centroid, or even the zone identifier for each sub-zone, as this information can be inferred from the zone order.

{
   "dggrs" : "https://www.opengis.net/def/dggrs/OGC/1.0/ISEA3H",
   "zoneId" : "B2-1-A",
   "depths" : [ 7 ],
   "values" : {
      "Elevation" : [
         {
            "depth" : 7,
            "shape" : { "count" : 2269, "subZones" : 2269 },
            "data" : [ -43.212332564804, -49.3541585971952, ..., -5158.8415987109893 ]
         }
      ]
   }
}

Listing 11

Figure 31 — DGGS-JSON data representation available from a zone information resource on the GNOSIS Map Server

4.4.5.  Geonovum JSON Linter

The team from Geonovum took the existing JSON-FG linter and renamed it to the OGC-Checker. They added functionality to support the OGC API — Features — Part 1: Core Standard and a small portion of the OGC API — Common — Part 1: Core Standard. The tool is now capable of automatically discovering which conformance classes are implemented and can apply the appropriate rulesets for validation based on that. This will enable the maintainers of the tool to add support for other OGC API Standards in the future. Figure 32 shows a screenshot of the linter having validated an instance of the OGC API — Features Standard.

Figure 32 — Screenshot of the JSON Linter

The linter is able to report on any errors that it detects on an implementation. Figure 33 shows a screenshot of an example error message presented by the JSON Linter. In the example, the key servers which is required by the OpenAPI 3.0 Specification has been changed to serves. The linter makes use of Spectral, an open source suite of libraries for testing compliance to the OpenAPI Specification. The linter reports the error on the right hand side of the display.

Figure 33 — Screenshot of an example error message presented by the JSON Linter

Testing the linter on example implementations of OGC API — Features led to the discovery of a number of small issues that were resolved by Clemens Portele (interactive instruments) during the code sprint. With the successful implementation of the linter during the code sprint, the team has taken the first steps toward making the linter/validator more generic. The results can be found here: https://github.com/Geonovum-labs/ogc-checker, a live demo is available here: https://geonovum-labs.github.io/ogc-checker/#/ogc-api

6.1.1.  Experimentation

The sprint participants made the following recommendations regarding potential experiments in future Collaborative Solutions and Innovation (COSI) Program initiatives:

6.1.2.  Prototyping

The sprint participants made the following recommendations regarding prototype development in future COSI initiatives:

6.1.3.  Standardization

The sprint participants made the following recommendations regarding future discussions in working groups and the Standards Program: