A Machine Learning API for Earth Observation Data Cubes Based on openEO

# A Machine Learning API for Earth Observation Data Cubes Based on openEO
Source: [https://arxiv.org/html/2609.13453](https://arxiv.org/html/2609.13453)
Brian PondiEmail:[brian\.pondi@uni\-muenster\.de](mailto:[email protected])Affiliation:Institute for Geoinformatics, University of Münster, Heisenbergstr\. 2, Münster, 48149, North\-Rhine Westphalia, GermanyJonas HurstEmail:[jhurst@uni\-muenster\.de](mailto:[email protected])Affiliation:Institute for Geoinformatics, University of Münster, Heisenbergstr\. 2, Münster, 48149, North\-Rhine Westphalia, GermanyRolf SimoesEmail:[rolfsimoes@gmail\.com](mailto:[email protected])Affiliation:FGV Agro \- Center for Agribusiness Studies, Fundação Getulio Vargas, Av\. Paulista, 542, São Paulo, 01310\-000, São Paulo, BrazilJonas StarkeEmail:[jstarke@uni\-muenster\.de](mailto:[email protected])Affiliation:Institute for Geoinformatics, University of Münster, Heisenbergstr\. 2, Münster, 48149, North\-Rhine Westphalia, GermanyMarius AppelEmail:[marius\.appel@hs\-bochum\.de](mailto:[email protected])Affiliation:Bochum University of Applied Sciences, Am Hochschulcampus 1, Bochum, 44801, North\-Rhine Westphalia, GermanyEdzer PebesmaEmail:[edzer\.pebesma@uni\-muenster\.de](mailto:[email protected])Affiliation:Institute for Geoinformatics, University of Münster, Heisenbergstr\. 2, Münster, 48149, North\-Rhine Westphalia, Germany

###### Abstract

Earth Observation \(EO\) data are increasingly organized and analyzed as spatio\-temporal data cubes, while machine learning \(ML\) methods operate on tabular feature matrices or structured tensor inputs\. This representational mismatch means that integrating ML into EO workflows currently requires platform\-specific transformations that are difficult to reproduce or transfer across cloud infrastructures\. TheopenEOspecification provides a unified interface for EO data access and processing across heterogeneous backends, but lacks a standardized approach for ML integration\.

We propose a process\-level ML specification foropenEOthat structures workflows into three stages: model initialization, model actions covering training, tuning, inference, validation, and model management\. The specification supports classical algorithms such as Random Forest and SVM as well as deep learning architectures for time\-series and spatial patch\-based modeling, including TempCNN and Temporal Attention Encoders and foundation model inference\. Three prototype implementations in R and Python demonstrate feasibility across diverse technology stacks\. A crop type mapping use case demonstrates cross\-backend interoperability by submitting an identical process graph to independent R and Python backends and comparing the resulting predictions and evaluation metrics\.

Two further use cases demonstrate deep learning on time series and foundation model inference, each executed on a dedicated backend\. Prototype implementations reveal, however, that full cross\-backend portability requires deeper harmonization of serialization formats and execution semantics than the process level alone can enforce; backend library versions and preprocessing conventions outside the specification boundary also affects reproducibility\. Addressing both through explicit backend conformance profiles represents the most important near\-term direction\. The specification advances the reproducibility, portability, and accessibility of ML workflows on EO data cubes across cloud platforms\.

###### keywords

openEO, earth observation, data cubes, machine learning, deep learning, interoperability

### 1Introduction

Earth Observation \(EO\) data are increasingly organized and analyzed as*data cubes*: multidimensional arrays with explicit spatial, temporal, and band dimensions\(x,y,t​i​m​e,b​a​n​d\)\(x,y,time,band\)[Baumann et al\. \(2018\)](https://arxiv.org/html/2609.13453#bib.bib28);[Appel and Pebesma \(2019\)](https://arxiv.org/html/2609.13453#bib.bib11)\. This representation supports scalable analytics, reproducible querying, and consistent spatio\-temporal alignment across large EO data archives\. Driven by advances in satellite technology and open data\-sharing policies, large volumes of EO data are now freely available for applications such as land\-cover monitoring, carbon stock estimation, and disaster response[Wulder et al\. \(2012\)](https://arxiv.org/html/2609.13453#bib.bib8);[Kansakar and Hossain \(2016\)](https://arxiv.org/html/2609.13453#bib.bib9)\. Due to the petabyte scale of these datasets \(e\.g\., more than 90 PB in the Copernicus Data Space Ecosystem as of May 2026111[https://dashboard\.dataspace\.copernicus\.eu/](https://dashboard.dataspace.copernicus.eu/), accessed May 2026\.\), EO data cubes are predominantly stored and processed in cloud environments\.

Meanwhile, machine learning \(ML\) has become a central analytical tool for extracting patterns and predictions from these datasets, with applications across land\-cover classification[Pelletier et al\. \(2019\)](https://arxiv.org/html/2609.13453#bib.bib14), crop yield estimation[Qiao et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib16), and disaster monitoring[Xie et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib17)\. Yet a fundamental representational gap exists between EO data cubes and what ML models actually consume\. Classical methods such as Random Forests[Breiman \(2001\)](https://arxiv.org/html/2609.13453#bib.bib30)and Support Vector Machines[Cortes and Vapnik \(1995\)](https://arxiv.org/html/2609.13453#bib.bib31)expect tabular feature matrices, while deep learning models require structured multi\-dimensional arrays with fixed shape and ordering\. Bridging this gap requires systematic transformations between cubes, tables, and tensors \(Fig\.[1](https://arxiv.org/html/2609.13453#S1.F1)\) to satisfy each model’s input constraints\.

In practice, these transformations are implemented in an*ad hoc*and platform\-specific manner, tightly coupled to particular software stacks or ML libraries\. Workflows developed for one platform are consequently difficult to reproduce, reuse, or transfer across infrastructures, even when operating on conceptually identical EO data cubes[Schramm et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib24)\. Rolf et al\.[Rolf et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib23)have argued that satellite data constitute a distinct modality in ML whose spatio\-temporal structure requires specialized methods rather than the direct reuse of approaches designed for natural images\. The absence of shared abstractions for EO\-specific ML operations forces each platform to re\-implement these methods independently, fragmenting effort and limiting reproducibility across infrastructures\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/datacube_table_tensors.png)Figure 1:Representation transformations between EO data cubes, tabular feature matrices \(classical ML\), tensor representations \(deep learning\), and prediction cubes\. Each transformation must bridge a structural mismatch between the cube’s named dimensions and the model’s expected input layout\.The openEO specification standardizes EO data access and processing through a common API for querying and manipulating data cubes across heterogeneous cloud backends[Schramm et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib24)\. In April 2026, the Open Geospatial Consortium \(OGC\) approved and published the openEO API as an OGC Community Standard and the openEO Processes as an OGC Community Practice[Mohr \(2026a\)](https://arxiv.org/html/2609.13453#bib.bib36);[Mohr \(2026b\)](https://arxiv.org/html/2609.13453#bib.bib37)\. As openEO adoption scales under formal governance, ad hoc and backend\-specific ML workarounds become increasingly unsustainable: a gap that individual platforms could manage independently now requires a shared solution at the specification level\. Yet openEO’s support for ML remains limited and fragmented\. A small number of ML\-related processes exist in isolated backends and have been labeled as “experimental” for more than four years, notablyfit\_class\_random\_forestandpredict\_random\_forestin VITO’s Terrascope platform222[https://docs\.terrascope\.be/Developers/WebServices/OpenEO/OpenEO\.html](https://docs.terrascope.be/Developers/WebServices/OpenEO/OpenEO.html), but these evolved without a shared structure and are not portable across backends\. User\-defined functions \(UDFs\) allow deep learning workflows in principle, but they typically depend on backend\-specific environments, which limits both portability and reproducibility\. Extending openEO to support ML, therefore, requires not just additional endpoints but a coherent process\-level specification that integrates with the existing data cube model\.

To address this gap, we propose a standardized ML specification for EO data cubes within theopenEOecosystem\. The specification structures ML workflows into three stages: \(i\) model initialization, \(ii\) model actions covering training, tuning, inference, and validation, and \(iii\) model management, covering saving and loading\. By defining these operations at the process level, the same workflow can be expressed once and executed across heterogeneous backends while remaining agnostic to the underlying ML representation\. We evaluate two claims: \(i\) that a process\-level ML specification can express the three dominant supervised ML workflow types in EO practice—feature\-based, time\-series, and patch\-based—within a single declarative abstraction, and \(ii\) that an identical process graph submitted to independentopenEObackends yields predictions whose overall accuracy and dominant per\-location class assignment agree within the variation expected from differences in underlying ML library defaults\.

The contributions of this work are threefold: \(i\) a backend\-agnostic, process\-level ML specification integrated with the openEO process catalog, covering classical ML, deep learning on time series, and foundation\-model workflows; \(ii\) prototype implementations in both R and Python; and \(iii\) representative use cases demonstrating how the specification improves interoperability, reproducibility, and accessibility of ML workflows on EO data cubes\. The modular process structure provides a foundation for future extension to emerging paradigms, including federated learning[Moreno\-Álvarez et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib19)and large\-scale foundation models[Xiao et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib18)\.

### 2Background

#### 2\.1Data Cubes

A widely used data structure in EO is the*raster data cube*: a multidimensional array with consistent spatial, temporal, and spectral axes that organizes large satellite image collections into a uniform, queryable form\([Kopp et al\., 2019](https://arxiv.org/html/2609.13453#bib.bib10)\)\. Image collections comprise sets of satellite images, each containing multiple spectral bands or variables\. Within a single image, bands typically share a common spatial extent, acquisition timestamp, and reference system, although their pixel resolutions may differ\([Appel and Pebesma, 2019](https://arxiv.org/html/2609.13453#bib.bib11)\)\. Unlike the regular structure of data cubes, conventional image collections often include scenes with irregular spatial coverage, variable acquisition intervals, and differing coordinate reference systems, making uniform processing more challenging\.

By standardizing indexing along named dimensions\(x,y,t​i​m​e,b​a​n​d\)\(x,y,time,band\)and attaching explicit metadata, data cubes ensure that the same query produces identical samples across backends\. Deterministic re\-slicing and consistent dimension labels further guarantee that training, validation, and inference draw on the same spatio\-temporal references regardless of the execution environment\. These properties make the data cube the natural anchor for the ML specification proposed in this paper: the initialization, fit, predict, and management processes defined in later sections all operate on this shared structure\.

Figure[2](https://arxiv.org/html/2609.13453#S2.F2)illustrates a workflow for converting image files into the canonical cube layout\(x,y,t​i​m​e,b​a​n​d\)\(x,y,time,band\)that underpins sampling and batching throughout the specification\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/data-cube-kopp.png)Figure 2:A workflow for converting image/raster files into a pixel\-aligned image/raster data cube\(x,y,t​i​m​e,b​a​n​d\)\(x,y,time,band\)\. Adapted from[Kopp et al\. \(2019\)](https://arxiv.org/html/2609.13453#bib.bib10)\.The regular, tensor\-like structure of raster data cubes makes them naturally compatible with a wide range of ML architectures\. Convolutional and recurrent models benefit directly from the spatial and temporal ordering that cubes preserve[Zhu et al\. \(2017\)](https://arxiv.org/html/2609.13453#bib.bib7), and architectures developed specifically for EO data, includingTempCNN[Pelletier et al\. \(2019\)](https://arxiv.org/html/2609.13453#bib.bib14),ConvLSTM[Rußwurm and Körner \(2018\)](https://arxiv.org/html/2609.13453#bib.bib13), and Temporal Self\-Attention networks[Sainte Fare Garnot and Landrieu \(2020\)](https://arxiv.org/html/2609.13453#bib.bib12), exploit this structure to learn phenological and spatial patterns from aligned observation sequences\.

Complementing raster cubes,*vector data cubes*333[https://r\-spatial\.org/r/2022/09/12/vdc\.html](https://r-spatial.org/r/2022/09/12/vdc.html)provide a structured representation for training and validation data\. Like raster cubes, they are modeled asnn\-dimensional arrays, but include at least one spatial dimension that maps to a set of 2\-D vector geometries such as points, lines, or polygons\. Additional axes capture time, attributes, or category labels\. This design enables vector cubes to store ground\-truth annotations such as field parcel boundaries, land\-cover classes, or point measurements in a queryable form\. Crucially, vector data cubes can be joined with raster data cubes by spatial and temporal relationships, providing a clean interface between feature inputs and target variables in supervised learning workflows\.

#### 2\.2ML Workflow Types for EO Data Cubes

EO data present distinctive challenges for ML\. Unlike conventional tabular datasets, satellite imagery is inherently spatio\-temporal, high\-dimensional, and spatially autocorrelated[Rolf et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib23);[Adegun et al\. \(2023\)](https://arxiv.org/html/2609.13453#bib.bib22)\. Observations combine multiple spectral bands, fine spatial resolution, and repeated temporal acquisitions, characteristics that violate the independent and identically distributed \(i\.i\.d\.\) assumption underlying many standard ML methods\. Linear regression, logistic regression, and naive Bayes classifiers assume that observations are drawn independently and identically from a fixed distribution, an assumption that breaks down when adjacent pixels share spatial context or when repeated acquisitions are temporally correlated\. Even ensemble methods such as Random Forests[Breiman \(2001\)](https://arxiv.org/html/2609.13453#bib.bib30)and gradient boosting machines, while more robust in practice, rely on tabular feature vectors that must be carefully engineered to encode spatio\-temporal structure explicitly\. Support Vector Machines[Cortes and Vapnik \(1995\)](https://arxiv.org/html/2609.13453#bib.bib31)face similar constraints\. ML workflows for EO must therefore explicitly account for spatial and temporal structure rather than treating observations as exchangeable samples\.

Within openEO, satellite collections are exposed as data cubes that can be queried and transformed through standardized processes\. This abstraction enables consistent extraction of pixel time series, image patches, or aggregated features across backends\. However, different ML models consume EO data in fundamentally different forms, and the way a data cube is decomposed into learning units shapes the entire ML workflow and determines which operations must be supported\. The three use cases in Sections[5](https://arxiv.org/html/2609.13453#S5),[6\.1](https://arxiv.org/html/2609.13453#S6.SS1), and[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)demonstrate that process\-level abstraction can support all three dominant decomposition strategies described below\.

In practice, three workflow types dominate EO ML applications, each defined by how the data cube is transformed into the input structure expected by the model\.

Feature\-based workflowsconvert observations at each location into engineered descriptors, including spectral indices, textural measures, and ancillary layers, aggregated into a two\-dimensional tabular feature matrix\(N×F\)\(N\\times F\), whereNNis the number of samples andFFthe number of features\. This matrix is the canonical input for classical estimators such as Random Forests or SVMs[Belgiu and Drăguţ \(2016\)](https://arxiv.org/html/2609.13453#bib.bib4);[Maxwell et al\. \(2018\)](https://arxiv.org/html/2609.13453#bib.bib6)\. Supporting this workflow type requires processes for feature extraction, spatial aggregation, and sampling that transform a cube into this canonical form\.

Time\-series workflowstreat each cube location as a temporal signal, modeling phenological trajectories or disturbance dynamics directly from observation sequences rather than engineered features[Simoes et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib5)\. Deep sequence models such as TempCNNs[Pelletier et al\. \(2019\)](https://arxiv.org/html/2609.13453#bib.bib14)and attention\-based architectures[Sainte Fare Garnot and Landrieu \(2020\)](https://arxiv.org/html/2609.13453#bib.bib12)consume inputs shaped as\(B×T×C\)\(B\\times T\\times C\), whereBBis batch size,TTthe number of time steps, andCCthe number of spectral channels\. Supporting this workflow type requires processes for temporal interpolation, gap\-filling, and consistent extraction of ordered sequences from data cubes\.

Spatial patch\-based workflowsleverage local spatial context by operating on patches extracted from data cubes, enabling convolutional networks to capture texture, structure, and spatial dependencies[Zhu et al\. \(2017\)](https://arxiv.org/html/2609.13453#bib.bib7);[Rußwurm and Körner \(2018\)](https://arxiv.org/html/2609.13453#bib.bib13);[Qiao et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib16)\. Two\-dimensional patch models consume inputs shaped as\(B×C×H×W\)\(B\\times C\\times H\\times W\), while spatio\-temporal models extend this to\(B×T×C×H×W\)\(B\\times T\\times C\\times H\\times W\)[Shi et al\. \(2015\)](https://arxiv.org/html/2609.13453#bib.bib32)or full 4\-D stacks\(B×T×C×Z×Y×X\)\(B\\times T\\times C\\times Z\\times Y\\times X\)for volumetric representations[Bodnar et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib33), whereHH,WW, andZZare the spatial and vertical extents of the patch\. Bi\-temporal change detection models consume a specialised variant shaped as\(B×2×C×H×W\)\(B\\times 2\\times C\\times H\\times W\), where the second dimension indexes the two acquisition dates being compared[Rolih et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib34)\. Supporting this workflow type requires tiling, patch extraction, batching, and reconstruction of predictions into spatially coherent output cubes\.

In operational settings these workflow types frequently intersect: feature engineering may precede temporal modeling, and hybrid architectures often combine spatial and temporal context\. The three types were selected because they cover the dominant supervised ML paradigms currently employed in EO practice and represent the breadth of operations a general specification must support\. Emerging approaches such as graph\-based learning or large foundation models can be incorporated incrementally through the same process\-level abstraction without altering the core design\.

#### 2\.3ML API Conventions and Standards

Covering this range of workflow types within a single specification requires grounding in both EO\-specific requirements and the API conventions that have emerged in the broader ML ecosystem\. Supervised ML APIs have converged on a design pattern that scikit\-learn[Pedregosa et al\. \(2011\)](https://arxiv.org/html/2609.13453#bib.bib40)established: configure a model with hyperparameters, train it viafit\(X, y\), and apply it viapredict\(X\), with each stage kept separate\. PyTorch’sModule444[https://docs\.pytorch\.org/docs/2\.12/notes/modules\.html](https://docs.pytorch.org/docs/2.12/notes/modules.html)abstraction and the Kerascompile/fitAPI555[https://keras\.io/api/models/model\_training\_apis/](https://keras.io/api/models/model_training_apis/)carry the same separation into deep learning; the Hugging FaceTransformerslibrary[Wolf et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib42)extends it to pretrained Natural Language model pipelines, and MLflow[Chen et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib41)applies it to model lifecycle management through experiment tracking and model registries\. The proposed specification’s three\-stage structure, introduced in Section[3](https://arxiv.org/html/2609.13453#S3), maps directly onto this same separation, transposed to the declarative process\-level abstraction ofopenEOand the dimensional structure of EO data cubes\.

ONNX \(Open Neural Network Exchange\)[ONNX Community \(2019\)](https://arxiv.org/html/2609.13453#bib.bib43), an open standard governed by the Linux Foundation and backed by industry software and vendor consortium, including Microsoft, Meta, IBM, NVIDIA, AWS, Intel, AMD, Huawei Technologies, Siemens, Alibaba Group, Tencent, Qualcomm, and Arm represent trained ML models as portable computation graphs independent of the training framework\. A model trained in PyTorch, scikit\-learn, Tensorflow, XGBoost, LibSVM, or Keras can be exported to ONNX and run in any ONNX\-compatible runtime, separating training from deployment\. Because EO backends may rely on different ML execution stacks—as the prototype implementations in Section[4](https://arxiv.org/html/2609.13453#S4)illustrate—ONNX is the recommended format for model exchange: a model produced on one backend can be loaded and applied on another without bridging code\.

The SpatioTemporal Asset Catalog \(STAC\)666[https://stacspec\.org](https://stacspec.org/)is an open JSON specification for cataloguing geospatial data assets with queryable, provider\-agnostic metadata, used by major EO data providers and open data archives\. The STAC Machine Learning Model \(STAC MLM\) extension[Charette\-Migneault et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib25)applies this framework to spatio\-temporal ML models, standardizing how architecture, input and output specifications, model hyperparameters, pretrained source, tasks and software dependencies are recorded as catalog assets\. Because openEO backends already interact with STAC\-compliant catalogs for data access, aligning model management with the same infrastructure means trained models can be shared and retrieved through workflows EO practitioners already have in place\.

### 3ML API Specification

Building on the workflow types in Section[2\.2](https://arxiv.org/html/2609.13453#S2.SS2)and the API conventions in Section[2\.3](https://arxiv.org/html/2609.13453#S2.SS3), this section describes the ML API processes for theopenEOecosystem\. The specification is organized into three stages: model initialization, model actions, and model management, each covering a distinct subset of processes for end\-to\-end ML on EO data cubes\.

The proposed processes are described as JSON schemas, available in the project repository on GitHub777[https://github\.com/PondiB/openEO\-processes](https://github.com/PondiB/openEO-processes)\. An example schema is provided in Appendix[11](https://arxiv.org/html/2609.13453#S11)\. This follows the openEO community’s standard development workflow: GitHub is the platform for proposing and iterating on process specifications through open issues and pull requests\. Once a specification has been implemented in at least two independent production backends, it is promoted to the stable, versioned catalogue at[https://processes\.openeo\.org/](https://processes.openeo.org/), which is the normative specification\. The broader openEO Processes specification—which defines the framework within which the proposed ML processes sit—has been approved and published as an OGC Community Practice \(version 1\.2, April 2026;[https://docs\.ogc\.org/cp/24\-060\.html](https://docs.ogc.org/cp/24-060.html)\), situating this work within an established international open geospatial standards context\.

Five core principles defined by the authors guided the design of the API:

- •Modularity: Decoupling initialization, action, and management into discrete processes allows users to compose complex pipelines from simple building blocks and swap algorithms without rewriting entire workflows\.
- •Consistency: Uniform naming conventions, parameter ordering, and behavior across all ML processes minimize surprises for users, improving learnability and reducing integration friction\.
- •Backend\-Agnosticism: Defining processes independently of execution engines allows backends to map ML processes to native libraries such as scikit\-learn, XGBoost, PyTorch, or caret, while preserving a consistent user experience\.
- •Sensible Defaults: Processes expose well\-chosen default hyperparameters that cover the majority of common use cases, so that simple ML tasks run without configuration, reducing errors and accelerating prototyping\.
- •Extensibility: A compact core API covers common ML tasks while supporting extension through community proposals, enabling new algorithms and workflow types to be added incrementally without modifying existing processes\.

The selection of processes presented in this section is intentionally pragmatic rather than exhaustive, and the rationale for inclusion is explicit\. Processes were selected on three criteria: \(i\) they correspond to ML capabilities already widely used in operational EO analysis; \(ii\) they cover at least one of the three workflow types identified in Section[2](https://arxiv.org/html/2609.13453#S2), ensuring that feature\-based, time\-series, and spatial patch\-based workflows are all supported; and \(iii\) mature, tested implementations exist in established libraries so that backends can realize the processes without bespoke ML development\. Processes that do not yet meet criterion \(iii\), such as graph neural network architectures, are deliberately excluded from the current specification and left for future community proposals\. In particular, several classification processes were introduced to make methods available in EO\-focused libraries, such as thesitspackage[Simoes et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib5)in R, accessible within theopenEOecosystem\. This scoped selection provides a concrete starting point while keeping the process set open for future extension\.

#### 3\.1Model Initialization

Model initialization processes carry the prefixmlm\_and produce untrained model definition objects\. Each process name follows the pattern:

mlm\_<type\>\_<model\>

where<type\>is an abbreviated ML task category, such asclassfor classification,regrfor regression,segmfor segmentation, andgenfor generative models, and<model\>identifies the algorithm or architecture, such asrandom\_forest,svm,xgboost,tempcnn, ortae\.

Each initialization process returns aModelobject that captures the selected algorithm together with its initial hyperparameters and references to the corresponding training and inference routines\. This representation allows users to define models ranging from classical algorithms to deep learning architectures, while deferring all computation to later process stages\.

All initialization processes expose aseedparameter for controlling stochastic behavior and supporting reproducible experimentation\. Hyperparameters are given sensible default values so that models can be trained immediately without configuration; any parameter can be explicitly overridden during the initialization call to suit the specific task\. These parameters can alternatively be designated as tuning candidates for the dedicated search processesml\_tune\_grid, which evaluates a user\-defined grid of configurations, andml\_tune\_random, which samples configurations from user\-defined distributions[Bergstra and Bengio \(2012\)](https://arxiv.org/html/2609.13453#bib.bib29)\.

Integrating new algorithms\.The specification is designed so that new model types can be added without modifying any existing process\. A contributor adds a newmlm\_process by: \(i\) choosing a name that follows themlm\_<type\>\_<model\>convention; \(ii\) defining the process schema in JSON, specifying parameters, their types, and default values following the same structure shown in Appendix[11](https://arxiv.org/html/2609.13453#S11); \(iii\) returning aModelobject whosetrainfield holds the backend training routine and whosepredictfield holds the inference routine\. Once registered, the new process is immediately accessible throughml\_fitandml\_predictwithout any changes to those processes\. TheopenEOcraftdecorator mechanism illustrated in Section[6\.1](https://arxiv.org/html/2609.13453#S6.SS1)demonstrates this pattern concretely: a single decorated R function becomes a fully registeredopenEOprocess accessible to all client libraries\. Table[1](https://arxiv.org/html/2609.13453#S3.T1)lists the representative initialization processes currently included in the specification\.

Table 1:Examples of ML Initialization Processes \(mlm\_ prefix\) with representative tunable parameters\.
#### 3\.2Model Actions

Model action processes carry the prefixml\_and execute the core stages of an ML workflow: training, hyperparameter tuning, validation, inference, uncertainty estimation, and spatial post\-processing\. Each process name follows the pattern:

ml\_<action\>

The central process in this group isml\_fit, which takes the untrainedModelobject produced by any initialization process and trains it against a vector data cube containing input features and target labels\. In this iteration of the specification, train and test partitioning is handled internally; users provide their full labelled dataset without pre\-splitting\. Once trained, the model is passed toml\_predictfor predictions, or toml\_predict\_probabilitiesfor probability outputs on classification tasks\. Both prediction processes also accept models loaded from serialized formats, with ONNX[ONNX Community \(2019\)](https://arxiv.org/html/2609.13453#bib.bib43)recommended for cross\-backend portability\.

These probability outputs feed directly into downstream processes\.ml\_uncertainty\_classquantifies prediction confidence using measures such as least\-confidence, margin, or probability ratio, enabling human\-in\-the\-loop workflows by highlighting regions where model certainty is low or training data are sparse\.ml\_smooth\_classapplies Bayesian spatial smoothing to probability outputs, reducing per\-pixel classification noise and improving spatial coherence in scenes with mixed land cover types[Simoes et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib5)\. Finally,ml\_label\_classconverts a probability cube into a labeled output cube by applying softmax normalization and selecting the class with the highest probability at each location\.

Hyperparameter search is supported throughml\_tune\_gridandml\_tune\_random, and model evaluation throughml\_validate, which computes user\-selected performance metrics against a user\-provided validation set, andml\_validate\_kfold, which accepts an untrained model and a full training set, manages fold assignment internally, and returns the model refitted on the full training set alongside cross\-validation scores\. Table[2](https://arxiv.org/html/2609.13453#S3.T2)summarizes the full set of model action processes\. The design is open for extension, and new processes can be contributed under the same naming convention\.

Table 2:ML Action Processes \(ml\_ prefix\), including training, tuning, validation, and inference\.
#### 3\.3Model Management

Model management processes handle the storage and retrieval of ML artifacts, enabling models to be saved, shared, discovered, and reloaded across sessions and backends\. The processes follow existingopenEOnaming conventions, as listed in Table[3](https://arxiv.org/html/2609.13453#S3.T3)\.

Saving and loading are aligned with the STAC MLM extension[Charette\-Migneault et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib25)\(see Section[2\.3](https://arxiv.org/html/2609.13453#S2.SS3)\), so that saved models are catalogued as reproducible assets discoverable by other users and backends\. For models that are intended for local use rather than broad sharing, theload\_ml\_modelprocess provides direct access to models already registered within the current backend\.

Table 3:Model Management Processes\.

### 4Prototype Implementations

Three prototype implementations of the proposedopenEOML specification have been developed, each demonstrating how standardized ML processes can be integrated into EO data cube environments\. The implementations span R and Python ecosystems and cover both classical ML and deep learning workflows\. All three can be used with theopenEOclient libraries for R, Python, Julia, and JavaScript, as well as theopenEOweb editor \(Fig\.[3](https://arxiv.org/html/2609.13453#S4.F3)\), illustrating the applicability of the specification across diverse programming environments\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/ml-api-openeo-backend.png)Figure 3:openEObackend interaction with client libraries across languages\.None of the three implementations covers the full ML specification at this stage; feature completion is a goal for future development\. Table[4](https://arxiv.org/html/2609.13453#S4.T4)summarizes the capabilities of each implementation\.

Table 4:Overview of the three prototype implementations of the proposed ML specification and their respective capabilities\. Color coding distinguishes the two R\-based backends,openEOcubesandopenEOcraft\(blue\), from the Python\-basedopeneo\-processes\-dask\-mlbackend \(green\)\. Checkmarks indicate supported features; crosses indicate features not yet implemented\.#### 4\.1openEOcubes

openEOcubesis an R backend built on top ofgdalcubes[Appel and Pebesma \(2019\)](https://arxiv.org/html/2609.13453#bib.bib11), a library for managing spatiotemporal raster data as data cubes, exposed through theopenEOspecification via a dedicated driver[Pondi et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib20)\. Classical ML workflows are supported through thecaretpackage[Kuhn \(2008\)](https://arxiv.org/html/2609.13453#bib.bib21)\. Because ONNX model export is not natively available in R, thereticulate888[https://rstudio\.github\.io/reticulate/](https://rstudio.github.io/reticulate/)package is used to invoke Python tooling for serializing R\-trained models to ONNX format, enabling model portability across frameworks\. Deep learning workflows are handled through thetorch999[https://torch\.mlverse\.org/](https://torch.mlverse.org/)package for R, which supports training and inference of neural network models within theopenEOprocess model\.

#### 4\.2openEOcraft

openEOcraft101010[https://github\.com/Open\-Earth\-Monitor/openEOcraft](https://github.com/Open-Earth-Monitor/openEOcraft)is a generic, open\-source R backend designed to expose arbitrary R data cube implementations asopenEO\-compliant services\. In contrast toopenEOcubes, which is tightly coupled togdalcubes,openEOcraftintroduces a flexible abstraction layer built around a lightweight decorator mechanism \(@openeo\-process\) that registers R functions asopenEOprocesses without requiring changes to the core API\.

This mechanism enables straightforward integration of thesits[Simoes et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib5)package, an R library for satellite image time\-series classification, intoopenEO\-compliant workflows\.sitsprovides a broad range of classical ML and deep learning methods, and its integration demonstrates how the proposed specification accommodates diverse modelling approaches across R libraries while remaining consistent with theopenEOprocess model\.

1

2mlm\_class\_tempcnn␣<\-␣function\(

3␣␣cnn\_layers␣=␣c\(64,␣64,␣64\),

4␣␣cnn\_kernels␣=␣c\(5,␣5,␣5\),

5␣␣learning\_rate␣=␣5e\-4,

6␣␣epochs␣=␣150,

7␣␣batch\_size␣=␣64,

8␣␣seed␣=␣NULL

9\)␣\{

10␣␣list\(

11␣␣␣␣train␣=␣function\(training\_set\)␣\{

12␣␣␣␣␣␣if␣\(\!is\.null\(seed\)\)␣set\.seed\(seed\)

13␣␣␣␣␣␣model␣<\-␣sits::sits\_tempcnn\(

14␣␣␣␣␣␣␣␣cnn\_layers␣=␣cnn\_layers,

15␣␣␣␣␣␣␣␣cnn\_kernels␣=␣cnn\_kernels,

16␣␣␣␣␣␣␣␣opt\_hparams␣=␣list\(lr␣=␣learning\_rate\),

17␣␣␣␣␣␣␣␣epochs␣=␣epochs,

18␣␣␣␣␣␣␣␣batch\_size␣=␣batch\_size

19␣␣␣␣␣␣\)

20␣␣␣␣␣␣sits::sits\_train\(training\_set,␣model\)

21␣␣␣␣\}

22␣␣\)

23\}

Listing 1:Minimal example of exposing a new model initialization process via the@openeo\-processdecorator inopenEOcraft\.Listing[1](https://arxiv.org/html/2609.13453#LST1)illustrates the decorator pattern in practice\. The decorated function is registered as theopenEOprocessmlm\_class\_tempcnnand becomes immediately accessible to allopenEOclient libraries with a well\-defined parameter interface\. The function returns a model definition object represented as an R list that encapsulates the training routine while delegating the concrete implementation to thesitslibrary\. Additional ML methods can be integrated by adding new decorated functions that follow the samemlm\_naming conventions and return structure\.

openEOcraft’s preprocessing is built aroundcube\_regularize, which wrapssits’sits\_regularizeand performs temporal regularization and cloud masking as a single bundled step rather than as separate composable openEO processes\. Running the RF workflow in Section[5](https://arxiv.org/html/2609.13453#S5)requiresaggregate\_temporal\_periodandmaskto be exposed individually, which means decomposing sits internals\. Since sits is maintained by INPE \(Brazil’s National Institute for Space Research\) and lies outside the authors’ control, this refactoring was not feasible; openEOcraft is therefore excluded from that comparison\. It was selected as a prototype backend becausesitshas been in active development for over five years, tested at continental scale across South America, and covers both classical ML and deep learning in a single package\. The sits tibble\-\-\-the package’s native data structure for training samples, distributed in most published datasets as RDS files on GitHub111111[https://github\.com/e\-sensing/sitsdata](https://github.com/e-sensing/sitsdata)—also makes it a distinctive case for examining how proprietary data formats interact with the specification, a point taken up in Section[7](https://arxiv.org/html/2609.13453#S7)\.

#### 4\.3openeo\-processes\-dask\-ml

This is the only implementation among the three that supports all three EO ML workflow types: engineered feature vectors, pixel\-wise time series, and spatial neighborhoods\. A key feature is automatic input and output reshaping: the STAC MLM metadata associated with a loaded model specifies the expected input shape and its correspondence to data cube dimensions, and the implementation automatically reshapes the EO data cube to match before inference and reconstructs the model output into a data cube after prediction\.

At present, the implementation supports inference from pre\-trained models but does not yet include fine\-tuning support\. Adoption by operational backends has been limited by the challenge of robustly integrating parallelized Dask computations with ML frameworks such as PyTorch and CUDA for GPU\-accelerated inference\. Section[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)demonstrates the current capabilities through a patch\-level prediction use case using an EO foundation model\.

Together, the three implementations demonstrate that a standardized ML specification can be realized across multipleopenEObackend services and programming environments, supporting interoperable and reproducible ML workflows on EO data cubes across both classical ML and deep learning paradigms\. Sections[5](https://arxiv.org/html/2609.13453#S5)and[6](https://arxiv.org/html/2609.13453#S6)exercise these implementations through revealing feasibility demonstrations—each use case shows what the specification achieves under realistic conditions and where current limits remain, an approach the broader federatedopenEOplatform \([https://openeo\.cloud/](https://openeo.cloud/)\) took from proof\-of\-concept[Jacob et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib46)to matured federation[Mohr et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib15)\.

### 5Cross\-Backend Interoperability: Crop Type Mapping in Brittany, France

To demonstrate how the proposedopenEOML specification enables interoperable EO workflows across multiple backends, we designed a crop type mapping use case in which an identical client\-side process graph is submitted to R\-basedopenEOcubesand Python\-basedopeneo\-processes\-dask\-mlwithout modification; openEOcraft is not included in this comparison for reasons detailed in Section[4](https://arxiv.org/html/2609.13453#S4)\. The same Random Forest classifier is trained to identify crop types in Brittany \(Breizh\), France, and applied to map crop types in a neighboring region on each backend independently, allowing the predictions and evaluation metrics to be directly compared\. This use case specifically targets the feature\-based workflow type introduced in Section[2\.2](https://arxiv.org/html/2609.13453#S2.SS2), in which a data cube is reduced to a tabular feature matrix before being passed to a classical ML estimator\.

#### 5\.1Workflow Design

The workflow \(Fig\.[4](https://arxiv.org/html/2609.13453#S5.F4)\) separates a training region from an independent prediction region\. The prediction area is located in northwestern Brittany, covering approximately−4\.02∘\-4\.02^\{\\circ\}to−3\.74∘\-3\.74^\{\\circ\}longitude and48\.10∘48\.10^\{\\circ\}to48\.20∘48\.20^\{\\circ\}latitude\. The training area is directly north of it, covering−4\.02∘\-4\.02^\{\\circ\}to−3\.74∘\-3\.74^\{\\circ\}longitude and48\.20∘48\.20^\{\\circ\}to48\.30∘48\.30^\{\\circ\}latitude\. Two Sentinel\-2 Level 2A data cubes are loaded for the May to September 2017 growing season, including 12 reflectance bands and the Scene Classification Layer \(SCL\), and filtered to scenes with cloud cover below 50 % to reduce noise in the temporal composites\.

Both cubes undergo identical preprocessing to ensure consistent feature construction across training and inference\. Cloud and cloud\-shadow masking is derived from the SCL band, after which the SCL band is dropped and only the reflectance bands are retained\. Temporal aggregation is performed usingaggregate\_temporal\_periodto generate cloud\-free monthly median composites\. The Normalized Difference Vegetation Index \(NDVI\) is then derived and appended as an additional feature band\. These steps regularize the original spatio\-temporal data cubes and produce feature\-consistent representations suitable for classical ML\.

For training, we use field polygons with crop type labels from the BreizhCrops dataset[Rußwurm et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib27)for 2017 and clip them to the bounding box of the training area, yielding 3,173 labeled field\-parcel polygons\. Theaggregate\_spatialoperation reduces the preprocessed training cube to a vector data cube containing, for each labeled geometry, the median value of every spectral band\.

Model initialization follows the standardized pattern introduced in Section[3](https://arxiv.org/html/2609.13453#S3)\. The classifier is created viamlm\_class\_random\_forest, specifying 150 trees, square\-root feature sampling at each split, and a fixed random seed for reproducibility\. Training is executed throughml\_fit\(invoked in the Python client via thefit\(\)wrapper\), returning a trained model object\. For inference, the trained model is applied to the independently preprocessed prediction cube usingml\_predict\(via thepredict\(\)wrapper\), producing a categorical data cube of crop type predictions over the prediction region\. The output is exported as GeoTIFF usingsave\_resultand submitted as an asynchronous backend job\.

1import␣openeo

2

3

4connection␣=␣openeo\.connect\(

5␣␣␣␣url="<host\-url\>",␣auth\_type="basic",

6␣␣␣␣auth\_options=\{"username":␣"<user\>",␣"password":␣"<password\>"\}

7\)

8

9

10COLLECTION\_NAME␣=␣"sentinel\-2\-l2a"

11BAND\_NAMES␣=␣\[

12␣␣␣␣"coastal",␣"blue",␣"green",␣"red",␣"rededge1",␣"rededge2",

13␣␣␣␣"rededge3",␣"nir",␣"nir08",␣"nir09",␣"swir16",␣"swir22",␣"scl"

14\]

15

16

17training\_data\_path␣=␣"\./breizh\_data\.geojson"

18

19

20def␣prepare\_datacube\(bbox\):

21␣␣␣␣datacube␣=␣connection\.load\_collection\(

22␣␣␣␣␣␣␣␣collection\_id=COLLECTION\_NAME,

23␣␣␣␣␣␣␣␣spatial\_extent=bbox,

24␣␣␣␣␣␣␣␣temporal\_extent=\["2017\-05\-01T00:00:00Z",␣"2017\-09\-30T23:59:59Z"\],

25␣␣␣␣␣␣␣␣bands=BAND\_NAMES,

26␣␣␣␣␣␣␣␣max\_cloud\_cover=50,

27␣␣␣␣\)

28␣␣␣␣

29␣␣␣␣scl␣=␣datacube\.band\("SCL"\)

30␣␣␣␣cloud\_mask␣=␣\(scl␣==␣3\)␣\|␣\(scl␣==␣8\)␣\|␣\(scl␣==␣9\)

31

32␣␣␣␣

33␣␣␣␣datacube␣=␣datacube\.filter\_bands\(b␣for␣b␣in␣BAND\_NAMES␣if␣b␣\!=␣"SCL"\)

34␣␣␣␣datacube␣=␣datacube\.mask\(cloud\_mask\)

35

36␣␣␣␣

37␣␣␣␣datacube␣=␣datacube\.aggregate\_temporal\_period\(period="month",␣reducer="median"\)

38

39␣␣␣␣

40␣␣␣␣datacube␣=␣datacube\.ndvi\(red="red",␣nir="nir",␣target\_band="NDVI"\)

41

42␣␣␣␣return␣datacube

43

44

45

46datacube\_predict␣=␣prepare\_datacube\(\{"west":␣\-4\.02,␣"south":␣48\.10,␣"east":␣\-3\.74,␣"north":␣48\.20,␣"crs":␣4326\}\)

47datacube\_train␣␣␣=␣prepare\_datacube\(\{"west":␣\-4\.02,␣"south":␣48\.20,␣"east":␣\-3\.74,␣"north":␣48\.30,␣"crs":␣4326\}\)

48

49

50training\_data␣=␣datacube\_train\.aggregate\_spatial\(training\_data\_path,␣"median"\)

51

52

53rf\_model␣=␣connection\.mlm\_class\_random\_forest\(num\_trees=150,␣seed=42,␣max\_variables="sqrt"\)

54rf\_model\_fitted␣=␣rf\_model\.fit\(training\_set=training\_data,␣target="class\_name"\)

55

56

57predictions␣=␣rf\_model\_fitted\.predict\(datacube\_predict\)

58

59

60result␣=␣predictions\.save\_result\("GTiff"\)

61job␣=␣result\.create\_job\(\)

62job\.start\_and\_wait\(\)

63job\.get\_results\(\)\.download\_files\("output"\)

Figure 4:PythonopenEOclient workflow for crop type mapping using a Random Forest classifier\. The workflow loads Sentinel\-2 data, applies SCL\-based cloud masking, selects reflectance bands, computes monthly median composites, derives NDVI, aggregates training features over labeled geometries, trains the model, and applies it to a separate prediction region\.
#### 5\.2Comparison of Results

The most direct test of cross\-backend interoperability is whether two independent implementations of the same process graph reach comparable predictive performance\. Both backends achieve an overall accuracy of 0\.82 on the held\-out prediction region \(Table[5](https://arxiv.org/html/2609.13453#S5.T5)\), despite relying on different language ecosystems \(R withcaretversus Python withscikit\-learn\) and different data cube engines \(gdalcubesversusxarray\)\. Per\-class metrics follow the same pattern in both implementations: high precision and recall for corn, wheat, and rapeseed, and substantially lower scores for permanent and temporary meadows\. The remaining numerical differences are small \(typically within±\\pm0\.05 across all metrics\) and are consistent with implementation\-level choices in the underlying ML libraries that the openEO process graph does not constrain — for example, the specific Random Forest variant, default split criteria, and internal random\-number\-generator behavior\. The fixed seed therefore guarantees reproducibility within a backend, but not across backends written against different ML frameworks\.

Table 5:Per\-class precision, recall, and F1 score for the Random Forest crop type classifier on the held\-out prediction region\.Per\-class metrics against ground truth do not directly measure agreement between the two backends\. We therefore also compute Cohen’sκ\\kappaover 258,168 paired pixels at 30 m resolution, treating the two backend predictions as independent raters\. The backends reachκ=0\.76\\kappa=0\.76, characterised by Landis and Koch[Landis and Koch \(1977\)](https://arxiv.org/html/2609.13453#bib.bib38)as “substantial” agreement\. We report the point estimate without a confidence interval, since adjacent pixels within fields are not statistically independent[Foody \(2004\)](https://arxiv.org/html/2609.13453#bib.bib39)\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/use-case-1-france.png)Figure 5:Crop type maps for the prediction region in Brittany \(Breizh\), France, produced by applying the trained Random Forest classifier to the Sentinel\-2 data cube\. The maps show the spatial distribution of the six crop classes included in the BreizhCrops training dataset, as produced by theopeneo\-processes\-dask\-ml\(top\) andopenEOcubes\(bottom\) implementations\.Visual inspection of the predicted maps \(Fig\.[5](https://arxiv.org/html/2609.13453#S5.F5)\) confirms that the spatial patterns produced by the two backends are highly consistent at the parcel scale, with minor disagreements concentrated along field boundaries and in mixed\-cover patches\. The class\-frequency histogram \(Fig\.[6](https://arxiv.org/html/2609.13453#S5.F6)\) shows that the marginal distributions of predicted classes also align closely between backends, with the largest discrepancy occurring in the temporary\-meadow / wheat split — the same classes that contribute most to the lower per\-class metrics in Table[5](https://arxiv.org/html/2609.13453#S5.T5)\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/use_case_1_histogram.png)Figure 6:Relative frequency of classes assigned to a pixel in the prediction area for theopenEOcubesandopeneo\-processes\-dask\-mlimplementations\.Because the prediction area also contains urban surfaces, forests, and water bodies that the six\-class crop classifier was not trained to recognize, a pixel\-wise comparison overstates the relevance of background disagreements for the agricultural use case\. We therefore complement the pixel\-level metrics with a field\-level comparison: for each BreizhCrops field polygon, we extract the modal predicted class from each backend and compute the proportion of polygons assigned the same class\. Across all 3,173 fields, the two backends agree on the modal crop type for 85 % of polygons\. The residual disagreements concentrate on field types where per\-class metrics are weakest in Table[5](https://arxiv.org/html/2609.13453#S5.T5), notably the permanent\-meadow / temporary\-meadow split, consistent with both backends struggling on the same inherently ambiguous cases rather than failing in implementation\-specific ways\.

Random Forest is widely used in EO classification practice[Belgiu and Drăguţ \(2016\)](https://arxiv.org/html/2609.13453#bib.bib4);[Maxwell et al\. \(2018\)](https://arxiv.org/html/2609.13453#bib.bib6)\. R and Python implementations use different random number generators and tree\-building strategies, so pixel\-level exact agreement across backends is not expected even with a fixed seed\. Statistical equivalence is the right bar, and the findings meet it\. A difference would become concerning if backends diverged on classes each handles well independently, or if spatial disagreement followed geographic rather than classification boundaries; neither condition holds here\. Full bitwise reproducibility still requires deeper harmonization of ML library defaults and serialization conventions, a point we return to in Section[7](https://arxiv.org/html/2609.13453#S7)\.

### 6Use Cases: Deep Learning and Foundation Model Workflows

The following two use cases complement the feature\-based Random Forest workflow presented in Section[5](https://arxiv.org/html/2609.13453#S5)by covering the remaining two EO ML workflow types introduced in Section[2](https://arxiv.org/html/2609.13453#S2): pixel\-wise time series classification and spatial patch\-based inference\. Together, all three use cases demonstrate that the proposed ML API specification is applicable across the full range of supervised ML paradigms currently employed in EO practice\.

#### 6\.1TempCNN for Land Cover Mapping in Brazil

This use case demonstrates how the proposed ML API enables a reproducible, backend\-agnostic deep learning workflow for land cover monitoring in Brazil\. The workflow uses a Temporal Convolutional Neural Network \(TempCNN\)[Pelletier et al\. \(2019\)](https://arxiv.org/html/2609.13453#bib.bib14)trained on pixel\-level Sentinel\-2 time series and executed within anopenEO\-compliant backend via thesitspackage[Simoes et al\. \(2021\)](https://arxiv.org/html/2609.13453#bib.bib5)\. It highlights three core aspects of the ML API: model initialization, model tuning/training and prediction, and serialization of model artifacts in the backend\.

Training data consist of 6,007 labelled Sentinel\-2 time series covering the state of Rondônia in the Brazilian Amazon\. Each sample comprises a 16\-day composite for 2022 \(23 observations\) at 10 metres spatial resolution and is assigned to one of nine land cover classes relevant to deforestation monitoring, includingClear\_Cut\_Bare\_Soil,Clear\_Cut\_Burned\_Area,Clear\_Cut\_Vegetation, andForest\. Samples were collected through visual interpretation and are available in thesitsdatapackage151515[https://github\.com/e\-sensing/sitsdata](https://github.com/e-sensing/sitsdata)under a CC\-BY 4\.0 license\.

BecauseopenEOcraftexposes the standardized ML processes introduced in Section[3](https://arxiv.org/html/2609.13453#S3), the entire pipeline is captured in a single process graph \(see Appendix[10](https://arxiv.org/html/2609.13453#S10)\) and can be replayed across infrastructures without modifying the client code\. Figure[7](https://arxiv.org/html/2609.13453#S6.F7)summarises the workflow\.

1

2library\(openeo\)

3

4

5connection␣<\-␣connect\(host␣=␣"<host\-url\>",␣user␣=␣"<user\>",␣password␣=␣"<password\>"\)

6

7

8p␣<\-␣processes\(\)

9

10

11deforestation\_data␣<\-

12␣␣"https://github\.com/e\-sensing/sitsdata/raw/main/data/samples\_deforestation\_rondonia\.rds"

13

14

15tempcnn\_model\_init␣<\-␣p$mlm\_class\_tempcnn\(

16␣␣optimizer␣=␣"adam",␣epochs␣=␣20,␣batch\_size␣=␣64

17\)

18

19

20param\_grid␣<\-␣list\(

21␣␣learning\_rate␣=␣c\(0\.0005,␣0\.0001\),

22␣␣epochs␣=␣c\(20,␣40\)

23\)

24

25

26tempcnn\_tuned␣<\-␣p$ml\_tune\_grid\(

27␣␣model␣=␣tempcnn\_model\_init,

28␣␣training\_data␣=␣deforestation\_data,

29␣␣target␣=␣"label",

30␣␣parameters␣=␣param\_grid,

31␣␣scoring␣=␣"accuracy",

32␣␣cv␣=␣0,

33␣␣seed␣=␣42

34\)

35

36

37tempcnn\_model␣<\-␣p$save\_ml\_model\(

38␣␣data␣=␣tempcnn\_tuned,

39␣␣name␣=␣"tempcnn\_rondonia\_tuned\_v1",

40␣␣return\_model␣=␣TRUE

41\)

42

43

44datacube␣<\-␣p$load\_collection\(

45␣␣id␣=␣"mpc\-sentinel\-2\-l2a",

46␣␣spatial\_extent␣=␣list\(west␣=␣\-63\.50,␣east␣=␣\-63\.35,

47␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣south␣=␣\-8\.92,␣north␣=␣\-8\.78\),

48␣␣temporal\_extent␣=␣c\("2022\-01\-01",␣"2022\-12\-31"\),

49␣␣bands␣=␣list\("B02",␣"B03",␣"B04",␣"B05",␣"B06",␣"B07",␣"B08",

50␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"B11",␣"B12",␣"B8A"\)

51\)

52

53

54datacube␣<\-␣p$cube\_regularize\(data␣=␣datacube,␣period␣=␣"P16D",␣resolution␣=␣30\)

55

56

57datacube␣<\-␣p$ndvi\(data␣=␣datacube,␣red␣=␣"B04",␣nir␣=␣"B08",␣target\_band␣=␣"NDVI"\)

58

59

60data␣<\-␣p$ml\_predict\(data␣=␣datacube,␣model␣=␣tempcnn\_model\)

61

62

63ml\_job␣<\-␣p$save\_result\(data␣=␣data,␣format␣=␣"GTiff"\)

64job␣<\-␣create\_job\(graph␣=␣ml\_job,

65␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣title␣=␣"TempCNNfine\-tuning\+inference"\)

66job␣<\-␣start\_job\(job\)

67

68

69while␣\(status\(job\)␣\!=␣"finished"\)␣Sys\.sleep\(30\)

70

71

72download\_results\(job␣=␣job,␣folder␣=␣"\./results/"\)

Figure 7:RopenEOclient code fine\-tuning a TempCNN with grid search on labelled Sentinel\-2 time series from Rondônia, Brazil, computing NDVI as an additional feature, applying the tuned model for land\-cover inference, and downloading the prediction GeoTIFF and tuning report on job completion\.After authenticating with the backend, the client initializes a TempCNN viamlm\_class\_tempcnn, specifying the optimizer and base hyperparameters as provenance metadata\.ml\_tune\_gridthen conducts a four\-run grid search over two learning rates \(0\.00050\.0005,0\.00010\.0001\) and two epoch counts \(20, 40\), scoring each candidate by validation accuracy on the Rondônia samples \(Table[6](https://arxiv.org/html/2609.13453#S6.T6)\)\. The best configuration—learning rate0\.00050\.0005, 40 epochs—achieves 93\.1 % validation accuracy and is refitted on the full training set before being persisted viasave\_ml\_model\. This artifact can subsequently be retrieved usingload\_stac\_mlin a new job, ensuring reproducibility of both architecture and weights across sessions\.

Table 6:TempCNN grid search results on the Rondônia training set\. Run 2 was selected for final training\.For inference, the workflow loads a Sentinel\-2 Level 2A data cube clipped to the Rondônia area of interest for 2022, with spatial\(x,y\)\(x,y\), temporal\(t​i​m​e\)\(time\), and band\(b​a​n​d\)\(band\)dimensions\. Preprocessing is applied within the same process graph to guarantee consistent feature engineering: the cube is harmonized to 16\-day intervals and resampled to a consistent spatial resolution, yielding an aligned multivariate time series per pixel\. Thendviprocess derives and appends a vegetation index band, producing an augmented feature cube that combines spectral reflectances with a derived index\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/use-case-2-brazil.png)Figure 8:Land cover classification map for the Rondônia study area, generated by applying the trained TempCNN model to Sentinel\-2 time series\. The map shows the spatial distribution of the nine land cover classes used in training and demonstrates execution of a deep learning workflow on EO data cubes, from preprocessing and inference to export of a categorical output cube\.Theml\_predictprocess streams each multiband pixel time series through the trained TempCNN along the temporal dimension, generating a categorical prediction per spatial location\. This operation reduces the feature cube to a single classification layer while preserving the spatial grid\. The result is exported as GeoTIFF viasave\_resultand executed asynchronously throughcreate\_jobandstart\_job\. Once the job completes,download\_resultsretrieves both the land cover GeoTIFF and the tuning report from the backend\. All preprocessing and inference steps remain encoded in the process graph, ensuring reproducibility and backend\-agnostic execution\. The exported map is visualized in Fig\.[8](https://arxiv.org/html/2609.13453#S6.F8)\.

#### 6\.2Foundation Model Inference for EO Embeddings

Recent advances in self\-supervised representation learning have produced a growing set of so\-called Foundation Models \(FM\) for EO\. These models transform their input into compact, task\-agnostic embedding vectors which can generalize to a wide variety of downstream tasks[Jakubik et al\. \(2023\)](https://arxiv.org/html/2609.13453#bib.bib3)\. Many FMs operate on spatial neighborhoods and are therefore supported only by theopeneo\-processes\-dask\-mlimplementation at the time of writing\. As noopenEObackend has adopted this implementation yet, client code cannot be provided\. The process graph is instead constructed manually and invoked as if received through theopenEOAPI\.

While the previous use cases \([5](https://arxiv.org/html/2609.13453#S5)and[6\.1](https://arxiv.org/html/2609.13453#S6.SS1)\) focused on pixel\-level time series, we demonstrate in this section how our proposed API support state\-of\-the\-art spatial patch\-based ML tasks: Specifically: we show howload\_stac\_mlandml\_predictcan be chained to load a the pre\-trained Terramind FM from an external STAC catalog and transform an EO datacube into a datacube of embeddings through theopenEOAPI\.

![Refer to caption](https://arxiv.org/html/2609.13453v1/figures/ml_predict_fm.png)Figure 9:Conceptual chaining ofload\_stac\_mlandml\_predictto transform a Sentinel\-2 EO data cube into a data cube of embeddings using the TerraMind foundation model\.The pre\-trained TerraMind\-v1\-base backbone[Jakubik et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib2)is loaded as a STAC MLM Item[Charette\-Migneault et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib25)viaload\_stac\_ml\(Fig\.[9](https://arxiv.org/html/2609.13453#S6.F9)\)\. The STAC MLM metadata specifies the model’s expected input and output shapes and their correspondence to EO data cube dimensions \(thebatchdimension is created dynamically and can be of arbitrary length\):

- •Model input:\{batch: \-1, band: 12, y: 224, x: 224\}
- •Model output:\{batch: \-1, embedding\_level: 24, patch: 196, embedding: 1024\}

Theml\_predictprocess matches model input and output dimension shapes to the data cube dimensions and transforms them accordingly:

- •timeis present in the data cube but not in the model input; the model is therefore applied independently at each time step\.
- •bandis present in the data cube and the model input but absent from the model output; this dimension is dropped in the output\.
- •x, yare present in the data cube and the model input but absent from the model output\. The model is applied along the spatial dimensions, and each prediction covers the full spatial footprint of the input patch\. The spatial dimensions in the output data cube are therefore reduced such thaty=⌊2242÷224⌋=10y=\\lfloor 2242\\div 224\\rfloor=10andx=⌊2213÷224⌋=9x=\\lfloor 2213\\div 224\\rfloor=9\. The remaining2242−10×224=22242\-10\\times 224=2pixels inyyand2213−9×224=1972213\-9\\times 224=197pixels inxxare insufficient to form a complete input patch and are not represented in the output\.
- •embedding\_level,patch, andembeddingare absent from the model input but present in the model output; these dimensions are therefore added to the output data cube\.

The resulting data cube of embeddings is not visualized here, as embeddings are an abstract, high\-dimensional representation for which direct visual interpretation is not meaningful\. In a next step, an application\-specific downstream task model could derive meaningful results from the embeddings \(e\.g\., a water segmentation map\), or they could be saved to file and downloaded to the client, thereby elevating the openEO\-API to serve as an interface for ad\-hoc earth embedding generation\.

#### 6\.3Synthesis Across Use Cases

Considered together, the three use cases in Sections[5](https://arxiv.org/html/2609.13453#S5),[6\.1](https://arxiv.org/html/2609.13453#S6.SS1), and[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)cover the full range of supervised ML workflow types for EO data cubes identified in Section[2\.2](https://arxiv.org/html/2609.13453#S2.SS2): feature\-based classification using Random Forests, pixel\-wise time\-series classification using TempCNN, and spatial patch\-based inference using a geospatial foundation model\. In each case, the same core processes — themlm\_initialization family,ml\_fitorml\_tune\_\*,ml\_predict, and the model management processes — are composed within a single declarative process graph\. Use Cases[5](https://arxiv.org/html/2609.13453#S5)and[6\.1](https://arxiv.org/html/2609.13453#S6.SS1)execute these graphs end\-to\-end on live backends; Use Case[5](https://arxiv.org/html/2609.13453#S5)runs across two of the three prototype backends rather than all three, because openEOcraft’s bundled preprocessing step is not directly composable into the process graph that comparison requires \(Section[4](https://arxiv.org/html/2609.13453#S4)\)\. Use Case[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)demonstrates the dimensional reshaping logic\. This consistency across diverse model families and workflow types confirms that the three\-stage specification is sufficient to cover the full range of supervised ML workflows currently employed in EO practice, and motivates the reflection on its broader implications that follows\.

### 7Discussion

Building on the use cases of Sections[5](https://arxiv.org/html/2609.13453#S5)–[6\.2](https://arxiv.org/html/2609.13453#S6.SS2), this section reflects on how the proposed specification realizes its stated aims, what the prototype implementations revealed about the practical challenges of standardizing ML across heterogeneous EO backends, and what remains to be addressed in future work\.

#### 7\.1Core Aims and Their Realization

##### 7\.1\.1Accessibility

By abstracting ML workflows into high\-level processes with sensible default hyperparameters, the specification allows domain experts to apply methods such as Random Forest, XGBoost, TempCNN, or TAE without requiring deep programming or ML expertise\. Multi\-language client support further lowers the entry barrier by letting users work in their preferred environment\. At the same time, configurability within the specification is preserved: hyperparameters defined in each process schema can be explicitly overridden during initialization or systematically explored through the dedicated tuning processesml\_tune\_gridandml\_tune\_random\. Integration with the STAC MLM extension supports discovery and reuse of pre\-trained models, reducing the computational burden for users who do not need to train from scratch\. The inclusion of validation and tuning processes extends the specification beyond single\-pass model execution, enabling systematic model development and evaluation within the same declarative workflow abstraction\.

Accessibility depends, however, on more than standardized APIs\. The need to accommodate backend\-specific conventions for model serialization and data handling, including formats such assitstibbles and R data frames, highlights that further standardization of data exchange formats across environments remains an open challenge\. The range of models and configurable parameters available in practice also depends on which processes each backend has implemented; users who require access to the full parameter space of an underlying library retain more flexibility by using it directly, and the specification is designed for portability and accessibility rather than as a substitute for direct library use\.

##### 7\.1\.2Interoperability

The specification enables portable ML workflows across cloud backends, local installations, and self\-hosted systems through backend\-agnostic process definitions\. The three prototype implementations demonstrate that equivalent conceptual workflows can be executed across diverse infrastructures\. Use Case[5](https://arxiv.org/html/2609.13453#S5)confirms this at the process level: an identical client\-side process graph submitted to bothopenEOcubesandopeneo\-processes\-dask\-mlwithout modification yields predictions that match in overall accuracy, and converge on the same dominant class at the parcel level with substantial pixel\-level agreement \(κ=0\.76\\kappa=0\.76\), despite the backends relying on entirely different execution engines\.

Achieving full interoperability across backends, however, requires alignment that goes beyond the API layer\. Cross\-backend execution remains challenging due to differences in programming language ecosystems, feature engineering conventions, and model serialization mechanisms\. ONNX adoption as the recommended serialization format enables cross\-platform model exchange, but introduces practical constraints: R backends currently require Python bridging via thereticulatepackage to export ONNX artifacts, and models stored assits\-specific R class objects are not directly portable to Python backends\. These issues reflect a broader challenge: while the specification successfully standardizes process interfaces, deeper harmonization of data formats, serialization standards, and execution semantics is needed before seamless cross\-backend reproducibility can be taken for granted\.

Random Forest was selected as the reference algorithm because it is the most widely used classifier in EO workflows[Belgiu and Drăguţ \(2016\)](https://arxiv.org/html/2609.13453#bib.bib4);[Maxwell et al\. \(2018\)](https://arxiv.org/html/2609.13453#bib.bib6)and is available natively across all three prototype backends; the criteria for distinguishing specification failures from implementation\-level noise in such a comparison are established in Section[5](https://arxiv.org/html/2609.13453#S5)\. For applications requiring stronger guarantees, ONNX model exchange—loading an identical trained artifact on a second backend viaload\_stac\_ml—would reduce remaining differences to preprocessing divergences alone\.

##### 7\.1\.3Reproducibility

Reproducibility is built into the specification through seed control, explicit hyperparameter records, and composable process graphs that encode complete analytical workflows\. The use cases demonstrate successful model persistence and reloading viasave\_ml\_modelandload\_stac\_ml, enabling full pipeline recreation across sessions and computational environments\. Whensave\_ml\_modelis invoked, the specification allows contextual metadata including software dependencies, model inputs and outputs, and system configurations to be recorded and exported as a STAC MLM Item, providing a structured mechanism for preserving the computational environment alongside the model artifact\.

In practice, reproducibility is still affected by variations in backend libraries and dependency management\. Identical process graphs may yield slightly different numerical results if model implementations, library versions, preprocessing steps, or data coverage differ across backends\. Handling vector training labels introduces further ambiguity in cases of partial spatial overlaps, mixed pixels, or temporal misalignment between features and labels\. Addressing these issues fully will require both tighter conventions for data exchange and more explicit backend conformance reporting\.

##### 7\.1\.4Extensibility

The modular process structure provides a foundation for community\-driven extensions that can accommodate emerging ML paradigms without altering the core specification\. The integration of the TerraMind foundation model[Jakubik et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib2)in Use Case[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)demonstrates how large pre\-trained models can be incorporated into the same standardized interface for inference and downstream adaptation\. Foundation models such as TESSERA[Feng et al\. \(2026\)](https://arxiv.org/html/2609.13453#bib.bib35), Prithvi[Szwarcman et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib26)and TerraMind[Jakubik et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib2), trained on large EO datasets, offer the possibility of reducing labeled data requirements and improving model generalization across regions and tasks\.

Federated learning workflows[Moreno\-Álvarez et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib19)represent another candidate for incremental integration through the same process\-level abstraction\. Random Forest is a natural starting point: local forests trained on regional data cubes at each backend can be retrieved viaload\_stac\_mland aggregated into a global ensemble[Hauschild et al\. \(2022\)](https://arxiv.org/html/2609.13453#bib.bib45);[Liu et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib44), with no raw training data leaving any backend\.

Long\-term success will require sustained community participation, consistent governance, and iterative refinement based on operational feedback\. TheopenEOecosystem supports these goals through its Project Steering Committee and regular community meetings, which provide structured mechanisms for shared decision\-making and transparent evolution of the specification\.

#### 7\.2Lessons from Prototype Implementations

The three prototype implementations reveal how backend\-specific design choices interact with the shared specification and where the boundaries of portability currently lie\.

openEOcubes, built ongdalcubes, R Torch, andcaret, supports both feature\-based and time\-series workflows but requires custom ONNX export pathways that depend on Python bridging, introducing a fragility that would not arise in a natively cross\-language serialization standard\.openEOcraftsupports both workflow types, but as discussed in Section[4](https://arxiv.org/html/2609.13453#S4), its bundled preprocessing step, and itssits\-native data model constrain direct portability to other backends\. The Python implementation usingxarrayand Dask enables distributed computation and is the only implementation covering all three workflow types, but it introduces different constraints around memory management, process scheduling, and GPU integration that have so far limited adoption by operational backends\.

Together, these differences illustrate both the value and the limits of a shared specification\. The specification successfully defines a consistent conceptual model that allows users to express ML workflows in a backend\-agnostic form\. What it cannot yet fully guarantee is that those workflows execute identically across backends, because execution fidelity depends on decisions made below the process level: library versions, serialization formats, and data structure conventions that fall outside the scope of the current specification\. Addressing this gap systematically, through explicit backend conformance profiles that document process availability, supported formats, and known behavioral differences, would substantially improve the practical utility of the specification in operational and research settings alike\.

### 8Conclusion

This paper introduced a standardized ML specification for EO data cubes within theopenEOecosystem, organized into three coherent stages: model initialization, model actions, and model management\. Three prototype implementations in R and Python, validated through crop type mapping, land cover classification, and foundation model inference use cases, demonstrate that the specification is practically realizable across diverse technology stacks and that an identical process graph submitted to independent backends yields predictions that match in overall accuracy and converge on the same dominant class at the parcel level\.

The use cases collectively cover all three EO ML workflow types identified in this paper: feature\-based classification, pixel\-wise time\-series modeling, and spatial patch\-based inference\. This breadth confirms that a single, backend\-agnostic process\-level abstraction is sufficient to express the dominant supervised ML paradigms currently employed in EO practice\. The integration of the TerraMind foundation model[Jakubik et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib2)and compliance with the STAC MLM extension[Charette\-Migneault et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib25)further demonstrate that the specification extends naturally to pre\-trained model reuse and catalog\-based model discovery, reducing the barrier to entry for users who do not need to train from scratch\.

Although the specification facilitates portability of ML\-based processing of EO data cubes, full interoperability across backends, however, requires deeper alignment of data formats, model serialization standards, and execution semantics than the current process\-level specification alone can enforce\. Reproducibility is still affected by backend library versions and preprocessing conventions that fall outside the specification boundary\. Addressing these gaps systematically, through explicit backend conformance profiles and tighter data exchange conventions, is the most important direction for near\-term development\.

The modular architecture provides a foundation for incremental extension\. The decorator\-based registration mechanism demonstrated inopenEOcraftshows how new algorithms can be integrated without modifying the core API, and the same process\-level abstraction provides a foundation for future extension to emerging paradigms, including federated learning[Moreno\-Álvarez et al\. \(2024\)](https://arxiv.org/html/2609.13453#bib.bib19)and self\-supervised foundation models[Jakubik et al\. \(2023\)](https://arxiv.org/html/2609.13453#bib.bib3);[Szwarcman et al\. \(2025\)](https://arxiv.org/html/2609.13453#bib.bib26);[Feng et al\. \(2026\)](https://arxiv.org/html/2609.13453#bib.bib35)\. Operational adoption in environments such as the Copernicus Data Space Ecosystem, the federatedopenEOplatform, VITO’s Terrascope platform, and IBM’s TensorLakeHouse is a natural next step, contingent on the robust integration of distributed computation frameworks with ML execution backends\.

By defining process\-level abstractions that bridge EO data cubes with tabular and tensor\-based ML representations, the specification makes ML workflows on EO data more interoperable, reproducible, and accessible across the infrastructure heterogeneity that characterizes operational Earth observation today\.

### 9Availability and Requirements

ML API Specification:The proposed ML API specification is openly available under the Apache License Version 2\.0 in theproposalsdirectory of the following repository:[https://github\.com/PondiB/openeo\-processes/tree/ml\-api](https://github.com/PondiB/openeo-processes/tree/ml-api)\.

Use Case Examples:Reproducible code for all use cases presented in this paper, including the crop type mapping workflow \(Section[5](https://arxiv.org/html/2609.13453#S5)\), the TempCNN land cover classification \(Section[6\.1](https://arxiv.org/html/2609.13453#S6.SS1)\), and the foundation model embedding pipeline \(Section[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)\), is openly available under the Apache License Version 2\.0 at:[https://github\.com/PondiB/openeo\-ml\-showcase](https://github.com/PondiB/openeo-ml-showcase)\.

Operating System:All three prototype implementations are compatible with Windows, macOS, and Linux\.

##### Acknowledgments

We gratefully acknowledge financial support from the European Union’s Horizon Europe research and innovation programme\. Authors BP and JS are supported under agreement No\. 101059548 for the Open\-Earth\-Monitor Cyberinfrastructure \(OEMC\) project and under agreement No\. 101058386 for the interdisciplinary Digital Twin Engine for Science \(interTwin\) project\. Author JH is supported under agreement No\. 101131841 for the Embed2Scale project\. Additional funding was provided by the Swiss State Secretariat for Education, Research and Innovation and by UK Research and Innovation\.

Authors’ contributions:Brian Pondi:Writing – Original Draft, Conceptualization, Software, Methodology, Visualization, Validation, Investigation\.Jonas Hurst:Writing – Original Draft, Formal Analysis, Software, Validation, Visualization, Investigation\.Rolf Simoes:Writing – Original Draft, Software, Validation, Visualization, Investigation\.Jonas Starke:Software, Visualization, Data Curation, Investigation\.Marius Appel:Writing – Review and Editing, Supervision\.Edzer Pebesma:Writing – Review and Editing, Supervision, Resources, Project Administration\.

Data Availability:The BreizhCrops benchmark dataset is openly available from[Rußwurm et al\. \(2020\)](https://arxiv.org/html/2609.13453#bib.bib27)at[https://breizhcrops\.org/](https://breizhcrops.org/)\. The Rondônia deforestation dataset is provided by Brazil’s National Institute for Space Research \(Instituto Nacional de Pesquisas Espaciais\) at[https://github\.com/e\-sensing/sitsdata](https://github.com/e-sensing/sitsdata)\.

Funding:This work was supported by the European Commission under Horizon Europe agreement No\. 101059548 \(Open\-Earth\-Monitor Cyberinfrastructure\), No\. 101058386 \(interdisciplinary Digital Twin Engine for Science\), and No\. 101131841 \(Embed2Scale\), as well as by the Swiss State Secretariat for Education, Research and Innovation, and by UK Research and Innovation\.

Competing Interests:The authors declare no competing interests\.

### 10ML Process Graph

This appendix provides a concrete example of anopenEOJSON process graph generated from the ML workflow described in Section[6\.1](https://arxiv.org/html/2609.13453#S6.SS1)\. The graph captures all data cube preprocessing, TempCNN hyperparameter fine\-tuning, model export, and inference steps required to execute the workflow on a backend \(Fig\.[10](https://arxiv.org/html/2609.13453#S10.F10)\)\. By expressing these steps declaratively, the process graph makes the sequence of operations, data dependencies, and model interactions explicit and reproducible\.

1\{

2␣"process\_graph":␣\{

3␣␣"loadcollection1":␣\{

4␣␣␣"process\_id":␣"load\_collection",

5␣␣␣"arguments":␣\{

6␣␣␣␣"id":␣"mpc\-sentinel\-2\-l2a",

7␣␣␣␣"spatial\_extent":␣\{"west":\-63\.50,"south":\-8\.92,"east":\-63\.35,"north":\-8\.78\},

8␣␣␣␣"temporal\_extent":␣\["2022\-01\-01","2022\-12\-31"\],

9␣␣␣␣"bands":␣\["B02","B03","B04","B05","B06","B07","B08","B11","B12","B8A"\]

10␣␣␣\}

11␣␣\},

12␣␣"cuberegularize1":␣\{

13␣␣␣"process\_id":␣"cube\_regularize",

14␣␣␣"arguments":␣\{"data":\{"from\_node":"loadcollection1"\},"period":"P16D","resolution":30\}

15␣␣\},

16␣␣"ndvi1":␣\{

17␣␣␣"process\_id":␣"ndvi",

18␣␣␣"arguments":␣\{"data":\{"from\_node":"cuberegularize1"\},"red":"B04","nir":"B08","target\_band":"NDVI"\}

19␣␣\},

20␣␣"mlmclasstempcnn1":␣\{

21␣␣␣"process\_id":␣"mlm\_class\_tempcnn",

22␣␣␣"arguments":␣\{"optimizer":"adam","learning\_rate":0\.0005,"epochs":20,"batch\_size":64\}

23␣␣\},

24␣␣"mltunegrid1":␣\{

25␣␣␣"process\_id":␣"ml\_tune\_grid",

26␣␣␣"arguments":␣\{

27␣␣␣␣"model":\{"from\_node":"mlmclasstempcnn1"\},

28␣␣␣␣"training\_data":"\{<deforestation\_data\>\}",

29␣␣␣␣"target":"label",

30␣␣␣␣"parameters":\{"learning\_rate":\[0\.0005,0\.0001\],"epochs":\[20,40\]\},

31␣␣␣␣"scoring":"accuracy","cv":0,"seed":42

32␣␣␣\}

33␣␣\},

34␣␣"savemlmodel1":␣\{

35␣␣␣"process\_id":␣"save\_ml\_model",

36␣␣␣"arguments":␣\{"data":\{"from\_node":"mltunegrid1"\},"name":"tempcnn\_rondonia\_tuned\_v1","return\_model":true\}

37␣␣\},

38␣␣"mlpredict1":␣\{

39␣␣␣"process\_id":␣"ml\_predict",

40␣␣␣"arguments":␣\{"data":\{"from\_node":"ndvi1"\},"model":\{"from\_node":"savemlmodel1"\}\}

41␣␣\},

42␣␣"saveresult1":␣\{

43␣␣␣"process\_id":␣"save\_result",

44␣␣␣"arguments":␣\{"data":\{"from\_node":"mlpredict1"\},"format":"GTiff"\},

45␣␣␣"result":␣true

46␣␣\}

47␣\}

48\}

Figure 10:openEO JSON process graph for the TempCNN fine\-tuning and land cover mapping workflow\. Each node inprocess\_graphcorresponds to oneopenEOprocess, withfrom\_nodereferences expressing the data flow between operations\.Each node in the graph corresponds to a singleopenEOprocess, and data flow between nodes is expressed throughfrom\_nodereferences rather than intermediate variables, making dependencies explicit\. Theload\_collection,cube\_regularize, andndvinodes define the preprocessing applied to the Sentinel\-2 data cube before inference\. Themlm\_class\_tempcnnnode declares the base TempCNN architecture and hyperparameters;ml\_tune\_gridevaluates a parameter grid on the labelled training samples, selects the best configuration, and refits the model on the full training set \(writingtuning\_results\.jsonin the job workspace\)\. Thesave\_ml\_modelnode persists the tuned model whilereturn\_model: truekeeps it available as an input to downstream processes\.ml\_predictapplies the tuned model to the preprocessed cube, andsave\_resultexports the classification as a GeoTIFF\. Theresult: trueflag on the final node signals to the backend which output to return when the job completes\.

### 11Example ML Process Schema

This appendix shows an example JSON process specification forml\_predict\(Fig\.[11](https://arxiv.org/html/2609.13453#S11.F11)\), illustrating how ML processes are formally defined within theopenEOprocess catalog\. Process specifications define the expected inputs, outputs, and data types, providing a shared contract that all backend implementations must satisfy\.

1\{

2␣␣"id":␣"ml\_predict",

3␣␣"summary":␣"ApplyatrainedMLmodeltoadatacube",

4␣␣"description":␣"Appliesamachinelearningmodeltoadatacubeof

5inputfeaturesandreturnsthepredictedvalues\.",

6␣␣"categories":␣\["machinelearning"\],

7␣␣"experimental":␣true,

8␣␣"parameters":␣\[

9␣␣␣␣\{

10␣␣␣␣␣␣"name":␣"data",

11␣␣␣␣␣␣"description":␣"Thedatacubecontainingtheinputfeatures\.",

12␣␣␣␣␣␣"schema":␣\{

13␣␣␣␣␣␣␣␣"type":␣"object",

14␣␣␣␣␣␣␣␣"subtype":␣"datacube"

15␣␣␣␣␣␣\}

16␣␣␣␣\},

17␣␣␣␣\{

18␣␣␣␣␣␣"name":␣"model",

19␣␣␣␣␣␣"description":␣"AtrainedMLmodel,asreturnedbyml\_fitor

20loadedviaload\_ml\_modelorload\_stac\_ml\.",

21␣␣␣␣␣␣"schema":␣\{

22␣␣␣␣␣␣␣␣"type":␣"object",

23␣␣␣␣␣␣␣␣"subtype":␣"ml\-model"

24␣␣␣␣␣␣\}

25␣␣␣␣\}

26␣␣\],

27␣␣"returns":␣\{

28␣␣␣␣"description":␣"Adatacubewiththepredictedvalues\.Theinput

29featuredimensionsareremovedandanewdimensionnamed

30’predictions’oftype’other’isadded\.Ifasinglevalueis

31returnedperlocation,thisdimensioncarriesasinglelabel’0’\.",

32␣␣␣␣"schema":␣\{

33␣␣␣␣␣␣"type":␣"object",

34␣␣␣␣␣␣"subtype":␣"datacube",

35␣␣␣␣␣␣"dimensions":␣\[\{"type":␣"other"\}\]

36␣␣␣␣\}

37␣␣\}

38\}

Figure 11:JSON process specification forml\_predict, defining the expected input types, output structure, and data cube transformation behavior\. Theexperimentalflag indicates that the process definition is subject to revision as the specification matures\.The specification follows the same structural pattern as all otheropenEOprocess definitions, ensuring thatml\_predictis treated as a first\-class citizen in the process catalog rather than a special\-case extension\. Both parameters are typed asopenEOobjects:datamust be a data cube, andmodelmust be anml\-modelobject produced byml\_fit,load\_ml\_model, orload\_stac\_ml\. The return type is also a data cube, which means the output ofml\_predictcan be passed directly to any subsequentopenEOprocess, such asml\_uncertainty\_class,ml\_label\_class, orsave\_result, without requiring format conversion\. Theexperimentalflag signals that the definition may be refined through community feedback before it is promoted to a stable process\.

### 12openEO Workflow for Foundation Model Embeddings

This appendix provides theopenEOprocess graph corresponding to the embedding pipeline described in Section[6\.2](https://arxiv.org/html/2609.13453#S6.SS2)\(Fig\.[12](https://arxiv.org/html/2609.13453#S12.F12)\)\. The workflow loads Sentinel\-2 data as a data cube, retrieves the pre\-trained TerraMind foundation model described as a STAC MLM Item, and applies the model to compute embeddings\. The output is a high\-dimensional data cube intended for downstream processing rather than immediate export\.

1\{

2␣"process\_graph":␣\{

3␣␣"load\_data":␣\{

4␣␣␣"process\_id":␣"load\_stac",

5␣␣␣"arguments":␣\{

6␣␣␣␣"url":␣"https://earth\-search\.aws\.element84\.com/v1/collections/sentinel\-2\-l2a",

7␣␣␣␣"spatial\_extent":␣\{"west":␣8\.2,␣"east":␣8\.5,␣"south":␣48\.9,␣"north":␣49\.1\},

8␣␣␣␣"temporal\_extent":␣\["2024\-08\-05",␣"2024\-08\-12"\],

9␣␣␣␣"bands":␣\[

10␣␣␣␣␣"coastal",␣"blue",␣"green",␣"red",

11␣␣␣␣␣"rededge1",␣"rededge2",␣"rededge3",

12␣␣␣␣␣"nir",␣"nir08",␣"nir09",␣"swir16",␣"swir22"

13␣␣␣␣\],

14␣␣␣␣"resolution":␣10

15␣␣␣\}

16␣␣\},

17␣␣"load\_model":␣\{

18␣␣␣"process\_id":␣"load\_stac\_ml",

19␣␣␣"arguments":␣\{

20␣␣␣␣"uri":␣"<url\-to\-stac\-mlm\-item\>",

21␣␣␣␣"model\_asset":␣"weights"

22␣␣␣\}

23␣␣\},

24␣␣"predict":␣\{

25␣␣␣"process\_id":␣"ml\_predict",

26␣␣␣"arguments":␣\{

27␣␣␣␣"data":␣\{"from\_node":␣"load\_data"\},

28␣␣␣␣"model":␣\{"from\_node":␣"load\_model"\}

29␣␣␣\},

30␣␣␣"result":␣true

31␣␣\}

32␣\}

33\}

Figure 12:openEO process graph for computing EO embeddings from Sentinel\-2 data using the TerraMind foundation model\. The workflow loads an EO data cube, retrieves a pre\-trained model viaload\_stac\_ml, and applies inference viaml\_predict\. The resulting embedding cube is an intermediate output intended for further downstream processing\.In contrast to the supervised ML pipelines in Sections[5](https://arxiv.org/html/2609.13453#S5)and[6\.1](https://arxiv.org/html/2609.13453#S6.SS1), this workflow contains noml\_fitstep, as the foundation model is pre\-trained and used exclusively for inference\. The three steps are therefore: \(i\) EO data loading viaload\_stac, \(ii\) model retrieval viaload\_stac\_ml, and \(iii\) embedding generation viaml\_predict\. The resulting embedding cube can subsequently be passed to furtheropenEOprocesses within the same declarative workflow, for example for dimensionality reduction, clustering, or fine\-tuning on a downstream classification task\.

## References

- A\. A\. Adegun, S\. Viriri, and J\. TapamoReview of deep learning methods for remote sensing satellite images classification: experimental survey and comparative analysis\.Journal of Big Data10\(1\),pp\. 93\.External Links:[Document](https://dx.doi.org/10.1186/s40537-023-00824-8)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p1.1)\.
- Appel and Pebesma \(2019\)M\. Appel and E\. PebesmaOn\-demand processing of data cubes from satellite image collections with the gdalcubes library\.Data4\(3\),pp\. 92\.External Links:[Document](https://dx.doi.org/10.3390/data4030092)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p1.1),[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p1.1),[§4\.1](https://arxiv.org/html/2609.13453#S4.SS1.p1.1)\.
- Baumannet al\.\(2018\)P\. Baumann, D\. Misev, V\. Merticariu, and B\. Pham HuuDatacubes: towards space/time analysis\-ready data\.InService\-Oriented Mapping: Changing Paradigm in Map Production and Geoinformation Management,J\. Döllner, M\. Jobst, and P\. Schmitz \(Eds\.\),pp\. 269–299\.External Links:[Document](https://dx.doi.org/10.1007/978-3-319-72434-8%5F14)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p1.1)\.
- Belgiu and Drăguţ \(2016\)M\. Belgiu and L\. DrăguţRandom forest in remote sensing: a review of applications and future directions\.ISPRS Journal of Photogrammetry and Remote Sensing114,pp\. 24–31\.External Links:[Document](https://dx.doi.org/10.1016/j.isprsjprs.2016.01.011)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p4.1),[§5\.2](https://arxiv.org/html/2609.13453#S5.SS2.p5.1),[§7\.1\.2](https://arxiv.org/html/2609.13453#S7.SS1.SSS2.p3.1)\.
- Bergstra and Bengio \(2012\)J\. Bergstra and Y\. BengioRandom search for hyper\-parameter optimization\.Journal of Machine Learning Research13,pp\. 281–305\.External Links:[Document](https://dx.doi.org/10.5555/2188385.2188395),[Link](https://jmlr.org/papers/v13/bergstra12a.html)Cited by:[§3\.1](https://arxiv.org/html/2609.13453#S3.SS1.p3.1)\.
- Bodnaret al\.\(2024\)C\. Bodnar, W\. P\. Bruinsma, A\. Lucic, M\. Stanley, A\. Vaughan, J\. Brandstetter, P\. Garvan, M\. Riechert, J\. A\. Weyn, H\. Dong, J\. K\. Gupta, K\. Thambiratnam, A\. T\. Archibald, C\. Wu, E\. Heider, M\. Welling, R\. E\. Turner, and P\. PerdikarisA foundation model for the earth system\.External Links:2405\.13063,[Link](https://arxiv.org/abs/2405.13063)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.
- Breiman \(2001\)L\. BreimanRandom forests\.Machine Learning45\(1\),pp\. 5–32\.External Links:[Document](https://dx.doi.org/10.1023/A%3A1010933404324)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p2.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p1.1)\.
- Charette\-Migneaultet al\.\(2024\)F\. Charette\-Migneault, R\. Avery, B\. Pondi, J\. Omojola, S\. Vaccari, P\. Membari, D\. Peressutti, J\. Yu, and J\. SundwallMachine learning model specification for cataloging spatio\-temporal models\.InProceedings of the 3rd ACM SIGSPATIAL International Workshop on Searching and Mining Large Collections of Geospatial Data,GeoSearch ’24,New York, NY, USA,pp\. 36–39\.External Links:[Document](https://dx.doi.org/10.1145/3681769.3698586)Cited by:[§2\.3](https://arxiv.org/html/2609.13453#S2.SS3.p3.1),[§3\.3](https://arxiv.org/html/2609.13453#S3.SS3.p2.1),[§6\.2](https://arxiv.org/html/2609.13453#S6.SS2.p3.1),[§8](https://arxiv.org/html/2609.13453#S8.p2.1)\.
- Chenet al\.\(2020\)A\. Chen, A\. Chow, A\. Davidson, A\. DCunha, A\. Ghodsi, S\. A\. Hong, A\. Konwinski, C\. Mewald, S\. Murching, T\. Nykodym, P\. Ogilvie, M\. Parkhe, A\. Singh, F\. Xie, M\. Zaharia, R\. Zang, J\. Zheng, and C\. ZumarDevelopments in mlflow: a system to accelerate the machine learning lifecycle\.InProceedings of the Fourth International Workshop on Data Management for End\-to\-End Machine Learning,DEEM ’20,New York, NY, USA\.External Links:ISBN 9781450380232,[Document](https://dx.doi.org/10.1145/3399579.3399867)Cited by:[§2\.3](https://arxiv.org/html/2609.13453#S2.SS3.p1.1)\.
- Cortes and Vapnik \(1995\)C\. Cortes and V\. VapnikSupport\-vector networks\.Machine Learning20\(3\),pp\. 273–297\.External Links:[Document](https://dx.doi.org/10.1007/BF00994018)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p2.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p1.1)\.
- Fenget al\.\(2026\)Z\. Feng, C\. Atzberger, S\. Jaffer, J\. Knezevic, S\. Sormunen, R\. Young, M\. C\. Lisaius, M\. Immitzer, T\. Jackson, J\. Ball, D\. A\. Coomes, A\. Madhavapeddy, A\. Blake, and S\. KeshavTESSERA: temporal embeddings of surface spectra for earth representation and analysis\.External Links:[Document](https://dx.doi.org/10.48550/arXiv.2506.20380)Cited by:[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p1.1),[§8](https://arxiv.org/html/2609.13453#S8.p4.1)\.
- Foody \(2004\)G\. M\. FoodyThematic map comparison: evaluating the statistical significance of differences in classification accuracy\.Photogrammetric Engineering & Remote Sensing70\(5\),pp\. 627–633\.External Links:[Document](https://dx.doi.org/10.14358/PERS.70.5.627)Cited by:[§5\.2](https://arxiv.org/html/2609.13453#S5.SS2.p2.1)\.
- Hauschildet al\.\(2022\)A\. Hauschild, M\. Lemanczyk, J\. Matschinske, T\. Frisch, O\. Zolotareva, A\. Holzinger, J\. Baumbach, and D\. HeiderFederated Random Forests can improve local performance of predictive models for various healthcare applications\.Bioinformatics38\(8\),pp\. 2278–2286\.External Links:[Document](https://dx.doi.org/10.1093/bioinformatics/btac065)Cited by:[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p2.1)\.
- Hoyer and Hamman \(2017\)S\. Hoyer and J\. Hammanxarray: N\-D labeled Arrays and Datasets in Python\.Journal of Open Research Software5\(1\)\.External Links:[Document](https://dx.doi.org/10.5334/jors.148)Cited by:[§4\.3](https://arxiv.org/html/2609.13453#S4.SS3.p1.1)\.
- Jacobet al\.\(2021\)A\. Jacob, M\. Mohr, P\. J\. Zellner, J\. Dries, M\. Claus, C\. Briese, P\. Griffiths, and E\. PebesmaopenEO platform brings analysis\-ready data on demand\.InProceedings of the 2021 Conference on Big Data from Space \(BiDS’21\),External Links:[Document](https://dx.doi.org/10.2760/125905)Cited by:[§4\.3](https://arxiv.org/html/2609.13453#S4.SS3.p4.1)\.
- Jakubiket al\.\(2023\)J\. Jakubik, S\. Roy, C\. E\. Phillips, P\. Fraccaro, D\. Godwin, B\. Zadrozny, D\. Szwarcman, C\. Gomes, G\. Nyirjesy, B\. Edwards, D\. Kimura, N\. Simumba, L\. Chu, S\. K\. Mukkavilli, D\. Lambhate, K\. Das, R\. Bangalore, D\. Oliveira, M\. Muszynski, K\. Ankur, M\. Ramasubramanian, I\. Gurung, S\. Khallaghi, H\. Li, M\. Cecil, M\. Ahmadi, F\. Kordi, H\. Alemohammad, M\. Maskey, R\. Ganti, K\. Weldemariam, and R\. RamachandranFoundation models for generalist geospatial artificial intelligence\.External Links:2310\.18660,[Link](https://arxiv.org/abs/2310.18660)Cited by:[§6\.2](https://arxiv.org/html/2609.13453#S6.SS2.p1.1),[§8](https://arxiv.org/html/2609.13453#S8.p4.1)\.
- Jakubiket al\.\(2025\)J\. Jakubik, F\. Yang, B\. Blumenstiel, E\. Scheurer, R\. Sedona, S\. Maurogiovanni, J\. Bosmans, N\. Dionelis, V\. Marsocci, N\. Kopp, R\. Ramachandran, P\. Fraccaro, T\. Brunschwiler, G\. Cavallaro, J\. Bernabe\-Moreno, and N\. LongépéTerraMind: large\-scale generative multimodality for earth observation\.External Links:2504\.11171,[Link](https://arxiv.org/abs/2504.11171)Cited by:[§6\.2](https://arxiv.org/html/2609.13453#S6.SS2.p3.1),[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p1.1),[§8](https://arxiv.org/html/2609.13453#S8.p2.1)\.
- Kansakar and Hossain \(2016\)P\. Kansakar and F\. HossainA review of applications of satellite earth observation data for global societal benefit and stewardship of planet earth\.Space Policy36,pp\. 46–54\.External Links:[Document](https://dx.doi.org/10.1016/j.spacepol.2016.05.005)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p1.1)\.
- Koppet al\.\(2019\)S\. Kopp, P\. Becker, A\. Doshi, D\. J\. Wright, K\. Zhang, and H\. XuAchieving the full vision of earth observation data cubes\.Data4\(3\),pp\. 94\.External Links:[Document](https://dx.doi.org/10.3390/data4030094)Cited by:[Figure 2](https://arxiv.org/html/2609.13453#S2.F2),[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p1.1)\.
- Kuhn \(2008\)M\. KuhnBuilding predictive models in R using the caret package\.Journal of Statistical Software28\(5\),pp\. 1–26\.External Links:[Document](https://dx.doi.org/10.18637/jss.v028.i05)Cited by:[§4\.1](https://arxiv.org/html/2609.13453#S4.SS1.p1.1)\.
- Landis and Koch \(1977\)J\. R\. Landis and G\. G\. KochThe measurement of observer agreement for categorical data\.Biometrics33\(1\),pp\. 159–174\.External Links:[Document](https://dx.doi.org/10.2307/2529310)Cited by:[§5\.2](https://arxiv.org/html/2609.13453#S5.SS2.p2.1)\.
- Liuet al\.\(2020\)Y\. Liu, Y\. Liu, Z\. Liu, Y\. Liang, C\. Meng, J\. Zhang, and Y\. ZhengFederated forest\.IEEE Transactions on Big Data8,pp\. 843–854\.External Links:[Document](https://dx.doi.org/10.1109/TBDATA.2020.2992755)Cited by:[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p2.1)\.
- Maxwellet al\.\(2018\)A\. E\. Maxwell, T\. A\. Warner, and F\. FangImplementation of machine\-learning classification in remote sensing: an applied review\.International Journal of Remote Sensing39\(9\),pp\. 2784–2817\.External Links:[Document](https://dx.doi.org/10.1080/01431161.2018.1433343)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p4.1),[§5\.2](https://arxiv.org/html/2609.13453#S5.SS2.p5.1),[§7\.1\.2](https://arxiv.org/html/2609.13453#S7.SS1.SSS2.p3.1)\.
- Mohret al\.\(2025\)M\. Mohr, E\. Pebesma, J\. Dries, S\. Lippens, B\. Janssen, D\. Thiex, G\. Milcinski, B\. Schumacher, C\. Briese, M\. Claus, A\. Jacob, P\. Sacramento, and P\. GriffithsFederated and reusable processing of earth observation data\.Scientific Data12\(1\),pp\. 194\.External Links:[Document](https://dx.doi.org/10.1038/s41597-025-04513-y)Cited by:[§4\.3](https://arxiv.org/html/2609.13453#S4.SS3.p4.1)\.
- Mohr \(2026a\)M\. MohropenEO API 1\.2\.OGC Community Standard,Open Geospatial Consortium\.Note:Approval Date: 2026\-03\-05\. Publication Date: 2026\-04\-15\.[http://www\.opengis\.net/doc/cs/openeo\-api/1\.2](http://www.opengis.net/doc/cs/openeo-api/1.2)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p4.1)\.
- Mohr \(2026b\)M\. MohropenEO Processes 1\.2\.OGC Community Practice,Open Geospatial Consortium\.Note:Approval Date: 2026\-03\-05\. Publication Date: 2026\-04\-15\.[http://www\.opengis\.net/doc/cp/openeo\-processes/1\.2](http://www.opengis.net/doc/cp/openeo-processes/1.2)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p4.1)\.
- Moreno\-Álvarezet al\.\(2024\)S\. Moreno\-Álvarez, M\. E\. Paoletti, A\. J\. Sanchez\-Fernandez, J\. A\. Rico\-Gallego, L\. Han, and J\. M\. HautFederated learning meets remote sensing\.Expert Systems with Applications255,pp\. 124583\.External Links:[Document](https://dx.doi.org/10.1016/j.eswa.2024.124583)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p6.1),[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p2.1),[§8](https://arxiv.org/html/2609.13453#S8.p4.1)\.
- ONNX Community \(2019\)ONNX CommunityONNX: open neural network exchange\.Note:[https://onnx\.ai](https://onnx.ai/)Accessed: June 2026Cited by:[§2\.3](https://arxiv.org/html/2609.13453#S2.SS3.p2.1),[§3\.2](https://arxiv.org/html/2609.13453#S3.SS2.p2.1)\.
- Pedregosaet al\.\(2011\)F\. Pedregosa, G\. Varoquaux, A\. Gramfort, V\. Michel, B\. Thirion, O\. Grisel, M\. Blondel, P\. Prettenhofer, R\. Weiss, V\. Dubourg, J\. Vanderplas, A\. Passos, D\. Cournapeau, M\. Brucher, M\. Perrot, and É\. DuchesnayScikit\-learn: machine learning in Python\.Journal of Machine Learning Research12,pp\. 2825–2830\.External Links:[Document](https://dx.doi.org/10.5555/1953048.2078195)Cited by:[§2\.3](https://arxiv.org/html/2609.13453#S2.SS3.p1.1)\.
- Pelletieret al\.\(2019\)C\. Pelletier, G\. I\. Webb, and F\. PetitjeanTemporal convolutional neural network for the classification of satellite image time series\.Remote Sensing11\(5\),pp\. 523\.External Links:[Document](https://dx.doi.org/10.3390/rs11050523)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p2.1),[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p4.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p5.1),[§6\.1](https://arxiv.org/html/2609.13453#S6.SS1.p1.1)\.
- Pondiet al\.\(2024\)B\. Pondi, M\. Appel, and E\. PebesmaOpenEOcubes: an open\-source and lightweight R\-based RESTful web service for analyzing earth observation data cubes\.Earth Science Informatics17\(2\),pp\. 1809–1818\.External Links:[Document](https://dx.doi.org/10.1007/s12145-024-01249-y)Cited by:[§4\.1](https://arxiv.org/html/2609.13453#S4.SS1.p1.1)\.
- Qiaoet al\.\(2021\)M\. Qiao, X\. He, X\. Cheng, P\. Li, H\. Luo, L\. Zhang, and Z\. TianCrop yield prediction from multi\-spectral, multi\-temporal remotely sensed imagery using recurrent 3d convolutional neural networks\.International Journal of Applied Earth Observation and Geoinformation102,pp\. 102436\.External Links:[Document](https://dx.doi.org/10.1016/j.jag.2021.102436)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p2.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.
- Rolfet al\.\(2024\)E\. Rolf, K\. Klemmer, C\. Robinson, and H\. KernerPosition: mission critical — satellite data is a distinct modality in machine learning\.InProceedings of the Forty\-first International Conference on Machine Learning,ICML ’24\.External Links:[Link](https://proceedings.mlr.press/v235/rolf24a.html)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p3.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p1.1)\.
- Rolihet al\.\(2025\)B\. Rolih, M\. Fucka, F\. Wolf, and L\. C\. ZajcBe the change you want to see: revisiting remote sensing change detection practices\.IEEE Transactions on Geoscience and Remote Sensing63,pp\. 1–11\.External Links:[Document](https://dx.doi.org/10.1109/tgrs.2025.3585342)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.
- Rußwurm and Körner \(2018\)M\. Rußwurm and M\. KörnerConvolutional lstms for cloud\-robust segmentation of remote sensing imagery\.External Links:1811\.02471,[Link](https://arxiv.org/abs/1811.02471)Cited by:[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p4.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.
- Rußwurmet al\.\(2020\)M\. Rußwurm, C\. Pelletier, M\. Zollner, S\. Lefèvre, and M\. KörnerBreizhCrops: a time series dataset for crop type mapping\.External Links:1905\.11893,[Link](https://arxiv.org/abs/1905.11893)Cited by:[§5\.1](https://arxiv.org/html/2609.13453#S5.SS1.p3.1),[§9](https://arxiv.org/html/2609.13453#S9.SS0.SSSx1.p3.1)\.
- Sainte Fare Garnot and Landrieu \(2020\)V\. Sainte Fare Garnot and L\. LandrieuLightweight temporal self\-attention for classifying satellite image time series\.External Links:2007\.00586,[Link](https://arxiv.org/abs/2007.00586)Cited by:[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p4.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p5.1)\.
- Schrammet al\.\(2021\)M\. Schramm, E\. Pebesma, M\. Milenković, L\. Foresta, J\. Dries, A\. Jacob, W\. Wagner, M\. Mohr, M\. Neteler, M\. Kadunc, T\. Miksa, P\. Kempeneers, J\. Verbesselt, B\. Gößwein, C\. Navacchi, S\. Lippens, and J\. ReicheThe openEO API — harmonising the use of earth observation cloud services using virtual data cube functionalities\.Remote Sensing13\(6\),pp\. 1125\.External Links:[Document](https://dx.doi.org/10.3390/rs13061125)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p3.1),[§1](https://arxiv.org/html/2609.13453#S1.p4.1)\.
- Shiet al\.\(2015\)X\. Shi, Z\. Chen, H\. Wang, D\. Yeung, W\. Wong, and W\. WooConvolutional LSTM network: a machine learning approach for precipitation nowcasting\.External Links:1506\.04214,[Link](https://arxiv.org/abs/1506.04214)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.
- Simoeset al\.\(2021\)R\. Simoes, G\. Camara, G\. Queiroz, F\. Souza, P\. R\. Andrade, L\. Santos, A\. Carvalho, and K\. FerreiraSatellite image time series analysis for big earth observation data\.Remote Sensing13\(13\),pp\. 2428\.External Links:[Document](https://dx.doi.org/10.3390/rs13132428)Cited by:[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p5.1),[§3\.2](https://arxiv.org/html/2609.13453#S3.SS2.p3.1),[§3](https://arxiv.org/html/2609.13453#S3.p5.1),[§4\.2](https://arxiv.org/html/2609.13453#S4.SS2.p2.1),[§6\.1](https://arxiv.org/html/2609.13453#S6.SS1.p1.1)\.
- Szwarcmanet al\.\(2025\)D\. Szwarcman, S\. Roy, P\. Fraccaro, T\. E\. Gislason, B\. Blumenstiel, R\. Ghosal, P\. H\. de Oliveira, J\. L\. d\. S\. Almeida, R\. Sedona, Y\. Kang, S\. Chakraborty, S\. Wang, C\. Gomes, A\. Kumar, M\. Truong, D\. Godwin, H\. Lee, C\. Hsu, A\. Akbari Asanjan, B\. Mujeci, D\. Shidham, T\. Keenan, P\. Arevalo, W\. Li, H\. Alemohammad, P\. Olofsson, C\. Hain, R\. Kennedy, B\. Zadrozny, D\. Bell, G\. Cavallaro, C\. Watson, M\. Maskey, R\. Ramachandran, and J\. Bernabe MorenoPrithvi\-EO\-2\.0: a versatile multi\-temporal foundation model for earth observation applications\.External Links:2412\.02732,[Link](https://arxiv.org/abs/2412.02732)Cited by:[§7\.1\.4](https://arxiv.org/html/2609.13453#S7.SS1.SSS4.p1.1),[§8](https://arxiv.org/html/2609.13453#S8.p4.1)\.
- Wolfet al\.\(2020\)T\. Wolf, L\. Debut, V\. Sanh, J\. Chaumond, C\. Delangue, A\. Moi, P\. Cistac, T\. Rault, R\. Louf, M\. Funtowicz, J\. Davison, S\. Shleifer, P\. von Platen, C\. Ma, Y\. Jernite, J\. Plu, C\. Xu, T\. L\. Scao, S\. Gugger, M\. Drame, Q\. Lhoest, and A\. M\. RushTransformers: state\-of\-the\-art natural language processing\.InProceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations,Online,pp\. 38–45\.External Links:[Document](https://dx.doi.org/10.18653/v1/2020.emnlp-demos.6)Cited by:[§2\.3](https://arxiv.org/html/2609.13453#S2.SS3.p1.1)\.
- Wulderet al\.\(2012\)M\. A\. Wulder, J\. G\. Masek, W\. B\. Cohen, T\. R\. Loveland, and C\. E\. WoodcockOpening the archive: how free data has enabled the science and monitoring promise of landsat\.Remote Sensing of Environment122,pp\. 2–10\.External Links:[Document](https://dx.doi.org/10.1016/j.rse.2012.01.010)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p1.1)\.
- Xiaoet al\.\(2024\)A\. Xiao, W\. Xuan, J\. Wang, J\. Huang, D\. Tao, S\. Lu, and N\. YokoyaFoundation models for remote sensing and earth observation: a survey\.External Links:2410\.16602,[Link](https://arxiv.org/abs/2410.16602)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p6.1)\.
- Xieet al\.\(2020\)B\. Xie, J\. Xu, J\. Jung, S\. Yun, E\. Zeng, E\. M\. Brooks, M\. Dolk, and L\. NarasimhaluMachine learning on satellite radar images to estimate damages after natural disasters\.InProceedings of the 28th International Conference on Advances in Geographic Information Systems,SIGSPATIAL ’20,New York, NY, USA,pp\. 461–464\.External Links:[Document](https://dx.doi.org/10.1145/3397536.3422349)Cited by:[§1](https://arxiv.org/html/2609.13453#S1.p2.1)\.
- Zhuet al\.\(2017\)X\. X\. Zhu, D\. Tuia, L\. Mou, G\.\-S\. Xia, L\. Zhang, F\. Xu, and F\. FraundorferDeep learning in remote sensing: a comprehensive review and list of resources\.IEEE Geoscience and Remote Sensing Magazine5\(4\),pp\. 8–36\.External Links:[Document](https://dx.doi.org/10.1109/MGRS.2017.2762307)Cited by:[§2\.1](https://arxiv.org/html/2609.13453#S2.SS1.p4.1),[§2\.2](https://arxiv.org/html/2609.13453#S2.SS2.p6.1)\.