I. Executive Summary
The mechanisms through which maps are delivered across the Internet have evolved significantly over the past two decades. Advancement of such mechanisms has been driven by a combination of factors, for example, new data formats have emerged, the SWaP-C (size, weight, power, and cost) of the devices has improved, and the capabilities of web browsers have been enhanced by improvements brought by HTML5. This means that some of the functionality that web mapping applications previously could not implement in a standardized way, are now becoming increasingly common.
To support the development of OGC API Standards that standardize many of the new capabilities available to web mapping applications, the OGC and EuroGeographics hosted the 2022 Web Mapping Code Sprint from November 29th to December 1st, 2022. The event was sponsored by OGC Strategic Member, Ordnance Survey. The code sprint was held as a hybrid event, consisting of a virtual element hosted on the OGC’s Discord environment and an in-person element hosted by EuroGeographics in Brussels, Belgium.
Code Sprints experiment with emerging ideas in the context of geospatial Standards, help improve interoperability of existing Standards by experimenting with new extensions or profiles, and are used for building proofs-of-concept to support standards-development activities and the enhancement of software products. Non-coding activities such as testing, working on documentation, or reporting issues are also conducted during a code sprint. In addition, the code sprints’ mentor stream provides an excellent opportunity to onboard developers new to the Standards.
The 2022 Web Mapping Code Sprint focused on the following:
OGC API – Tiles Standard: This Standard describes API building blocks that can enable implementations to serve map tiles, vector tiles (tiled feature data) or tiled coverage data;
OGC API – Maps candidate standard: This candidate Standard describes API building blocks that can enable implementations to serve spatially referenced and dynamically rendered electronic maps;
OGC API – Styles candidate Standard: This candidate Standard describes API building blocks that can enable implementations to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine to features and/or coverages; and
and various Styles & Symbology Encodings (e.g., SLD, SymCore, etc.).
The mentor stream of the code sprint featured two tutorials, about understanding and using one server side and one client side implementation of OGC API — Tiles. They were both well attended, both in-person and online. The mentor stream also included two onboarding sessions, focused on collaborating in software projects that implement the standards.
The code sprint successfully facilitated the development and testing of prototype implementations of OGC API Standards, including candidate Standards, that relate to web mapping. Further, the code sprint provided a foundation for the development of the next version of the Symbology Core Standard. Sprint participants were able to provide feedback directly to the editors of the Standards and the editors were able to clarify any issues encountered by the sprint participants. The code sprint also raised awareness about the Standards. The code sprint therefore met all of its objectives.
The OGC is an international consortium of more than 500 businesses, government agencies, research organizations, and universities driven to make geospatial (location) information and services FAIR — Findable, Accessible, Interoperable, and Reusable. The consortium consists of Standards Working Groups (SWGs) that have responsibility for designing a candidate Standard prior to approval as an OGC Standard and for making revisions to an existing OGC Standard. The sprint objectives for the SWGs were to:
Create awareness about OGC Standards;
Develop prototype implementations of OGC Standards, including implementations of draft OGC Application Programming Interface (API) Standards;
Test the prototype implementations;
Provide feedback to the Editor about what worked and what did not; and
Provide feedback about the Standards and candidate Standards.
EuroGeographics is a not-for-profit organization that represents many of the National Mapping, Cadastral, and Land Registration Authorities across Europe. The organization facilitates access to data, services, and expertise, as well as supporting the sharing of knowledge across the continent. The organization also publishes a product called Open Maps for Europe, which provided a useful resource for sprint participants. For example, within the first day of the code sprint, the sprint participants had implemented an OGC API -Maps façade in front of a Web Map Service (WMS) that was serving maps from the Open Maps for Europe product.
Ordnance Survey (OS) is the National Mapping Agency of Great Britain. OS publishes printed and digital maps, as well as offering access to the maps and data through a variety of APIs. In September 2022, OS launched the OS NGD API suite of products that implement a number of OGC API Standards. The Web Mapping Code Sprint therefore provided an opportunity for OS to directly support the advancement and implementation of the OGC API Standards on which the new OS NGD API products are built. The code sprint also provided an opportunity for OS engineers to directly engage with the editors of the Standards. Such access to editors and SWG members greatly accelerates development of applications.
This engineering report makes the following recommendations for future innovation work items:
Prototyping and demonstration of support for the querying of coverages in HTML Previews of coverage tiles;
A testbed activity to implement the prototype Symbology Core v2.0 would help to evaluate support for the various use cases identified in this sprint;
A testbed activity to evaluate options for access control across OGC API Standards (covering at least the Features, Records, Tiles, and Styles APIs);
A testbed activity applying the ISO 19135 standard to the registration and management of styles through OGC API — Styles; and
A testbed activity analysing the potential for consistent modification and harmonization of different stylesheets (e.g., SLD, Mapbox styles, ArcGIS, MapInfo).
The sprint participants also made the following recommendations for things that the SWGs should consider:
A code sprint focused on general security/access control issues, across OGC API and broader OGC Standards;
Design an approach for supporting ‘Cancel’ requests, so that long-running jobs can be terminated as users zoom or pan across a map;
A user guide for OGC API — Tiles would help to accelerate uptake (e.g., describing how to build static tile servers in the Cloud); and
A future version of the OGC API — Tiles Standard could relax or remove the requirement that the tileset list URL ends with /tiles.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
hackathon, application-to-the-cloud, testbed, docker, web service
III. Security considerations
No security considerations have been made for this document.
IV. Submitters
All questions regarding this document should be directed to the editor or the contributors:
| Name | Organization | Role |
|---|---|---|
| Gobe Hobona | Open Geospatial Consortium | Editor |
| Joana Simoes | Open Geospatial Consortium | Editor |
| Andreas Matheus | Secure Dimensions | Contributor |
| Antonio Cerciello | OSGeo | Contributor |
| Clemens Portele | interactive instruments GmbH | Contributor |
| Erwan Bocher | CNRS (National Center for Scientific Research) | Contributor |
| Francesco Bartoli | OSGeo | Contributor |
| Iván Sánchez Ortega | OSGeo | Contributor |
| Jérôme Jacovella-St-Louis | Ecere Corporation | Contributor |
| Joan Maso | UAB-CREAF | Contributor |
| Keith Pomakis | MariaDB | Contributor |
| Michael Gordon | Ordnance Survey | Contributor |
| Núria Julià Selvas | UAB-CREAF | Contributor |
| Olivier Ertz | HEIG-VD (School of Management and Engineering Vaud) | Contributor |
| Oscar Andrés Díaz | GeoSolutions | Contributor |
| Prajwalita Chavan | IIT Bombay | Contributor |
| Robin Houtmeyers | Hexagon | Contributor |
| Tim Schaub | Planet Labs PBC | Contributor |
| Tom Crauwels | Hexagon | Contributor |
| Tom Kralidis | Meteorological Service of Canada | Contributor |
V. Abstract
The subject of this Engineering Report (ER) is a code sprint that was held from November 29th to December 1st, 2022 to advance OGC API Standards that relate to web mapping, and others that relate to styling and symbology encoding standards. The code sprint was hosted by the Open Geospatial Consortium (OGC) and EuroGeographics. The code sprint was sponsored by Ordnance Survey (OS), and was held as a hybrid event with the face-to-face element hosted at the Mundo Madou centre in Brussels, Belgium.
2022 Web Mapping Code Sprint Summary Engineering Report
1. Scope
A Code Sprint is a collaborative and inclusive event driven by innovative and rapid programming with minimal process and organization constraints to support the development of new applications and open standards. Code Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, and are used for building proofs of concept to support standards development activities and enhancement of software products.
The code sprint described in this engineering report focused on the following approved and candidate Standards:
OGC API — Tiles Standard;
OGC API — Maps candidate Standard;
OGC API — Styles candidate Standard; and
various Styles & Symbology Encodings (e.g., SLD, SE, SymCore, etc.).
The code sprint was organized to provide a collaborative environment that enables software developers, users, and architects to work together on open standards that relate to web mapping, styles, and symbology. This engineering report presents the sprint architecture, the results of the prototyping, and a discussion resulting from the prototyping.
2. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Joan Masó, Jérôme Jacovella-St-Louis: OGC 17-083r4, OGC Two Dimensional Tile Matrix Set and Tile Set Metadata. Open Geospatial Consortium (2022). https://docs.ogc.org/is/17-083r4/17-083r4.html.
Joan Masó, Jérôme Jacovella-St-Louis: OGC 20-057, OGC API — Tiles — Part 1: Core. Open Geospatial Consortium (2022). https://docs.ogc.org/is/20-057/20-057.html.
Charles Heazel: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). https://docs.ogc.org/is/19-072/19-072.html.
Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html
Joan Masó, Jérôme Jacovella-St-Louis: OGC API — Maps — Part 1: Core (Draft). OGC 20-058, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-058.html
Clemens Portele: OGC API — Styles (Draft). OGC 20-009, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-009.html
Markus Lupp: OGC 05-078r4, OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification. Open Geospatial Consortium (2007). https://portal.ogc.org/files/?artifact id=22364.
WHATWG. HTML, Living Standard [online, viewed 2022-12-08]. Available at https://html.spec.whatwg.org/
3. Terms, definitions and abbreviated terms
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
3.1. API
a standard set of documented and supported functions and procedures that expose the capabilities or data of an operating system, application, or service to other applications [adapted from ISO/IEC TR 13066-2:2016]
3.2. coordinate reference system
a coordinate system that is related to the real world by a datum term name [source: ISO 19111]
3.3. dataset
a set of data, published or curated by a single agent, and available for access or download in one or more representations (modified from DCAT: https://www.w3.org/TR/vocab-dcat-2/#dcat-scope).
Note 1 to entry: A Web API implementing OGC API — Common often gives access to a single dataset which may be comprised of one or more geospatial data resources.
3.4. geospatial data resource
a web accessible resource that consists of a set of geospatial data
Note 1 to entry: In Web APIs implementing OGC API — Common — Part 2: Geospatial Data, geospatial data resources are referred to as collections and are defined in the collections conformance class.
Note 2 to entry: geodata is sometimes used in this document as an abbreviation of geospatial data
3.5. geospatial resource aspect
a web accessible resource that represents a component of geospatial information (metadata, schemas…) or geospatial data accessed using a particular mechanism and data model (e.g., feature items, tiles, maps, coverages,…) of a more generic geospatial data resource (e.g., a collection)
Note 1 to entry: Not to be confused with a web accessible resource representation. While resource representations share the same path and are selected by format negotiation, geospatial aspects use different paths. Commonly a geospatial aspect is a subpath of a geospatial data resource.
3.6. map tile
a tile that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices
Note 1 to entry: Map tiles are generated in combination with OGC API — Maps.
3.7. OpenAPI Document
a document (or set of documents) that defines or describes an API. An OpenAPI definition uses and conforms to the OpenAPI Specification (https://www.openapis.org)
3.8. geographic information
information concerning phenomena implicitly or explicitly associated with a location relative to the Earth (source: ISO 19101)
3.9. map
portrayal of geographic information as a digital image file suitable for display on a computer screen (source: OGC 06-042)
3.10. portrayal
presentation of information to humans (source: ISO 19117)
3.11. map tile
tile that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices
3.12. tile
geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected “piece” without “holes” or “lines” (topological disc).
In the context of a 2D tile matrix, a tile is one of the rectangular regions of space, which can be uniquely identified by row and column integer indices, making up the tile matrix.
In the context of a geospatial data tile set, a tile contains data for such a partition of space as part of an overall set of tiles for that tiled geospatial data.
Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space
Note 2 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard
Note 3 to entry: Tiles are useful to efficiently request, transfer, cache, display, store and process geospatial data for a specific resolution and area of interest, providing deterministic performance and scalability for arbitrarily large datasets.
Note 4 to entry: Tiles can contain a variety of data types, such as grid-based pictorial representations (map tiles), coverage subsets (coverage tiles), or feature-based representations (vector tiles).
3.13. tile matrix
tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous tiles, each of which being assigned a unique identifier
Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard
Note 2 to entry: Each tile of a tile matrix is uniquely identifiable by a row and a column integer index. The number of rows is referred to as the matrix height, while the maximum number of columns is referred to as the matrix width (the number of columns can vary for different rows in variable width tile matrices).
3.14. tile matrix set
tiling scheme consisting of a set of tile matrices defined at different scales covering approximately the same area and having a common coordinate reference system.
Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard
3.15. tile set
a set of tiles resulting from tiling data according to a particular tiling scheme
Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, but adapted to clarify that in the context of this document, a tile set refers specifically to a set of tiles containing data and following a common tiling scheme.
3.16. Web API
API using an architectural style that is founded on the technologies of the Web [source: OGC API — Features — Part 1: Core]
3.17. Abbreviated terms
API
Application Programming Interface
CRS
Coordinate Reference System
GIS
Geographic Information System
OGC
Open Geospatial Consortium
OWS
OGC Web Services
REST
Representational State Transfer
WMS
Web Map Service
WMTS
Web Map Tile Service
4. High-Level Architecture
As illustrated in Figure 1, the sprint architecture was designed with the view of enabling client applications to connect to different servers that implement open geospatial standards that relate to web mapping, styles, and symbology. Implementations of OGC API — Maps, OGC API — Tiles and OGC API — Styles were deployed in participants’ own infrastructure in order to build a solution with the architecture shown below in Figure 1.
Figure 1 — High Level Overview of the Sprint Architecture
The rest of this section describes the software deployed and standards implemented during the code sprint.
4.1. Approved and Draft Standards
This section describes the approved and draft standards implemented during the code sprint.
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. Open Source Software Projects
This section describes open source software products that were deployed during the code sprint.
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. Proprietary products
This section describes proprietary software products that were deployed during the code sprint.
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. Results
The code sprint included multiple software products and implementations of OGC and ISO Standards. This section presents some of the results from the code sprint.
5.1. MariaDB CubeWerx CubeSERV
Developers from MariaDB configured an instance of their CubeSERV product to offer an OGC API — Maps interface in front of a WMS that was serving EuroGeographics’s EuroRegionalMap. A screenshot of the CubeSERV user interface is shown in Figure 2. The user interface lists the coordinate reference systems that are supported by the collection that is being retrieved.
Figure 2 — Screenshot of CubeSERV describing a collection
The styles that are supported by the collection can also be accessed, as demonstrated in Figure 3.
Figure 3 — Screenshot of CubeSERV describing styles supported by the collection
The supported map tiles can also be retrieved. A screenshot describing part of a supported tile matrix set is shown in Figure 4.