May 2021 OGC API Code Sprint Summary Engineering Report

For the OGC Innovation Program, the sprint participants identified a need to:

OGC Innovation Program activities rely on sponsorship to resource initiatives. Therefore, the potential activities listed above will be presented to the OGC Technical Committee through the Architecture Domain Working Group in order to raise interest from potential sponsors.

For the OGC Standards Program, the sprint participants identified a need to:

The OGC API - Maps and OGC API - Tiles Standards Working Groups will be tasked with specifying requirements for the legend and info conformance classes. Once the requirements have been specified, there may be a need to conduct further experimentation focusing on implementations of the legend and info conformance classes.

NRCan is a part of the Federal Government of Canada. NRCan is mandated to ensure the sustainable development of Canada’s natural resources, allowing the department’s work to explore energy, minerals and metals, forests, earth sciences, mapping, and remote sensing. Geospatial data plays a key role in all of the aforementioned areas, hence NRCan’s interest in the development of OGC APIs. As the NMA of Canada, NRCan plays a critical nation-wide role in the distribution of authoritative geospatial data products, including cartographic products such as maps.

There are specific priorities that drive what NRCan would like to see from OGC APIs. These include for example: climate change, response to disasters/extreme events, the Arctic, trade, sovereignty, and Indigenous reconciliation. The government has a strong desire to have collaboration and innovation within government processes in order to benefit Canadian society broadly. Innovation provides a bridge between the government’s internal focus areas and how these will apply within Canada and its position in the world. So, indeed, all the OGC APIs that are being developed through this sprint will, in the future, help to benefit society.

OGC APIs have a substantial role to play in the future of NMAs. At NRCan, this role is likely to involve the development and provision of microservices in order to support the delivery of geospatial data, maps and analytics. This role can be described in terms of the following needs:

For demonstration purposes, Sprint participants were encouraged to publish specific data and maps through OGC APIs for the following Areas of Interest (AOI):

Europe: The area around Bournemouth, England, within the extent specified by this GeoJSON file or this WKT string in EPSG:4326 coordinates POLYGON -2.13384466616954 50.5343261657655,-2.14712951953212 50.822458640394,-1.77636133932212 50.8243659606517,-1.75884948716236 50.539699354356,-2.13384466616954 50.5343261657655.

North America: Red River of the North, within the extent specified by this GeoJSON file or this WKT string in EPSG:4326 coordinates POLYGON -97.8656275465241 50.1994331527875,-97.8290574091464 48.9215621457706,-96.475962326173 48.9305725567791,-96.4851048605174 50.2082107872824,-97.8656275465241 50.1994331527875.

The datasets that were recommended for the code sprint included:

The draft OGC API - Maps standard describes an API that presents maps portraying data that has been rendered according to a style. The maps served by implementations of the draft OGC API - Maps standard are retrieved as images of any size, generated on-the-fly, and with the styling determined by the client application. The draft standard can be considered the successor to the widely implemented WMS standard. The draft OGC API – Maps standard is a multipart standard that includes a Core (Part 1) and extensions that are planned to be developed in the future.

The draft OGC API - Tiles standard describes an API that implements the OGC Two Dimensional Tile Matrix Set (TMS) standard to enable access to tiled resources on the Web. The TMS standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix) for a limited list of scales in a CRS. The draft OGC API – Tiles standard is a multipart standard that includes a Core (Part 1) and extensions that are planned to be developed in the future.

OGC API - Styles describes the interface and exchange of styling parameters and instructions. The construction of symbology components of styles is addressed in the OGC Symbology Conceptual Model: Core Part standard and multiple OGC and other style encoding standards.

The CubeWerx server ("cubeserv") supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g. GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems. At the time of publishing this engineering report, the CubeSERV OGC API - Features Server product is certified OGC compliant to the OGC API - Features - Part 1: Core standard. A screenshot of the landing page of a CubeSERV instance from a demonstration of the product during the code sprint is shown in Figure 2.

Another screenshot of the CubeSERV instance, showing an HTML view of the API definition, is shown in Figure 3.

The cubeserv product is implemented in C and currently implements the following OGC specifications:

During this code sprint, CubeWerx helped fine-tune and mature several aspects of the OGC API Maps, Tiles and Tiles specifications, and refined its implementation accordingly.

EarthPulse is a Small-to-Medium-sized Enterprise (SME) which operates within the fields of data engineering and data analytics. Its staff are experts in the areas of data analytics, full-stack development, Big Data, product development and access, management and processing of data sources such as geospatial or textual data.

EarthPulse is committed to Free and Open Source software (FOSS) and open standards.

@doublebyte1 and @PascalLike participated in this sprint.

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API specifications. Multiple encodings are supported including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds or 3D meshes), GeoTIFF, GeoJSON, Mapbox Vector Tiles and MapML. An experimental server is available online at https://maps.ecere.com/ogcapi and has been used in multiple OGC Innovation Program initiatives. At the time of publishing this engineering report, the GNOSIS Map Server 1.0 product is certified OGC compliant to the OGC API - Features - Part 1: Core standard.

During the code sprint, Ecere loaded high resolution digital terrain model data provided by Natural Resources Canada for the Red River, Manitoba area of interest onto the experimental map server, including both 1-meter and 2-meter resolution. The API allows to retrieve coverages, maps and tiles (both coverage and map tiles) of this dataset, for which a style was also prepared and made available through the Styles API.

A screenshot of a Collection page for this dataset deployed on a GNOSIS Map Server instance is shown in Figure 6.

Ecere also demonstrated visualizing data accessed via OGC APIs through GNOSIS Cartographer. A screenshot of GNOSIS Cartographer used to visualize the Red River HRDEM is shown in Figure 7.

Developers from Ecere worked on implementing support for the styles management conformance class of OGC API - Styles in GNOSIS Map Server, which will allow authenticated users to create, update and delete style resources.

Support for the new attribution field in the resources describing collections of geospatial data was also implemented in the server.

Additionally, the Tiles API implementation of the GNOSIS Map Server was updated to reflect the latest development of the TileMatrixSet and TileSet metadata specifications, including a transition to JSON Schema to describe the vector features properties.

For this code sprint, the GNOSIS Map Server instance deployed for the sprint was configured to offer an endpoint supporting:

GeoSolutions deployed an instance of the GeoServer product. GeoServer is a Java-based software server that allows users to view and edit geospatial data. Using open standards by the OGC, GeoServer allows for great flexibility in map creation and data sharing. For this code sprint, the server was configured to offer an endpoint supporting:

The development focused on updating the OGC API - Tiles implementation to the latest evolution of the spec, as well as setting up a permanent demonstration server for OGC API implementations

ldproxy is an implementation of the OGC API family of specifications. ldproxy is developed by interactive instruments GmbH, written in Java (Source Code) and is typically deployed using docker (DockerHub). The software originally started in 2015 as a Web API for feature data based on Web Feature Service (WFS) 2.0 capabilities, inspired by the W3C/OGC Spatial Data on the Web Best Practices. In addition to the JSON/XML encodings, an emphasis is placed on an intuitive HTML representation.

The current version supports WFS 2.0 instances as well as PostgreSQL/PostGIS and GeoPackage databases as backends. It implements all conformance classes and recommendations of "OGC API - Features - Part 1: Core" and "OGC API - Features- Part 2: Coordinate Reference Systems By Reference", as well as other draft extensions (including Part 3 and Part 4 of OGC API Features). ldproxy also has draft implementations for additional resource types from OGC API Tiles and OGC API Styles). At the time of publishing this engineering report, the ldproxy 2.0 product is certified OGC compliant to the OGC API - Features - Part 1: Core standard and is one of the Reference Implementations of the standard.

For this code sprint, the server was configured to offer an endpoint supporting:

A screenshot showing the landing page of an ldproxy instance during the code sprint is shown in Figure 8. The instance had been configured before the sprint to serve OS Open Zoomstack vector tiles, OS Open Zoomstack styles and OS Open Zoomstack features through an API conforming to OGC API - Styles and OGC API - Features. The instance also supported the capability to create, update and delete styles and their metadata.

A screenshot of the HTML version of the API definition of the ldproxy instance is shown in Figure 9.

During the sprint, ldproxy has been updated to implement the latest drafts of OGC API - Tiles and the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata specifications. This includes changes that were agreed among the participants during the sprint.

The Meteorological Service of Canada (MSC) is a federal department of the Government of Canada. MSC works in close collaboration with NRCan to align national spatial data infrastructure activities in support of providing data to Canadians, as well as in meeting Canada’s international commitments with the UN World Meteorological Organization (WMO).

MSC provides weather, climate, and water data via its MSC GeoMet API platform, which offers both first generation OGC Web Services (WMS, WCS) as well as OGC API standards (OGC API - Features, OGC API - Processes).

MSC’s participation in the sprint is driven by the need for lowering the barrier to entry to weather/climate/water data for both existing and new information communities as well as the mass market. The OGC API efforts are well positioned to extend the reach of MSC data, and the availability of implementations further helps with this goal.

MSC’s evolving OGC API offerings are provided using the pygeoapi product - an open source Python server implementation of the OGC API suite of standards. The product supports the microservices approach and allows for scalability and cloud friendly deployment. At the time of publishing this engineering report, the pygeoapi 0.9.0 product is certified OGC compliant to the OGC API - Features - Part 1: Core standard, and additionally implements the following standards:

During the sprint, MSC deployed an instance of pygeoapi and worked with OSGeo colleagues from GeoCat BV and Geobeyond Srl to implement an endpoint supporting the abovementioned standards, as well as the following feature enhancements developed during the sprint:

MSC also collaborated with Ecere in testing and updating OGC API - Tiles support in pygeoapi to align with recent iterations of the specification.

A screenshot from a demonstration of a pygeoapi instance during the code sprint is shown in Figure 10.

The resulting work can be found in a pygeoapi feature branch. The work will continue to evolve as the OGC API - Maps and OGC API - Styles specifications evolve.

During the code sprint, MSC also extended the Python OWSLib client library to support OGC API - Maps and OGC API - Styles. The resulting work will continue to evolve with specification development.

Finally, MSC raised support of dimensions in OGC API - Maps as a discussion in the context of MetOcean requirements.

The Open Source Geospatial Foundation (OSGeo) is a not-for-profit organization whose mission is to foster global adoption of open geospatial technology by being an inclusive software foundation devoted to an open philosophy and participatory community driven development. The foundation consists of projects that develop open source software products. Multiple OSGeo projects and community projects participated in the sprint, for example GeoServer, pygeoapi and OWSLib.

The Centre for Ecological Research and Forestry Applications (CREAF) is a public research institute created in 1987 and located in Catalonia. It is part of the Autonomous University of Barcelona (UAB). CREAF deployed an instance of the MiraMon Map Server. The MiraMon Map Server is a CGI application encoded in C language that is part of the MiraMon Geographic Information System (GIS) & Remote Sensing (RS) suite. The software originally started 10 years ago as a WMS server in support of the Catalan Administration and CREAF data services. Currently the server implements WMS, WMTS and partially implements WFS and WCS. It also partially implements the OGC Sensor Observation Service (SOS) standard. It also includes prototype support for the draft OGC API - Maps and OGC API - Tiles specifications. In order to perform efficiently, it requires a process preparing the data to be offered. The server can interoperate with other vendors' clients. When combined with the MiraMon Map Client, the server offers additional functionality, including functionality recently developed for the Catalan Data Cube. The MiraMon Map Client is built using client-side JavaScript and can therefore run on any web browser.

Sprint participants from the Defence Science and Technology Laboratory (Dstl) took the lead in preparing an initial draft version of a Quick Start Guide for OGC API - Styles. The guide is intended to focus a developer on the API’s capabilities in order to increase a developer’s understanding of the API and to help them get started. The guide identifies a number of use cases, key concepts, resources and provides examples.

The sprint participants considered what the APIs will do to help meet the needs of NMAs. The following is a summary:

For the OGC Innovation Program, the sprint participants identified a need to:

OGC Innovation Program activities rely on sponsorship to resource initiatives. Therefore, the potential activities listed above will be presented to the OGC Technical Committee through the Architecture Domain Working Group in order to raise interest from potential sponsors.

For the OGC Standards Program, the sprint participants identified a need to:

The OGC API - Maps and OGC API - Tiles Standards Working Groups will be tasked with specifying requirements for the legend and info conformance classes. Once the requirements have been specified, there may be a need to conduct further experimentation focusing on implementations of the legend and info conformance classes.

The OGC API - Styles Standards Working Group will resolve all issues related to the specification that were raised during the sprint.