3.1.1.  OGC SensorThings API

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

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

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

3.1.3.  OGC API — Features

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

3.1.4.  OGC API — Tiles

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

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

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

3.1.5.  OGC API — Environmental Data Retrieval

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

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

3.1.6.  OGC API — Processes

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

3.1.7.  OGC CityGML

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

3.1.8.  OGC CDB

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

3.1.9.  OGC GeoPackage

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

3.1.10.  OGC GML in JPEG 2000 (GMLJP2)

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

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

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

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

3.2.2.  OGC API — Records

The OGC API — Records candidate Standard provides discovery and access to metadata records that describe resources such as features, coverages, tiles / maps, models, assets, datasets, services, or widgets (OGC 20-004). The candidate Standard enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed. The candidate Standard also enables the discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed.

3.2.3.  OGC API — Coverages

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

3.2.4.  OGC Publish/Subscribe extension of OGC API Standards

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

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

The draft OGC Features and Geometries JSON (JSON-FG) Standard extends the GeoJSON format to support a limited set of additional capabilities that are out-of-scope for GeoJSON but that are important for a variety of use cases involving feature data (OGC 21-045). In particular, the JSON-FG Standard specifies the following extensions to the GeoJSON format:

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

• support for solids and prisms as geometry types;

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

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

3.3.1.  NGIIS GIMI

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

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

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

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

• enable automation; and

• support to disadvantaged and remote users.

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

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

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

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

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

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

3.3.2.  AsyncAPI

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

3.4.1.  OSGeo pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of Standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation. pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

3.4.2.  OSGeo pycsw

pycsw is an implementation of the OGC API — Records candidate Standard and the OGC’s Catalog Service for the Web (CSW) Standard written in Python. Started in 2010 (more formally announced in 2011), pycsw allows for the publishing and discovery of geospatial metadata via numerous APIs (CSW 2/CSW 3, OpenSearch, OAI-PMH, SRU), providing a standards-based metadata and catalog component of spatial data infrastructures. pycsw is Open Source, released under an MIT license, and runs on all major platforms (Windows, Linux, Mac OS X). pycsw is an official OSGeo Project as well as an OGC Reference Implementation. pycsw supports numerous metadata content and API standards, including the OGC API — Records — Part 1: Core, version 1.0 candidate Standard and its associated specifications. The official documentation provides an overview of all supported standards.

3.4.3.  ldproxy

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

3.4.4.  MariaDB Geospatial Data Server

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

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

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

• All conformance classes and recommendations of the OGC API — Features — Part 1: Core Standard

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

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

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

• Multiple versions of the Web Map Service (WMS), Web Processing Service (WPS), Web Map Tile Service (WMTS), and Web Feature Service (WFS) Standards

• A number of other “un-adopted” OGC Web Service draft specifications including the Testbed-12 Web Integration Service, OWS-7 Engineering Report — GeoSynchronization Service, and the Web Object Service prototype

The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats, for example, Geography Markup Language (GML), GeoJSON, Mapbox Vector Tiles, MapMP, as well as several coordinate reference systems.

3.4.5.  GNOSIS Map Server

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

3.4.6.  web-gimi-viewer

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

It leverages:

• mp4box for the ISOBMFF container;

• vidterra’s misb.js for the ST0601 KLV metadata;

• The browser’s XML parser for the security metadata;

• heic2any for the HEIC image codec; and

• Gleo for the web map interface.

4.1.1.  OGC API — Records

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

Discussions included the following.

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

  • issue sweep;

  • requirements refactoring (shared query parameters);

  • resulting ATS refactoring;

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

  • clarification on …​/items q parameter; and

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

• Proposal for facets:

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

  • specifying facets on …​/items requests;

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

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

• Discussion on federation/distributed search as follows.

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

  • Current issues such as:

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

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

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

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

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

 Greece (24 records)
 Germany (12 records)
 England (5 records)

2020-01-01 to 2020-02-01: 18 records
2020-02-01 to 2020-03-01: 22 records
2020-03-01 to 2020-04-01: 43 records

hasDownloads : 2051 records
hasMaps : 11495 records

4.1.2.  OGC API — Environmental Data Retrieval

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

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

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

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

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

Discussions included the following.

• Links requirements as discussed in Issue 451.

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

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

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

• Channels requirements as discussed in Issue 452.

• Is the OGC API endpoint topic structure enough?

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

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

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

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

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

  • Connected Systems

  • Features: feature transactions

  • Processes: subscribing to async jobs channels, new processes

  • Records: aggregation/metadata ingest/publication

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

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

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

4.1.3.  OGC API — Features

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

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

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

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

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

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

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

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

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

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

• Improve the wording in some normative statements.

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

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

• Remove broken dependency in Clause 13.

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

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

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

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

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

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

4.1.4.  OGC API — Maps

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

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

4.1.5.  STAplus SensorThings API Extension

4.1.5.3.  Proposed Solution

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

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

Figure 2 — The STAplus and GeoXACML based architecture implemented by the CitiObs project

For the code sprint, the participants proposed extending the existing STAplus implementation with a GeoXACML Policy Enforcement Point (PEP) to enforce policies executed by the GeoXACML 3.0 Policy Decision Point (PDP). The participants planned to leverage the GeoXACML 3.0 implementation from Secure Dimensions and the XACML 3.0 implementation from Thales and also planned to visualize the access control results (enforcing a GeoXACML 3.0 policy) by using the generic STAplus visualization application TAPIS implemented by CREAF.

4.1.5.4.  Achievement

During the Code Sprint, a demo was implemented that included the following components.

• STAplus endpoint: https://ogc.demo.secure-dimensions.de/staplus/v1.1

• TAPIS endpoint: https://www.tapis.grumets.cat/

As per the architecture diagram, the (Geo)XACML policy controls the SQL query rewriting. To demonstrate the functionality, a GeoXACML 3.0 wrapper was implemented. To leverage this functionality, a policy must be written using XACML 3 obligations. An obligation can be understood as an object that gets executed by the PEP. In this implementation, the obligation targets to rewrite the SQL query that was constructed from the HTTP request. To ease the policy construction, the sprint participants used an extension to ALFA, a JavaScript alike notation for writing policies which resolves to the following simplistic structure of a policy:

Figure 3 — Fragment from example GeoXACML policy

The ”interesting” part of the policy is the obligation that undertakes the SQL rewrite. The implementation is generic, as it supports declaring obligations based on parameterized SQL expressions. In technical terms, the SQL expression must leverage the actual database structure but also honor the relations among the STAplus entities.

Figure 4 — STAplus Entity Type diagram

The following example illustrates the obligation to filter on “my” obligations.

{
  "entries": [
    {
      "tableName": "OBSERVATIONS",
      "wrappers": [
        {
          "@class": "de.fraunhofer.iosb.ilt.frostserver.persistence.pgjooq.utils.validator.SecurityWrapperMulti",
          "wrappers": [
            {
              "condition": {
                "@class": "de.fraunhofer.iosb.ilt.frostserver.persistence.pgjooq.utils.validator.CheckFixed",
                "valid": true
              },
              "wrapper": {
                "@class": "de.fraunhofer.iosb.ilt.frostserver.persistence.pgjooq.utils.validator.SecurityWrapperJoin",
                "joins": [
                  {
                    "targetTable": "DATASTREAMS",
                    "targetAlias": "ds",
                    "joinOnSql": "t.\"DATASTREAM_ID\" \u003d ds.\"ID\"",
                    "joinType": "INNER"
                  },
                  {
                    "targetTable": "PARTIES",
                    "targetAlias": "pa",
                    "joinOnSql": "ds.\"PARTY_ID\" \u003d pa.\"ID\"",
                    "joinType": "LEFT"
                  }
                ],
                "where": "pa.\"AUTHID\" \u003d ?",
                "usernameParameter": true
              }
            }
          ]
        }
      ]
    }
  ]
}

Wrapper to filter observations

A wrapper was implemented to filter observations according to the policy. The SQL wrapper applies to the table “OBSERVATIONS” and uses a join on “DATASTREAMS” and “PARTIES” with a final WHERE clause that conditions the Party/authId eq username. The joins follow the relations per the STAplus UML diagram. But instead of using the entity type names from the UML diagram, the actual table names are used.

The visualization of the “my observations” was done via the TAPIS implementation. First, a user needs to select the Party representing the user. Then the system connects to the Datastreams for the Party. Once a Datastream is selected, the user can query the observations.

Case 1: Anonymous access

Figure 5 — Screenshot of the interface when a user is NOT logged into the TAPIS system

Figure 5 shows that for anonymous access, no observations are returned.

Case 2: User Long John Silver logged in access

Figure 6 — Screenshot of the interface showing observations when a user has been authenticated

Figure 6 shows that Long John Silver can fetch his observations.

Figure 7 — Screenshot of the interface when authenticated user is prevented from accessing other user’s observations

Figure 7 shows that Long John Silver cannot fetch Joan’s observations; the attempt to access observations results in “no data”.

4.2.1.  OGC Features and Geometries JSON

The JSON-FG candidate Standard was approved by the OGC Architecture Board for Public Comment shortly before the code sprint. The JSON-FG team held one breakout session during the sprint to answer questions on the specification and provide an overview over changes introduced in the new draft version 0.2.

The following list summarizes JSON-FG-related results achieved during the sprint.

• Participants from Geonovum tested the new JSON-FG driver in GDAL, see Clause 4.3.6 for details.

• A free and open source json-fg-validator tool was created as an executable test suite to test JSON FG documents against the requirements. The initial implementation provides a framework to test and report. The first pass covered most of the “Core” Requirements Class.

  The tool is implemented in Python and contributions are welcome and encouraged.

  

  Figure 8 — Screenshot of the json-fg-validator tool providing an ETS report.

• Development of a json-fg-linter tool was started by Geonovum. The linter rules are based on JSON-FG requirements classes Core, 3D and Feature Types, and Schemas. In addition, the linter does some consistency checks that are useful but not based on explicit requirements.

• An initial version of a json-fg-java library was developed by Geonovum. The library aims to make encoding and decoding of JSON-FG documents as easy as possible in Java. The status of the library is experimental. The implementation is compatible with v0.2.1 of the JSON-FG specification.

• A JSON-FG map client was deployed by sprint participants that supported viewing JSON-FG documents by drag-and-drop.

• MUDDI-conformant data was loaded into MariaDB and published via an OGC Web API, including in JSON-FG; see Clause 4.3.1 for details.

• The ldproxy implementation was updated to JSON-FG version 0.2.1 during the sprint, see Clause 4.3.2 for details.

One topic during the breakout was support for different coordinate reference systems and the GeoJSON compatibility. Since the sprint took place in London, the British National Grid (EPSG:27700) was used as the coordinate reference system in example requests to an API implementing OGC API — Features as follows.

• The MariaDB results section includes a “Manhole” feature being presented as JSON-FG using the EPSG:27700 CRS as provided from the MariaDB feature server.

• An airport feature from the OS Open Zoomstack dataset in the default coordinate reference system (OGC:CRS84):

  {
    "type": "FeatureCollection",
    "numberReturned": 1,
    "timeStamp": "2023-11-08T06:30:45Z",
    "featureType": "Airport",
    "featureSchema": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
    "coordRefSys": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
    "conformsTo": [
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/core",
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/types-schemas"
    ],
    "geometryDimension": 0,
    "features": [
      {
        "type": "Feature",
        "id": 1,
        "geometry": {
          "type": "Point",
          "coordinates": [
            -1.2918826,
            59.8783475
          ]
        },
        "properties": {
          "name": "Sumburgh Airport"
        },
        "place": null,
        "time": null
      }
    ]
  }

• The same airport in the British National Grid (EPSG:27700):

  {
    "type": "FeatureCollection",
    "numberReturned": 1,
    "timeStamp": "2023-11-08T06:32:22Z",
    "featureType": "Airport",
    "featureSchema": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
    "coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/27700",
    "conformsTo": [
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/core",
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/types-schemas"
    ],
    "geometryDimension": 0,
    "features": [
      {
        "type": "Feature",
        "id": 1,
        "geometry": null,
        "properties": {
          "name": "Sumburgh Airport"
        },
        "place": {
          "type": "Point",
          "coordinates": [
            439742.86,
            1110569.17
          ]
        },
        "time": null
      }
    ]
  }

• The same airport in the British National Grid (EPSG:27700), but for GeoJSON compatibility also with the geometry in OGC:CRS84:

  {
    "type": "FeatureCollection",
    "numberReturned": 1,
    "timeStamp": "2023-11-08T06:32:41Z",
    "featureType": "Airport",
    "featureSchema": "https://demo.ldproxy.net/zoomstack/collections/airports/schema",
    "coordRefSys": "http://www.opengis.net/def/crs/EPSG/0/27700",
    "conformsTo": [
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/core",
      "http://www.opengis.net/spec/json-fg-1/0.2/conf/types-schemas"
    ],
    "geometryDimension": 0,
    "features": [
      {
        "type": "Feature",
        "id": 1,
        "geometry": {
          "type": "Point",
          "coordinates": [
            -1.2918826,
            59.8783475
          ]
        },
        "properties": {
          "name": "Sumburgh Airport"
        },
        "place": {
          "type": "Point",
          "coordinates": [
            439742.86,
            1110569.17
          ]
        },
        "time": null
      }
    ]
  }

4.2.2.  OGC CDB

The Sprint participants from Ecere Corporation and FlightSafety International Visual Systems collaborated on work to advance the development of CDB 2.0. These participants set up a new draft CDB 2.0 GeoPackage Data Store candidate standard with initial content. The candidate standard defines a data store implementing the CDB 2.0 Core Conceptual Model based on the OGC GeoPackage data container and GeoPackage extensions for storing different data types.

The candidate standard defines a conceptual model and data stores for encoding different types of data, including detailed 3D environments, according to that conceptual model with a focus on deterministic performance and scalability. This version of CDB is envisaged to enable a variety of use cases ranging from mobile computing at the edge to large scale data repositories, including training, simulation, digital twins, and acting as an efficient backing data store for OGC API implementations.

4.2.3.  GML and JSON-FG schemas for the MUDDI Core Logical Model

To support sprint participants with encoding MUDDI-conformant data, interactive instruments GmbH derived GML and JSON-FG application schemas from the Core Logical Model of MUDDI.

ShapeChange is a free and open source tool written in Java that takes application schemas constructed according to ISO 19109 from a UML model and derives implementation representations. Implementation representations include GML application schemas, JSON Schemas, SQL DDL, feature catalogs, etc.

For the code sprint, a ShapeChange configuration for the Core Logical Model was created that derives a GML application schema, a JSON-FG schema, and an HTML feature catalog.

The results were made available in a folder of the GitHub repository used for the code sprint. In particular:

• GML application schema

• JSON-FG Schema

Participants from the MUDDI working group and interactive instruments discussed several modelling aspects of the Core Logical Model before deriving the results. For the sprint, the following decisions/changes were made to the Core Logical Model.

• Some errors in the model were fixed (e.g., undefined data types like “int” instead of “Integer” or duplicate model elements with the same name).

• Geometry types from ISO 19107:2003 are used; geometry properties have a maximum multiplicity of “1”.

• The application schema Codelist Register — MUDDI Core should be parallel to the Core Logical Model, not nested into it.

The following are remarks on the generated schemas.

• The GML application schema was generated using the GML encoding rule from ISO 19136:2020. For simplicity, codelist values are represented as plain strings, with additional values having prefix “other: .” The target namespace, the namespace prefix, and XML Schema Definition (XSD) filename are placeholders.

• In the JSON-FG application schema, “$id” value is a placeholder. Schema references use JSON Pointers, not the anchors, because validator support for JSON Pointers is better compared to anchor references.

The schemas were used, for example, by participants from Safe Software, see Clause 4.3.4 for details.

4.2.4.  MUDDI logical schema experimentation

Sprint participants from Ordnance Survey and the Geospatial Commission sought to examine how a schema that conformed to MUDDI could be created to support the ingestion of typical utility source data. The participants organized their code sprint work into creation of a backend to store MUDDI-compliant data and a front end to display the data. To facilitate the task, open utility data was transformed into MUDDI-compliant data.

The Geospatial Commission and Ordnance Survey actively supported the MUDDI logical schema experimentation because the UK’s National Underground Asset Register (NUAR) data model is an implementation of the MUDDI model [21]. The Geospatial Commission therefore provided a range of artifacts and sample data in support of the experimentation.

The sprint participants started by reviewing the MUDDI extended conceptual model. All of the feature types in the model were translated associated tables in a database, as illustrated in Figure 9. The sprint participants also considered the inheritance between feature types, creating tables for ‘real’ feature types which inherit attribution from ‘abstract’ feature types in the conceptual model.

Figure 9 — Illustration of a MUDDI logical schema for a relational database

The figure shows the tables that were created and how the tables relate to one another. The figure consists of tables for each real feature type. These tables are mostly linked by foreign keys, e.g., for linking conveyance information against network information.

Some fields are related to multiple tables, so in order to maintain the relationship structure, the sprint participants had to create relationship tables to document relationships between different tables. As shown on the figure, there is a ‘big’ table in the middle which ensures that a user can record the relationships between a MUDDI Event type and any MUDDI Object type. Another example of a relationship table that had to be created to support representation of MUDDI in a relational model is the accessory table, which links Network Accessories (e.g., containers and sensors) to the relevant network conveyance (node or link). The figure has been created using an online tool called dbdocs.io.

One thing that the sprint participants found unclear in the candidate standard was the relationship between a network, subnetworks, and subordinate networks. The relationships between these types of networks is illustrated in Figure 10. A network is the entirety of the graph consisting of all nodes and edges, as highlighted by the blue oval on the diagram. The subnetwork is a geographic subset of the network, for example one owned by a county and is illustrated on the diagram through the three green ovals. There is also a subordinate network which is based on an asset property rather than geographic subsetting.

Figure 10 — Relationships between types of networks in MUDDI

To demonstrate that sample data conforming to the logical schema could be displayed on a web application, the sprint participants uploaded the data into a pygeoapi instance. The pygeoapi instance was then linked into a web application. A screenshot of the web application is shown in Figure 11.

Figure 11 — A screenshot of a web application displaying underground asset data

Future work on the storage aspects of the MUDDI task could involve using the MUDDI logical schema as a template for MUDDI compliance. The logical schema does not currently have much attribution about the assets themselves. Therefore any implementation would be expected to introduce additional attributes. The code for the logical schema is available at: https://github.com/Geovation/muddi_compliance

4.2.5.  Analysis of MUDDI by IIT Bombay

Sprint participants from IIT Bombay conducted an analysis of the MUDDI model, in relation to the physical data that had been supplied for the code sprint to determine the potential use of the logical model (represented in the schemas) to support harmonization of physical data which had been synthesized to represent data from different utility providers.

Several datasets had been provided, therefore half of the first day of the code sprint was spent reviewing the datasets and developing an understanding of the content that had been provided. One of the observations made during the review of the datasets was that some of the data was in different languages (e.g. English, German, etc.). A screenshot of the data displayed on FME Data Inspector is shown in Figure 12.