Representation of dimension/variable auxiliary coordinates

[fmigneault]

The Variable Object mentions how to represent data variables vs auxiliary variables containing coordinates (e.g.: lat variable derived from dimensions (y, x)). In this case, auxiliary makes a lot of sense because it depends on multiple dimensions.

However, another common occurrence in NetCDF files is to have 1:1 dimension/variable mappings in order to list the value instances composing that dimension, as shown below through time, rlat and rlon.

>>> data
<xarray.Dataset> Size: 197MB
Dimensions:         (time: 13, rlat: 1290, rlon: 2540)
Coordinates:
  * time            (time) datetime64[ns] 104B 2024-01-01 ... 2024-01-01T12:0...
  * rlat            (rlat) float32 5kB -12.3 -12.28 -12.26 ... 16.66 16.68 16.7
  * rlon            (rlon) float32 10kB -14.82 -14.8 -14.78 ... 42.28 42.31
    lon             (rlat, rlon) float32 13MB ...
    lat             (rlat, rlon) float32 13MB ...
Data variables:
    rotated_pole    float32 4B ...
    HRDPS_P_PR_SFC  (time, rlat, rlon) float32 170MB ...
Attributes:
    Remarks:                         Variable names are following the convent...
    License:                         These data are provided by the Canadian ...
    product:                         HRDPS
    Conventions:                     CF-1.6
    DODS_EXTRA.Unlimited_Dimension:  time

It is not clear whether from the extension's description if those should also be considered auxiliary variables or not (omitting them in favour of cube:dimensions). Notably, the Dimension Object provides extent/bbox, values and step properties to describe these values, and it could seem confusing for users to have "duplicate" entries between cube:variables and cube:dimensions.

STAC examples using this extension seem to omit these 1:1 variable cases. Is that the expectation, or should it still to the actual metadata of the NetCDF?

In a similar fashion, would all those dimensions/variables be potential candidates for presentation by cf:paramter, or does it limit itself to only data variables?

Reference: crim-ca/stac-populator#114 (comment)

[m-mohr]

This is left intentionally open as we didn't want to exclude any usecases, i.e. list it as you need it.

I personally would only list variables that have additional (measured) data values in addition to the dimension labels.

I don't quite understand the question about cf:paramter yet.

[fmigneault]

The main confusion is about this indication in the README:

auxiliary: a variable that contains coordinate data, but isn't a dimension in cube:dimensions

In this specific case, time, rlat and rlon are dimensions and contain coordinates.
According to the README, that would mean they should be omitted from cube:variables.

However, opening this file with an NCML descriptor shows:

<dimension name="rlon" length="2540" />
<dimension name="rlat" length="1290" />
<dimension name="time" length="13" isUnlimited="true" />

<variable name="lon" shape="rlat rlon" type="float">...</variable>
<variable name="lat" shape="rlat rlon" type="float">...</variable>
<variable name="rlon" shape="rlon" type="float">...</variable>
<variable name="rlat" shape="rlat" type="float">...</variable>
<variable name="time" shape="time" type="int">...</variable>

NetCDF therefore encodes those "dimension coordinates" as "variables", yet still does not consider them "data variables" (as shown in the previous xarray, they are not listed under Data variables:), so it could be interpreted as them being "auxiliary variables".

The lon and lat are valid auxiliary variables derived from (rlat, rlon), but rlat/rlon are themselves somewhat ambiguous. On one hand, I could follow the datacube auxiliary definition (therefore omit them from cube:variables as they are cube:dimensions), or I could list them explicitly as cube:variable+auxiliary to match the NetCDF definition (but purposely going against what datacube indicates).

The cf:parameter question is specifically regarding this part
https://github.com/stac-extensions/cf#cfparameter

An Item is only allowed to use cf:parameter in its Properties if it has at least one asset with a defined parameter array.

If I omit the ambiguous auxiliary variables from the STAC Item (only have them in cube:dimensions), then it does not seem to make sense to have an Asset with only cube:dimensions without any associated "variable/property". The values would not have any described "variable/property access name" to read them in code (as they are only dimensions).

Therefore, I do not know where I could provide the cf:parameter pointer to what rlon and rlat. This somewhat goes along #26 (definition parameter) that could be used instead of cf:parameter to provide the URI to the reference definition if it was available.