Automatically detect dim names

[clausmichele]

For the tests I'm writing, it would be good to automatically detect the dim names provided by the data collection.

For openEO collections is fairly easy, since the cube:dimensions field is required: https://api.openeo.org/#tag/EO-Data-Discovery/operation/describe-collection

However, when using load_stac, it is not obvious that the STAC metadata includes them. In the contect of the test suite is not an issue, since the sample STAC collection that I created does include the field.

But generally at openEO level, it is not defined how the back-end should name the dimensions in the case no cube:dimensions filed is provided. Probably we will need to discuss about this in the next dev meeting or PSC.

[m-mohr]

But generally at openEO level, it is not defined how the back-end should name the dimensions in the case no cube:dimensions filed is provided.

Although defined in cube:dimensions, this is generally talking about datacubes, so there are at least recommendations available:

Maybe we should move this to a more general place in the API spec?

[clausmichele]

@m-mohr I was actually thinking about STAC Collections that do not contain the cube:dimensions property, like https://earth-search.aws.element84.com/v1/collections/sentinel-2-l2a
Anyway, for the sake of the test suite, now I implemented an automatic read of the collection metadata, looking for cube:dimensions here:

openeo-test-suite/src/openeo_test_suite/tests/workflows/conftest.py

Line 162 in 3db8c51

def collection_dims(

[m-mohr]

Yes, exactly. The S2 L2A provided is not (really) a datacube, in this case I'd load the data into a datacube as proposed in the screenshot above (so for S2 L2A usually x,y,t,bands).

[clausmichele]

Ok, then I see two possibilities to clarify this scenario:

1. In the process definition of load_stac, define that if no cube:dimensions are provided it's mandatory to use x,y,t,bands.
   1.1. If cube:dimensions are provided it's mandatory to use the dimension names provided there.
2. Allow each back-end to use their default dimension names making it clear somewhere that they need to use that.

I would choose 1, adding some informative error messages for the scenario where a user tries to use the default dim names but the STAC Collection provide different ones.

[m-mohr]

Yes, I think we should clarify that in load_stac. We more or less copy the text from the API to load_stac and if back-ends don't follow that convention, they can just change the process description.

Processes would anyway throw an error if the dimension names are not present.

[m-mohr]

@clausmichele See Open-EO/openeo-processes#489 and Open-EO/openeo-processes#488

[clausmichele]

I'm closing this issue since it's solved for the scope of the test suite.