openEO Python Client

The spectral index specifications used in this project are derived from the Awesome Spectral Indices project by David Montero Loaiza.

Specifically:

• The awesome-spectral-indices/ directory contains specifications based on a versioned release of the original project.
• The extra-indixes-dict.json file contains additional spectral indices that are not yet included in the primary Awesome Spectral Indices dataset.

Since version 0.13.0, the way UDFs are handled has been simplified.

Key Changes:

• Auto-detection: openeo.UDF now automatically detects the runtime from the source code or file extension. You no longer need to pass runtime="Python" explicitly.
• Simplified Arguments: The data argument is deprecated and unused; you should no longer provide it.
• Uniformity: Use the process argument for all operations (apply, reduce_dimension, apply_dimension) instead of specialized arguments like code or runtime.

Recommended Pattern:

# Create the UDF object
udf = openeo.UDF(udf_code)

# Use the 'process' argument in DataCube methods
cube.apply(process=udf)
cube.reduce_dimension(reducer=udf, dimension="t")
cube.apply_dimension(process=udf, dimension="t")

The artifacts functionality automates the process of uploading files to provider-managed storage (such as S3-compatible object storage) so they can be used during job execution.

1. Factory Pattern: build_artifact_helper inspects your connection object to see if the openEO backend advertises a preferred configuration type and returns the appropriate helper.
2. Storage & Access:
   • upload_file retrieves temporary credentials (e.g., S3 credentials) based on the backend's advertised config and your current session, then uploads the file and returns a URI that the backend can resolve.
   • get_presigned_url creates a standalone URI signed with those temporary credentials. This is useful for tools or execution steps that cannot handle internal backend references.

For large data cubes or complex algorithms that might exceed computation time limits, use Batch Jobs instead of synchronous downloads.

Batch jobs allow for asynchronous execution: you can start a job, disconnect from the back-end, and reconnect later to check the status or download the results. The library provides helpers to monitor running jobs and view progress reports.

openEO provides specific processes for Random Forest-based machine learning workflows for Earth Observation applications:

• fit_class_random_forest: Trains a random forest classification model.
• fit_regr_random_forest: Trains a random forest regression model.
• predict_random_forest: Performs inference/prediction using a trained model.

The openEO Python Client facilitates setting up and executing these training and inference workflows as batch jobs.

Warning: This API and documentation are experimental and subject to change.

The openEO Python client offers two distinct ways to interact with back-ends:

1. High-level Interface: Uses the openeo module (e.g., openeo.connect). It is designed to be concise and readable, abstracting away the underlying web service details.
2. Low-level Interface: Uses the openeo.rest modules. This provides more granular control over the API calls, resource management, and specific RESTful interactions with the server.

Some openEO processes act as 'parent' processes that require a sub-process (a callback) to be applied to a subset or slice of the data. The parent process manages the execution and invocation of the callback.

Common parent processes include:

• apply: Requires a transformation applied to each pixel separately (e.g., scaling a value).
• reduce_dimension: Requires an aggregation function to convert an array of values (along a dimension) into a single value (e.g., temporal mean).
• aggregate_spatial: Requires a function to aggregate values within specific geometries.

Supported DataCube methods that accept callbacks include:

• aggregate_spatial
• aggregate_temporal
• apply
• apply_dimension
• apply_neighborhood
• reduce_dimension