Skip to content

Latest commit

 

History

History
177 lines (128 loc) · 9.67 KB

ogc-submission.adoc

File metadata and controls

177 lines (128 loc) · 9.67 KB
Raw

Open Geospatial Consortium

Submission Date: 2024-03-07

Approval Date:   <yyyy-mm-dd>

Internal reference number of this OGC® document:    YY-nnnrx

Category: OGC® Community Standard Work Item Justification

Authors:   openEO Project Steering Committee

openEO Community Standard

Copyright notice

Copyright © 2023 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

1. Introduction

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.

2. Overview of proposed submission

openEO defines an open application programming interface (API) that connects clients in languages such as R, Python, and JavaScript to big Earth observation cloud back-ends in a simple and unified way.

The openEO specifications aim at increasing the interoperability of big EO data processing of satellite imagery in the cloud. Implementations of the openEO API can be used to add an interoperability layer on top of existing services. Multiple organizations agreed to define and implement such an API. Its development was driven by the need to overcome the challenges associated with different tools, APIs, and data formats in geospatial technology. openEO was developed bottom-up and each version was backed by implementations.

The primary use case for developing openEO was to simplify and unify the data processing using a common API specification with 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 supporting comparing and reproducing processing results more easily between different providers.

openEO is an open source project and the specification consists of two parts: * The openEO API, an HTTP API description specified as an OpenAPI document * The openEO Processes, a set of pre-defined processes defined following the openEO process description in JSON that is defined in the openEO API specification

Both specifications are released under the Apache 2.0 license and are publicly available via GitHub. The project is governed by a Project Steering Committee: https://openeo.org/psc/

openEO is backed by various tools and resources that facilitate its use. These include a variety of server and client implementations, including a web interface for non-programmers and a server implementation that can run locally in a Python environment.

3. Relationship to other OGC Standards

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 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 and OpenID Connect.

4. Alignment with OGC Standards Baseline

The openEO API aligns with the OGC APIs Standard baseline (especially 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 Specifications cater 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 an ecosystem of open source clients. 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 considerably large ecosystem of open source servers and clients.

5. Evidence of implementation

The following is a list of publicly available implementations and deployments of the openEO specification.

Server deployments (9+):

Client implementations (5+):

All these implementations are developed as open source software, and can be found, along with further implementations, in https://github.com/open-EO.

Date of most recent version:

  • Version 1.2.0 of the openEO API was released on May 25, 2023.

  • Version 1.2.0 of the openEO Processes was released on Dec 13, 2021.

Implementation description:

The openEO specifications are open source projects and publicly available via GitHub. Most of the server implementations and all of the client implementations mentioned above are also developed and released as open source software.

The openEO API is accompanied by a separately versioned set of openEO process descriptions that both are implemented by client and server implementations as shown in the list above. Various additional tools are available in the openEO ecosystem, such as validators, documentation generators, etc.

Implementation URL: https://github.com/open-EO

Is implementation complete?

  • ✓ Yes

  • ❏ No

6. Public availability

Is the proposed Community standard currently publicly available?

7. Supporting OGC Members

  • University of Münster - Institute for Geoinformatics

  • Eurac Research

  • VITO (Flemish Institute for Technological Research)

  • GeoConnections - Natural Resources Canada

  • EUMETSAT

  • European Space Agency (ESA)

  • EOX IT Services GmbH

  • Telespazio VEGA UK Ltd

  • Planet Labs PBC

  • German Aerospace Center - DLR

  • Matthias Mohr - Softwareentwicklung

8. Intellectual Property Rights

Will the contributor retain intellectual property rights?

  • ✓ Yes - The specification is open source, released under Apache 2.0 license

  • ❏ No

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.