Add size to the all dimension objects

[jsignell]

We already have the extents and step which you can kind of use to get the size of the dimension object but you might be slightly off if you just get it be doing (extents[1] - extents[0]) / step then you might get a rounding issue and not quite end up with the right value.

So we recommend adding size which is the total number of values in a particular dimension.

[m-mohr]

The formula given above would compute the number of dimension labels (i.e. the count of values). The term size is rather ambiguous, I think. Could be understood as the count or the step / resolution. I'd rather prefer to name it count.

The rounding issue should not really be an issue for a count, simply round it to an integer. A count should always be an integer anyway.

[strobpr]

The relation between the extent covered by a grid (or any type of regular discretisation) and the number of samples in the grid is an interesting question, which in my opinion depends on the type of sampling you apply. If you do ‘point’ sampling (as e.g. in OGC coverages ISO19123-1) the situation is different than if you do ‘area’ (or interval) sampling (as in DGGS ISO19170). To make it even more confusing the cf-convention is using a third way, by allowing in principle some sort of ‘sparse area’ sampling with 'points' that have 'bounds'. I summarised the calculation of extent (per dimension/axis) for these three approaches with some 2-dimensional examples below. It should be the same for any number of dimensions.
In the past the (geographic) bounding boxes generated by gdal and other tools often did not appropriately consider the type of spatial grid of the data (which also often was poorly or falsely documented in metadata), which lead to wrong bounding boxes and shifts in the data when overlaid.
This can only be avoided if grids are exhaustively defined in the metadata, which is where I still see some shortfalls in STAC, but maybe I'm the only one.

[jsignell]

Those are super helpful visuals! So basically you could have an off-by-one error if you try to compute the count of dimension labels using the formula that I started with even for the more common two cases of "Pixel is Point" and "Pixel is Area". I think there is a question of how much of this information really belongs in STAC vs just within the metadata in the data format itself.

[strobpr]

Yes, exactly, she size of the samples does matter! To cover the same extent using the same sample spacing with a node grid (s=0) you need one sample more than with a continuous zone grid (s=S). What I should have added to the visuals is that while ‘E’ in all three cases is the same, ’n’ is different (7 for ‘Grid of Nodes’’, 6 for ‘Grid of Zones’, and 3 in the ‘Sparse Grid of Zones’).

What belongs in STAC? Well, that’s actually a good question and the answer depends on what STAC is supposed to convey. Anyone using gridded data probably needs to understand the area (or extent) covered by a dataset and of course the number of samples (or pixels as columns/rows) the dataset provides over this extent. What is always stated is the latter, but the first is often not so clear, because the sample size and distance is not made explicit. The extent (or ‘bounding box’) is then construed either based on assumptions or undocumented expert knowledge (“I know what my grid means”).

If STAC wants to avoid that, it has to be explicit regarding sample size, spacing, and positioning. This could e.g. be done with fields such as GTRasterTypeGeoKey (#1025) in Geotiff together with an explicit information how the zones are placed and referenced (for which there aren’t really standards yet to my knowledge).