Get datacube and dimension properties

[m-mohr]

It seems useful to be able to query the data cube / dimension properties.

The following could be of interest (taken from the openEO Glossary):

• Data Cube: Dimensions (might not be required as process, I'm missing a use case)
• Dimension:
  • Name (might not be required as process, I'm missing a use case)
  • Axis / Number (might not be required as process, I'm missing a use case)
  • Type (might not be required as process, I'm missing a use case)
  • Extents / Labels -> exists as dimension_labels
  • reference system / projection -> could be dimension_proj (STAC proj extension) / dimension_reference_system (STAC data cube extension) or so?
  • resolution -> could be dimension_gsd (STAC gsd field) or so?

[m-mohr]

Some related prior comments from #187:

@m-mohr

I just realized we have count(dimension_labels()) which could be useful to compute the resolution, but still I feel a separate process would make it more convenient. People will likely not like to compute such stuff by hand.

@jdries

I would also opt for a process that returns the physical 'pixel size' for a spatial dimension. Usually this is returned in the distance unit of the CRS. So degrees for lat lon, meter for utm. But what would be a good name?

[m-mohr]

@jdries @clausmichele I made this a separate issue.

Regarding your question about the pixel size process: dimension_ground_sample_distance (a bit long) / dimension_gsd (not sure how intuitive it is) could be potential names. That would be in line with our metadata ("gsd" in STAC).

[jdries]

In OGC coverages, they simply used resolution: http://docs.opengeospatial.org/is/09-146r6/09-146r6.html#31 Following STAC is also an option, but keep in mind that 'ground sample distance' very specifically seems to refer to spatial dimensions, whereas the OGC definition can accomodate any regularly spaced axis.

[m-mohr]

Yep, there were discussions in STAC about gsd vs resolution and we felt gsd is more specific and resolution a bit overloaded.

I don't see a bigger issue with gsd yet, as the openEO glossary explicitly says in the title of the data cube chapter we are working with "spatial data cubes" so a spatial term seems reasonable, but we could also loosen that in the future?

Having that said, I have no strong preference.

[m-mohr]

From D34 to keep track of feedback:

Dimensionality of the data cube in processing chain: It has been mentioned that it would be beneficial to have the possibility to know which dimensionality and dimension labels (especially temporal and spectral) the data cube has at a certain state of the process graph.