Simpler or more predictable dimension detection with load_stac?

[soxofaan]

We recently had various discussion that working with load_stac based cubes can hard because it is not always clear if certain dimensions are present. Which causes confusion down the line, e.g. "can I drop the time dimension?" or "should I re-add this dimension before merge_cubes"?

STAC is pretty flexible, and it is not always very clear if a load_stac'ed datacube is expected to have a temporal dimension for example. Moreover in openEO, it's also important to know the dimension names to properly handle openEO processes like reduce_dimension/apply_dimension/..., and this has to be consistent both at client and backend side.

With the STAC datacube extension it is possible to explicitly list and name dimensions, which seems to be the source of truth for this problem. Note that this extension allows to explicitly omit a dimension, and as such should not be assumed to be present in the data cube.

However, when this datacube extension is not available in the STAC metadata, it seems best, based on discussion with users, to just naively assume a typical 4D EO datacube:

• spatial dimensions "x" and "y"
• temporal dimension "t"
• band dimension "bands"

(based on the openEO recommendation on openEO collection dimension names)

[soxofaan]

this WIP PR is related to this:

• Leverage pystac for deeper spatial dimension detection #739