I. Executive Summary
Over the past decade, geospatial technologies and data have become more widespread in use and application. A key catalyst for this increased uptake of geospatial technologies is the interoperability achieved through implementation of open geospatial standards. Another important catalyst for this increased uptake is the availability of open source software products that are able to extract, transform, analyze, and disseminate geospatial data.
In February 2021, the Open Geospatial Consortium (OGC), the Apache Software Foundation (ASF), and the Open Source Geospatial Foundation (OSGeo) held their first joint Open Source Software and Open Standards Code Sprint (OGC 21-008). The success of that first joint code sprint provided the foundation for a second joint code sprint. This Engineering Report (ER) summarizes the main achievements of the second joint code sprint, conducted between March 8th and 10th, 2022. The second code sprint, named the 2022 Joint OGC OSGeo ASF Code Sprint, served to accelerate the support of open geospatial standards within the developer community.
Part of the motivation for holding the code sprint in 2022 was the growing uptake of location information across the global developer communities. The code sprint brought together developers of Open Standards, Open Source Software and Proprietary Software. The code sprint therefore provided a rare opportunity for developers across these communities to focus on common challenges, within a short space of time, and in a shared collaborative environment.
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:
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
Provide feedback about the specification document
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. The sprint objectives for OSGeo projects were:
Release new software versions
Fix open issues
Develop new features
Improve documentation, translations
Develop prototype implementations of OGC standards
The Apache Software Foundation (ASF) is an all-volunteer community comprising 815 individual Members and 8,500 Committers on six continents stewarding more than 227 million lines of code, and overseeing more than 350 Apache projects and their communities. The sprint objectives for ASF projects were:
Improve support of OGC standards
Improve visualization capabilities
Improve documentation
Improve interoperability with other libraries
The 2022 Joint Code Sprint introduced several changes that were not there during the 2021 Joint Code Sprint. First, a new collaboration platform – Discord- was used. Discord allowed both chat and video communications to be offered from within the same environment. Discord also supported the creation of multiple chat channels, thereby making it possible for separate projects to have their own dedicated chat channels. Second, the code sprint offered Mentor Streams that presented tutorials for developers that were getting started in using various standards or software products. Finally, a dedicated chat channel was created for the event sponsor, Ordnance Survey, on the code sprint’s Discord environment thereby making it possible for sprint participants to visit the channel and ask about the sponsor’s products.
The code sprint facilitated the development and testing of prototype implementations of OGC standards, including implementations of draft OGC API standards. Further, the code sprint also enabled the participating developers to provide feedback to the editors of OGC standards. Furthermore, the code sprint provided a collaborative environment for OSGeo and ASF developers to fix open issues in products, develop new features, improve documentation, improve interoperability with other libraries/products, and develop prototype implementations of OGC standards. The code sprint therefore met all of its objectives and achieved its goal of accelerating the support of open geospatial standards within the developer community.
The engineering report makes the following recommendations for future innovation work items:
Prototypes of catalogues that can be crawled through by an application. Currently there are several searchable catalogues but no catalogues that can be crawled through by an application.
More specification validation work for OGC API Records.
More experiments for the Workflows extension of OGC API Processes. This could try out a variety of workflow approaches.
Experimentation on how a processing server can interact properly with other OGC API implementations that serve data. For example, in this code sprint there was an implementation of OGC API Processes (ZOO Project) that interacted with an OGC API Features implementation (MapServer).
Experimentation with OGC’s geoparquet candidate standard and Apache Arrow.
The engineering report also makes the following recommendations for things that the Standards Working Groups should consider introducing support for:
To improve examples and documentation related to OGC API Records.
To advance the development of the Executable Test Suites of OGC API Processes.
To advance the development of the Executable Test Suites of OGC API Tiles.
To advance the development of the Executable Test Suites of OGC API Coverages.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
OGC, OSGeo, hackathon, code sprint, standards, geospatial, API, open source
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 |
Angelos Tzotsos | Open Source Geospatial Foundation | Editor |
Martin Desruisseaux | Geomatys | Editor |
Tom Kralidis | Meteorological Service of Canada | Editor |
Gérald Fenoy | GeoLabs | Contributor |
Rajat Shinde | IIT Bombay | Contributor |
Michael Arneson | INT | Contributor |
Blasco Brauzzi | Terradue Srl | Contributor |
Vicky Vergara | pgRouting (OSGeo) | Contributor |
Josh Townsend | bp | Contributor |
Jerome Jacovella-St-Louis | Ecere Corporation | Contributor |
Massimiliano Cannata | SUPSI | Contributor |
Morten Breiner | EIVA | Contributor |
Ana Paula Seraphim | University of Cambridge | Contributor |
Paloma Abad | National Center of Geographic Information (Spain) | Contributor |
Carmen Tawalika | mundialis | Contributor |
Clemens Portele | interactive instruments GmbH | Contributor |
Haifeng Niu | Department of Land Economy, University of Cambridge | Contributor |
Samantha Lavender | Pixalytics Ltd | Contributor |
Ashish Kumar | IIT (BHU) Varanasi | Contributor |
Carlos Eduardo Mota | CPRM | Contributor |
Bruno Kinoshita | Apache Software Foundation | Contributor |
Paul van Genuchten | ISRIC World Soil Information | Contributor |
Panagiotis Vretanos | CubeWerx Inc. | Contributor |
Anika Weinmann | mundialis | Contributor |
Eugene Yu | George Mason University | Contributor |
Iván Sánchez Ortega | OSGeo charter member | Contributor |
Ayodele Michael A | (self) | Contributor |
Weston Renoud | QPS BV | Contributor |
Luca Delucchi | Fondazione Edmund Mach | Contributor |
Francesco Bartoli | Geobeyond | Contributor |
Patrick Dion | Ecere Corporation | Contributor |
Antonio Cerciello | Byte Road | Contributor |
Brian M. Hamlin | OSGeo California Chapter | Contributor |
Jack Riley | NOAA | Contributor |
James Case | Case Ocean Services LLC | Contributor |
Kevin Lalli | Hydrosat | Contributor |
Marta Conceição | FMUL | Contributor |
Matthias Loeks | BASF Digital Farming GmbH | Contributor |
Maxime Collombin | University of Applied Sciences, Western Switzerland, School of Business & Engineering Vaud (HEIG-VD) | Contributor |
Mehmet Akif Ortak | IT | Contributor |
Tracey Birch | (self) | Contributor |
V. Abstract
The subject of this Engineering Report (ER) is a code sprint that was held from the 8th to the 10th of March 2022 to advance support of open geospatial standards within the developer community, whilst also advancing the standards themselves. The code sprint was hosted by the Open Geospatial Consortium (OGC), the Apache Software Foundation (ASF), and Open Source Geospatial Foundation (OSGeo). The code sprint was sponsored by Ordnance Survey (OS), and held as a completely virtual event.
Joint OGC OSGeo ASF Code Sprint 2022 Summary Engineering Report
1. Scope
This Engineering Report (ER) summarizes the main achievements of the Joint OGC OSGeo ASF Code Sprint, conducted between March 8th and 10th, 2022. Sponsored by Ordnance Survey (OS), the code sprint was hosted by the OGC, ASF, and OSGeo with the goal of accelerating the support of open geospatial standards within the developer community.
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.
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.
Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md
Berners-Lee, T., Fielding, R., Masinter, L: IETF RFC 3896, Uniform Resource Identifier (URI): Generic Syntax, https://tools.ietf.org/rfc/rfc3896.txt
W3C: HTML5, W3C Recommendation, https://www.w3.org/TR/html5/
Schema.org: https://schema.org/docs/schemas.html
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). https://docs.ogc.org/is/17-069r3/17-069r3.html.
Heazel, C.: OGC API — Common — Part 1: Core (Draft). OGC 19-072, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/19-072.html
Heazel, C.: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html
OGC: OGC 07-011, Topic 6 — Schema for coverage geometry and functions. Open Geospatial Consortium (2007). https://portal.ogc.org/files/?artifact id=19820.
John R. Herring: OGC 17-087r13, Topic 1 — Features and geometry – Part 1: Feature models . Open Geospatial Consortium (2020). https://docs.ogc.org/as/17-087r13/17-087r13.html.
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
An Application Programming Interface (API) is 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. 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.4. Web API
API using an architectural style that is founded on the technologies of the Web [source: OGC API — Features — Part 1: Core]
3.5. Abbreviated terms
API
Application Programming Interface
ASF
Apache Software Foundation
CIS
Coverage Implementation Schema
CRS
Coordinate Reference System
DGGS
Discrete Global Grid Systems
EDR
Environmental Data Retrieval
GIS
Geographic Information System
GRASS
Geographic Resources Analysis Support System
MOU
Memorandum of Understanding
OGC
Open Geospatial Consortium
OSGeo
Open Source Geospatial Foundation
OWS
OGC Web Services
REM
Route Exchange Model
REST
Representational State Transfer
SDI
Spatial Data Infrastructure
TMS
Tile Matrix Set
WCS
Web Coverage Service
WFS
Web Feature Service
WMS
Web Map Service
WMTS
Web Map Tile Service
WPS
Web Processing Service
4. High-Level Architecture
The focus of the sprint was on the support of implementations of open geospatial standards across various open source software projects. Implementations of approved and candidate OGC Standards 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
As illustrated the sprint architecture was designed with the view of enabling client applications to connect to different servers that implement open geospatial standards such as the suite of OGC API standards. The architecture also included several different software libraries that support open geospatial standards and enable the extraction, transformation and loading of geospatial data. The rest of this section describes the software deployed and standards implemented during the code sprint.
4.1. Approved OGC Standards
This section describes the approved OGC standards implemented during the code sprint.
4.1.1. OGC API — Features
The OGC API — Features standard offers the capability to create, modify, and query spatial data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of sharing feature data. A ‘feature’ is an abstraction of real-world phenomena or entity (OGC 17-087r13). The standard specifies discovery and query operations, with additional operations planned for future extensions of the standard. Discovery operations enable client applications to interrogate the API to determine its capabilities and retrieve information about the dataset that is accessible through the API. In contrast, Query operations enable client applications to retrieve feature data from the underlying storage based upon selection criteria defined by the client. The standard can be considered the successor to the widely implemented Web Feature Service (WFS) standard.
The OGC API — Features standard comprises of multiple parts, which are listed below:
Part 1: Core is an approved standard that describes the mandatory capabilities that every implementing service has to support and is restricted to read-access to spatial data that is referenced to the World Geodetic System 1984 (WGS 84) Coordinate Reference System (CRS).
Part 2: CRS by Reference is an approved standard that enables the use of different CRS, in addition to the WGS 84.
Part 3: Filtering is a candidate standard that defines the behavior of a server that supports enhanced filtering capabilities expressed using the Common Query Language (CQL2).
Additional capabilities that address specific needs will be specified in additional parts. Envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, and richer queries.
4.1.2. OGC API — Environmental Data Retrieval
An Environmental Data Retrieval (EDR) API provides a family of lightweight interfaces to access environmental data resources. Each resource addressed by an EDR API maps to a defined query pattern. The OGC API – Environmental Data Retrieval standard identifies resources, captures compliance classes, and specifies requirements that are applicable to environmental data retrieval. The standard addresses two fundamental operations; discovery and query of environmental data resources. Discovery operations allow the API to be interrogated to determine its capabilities and retrieve information (metadata) about this distribution of a resource. This includes the API definition of the server as well as metadata about the environmental data resources provided by the server. Query operations allow environmental data resources to be retrieved from the underlying data store based upon simple selection criteria, defined by this standard and selected by the client.
4.1.3. OGC API — Processes
The OGC API — Processes standard enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. Typically, these processes combine raster, vector, and/or coverage data with well-defined algorithms to produce new raster, vector, and/or coverage information. The standard can be considered the successor to the widely implemented Web Processing Service (WPS) standard.
OGC API – Processes is comprised of multiple parts, which are listed below:
Part 1: Core is an approved standard that specifies an interface that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality.
Part 2: Deploy, Replace, Undeploy is a candidate standard that specifies an interface for deployment, replacement, and undeployment of processes from a server.
Part 3: Workflows is a candidate standard specifies an interface that provides the ability to chain nested processes, refer to external processes and collections accessible via OGC API standards, and trigger execution of processes through implementations of OGC API standards.
4.1.4. OGC GeoAPI
The GeoAPI Implementation Standard defines the normalized use of the GeoAPI library. The GeoAPI library contains a series of interfaces and classes in the Java programming language defined in several packages which interpret into Java the data model and Unified Modeling Language (UML) types that are specified in ISO and OGC standards documents. The library includes extensive Javadoc code documentation which complements the implementation of the ISO/OGC specifications by explaining particularities of the GeoAPI library: interpretations made of the specifications where there was room for choice, constraints due to the library’s use of Java, or standard patterns of behavior expected by the library, notably in its handling of return types during exceptional situations.
In this code sprint, the GeoAPI implementers focused on support for the Geospatial Integrity of Geoscience Software (GIGS) specification.
4.2. Draft OGC Specifications
This section describes the draft OGC specifications implemented during the code sprint.
4.2.1. OGC API — Common
The draft OGC API — Common standard specifies the set of common practices and shared requirements that have emerged from the development of Resource Oriented Architectures and Web APIs within the OGC. The specification serves as a common foundation upon which all OGC APIs will be built. Consistent with the architecture of the Web, this specification uses a resource architecture that conforms to principles of Representational State Transfer (REST). The draft OGC API – Common specification establishes a common pattern that leverages the OpenAPI specification for describing APIs.
4.2.2. OGC API — Coverages
The draft OGC API — Coverages standard defines a Web API for accessing coverages that are modeled according to the Coverage Implementation Schema (CIS) 1.1. A coverage is a feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain (OGC 07-011). Coverages are represented by some binary or ASCII serialization, specified by some data (en-coding) format. Arguably the most popular type of coverage is that of a gridded coverage. Gridded coverages have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid. Satellite imagery is typically modeled as a gridded coverage, for example. OGC API — Coverages can be considered the future successor to the widely implemented Web Coverage Service (WCS) standard.
4.2.3. OGC API — Maps
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. OGC API — Maps can be considered the future successor to the widely implemented Web Map Service (WMS) standard.
4.2.4. OGC API — Records
The draft OGC API — Records standard provides discovery and access to metadata records about resources such as features, coverages, tiles / maps, models, assets, services or widgets. The draft specification enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed. The draft specification also enables the discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed. OGC API — Records can be considered the future successor to the widely implemented Catalogue Services for the Web (CSW) standard.
4.2.5. OGC API — Routes
The draft OGC API — Routes standard specifies the behavior of a Web API that allows applications to request routes in a manner independent of the underlying routing data set, routing engine or algorithm. The draft standard defines modular API building blocks for computing new routes, specifying commonly used routing parameters, and for managing routes. Implementations of OGC API — Routes represent routes as a feature collection encoded in GeoJSON according to the OGC Route Exchange Model (REM) candidate standard.
4.2.6. OGC API — Tiles
The draft OGC API - Tiles standard specifies the behavior of Web APIs that provide access to tiles of one or more geospatial data resources (collections) or from the whole dataset that the Web API offers. This draft standard defines how to discover which resources offered by the Web API can be retrieved as tiles, get metadata about the available tile sets (including according to which tile matrix set each tile set is partitioned in and the limits of that tile set within a common potentially global tile matrix set) and how to request a tile.
4.2.7. OGC Gridded Geodetic Data Exchange Format (GGXF)
The purpose of the Gridded Geodetic Data Exchange Format (GGXF) project team is to design a file structure and computer storage mechanism for the efficient exchange of regularly gridded geodetic data.
4.3. OSGeo Projects
This section describes software products, from OSGeo Projects, that were deployed during the code sprint.
4.3.1. OSGeo GRASS GIS
The Geographic Resources Analysis Support System (GRASS) is an open source GIS providing raster, vector and geospatial processing capabilities. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R or in the cloud [1].
4.3.2. OSGeo MapServer
MapServer is an open source platform for publishing spatial data and interactive mapping applications to the web.
In this code sprint, the participants implemented an extension to MapServer that enabled MapServer to offer an interface conforming to OGC API — Features.
4.3.3. OSGeo PostGIS
PostGIS provides spatial objects for the PostgreSQL database, allowing storage and query of information about location and mapping.
4.3.4. OSGeo Proj
PROJ is a generic coordinate transformation software library that transforms geospatial coordinates from one coordinate reference system (CRS) to another.
4.3.5. OSGeo pycsw
pycsw is a server-side python implementation of the OGC Catalogue Services for the Web (CSW) standard.
4.3.6. OSGeo QGIS
QGIS is a free and open-source cross-platform desktop GIS that supports viewing, editing, and analysis of geospatial data.
4.4. OSGeo Community Projects
This section describes software products, from OSGeo Community Projects, that were deployed during the code sprint.
4.4.1. OSGeo Leaflet
Leaflet is an open-source JavaScript library for mobile-friendly interactive maps. It works across all major desktop and mobile platforms, can be extended with a variety of plugins, and offers a well-documented API.
4.4.2. OSGeo OWSLib
OWSLib is a Python package for client programming with OGC Web Service (OWS) standards, and their related content models. OWSLib also supports some OGC API Standards.
4.4.3. OSGeo pgRouting
pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality.
4.4.4. OSGeo pygeoapi
pygeoapi is a Python server implementation of the OGC API suite of standards.
4.4.5. OSGeo pygeometa
pygeometa is a Python package to generate metadata for geospatial datasets.
4.4.6. 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.4.7. OSGeo ZOO-Project
ZOO-Project is a Web Processing Service (WPS) implementation written in C. It is an open source platform which implements the WPS 1.0.0 and WPS 2.0.0 OGC Standards.
4.5. ASF Projects
This section describes software products, from ASF Projects, that were deployed during the code sprint.
4.5.1. Apache SIS
Apache Spatial Information System (SIS) is a free and open source software library for developing geospatial applications. The library is an implementation of OGC GeoAPI 3.0.1 interfaces and can be used for desktop or server applications. Services provided by Apache SIS include metadata, coordinate transformations, filtering and grid coverages. The library is implemented using the Java programming language.
In this code sprint, Apache SIS was used for testing the Geospatial Integrity of Geoscience Software (GIGS) tests runner.
4.6. Other open source products
4.6.1. ldproxy
ldproxy is an implementation of the OGC API family of specifications, inspired on 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). The software originally started in 2015 as a Web API for feature data based on WFS 2.0 capabilities. 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 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 the draft extensions (that is Part 3 and Part 4). ldproxy also has draft implementations for additional resource types (Tiles, Styles).
4.6.2. RabbitMQ
RabbitMQ is an open source message broker that supports multiple messaging protocols. RabbitMQ is lightweight and deployable on premises and cloud computing environments. RabbitMQ can support distributed and federated enterprises to meet scalability and availability requirements.
In this code sprint, RabbitMQ was reviewed by ZOO Project developers as an option for supporting pubsub (publish/subscribe) needs.
4.6.3. Testbed-17 D166 Prototype
The aim of the Testbed-17 D166 prototype was to support experimentation on lowering the entry barrier for implementing OGC Web APIs [2]. The prototype uses JavaScript to implement offer interfaces conforming to OGC API Features and OGC API EDR standards. The base system is provisioned by a PostgreSQL database and supported by an instance of the GDAL library.
4.6.4. Testbed-17 D168 Prototype
The aim of the Testbed-17 D168 prototype was to help with optimizing documentation and scripts to support data providers implementing OGC API Standards in Cloud environments [2]. The prototype is designed to be a conda-deployable python environment.
4.7. Proprietary products
4.7.1. CubeWerx CubeServ
The CubeWerx server (“cubeserv”) is implemented in C and currently implements the following OGC specifications:
All conformance classes and recommendations of the OGC API — Features — Part 1: Core standard.
Multiple conformance classes and recommendations of the draft OGC API — Records — Part 1: Core standard.
Multiple conformance classes and recommendations of the draft OGC API — Coverages — Part 1: Core 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 services 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.7.2. GNOSIS Map Server
The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API specifications. 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, GeoECON, GML and MapML. An experimental server is available online at https://maps.ecere.com/ogcapi and has been used in multiple OGC Innovation Program initiatives.
5. Results
The code sprint included multiple software libraries, OWS implementations, OGC API implementations and different client applications. In addition to supporting OWS and OGC API standards, various ASF and OSGeo software products involved in the code sprint also supported a variety of OGC encoding standards. This section presents some of the results from the code sprint.
5.1. Leaflet
One of the contributors of Leaflet implemented support for OGC API — Maps in the code sprint. Support for OGC API — Maps in Leaflet was implemented as a plug-in, enabling anyone to integrate the JavaScript files into their JavaScript application.