Joint OGC OSGeo ASF Code Sprint 2021 Summary Engineering Report

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. The specification is a multi-part standard. Part 1, labelled the Core, 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 enables the use of different CRS, in addition to the WGS 84. 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.

The OGC API - Features standard is part of the OGC API family of standards. OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The standards make use of the OpenAPI specification for defining the API building blocks.

This standard specifies the core requirements and extension mechanisms for Discrete Global Grid Systems (DGGS). A DGGS is a spatial reference system that uses a hierarchical tessellation of cells to partition and address the globe. DGGS are characterized by the properties of their cell structure, geo-encoding, quantization strategy and associated mathematical functions. The OGC DGGS Abstract Specification supports the description of standardized DGGS infrastructures that enable the integrated analysis of very large, multi-source, multi-resolution, multi-dimensional, distributed geospatial data. A prototype DGGS API was recently built in the OGC Testbed-16 initiative. It is anticipated that the DGGS API will become a part of the OGC API family of standards.

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.

GeoPackage is an open, platform-independent, portable, self-describing, compact format for transferring geospatial information. The GeoPackage Encoding Standard governs the rules and requirements for storing content in an SQLite database. The content may include geospatial and non-geospatial content. The standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints.

The draft OGC API - Common specification documents 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 draft OGC API - Common specification is part of the OGC API family of standards. 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.

The OGC API - Coverages specification defines a Web API for accessing coverages that are modeled according to the Coverage Implementation Schema (CIS) 1.1. 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. The draft OGC API - Coverages specification is part of the OGC API family of standards.

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 candidate standard identifies resources, captures compliance classes, and specifies requirements that are applicable to environmental data retrieval. The candidate 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. The OGC API – Environmental Data Retrieval candidate standard is part of the OGC API family of standards. The OGC API – Environmental Data Retrieval candidate standard is part of the OGC API family of standards.

The draft OGC API - Maps standard describes an API that presents maps portraying data that has been rendered according to a style. The maps served by implementations of the draft OGC API - Maps standard are retrieved as images of any size, generated on-the-fly, and with the styling determined by the client application. The draft standard can be considered the successor to the widely implemented WMS standard. The draft OGC API – Maps specification is part of the OGC API family of standards.

The draft 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 draft OGC API – Processes specification is part of the OGC API family of standards.

OGC API - Records 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. The draft OGC API – Records specification is part of the OGC API family of standards.

OGC API - Routes describes the requirements for interoperable web-based route computation and specifies a number of alternative approaches to fulfill these requirements. One of the approaches is based on the current draft of the draft OGC API - Processes - Part 1: Core specification while the other comprises a specialized API although also based on the draft OGC API - Common - Part 1: Core specification. Both approaches facilitate a common Route Exchange Model (REM) that is based on GeoJSON.

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

OGC API - Tiles references the OGC Two Dimensional Tile Matrix Set (TMS) standard. The TMS standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix) for a limited list of scales in a CRS. The draft OGC API – Tiles specification is part of the OGC API family of standards.

GeoNetwork is a catalog application for managing spatially referenced resources. It provides metadata editing and search functions as well as an interactive web map viewer.

GeoNode is a web-based application and platform for developing Geographic Information Systems (GIS) and for deploying Spatial Data Infrastructures (SDI).

GeoServer is a Java-based software server that allows users to view and edit geospatial data. Using open standards by the OGC, GeoServer allows for great flexibility in map creation and data sharing.

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 [2].

Mapbender is a web-based geoportal framework to publish, register, view, navigate, monitor and grant secure access to spatial data infrastructure services.

MapServer is an open source platform for publishing spatial data and interactive mapping applications to the web.

OSGeoLive is a self-contained bootable DVD, USB thumb drive or Virtual Machine based on the Lubuntu operating system, that allows users to try a wide variety of open source geospatial software without installing anything.

PostGIS provides spatial objects for the PostgreSQL database, allowing storage and query of information about location and mapping.

PROJ is a generic coordinate transformation software library that transforms geospatial coordinates from one coordinate reference system (CRS) to another.

pycsw is a server-side python implementation of the OGC Catalogue Services for the Web (CSW) standard.

QGIS is a free and open-source cross-platform desktop GIS that supports viewing, editing, and analysis of geospatial data.

GeoHealthCheck is a Python application to support monitoring OGC Web Services uptime and availability.

Map Markup Language (MapML) is a text-based format which allows map authors to encode map information as hypertext documents exchanged over the Uniform Interface of the Web.

GeoTrellis is an open source, geographic data processing library implemented in Scala and designed to work with large geospatial raster data sets.

MapProxy is an open source proxy for geospatial data. It caches, accelerates and transforms data from existing map services and serves different desktop or web GIS client applications.

MobilityDB is a database management system for moving object geospatial trajectories, such as GPS traces.

OWSLib is a Python package for client programming with OGC Web Service (OWS) interface standards, and their related content models.

PDAL is a C++ BSD library for translating and manipulating point cloud data.

pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality.

pygeoapi is a Python server implementation of the OGC API suite of standards.

Stetl, Streaming ETL, is an open source (GNU GPL) toolkit for the extraction, transformation and loading (ETL) of geospatial data. Stetl is based on existing ETL tools like GDAL/OGR and XSLT.

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 standards edited by the Open Geospatial Consortium (OGC).

Apache ActiveMQ™ is an open source, multi-protocol, Java-based messaging server. It supports industry standard protocols so users get the benefits of client choices across a broad range of languages and platforms.

Apache CXF™ is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS.

A free and open source Java framework for building Semantic Web and Linked Data applications.

Apache Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.

Apache Spatial Information System (SIS) is a free software, Java language 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.

Apache Superset is an open-source software cloud-native application for data exploration and data visualization able to handle data at petabyte scale.

Apache Tomcat is an open-source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and WebSocket technologies.

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 other draft extensions (including Part 3 and Part 4). ldproxy also has draft implementations for additional resource types (Tiles, Styles).

The CubeWerx server ("cubeserv") is implemented in C and currently implements the following OGC specifications:

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.

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

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.

The National Weather Service deployed an instance of the OGC API - Environmental Data Retrieval candidate standard. The implementation offers the following types of data products: MEteorological Terminal Aviation Routine Weather Report (METAR), Terminal Aerodrome Forecast (TAF), Global Forecast System(GFS), North American Mesoscale model (NAM), National Digital Forecast Database (NDFD), Canadian Global Deterministic Prediction System (GDPS), French Action de Recherche Petite Echelle Grande Echelle (ARPEGE), and NASA monthly precipitation and hourly data (originally in HDF5 format).

The implementation is able to ingest GRIB and HDF5 data as well as text products and data from Thredds. The implementation also contains schema support for the following output formats: CoverageJSON, GRIB, and IWXXM, with additional support added during this sprint to add support for NetCDF. In the future, work will be done to support HDF5 as an output format, but NetCDF was decided on to implement first.

Finally, the implementation supports the sampling geometry types of Position, Area, and Cube with additional support added during this sprint for Trajectory.