openEO develops interoperable processes for big Earth observation cloud processing. This repository contains the process specifications. Each process is specified in a separate JSON file, which conforms to the corresponding API process schema.

• Latest Version of the Specification

The master branch is the 'stable' version of the openEO processes specification. An exception is the proposals folder, which provides experimental new processes currently under discussion. They may still change, but everyone is encouraged to implement them and give feedback.

The latest release is version 1.2.0. The draft branch is where active development takes place. PRs should be made against the draft branch.

Note: https://processes.openeo.org always points to the latest released version.

See also the changelog for the changes between versions and the milestones for a rough roadmap based on GitHub issues.

This repository contains a set of files formally describing the openEO Processes:

• The *.json files provide stable process specifications as defined by openEO. Stable processes need at least two implementations and a use-case example added to the examples folder or consensus from the openEO PSC.
• The *.json files in the proposals folder provide proposed new process specifications that are still experimental and subject to change, including breaking changes. Everyone is encouraged to base their work on the proposals and give feedback so that eventually the processes evolve into stable process specifications.
• implementation.md in the meta folder provide some additional implementation details for back-ends. For back-end implementors, it's highly recommended to read them.
• subtype-schemas.json in the meta folder defines common data types (subtypes) for JSON Schema used in openEO processes.
• The examples folder contains some useful examples that the processes link to. All of these are non-binding additions.
• The tests folder can be used to test the process specification for validity and consistent "style". It also allows rendering the processes in a web browser. Check the tests documentation for details.

• All new processes must be added to the proposals folder.
• Processes will only be moved from proposals to the stable process specifications once there are at least two implementations and an example process in the examples folder showing it in a use case. This doesn't require a PSC vote individually as it's not a breaking change, just an addition.
• The proposals folder allows breaking changes without a PSC vote and without increasing the major version number (i.e. a breaking change in the proposals doesn't require us to make the next version number 2.0.0).
• The proposals are released as experimental processes with the other processes.
• Each release and all breaking changes in the stable process specifications must go through PSC vote.