Why has cube:variables extent and values?

[m-mohr]

I'm just wondering why we had added extent and values to the variables in the first place, IMHO they don't make sense here unless I'm missing something. In the dimensions they are the dimension labels, e.g. in the time dimension the timestamps, the coordinates for x and y and for bands the band names/indices.

What's the purpose in variables? Variables consist of dimensions and as such the dimension labels are defined there. I first thought it might describe values in the array itself, but that would only work really for the extent as otherwise in values you'd need to list ALL values in the (multidimensional) array, which is actually not allowed. values is a one-dimensional array.

I feel like it makes more sense to remove extent and values and replace it with statistics.

To make it less breaking, we could deprecate the extent and values property first, and recommend statistics instead.

[jsignell]

This aligns with the discussion in the room at the STAC+Zarr sprint. We didn't know what values would be for in the Variables object. It doesn't seem like a great idea to allow values in the dimension object either. It feels like a real anti-pattern to include fields that scale so directly with the number of values in an array.

[m-mohr]

values in cube:dimension makes a lot of sense. Note that values here means the dimension labels, which has nothing to do with the actual data values in the array. A dimension doesn't have a directly associated array unless it's combined with other domains to a variable.

[jsignell]

Normally in Zarr a dimension does have a 1D array associated with it.

[m-mohr]

With what kind of values? Aren't those just the labels for the dimension?

[jsignell]

Right yeah so for example a time dimension would normally be associated with an array that contains all the datatime values. And a latitude dimension would be associated with an array that contains a bunch of latitude values.

[m-mohr]

Yeah, that's just the labels. That's exactly what we want to know for a dimension. If the list becomes too large, the extent and step can potentially be used.

[jsignell]

Right I guess my point is we wouldn't want to put all those labels in the STAC metadata.

[m-mohr]

We do in openEO :-) Of course not for all dimensions, sometimes (e.g. x,y) extents are more reasonable, but e.g. for bands dimension labels values are more helpful. Usually for discrete values you want the values, in those cases it's also often not a large list. Temporal and spatial dimensions usually go for the extent.

[jsignell]

I went to start on this and came across this example: https://github.com/stac-extensions/datacube/blob/main/examples/daymet-hi-annual.json#L85-L98 which kind of explains why these exist in the first place. Basically it's because there is no differentiation in the datacube extension between "data variables" and "coordinate variables" so if you have 2D lat, lon for instance you would define that in cube:variables. This is making me want to leave extent in there, but maybe just recommend that for "data variables" people prefer to use statistics.