load_stac: support Point features

[bossie]

Job j-2501092015144dff8818ec4f35a686e3 passes a single Point feature at [40.290404, 60.542651] to load_stac; the latter then issues this item search request: https://stac.openeo.vito.be/search?limit=20&bbox=40.290404%2C60.542651%2C40.290404%2C60.542651&collections=COPERNICUS30_DEM_SLOPE

The STAC API raises an error:

{
"code": "RequestError",
"description": "RequestError(400, 'search_phase_execution_exception', 'failed to create query: Provided shape has duplicate consecutive coordinates at: POINT (40.290404 60.542651)')"
}

because the bbox param is simply made up of the Point in question: 40.290404,60.542651,40.290404,60.542651

[bossie]

A possible fix might be to pass intersects instead of bbox to the item search request because the former supports Points as well: TBC

Client side filtering in load_stac i.e. intersects_spatially might have to be adapted as well.

[bossie]

load_stac does not support passing Points or Point Features as spatial_extent. The easiest way to get this process graph to work is to omit spatial_extent from load_stac/load_collection and just provide the Point Feature to aggregate_spatial.

Related: Open-EO/openeo-processes#502

[bossie]

@kvantricht could you try the above and let me know if it works?

[kvantricht]

@kvantricht could you try the above and let me know if it works?

note that for consistency in training and inference, we use the same datacube builder in extractions as well as in inference runs. In the latter, no aggregate_spatial is happening, so I'm not sure if your proposed solution would work in this case?

[bossie]

Related: Open-EO/openeo-processes#527

[kvantricht]

@kvantricht could you try the above and let me know if it works?

@bossie can confirm for the time being that two jobs previously failing now succeed with single-point geometry and removing spatial_extent. Need to test still if also our normal patch-based processing using the same datacube definition keeps working correctly.

[kvantricht]

So looks like the patch track also still works. I'm only wondering about a corner case where eventual spatial extent comes from features loaded from URL. We'll see. For now, it seems I can rerun my point jobs and many succeed now.

[bossie]

Cool. Let me know if I can close this, or if you encounter any issues.

[kvantricht]

For now can be closed indeed I think, if somehow it's clear (documentation?) that load_stac is not supposed to be used with a spatial_extent based on points (but maybe it is already).

[bossie]

For now can be closed indeed I think, if somehow it's clear (documentation?) that load_stac is not supposed to be used with a spatial_extent based on points (but maybe it is already).

From the description of load_stac from https://documentation.dataspace.copernicus.eu/APIs/openEO/Processes.html:

The GeoJSON can be one of the following feature types:

A Polygon or MultiPolygon geometry,
a Feature with a Polygon or MultiPolygon geometry, or
a FeatureCollection containing at least one Feature with Polygon or MultiPolygon geometries.

but that will probably be made even more strict: Open-EO/openeo-processes#527

[bossie]

I've got a PR set up to enforce this (make it fail fast) but since it's a breaking change we'll want to see when and how we want to merge it.

[bossie]

Moved PR to Open-EO/openeo-python-driver#360.