Updates for openeo API v1.2 and openeo-processes v2.0.0

[soxofaan]

Upcoming API/spec updates:

• Release v1.2.0 openeo-api#492
• Release v2.0.0-rc.1 openeo-processes#439

This is central/epic ticket to follow up necessary coverage of these changes in the python client

[soxofaan]

related to Open-EO/openeo-python-client#424 in python client

[soxofaan]

refs/sub-issues

• support text_concat instead of text_merge #196

[soxofaan]

Something to consider from openeo-processes 2.0 :

Updated the processes based on the subtypes raster-cube or vector-cube to work with the subtype datacube instead. Open-EO/openeo-processes#68

Inconsistent usage of datacube vs raster-cube schema's triggers warnings in web editor, e.g. see Open-EO/openeo-aggregator#118

FYI, at the moment, openeo.vito.be/openeo/1.1/processes uses raster-cube (and vector-cube) for most processes, except these that use datacube: ['load_geojson', 'load_url', 'load_stac'], as these load the 2.x style spec (introduced by 982591b), like

openeo-python-driver/openeo_driver/ProcessGraphDeserializer.py

Lines 1584 to 1585 in 301e344

	@process_registry_100.add_function(spec=read_spec("openeo-processes/2.x/proposals/load_geojson.json"))
	def load_geojson(args: ProcessArgs, env: EvalEnv) -> DriverVectorCube:

[soxofaan]

working on in a feature branch to provide the 2.0 version of processes at a https://openeo.vito.be/openeo/1.2/ while keeping the 1.x version on https://openeo.vito.be/openeo/1.1 and lower

I think it would be good if we could also make that link more explicit in the metadata -> Open-EO/openeo-api#517

[soxofaan]

merged current work in ec902ac:

/openeo/1.2 (still flagged as not production ready for now) will expose v2 of processes
while standard /openeo/1.0 and /openeo/1.1 endpoints stick to existing v1.x processes

[soxofaan]

still to do under this ticket:

• add support for new v2 processes
• support new openeo-api v1.2 features

[jdries]

@soxofaan our 1.2 version of the api is still marked as not production ready. Are there actually things in the implementation that make it less stable than 1.1? Or do we lack things that are required in 1.2?

[soxofaan]

I don't think it's less stable, code-path-wise it's largely the same as 1.1

It's just not fully 1.2 compatible. We just added 1.2 feature in ad-hoc style to support use cases, we didn't do a full sweep yet to check against the full 1.2 requirements list

[jdries]

Looking at the changelog, I would say we can simply mark it as production ready. To me it seems to be the best version we have to offer, with some very relevant 1.2 specific features such as log level.

…

________________________________ From: Stefaan Lippens ***@***.***> Sent: Tuesday, November 7, 2023 9:56 AM To: Open-EO/openeo-python-driver ***@***.***> Cc: Jeroen Dries ***@***.***>; Comment ***@***.***> Subject: Re: [Open-EO/openeo-python-driver] Updates for openeo API v1.2 and openeo-processes v2.0.0 (Issue #195) I don't think it's less stable, code-path-wise it's largely the same as 1.1 It's just not fully 1.2 compatible. We just added 1.2 feature in ad-hoc style to support use cases, we didn't do a full sweep yet to check against the full 1.2 requirements list — Reply to this email directly, view it on GitHub<#195 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABNJPSEALNYJRAYHWG2AUMTYDHZUBAVCNFSM6AAAAAAYFBFAKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGA3DSNJRHA>. You are receiving this because you commented.Message ID: ***@***.***> VITO Disclaimer: http://www.vito.be/e-maildisclaimer

[soxofaan]

I just remembered something that could be a bit tricky:

openeo/1.2 (still flagged as not production ready for now) will expose v2 of processes
while standard /openeo/1.0 and /openeo/1.1 endpoints stick to existing v1.x processes

This means that if we bump 1.2. to be production ready, users of the generic "openeo.vito.be" connection url, will suddenly be bumped to v2 version of processes (served at /processes).

In general I don't think this will cause issues.
However, at one point the v1-vs-v2 version of processes did cause a confusing issue in the aggregator (Open-EO/openeo-aggregator#118). So we should keep that in mind if people notice weird things. We can always point them to a pinned down API endpoint as workaround

[soxofaan]

flagged 1.2 as production ready with 97d5192

[soxofaan]

flagging 1.2 as production ready caused nextland integration tests to fail because these use chunk_polygon which does not exist in v2 version of processes.

will revert flagging 1.2 as production ready for now. And then port nextland to apply_polygon

[soxofaan]

pushed another attempt to flag 1.2 as production ready: 9f5361c