html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/5170#issuecomment-1527376059,https://api.github.com/repos/pydata/xarray/issues/5170,1527376059,IC_kwDOAMm_X85bCei7,5821660,2023-04-28T10:47:38Z,2023-04-28T10:47:38Z,MEMBER,"@floriankrb Sorry for the long delay. If you are still interested in the source of the issue, here is what I found:

By default Xarray will promote any data variable which shares it's name with a dimension to a coordinate. That accounts for ['number', 'time', 'step', 'heightAboveGround', 'latitude', 'longitude']. `valid_time` is a two dimensional coordinate (by CF standard) and is a coordinate here because `t2m` data variable has a corresponding `coordinates`-attribute containing `valid_time`. In the decoding-step `valid_time` gets added to the `.coords`. The attribute is removed from `t2m`'s attrs and kept in `t2m.encoding`. So far so good.

By renaming `number` to `n` that coordinates attribute (in encoding) does **not** change as well. So when the data is written, `t2m` will still hold `number` in it's `coordinates`-attribute (on disk).

The issue manifests on subsequent read as now the decoding-step tries to align the found `coordinates` with the available data variables. As `number` is not available, no coordinate from that string will be taken into account as coordinate (note the `all` on line 444):

https://github.com/pydata/xarray/blob/0f4e99d036b0d6d76a3271e6191eacbc9922662f/xarray/conventions.py#L439-L447

This can easily be observed by looking into `t2m.attrs` where the `coordinates` remains instead of being preserved in `.encoding`.

So the source of all problems here is that the renaming `number` -> `n` was missed for `coordinates`-attribute of `t2m`'s `.encoding`.



","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,859772411