Publication Date: 2021-04-12

Approval Date: 2021-03-30

Submission Date: 2021-03-03

Reference number of this document: OGC 21-008

Category: OGC Public Engineering Report

Editor: Gobe Hobona, Angelos Tzotsos, Tom Kralidis, Martin Desruisseaux

Title: Joint OGC OSGeo ASF Code Sprint 2021 Summary Engineering Report


OGC Public Engineering Report

COPYRIGHT

Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject

The subject of this Engineering Report (ER) is a code sprint that was held from 17 to 19 February 2021 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 event was sponsored by Ordnance Survey (OS) and GeoCat BV, and held as a completely virtual event.

2. Executive Summary

This Engineering Report (ER) summarizes the main achievements of the Joint OGC OSGeo ASF Code Sprint, conducted between February 17th and 19th, 2021. The sprint served to accelerate the support of open geospatial standards within the developer community.

Part of the motivation for holding the sprint was the growing uptake of location across the global developer communities. The code sprint brought together developers of Open Standards, Open Source Software and Proprietary Software, providing a rare opportunity for developers across these communities to focus on common challenges within a short space of time in a shared collaborative environment.

The Open Geospatial Consortium (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:

  • 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 813 individual Members and 8,000 Committers on six continents stewarding more than 200 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 (GeoSPARQL, Filters, …)

  • Improve visualization capabilities (map, …)

  • Improve documentation (web site, …)

  • Improve interoperability with other libraries (GeoAPI)

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:

  • Themes, trees, nesting, and other strategies for organizing datasets need to be explored. This is needed because data providers often have thousands of datasets that they need to manage or publish.

  • There is a need for more experimentation on styles and coverages, including on how styles can be used to render/filter coverages.

  • Tiled coverages and their support through OGC API - Coverages and OGC API - Tiles integration should be explored further.

  • More experimentation is needed on workflows in relation to the OGC API - Processes - Part 3: Workflows.

  • Further development of the Discrete Global Grid Systems (DGGS) API, including work on client applications and visualization.

  • There is a need to advance OGC APIs and other OGC standards to enable the cataloguing and discovery of models e.g. Artificial Intelligence (AI)/Machine Learning models.

  • The implications of OpenAPI 3.1, JSON Schema and Webhooks need to be examined and a path towards transition identified.

  • Some integration of the MapML format concept with the OGC API offerings, for example into the HTML representation of features, to enhance the spatial indexing of HTML.

  • Enhancement of OGC’s Link Relations Register.

The engineering report also makes the following recommendations for things that the Standards Working Groups should consider introducing support for:

  • Associations between records and other elements in catalogues

  • Landing page of landing pages

  • Searchable collections in OGC APIs (including the collections of collections)

  • Where appropriate, clarification that GeoJSON is the default JSON encoding for OGC API - Features and OGC API - Records

2.1. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Name Organization Role

Gobe Hobona

Open Geospatial Consortium

Editor

Angelos Tzotsos

Open Source Geospatial Foundation

Editor

Tom Kralidis

Meteorological Service of Canada

Editor

Martin Desruisseaux

Geomatys

Editor

Ahmad Ayubi

Natural Resources Canada

Contributor

Alex Mandel

Development Seed

Contributor

Alexander Kmoch

University of Tartu

Contributor

Andrea Aime

GeoSolutions

Contributor

Anna Petrasova

NC State University

Contributor

Anon Bianglae

i-bitz

Contributor

Ashish Kumar

IIT (BHU) Varanasi

Contributor

Astrid Emde

Open Source Geospatial Foundation

Contributor

Benahmed Daho Ali

TransformaTek

Contributor

Benard Odhimabo

8-teq

Contributor

Bo Lu

Natural Resources Canada

Contributor

Brian Hamlin

Open Source Geospatial Foundation

Contributor

Bruno Kinoshita

Apache Software Foundation

Contributor

Carsten Ehbrecht

DKRZ

Contributor

Charles Heazel

Heazeltech LLC

Contributor

Chris Little

Met Office

Contributor

Clemens Portele

interactive instruments GmbH

Contributor

Dave McLaughlin

Penn State University

Contributor

Davince Koyo

Individual

Contributor

Edward Lewis

British Geological Survey

Contributor

Florian Hoedt

Thünen-Institute

Contributor

Francesco Bartoli

Geobeyond Srl

Contributor

Francis Charette Migneault

Computer Research Institute of Montréal (CRIM)

Contributor

Francois Prunayre

titellus

Contributor

Gérald Fenoy

GeoLabs

Contributor

Hisham Massih

Esri

Contributor

Ignacio "Nacho" Correas

Skymantics

Contributor

Ingrid Santana

UFMG

Contributor

Irene Muema

8teq Technologies

Contributor

James Munroe

Elemental Earth Data Ltd.

Contributor

Jamie Goodyear

Apache Software Foundation

Contributor

Jeff McKenna

GatewayGeo

Contributor

Jeffrey Yutzler

Image Matters

Contributor

Jerome St-Louis

Ecere Corporation

Contributor

Joan Maso

UAB-CREAF

Contributor

Jody Garnett

GeoCat

Contributor

Joseph Kariuki

AthenaSl

Contributor

Julia Wakaba

8teq

Contributor

Just van den Broecke

Just Objects B.V.

Contributor

Kathleen Schaefer

UC Davis

Contributor

Luca Delucchi

Fondazione Edmund Mach

Contributor

Luke Hodgson

TPG

Contributor

Mahmoud SAKR

Université Libre de Bruxelles

Contributor

Marco Neumann

KONA

Contributor

Mark Thomas

Apache Software Foundation

Contributor

Martha Vergara

Open Source Geospatial Foundation 

Contributor

Massimo Di Stefano

Met.no

Contributor

Matt Pavlovich

ASF / HYTE Technologies, Inc.

Contributor

Matthew Purss

Pangaea Innovations Pty. Ltd.

Contributor

Michael Rushin

George Mason University

Contributor

Michel Gabriël

GeoCat

Contributor

Nattapat Phumphan

i-bitz company limited 

Contributor

Nazih Fino

Global Nomad GIS Services

Contributor

Núria Julià

UAB-CREAF

Contributor

Nutthapol Jansuri

I-bitz

Contributor

Oscar Diaz

Geosolutions Consulting

Contributor

Panagiotis Vretanos

CubeWerx Inc.

Contributor

Pandu Wicaksono

Badan Pusat Statistik

Contributor

Pankaj Kumar

https://geoknight.medium.com/

Contributor

Patrick Dion

Ecere Corporation

Contributor

Paul Hershberg

NOAA

Contributor

Paul van Genuchten

GeoCat BV

Contributor

Peter Rushforth

Natural Resources Canada

Contributor

Pongsakorn Udombua

i-bitz company limited.

Contributor

Prasong Patheepphoemphong

i-bitz company limited

Contributor

Qianqian Zhang

China Agricultural University

Contributor

Rajat Shinde

Indian Institute of Technology Bombay

Contributor

Rajveer Shekhawat

Manipal University Jaipur

Contributor

Richard Mitanchey

Cerema

Contributor

Richie Carmichael

Esri

Contributor

Sander Schaminee

GeoCat BV

Contributor

Sattawat Arab

i-bitz

Contributor

Sean Arms

UCAR

Contributor

Shane Mill

NOAA

Contributor

Shivashis Padhi

Individual

Contributor

Srini Kadamati

Preset

Contributor

Steve Ochieng

Individual

Contributor

Steve Olson

NOAA/NWS

Contributor

Steven McDaniel

Hexagon Geospatial

Contributor

Vaclav Petras

NC State University

Contributor

Vicky Vergara

georepublic/OSgeo/pgRouting

Contributor

Yugandhar Thippireddy

accenture

Contributor

2.2. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

3. References

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

● 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).

● coordinate reference system

A coordinate system that is related to the real world by a datum term name (source: ISO 19111)

● 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)

● Web API

API using an architectural style that is founded on the technologies of the Web [source: OGC API - Features - Part 1: Core]

4.1. Abbreviated terms

  • API Application Programming Interface

  • ARPEGE French Action de Recherche Petite Echelle Grande Echelle

  • ASF Apache Software Foundation

  • CIS Coverage Implementation Schema

  • CRS Coordinate Reference System

  • DGGS Discrete Global Grid Systems

  • EDR Environmental Data Retrieval

  • GDPS Canadian Global Deterministic Prediction System

  • GFS Global Forecast System

  • GIS Geographic Information System

  • GRASS Geographic Resources Analysis Support System

  • GSS GeoSynchronization Service

  • METAR MEteorological Terminal Aviation Routine Weather Report

  • MOU Memorandum of Understanding

  • NAM North American Mesoscale model

  • NDFD National Digital Forecast Database

  • 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

  • SIS Spatial Information System

  • SOS Sensor Observation Service

  • TAF Terminal Aerodrome Forecast

  • 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

5. Overview

Section 6 introduces the code sprint and lists the affiliations of the registered participants.

Section 7 presents the high-level architecture of the code sprint, and describes the software products and OGC standards that were deployed in the code sprint.

Section 8 presents a summary of the results of the code sprints.

Section 9 discusses some of the issues raised and explored during the code sprint.

Section 10 summarizes the main conclusions and makes recommendations for future work.

6. Introduction

This Engineering Report (ER) summarizes the main achievements of the Joint OGC OSGeo ASF Code Sprint, conducted between February 17th and 19th, 2021. Sponsored by Ordnance Survey (OS) and GeoCat BV, 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 [1].

6.1. Participants

The code sprint had 87 registered participants. Software developers and solutions architects from the following organizations registered to participate in the code sprint:

  • 8teq Technologies

  • accenture

  • HYTE Technologies, Inc.

  • Apache Software Foundation

  • AthenaSl

  • Badan Pusat Statistik

  • British Geological Survey

  • Cerema

  • China Agricultural University

  • Computer Research Institute of Montréal (CRIM)

  • CubeWerx Inc.

  • Development Seed

  • DKRZ

  • Ecere Corporation

  • Elemental Earth Data Ltd.

  • Esri

  • Fondazione Edmund Mach

  • GatewayGeo

  • Geobeyond Srl

  • GeoCat BV

  • GeoLabs

  • Geomatys

  • georepublic/OSgeo/pgRouting

  • George Mason University

  • GeoSolutions

  • Global Nomad GIS Services

  • Heazeltech LLC

  • Hexagon Geospatial

  • geoknight

  • i-bitz company limited

  • IIT (BHU) Varanasi

  • Image Matters

  • Indian Institute of Technology Bombay

  • interactive instruments GmbH

  • Just Objects B.V.

  • KONA

  • Manipal University Jaipur

  • Met Office

  • Met.no

  • Meteorological Service of Canada

  • Natural Resources Canada

  • NC State University

  • National Oceanic and Atmospheric Administration (NOAA) National Weather Service (NWS)

  • Open Geospatial Consortium

  • Open Source Geospatial Foundation

  • Pangaea Innovations Pty. Ltd.

  • Penn State University

  • Preset

  • Skymantics

  • Thünen-Institute

  • titellus

  • TPG

  • TransformaTek

  • UAB-CREAF

  • UC Davis

  • UFMG

  • Université Libre de Bruxelles

  • University of Tartu

7. High Level Architecture

The focus of the sprint was on support of the development of the open geospatial standard across various open source software projects. Implementations of these draft standards were deployed in participants’ own infrastructure in order to build a solution with the architecture shown below in Figure 1.

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

7.1. Approved OGC Standards

This section describes the approved OGC standards implemented during the code sprint.

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

7.1.2. OGC Discrete Global Grid Systems (DGGS)

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.

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

7.1.4. OGC GeoPackage

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.

7.2. Draft OGC Specifications

This section describes the draft OGC specifications implemented during the code sprint.

7.2.1. OGC API - Common

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.

7.2.2. OGC API - Coverages

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.

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

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

7.2.5. OGC API - Processes

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.

7.2.6. OGC API - Records

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.

7.2.7. OGC API - Routes

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.

7.2.8. OGC API - Styles

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.

7.2.9. OGC API - Tiles

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.

7.3. OSGeo Projects

This section describes software, by OSGeo Projects, that was deployed during the code sprint.

7.3.1. OSGeo GeoNetwork

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.

7.3.2. OSGeo GeoNode

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

7.3.3. OSGeo GeoServer

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.

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

7.3.5. OSGeo Mapbender

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

7.3.6. OSGeo MapServer

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

7.3.7. OSGeo OSGeoLive

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.

7.3.8. OSGeo PostGIS

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

7.3.9. OSGeo Proj

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

7.3.10. OSGeo pycsw

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

7.3.11. OSGeo QGIS

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

7.4. OSGeo Community Projects

This section describes software, by OSGeo Community Projects, that was deployed during the code sprint.

7.4.1. OSGeo GeoHealthCheck

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

7.4.2. MapML extension for GeoServer

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.

7.4.3. OSGeo GeoTrellis

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

7.4.4. OSGeo mapproxy

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.

7.4.5. OSGeo MobilityDB

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

7.4.6. OSGeo OWSLib

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

7.4.7. OSGeo pdal

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

7.4.8. OSGeo pgRouting

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

7.4.9. OSGeo pygeoapi

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

7.4.10. OSGeo Stetl

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.

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

7.5. ASF Projects

This section describes software, by ASF Projects, that was deployed during the code sprint.

7.5.1. Apache ActiveMQ

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.

7.5.2. Apache CXF

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.

7.5.3. Apache Jena

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

7.5.4. Apache Karaf

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

7.5.5. Apache SIS

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.

7.5.6. Apache Superset

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

7.5.7. Apache Tomcat

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

7.6. Other open source

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

7.7. Proprietary products

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

  • Multiple conformance classes and recommendations of the draft OGC API - Coverages - Part 1: Core specification.

  • Multiple conformance classes and recommendations of the draft OGC API - Processes - Part 1: Core specification.

  • 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, Web Object Service Implementation Specification.

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.

7.7.2. CREAF MiraMon Map Server

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

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

7.7.4. NOAA NWS EDR API Implementation

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.

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

Figure 2 shows a screenshot of the OpenSphere application displaying a DGGS that had been uploaded as a GeoJSON-encoded feature collection. On the screenshot, one of the grid cells is highlighted after being clicked on.