OpenEO Community Standard

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.

Documents

(Hover over Type for full description)
Document title Version OGC Doc No. Type
openEO API 1.2 Community Standard 1.2 24-059 CS
OGC Open Call Requests
Overview

The OGC openEO Community Standard defines an API in support of interoperable cloud-based processing of large Earth observation datasets.

We recommend reading the glossary before diving into this specification. The glossary explains the most important terms used in this specification.

The OGC openEO Community Standard consists of two parts:

  • OGC openEO API Community Standard, this API specification
  • OGC openEO Processes Community Standard, a set of well-defined processes that is recommended to be implemented by back-end providers and is offered through their openEO API

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.

Open Calls and Requests

Members of the public can review draft standards and share feedback to ensure they are practical and widely applicable.

Insights

You’ll find the latest thought leadership from OGC here.