by Edzer Pebesma, the openEO consortium
Earth Observation data are becoming too large to be downloaded locally for analysis. Also, the way they are organised (as tiles, or granules: files containing the imagery for a small part of the Earth and a single observation date) makes it unnecessary complicated to analyse them. The solution to this is to store these data in the cloud, on compute back-ends, process them there, and browse the results or download resulting figures or numbers. But how do we do that?
With such an API,
An API is an application programming interface. It defines a language that two computers (a client and a server) use to communicate.
The following figure shows how many interfaces are needed to be able to compare back-ends from different clients, without an openEO API:
With an openEO API (dark blue), the situation becomes much easier:
However, existing back-ends need to be taught to work with the new API, and clients that interact with back-ends need to be developed.
The task of the openEO project is to design, develop, and evaluate an API for cloud-based Earth Observation data processing.
The three use cases comprise
The full description, including the consecutive interaction steps of the API, is found on the
With all this, you can install your own back-end of choice, install a client, and start analysing the data! (but do read “Next steps”, below). Alternatively, we show a couple of videos of screen casts made while testing the various clients and back-ends.
Demonstrates use of back-ends Sentinel Hub, WCPS EURAC, and OpenShift EODC
The following four documents (formal project deliverables) describe the proof-of-concept more extensively:
In addition, a document has been written that describes standards and interfaces used by the various back-ends, and the extent to which they are or will be useful for further developing the openEO API:
These deliverables have been submitted, but have not been approved, and hence may not be final.
During the proof-of-concept, intentionally a number of difficult issues were not addressed, including
The next steps will include:
As any API, the openAPI will only become good and useful if it is being used, and it needs testing by a wide audience. We are now at the stage of designing it, but at the point where large chunks are useful already. If you want to contribute to any of this, please do not hesitate and contact us e.g. by