Spec for "bands" cube:dimension?

[soxofaan]

For collection metadata the spec defines the cube dimensions under properties/cube:dimensions. For spatial and temporal dimensions the type is well defined (spatial and temporal), but for "additional dimension" (typically for spectral bands I guess) it a is free form "custom type".

Example from the example in the spec:

"properties": {
  "cube:dimensions": {
    .....
    "spectral": {
      "type": "bands",
      "values": ["B1", "B2", "B3", ...  ]
    }

Example from earth engine (https://earthengine.openeo.org/v0.4/collections/COPERNICUS/S2_SR):

"properties": {
  "cube:dimensions": {
    .....
    "bands": {
      "type": "bands",
      "values": ["B1", "B2", "B3", ...  ]
    }

Note how both use the type "bands" , but use a different key ("bands" versus "spectral").

At the moment this "bands" type is just the generic "custom type" and not specified in the spec as far I know. But wouldn't it be better to do so as it is a very common dimension?

Also: shouldn't there be a recommendation/spec about the key names in of the cube:dimensions map/dict? See the above example with "bands" versus "spectral". For example: recommend to give the common dimension names "x", "y", "temporal" and "bands"?

[m-mohr]

Indeed, the type bands should be standardized and I thought I had done it, but can't find it myself. The closest I could get is the description of some processes:

reduce / filter:

For multi-spectral imagery there is usually a separate dimension of type bands for the bands.

filter_bands:

The data cube is expected to have only one dimension of type bands.

load_collection (which unfortunately contradicts to filter_bands above):

Applies to all dimensions of type bands if there are multiple of them.

Regarding names: I'm not sure whether back-ends would follow it. We could make a recommendation though.

[soxofaan]

Regarding names: I'm not sure whether back-ends would follow it. We could make a recommendation though.

I don't know openapi well enough, but I guess you can not enforce that indeed. I was just wondering that this might cause portability issues when switching between backends

[m-mohr]

PR #229 includes a quite simple dimension with type bands.

[m-mohr]

@soxofaan Also added a recommendation for dimension names, see commit 831cc27 .

I'm still debating with myself whether the recommendations for spectral and z are useful...

[soxofaan]

thanks, that's indeed better,

I'm still debating with myself whether the recommendations for spectral is useful...

Indeed, I'm not sure whether it is necessary to introduce a distinction between "multi-spectral" and "non-multi-spectral" on that level of the API

[m-mohr]

@soxofaan I'm still thinking why we liked spectral so much when we discussed it last year...

Maybe it was: spatial, temporal, spectral was consistent
Now it is: x, y, temporal, spectral
Could also be: x, y, t (or time? or temporal?), bands