Publication Date: 2019-11-14

Approval Date: 2019-09-12

Submission Date: 2019-08-21

Reference number of this document: OGC 19-062

Reference URL for this document: http://www.opengis.net/doc/PER/OGCAPI-hackathon-2019

Category: OGC Public Engineering Report

Editor: Gobe Hobona

Title: OGC API Hackathon 2019 Engineering Report


OGC Public Engineering Report

COPYRIGHT

Copyright © 2019 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 hackathon event that was held from 20 to 21 June 2019 to advance the development of OGC Application Programming Interface (API) specifications. An 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). The OGC API Hackathon 2019, as the event was called, was hosted by Geovation at its hub in London, United Kingdom. The event was sponsored by the European Space Agency (ESA) and Ordnance Survey.

2. Executive Summary

Several technologies and practices have emerged over the past decade that have presented new opportunities for geospatial software developers. Amongst those technologies are Web Application Programming Interfaces (APIs). In order to leverage the capabilities offered by these technologies, the OGC has initiated a body of work to develop draft standards for OGC APIs. At the February 2019 OGC Technical Committee (TC) meeting in Singapore, the TC took a decision to hold a hackathon to help advance many of the draft OGC API standards.

The hackathon was held from 20 to 21 June 2019, hosted by the Geovation Hub in London, United Kingdom. The European Space Agency (ESA), Ordnance Survey, and Geovation sponsored the event. The hackathon was also supported by the US National Geospatial Intelligence Agency (NGA). The goal of the hackathon was to advance the development of OGC API specifications, with the aim of the hackathon being to provide an environment and an opportunity for the geospatial community to achieve this goal. The following objectives were set for the hackathon:

  • Develop, deploy and test services/clients that support OGC APIs;

  • Suggest improvements for a common core;

  • Define rules/guidance that can be documented;

  • Validate work that has been completed to date; and

  • Contribute to the GitHub repositories of the draft standards.

More than 70 individuals participated in the event. The participants represented 60 organizations; 41 of those organizations are OGC members; one of the organizations is an OGC Alliance Partner and the remaining 18 organizations are non-members. Working collaboratively, the participants formed teams around the draft standards.

During the two-day hackathon, the participants developed, deployed and tested a variety of implementations of OGC APIs. The hackathon focused on implementation of the following draft OGC API specifications.

  • OGC API - Common: A specification of practices and shared requirements that are common across all OGC APIs.

  • OGC API - Processes: A specification for APIs that wrap executable processes that can be invoked by a client application.

  • OGC API - Map Tiles: A specification for APIs that provide access to Map Tiles in a manner independent of the underlying data store.

  • OGC API - Coverages: A specification for APIs that allow access to coverages that are modeled according to the Coverage Implementation Schema (CIS).

  • OGC API - Features: A specification for APIs that disseminate feature data for sharing.

The following additional draft specifications were also considered by the hackathon participants.

  • OGC API - Catalogues: A specification for APIs that allow access to catalogues and can disseminate metadata.

  • Weather on the Web API: A specification for APIs that disseminate any meteorological information that covers past, present, and future states of the atmosphere including observations and climatological data.

The implementations were from different organizations, including private, public and academic organizations. Suggestions for improvements were made, and in some cases, editors of the standards were able to update the draft standards during the hackathon. Improvements to the common core were discussed, and where possible, agreed on. The work that had previously been done was validated through development and testing. Where the previous work was invalid, suggestions for improvements were identified. Requirements and recommendations were discussed and documented as rules and guidance in the Github repositories of the draft standards. This Engineering Report therefore concludes that the hackathon achieved its goal.

One of the key findings of the hackathon was that the draft OGC API standards are implementable. This was evidenced by the implementations developed by many of the participating organizations at the hackathon. Another key finding is that the 'building-block' principle, adopted by the different draft standards, allows for a common core to be specified. This was evidenced in the use of common capabilities such as /collection paths and support for bounding box (BBOX) queries. Another key finding is that when interfaces built on a combination of Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML) and JavaScript Object Notation (JSON) are standardized across different geospatial applications, the interfaces can be viable enablers of interoperability between the applications. This was evidenced by the successful Technology Integration Experiments (TIEs) achieved during the hackathon.

Based on the results and findings of the hackathon, this engineering report makes the following recommendations.

  1. The Web Map Service (WMS) Standards Working Group (SWG) should consider separating the Map Tiles API into separate building blocks (specifications), one for maps and the other for tiles.

  2. The OGC Web Services (OWS) Common SWG should continue to work on achieving a common understanding for OGC API - Common and should continue to seek to get buy-in from all groups representing the various resources like features, maps, tiles, processes, coverages, etc.

  3. The Web Coverage Service (WCS) SWG should continue to work on specifying the concept of collections of coverages.

  4. The OGC Architecture Board (OAB) should consider potential revisions to the OGC Reference Model to reflect the role of the OGC APIs.

  5. Future OGC API hackathons should include a convergence phase where ideas from the various groups are compared and commonalities can be extracted for the Common API.

  6. The WCS SWG should establish a clear correspondence between WCS Core and all WCS extensions; this should then be related to the emerging OGC API - Coverages Specification.

  7. The Web Processing Service (WPS) SWG should consider how a server might facilitate the handling of a large number of processes (for example through pagination or a higher-level grouping of thematically similar processes).

  8. The WPS SWG should consider further alignment between the OGC API – Processes specification and WPS 2.0 schemas.

  9. The Catalogue Services SWG should reconcile the time and bbox related search parameters from the OGC OpenSearch Geo and Time Extensions (OGC 10-032) and the OGC API - Features specification (OGC 17-069r2).

  10. Future OGC hackathons should be three days long, if possible, and allow a larger amount of time to be spent in shared sessions where portions of the OGC API - Common specification can be discussed and their suitability to the various services verified.

It is envisaged that the output of the hackathon will be instrumental to the evolution of OGC web service standards to a modern API-based approach, setting the course for open geospatial standards for the next decade. The output should lead to a solid, common core and advancement of a whole new generation of OGC standards that are flexible in modern IT environments. This does not mean that existing OGC web service standards will fade away. Instead, it means that a new suite of OGC standards will give developers and users the option of leveraging capabilities offered by Web APIs.

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

Scott Simmons

Open Geospatial Consortium

Contributor

George Percivall

Open Geospatial Consortium

Contributor

Michael Gordon

Ordnance Survey

Contributor

Simon Green

Ordnance Survey

Contributor

Clemens Portele

interactive instruments GmbH

Contributor

Jorge Samuel Mendes de Jesus

ISRIC - World Soil Information

Contributor

Peter Baumann

rasdaman GmbH

Contributor

Francesco Bartoli

Geobeyond

Contributor

Dirk Stenger

lat/lon GmbH

Contributor

Chuck Heazel

Heazeltech LLC

Contributor

Matthias Mohr

University of Münster

Contributor

Robin Houtmeyers

Hexagon Geospatial

Contributor

Jonathan Moules

GeoSeer

Contributor

Gérald Fenoy

GeoLabs

Contributor

Brad Hards

Sigma Bravo

Contributor

Chris Little

Met Office

Contributor

Yves Coene

Spacebel

Contributor

Adam Branscomb

Esri UK

Contributor

Adam Martin

Esri

Contributor

Joan Masó

CREAF

Contributor

Stephan Meißl

EOX

Contributor

Tom Kralidis

Open Source Geospatial Foundation (OSGeo)

Contributor

Alexander Jacob

Eurac Research

Contributor

Brian Osborn

CACI

Contributor

Robert St. John

CACI

Contributor

Jerome St-Louis

Ecere

Contributor

Andrea Aime

GeoSolutions

Contributor

Sam Meek

Helyx SIS

Contributor

Panagiotis (Peter) A. Vretanos

CubeWerx Inc.

Contributor

Alexander Lais

Solenix

Contributor

Benjamin Proß

52°North GmbH

Contributor

Antonio Cerciello

GeoCat

Contributor

Jody Garnett

GeoCat

Contributor

Paul van Genuchten

GeoCat

Contributor

Marian Neagul

West University of Timisoara

Contributor

Anze Skerlavaj

Sinergise

Contributor

Danilo Bretschneider

Cologne Government Regional Office - Geobasis NRW

Contributor

Note
Role = Editor and/or Contributor

2.2. Team Leads

The following table lists the Hackathon Team Leads and their affiliated working groups.

Team Leads

Name Working Group Team

Clemens Portele

WFS/FES SWG

OGC API - Features

Chuck Heazel

OWS Common SWG

OGC API - Common

Joan Masó

WMS SWG & OWS Common SWG

OGC API - Map Tiles & OGC API - Common

Stephan Meißl

WCS SWG

OGC API - Coverages

Benjamin Proß

WPS SWG

OGC API - Processes

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

The following normative documents are referenced in this document.

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.

● application programming interface

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)

● feature

abstraction of real-world phenomena (source: ISO 19101-1:2014)

● OpenAPI definition | OpenAPI document

a document (or set of documents) that defines or describes an API and conforms to the OpenAPI Specification [derived from the OpenAPI Specification]

● Web API

API using an architectural style that is founded on the technologies of the Web [derived from the W3C Data on the Web Best Practices]

Note
Best Practice 24: Use Web Standards as the foundation of APIs in the W3C Data on the Web Best Practices provides more detail.
● commit

As a noun, a commit is a single point in the Git history that represents a "revision" or "version" [derived from https://git-scm.com/docs/gitglossary].

● coverage

feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain, as defined in OGC Abstract Topic 6 (OGC 07-011).

● Regular grid

grid whose grid lines have a constant distance along each grid axis

● process

A process p is a function that for each input returns a corresponding output

processterm

where X denotes the domain of arguments x and Y denotes the co-domain of values y. Within the Web Processing Service (WPS) standard, process arguments are referred to as process inputs and result values are referred to as process outputs. Processes that have no process inputs represent value generators that deliver constant or random process outputs.

● service

distinct part of the functionality that is provided by an entity through interfaces (source: ISO/IEC TR 14252)

● operation

specification of a transformation or query that an object may be called to execute (source: ISO 19119:2016)

● request

invocation of an operation by a client

● response

result of an operation, returned from a server to a client

4.1. Abbreviated terms

API Application Programming Interface CRS Coordinate Reference System CSW Catalogue Service for the Web GML Geography Markup Language HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol JSON JavaScript Object Notation WCS Web Coverage Service WFS Web Feature Service WMS Web Map Service WMTS Web Map Tile Service WPS Web Processing Service OWS OGC Web Services REST Representational State Transfer XML Extensible Markup Language

5. Overview

Section 6 introduces the OGC API Hackathon by describing the challenge, the scenario adopted, and the infrastructure used by the participants. The section also presents overviews of the datasets and services identified to support participants during the Hackathon. The section also presents a list of the organizations represented by the participants.

Section 7 describes each of the OGC API specifications that were involved in the hackathon.

Section 8 presents the solution architecture developed in this hackathon. The section identifies the client and service implementations of the OGC API specifications.

Section 9 documents the results and provides a summary of what occurred during the event.

Section 10 provides a summary of the main findings, as well as discussing the experiences and lessons learnt.

Appendix A describes implementations from many of the participating organizations, as well as their motivation for participating, suggestions for alternative approaches, their experiences, impressions and recommendations.

6. Introduction

The development of OGC API specifications is not a new activity within the Consortium, as OGC members and staff have been investigating OpenAPI (and its commercial equivalent, Swagger) in a concentrated effort since 2016. This effort was the result of a recognition that although the existing OGC web service standards are in effect web APIs, there are approaches adopted by modern web API frameworks that would require a fairly fundamental change in underlying design.

Two documents really provided the initial energy to get serious about redesign: the OGC Open Geospatial APIs White Paper, edited by George Percivall [1], and the Spatial Data on the Web Best Practices, jointly developed by OGC and the World Wide Web Consortium (W3C) [2]. These documents highlighted how geospatial data should be more native to the web. Further, OGC staff were working on “implementer-friendly” views of OGC standards and experimented with an OpenAPI definition for the Web Map Tile Service (WMTS).

But perhaps the most important impact was the leap of the OGC Web Feature Service (WFS) and Filter Encoding Service (FES) Standards Working Group (SWG) that rebuilt the WFS standard with an integrated OpenAPI definition as core to description of how to build against the standard. The work on WFS, which has resulted in the OGC API - Features specification (formerly called WFS 3.0), benefited from a two-day Hackathon held in 2018. Since then, other OGC web service SWGs have begun to independently develop API specifications based on their relevant OGC web service standards.

Numerous discussions occurred at OGC quarterly Technical Committee (TC) Meetings to consider those elements being developed in each SWG which should be common to all web API standards. These discussions came to a head at the February 2019 TC Meeting in Singapore, where a series of working group meetings and common sessions for the whole TC Membership reinforced the desire to work on a common framework for many OGC web standards and to develop a nomenclature for labeling these standards. Thus, the pattern “OGC API - [resource]” was coined. The discussions in Singapore also resulted in the planning of the OGC API Hackathon to define and test common elements from Coverages, Map Tiles, and Processing standards work using foundational material from the Features work.

The OGC API Hackathon 2019 was hosted by the Geovation Hub in London, United Kingdom, from 20 to 21 June 2019. The hackathon was sponsored by the European Space Agency (ESA), Ordnance Survey and Geovation. The hackathon was also supported by the US National Geospatial Intelligence Agency (NGA). The goal of the hackathon was to advance the development of OGC API specifications. The aim of the hackathon was to provide an environment and an opportunity for the geospatial community to achieve this goal.

The objectives of the hackathon were set out to:

  • develop, deploy and test services/clients that support OGC APIs;

  • suggest improvements for a common core;

  • define rules/guidance that can be documented;

  • validate work that has been completed to date; and

  • contribute to the GitHub repositories.

6.1. Overview of the Challenge

The challenge of the Hackathon was to define and test common elements from Coverages, Map Tiles, and Processing standards work using foundational material from the Features work. The magnitude of this challenge was reflected by the fact that the OGC API specifications for Coverages, Map Tiles, and Processing were all at different stages of development. Therefore, the Hackathon had to advance the development of all of the specifications to a stage where common elements across all of the specifications could be identified.

6.2. Scenario

To facilitate the development of the OGC API specifications, the scenario presented in this section was provided as a reference for the teams [3]. The scenario is based on flood risk management and is motivated by recent events such as the 2018 floods that affected parts of Europe (including the United Kingdom, Italy, France, Spain and Portugal) [4] and the 2019 floods that affected parts of the United States [5]. The scenario draws from the OGC’s Disasters Interoperability Concept Development Study (CDS) which assessed geospatial Web services across the disaster domain, defining the core components of National Spatial Data Infrastructure (SDI) architecture for disasters (Disasters SDI), and defining use cases and scenarios for future implementations as part of a follow-on pilot phase [6].

Risk mitigation is one of the phases in the ‘life cycle’ of disaster management [6], which includes the steps shown in Figure 1. Mitigation refers to taking sustained actions to minimize or completely eliminate the long-term risk from hazards and their effects on individuals and property. Preparedness refers to building the emergency management capabilities to respond effectively to any hazard, as well as to recover from the hazard. Response refers to conducting emergency operations that reduce the hazard to acceptable levels (or eliminate it entirely) in order to save lives, through evacuation of potential victims, and provision of food, water, medical care, and shelter to those affected by the disaster. Recovery refers to the rebuilding of communities that have been affected by a disaster so that those communities, as well as their governments, can return to normality and function on their own. A more detailed discussion on disaster management can be found in the OGC Development of Disaster Spatial Data Infrastructures for Disaster Resilience Engineering Report [6].

disastermgmtcycle2
Figure 1. Disaster management cycle

As part of Government flood risk management policy, Local Authorities have to carry out a preliminary flood risk analysis. Using satellite imagery, flood risk data, along with asset information, vulnerable property information and topographic data, Local Authorities carry out analysis to improve resilience and promote a more efficient use of resource.

A Local Authority is tasked with identifying at-risk residential properties in order to assist in flood prevention and amelioration. By carrying out this task, the Local Authority aims to reduce the number of residential properties affected by floods, as well as to decrease the economic and social costs associated with such devastating events. The Geospatial Specialists at the Local Authority embark on the steps presented in Table 1 in order to carry out the task.

Table 1. Steps in the flood risk management scenario
Step Description Notes

1

Receive satellite imagery, digital terrain model, Flood Risk Zone, address, and topographic data

2

Overlay flood assets such as culverts, levees etc.

3

Combine multiple datasets together.

4

Data analysis to assess/quantify flood risk.

A number of hydrology approaches may be applied e.g., run-off modeling

5

Identify at risk properties and possible remediation strategies.

6

Execute cost-benefit analysis to determine priorities.

7

Commission work for on-the-ground implementation. This may be carried out by internal or external teams.

8

Impact of remediation work assessed by external engineering consultant.

The illustration in Figure 2 shows the Area of Interest (AOI) that was selected to facilitate prototyping, demonstration and briefings. The AOI covered the region of Carmarthenshire, Wales and focused on the town of Carmarthen. The region was the site of significant flooding in October 2018 and hence provided an appropriate location for the flood-based scenario adopted for the Hackathon.