Awesome
openEO Processes
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.
Versions / Branches
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 2.0.0-rc.1. The draft branch is where active development takes place. PRs should be made against the draft branch.
Version / Branch | Status | openEO API versions |
---|---|---|
unreleased / draft | in development | 1.x.x |
2.0.0 RC1 / master | upcoming version (RC) | 1.x.x |
1.2.0 | latest stable version | 1.x.x |
1.1.0 | legacy version | 1.x.x |
1.0.0 | legacy version | 1.x.x |
1.0.0 RC1 | legacy version | 1.x.x |
0.4.2 | legacy version | 0.4.x |
0.4.1 | legacy version | 0.4.x |
0.4.0 | legacy version | 0.4.x |
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.
Repository
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 openEO Community Examples repository or consensus from the openEO PSC. - The
*.json
files in theproposals
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 (subtype
s) for JSON Schema used in openEO processes. - Previously, an
examples
folder contained examples of user-defined processes. These have been migrated to the openEO Community Examples repository. - 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.
Process
- 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
openEO community examples
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.