3.5.  Abbreviated terms

API

Application Programming Interface

ASF

Apache Software Foundation

CIS

Coverage Implementation Schema

CRS

Coordinate Reference System

DGGS

Discrete Global Grid Systems

EDR

Environmental Data Retrieval

GIS

Geographic Information System

GRASS

Geographic Resources Analysis Support System

MOU

Memorandum of Understanding

OGC

Open Geospatial Consortium

OSGeo

Open Source Geospatial Foundation

OWS

OGC Web Services

REM

Route Exchange Model

REST

Representational State Transfer

SDI

Spatial Data Infrastructure

TMS

Tile Matrix Set

WCS

Web Coverage Service

WFS

Web Feature Service

WMS

Web Map Service

WMTS

Web Map Tile Service

WPS

Web Processing Service

4.1.  Approved OGC Standards

This section describes the approved OGC standards implemented during the code sprint.

4.2.  Draft OGC Specifications

This section describes the draft OGC specifications implemented during the code sprint.

4.3.  OSGeo Projects

This section describes software products, from OSGeo Projects, that were deployed during the code sprint.

4.4.  OSGeo Community Projects

This section describes software products, from OSGeo Community Projects, that were deployed during the code sprint.

4.5.  ASF Projects

This section describes software products, from ASF Projects, that were deployed during the code sprint.

4.6.  Other open source products

4.7.  Proprietary products

5.1.  Leaflet

One of the contributors of Leaflet implemented support for OGC API — Maps in the code sprint. Support for OGC API — Maps in Leaflet was implemented as a plug-in, enabling anyone to integrate the JavaScript files into their JavaScript application.

Figure 2 — Screenshot of the leaflet demo

5.2.  QGIS MetaSearch Plugin

Developers from OSGeo and the Meteorological Service of Canada (MSC) worked on an enhancement to the QGIS MetaSearch plugin to improve support for OGC API — Records. MetaSearch is a core plugin that enables QGIS to act as a client application for interacting with metadata catalogue services.

Figure 3 — Screenshot of the demo of the MetaSearch plugin for QGIS

5.3.  Extension of the Testbed-17 Dataset testing (D166) prototype

For the code sprint, the maintainers of the Testbed-17 Dataset testing (D166) prototype experimented with use of ArcGIS and arcpy to offer an implementation of OGC API EDR. During the experimentation, the sprint participants identified an alternative way of defining the bbox query parameter in the YAML-encoded schema files provided with the OGC API EDR Standard. This would enable an OpenAPI documentation tool such as SwaggerUI to display a field for the query parameter.

Currently the bbox query parameter is defined as shown below:

        schema:
          oneOf:
          — maxItems: 4
            minItems: 4
            type: object
          — maxItems: 6
            minItems: 6
            type: object
          type: array

Figure 4

This results in the SwaggerUI presentation looking as shown in Figure 5 below.

Figure 5 — Current display of the bbox query parameter on SwaggerUI

The sprint participants suggested changing the definition of the bbox query parameter to the one shown below:

        schema:
          oneOf:
          — items:
              maxItems: 4
              minItems: 4
              type: object
            type: array
          — items:
              maxItems: 6
              minItems: 6
              type: object
            type: array

Figure 6

The change results in the SwaggerUI presentation looking as shown in Figure 7 below.

Figure 7 — Display of the bbox query parameter on SwaggerUI after the modification

5.4.  Extension of the Testbed-17 Dataset testing (D168) prototype

For this code sprint, the prototype’s support for OGC API — Records was reviewed.

The OSGeo pygeometa package is used to create the metadata for both the crawlable catalogue Record and individual object Records. The current implementation uses a fork of pygeometa with a new schema for the catalogue versus existing schema for the objects. It was tested whether the existing pygeometa schema could be adjusted to also satisfy the catalogue Record creation.

The maintainers of the prototype deployed catalogues with multiple objects, stored in an AWS S3 bucket, to test various options and support the discussion.

Figure 8 — Screenshot of part of a script from the Testbed-17 Dataset testing (D168) prototype

5.5.  CubeWerx CubeSERV

The participants from CubeWerx worked on their implementation of OGC API – Records and the interoperability with STAC. A screenshot from their prototype implementation is shown in the figure below.

Figure 9 — Screenshot of the CubeWerx CubeSERV demo

5.6.  Ecere GNOSIS Cartographer

Developers from Ecere supported the code sprint through provision of client-side and server-side implementations of various OGC API candidate and approved standards. Ecere demonstrated visualization of data accessed via OGC APIs through GNOSIS Cartographer.

Figure 10 — Screenshot of the Ecere GNOSIS Cartographer demo

Ecere also provided an instance of the GNOSIS Maps Server, which implements multiple OGC API candidate and approved standards. Other sprint participants were then able to interact with GNOSIS Maps Server to help build OGC API support in their client applications, for example leaflet.

5.7.  ZOO Project

The maintainers of ZOO Project worked on an extension of ZOO Project that enabled third party software to interoperate with an instance of ZOO Project. The third party software products integrated with ZOO Project during the code sprint included RabbitMQ and OSGeo MapServer.

Figure 11 — Screenshot of the landing page of an instance ZOO Project

5.8.  Integration with OSGeo MapServer

The integration with OSGeo MapServer made it possible for the results of a process that had been executed through the OGC API — Processes interface of ZOO Project to be automatically configured for display in an instance of OSGeo MapServer.

Figure 12 — Screenshot of an instance of MapServer interoperating with an instance of ZOO Project

5.9.  Integration with RabbitMQ

The integration with RabbitMQ made it possible to use the RabbitMQ product for invoking a process that is available through the OGC API — Processes interface of ZOO Project.

Figure 13 — Screenshot of the interface of RabbitMQ

5.10.  Geospatial Integrity of Geoscience Software (GIGS)

The Geospatial Integrity of Geoscience Software (GIGS) tests are the products of an initiative of the International Association of Oil & Gas Producers (IOGP) to provide tests for coordinate operations. GIGS datasets are available as CSV files on the IOGP-GIGS GitHub repository. The aim of the GIGS activity during this code sprint was to convert the CSV files into implementation-neutral executable tests. The Apache SIS project has been used for testing the tests, but those tests do not contain any dependency to SIS. Implementation-neutral tests can be realized by a web service, and efforts in this direction are already underway at IOGP. But implementation-neutral tests (or other services) can also be done through programming interfaces.

At the time of writing, the only programming language for which an OGC Standard API exists is the Java language (note: it does not imply that implementations must be in Java; an implementation can be in C/C++ with wrappers such as PROJ-JNI). A Python binding of GeoAPI is in development but not yet submitted to the OGC GeoAPI SWG for approval.

The executable tests are implemented as JUnit 5 tests and can be executed by any implementation of GeoAPI 3.0.1 Java interfaces. A future version may allow execution of any implementation of Python interfaces if those interfaces (after completion) are approved as an OGC standard. The tests can be either integrated in the test suite of a project (e.g. using Maven, but other build tools work as well), or be executed by a Graphical User Interface (GUI) shown below. When using the GUI, the user selects the JAR file of the library to test. The implementation entry points are automatically discovered using the standard java.util.ServiceLoader mechanism of the Java platform. Optional metadata such as implementation name and version are fetched from the standard MANIFEST.MF file bundled in the specified JAR file.

Figure 14 — Screenshot of GIGS test execution on Apache SIS library

Tests are configurable. Configuration options include:

• Whether names of objects (datum, CRS…) in the implementation are the names defined by EPSG.

• Whether the list of aliases for each object includes at least the aliases defined by EPSG.

• Whether dependencies (e.g. the datum in a CRS) also use the EPSG codes, names and aliases.

• Whether the implementation can still create objects that have been deprecated by EPSG.

• Whether the implementation has information about which version of a coordinate operation is used.

• And more…

Configuration options can be modified on a case-by-case basis in a project (not yet through the GUI). In the above screenshot, where a test was failing because a “Côte d’Ivoire” alias was missing, it would be possible to disable the alias check only for that particular CRS. When a test has some disabled checks, the green bar indicating a successful test becomes shorter.

GIGS tests are divided into series:

• Series 2200 tests the capability of an implementation to build various kinds of objects (datum, CRS, operation…) from EPSG codes, and checks that the object matches EPSG definitions.

• Series 3200 tests the capability of an implementation to build various kinds of objects from custom parameters (not necessarily matching an object from the EPSG database).

• Series 5100 tests various coordinate operations (including map projections) and checks that the implementation produces the expected values.

• Series 5200 tests various coordinate transformations (including datum shifts) and checks that the implementation produces the expected values.

• Series 5300, 5400 and 5500 tests operations with seismic and Wells data.

• Series 7000 checks that some deprecated objects are marked as such.

In this code sprint, we completed all Series 2200 tests. Series 3200 tests are available from GIGS version 1, but have not yet been ported to version 2. A little bit of time has been invested in making the GUI test runner more usable.

6.1.  OGC API — Records

The participants prototyped implementations of a static catalogue. The idea of a crawlable catalogue is that the catalogue can be created using static files in accessible locations and then to have records linked together. It is therefore more of a manifest or a register. This approach is useful for publishing metadata records on Cloud storage services such as Amazon S3. There was a discussion around having fixed various files in a crawable catalogue. It was agreed that it would be better for the Standards to only make a recommendation, and then allow the implementer to decide on what names to give to the files.

There was discussion about schemas, including around the nesting of the properties keys i.e. one provided by GeoJSON and the one provided by OGC API — Records. There was also a discussion around some of the structures of STAC, for example the STAC Catalogue. It was agreed that the STAC Catalogue structure is a useful structure that could inform the approach taken for OGC API — Records.

The participants discussed the challenge of identifying a profile or extension of GeoJSON through a media type, when the media type is not registered with IANA. This topic came about because of work undertaken during the code sprint to implement an Executable Test Suite for the EO Dataset Metadata GeoJSON (-LD) Standard (OGC 17-003r2). If a conformance class for the EO Data Metadata standard is specified in a future extension of OGC API — Records, then a way to identify the profile of GeoJSON requested by the client from the server would need to be specified.

6.2.  OGC API — Routes

There was discussion around the Route Exchange Model (REM). One of the observations made by sprint participants was that attaching the units of a value to a property name (e.g. length_m) could potentially lead to ambiguity (e.g. whether the _m stands for meters or miles).

Another observation was that assigning a value of Segment to a feature with a Point geometry could lead to confusion amongst implementers that use Graph databases to calculate routes. This is because in Graph theory Nodes are typically represented as points, and Edges are typically represented as lines.

There was a suggestion that a proposal should be submitted to the Google Summer of Code (GSOC) program for a project that implements OGC API — Records and/or the Route Exchange Model in the open source pgRouting extension of PostgreSQL/PostGIS.

6.3.  OGC API — Environmental Data Retrieval

Results of the extension of the Testbed-17 Dataset testing (D166) prototype led to a discussion with the editors of the OGC API — Environmental Data Retrieval standard and a Pull Request was created for updating the API definition files of the standard. It was noted that the modification might also be relevant to OGC API — Common.

6.4.  OGC API — Maps and OGC API — Common

One of the sprint participants, a contributor to Leaflet, observed that the implementation of OGC API — Maps that they were interacting with did not offer much attribution.

A summary of the issue recorded by the participants is below. The issue related to attribution on both the list of collections, and the metadata of a collection:

• Clarity is needed on whether attribution belongs to OGC API — Common — Part 1 (Core) or Part 2 (Geospatial Data). Currently it appears there can be an attribution field in either/both the list of collections (Part 1) or in the metadata of a specific collection (Part 2). Therefore, clarity is needed on what the behavior of a client should be — shall a client display attribution about the service, or only about the collections being displayed/used? Allowing attribution only in Part 2, or clarifying how the attribution in Part 1 would be displayed would solve this concern.

• Allowing servers to use any kind of HTML markup in the attribution field might be problematic due to three specific problems: <script>s, tracking pixels, and parsing. In a best-case scenario, an OGC API server might push some invisible tracking pixels to clients (an image linking to an invisible 1×1 pixel). While good-intentioned, this opens a rabbit hole of cookies and privacy concerns. Another concern is clients with no means of parsing HTML and building a document model about it. Using a specific format of markup will force clients to include a parser for that markup language. A similar concern would arise if another markup language would be used, e.g. markdown. The worst-case scenario would be an infosec attacker gaining a hold of an OGC API server, and changing the attribution field to include a <script> reference. That would be an attack vector to inject malware in any clients. Therefore, there appears not to be any scenario where allowing <script> as part of attribution might be useful.

6.5.  Editorial

The sprint participants also identified a number of editorial issues in draft specifications and recorded the issues for Standards editors to address. Examples include:

• References to example files of the draft OGC API — Records — Part 1: Core

• Use of the correct case in link relations in a draft future extension of OGC API — Routes

• Documentation in yaml files of the draft OGC API — Maps — Part Core

6.6.  Summary of Lessons Identified

The following are the immediate lessons identified by the sprint participants:

• There is concern about the format for presenting attribution of collections and collection metadata. There is a need for some compromise on the attribution format.

• The code sprints provide an opportunity for feedback from more developers within and outside of the OGC, ASF, and OSGeo communities.

• There is a need to always have a bbox response in the HTTP header, to help with determining the extent of the data returned.

• OGC API Standards offer an improved developer experience compared to the OGC Web Services suite of standards.

• The examples in OGC API Standards are absolutely key to helping developers to implement the standards.

• There is a frequently asked question of: What is the relationship between OGC API Records and STAC? There is a need for clear communications on what the relationship is and which standard to use where. There is a need to delineate these from both a communications and technical standpoint.

• There is a need to make OGC API Standards stand out.

• There is some similarity between STAC and some of the OGC API Standards. STAC also uses OGC API Features. The idea is to specify OGC API Records such that STAC can be a profile of OGC API Records.

• With some resources, it is not sufficient to record a link to a resource. For example, with a WMS there would be a need to parse the capabilities.

Whereas some of the lessons listed above might have implications for standards, others may have implications for developer guide documentation and similar resources. This highlights why conducting code sprints that involve open standards and open source software communities is critical for the uptake of standards.

7.1.  Future Work

The sprint participants made the following recommendations for future innovation work items:

• Prototypes of catalogues that can be crawled through by an application. Currently there are several searchable catalogues but not catalogues that can be crawled through by an application.

• More specification validation work for OGC API Records.

• More experiments for the Workflows extension of OGC API Processes. This could try out the various workflow approaches. https://github.com/opengeospatial/ideas/issues/115

• Experimentation on how a processing server can interact properly with other OGC API implementations that serve data. For example, in this code sprint there was an implementation of OGC API Processes (ZOO Project) that interacted with an OGC API Features implementation (MapServer).

• Experimentation with OGC’s geoparquet specification and Apache Arrow.

The sprint participants also made the following recommendations for things that the SWGs should consider:

• To improve examples and documentation related to OGC API Records.

• To advance the development of the Executable Test Suites of OGC API Processes.

• To advance the development of the Executable Test Suites of OGC API Tiles.

• To advance the development of the Executable Test Suites of OGC API Coverages.