Processes to work with a CRS dimension?

[m-mohr]

In issue Open-EO/openeo.org#9 it was decided that CRS can be a dimension. This is now part of the openEO API, but we don't really have processes to work with such a dimension. For example, how would a reduce on a CRS dimension work? See also the related questions in Open-EO/openeo.org#9 (comment)

What were your thoughts on this @edzer @jdries ?

[clausmichele]

Let's try to resume this topic.
In my opinion it would be useful to have a process that returns the (single I guess) label of the CRS dimension. This can be used on its own, to inspect the metadata of the data cube and getting the projection without downloading the actual data, or in combination with a process like vector_reproject, to set the desired target projection.

What do you think? @jdries @soxofaan @m-mohr @ValentinaHutter @christophreimer

[m-mohr]

@clausmichele What about dimension_labels and inspect?
A CRS dimension usually wouldn't exist for only a single CRS, so it's usually multiple, I guess...

[clausmichele]

Fair, but we need to check if the back-ends actually support the CRS dimension. I think we didn't test it in the openeo-test-suite, I was not aware it was part of the API already.

[m-mohr]

I think VITO had an implementation to handle e.g. the S2 UTMs? @jdries

[edzer]

IIRC the VITO motivation was having to go through a large number of Sentinel-2 tiles over multiple UTM zones without wanting to warp them to a single CRS (e.g. a single UTM zone).

For example, how would a reduce on a CRS dimension work?

Such a reduction could warp/mosaic all the tiles/subcubes into a single tile/cube with one CRS.

[ValentinaHutter]

In our backend, we did not add a crs dimension, but as we use xarray, we mostly have the crs stored as an attribute. This cannot be accessed by the user directly, but could be adapted easily, if required. For vector_reproject, you do not need to specify the input crs, do you? It would be useful if you for example have two vector cubes and want to align them by reprojecting one of them to the crs of the other vector cube.

[jdries]

We defined it conceptually, but did not really add it to the actual implementation.
The main reason being that in practices we in fact are anyway often restricted to AOI sizes that fit within a single UTM zone.
Another very common solution is that users immediately reproject into a CRS that doesn't have this problem. (For instance EPSG:3035 when working in continental Europe.)
Generally speaking it could make sense to get a description of the cube without the actual data. I'm wondering if perhaps we could just return STAC metadata with the cube extension to encode this kind of info?
For the case where the cube only has a single CRS, I'm not sure if I would really expose this as a single label dimension, because it might confuse users.

[ValentinaHutter]

Reading your comment, I want to add that we generally do not use the utm crs, but the equi7 crs, which is defined by a single crs on continental scale, so for us it would mostly be a single label dimension.

[clausmichele]

Generally speaking it could make sense to get a description of the cube without the actual data. I'm wondering if perhaps we could just return STAC metadata with the cube extension to encode this kind of info?

This might be really useful, maybe we should try to have a debug or simulate process running as we were mentioning here? Open-EO/openeo-api#243

@ValentinaHutter on the openeo-processes-dask side it would not be difficult to return the metadata only, without loading the data.

[m-mohr]

We have everything in place for this, I think: https://github.com/Open-EO/openeo-processes/blob/master/meta/implementation.md#inspect-process

GEE implements it for example:

The rendering in the Web Editor could be improved a bit.

For the case where the cube only has a single CRS, I'm not sure if I would really expose this as a single label dimension, because it might confuse users.

I agree! If you load data and a dimension has a single label, the dimension should not exist unless it is exposed explicitly in metadata (also applies for bands and t).

[m-mohr]

If users want to get more information on the labels that are exposed as extents here (e.g. timestamps), they can run dimension_labels and inspect:

It seems I have some bugs to fix in GEE and the Web Editor though ;-)