load_stac properties STAC API constraints?

[soxofaan]

From description of properties in load_stac:

openeo-processes/proposals/load_stac.json

Lines 188 to 189 in fd26251

"name": "properties",

"description": "Limits the data by metadata properties to include only data in the data cube which all given conditions return `true` for (AND operation).\n\nSpecify key-value-pairs with the key being the name of the metadata property, which can be retrieved with the openEO Data Discovery for Collections. The value must be a condition (user-defined process) to be evaluated against a STAC API. This parameter is not supported for static STAC.",

ends with:

... The value must be a condition (user-defined process) to be evaluated against a STAC API.
This parameter is not supported for static STAC.

I'm not sure it's necessary to add these STAC API oriented constraints.
An openEO backend can still do property based filtering on it's own even on static STAC documents, right?

[m-mohr]

In theory yes, in practice, I'm not sure. I'd assume that it's much more common that providers don't ingest static catalogs (which can take really long) into an API for a potential search. So from a practical perspective I'd assume the statement is true in most cases and as such potentially helpful.

[soxofaan]

don't ingest static catalogs (which can take really long) into an API for a potential search.

But not allowing metadata based filtering makes it worse for the backend because you then have to load all raster/EO data which is typically orders of magnitude larger than the metadata.

I just think that the load_stac spec should not be overly specific here and avoid too much assumptions about what backends want/can implement. A backend can always throw FeatureUnsupported if things get out of their current feature scope.

For example, in the VITO backend we already support some cases of property based filtering on static STAC collections, but that's apparently not in line with the spec, strictly speaking.

[soxofaan]

Minor thing that could taken into account when this evolves into a PR:

This part on the same line is probably a direct copy from properties argument from load_collection, but needs some translation to the STAC context:

which can be retrieved with the openEO Data Discovery for Collections.