GEP is preparing to support a broader range of EO processing approaches, allowing openEO workflows, EO Application Packages, OGC API - Processes and other documented service APIs to coexist within a common interoperable environment.
Earth Observation processing is evolving towards a richer and more interoperable ecosystem, where users and service providers should not be forced into a single processing model. Some applications are naturally expressed as data-cube analytics through the openEO API and process model, while others are better packaged as portable, containerised EO processing chains exposed through OGC API - Processes and EO Application Packages. In other cases, specialised models or services may already be available through well-documented APIs and should remain accessible without unnecessary rewriting.
GEP is preparing to support this diversity more explicitly. As part of its technology roadmap, GEP intends to support openEO as one of the processing interfaces available in the GEP ecosystem, alongside the existing Application Package approach and other interoperable service interfaces where appropriate. This is a roadmap direction and not an announcement that an operational openEO processing service is already available on GEP today.
The objective is to make GEP more flexible for EO application developers, researchers, service providers and institutional users. Rather than promoting one execution paradigm for all applications, the platform should provide a common environment where different processing approaches can be discovered, accessed, executed, connected and reused according to the needs of each application.
Supporting different processing approaches
GEP already provides a portfolio of EO processing services for the geohazards community, documented in the current GEP services documentation. These services build on Terradue’s long experience with cloud-based EO processing, service operation, algorithm portability and the use of EO Application Packages to make processing chains reusable across different execution environments.
The next step is to extend this approach towards greater processing-interface neutrality. In practical terms, this means that an openEO-native workflow should be able to remain openEO-native, an established containerised EO chain should be able to remain an EO Application Package exposed through OGC API - Processes, and an external model or specialised service should be able to remain accessible through its documented API where this is the most appropriate approach.
This is an important principle for the future GEP ecosystem: bring the processing capability to GEP without necessarily having to rewrite the processing capability for GEP.
How openEO complements EO Application Packages
openEO and EO Application Packages address related but different needs, and they are most useful when they are treated as complementary technologies. openEO is well suited to applications and analytics that can be expressed through its API and process model, especially where users benefit from a common data-cube processing interface, client libraries and execution on openEO backends. EO Application Packages remain highly relevant for portable and containerised EO processing chains, particularly where existing software, complex workflows, specialised dependencies or operational production logic need to be preserved and exposed through OGC API - Processes.
For GEP, supporting openEO does not mean abandoning EO Application Packages, nor does it mean turning GEP into an “openEO-only” platform. The intended direction is to support openEO as another first-class way of accessing EO processing capabilities, alongside Application Packages and other documented service interfaces.
This approach is especially important for service providers as a developer who already has an openEO workflow should not be forced to repackage it as a containerised chain if openEO remains the most natural expression of the application. At the same time, a team with a mature containerised EO chain should not be forced to rewrite it as an openEO process graph if the Application Package model is the better fit. GEP should provide the common environment around these capabilities: discovery, access, execution, storage, catalogues, portability, traceability and operational use.
Experience from EOEPCA+ and APEx
This roadmap direction is informed by Terradue’s participation in wider European activities where openEO, OGC API - Processes and EO Application Packages are being considered as interoperable and complementary approaches. EOEPCA+ is focused on interoperable building blocks for federated EO cloud and platform offerings, and its processing documentation describes workflows defined either as OGC Application Packages or as openEO Process Graphs. EOEPCA material also explores how openEO processing and OGC Application Packages can be combined in different ways, including the execution of openEO process graphs through Application Package mechanisms and the use of CWL-based processing within openEO contexts.
APEx provides another relevant reference point. The APEx public documentation presents openEO User Defined Processes and OGC Application Packages as service implementation options, and describes EO Application Packages as one of the standardised options used to expose algorithms as services through OGC API - Processes. APEx also identifies Geohazards TEP as an APEx-compliant platform for OGC API - Processes using EO Application Packages. Terradue is listed among the organisations delivering APEx services under ESA guidance.
This experience is helping shape the future GEP roadmap, but it should not be read as a statement that GEP is simply inheriting functionality from EOEPCA+ or APEx. The goal for GEP is to adopt the relevant interoperability lessons in a way that fits the platform’s own geohazards community, operational services, subscription model and long-term evolution.
A relevant example: Sentinel-1 InSAR processing with openEO
The recent ESA article on Sentinel-1 InSAR processing with openEO in CDSE is a useful example of the kind of openEO-native capability that the GEP roadmap should be ready to support. The article describes new Sentinel-1 coherence and interferogram capabilities available as openEO User Defined Processes in the APEx Algorithm Catalogue, enabling users to generate products within the Copernicus Data Space Ecosystem without downloading large datasets or maintaining local computing infrastructures.
For GEP, the strategic point is not to duplicate every backend or rewrite every workflow, but to prepare the platform to connect with relevant capabilities where they already exist and where they are useful for the geohazards community. In the future, this could allow users to access openEO-native processing capabilities, Application Package-based services and other specialised EO services from a common GEP context, depending on the maturity of the integration and the access conditions of each service.
What this means for future GEP users and service providers
For users, this roadmap should make GEP more flexible as a researcher or geohazard expert should be able to discover suitable data and processing options without first having to understand which technical interface sits behind each service. A workflow may be executed through openEO, through an EO Application Package exposed via OGC API - Processes, or through another documented service interface, while GEP provides the surrounding environment for access, execution context, outputs, catalogues and analysis.
For application developers and service providers, the benefit is also clear. The aim is to reduce unnecessary rewrites, preserve existing investments in EO applications, and make it easier to bring useful capabilities into the GEP ecosystem. This is consistent with Terradue’s long-standing focus on portability, interoperability and avoiding cloud or technology vendor lock-in.
This roadmap also prepares GEP for the next generation of assisted and more automated EO workflows. As processing capabilities become better described, easier to discover and accessible through standard interfaces, it becomes easier for users, platforms and future orchestration tools to identify which capability is suitable for a given objective, understand how it can be executed, combine it with other services where appropriate, and keep the resulting workflow traceable.
Preparing the next step
GEP’s technology roadmap will continue to be based on practical interoperability rather than on a single processing paradigm. openEO support is planned as an additional processing interface in the GEP ecosystem, complementing the existing Application Package approach and other service APIs where appropriate.
More information will be shared as this capability progresses, including how openEO-based processing options may be exposed, discovered and used from the GEP environment. Until then, the operational GEP processing services remain those described in the current GEP services documentation.
This topic describes a planned GEP roadmap capability. It does not announce the availability of an operational openEO processing service on GEP today. openEO support is intended to complement, not replace, the existing EO Application Package and OGC API - Processes approach used for GEP processing services.