Worldcereal crop extent UDP

[VincentVerelst]

UDP to generate WorldCereal crop extent.

Note: Currently it's not possible to parametrize the S1 orbit state; see Open-EO/openeo-python-driver#327

Usage example:

import openeo

spatial_extent = {'west': 622694.5968575787,
 'south': 5672232.857114074,
 'east': 623079.000934101,
 'north': 5672519.995940826,
 'crs': 'EPSG:32631',
 'srs': 'EPSG:32631'}

temporal_extent = ['2018-05-01', '2019-04-30']

c = openeo.connect('openeofed.dataspace.copernicus.eu').authenticate_oidc()

classes = c.datacube_from_process(
    process_id='worldcereal_crop_extent',
    namespace="https://raw.githubusercontent.com/ESA-APEx/apex_algorithms/refs/heads/worldcereal_crop_extent_udp/openeo_udp/worldcereal_crop_extent.json",  # To change to main branch after PR merge
    temporal_extent=temporal_extent,
    spatial_extent=spatial_extent,
)

ONNX_DEPS_URL = "https://artifactory.vgt.vito.be/artifactory/auxdata-public/openeo/onnx_dependencies_1.16.3.zip"

JOB_OPTIONS = {
        "driver-memory": "4g",
        "executor-memory": "2g",
        "executor-memoryOverhead": "1g",
        "python-memory": "3g",
        "soft-errors": "true",
        "udf-dependency-archives": [f"{ONNX_DEPS_URL}#onnx_deps"],
    }

job = classes.execute_batch(
    title="WorldCereal Crop Extent",
    out_format="GTiff",
    job_options=JOB_OPTIONS,
)

[VincentVerelst]

Unit test is failing, because UDP namespace refers to a main branch URL (which will only exist after PR merge)

EDIT: changed namespace URL again to feature branch to pass unit tests

[jdegerickx]

can we also support postprocess parameters as an additional argument in the UDP?
Demonstrated for instance here

[VincentVerelst]

can we also support postprocess parameters as an additional argument in the UDP? Demonstrated for instance here

I think not, as they are all client side if..else.. statements. Changing a postprocess parameter will just change your entire process graph.

[jdegerickx]

I think not, as they are all client side if..else.. statements. Changing a postprocess parameter will just change your entire process graph.

So in practice this means we need a whole batch of UDP's for each possible combination of postprocess parameters?

[VincentVerelst]

I think not, as they are all client side if..else.. statements. Changing a postprocess parameter will just change your entire process graph.

So in practice this means we need a whole batch of UDP's for each possible combination of postprocess parameters?

I believe so; the backend would need to support something like conditional nodes in a process graph, but that seems like a very complicated feature.
@jdries, maybe you have some suggestions on how we can tackle the postprocessing parameters?

[jdries]

I think you can in fact use the openEO 'if' process at top level, to indeed switch your process graph based on a UDP parameter. Of course, we have to be careful and keep it sensible. For some cases, it is indeed really better to simply construct a library of different UDP's, with a clear set of parameters each, avoiding that one parameter depends on the value of other parameters.

[jdries]

@VincentVerelst given that we have someone waiting for this, would it be safe to already merge this version, and then perhaps continue? (So does this graph work when we run it?)

[VincentVerelst]

@VincentVerelst given that we have someone waiting for this, would it be safe to already merge this version, and then perhaps continue? (So does this graph work when we run it?)

@jdries , yes the process graph in its current version is working.

• Currently it will use the default postprocessing parameters, as they're not customizable
• It will also always select the DESCENDING orbit state for S1, as that is also not customizable yet (see Support parametrization of properties in UDP Open-EO/openeo-python-driver#327). Later this may become a problem, as in the training for v2, the orbit state is selected, based on most data available. For v1, however, I'm not sure how much of a problem that is