I. Abstract
The subject of this Engineering Report (ER) is a code sprint that was held from July 10th to 12th, 2024 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 Google and supported by Natural Resources Canada (NRCan). The code sprint included activities involving several OGC API Standards and data encoding standards, as well as special tracks on Data Quality & Artificial Intelligence, Map Markup Language (MapML) and Validators.
II. Executive summary
The rapid adoption of Artificial Intelligence (AI) has highlighted the need for good quality training data to enable the systems to offer effective decision making support. Data quality is therefore a critical requirement for future geospatial technologies just as it has always been for historic ones. Whereas some of those future geospatial technologies will likely rely on raster data, many others will rely on vector feature data. Therefore, validators capable of checking the validity of vector feature data files are likely to play a key role in an AI-driven future.
The focus of this Engineering Report (ER) is a code sprint that was held from July 10th to 12th, 2024 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 Google and supported by Natural Resources Canada (NRCan). The code sprint included activities involving several OGC API Standards and data encoding standards, as well as special tracks on Data Quality & AI, Map Markup Language (MapML) and Validators. Other activities at the code sprint were related to OGC CoverageJSON, OGC SensorThings API WebSub Extension, OGC API — Records, OGC API — Features, and OGC Styles and Symbology.
The MapML special track of the code sprint sought to prototype integration of a MapML viewer into implementations of OGC API Standards. The MapML specification extends the semantics of several HTML Standard elements, and specifies a small set of new, mapping-specific elements, in the HTML namespace. This engineering report concludes that the sprint participants proved that MapML has a role to play in the geospatial ecosystem and that MapML can be easily integrated into implementations of OGC API Standards.
The Data Quality and AI track of the code sprint sought to implement support for the Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) Standard and for a Data Quality Measures Register based on the ISO 19157 series of Standards. The TrainingDML-AI Standard offers a conceptual model and data encodings for geospatial machine learning training data. The engineering report concludes that the use cases for machine readable and executable provenance chains should be widened to include specific Machine Learning (ML) training data use cases. The ability to sample, correct, and train large datasets should have a reproducible method for training models.
The Validators track of the code sprint sought to extend and implement various tools for testing datasets and products for compliance to OGC Standards. In a previous code sprint a JSON-FG Linter was developed. A linter checks the correctness of code or encoding format inside an Editor application while a user is writing or editing. In this code sprint, some of the participants sought to expand on the previous work by creating a linter for OGC API — Features. Another team of participants sought to implement an Executable Test Suite (ETS) for TrainingDML-AI. The engineering report concludes that there is significant potential for client-side validators such as the Linter to enhance the developer experience, alongside server-side validators such as TEAM Engine.
The code sprint was held as a generic code sprint meaning that all OGC working groups were encouraged to participate in the event. As a result, several OGC Standards Working Groups (SWGs) set up teams of developers to collaborate with during the three-day event. In addition to providing software developers with an environment for collaborative coding and experimentation, the code sprint also provided opportunities for thought leadership through presentations and tutorials in the Mentor Stream. This made the code sprint a rich environment for knowledge transfer across teams, as well as for nurturing cross-functional teams.
The sprint participants made the following recommendations regarding potential experiments in future Collaborative Solutions and Innovation (COSI) Program initiatives:
OGC API — 3D Geovolumes experimentation in the context of Digital Twins;
CDB2 experimentation in the context of Digital Twins;
Experimentation on consistency of metadata frameworks;
Experimentation on consistency of parameter and schema fragments in APIs; and
Experimentation on OGC API — Features and Geocoding.
The sprint participants made the following recommendations regarding prototype development in future COSI initiatives:
Initiative on Urban Digital Twins;
An activity building on the ISO metadata activity;
Prototyping of an HTML MapML validator, possibly as a service — see https://github.com/Maps4HTML/validator-mapml for ideas; and
Prototyping of extension of MapML to enable it to consume the JSON-based payloads that are described in the OGC API family of standards.
The sprint participants made the following recommendations regarding future discussions in working groups and the Standards Program:
Discussion on consistency of parameter and schema fragments in APIs;
Development of a roadmap for a possible TrainingDML-AI conformance class for OGC API — Records;
Guidance on the consistency of scale between Observations, Measurements, and Samples (OMS) and the API Standards;
Addition of a security element in future versions of TrainingDML-AI and other metadata encodings;
Run a code sprint focused on machine-readable provenance chains, model reproducibility, and recording data quality;
Update OGC RAINBOW to offer executable code and variable injection to ensure the chains are machine readable;
Test the process of machine-readable provenance chains with several different datasets with a focus on model reproducibility; and
Provide feedback to ISO/TC 211 on findings regarding Data Quality and AI.
III. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, API, openapi, html, tdml-ai, mapml, json-fg
IV. Submitters
All questions regarding this document should be directed to the editors or the contributors:
Table — Submitters
| Name | Organization | Role |
|---|---|---|
| Gobe Hobona | OGC | Editor |
| Joana Simoes | OGC | Editor |
| Tom Kralidis | OSGeo | Contributor |
| Chris Little | Met Office | Contributor |
| Frank Terpstra | Geonovum | Contributor |
| Joost Farla | Geonovum | Contributor |
| Maxime Collombin | University of Applied Sciences, Western Switzerland (HEIG-VD) | Contributor |
| Sam Meek | Helyx Secure Information Systems | Contributor |
| Peter Rushforth | Natural Resources Canada | Contributor |
| Aliyan Haq | Natural Resources Canada | Contributor |
| Rui Cavaco | Norte Portugal Regional Coordination and Development Commission | Contributor |
| Ivana Ivanova | Curtin University | Contributor |
| Jerome St-Louis | Ecere | Contributor |
| Ricardo Garcia Silva | Geobeyond | Contributor |
| Samantha Lavender | Pixalytics Ltd | Contributor |
| Joan Maso | UAB-CREAF | Contributor |
| Panagiotis (Peter) A. Vretanos | CubeWerx Inc. | Contributor |
1. Introduction
OGC Code Sprints experiment with emerging ideas in the context of geospatial Standards and help improve interoperability of existing Standards by experimenting with new extensions or profiles. They are also used for building proofs-of-concept to support standards development activities and the enhancement of software products. The nature of the activities is influenced by whether a code sprint is ‘generic’ or ‘focused’. All OGC working groups are invited and encouraged to set up a thread in generic code sprints, whereas focused code sprints are tailored to a specific set of standards (typically limited to three standards).
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.
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).
A coordinate system that is related to the real world by a datum term name (source: ISO 19111).
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).
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
GIS
Geographic Information System
OGC
Open Geospatial Consortium
OWS
OGC Web Services
REST
Representational State Transfer
TEAM
Test, Evaluation, And Measurement Engine
3. High-Level Architecture
As illustrated in Figure 1, 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. The participants deployed the their software in their own infrastructure.
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 or in support of 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.
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-057r1). 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. Candidate OGC Standards
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:
the ability to use Coordinate Reference Systems (CRSs) other than WGS84;
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.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. Specifications from the Community
3.3.1. MapML
3.3.1.1. Introduction
Map Markup Language (MapML) is a text-based format which enables web page authors to insert maps into web pages as hypertext documents exchanged over HTTP. One of the well known implementations of MapML is the open source GeoServer software product, which provides access to MapML through WMS, WMTS, and WFS so far. Through this code sprint, the MapML community sought to tackle integration of MapML into OGC APIs and potentially to demonstrate both the serving of MapML documents through such APIs and the accessing of content encoded as MapML. Experimenting with the implementation of MapML in OGC APIs is important because of the need to obtain feedback from the developer community and because MapML is a proposal to the browser community from the spatial community for natively integrating maps into web pages. In order to make that case to the browser community, there is a need to have the widest possible review and feedback from the geospatial community.
Across society, HTML plays a key role on the Web. Maps are therefore important enough to fit into web browsers because maps play a key role in how location is communicated across society. So on the day that browsers handle maps natively the same way that they handle images, there should be a wealth of content waiting to be displayed on the possibly billions of web pages that will display location information. Thus, integrating MapML support into geospatial content management systems that are fronted by implementations of OGC Web Service Standards and OGC API Standards will be essential and so the OGC community and the MapML viewer polyfill are key to meeting that goal.
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.1.3. Layers
In MapML, a map can have zero or more layers and for map layers fewer is oftentimes better, because a map can get very visually cluttered if it has too many layers. Layers are exposed to the user through the layer control in DOM order, from the closest to document start to the furthest. MapML documents are parsed in sequence based on ‘distance’ from the document start. Layers and layer content is rendered according to the ‘painters model’. Layers contain a single level of node depth; there cannot be recursively or infinitely nested layers or layer content.
3.3.1.4. Map Extents
A map extent (map-extent element) is a templated form of map content that allows the map author to fetch features, tiles or whole-map image content on demand (from a web service or API) based on map movement. The fetched content overlays and potentially obscures previously rendered content (per the painter’s model). Consequently, each map-extent is exposed in the layer control underneath the parent layer as part of that layer’s settings menu item, in which it is labeled (by default) as a ‘Sub-layer’ (the default accessible name) which can be progressively turned on or off by the user, whereas individual features are not exposed individually in the layer control. If control of individual features is needed, those features need to be wrapped in a layer of their own. Layers can contain feature collections. Features on a map are a single tab stop, but are keyboard navigable via the arrow keys.
3.3.1.5. Coordinate Reference Systems
MapML supports different map tiling schemes through a concept called the Tiled Coordinate Reference System (TCRS) A TCRS is a set of associated coordinate systems (some of) which share a common origin in space, but which differ by the size of their smallest unit at defined locations, e.g., meters/pixel along the equator (MapML). A TCRS binds an instance of a Coordinate Reference System with an instance of a Tile Matrix Set into a single well known value of projection, and it places axis order constraints on content encoded according to that TCRS (as do all CRS). Specifically, coordinates when not explicitly marked up, are required to be encoded with horizontal axis followed by vertical axis (“xy” order). An example of how the TCRS may be handled can be observed in GeoServer which defines the “MapML:” CRS authority for the pre-defined MapML projection values (i.e., MapML:OSMTILE, MapML:CBMTILE, MapML:WGS84 and MapML:APSTILE) in which the association between the tile matrix set and the coordinate reference system of the given TCRS is managed internally. Using this authority prefix allows GeoServer to enable MapML access through the strict OGC web service interface standards, and a similar technique may be applicable in the OGC API implementations. There are the four well known or proof of concept TCRS defined by the MapML specification (most importantly: OSMTILE, WGS84, and CBMTILE), and web developers can define custom TCRS for use in the MapML viewer, using the proj4.js library. OGC API implementations might be able to adapt the GeoServer technique of defining the “MapML:” CRS authority for OGC API-based interfaces where an official spatial reference system name is a required information item, and in doing so, to not rely on unwritten semantics which commonly happens in geospatial information exchange.
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:
Completeness — the number or percentage of features that appear within the dataset compared to the universe of discourse.
Thematic Accuracy — the number or percentage of misclassified features.
Logical Consistency — the number of missing links in a road dataset.
Conceptual Consistency — number of overlapping surfaces in a dataset.
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. Software Projects and Products
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 as follows.