OGC API Hackathon 2019 Engineering Report

The following datasets were identified as relevant to the scenario, and thus recommended for testing implementations of the specifications.

The following services were identified as relevant to the scenario, and thus recommended for testing implementations of the specifications.

Participants were advised to bring their own laptops to the hackathon. To support testing, the following infrastructure options were available to participants:

A summary of the paths offered by the OGC API - Common specification is presented below:

A summary of the paths offered by the OGC API - Features specification is presented below:

Support for HTML and JSON/GeoJSON as encodings is recommended for all resources. The specification includes conformance classes for GML (Simple Features profile), too.

A summary of the paths offered by the OGC API - Processes specification is presented below:

A summary of the paths offered by the OGC API - Map Tiles specification is presented below:

A summary of the paths offered by the OGC API - Coverages specification is presented below:

The pygeoapi server is a Python implementation of the emerging OGC API specifications. It is available from https://github.com/geopython/pygeoapi. Early versions of this software implemented the OGC API - Features specification (formerly WFS 3.0). Recent versions of the software have included support for both the OGC API - Features and the OGC API - Processes specifications. Support for these specifications make it possible publish feature data and geospatial processes. As the name suggests the software is built using the Python programming language and is supported by a developer toolchain that includes Docker and Git/Github.

The 52°North JavaPS product is an open source implementation of both the Web Processing Service (WPS) standard and the OGC API - Processes specification. It is available from https://github.com/52North/javaPS. JavaPS enables the deployment of geospatial processes on the Web in a way that conforms to OGC standards. The software is built using the Java programming language and is supported by a developer toolchain that includes Maven and Git/Github. The software features a pluggable architecture for processes and data encodings that is based on the 52°North Iceland project which represents a generic Java framework for OGC Web Services. By virtue of being based on the Iceland project, JavaPS provides components that are associated with processing geospatial data, for example request objects, response objects, decoders, encoders, parsers.

Esri produce both an installable product (ArcGIS Enterprise) and a Software-as-a-Service (SaaS) product (ArcGIS Online) which support adopted OGC specifications. ArcGIS Enterprise as a server implements WMS, WMTS, WCS2, WPS, WFS2, KML, GeoPackage etc as well as other de-facto standards. ArcGIS Online as a server implements WMTS, WFS2 as well as other de-facto standards.

Until the OGC API standards are stable and formally adopted, it is not feasible to implement them in the released products. Therefore, for the purposes of the Hackathon and further Research and Development (R&D), Esri have implemented the OGC API - Map Tiles specification as a facade on to ArcGIS Online tiled services. Technically this is currently implemented as a node.js server running in Microsoft Azure. https://ogc-tiles-esri-server.azurewebsites.net

The rasdaman ("raster data manager") product is a flexible, scalable datacube engine with location-transparent federation capabilities. Open-source rasdaman is available from www.rasdaman.org. Being a WCS reference implementation rasdaman supports OGC WMS, WCS, and WCPS (the OGC datacube analytics standard). For experimentation with the emerging OGC API for coverages, a rasdaman server has been made available on Amazon with an OpenAPI facade to WCS; access has been demonstrated with EURAC and Sinergise OpenAPI clients.

ldproxy is an implementation of the OGC API family of specifications, based on the W3C/OGC Spatial Data on the Web Best Practices. It is 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" plus a number of experimental OGC API Features extensions (CRS support, /items path, property selection, geometry simplification, transactions, dynamic links, and more). ldproxy also has draft implementations for additional resource types (Tiles, Styles).

The Helyx team implemented a service that conformed to the OGC API – Processes specification (formerly referred to as WPS 3.0) with the primary work completed in the OGC Routing API Pilot, which is currently on-going. The focus of the component implementation was to produce a schemaless collections endpoint to act as a storage location for data production processes capable of supporting data provided by WPS or those provided by WFS.

An advantage of the schemaless (and in the future, potentially serverless) approach is the efficiency of the hashing procedure enabling many Key-Value Pairs(KVPs) to be entered even on a low spec machine. Additionally, this approach has the potential to be made production-ready quickly due to the simplicity of the implementation requirements. A future possibility for this piece of work is to implement it using Hazelcast, as it backs up KVPs to a NoSQL database therefore caching the requests and increasing performance accordingly.

The ZOO-Project product, available at www.zoo-project.org, is an open-source implementation of both the Web Processing Service (WPS) standard (version 1.0.0 and 2.0) and the OGC API - Processes specification. The ZOO-Kernel is the main component written in C which enables the deployment of geospatial processes on the Web in a way that conforms to OGC standards. The geospatial processes are named ZOO-Services and can be implemented in various programming languages (C/C++, Fortran, Java, Python, C#, JavaScript, Perl, R, PHP, Ruby). ZOO-Kernel also supports the deployment of existing Open-Source GIS applications such as OrfeoToolBox and SAGA-GIS. Optionally the execution of OrfeoToolBox applications can be done remotely on an HPC server using SLURM scheduler.

EOxServer (http://eoxserver.org) was started more than 10 years ago as a reference implementation of WCS in particular the Earth Observation Application Profile (EO-WCS).

Support for the OGC API - Coverages draft was implemented in EOxServer in the OpenAPI branch (https://github.com/EOxServer/eoxserver/tree/openapi).

A demonstration using the provided Sentinel-2 data is available online at https://ows.eox.at/openapi/ and integrated in the Sinergise OGC Coverages Demo Client.

The GNOSIS Map Server is written in the eC programming language and currently implements WMTS, WFS, as well as prototyped support for the new OGC API. It supports multiple encoding 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 http://maps.ecere.com/geoapi and used for interoperability experiments in multiple OGC initiatives.

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. Currently the server implements WMS, WMTS and partially implements WFS and WCS. It also partially implements the OGC Sensor Observation Service (SOS) standard. In order to perform efficiently, it requires a process preparing the data to be offered. It can interoperate with other vendors clients but combined with the MiraMon Map Client it offers more functionality, including functionality recently developed for the Catalan Data Cube.

The software originally started 10 years ago as a WMS server in support of the Catalan Administration and CREAF data services.

It includes prototype support for the draft OGC API - Map Tiles specification.

The CubeWerx server ("cubeserv") is implemented in C and currently implements the following OGC web services.

The cubeserv executables supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also support a wide array of service-dependent output formats (e.g. GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.

OpenSphere is a pluggable, single-page, GIS web application that supports both 2D and 3D views. It supports binding to many popular servers and formats such as ArcGIS, GeoServer (and other OGC WMS/WFS services), XYZ, TMS, KML, GeoJSON, Shapefiles and CSVs. Other features include animation of both raster and vector data, import and export of various formats, and saving files and layers between sessions. Sigma Bravo extended OpenSphere to support OGC API - Features and OGC API - Map Tiles.

LuciadLightspeed provides a foundation for advanced geospatial analytics applications. It allows users to create high performance command & control and location intelligence applications with clean design implementation and rapid application development. A desktop client application was implemented using LuciadLightspeed and configured to interface services implementing the OGC API - Map Tiles specification.

The Solenix WPS Demo client is an adaptation of the OGC Testbed 14 client, accounting for some of the changes introduced with the OGC API - Processes specification. The client application runs from a web browser and connects to servers that conform to the OGC API – Processes specification.

A total of 7 servers were connected during the Hackathon, providing the participants with the scenario of a client running in the web browser served via HTTPS and the resulting security rules. The client was used during the Hackathon to debug server implementations, and in particular the Cross Origin Resource Sharing (CORS) behavior in web browsers.

The Esri client application is a simple Leaflet application which connects to the Esri OGC API - Map Tiles server implementation for testing purposes.

The Sinergise OGC Coverages Demo Client is a single-page Javascript application, using Leaflet.js to show the data from different backends. Support for two different backends was implemented, rasdaman and EOxServer from EOX IT Services GmbH. The frontend is available at http://webdev.sentinel-hub.com/ogc-hackathon/index.html (view source for additional info).

Helyx produced two clients as part of the hackathon, one standalone web client and one QGIS client. The Standalone Web Client was implemented with the purpose of providing a walkthrough of the OGC API to discover processes. The web client, which was implemented using JavaScript, was able to identify the inputs and outputs of each process, request inputs from the user, execute a process and display the result. The QGIS client performed a similar function to the web client, except it was designed and built in the QGIS plugin environment. The QGIS client walks through the API and identifies processes and parameters to automatically populate the Graphical User Interface (GUI) for each process therefore providing the user with well-defined inputs.

The ZOO-Project provided a Swagger demonstration interface which can be found at https://demo.mapmint.com/swagger-ui/dist. A demonstration user interface based on interfaces available at www.zoo-project.org was also provided. It is available here: https://demo.mapmint.com/examples3/spatialtools.html. It can be used to invoke execution of 4 services using the OGC API - Processes. The ZOO-Project also provided an Orfeo ToolBox application named BandMath. Orfeo ToolBox is an open-source project for state-of-the-art remote sensing, including a fast image viewer, apps callable from Bash, Python or QGIS, and a powerful C++ API.

The GNOSIS Software Development Kit is written in the eC programming language and currently implements client support for WMS, WMTS, WFS, as well as prototyped support for the new OGC API. Through an automated bindings generator part of the open-source Ecere SDK, the GNOSIS SDK is also made available to a growing list of other programming languages currently including C, C++ and Python. Clients written with the GNOSIS SDK, such GNOSIS Cartographer, can render styled geospatial views using cartographic or 3D perspective projections, with support for Virtual, Augmented and Mixed Reality.

The MiraMon Map Client is a pure JavaScript client that is part of the MiraMon GIS & RS suite. It currently implements WMS, WMTS and partially implements WFS, WCS and SOS. For all protocols it uses OGC standards as a communication platform without any intermediate encoding of protocol. It can interoperate with other vendors' services but combined with the MiraMon Map Server it offers more functionalities, including functionality recently developed for the Catalan Data Cube. It is an open source software product that can be downloaded from here: https://github.com/joanma747/MiraMonMapBrowser

The software originally started 10 years ago as a web portal in support of the Catalan Administration’s open data policy.

TEAM Engine (Test, Evaluation, And Measurement Engine) is a Java-based application for testing web services and other information resources. It executes test suites developed using the popular TestNG framework, OGC Compliance Test Language (CTL) scripts, and possibly other JVM-friendly languages. It is lightweight and easy to run from the command-line or as a web application.

TEAM Engine can be used to test almost any type of service or information resource. It is the official test harness used by the Open Geospatial Consortium’s (OGC) compliance program. Visit the project documentation website for more information.

Currently, there is a test suite available to verify "OGC API - Features" service implementations. The test suite is written in Java using the TestNG framework and source code is publicly available. Also, there is a public installation of the test suite on OGC CITE Beta environment.

The decision to hold the OGC API Hackathon was made by the TC at the 2019 TC meeting in Singapore. Following this decision, OGC staff engaged a number of potential sponsors from the OGC membership. Having identified sponsors and hosts, a series of teleconferences were held for planning the event. These teleconferences discussed venue logistics, computing infrastructure, data, scenarios, catering and other topics. A Gantt chart of the planning and execution of the hackathon is shown in Figure 5.

During the hackathon, the process involved alternation between briefings, discussions and coding. On the first day of the hackathon, three back-briefs were held, that is one in the morning, another in the afternoon and another in the evening. These briefings provided an opportunity for issues to be discussed across teams. Agreements and resolutions from the discussions triggered by the briefings were then fed back into the team-specific work.

The agenda for the hackathon is presented below.

By the event date, 76 individuals had been registered to participate in-person and 35 participants had been registered to participate remotely. On the event date, 64 individuals participated in person and more than 10 participated remotely. 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. The proportion of OGC members to alliance partners and non-members is illustrated in Figure 6.

A questionnaire sent out just before the hackathon to collect information about which OGC API specifications the participants would focus on received 27 responses. The spread of responses to the hackathon is shown in Figure 7.

The hackathon was therefore organized around teams based on the OGC API specifications. Participants interested in APIs other than those for coverages, processes, and map tiles, were asked to contribute to the work on advancing the OGC API - Common specification. This would help ensure that the OGC API - Common specification provides an appropriate a base for all future OGC APIs.

The client and service applications were bound together through interfaces conforming to the OGC APIs for Map Tiles, Processes, Features, Catalogues, and Coverages. The client applications included software from Hexagon, Helyx, OpenSphere, Esri, Solenix, EURAC and Sinergise. The service applications included software from 52 North, CubeWerx, Esri, Helyx, pygeoapi, Geoserver, Spacebel, West University of Timisoara, rasdaman, interactive instruments, EOX, and Ecere. The variety of software implementations suggests that the OGC API specifications widely implementable and do not depend on any single vendor’s technology.

As discussed in Architecture, the software products that were deployed by the aforementioned organizations included:

The deployed technologies included software implemented in C, C++, eC, Python, Java, and NodeJS. Some of the deployed technologies include Python adapters to software implemented in C++. This variety of programming languages shows that the OGC API specifications are independent of any programming language.

Two of the participants expressed concerns that the duration of the hackathon was rather short. There was a suggestion that a minimum of three days may have been more appropriate. To an extent, the approach taken to incrementally ramp up towards the hackathon date addressed some of these concerns. However, it is accepted that a three-day hackathon could have led to more outputs. A three-day hackathon could cover the following, for example:

It cannot be ignored that the scheduling of the hackathon during the week preceding the OGC TC meeting in nearby Leuven made it possible for some of the participants to travel to both events. This aspects of the scheduling made a difference for participants that had travelled from abroad. In some cases however, the scheduling meant that some interested parties could not attend the hackathon due to its proximity, in scheduling, to the TC meeting. Overall however the proximity to the TC meeting proved to be helpful.

In some hackathons prizes are awarded, ranging from a few hundred to a million dollars (USD). In organizing the OGC API Hackathon, OGC staff considered the goal of the hackathon in relation to the likely motivation of participants. Given that the goal of the hackathon was to advance the OGC API specification, collaboration between different organizations became a key consideration. A decision was therefore made to offer travel support to any participants that applied for such support, instead of offering a competition prize. A review of the motivation for various participants to take part in the hackathon supported this decision. Below are some examples of the motivation of some of the participants to participate, extracted from Implementations of OGC APIs:

The sample of statements presented above suggests that the advancement of open standards, on its own, can be useful as a motivator for participation. In situations where collaboration across organizations is not a key consideration, a competitive hackathon offering prizes would be appropriate.

One of 52°North’s core topic is Web-based processing of geospatial data. Currently, 52°North leads the development of the OGC API – Processes standard within the OGC WPS SWG. 52°North aimed to use the hackathon to:

52°North implemented and deployed an instance of the 52°North JavaPS software, which is an implementation of the OGC Web Processing Service (WPS) standard and the OGC API - Processes specification. A screenshot of the deployed service is shown in Figure 10. The software was configured to offer an interface that conforms to the OGC API - Processes specification.

The implementation is available at http://geoprocessing.demo.52north.org:8080/javaps/rest/

Figure 11 shows a simple user interface to submit new processing jobs.

The following points were discussed:

52°North uses the OGC API - Processes in a variety of projects and considers the specification to perform well. The API is also heavily used by other participants e.g. in the OGC Testbeds. The JSON is lightweight and 52°North considers the JSON to be more readable than the XML. The links in the JSON let the users/clients easily find the relevant resources, e.g. from the list of processes, to a single process description, and then to the job submission. The HTML encoding also increases usability, e.g., letting the user quickly submit jobs via a lightweight HTML POST client.

The hackathon was very well-organized and it was good to see so many people interested in the API development. 52°North recommends holding similar hackathons more regularly in order to get developers from outside the OGC involved in the standardization process early. The OGC API – Processes specification now has several implementations and the editor has received valuable comments. This gives fresh impulse to continue the work on the API and to eventually finalize it.

CREAF’s main motivation was to contribute to the next generation of OGC standards. The CREAF team wants to bring in their expertise gathered over the years in both writing and implementing OGC standards such as WMS, WMTS, WCS, WPS, etc.

Also, CREAF wants to make a case for having an OGC API - Common standard that can be the basis for other OGC API standards. OGC API - Common should be based on the common parts of the current OGC API Features. In addition, CREAF wants to propose a merge of WMS and WMTS in a single OGC API modular standard based on the proposed OGC API - Common specification, as well as to follow the progress of other groups.

CREAF implemented a limited version of the draft OGC API - Map Tiles specification in the MiraMon Web Server and was able to offer data of the UK area-of-interest supplied by the organizers. CREAF also modified the MiraMon Web Client to be able to support the new API syntax for getting a map.

A demonstration of the OGC API - Map Tiles implementation, using the data provided for the scenario, is available online at http://www.ogc.uab.es/OGCHackanthon/

During the hackathon the idea emerged of a map that can be created by applying a style and then requested as tiles. This way, tiles emerged as a building block that can be added to other resources and maps are just another data resource. Actually, the possibility of combining implementations of an OGC API for tiles with other APIs was already demonstrated in the OGC Vector Tiles Pilot [21]. The OGC API - Map Tiles specification is designed in a way that its implementations can also be combined with implementations of the OGC API - Coverages specification to retrieve small tiles of the gridded data (e.g. in GeoTIFF format).

The main issue with the current approach of combining maps and tiles in a single standard is modularity. There is a need for further discussions on how to divide the specification into small pieces (conformance classes) that can be combined in different ways.

The OGC API - Features specification defines a collection as a set of 'items' (a.k.a features). During the hackathon it became clear that the concept of "collection" needs to be generalized to any type of data type, for example coverages. After the hackathon, the discussion continued and it was proposed that, in some cases, the very same collection could be requested as features, a coverage, a map, etc.

CREAF has from the beginning been committed to complying to and improving OGC standards. UAB-CREAF has been an OGC member for more than 10 years and, at present, UAB-CREAF has produced several standards that mainly relate to WMTS but also with WCS and JPEG2000. UAB-CREAF has participated in eight OGC Innovation Program initiatives producing many Engineering Reports.

For more than 10 years, CREAF has been committed to developing an integrated 2D client that is based on OGC standards (including WMS, WMTS, WCS, WFS and SOS). The client application can be downloaded from here: https://github.com/joanma747/MiraMonMapBrowser

CREAF’s impression is that the OGC TC process provides a forum for discussing standards but the length of the sessions it too short for doing actual writing work. The Interoperability Experiments run for about nine months, providing enough time to develop and test implementations and demonstrate interoperability but they might not be agile enough. The hackathon format is great to bring representatives from the various groups at OGC around the table to get to a common understanding on the OpenAPI standards and to start modifying current implementations to adapt to the new OGC API requests and responses. OGC APIs are based on OpenAPI that is a description language (service metadata). During a two-day event, it is not possible to fully develop a server that produces OpenAPI documents automatically or a client that read and act upon them. As a result, only the most direct approach can be implemented leaving out most of the details. It is important that all that was discussed and started to be implemented at the hackathon continues in other activities so that it can result in something applicable and comprehensive.

The current work in OGC to define a new OWS Common is based in large part on the work done by the WFS/FES SWG for the "OGC API - Features - Part 1: Core" specification. Since CubeWerx is a co-editor of that document, CubeWerx wanted to be present at the hackathon in order to monitor and participate in the validation of the common aspects of the OGC API – Features specification that are relevant to other OGC web services such as WPS and catalogue.

For the last few OGC testbeds, CubeWerx has participated in the Earth Observation Cloud (EOC) threads developing an Application Deployment and Execution Service (ADES) which is based on WPS. In the last round (OGC Testbed-14), the thread developed a REST/JSON binding for the WPS API which CubeWerx implemented. This API, however, is different than the REST/JSON binding currently being developed for the WPS API by the WPS SWG. So, a primary motivation for CubeWerx’s participation in the API hackathon was to update our current WPS' REST/JSON API to match the API currently being developed by the WPS SWG.

CubeWerx has been involved with the WFS from its very beginning in OGC and has implemented most draft and adopted versions published by OGC including the latest "OGC API - Features - Part 1: Core" version. CubeWerx has also participated in a number of WFS-related hackathons, using each opportunity to test and refine CubeWerx’s implementation. The OGC API hackathon provided a further opportunity for CubeWerx to make final adjustments to its implementation based on the very latest version of the "OGC API - Features - Part 1: Core" draft standard.

CubeWerx has been involved with the web-based OGC catalogue for many years and was a co-editor of the OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding. CubeWerx has implemented every draft and adopted version of this specification using ebRIM as its information model. For the past several months, CubeWerx along with a number of other OGC members has been working to form a new catalogue SWG whose primary task would be to update the OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding based on the new OGC API framework. The hackathon provided an opportunity for CubeWerx to meet with other interested participants, present the current state of the OGC API catalogue work and further discuss the development of the API and the charter for a new SWG.

CubeWerx OGC web services are implemented in C as part of a single executable named "cubeserv." In preparation for the hackathon, CubeWerx deployed a couple of WFS’s and a WPS. During the hackathon, the implementations were updated in real time based on feedback from other participants using the services.

As has been mentioned or implied thus far, CubeWerx is transitioning its implementations of OGC web services to also support the new OGC API framework. Thus far, CubeWerx have implemented the "OGC API - Feature - Part 1: Core" release candidate and have also implemented a significant number of extensions for WFS 3.0 using the OGC API framework. CubeWerx have also implemented the REST/JSON binding of the WPS and have started implementing a catalogue based on the API defined be the CAT 4.0 group.

CubeWerx’s experience thus far is that services based on the new OGC API framework are easier and quicker to implement than services based on previous OGC web service specifications.

CubeWerx have also deployed services based on the OGC API framework into various projects and their experience has been that, from a client perspective, the behavior of the services is much more predictable and stable thus making the development of clients significantly simpler than was the case using the old OGC web service architecture.

CubeWerx is very encouraged to see that OGC is, in a manner of speaking, returning to its roots where software and specifications are developed concurrently so that specifications are validated in code. These implementation-driven hackathons are, in our opinion, a key element in defining specifications that are developer-friendly and will thus be adopted and implemented by the wider web community.

The motivation for Geobasis North Rhine-Westphalia (NRW) was to implement OGC specification for Map Tiles in their application TIM-online 2.0 and to getting more information about the work in working groups.

During the OGC API Hackathon event in London, Geobasis NRW implemented the OGC API - Map Tiles specification by using the web service provided by ESRI (https://ogc-tiles-esri-server.azurewebsites.net/api/).

Before the OGC API Hackathon, Geobasis NRW implemented the OGC API – Features specification by using ldproxy (https://www.ldproxy.nrw.de/). Have a look on the functionality:

Implementation available: https://www.tim-online.nrw.de/ogc-hackathon/

Ecere feel the most important goal that the OGC API has the potential to achieve is unifying access to different types of geospatial data through a modular, simple and consistent interface. Ecere are of the opinion that the great variability and separate nature of classic OGC services types (WFS and WCS in particular being completely distinct from W(M)TS) has been problematic and holding back direct access to raw data. The OGC API can address these issues, making it much easier to work with raw data and therefore enabling more efficient and more flexible client-side maps rendering, which is especially important for 3D views. As a result of our work on Vector Tiles in Testbed 13, Ecere had proposed back in 2017 the concept of a Unified Map Service (UMS) as a very simple example of how these challenges might be addressed.

For these reasons, Ecere were keen to participate in this hackathon. Our focus during the hackathon has been on contributing ideas and suggesting ways the modularity (building blocks approach) and consistency for different geospatial data types (vector features, coverages — gridded in particular, imagery) can be maintained. Ecere primarily interacted with the Maps and Tiles group, as well as the Processes group.

Ecere also wanted to take the opportunity to complete support for the OGC API in the newest iteration of our GNOSIS geospatial software (both clients and services).

During the hackathon, Ecere made great strides of progress towards our new OGC API service and clients, which Ecere have continued improving since. The latest version of our experimental service is hosted at http://maps.ecere.com/geoapi/ and our client applications are being used in OGC Innovation Program activities such as the Routing pilot and Testbed 15, for which demonstration videos will likely be published as the initiatives conclude.

Ecere have previously implemented server-side support for WMTS and WFS, and client-side support for WMS, WMTS and WFS. Ecere also regularly attend Technical Committee meetings and participated in several OGC Innovation Program initiatives. Ecere are looking forward to fully supporting all of the common modular blocks of the new OGC API, and hope to achieve compliance as the specifications are finalized.

On the topics of Map and Tiles, Ecere were strongly recommending to split them as separate building blocks: Maps, and Tiles. This is because Tiles can be used to deliver data, whether it is a rendered map, vector features or a gridded coverage. And rendering maps can be used independently from tiles. Ecere are happy that the specifications seems to be heading this way. Ecere also highlighted the fact that rendering Maps on the server is in fact a process, and that a good Processes API should easily be usable for the foundation of such a Maps API. The characteristics of such a Process API would also be beneficial, in many other use cases, as described below.

Ecere submitted a new idea to the OGC API - Processes GitHub repository, discussing how to achieve highly scalable and flexible processes that can be chained together and are centered around 'Collections' as inputs & outputs.

One might see a process as acting on 0, 1 or multiple "collection" (data) input, possibly in addition to parameters, and outputs 0, 1 or multiple "collection" (data) outputs.

In addition to nicely tying OGC API - Processes with Features and Coverages, it makes daisy chaining very easy to accomplish.

The "data delivery" building blocks (e.g. Features & Coverages) provide the mechanisms by which to identify "collections" of vector features or grid cells (data), and retrieve them. Built-in space partitioning mechanism such as bounding boxes or more complex sub-setting can be used to efficiently retrieve part of the data, or special building blocks such as Tiles or DGGS can offer additional exchange mechanisms. This makes processes highly scalable as different tiles, DGGS cells or subsets of the data could be processed in a massively parallel manner, all through a potential chain of processes. The specific space partitioning modular API blocks (e.g. Tiles or DGGS cell), or the base Features/Coverage mechanisms can be negotiated at any exchange level throughout the chain.

Since it seems that the community has to stick with the generic but loaded term of "collections" e.g., for OGC API - Features, Ecere consider that it would be a mistake to overload the term of "collection" with a meaning other than a "set of geospatial data with particular characteristics", such as a generic group of things (e.g., a list of available processes). One can imagine the confusion if what OGC processes do is act on "collections", while "collection" is also used to mean a regrouping of multiple processes.

A simple example is vectorization of a Digital Elevation Model (DEM). You have a collection representing a DEM (it is important here that the level of a "collection" should represent a "collection of gridded cells", not a collection of a collection of gridded cells, unless said collection of collections is intended to be treated as if the cells were all together in one single DEM layer). This is your input collection to a "vectorization" process. You invoke it with parameters, and you get a "vector" collection back. You can then chain another process working on a vector collection.

It can also be seen that rendering a "map" (as in the Maps API) is clearly a process rendering 1 or more "collections", taking a style as parameter, and producing an imagery ((A)RGB natural color image) "collection" as an output (the rendered map). The result can be retrieved through various data partitioning mechanisms (e.g., bounding box, or tiles), and the process can be optimized to render portions as required, cached, in parallel, etc.

Ecere think it makes a lot of sense for OGC API - Processes to support both synchronous (POST and get the 200 output result) and asynchronous modes, Maps and Routes being an important example of how this is useful for simple POST requests returning an output collection (e.g., a route or rendered map) right away.

There could be standardized "well known" processes such as the Maps Rendering process, the Routing process (open routing pilot), Vectorization process, etc., which would further greatly enhance interoperability and choreography of different processes. Most processes would also provide the output in a "collection" interface, which any other process, data delivery, or geospatial viewer supporting the OGC API would readily support. This also makes it possible to only process data on an as-needed basis, e.g., when first visualizing the output (or being requested by further down the raw data-process-visualization daisy chain) for a certain area or resolution level.

The concept of workflow could be simply described as a chain of OGC API resources and parameters. The actual communication between any 2 services in the chain can be negotiated (e.g., supporting tiles, supporting DGGS, supported data formats), and need not be included in that workflow description, so that alternate implementations with different support could apply the same workflow. All this makes for a great universal geospatial processing framework by which all processes and data collections become readily compatible, and one can easily discover and combine data sets from all over and using processes hosted anywhere.

Additional background can be found in another idea submitted to the OGC API - Common repository as issue ticker number 17.

The main motivation for EOX was to actively contribute to the next generation of OGC standards. The EOX team wanted to bring in their expertise gathered over the years in implementing current and previous OGC standards like WMS, WMTS, WCS, WPS, OpenSearch, etc.

Also, EOX wanted to make sure that Coverages do not fall behind the other OGC API specifications. EOX wanted to ensure that the OGC API - Coverages specification became more usable, in particular, that client implementers have a greatly improved experience.

EOX implemented the OGC API - Coverages draft in EOxServer in the OpenAPI branch (https://github.com/EOxServer/eoxserver/tree/openapi).

A demonstration using the provided Sentinel-2 data is available online at https://ows.eox.at/openapi/

The work on OGC API - Coverages needs to also address performance requirements. While it is a great feature to support arbitrary subsetting requests, allowing servers to tell clients which subsets are served with optimum performance is needed. Something similar to WMTS in the WMS/WMTS pair is missing for WCS.

It became quite clear during the hackathon that simply adding OpenAPI as an alternate protocol binding to WCS 2 is not enough. Core concepts need to be added, like grouping into collections, or reviewed and potentially revised, like requesting output format specifics.

EOX has from the beginning been committed to complying to and improving OGC standards. EOX is a longstanding associate member of OGC and actively contributes to the Coverages DWG and WCS SWG work for example with editing EO-WCS and providing reference implementations as well as in various testbeds.

Starting more than 10 years ago mainly with server-side implementations recently more and more client side development is done like EOxC (https://github.com/eoxc) or geotiff.js (https://geotiffjs.github.io).

The hackathon was great to bring representatives from the various groups at OGC around the table to get to a common understanding and identify future directions. Working together on the common understanding specified in OGC API - Common should continue and buy-in from all groups representing the various resources like features, maps, tiles, processes, coverages, etc. is crucial to the success of the next generation of OGC standards. This task needs to take into account the various stages different standard drafts are in making it not an easy task.

Evolution of the OGC specifications to a modern, developer-friendly API is essential.

To date, Esri have not implemented any of the new draft OGC API standards in their released software. They have however, been working on various R&D prototypes of server and client.

Esri has been involved in the OGC since its inception, and has widely implemented many other OGC standards in both server and client software. After each ArcGIS product release, the latest core OGC standards with compliance tests are reviewed. Currently, 133 ArcGIS products (multiple versions) have received compliance certifications across 338 OGC implementations.

Eurac Research is actively contributing to openEO (https://openeo.org/) an open source innovative aiming to federate EO cloud service providers by developing a standardized interface together with back-end and client implementations. This allows users to approach diverse EO data infrastructures, using source code with the same processing commands. Eurac Research develops a back-end driver (https://github.com/Open-EO/openeo-wcps-driver) that supports high-level interfaces for data cubes via OGC standard WCS and WCPS standards, and contributes further with the implementation of a use case for operational snow monitoring using openEO.

Since much of the development of OGC API specifications is moving in a similar direction, Eurac Research wanted to participate in the hackathon event in order to improve their understanding of the purpose and orientation of OGC API specifications, as well as to align the implementations as much as possible, in order to make them compatible. Currently several pieces of the openEO API are very similar to the OGC API, since Eurac Research were from the start of the development also looking at what was happening inside the OGC. The RESTful approach of WFS-3, now known as OGC API - Features, was specifically of great interest to Eurac Research. Another related initiative that Eurac Research is monitoring and following is the development of STAC by the Radiant Earth Foundation (https://github.com/radiantearth/stac-spec).

During the hackathon event in London, Eurac Research participated in the further development of the OGC API - Coverages specification on the first day and then developed a number of back-end implementations. Eurac Research also implemented the latest agreed-on specification on the second day of the hackathon. The implementation was based on the WCPS and is available at: http://saocompute.eurac.edu/openEO_WCPS_Driver/openeo/.

This solution is based on the aforementioned openEO WCPS driver and has adopted some new REST endpoints considering the OGC API - Coverages specification. In particular:

The existing driver works on top of an installation of Rasdaman community edition, exposing both the already existing WCS 2 and its WCPS 1 extension.

Eurac Research proposed the direct use of the path /collections/{collectionid}/{coverageid} instead of the path /collections/{collectionid}/coverages. The reason being that if collections can have different types of collections e.g. a feature collection and a coverage collection, it may be more appropriate that this information is delivered in the metadata of the collection with a type field.

The overall impression of the Hackathon was, for Alexander, that there still needs to be more integration between the different OGC API specifications. The goal should not be to just "restify" the existing standards, but to create a new well-defined suite of functionality that takes the current state of available data and technology into account. Most importantly the data available today is multidimensional, covering at least 3 or more dimensions that should be considered everywhere in the API. Secondly, in order to make actual use of the enormous amount of data available today, one cannot simply download the data an then process everything on the client-side. Processing should be performed as much as possible, where the data is, in order to avoid unnecessary copies, and unnecessary delay due to long Input/Output times. Finally processing should be as flexible as possible and allow for chaining of arbitrary functions or operations in order to allow a user to achieve whatever he wants with the data. Here, Eurac Research urges OGC to look into how processing is designed in openEO (https://open-eo.github.io/openeo-api/v/0.4.1/index.html) with its concept of a graph representation of workflows, that can contain any number of processes chained into arbitrarily complex graphs including even user-defined functions, when necessary processes are not natively supported by a given back-end implementation.

The concept of collections of coverages needs to be further specified more precisely. In particular it needs to be discussed and decided if collections should have the same projection and underlying grid, or if they can have arbitrary projections and grids. In the latter case a defined behavior should be decided of how to access a collection as opposed to an individual coverage. Questions like how are implementations mosaicking and integrating data from coverages on-the-fly when belonging to same collections, need to be answered. Are re-sampling methods, blending and mosaicking decided implicitly by the back-end implementation or can those be selected by query parameters or other means as well? How do we deal with multi-temporal (or arbitrary n-dimensional) mosaicking and resampling?

Geobeyond was motivated to participate in the hackathon by:

During the hackathon, Geobeyond implemented a draft GeoNode API based on:

This starting point will be the base building block to add more specifications to the next GeoNode 4.0 in order to be a reference implementation with at least the following OGC standards:

The following considerations of alternative approaches were identified by Geobeyond:

Geobeyond has experience with the following OGC API Specifications:

The event has been pretty much useful and productive for Geobeyond and the expectations are to see this kind of developer oriented meetings organized more frequently.

GeoCat actively support the OGC through participation in standards development and shipped implementations. Committed to SDI standards, especially with geospatial catalogues, GeoCat has implemented a wide range of OGC standards. GeoCat participated in the GeoNovum testbed for spatial data on the web, from which results were contributed to the final report of the OGC/W3C best practice for spatial data on the web report. This report was taken as the foundation for the OGC API developments. GeoCat believe enabling OGC standards to connect to web domain standards enlarges the audience of spatial data, and allows the spatial community to benefit from the latest web domain research and innovations.

There is a number of focus areas for GeoCat, especially related to GeoNetwork (https://www.geonetwork-opensource.org), in such events:

GeoCat has been constantly an active supporter of OGC and OGC standards, including recent efforts on the OGC API – Features specification.

GeoCat recognized the group’s admirable motivation towards creating standards that easy to understand and are developer-friendly.

GeoCat recognized valid remarks on the OGC API being very strict around the Collections concept. This was especially apparent with the OGC API – Processes specification where a collections-driven approach was markedly less intuitive than an OpenAPI approach.

These discussions are beneficial and lead to a strong standardization process.

The motivation for GeoLabs was to get more information about the direction followed by the working groups for the different standards, as well as to get answers to some questions that GeoLabs had about the OGC API - Processes specification. Indeed, GeoLabs implemented part of the OGC API - Processes specification before attending the hackathon and encountered some issues in trying to mimic the different options available in WPS 2.0. The hackathon therefore provided an opportunity for GeoLabs to discuss and share experiences with participants from other organizations.

GeoLabs came to the hackathon with the ZOO-Project implementation demonstration swagger interface available at: https://demo.mapmint.com/swagger-ui/dist/ for interacting with two instances based on the OGC API - Processes specification. The instances are available at: http://demo.mapmint.com/WPS2/ and http://demo.mapmint.com/WPS3/ (where the former is using the model available on the wps-rest-binding repository and the latter one is based on the tests GeoLabs made to change the wps-rest-binding, in order to make it fit the current WPS 2.0 definitions).

This implementation of the OGC API - Processes specification is based on the one available at http://www.zoo-project.org with some modifications. It is based on an implementation that is able to offer access to libraries and applications such as GDAL, OGR, GEOS, PROJ, the Orfeo ToolBox (https://www.orfeo-toolbox.org/) and the SAGA-GIS application. The demonstration includes numerous services available to be run using the implementation of the OGC API - Processes specification.

The Motivation behind creating GeoSeer was to help solve the discoverability problem. End users often find it difficult to find the services or data that exists. GeoSeer’s participation was an extension of this seeking to facilitate making life easier for finding data through the new OGC API specifications, or at least to ensure it did not get even harder. In fact, the team behind GeoSeer suggests that discovery is one of the aspects that could be improved in current OGC services and should be getting more consideration in the new OGC API specifications.

For GeoSeer, the OGC API specifications all seem quite interesting, though the concept of "collections" took some getting used to and remains somewhat confusing. This suggests that collections may not be as intuitive as could be desired and users may struggle with the concept.

In relation to discoverability:

GeoServer WFS 3 had been implemented in GeoServer as prototype community module, but is still based around a shared OWS dispatcher to avoid laying down a new architecture based on a single service example. The hackathon provided the occasion to prepare a new base architecture, dedicated to the OGC API services, based on a vision of other service API directions, as well as the formation of the emerging OGC API – Common specification.

The result is a new "OGC API" module divided between a core dispatch subsystem implementing common aspects between the various API, and a much-simplified Features API extending it.

This work will be extended in the next few months during OGC Testbed-15, implementing on top of the same base structure a Tiles API, a Styles API, a Image API, along with a dedicated API to collect tiles modified via the Image API, thus further strengthening the common code base.

GeoSolutions' participation in the separate thread has been focused on the Coverage API. As others have noticed, the current approach of treating the "collection" as a possibly heterogeneous set of coverages (e.g., accessing a single coverage via collection/{collectionId}/coverages/{coverageId} raises some doubts in terms of practical usage of the service for the simpler cases. There are evident needs of supporting different use cases, including:

GeoSolutions believe the subdivision of these use cases in a core specification and extension likely merits some further discussion, involving parties from both API Common and the coverages API.

Another relevant discussion that happened during the hackathon relates to the Map Tiles API, initially conceived as building blocks that could be added on top of the Features and Coverages API. While this is an important use case, GeoSolutions argued that it is also important to allow creation of standalone maps and tiles services where collections are opaque and the server is allowed to implement their rendering the desired way (e.g., cascading WMS and WMTS service is a case where the source is not feature nor coverage, standing up a simple mapping service without exposing the actual nature of the source data is another). The specification of Maps and Tiles has since then included the possibility of standalone usage.

GeoSolutions has been implementing OGC services in the GeoServer for well over 15 years, ranging between WMS and WMTS (mapping), WFS and WCS (data access), CSW and OpenSearch for EO (catalogues) and WPS (processing). At the same time the same services have been used extensively to provide solutions on the client side.

GeoSolutions' participation in OGC has been growing in the last few years, with active participation in multiple threads of OGC Testbeds, starting with Testbed 12 and continuing to the current date.

The hackathon has been very helpful to bring all parties interested in OGC specification together to discuss the future directions of the various API, confirming a shared approach and allowing each group to consider the concepts and how they apply to their specific service.

For future events GeoSolutions recommends that a larger amount of time be spent in shared sessions where portions of the API Common can be discussed and their suitability to the various services verified (as opposed to have a dedicated parallel group discussing Common).

As well as being an active participant on multiple OGC initiatives, e.g. Testbeds and Pilots, Helyx is also a provider of services to various government departments that are also members of the OGC.

Helyx prototyped an implementation of a routing profile of the OGC API - Processes specification. Much of the work going in the hackathon was done as part of the OGC Open Routing API Pilot. This initiative is focused specifically on routing as an application with use cases including online, offline and hybrid connectivity. Additionally, the routing engines in the Pilot are required to support parameters that include; shortest distance, shortest time and algorithms such as the traveling salesman problem. The solution provided a good use case for the OGC API – Processes specification including contributing to the debate in the WPS SWG, which is concerned with the role of WPS in the OGC API. In addition to the server-side solution, Helyx also produced two different clients; a web-based JavaScript client and a QGIS Client built using the QGIS plugin architecture.

No proposed alternatives.

Helyx has implemented and used several OGC Services in the web services suite and also have implementations for:

Helyx’s experience with WFS has been largely positive as much of the work has focused on the security aspects of data services. OGC API or WPS has been more challenging as there is a discussion going on within OGC regarding the purpose or utility of the WPS specification. There are currently two schools of thought about WPS within the OGC:

Each of their approaches have their advantages, option 1 is more flexible, looser and does not impose any well-defined paths or parameters. This means that generic clients are more likely to be able to recognize the pure OpenAPI specification. Option 2 is useful as it reflects the calls done as part of WPS 2 and REST bindings can be created accordingly. The tradeoff between the two has yet to be resolved.

It appears as though the many OGC standards will eventually transition to OpenAPI and JSON schemas, although this is far from defined. Perhaps a wider consideration is what this new approach means for architectures in both the OGC overall operating picture and by those utilizing OGC standards as part of their own architectures.

Hexagon Geospatial has been an active supporter of OGC and OGC standards for many years. Next to implementing a wide range of OGC standards, Hexagon Geospatial have ample experience in applying OGC standards within industry solutions for a variety of domains, such as Aviation, Defense & Intelligence, Maritime, Transportation, Mining or Disaster Management. By being part of many testbeds and interoperability experiments over the past decade and contributing numerous software components and engineering reports, Hexagon Geospatial also learned that cooperation with other people on real-world use cases is an excellent way of testing and improving specifications. Hexagon Geospatial is motivated to share its expertise as a long-term implementer and user to support the advancements of OGC standards related to map tiles, coverages and processes.

A desktop Java-based client was implemented by Hexagon Geospatial to experiment with the OGC API - Map Tiles specification. The client retrieved data from the server provided by Esri UK, accessing the maps using the tile-based approach.

Interesting about the client implementation is that it started from /collections/{collectionId} and used the provided metadata to look up the appropriate tile matrix set from /tileMatrixSets/{tileMatrixSetId}. Now that the tile structure was known, the client used /collections/{collectionId}/tiles/{styleId}/{tileMatrixSetId}/…​ to get the actual tile data. Note that the specification was still evolving and there was no map/ before {styleId}/ yet.

The implementation showed that the necessary metadata is available to access the map tiles generically.

Figure 14 shows the client accessing a map tiles collection from the server. The tiles are shown in the native CRS of the tile matrix set.

Figure 15 shows the client accessing a map tiles collection from the server. The tiles are requested in their native CRS, but reprojected onto a 3D globe.

A number of questions were raised in relation to consistency and duplication in various parts of the metadata in the API.

Hexagon Geospatial participated in the discussions about composition of the tiling scheme on top of collections or maps.

It was noted that there seems to be an opportunity for having more concepts in the Common API. Specifically, it seems that extent could be included.

When generating a map depicting multiple collections, the request will probably get quite complex. Perhaps it is useful to think of such a map as a composition of multiple single-collection maps. The multiple-collection map request could perhaps refer to multiple single-collection maps?

The Hexagon Geospatial product portfolios applied OGC standards from the start and currently implements more than a dozen OGC standards and candidate standards, including implementations of WFS, WMS, WCS, WMTS, WPS, CSW, GeoPackage, Filter Encoding, SLD / SE, GML, KML, 3D Tiles and NetCDF.

Hexagon Geospatial sees as a positive development that OGC is trying to make the APIs more easily consumable by users. However, and perhaps specifically to the Map Tiles specification, the variety of use cases and access patterns still leads to considerable complexity, for instance by having request parameters related to parts of the URL path.

Hexagon Geospatial believe the hackathon was useful to get a feel for the practicality of the proposed APIs. However, when each group goes off to work on their specification separately, it is easy for the APIs to start diverging. It would be good to have a convergence phase where ideas from the various group are compared and commonalities can be extracted for the Common API.

At the start of the hackathon ldproxy implemented the first draft release of OGC API Features (draft.1 from April 2018) plus several extensions (CRS, /items path, property selection, geometry simplification, transactions, dynamic links, etc.) as well as other resource types (tiles, styles).

Example services:

Most of the time at the hackathon was spent answering questions and discussing various approaches. Some progress was made in updating ldproxy to the latest draft of "OGC API - Features - Part 1: Core". The updates were tested and included in our OGC Testbed 15 implementation.

The hackathon was very helpful to broaden the OGC API discussions and to confirm the approach taken by OGC API Features. The event was very well organized, and the location was excellent.

Such two- or three-day implementation-driven "specification sprints" are an excellent mechanism for moving draft OGC standards that follow the same open process as OGC API Features forward.

Being actively engaged in coverage standardization over many years, it was important to support development of new APIs for coverages to ensure proper use of the coverage concept, to contribute an implementation based on rasdaman, and also to give assistance to other implementers in coverage concepts.

The rasdaman engine, which supports GET/KVP, POST/XML, and SOAP protocol bindings for coverage services, was extended with an experimental facade translating OpenAPI requests into standard WCS requests.

No alternatives are proposed, but more rigorous definitions are strongly encouraged, also to spot and resolve current issues - see below for details.

Jacobs University sees OpenAPI, as used by OGC, representing a minimalistic approach that aims at providing all functionality through URL syntax. Naturally, there are strong limitations in expressiveness and syntactic elegance. Additionally, some basic concepts need to be defined more clearly, see issues in the OGC API - Coverages repo:

Additional issues include

Jacobs University strongly recommends OGC pursues two "housekeeping" tasks before groups may have established their own interpretations:

lat/lon GmbH is involved in the OGC Compliance and Interoperability Testing (CITE) program, in the capacity of "Lead Compliance Tools". Thus, there is great interest in advancing the OGC test suites to be capable of testing the different OGC API specifications. During OGC Testbed-14, lat/lon GmbH developed a WFS 3.0, now called "OGC API - Features", test suite. This test suite represents a good base for other OGC API test suites. So, one major motivation is to investigate and evaluate the need for and technical preconditions of other OGC API test suites. Also, lat/lon GmbH is interested in whether there is demand for an executable test suite for the OGC API - Common specification and whether the WFS 3.0 test suite can be used as a base for a test suite based on the OGC API - Common specification.

In general, lat/lon GmbH is highly interested in further development of all OGC API specifications and provides input to discussions e.g. through GitHub issue trackers.

lat/lon GmbH advanced the OGC WFS 3.0 test suite, now "OGC API - Features", by working on open bugs and tasks. Also, the test suite was used by other participants to evaluate other participant’s service implementations and to find weaknesses in the test suite itself.

There were discussions trying to answer the question about technical preconditions of other OGC API test suites. Also, the need for an OGC API - Common test suite was discussed.

As OGC API specifications are closer to well-known IT standards, it is easier for non-geospatial developers to understand and work with the APIs. In addition, the JSON and HTML encodings enable users with less advanced technical skills to use the APIs. Especially, the HTML encoding might become interesting for non-technical users enabling even more users to work with OGC APIs.

lat/lon GmbH found the atmosphere at the OGC API Hackathon was very friendly, leading to productive work. Especially, the discussions about OGC API - Common and at which degree common content might be shared between all OGC API specifications helped a lot to generate a common understanding of OGC APIs and to bring all specifications forward. This hopefully leads to homogeneous OGC API specifications following the same pattern.

Thus, the hackathon was very helpful at this early stage as it will have an impact on the specifications itself. Future hackathons might help to continue creating homogeneous specifications already proven in practice.

The MSC implemented and deployed an instance of pygeoapi - a Python server implementation of the emerging OGC API specifications. A screenshot of the landing page of the deployed service is shown in Figure 16. The software was configured to offer an interface that conforms to the OGC API - Features and OGC API - Processes specifications.

A screenshot of the OpenAPI page of the deployed service is shown in Figure 17.

Meteorology has had a long tradition of inventing and using technologies for its specific and very demanding requirements. As weather and climate information become ever more important to many aspects of society, it has become increasingly important to make information available using widespread technologies and approaches. It is envisaged that using OpenAPI version 3 for defining public and private APIs to Met Office data and information will have many benefits, for both customers and Met Office infrastructure, especially when supporting services from computing clouds. The Met Office would like the APIs to be consistent with, and conformant to, any OGC OpenAPI standards.

Weather on the Web (WotW) is an initiative to agree APIs for common data retrieval patterns, such as points, time-series, polygons, and trajectories, in 2, 3 and 4 Dimensions. The intent is to make it a global standard for meteorological and environmental services.

Point Data has been working for some time, as have Time-series at a point, and Polygons. Trajectories and Data Tiles are being developed.

Fall-back is to develop our meteorological APIs separately from the OGC proposals and standardize through WMO, though this will be much slower.

A Hackathon was held in December 2018 in Washington DC, USA, building on the OGC WFS3.0 specification. Servers and clients based on existing WFS software were readily developed. Agreement was reached on the initial data retrieval patterns to support: point, timeseries, etc..

In the WFS3.0 spec, /Items/ needs to be replaced by 'point', 'timeseries', trajectory', etc. This is consistent with the approach advocated by Joan Maso, of CREAF, for maps and tiles.

All of the following are based on reading http://docs.opengeospatial.org/DRAFTS/17-069r2.html.

OSGeo projects have a long history of implementing OGC standards. Examples include (but are not limited to) PostGIS, QGIS, MapServer, GeoServer and many others.

The recent efforts around modernizing the OGC API standards provide opportunities for any project to implement OGC standards with a lower barrier to entry. In addition, the clean break approach provides opportunity to streamline codebases and implementations with less dependencies. Finally, OSGeo projects already provide reference implementations for numerous OGC standards. Participating at early stages of specification development allows for testing of approaches as well as leading the initial support of the standards into the FOSS4G community ecosystem.

This subsection provides a summary of participating projects:

The abovementioned projects (as well as others) are already implementing the OGC API Specifications and are actively participating in discussions to address gaps and improvements. Making the specification development process openly available on GitHub (as well as Gitter for chat) provides more opportunities for non-OGC members to provide input/feedback.

It is recommended to hold similar Hackathon events more regularly given the synergies and progress made during such a focused event. It is also recommended for Hackathons to be longer than 2 days in duration which may result in increased participation so as to justify travel.

Sigma Bravo supports open standards as a path to interoperability. The company recognizes the value of simple, implementer-friendly standards.

Sigma Bravo extended the OpenSphere web application to support OGC API - Features and OGC API - Map Tiles.

Interoperability with GeoServer, pygeoapi and SpaceBel OGC API - Features servers was demonstrated.

Interoperability with ESRI OGC API - Map Tiles was also demonstrated.

Sigma Bravo has significant experience with previous OGC standards, particularly on GeoPackage. The most mature part of the OGC API implementations is for OGC API - Features.

Sigma Bravo commends the OGC on the OGC API program of work, and thanks OGC staff and GeoVation for their work in organizing and hosting the hackathon. Sigma Bravo recommends that OGC seek to mature the OGC API standards through ongoing engagement and outreach activities, development of comprehensive Executable Test Suites and ongoing "in the open" standards development.

Motivation to participate was to assess possibility of using the new OGC API for Sinergise products and services and to contribute feedback to standards body.

Sinergise have implemented a frontend client which connects to two different backends and displays data, obtained via an implementation of the OGC API – Coverages specification, on the map. The client application is available at http://webdev.sentinel-hub.com/ogc-hackathon/index.html (view source for additional info). At the time of this writing one of the backends is not available, so Sinergise have updated the example so that it still loads after timeout.

Sinergise is using OGC WMS, WCS and WFS in production systems. There are some limitations in the existing standards so Sinergise welcome development of better alternatives.

Recommendations were submitted during hackathon sessions via tickets.

As an OGC member, Solenix is interested in contributing to standardization efforts, providing the experience of offering services to major European and national space agencies. As a software engineering company, Solenix is interested in the definition of versatile, practical and focused APIs, which benefit the OGC, the company’s software, and the experience that can be provided to customers.

This Hackathon was a natural fit to participate in the discussion and as a platform for learning and exchange of ideas.

During OGC Testbed-14, Solenix had developed a web-based client that allows interacting with WPS servers that used a preliminary REST and JSON binding for communication over HTTP. The OGC API – Processes specification is essentially an extension of this approach, which was modified in some of the areas.

During this OGC API Hackathon 2019 event, Solenix provided, adapted and extended the existing web client in order to account for modifications brought in by the new API. By the end of the Hackathon, a total of 7 servers were connected. Various small issues were discovered and addressed during the Hackathon on the connected server implementations, but of course also in the client itself.

The client is purely web based and developed using TypeScript and the Angular framework. Without a server-side counterpart that acts as trusted channel, the client communicates with the respective servers directly via the browser. The use of HTTP(S) and JSON via a REST interface is thus a natural technological fit, providing most of the tools for processing exchanged data out of the box.

From a security point of view, a browser is a particularly hardened runtime environment, which prefers that all data is received from the same origin, i.e., the same server location. Connecting to services on other servers requires the cooperation and adherence to the imposed rules by both sides to establish communication and safe operation. The most important set of rules is Cross-Origin Resource Sharing (CORS), which allows a server to negotiate the locations and types of requests that are available to clients. In close collaboration with the other participants, various specific issues and bugs in the respective use of CORS headers and HTTP statuses were identified, analyzed and rectified during the Hackathon, immediately benefiting the server implementers.

The client was also used to exercise the various endpoints as supported by the state of the OGC API – Processes specification at that stage, including the form generation for request parameters as well as the status display and result download for completed tasks.

A major part of the Processing Track during the Hackathon was dedicated to the discussion of REST-based interfaces and the applicable best practices to represent all of the elements as "Resources" with a URL, particularly to express Processes and their lifecycle.

All of the OGC APIs are intended to build on the OGC Common API, which defines a means for service discovery with a well-known initial structure. Consequently, the Processing API expands on this approach and proposes a structure to describe, announce and find available processes.

Most of the other OGC API standards deal with classical resources, e.g. imagery at a specific location on the globe. Once the representation of data is agreed, data remains clearly identifiable as a resource. The Processing API instead deals with ephemeral resources, e.g. the status of a task while it is running. Resources are thus in a constant flux and require defined behavior, e.g. an appropriate redirect, once the resource has become obsolete.

During the Hackathon, various means for providing meta-information about processes, their execution and chaining into more complex workflows was discussed and viewed through the lens of a RESTful interface design.

Participants gained the following two main points directly from using the Solenix client:

Both observations were also highlighted and discussed briefly during the presentation of the Solenix client towards the end of the Hackathon.

Spacebel was present in London to participate in the OGC API for Processes activities contributing an OGC API Processes implementation (Proxy).

In addition, Spacebel participated remotely on behalf of the H2020 DataBio project contributing a Catalog Server implementation hosting application and collection metadata from the DataBio Hub (https://www.databiohub.eu/registry/) aiming to improve alignment of the DataBio catalog and Hub implementation with the OGC API Common specification in addition to the Testbed-15 EOPAD discovery approach.

(1) DataBio Catalog Server (https://databio.spacebel.be/eo-catalog/readme.html) hosting EO applications and services (OGC 19-020), EO collections (OGC 17-084) and EO product (OGC 17-003) metadata implementing OpenSearch (OGC 10-032r8 and OGC 13-026r8) and Open API Common interfaces. Resources /, /conformance, /collections were implemented and interoperability was demonstrated through TIE testing with the OpenSphere client implementing OGC API Features provided by another participant. A limit parameter needed to be added server-side in addition to the maximumRecords parameter (which was used to comply with OASIS searchRetrieve (SRU) specifications) which was originally mapped on {count}.

(2) Web Processing Service (http://34.77.240.214/ades-proxy/swagger-ui/index.html) with a OGC API for Processes as defined in OGC Testbed 14 (https://raw.githubusercontent.com/spacebel/testbed14/master/json-spec/wps-t_tb14_spacebel-v1.6.yaml), including the Transactional and the Quoting & Billing extensions. Resources /, /conformance, /processes, `/jobs`were implemented and interoperability was shown through TIE testing with the Solenix client.

The Catalog Server combines an OpenSearch interface with GeoJSON responses (OGC 13-026r8, OGC 17-047) for simple clients and a more advanced OpenAPI-based interface.

Spacebel has experience with Swagger and OpenAPI since 2016 and already used this technology in previous OGC Testbeds.

Further alignment of the OpenSearch Catalog Server with OGC API Features interfaces, requires reconciling the time and bbox related search parameters from OGC 10-032 and OGC API Features. While OGC 10-032r8 has separate search parameters representing the start and end of a search interval {time:start} and {time:end} respectively, OGC API Features imposes a single search parameter to represent the interval.

OpenSearch and OpenAPI Common convergence would benefit from a revision of OGC 10-032r8 to ensure that the geo:box, time:start and time:end can be combined in a single URL template with the actual HTTP query parameter names imposed by OpenAPI Common for temporal and geographical search.

The approach to represent hyperlinks in JSON is unfortunately different from the encoding proposed by OGC 14-055r2 which means that an OpenSearch implementation based simultaneously on OGC 14-055r2 and OGC 17-047 in combination with OGC API Common will have different encodings for links in search responses and in other resource representations (e.g. /conformance, / etc).

The OGC API specifications are imposing to advertise "paths" in the Landing Page response and also contain wording suggesting that actual path names such as "api", "conformance", "collections" are mandatory and not just examples. This should be made clearer and it seems redundant to impose the declaration of paths in the landing page if indeed the path names are "fixed".

Making (JSON) data models available as separate JSON Schemas (https://swagger.io/docs/specification/data-models/keywords/) and not mixing them with actual OpenAPI descriptions (but refer to them) would allow validating JSON representations separately with JSON schema validation tools and before a service is put up.

The motivation for the University of Münster was to:

Problems with WPS for openEO:

WFS:

The university’s participation in the EOEP Hackathon was motivated by the aim of further extending the WPS 2.0 server developed as part of the ESA-funded EO4SEE Project.

Particularly the research group is interested in ensuring interoperability with third-party WPS implementations and adherence to the recommendations originating from the Testbed activities.

As part of the Hackathon UVT extended EWPS (the university’s server implementation) to support the REST-based bindings suggested by the draft standard. The implementation was successfully tested with two client implementations, particularly those developed by Solenix and Helyx.

UVT proposes modifying the current proposal to be more REST friendly by adapting WPS 2.0 conventions to RESTful alternatives.

UVT is using OGC WMS, WPS and WCS in research systems.

During the hackathon UVT submitted a series of recommendations regarding the standard, particularly an callback or notification API that would allow for more micro-service oriented applications. The notification API would allow the development of Workflow based (DAG) applications.

Also, UVT suggested extending the Common API to provide monitoring information in an implementation agnostic way. This would allow various tools to interoperate in a more friendly manner with OGC compliant services.

A demonstration user interface based on old interfaces available at www.zoo-project.org is available here: https://demo.mapmint.com/examples3/spatialtools.html. You can use it to invoke execution of 4 services using the OGC API - Processes. The data used as input for execution comes from pygeoapi OGC API - Features.

From here, you can use the following scenario to run OGR base vector operations:

The scenario presented here is the same as the one used for the OGR base vector operations. The only modification is that it uses an image as input data and run an Orfeo ToolBox application named BandMath.

Which challenge are you proposing to work on?

How much data (in Gigabytes) are you bringing to the Hackathon?

Does the data you are bringing to the Hackathon contain any personal or personally identifiable information that would fall under GDPR?

Are you bringing any commercially sensitive data to the Hackathon?

Which base image will your containers be built on? Include operating system or distribution if known.

What is the minimum required RAM for running and testing your software?

What is the minimum number of CPUs required to run your software?

What is the minimum storage (in Gigabytes) you will require for running and testing your software?

Please rate your team’s Microsoft Azure knowledge

NOTES: anything else you think we should know about your requirements for the environment your application and data require for the Hackathon?

What is your Github Handle?

Dietary restrictions

Which team will you work mostly with during the Hackathon?

Do you agree to the terms in the OGC Privacy Policy at https://www.opengeospatial.org/ogc/policies/privacy ?