issue_comments

Thank you for your explination.

Do you think it is safe to "strip" encoding after "loading" the data? or is it still used after the initial call to open_dataset?

This is another motivating reason for #5082. It's too hard to keep attrs or encoding in sync given Xarray's data model.

Since encoding is frequently out-of-date, it just causes a lot of problems. In general, the advice is to manually set encoding if you care about how your dataset is written to disk.

Kind bump

While the above "fix" addresses the issues with renaming coordinates, I think there are plenty of usecases where we would still end up with strange, or unexpected results. For example.

1. Load a dataset with many non-indexing coordinates.
2. Dropping variables (that happen to be coordinates).
3. Then adding back a variable with the same name.
4. Upon save, encoding would dictate that it is a coordinate of a particular variable and will promote it to a coordinate instead of data.

We could apply the "fix" to the drop_vars method as well, but I think it may be hard (though not impossible) to hit all the cases.

I think a more "generic", albeit breaking" fix would be to remove the "coordinates" entirely from encoding after the dataset has been loaded. That said, this only "works" if dataset['variable_name'].encoding['coordinates'] is considered a private variable. That is, users are not supposed to be adding to it at will.

And if you want to have a clean encoding dictionary, you may want to do the following:

python names = set(names) for _, variable in obj._variables.items(): if 'coordinates' in variable.encoding: coords_in_encoding = set(variable.encoding.get('coordinates').split(' ')) remaining_coords = coords_in_encoding - names if len(remaining_coords) == 0: del variable.encoding['coordinates'] else: variable.encoding['coordinates'] = ' '.join(remaining_coords)