Open soxofaan opened 10 hours ago
As far as I know there is no standard/convention/recommendation for the temporal dimension, so it's not ideal to pick one arbitrary here
wait we have a recommendation in openeo-api https://github.com/Open-EO/openeo-api/blob/c5a45b4647b06e313a4f099e9119bfa3cca5c6a3/openapi.yaml#L4457-L4467:
For interoperability, it is RECOMMENDED to use the following dimension names if there is only a single dimension with the specified criteria: x for the dimension of type spatial with the axis set to x y for the dimension of type spatial with the axis set to y z for the dimension of type spatial with the axis set to z t for the dimension of type temporal
so we can work with that
And a side-issue that could be included in the fix here: the band dimension of
cube = connection.load_stac(
"https://stac.terrascope.be/collections/sentinel-2-l2a",
bands=["B02", "B04", "B08"],
lists all bands of the original STAC metadata, not just ["B02", "B04", "B08"]
.
Extra filtering of the metadata is missing here apparently. Not only for bands, but also spatial and temporal
reported by @JorisCod:
fails with
MetadataException: No temporal dimension
the STAC at URL above does not use cube extension, which openeo python client depends on to detect the temporal dimension. So at the moment, the client currently handles this as "data has no temporal dimension".
There are other indicators in the STAC metadata that there is a temporal dimension, (e.g. "extent" > "temporal") so the client could be a bit more lenient here.
However, the client also needs the name of the dimension (e.g. "t", "time", or "temporal"). As far as I know there is no standard/convention/recommendation for the temporal dimension, so it's not ideal to pick one arbitrary here