This document provides a justification to the OGC Technical Committee (TC) for consideration of openEO as a Community Standard. This justification, along with the submitted candidate Community Standard, will form the basis for TC review and vote to approve the start of a Work Item as the first step in the Community Standard process for this Standard.

The submitters agree to abide by the TC Policies and Procedures and OGC Intellectual Property Rights Policy (http://www.opengeospatial.org/ogc/policies) during the processing of this submission.

Once approved, the Community Standard Work Item defined by this document is valid for six (6) months.

openEO specifies an open application programming interface (API) for connecting applications and other client software to big Earth observation cloud back-ends in a simple and unified way.

The openEO specification aims at increasing the interoperability of big EO data processing of satellite imagery in the cloud. Implementations of openEO can be used to add an interoperability layer on top of existing services. Its development has been driven by the need to overcome the challenges associated with different tools, APIs, and data formats in geospatial technology. openEO has been developed from the bottom up, with each version of the specification supported by implementations.

The primary use case for specifying openEO was to simplify and unify the data processing using a common API and a specification for a set of pre-defined processes. As such, users can still work in their favored programming language without worrying about data organization and pre-processing. Users can avoid vendor lock-in as the generated process descriptions can be executed at multiple provider endpoints, making it easier to compare and reproduce processing results between different providers.

The specification consists of two parts:

The openEO specification is openly licensed, governed and maintained. The specification is released under the Apache 2.0 license and is publicly available via GitHub. The project is governed by a Project Steering Committee: https://openeo.org/psc/

The openEO API builds on top of other standards and specifications and reuses other standards whenever possible. openEO’s basis is HTTP with JSON as request and response encoding. The API specification reuses building blocks from the OGC API – Common Standard. openEO adheres to the STAC API specification, which is based on the OGC API – Features Standard. openEO allows the exposure of a wide variety of visualization and download services using existing standards/specifications including OGC WMS, OGC WMTS, OGC WFS, OGC WCS, OGC API – Tiles, OGC API – Maps, OGC API – Features, and XYZ. For Authentication the openEO API uses the commonly used standards HTTP Basic (RFC 7617) and OpenID Connect.

The openEO API aligns with the OGC APIs Standard baseline (especially OGC API – Common) and STAC. The openEO API standard fits well within the OGC API roadmap.

OGC API – Processes and the openEO API are schematically similar with regards to processes and batch jobs and complement each other for these parts. The specification caters for different user audiences: openEO API comes out of the box with a wider scope of features, while OGC API - Processes only covers processing and additional features require the integration of other OGC API specifications. openEO allows for a more user-centric and less technical approach to big EO cloud processing, backed by an extensive set of pre-defined processes and its ecosystem. OGC API - Processes is a highly flexible API for executing any kind of processes on any kind of data with the caveats that get implied by this flexibility. On the other hand, openEO makes a different trade-off prioritizing interoperability between different implementations over flexibility by prescribing data models and process schemas. Users compose their algorithms in an abstract way as graphs using the openEO processes and leave the concrete realization of the process graph to the server implementation. OGC API – Processes is more focused on executing concrete implementations of an algorithm, e.g. provided as application packages, without implying a specific data model. Nevertheless, the openEO Processes could be used as a streamlined set of processes for OGC API – Processes. OGC API – Processes is currently missing pre-defined processes for increased interoperability between implementations. Additionally, work is ongoing to specify openEO user-defined processes as an encoding for OGC API – Processes - Part 3.

As requested by the reviewers, a detailed comparison of the openEO API and the OGC API - Processes has been compiled: https://github.com/Open-EO/openeo-api/blob/ogcapi-processes/crosswalks/ogcapi-processes.md If deemed useful, this could be the basis for further alignment in future versions of the specifications.

The openEO API is also considered as one building block for the emerging OGC GeoDataCube API Standard.

This specification enhances OGC operations and community involvement by providing a user-centric and less technical approach to big EO cloud processing, backed by an extensive set of pre-defined processes and a its surrounding ecosystem.

The openEO specification is backed by a considerably large ecosystem of open source servers, clients and tools. The following is a limited choice of the available implementations of the openEO specification. There are at least 10 additional implementations of the specification, which can be found through the links below.

All the implementations listed below are developed as open source software, and can be found, along with further implementations, on https://github.com/open-EO. Some implementation are also available in other GitHub organizations, e.g. https://github.com/IBM/tensorlakehouse-openeo-driver

Although many of the implementations are maintained close to the specification, they are indepenant projects and would not be part of the community standard.

Note: The specification is a set of building blocks that server and client implementations can pick from, which are called "profiles". Profiles are similar to conformance classes in OGC standards. Such profiles are available for both the API and the processes:

Due to the extensiveness of API and processes, server implementation are often incomplete as none of the services needs the full set of functionality of the API or processes. The profiles will be used to report completeness of the implementations below.

The European Space Agency (ESA) is adopting openEO as one of two options for future implementations of interoperable EO processing workflows and services. This adoption is happening in the frame of the projects EOEPCA+, ESA APEx, and Earth Code.

The Earth observation community is increasingly using openEO to describe EO processing workflows, and relying on the available backends to generate results. The following is a non-exhaustive list of publicly documented cases:

While it is hard to obtain public numbers on overall uptake by users, some of the backends already report 300 active users on a monthly basis. This is already a substantial number considering that these are mainly researchers and developers working in Earth Observation processing. A further increase is expected as we see that more backend implementations reach a maturity level that make them competitive with other well-known proprietary offerings for EO processing.

The openEO client libraries are downloaded by a broad audience of users, for example:

Is the proposed Community standard currently publicly available?

It’s made available under Apache 2.0 license at the following locations:

Will the contributor retain intellectual property rights?

If yes, the contributor will be required to work with OGC staff to properly attribute the submitter’s intellectual property rights.

If no, the contributor will assign intellectual property rights to the OGC.