issue_comments

Yes, I tested this locally, and here is the PR for that suggestion: #6366

No, in this case "coordinates" in encoding will resolve to False, so that's not the problematic step.

I think the problem is that the author of line 773 assumed that pop_to would return the value of attrs['coordinates'] if encoding['coordinates'] is not set. That is wrong and the line should be fixed to look like this instead: python coords_str = pop_to(encoding, attrs, "coordinates") or attrs.get("coordinates")

@DWesl Thanks for digging into the details of the CF! I read your post in the sense that solution (1) is the one to choose.

I have one more question though before we close this:

When setting "coordinates" as a variable attribute instead of as an encoding, the value of that variable attribute is overwritten when writing to a NetCDF file, see this example: python import xarray as xr ds = xr.Dataset( {"values": ('time', [0.0, 0.1])}, coords={ 'time': ('time', [0, 1]), 'lat': ('time', [5, 4]), 'lon': ('time', [10, 12]) }) ds['values'].attrs['coordinates'] = "time lon lat" ds.to_netcdf("test.nc") shell $ ncdump -h test.nc netcdf test { dimensions: time = 2 ; variables: double values(time) ; values:_FillValue = NaN ; values:coordinates = "lon lat" ; int64 time(time) ; int64 lat(time) ; int64 lon(time) ; } Is this intended, and if so, what is the reason?

Hey @dcherian,

Thanks for your consideration! I just started to create a new branch with my suggested changes, but then I noticed that setting the coordinates attribute to include non-auxiliary dimensions by default will let a lot of unit tests fail. That made me think about this again: In fact, always setting the coordinates attribute is permissible according to the conventions. However, most users will probably be confused about the clutter and we might run into some discussions about this in the future.

In my original post, the example can easily be fixed to reflect the coordinate attributes in the conventions (https://cfconventions.org/cf-conventions/cf-conventions.html#_single_trajectory) by enforcing the attribute value in the encoding: python import xarray as xr ds = xr.Dataset( {"values": ('time', [0.0, 0.1])}, coords={ 'time': ('time', [0, 1]), 'lat': ('time', [5, 4]), 'lon': ('time', [10, 12]) }) ds['values'].encoding['coordinates'] = "time lon lat" ds.to_netcdf("test.nc") shell $ ncdump -h test.nc netcdf test { dimensions: time = 2 ; variables: double values(time) ; values:_FillValue = NaN ; values:coordinates = "time lon lat" ; int64 time(time) ; int64 lat(time) ; int64 lon(time) ; }

From here, there are several ways to proceed: 1. Stick to the current logic which might be non-conformal with the CF conventions in case of "Discrete Sampling Geometries". However, users can manually fix this by setting the coordinates in encoding. 2. Enforce to always list all non-auxiliary coordinates in the variable attribute, which is conformal with the conventions, but generates a lot of clutter. 3. Implement a logic to recognize cases where a dataset is a "Discrete Sampling Geometry" and only then list the non-auxiliary coordinates in the variable attribute. This is a bit tricky, and I don't have the time to implement this, I'm afraid.

I actually suggest to choose solution (1) and close this issue as "won't fix". What do you think?

If you are interested in a fix, I would modify the following section: https://github.com/pydata/xarray/blob/613a8fda4f07181fbc41d6ff2296fec3726fd351/xarray/conventions.py#L726-L744 The variable_coordinates should be initialized for each variable v with the names in v.dims. Currently, the dimension names are explicitly excluded. So it seems to me like this behavior has originally been implemented on purpose because the main use of the coordinates attribute according to the CF convention is to list the auxiliary coordinates. However, the conventions also say: "Note that it is permissible, but optional, to list coordinate variables as well as auxiliary coordinate variables in the coordinates attribute." (https://cfconventions.org/cf-conventions/cf-conventions.html#coordinate-system)

So, this issue is about including the non-auxiliary coordinates by default because it's permissible in general, and it is even required for so-called "Discrete Sampling Geometries".