4.1.1.  OGC API — Maps

The OGC API — Maps candidate Standard describes an API that can serve spatially referenced and dynamically rendered electronic maps. 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, defined by the client.

4.1.2.  OGC API — Styles

OGC API — Styles specifies building blocks for Web APIs that enable map servers and clients as well as visual style editors to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine on features and/or coverages. The API implements the conceptual model for style encodings and style metadata. The model defines three main concepts, namely the style, stylesheet, and style metadata. The concepts are explained below.

• The style is the main resource.

• Each style is available in one or more stylesheets — the representation of a style in an encoding like OGC SLD 1.0 or Mapbox Style. Clients can use the stylesheet of a style that fits the user’s needs best, based on the capabilities of available tools and their preferences.

• For each style there is style metadata available, with general descriptive information about the style, structural information (e.g., layers and attributes), and so forth to allow users to discover and select existing styles for their data.

4.1.3.  OGC API — Tiles

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

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 a large 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 a large area (e.g., a satellite image).

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

STAplus is an extension to the OGC SensorThings data model. 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.

4.1.5.  OGC Styled Layer Descriptor

The Styled Layer Descriptor (SLD) encoding standard defines an encoding that supports user-defined symbolization and coloring of geographic feature and coverage data. SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. SLD is often used in combination with the OGC Symbology Encoding Standard (SE).

4.1.6.  OGC Styles and Symbology

The OGC Symbology Conceptual Model: Core Part Standard (OGC 18-067r3), also known as OGC SymCore, specifies the conceptual basis to define symbology rules for the portrayal of geographical data. It is modular and extensible (one core model, many extensions), also encoding agnostic (one symbology model, many encodings). It contains a minimal set of abstract classes representing explicit extension points of the model.

OGC Styles and Symbology is a vision for a standard that implements the OGC Symbology Conceptual Model: Core Part Standard (OGC 18-067r3). The Web Mapping Code Sprint was a key moment to consolidate the roadmap to achieve this vision. The plan towards such a candidate SymCore 2.0 Standard consists of the definition of a conceptual and logical model, Cascading Style Sheets (CSS) and JavaScript Object Notation (JSON) encodings, as well as a mapping to SLD/SE (eventually with existing well known vendor options). The requirements described will be supported by illustrated and encoded cartographic use cases.

4.2.1.  Leaflet

Leaflet is a popular JavaScript library for displaying maps in web pages, created in 2011 by Volodymir Agafonkin and released under a BSD-2 license. It has a minimalistic architectural design in order to provide a small code footprint. As a result, any advanced or specific functionality is implemented by plugins.

Leaflet.ImageOverlay.OGCAPI is a Leaflet plugin implementing an OGC API — Maps client, and was created during a previous code sprint.

4.2.2.  ldproxy

ldproxy is an implementation of the OGC API suite of Standards, inspired by the W3C/OGC Spatial Data on the Web Best Practices. ldproxy is developed by interactive instruments GmbH, written in Java (Source Code), and is typically deployed using docker (DockerHub). In addition to supporting commonly used data formats for geospatial data, an emphasis is placed on an intuitive HTML representation.

The current version supports PostgreSQL/PostGIS databases, GeoPackages and WFS 2.0 instances as backends for feature data. MBTiles is supported for tilesets.

ldproxy implements all conformance classes and recommendations of “OGC API — Features — Part 1: Core” and “OGC API — Features — Part 2: Coordinate Reference Systems By Reference” and is an OGC Reference Implementation for the two standards. ldproxy also supports the OGC API — Records candidate Standard as well as the draft extensions of OGC API — Features (that is Part 3, CQL2, Part 4 and most of the current proposals discussed by the Features API Standards Working Group). ldproxy supports GeoJSON, JSON-FG, HTML, FlatGeoBuf, CityJSON, glTF 2.0 and the Geography Markup Language (GML) as feature encodings.

ldproxy also has implementations for additional resource types: Vector and Map Tiles, Styles, Routes, and 3D Tilesets.

ldproxy is distributed under the Mozilla Public License 2.0.

4.2.3.  Miramon Map Browser

The Centre for Ecological Research and Forestry Applications (CREAF) at the Autonomous University of Barcelona (UAB) deployed an instance of the MiraMon Map Browser which is available on the CREAF website and on GitHub. The MiraMon Map Browser is a web application for creating visualization and analysis solutions that run in modern web browsers. The browser uses HTML5, JavaScript, and supports OGC Standards such as OGC API — Tiles, Web Map Service (WMS), and Web Map Tile Service (WMTS). The JavaScript client is able to combine AJAX, binary arrays, the WMS/WMTS protocols, the OGC API — Maps candidate Standard and the OGC API — Tiles Standard. The MiraMon Map Browser has also been extended to support STAplus, an extension of the OGC SensorThings API Standard.

4.2.4.  OSGeo OWSLib

OWSLib is a Python client for OGC Web Services (OWS) and their related content models. The project is an OSGeo Community project and is released under a BSD 3-Clause License.

OWSLib supports numerous OGC Standards, including increasing support for the OGC API suite of Standards. The official documentation provides an overview of all supported standards.

4.2.5.  OSGeo pygeoapi

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

pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

4.2.6.  STAplus Viewer App by Secure Dimensions

The STAplus Viewer App is a proof-of-concept implementation of a web-browser application based on JavaScript (JS) and Leaflet. The implementation further leverages JS libraries from STAM (SensorThings API Map) developed by Datacove for INSPIRE.

The STAplus Viewer App is based on the Leaflet JavaScript library. It is however possible to base the application on OpenLayers. This alternative implementation is available from the COS4Cloud project. Even though it looks and feels slightly different, both implementations provide the same functionality.

4.2.7.  TEAM Engine

The Test, Evaluation, And Measurement (TEAM) Engine is a testing facility that executes test suites developed using the TestNG framework or the OGC Compliance Test Language (CTL). It is typically used to verify specification compliance and is the official test harness of the OGC Compliance Testing Program (CITE).

4.2.8.  OpenLayers

OpenLayers is a library for developing browser-based mapping applications. It works with vector and raster data from a variety of sources and is able to reproject data for rendering. The library has broad support for OGC protocols and formats, including WMS, WMTS, Web Feature Service (WFS), Well Known Text (WKT), Well Known Binary (WKB), Geography Markup Language (GML), GeoTIFF/COG, and KML. In addition, it has support for community and non-OGC standards such as GeoJSON, XYZ tiles, TileJSON, and more. OpenLayers is written in JavaScript and is available under the BSD 2-Clause license.

The ol/source/OGCMapTile module provides a source for map tiles from an OGC API – Tiles implementation. The ol/source/OGCVectorTile module provides a source for vector tiles from an OGC API — Tiles implementation.

4.2.9.  xyz2ogc

The xyz2ogc program supports the generation of OGC API – Tiles metadata from existing XYZ tilesets. The program is implemented in the Go programming language and the published module can be used in Go-based services that implement the OGC API – Tiles Standard.

4.3.1.  MariaDB CubeWerx CubeServ

The CubeWerx 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 (e.g., GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.

4.3.2.  Ordnance Survey Implementation of OGC API — Styles

Ordnance Survey (OS) works with a wide array of customers and partners across many industries in the United Kingdom and beyond. A key part of the current OS Roadmap is the suite of products to deliver the OS National Geographic Database (OS NGD). At the end of September 2022, OS launched the OS NGD API – Features product which implements Parts 1, 2, and 3 of OGC API — Features to provide access to data along with filtering capabilities to enable customers to retrieve just the data they need. During the code sprint, developers from OS focuses on implementation of the OGC API — Styles candidate Standard. The work at the code sprint complemented other OS activities that are implementing OGC API — Tiles.

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

4.3.4.  Hexagon Luciad RIA

LuciadRIA is a product that enables applications running in a web browser to offer 2D, 3D, or 4D visualization of satellite and other imagery, vector-based data and dynamic content, such as tracks. LuciadRIA can connect to implementations of OGC API Standards, as well as implementations of OGC Web Service standards.

5.2.1.  OGC API — Maps and OGC API — Tiles implementation

The GDAL library project implemented support for the OGC API — Tiles — Part 1: Core Standard and the OGC API — Maps — Part 1: Core candidate Standard.

This library capability enables support for those Standards in QGIS.

During the sprint, participants tested this capability and discovered that following the final edits to OGC API — Tiles — Part 1: Core, the GDAL functionality no longer worked with the latest implementations of the Standard. An issue was filed with GDAL about this problem https://github.com/OSGeo/gdal/issues/6832.

Several of the problems were quickly resolved by the GDAL maintainer. However, issues pertaining to changes in version 2.0 of the 2D Tile Matrix Set Standard remain to be addressed, for which a separate issue was filed: https://github.com/OSGeo/gdal/issues/6882.

In addition, participants noted that the QGIS interface to add an OGC API data source to a project is currently a very counter-intuitive hidden capability, requiring to select the “File” option from “Layer > Add Vector/Raster Layer” and prefixing an OGC API landing or collection URL by “OGCAPI:”. The sprint participants found that the procedure was nearly impossible for users to figure out by themselves. The sprint participants also noted that the procedure was not explained in the documentation. Participants suggested that a more intuitive “Layer > Add OGC API layer…​” menu item (covering all OGC API access mechanisms) be added to QGIS in a future version. Details were added to this QGIS issue about supporting OGC APIs: https://github.com/qgis/QGIS/issues/50296.

5.4.1.  OGC API — Tiles implementation

Leaflet has built-in support for map tiles (or “TileLayer”s), but its internal implementation has significant constrains: All TileLayers must share the same coordinate system, must be aligned to the same origin of coordinates, and all tiles in any given TileLayer must have the same pixel size.

The flexibility of OGC API - Tiles in regard to tile size and origin of coordinates presented a challenge for the Leaflet client implementation. The sprint participants discussed this challenge and reached consensus to ignore TileMatrixSets which do not have a constant tile size, or that do not have a common origin of coordinates for the (0,0) tiles.

5.4.2.  OGC API — Maps implementation

An instance of leaflet was configured to access an OGC API — Maps implementation from a MariaDB CubeSERV instance. The CubeSERV instance had been configured to offer an OGC API — Maps façade in front of a WMS that offered layers of the EuroRegionalMap of EuroGeographics. A screenshot of the leaflet instance is shown in Figure 6.

Figure 6 — Screenshot of leaflet accessing implementations of OGC API - Maps and OGC API - Tiles.

5.5.1.  OGC API — Tiles

The participants from interactive instruments GmbH updated the ldproxy implementation of OGC API — Tiles — Part 1: Core to support the released version 1.0.0 of the Standard. Specifically, the main updates are:

• updated conformance class URIs;

• removed tileMatrixSetDefinition member from the tile set metadata;

• added tiling-scheme links to the tile set metadata;

• added the Link-Template header for the tile URI template;

• added operationId to all OpenAPI operations (in addition to setting the operationId for all Tiles operations, operationIds have been added to all other API operations, too); and

• the member tileMatrixSetURI in a tile matrix set was changed to uri.

Work was also started during the Code Sprint to support the optional OATiles-hint header, but this requires more complex changes in various layers of the software and was not finalized during the Code Sprint.

In addition, several improvements to the Tiles building blocks were implemented and tested before and during the Code Sprint:

• For tiles from an MBTiles provider, additional information from the MBTiles container is used for the tile set metadata, including the vector layer and bounding box information; and

• harmonize the behavior of the map with tiles in the HTML representation of a tile set, independent of how the representation is configured (using a Mapbox Style, using feature data with a wireframe style, or using tiles from an MBTiles container).

All changes are included in ldproxy v3.3.0, which was released on December 16, 2022.

The ldproxy demonstration deployment at https://demo.ldproxy.net/ was updated with the changes. The deployment includes an API that serves an Ordnance Survey Zoomstack dataset through features, tiles and styles resources.

For example, below is the (shortened) tile set metadata for the Zoomstack vector tiles, including the HTTP headers of the response:

HTTP/2 200
content-disposition: inline; filename="WebMercatorQuad.json"
content-language: en
content-type: application/json
date: Fri, 16 Dec 2022 16:26:03 GMT
etag: W/"ed1c7a5750df7c526823056406274c6e--gzip"
link: <https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad?f=tilejson>; rel="alternate"; title="This document as TileJSON"; type="application/vnd.mapbox.tile+json"
link: <https://demo.ldproxy.net/zoomstack/tileMatrixSets/WebMercatorQuad>; rel="http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme"; title="Definition of the tiling scheme"
link: <https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad?f=json>; rel="self"; title="This document"; type="application/json"
link-template: <https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=mvt>; rel="item"; title="Mapbox vector tiles; the link is a URI template where {tileMatrix}/{tileRow}/{tileCol} is the tile in the tiling scheme '{{tileMatrixSetId}}'"; type="application/vnd.mapbox-vector-tile"
vary: Accept,Accept-Language,Accept-Encoding
x-request-id: 72c93630-2a72-4ec0-a58d-e883e5a93bf5

{
  "links" : [ {
    "rel" : "self",
    "type" : "application/json",
    "title" : "Dieses Dokument",
    "href" : "https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad?f=json"
  }, {
    "rel" : "alternate",
    "type" : "application/vnd.mapbox.tile+json",
    "title" : "Dieses Dokument als TileJSON",
    "href" : "https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad?f=tilejson"
  }, {
    "rel" : "http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme",
    "title" : "Beschreibung des Kachelschemas",
    "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets/WebMercatorQuad"
  }, {
    "rel" : "item",
    "type" : "application/vnd.mapbox-vector-tile",
    "title" : "Mapbox Vector Tiles; der Link ist ein URI-Template wobei {tileMatrix}/{tileRow}/{tileCol} die Kachel im Kachelschema '{{tileMatrixSetId}}' identifiziert",
    "href" : "https://demo.ldproxy.net/zoomstack/tiles/WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=mvt",
    "templated" : true
  } ],
  "dataType" : "vector",
  "tileMatrixSetId" : "WebMercatorQuad",
  "tileMatrixSetURI" : "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad",
  "tileMatrixSetLimits" : [ {
    "tileMatrix" : "0",
    "minTileRow" : 0,
    "maxTileRow" : 0,
    "minTileCol" : 0,
    "maxTileCol" : 0
  }, ..., {
    "tileMatrix" : "13",
    "minTileRow" : 2343,
    "maxTileRow" : 2784,
    "minTileCol" : 3886,
    "maxTileCol" : 4157
  }, {
    "tileMatrix" : "14",
    "minTileRow" : 4686,
    "maxTileRow" : 5569,
    "minTileCol" : 7772,
    "maxTileCol" : 8314
  } ],
  "boundingBox" : {
    "lowerLeft" : [ -9.2230281, 49.8211737 ],
    "upperRight" : [ 2.6891998, 60.7781954 ],
    "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
  },
  "centerPoint" : {
    "coordinates" : [ -3.2835, 58.6359 ],
    "tileMatrix" : "10"
  },
  "layers" : [ {
    "title" : "sea",
    "id" : "sea",
    "dataType" : "vector"
  }, {
    "title" : "names",
    "id" : "names",
    "dataType" : "vector",
    "propertiesSchema" : {
      "properties" : {
        "name2language" : {
          "type" : "string"
        },
        "type" : {
          "type" : "string"
        },
        "name2" : {
          "type" : "string"
        },
        "name1" : {
          "type" : "string"
        },
        "name1language" : {
          "type" : "string"
        }
      },
      "type" : "object"
    }
  }, {
    "title" : "rail",
    "id" : "rail",
    "dataType" : "vector",
    "propertiesSchema" : {
      "properties" : {
        "type" : {
          "type" : "string"
        }
      },
      "type" : "object"
    }
  }, ..., {
    "title" : "airports",
    "id" : "airports",
    "dataType" : "vector",
    "propertiesSchema" : {
      "properties" : {
        "name" : {
          "type" : "string"
        }
      },
      "type" : "object"
    }
  }, {
    "title" : "woodland",
    "id" : "woodland",
    "dataType" : "vector"
  }, {
    "title" : "national_parks",
    "id" : "national_parks",
    "dataType" : "vector"
  }, {
    "title" : "urban_areas",
    "id" : "urban_areas",
    "dataType" : "vector"
  }, {
    "title" : "surfacewater",
    "id" : "surfacewater",
    "dataType" : "vector"
  } ]
}

Screenshots of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b) are shown in Figure 7.

Figure 7 — Screenshot of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b)

5.5.2.  OGC API — Styles

The ldproxy demonstration implementation of OGC API — Styles was updated with additional styles during the code sprint. The demo server provided a reference for other participants to validate their implementations by. A screenshot of a listing of styles offered by the ldproxy demo is shown in Figure 8 (a) and metadata about a single style, derived from the information in the style, is demonstrated in Figure 8 (b).

Figure 8 — Screenshot of the listing of styles offered by the ldproxy demo (a) and style metadata (b)

Figure 9 shows a map using the MapLibre JS library with a style from the API which accesses the Zoomstack vector tiles from the Tiles resources of the same API and hillshade coverage tiles from an Ordnance Survey server.

Figure 9 — Screenshot of a map with the Zoomstack style "Outdoor" with additional hillshades

5.6.1.  Contribution

The sprint participants from Hexagon, Robin Houtmeyers and Tom Crauwels, divided their efforts between the server side and the client side. On the server side they integrated OGC API — Tiles as a possible service option in LuciadFusion Studio. On the client side they created a prototype connector for the OGC API —  Maps candidate Standard and the OGC API — Tiles Standard in LuciadRIA and integrated the connector into the LuciadRIA Data Formats sample. More developer-focused information such as documentation, API reference, samples, videos, etc can be found on https://dev.luciad.com/ .

5.6.2.  Server side with LuciadFusion

LuciadFusion provides an all-in-one server solution for geospatial data management. At its core is an API that can be used to develop custom server solutions. It ships with LuciadFusion Studio, an out-of-the-box web frontend application developed on top of that API, that lets an end-user manage data intelligently, store and process a multitude of data formats and feed data to multiple applications. A demonstration video can be found here.

The sprint participants from Hexagon started from an earlier prototype that could offer data through an OGC API — Tiles interface. The goal of the earlier prototype was a proof of concept, a document that explains how to add support for OGC API — Tiles and a rough estimate of the workload. Since OGC API — Tiles is defined using the OpenAPI specification, the OpenAPI specification and the tool OpenAPI Generator could be used to generate domain models and REST controllers (for example: Spring controllers). 

During this sprint, that earlier prototype was integrated into LuciadFusion Studio as a proof of concept. This means that after adding or crawling data, it could be published as a service that implements OGC API — Tiles, as illustrated in Figure 10, next to existing services such as WMS, WMTS, etc. This functionality was demonstrated in a short video with sample data downloaded from Ordnance Survey’s OS Data Hub.

Figure 10 — Dialog for adding a layer from an OGC API - Tiles instance to LuciadFusion

Note: this is still work in progress; there is no out-of-the-box LuciadFusion prototype with OGC API support available yet. 

5.6.3.  Client side with LuciadRIA

5.6.3.2.  Capability parsing

Many of the new OGC API Standards offer a central overview of all data sets available on a server in JSON (or xml, html) at a “collections” URL. This central overview offers links to specific collections (with a unique ID) which in turn can offer links to maps, tiles, styles, etc. An overview from the GNOSIS Map Server:

/ogcapi/collections/{collectionID}(collection description)
/ogcapi/collections/{collectionID}/tiles(vector tiles)
/ogcapi/collections/{collectionID}/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual vector tile)
/ogcapi/collections/{collectionID}/map/tiles(map tiles)
/ogcapi/collections/{collectionID}/map/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual map tile)
/ogcapi/collections/{collectionID}/coverage/tiles(map tiles)
/ogcapi/collections/{collectionID}/coverage/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual coverage tile)
/ogcapi/collections/{collectionID}/items(vector features)
/ogcapi/collections/{collectionID}/coverage(coverage)
/ogcapi/collections/{collectionID}/map(map)
/ogcapi/collections/{collectionID}/styles/{styleId}/map(styled layer map)
/ogcapi/map(dataset map)
/ogcapi/styles/{styleId}/map(styled dataset map)
/ogcapi/tileMatrixSets/{tileMatrixSetId}(individual tiling scheme)

In the Data Formats sample, the team created a ConnectToOGCAPIMapsWizard and added it to the ConnectToModal. This wizard creates an OGCAPIMapsCapabilities object after connecting to a valid URL, which contains a collection of OGCAPIMapsCapabilitiesLayer objects, one for each collection available. Figure 11 shows a list of collections retrieved by a LuciadRIA web application from an OGC API — Maps instance. Finally, an OGCAPIMapsLoader is used to create a model and layer that LuciadRIA can use to load and visualize the data.

Figure 11 — List of collections retrieved by LuciadRIA from an OGC API - Maps instance

5.6.3.5.  Reprojecting

One of the core strengths of the Luciad portfolio is that it can be used to connect to and visualize data in any format or projection. LuciadRIA can even utilize the power of the GPU through WebGL to project data on-the-fly, such as imagery and vector data, to any known projection and visualize it as such. To demonstrate this, the team added another menu option in the sample to switch to different projections. Figure 12 shows a representation of a map retrieved in the EPSG:4978 coordinate reference system. Figure 13 shows a menu for selecting different coordinate reference systems. Figure 14 shows a representation of a map retrieved in the EPSG:27700 coordinate reference system. In sequence, these three screenshots demonstrate the ease of switching between different coordinate reference systems in LuciadRIA.

Figure 12 — Display of a map retrieved in EPSG:4978

Figure 13 — Dialog to select a coordinate reference system

Figure 14 — Display of a map retrieved in EPSG:27700

Next to some predefined options such as 3D, CRS84, WebMercator and a projection requested by another participant (British National Grid projection (EPSG:27700)), the team also added the option to load any projection known to LuciadRIA. To minimize the size of a LuciadRIA application, not all projections are available in it out of the box. However, other projections can be added as WKT (Well Known Text)) by its identifier, which in most cases will be an EPSG code. If LuciadRIA does not know this code, it will automatically try to request it from an external service that provides definitions of projections. After getting the WKT, the application can be restarted in the new projection and any subsequently loaded data will be reprojected into that projection.

5.6.4.  Resources

The LuciadRIA demonstration sample (= extended Data Formats sample) is available online:

https://demo.luciad.com/OGCAPIClient/?webgl&reference=epsg:4978

Using the ‘Connect To’ button at the bottom, an end-user can add connections to servers that implement OGC API — Maps.

The video created, showcasing the LuciadFusion integration, can be found here.

Servers, from other participants, used by LuciadRIA during the sprint are listed below:

GNOSIS Map Server: https://maps.gnosis.earth/ogcapi/
CubeServ: https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/EuroRegionalMap

5.7.1.  OGC API – Maps and support for Map Tiles

To begin with, the source code was overhauled to update the implementation to the approved version of OGC API — Tiles and the current draft version OGC API — Maps. A working instance of the MiraMon Map Browser was prepared showing collections from multiple providers, as demonstrated in Figure 15.

Figure 15 — Screenshot of the MiraMon Map Browser with a combination of several collections (or layers) in the same client using different OGC protocols and APIs, like WMS, WMTS, OGC API - Maps, OGC API - Tiles, and SensorThings API

After that, the work focused on having a full implementation of the OGC API - Maps candidate Standard in the MiraMon Map Browser to enable end-users to add collections from external servers. The map client is able to establish a connection with a server from the information provided by the landing page. The map client inspects the information and then follows the links, making the necessary requests to obtain a list of available map collections and their main characteristics.

As shown in Figure 16, the interface allows users to indicate the landing page of the service that should be explored. Once explored, it displays a list of available map collections and allows users to select the collection or collections to add as layers in the legend and the map display. The selected layers are added to the map display as demonstrated in Figure 17.

Figure 16 — Screenshot of the first step of the process for adding collections to the client from a OGC API - Maps compatible landing page prepared by Cubewerx

Figure 17 — Screenshot of the EuroGeographics map served by the Cubewerx API.

Finally, the focus of the work shifted to connecting to map collections retrieved from OGC API - Tiles implementations so that an end-user could add tiled maps to the client. The work consisted of obtaining the tiled description and the list of tiled maps available in a service from the landing page. The work was more extensive than the team had anticipated and in the process of an in-depth review of the Standard, some difficulties were encountered to properly understand some aspects. A suggestion for incorporating more coding examples in some of the requirements classes was made.

5.7.2.  OGC Sensor Things API implementation

When working with a large amount of citizen data accessible through an implementation of the SensorThings API Standard, the performance of a client application can be adversely impacted. In particular, trying to request the necessary data to present a map with a large number of features of interest can be a very slow and inefficient process. To address this issue, two approaches for tessellation of the data were tested during the code sprint and other approaches were proposed.

5.7.2.2.  A client-side implementation

A client-based tessellation solution was implemented that addressed the situation of a server that offers a significant number of vector objects, whether those objects represent features, sensors, or their observations. This approach required implementation of two capabilities directly in the client side: a tile matrix set and a “pre-fetch” SensorThings API request for the number of features in a tile.

By defining a tile matrix set with several zoom levels on the client-side, parallel tiled requests based on this division can be sent to the server by specifying the bounding box of each tile without changing anything in the Standard or the server implementations. In addition, only the tiles with a number of objects below a threshold would be completely requested.

MiraMon was configured to issue a request for each STA tile twice, the first request is for getting the count (i.e., number of features of interest in a tile), and then the second request is for getting the actual features of interest. The number of features of interest is requested from the STA server in a prefetch request. If the count of the features in the “tile” requested is greater than the threshold, then the number of features of interest is represented in the center of the tile with the presentation of the number of objects in each tile. Otherwise, the full description of the features of interest in the tile is requested and each feature of interested is represented in the screen. This approach is proposed by the STAM library and it has been implemented from scratch in the MiraMon Map Browser using the same principles.

Figure 18 — Screenshot of the MiraMon Map Browser requesting some tiles with the count of features of interest represented as big circles and others with the features of interest represented as small red dots. In addition, the information related to a particular observation is shown, including a picture.

Figure 19 — Screenshot of the MiraMon Map Browser showing the URLs requested for each tile where the each bounding box can be seen expressed in WKT as a polygon.

5.7.2.3.  A server-side implementation

Secure Dimensions contributed to the code sprint through a server-side implementation of a mechanism for creating tiles of observations. In this case, an OGC API - Tiles implementation is used as a facade for STA. The server implementing the OGC API - Tiles, renders the STA observation in PNG on-the-flight that is immediately delivered to the client. The MiraMon Map Browser is used as a client for this approach in order to visually verify that both server-side and client-side tiles generate the same view. Further work is needed to evaluate which of the two approaches could be more efficient in concrete use cases.

Figure 20 — Screenshot of the MiraMon Map Browser comparing the response of the the Secure Dimensions OGC API - tiles facade (bottom, represented as black dots) with a STA with the client side tile approach (top, represented as red dots) as described in the previous subsection. Spatial concordance between the position of the features of interest is checked.

5.13.1.  OGC API — Maps implementation

The pygeoapi project implemented support for the OGC API — Maps — Part 1: Core candidate Standard. Support for the Requirements Class “Map Core” was implemented, reviewed and approved by the pygeoapi development team. As a result, pygeoapi implementations are now able to easily publish geospatial data as dynamic maps thanks to the building block approach of OGC API Standards.

pygeoapi’s plugin architecture facilitated the implementation of two plugin backends for maps:

• MapScript: using the MapServer web mapping engine as the map renderer, using data and styling definitions (Styled Layer Descriptor [SLD], MapServer CLASS configuration files); and

• WMSFacade: a bridge/mediator to expose existing OGC WMS 1.3 services via OGC API — Maps

The official pygeoapi documentation provides more information on how to enable the new functionality. A screenshot of the associated OpenAPI/Swagger interface from the implementation is shown in the figure below.

Figure 23 — Screenshot of the pygeoapi OGC API - Maps MapScript plugin

Figure 24 — Screenshot of the pygeoapi OGC API - Maps WMSFacade plugin

Figure 25 — Screenshot of the pygeoapi OGC API - Maps interface via OpenAPI/Swagger UI

Figure 26 — Screenshot of the pygeoapi OGC API - Maps WMSFacade using the Open Maps for Europe WMS from Eurogeographics

5.13.2.  OGC API — Tiles updates

5.13.2.1.  Tile Metadata

Support for the Tile Set Metadata schema has been added to TileJSON MapBox. It is also possible to support any format by adding a JSON metadata file directly into the filesystem. As well, the absence of metadata does not represent an issue, facilitating support for different tiles providers.

Figure 27

5.13.2.2.  Vector tiles URL templates

The pygeoapi team added support for rendering vector tiles retrieved from an OGC API — Tiles implementation from a third-party service, using a generic URL template. One use case for this functionality would be to stream elasticsearch vector tiles, which are provided in elasticsearch >=8, as OGC API — Tiles.

Figure 28 — Screenshot of pygeoapi OGC API - Tiles using the Elasticsearch vector tiles

Users could also use this functionality to render pg_tileserv vector tiles, or any other service which uses format {z}/{y}/{x} or {z}/{x}/{y}

Figure 29 — Screenshot of pygeoapi OGC API - Tiles connecting to a pg_tileserv vector tiles service

5.13.3.  OGC API — Coverages browser rendering

Through a lightweight HTML viewer, the team added HTML representation of coverages to pygeoapi. This viewer is a Leaflet implementation, which uses the Leaflet.ImageOverlay.Arrugator plugin, and the proj4js library to provide client-side reprojection. Whenever a web browser visits a /coverage path on pygeoapi, the web browser sends an Accept: text/html header which triggers pygeoapi to respond with the lightweight coverage viewer.

Figure 30 — Screenshot of pygeoapi lightweight coverage viewer

The emphasis is not in the viewer, but rather in the fact that the viewer is the HTML representation of the coverage resource. Whenever an API client requests the coverage resource, it will be given an HTML map viewer, or the JSON-LD representation of the coverage, or the raw coverage data (as PNG, GeoTIFF, NetCDF, etc), in accordance with the established HTTP content negotiation rules (“Accept” HTTP headers, or “f” URL parameter).

This is aligned with pygeoapi’s implementation of OGC API — Features, where requesting features as HTML returns a map viewer loaded with those features.

5.13.4.  Mentor session

A pygeoapi mentor session was provided in support of delivering vector tiles using pygeoapi. The session focused on:

• installation

• overview of various endpoints and creating a standard source

• creating vector tiles

• serving vector tiles

• reading vector tiles from different clients

5.13.5.  Developer outreach

Members of the pygeoapi development team discussed project participation and contributions with various developers at the sprint.

5.15.1.  OGC API – Tiles updates

A previous OpenLayers release had ‘experimental’ support for rendering tiles from OGC API – Tiles implementations. This was added prior to the OGC API – Tiles Standard being finalized.

During the sprint, the implementation was tested against services conforming to the Tileset conformance class. Changes were proposed to graduate the source classes for rendering vector and map tiles from ‘experimental’ to ‘stable’. These changes were approved, and the classes will be part of the OpenLayers API in the next release.

Figure 33 — Map tiles from an OGC API – Tiles service in OpenLayers

Figure 34 — Vector tiles from an OGC API – Tiles service in OpenLayers

5.16.1.  Findings

The OGC API – Tiles Standard makes it easy for existing XYZ tilesets to conform with the Core requirements. This is possible as long as the service provides some way for the tile URL template and the meaning of the variables in that template to be obtained.

Since many existing XYZ tilesets do not have a formalized way for clients to obtain the tile URL template or to understand the meaning of the variables, it makes sense for tile providers to “upgrade” their services by conforming with the Tileset requirements.

In practice, conforming with the Tileset requirements means hosting two metadata documents for a single XYZ tileset: one providing the tileset metadata and one describing the tiling scheme. This can be reduced to a single document for the tileset metadata linking to an existing document hosted elsewhere that describes the tiling scheme.

It would be more convenient if OGC Standards were developed in a way that URIs for things like CRS or TileMatrixSet resolved to definitions of those resources. This could be implemented through Content Negotiation, as proposed by Issue#124 on the OGC Naming Authority GitHub repository. For example, it would be convenient if the WebMercatorQuad URI resolved to the definition for this tile matrix set. This would allow the tiling scheme for a tileset to be specified with the tile matrix set URI alone, and clients could reliably fetch the definition from this. Unfortunately, it is not enough for the OGC URIs to redirect to a different resource providing this content. A browser-based client served via the HTTPS protocol will not fetch the OGC URI unless it is served via HTTPS (to avoid mixed active content violations) and it is served with Cross-Origin Resource Sharing (CORS) headers.

Suggestion: If in the future OGC URI 1) used the HTTPS scheme, 2) resolved to useful resources, and 3) were served with CORS headers, it would make browser-based client implementations easier.

For services providing more than a single tileset, it makes sense to conform to the Tileset List requirements. Having conformed with the Tileset requirements, it is mostly straightforward to conform to the Tileset List requirements by providing a document that lists the metadata (or a subset of the metadata) for each tileset. In the case of a static server, requirement 9 adds a small additional burden on implementers. The specification requires that the URL for the list of tilesets ends with /tiles. In many cases, static servers determine the content type for a response based on a document extension. For example, a common pattern is to have an index.html document that the server will provide in response to a request that matches a directory location (e.g., https://example.com/path/to/directory/). The same can be done for an index.json document with a list of tilesets as long as the service can be configured to treat index.json files as the “default” document. The additional potential complication is that the service may need to be configured to redirect a slash-less URL (e.g., https://example.com/path/to/tiles) to a URL ending in a slash (e.g., https://example.com/path/to/tiles/) so that the default document will be served.

Suggestion: If there is not a real benefit to requiring that the tileset list URL ends with /tiles, perhaps a future version of the Standard could relax or remove this requirement.

In addition to the Tileset, Tileset List, and associated TMS conformance classes, the xyz2ogc program implements a few of the conformance classes from OGC API – Common, namely Core, JSON, and OpenAPI 3.0. However, xyz2ogc chose not to implement the additional requirements from the OGC API – Tiles OpenAPI 3.0 conformance class. In particular, the requirements related to homogenous collections of tilesets (e.g., not including vector tiles in a list that includes map tiles) didn’t match the design of the project (a single listing of tilesets that may include both vector and map types). A client capable of rendering both vector and map tiles can make this distinction invisible to users, and the idea with the xyz2ogc program is to provide users with a list of tilesets to choose from – dividing those into multiple lists based on tile content type seems arbitrary and a bit awkward.

Suggestion: In the future, it could be useful if the Standard allowed for linking to tilesets lists of mixed types.