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/4215#issuecomment-822141918,https://api.github.com/repos/pydata/xarray/issues/4215,822141918,MDEyOklzc3VlQ29tbWVudDgyMjE0MTkxOA==,2448579,2021-04-19T03:32:00Z,2021-04-19T03:32:00Z,MEMBER,I think this can be closed thanks to @DWesl ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654889988
https://github.com/pydata/xarray/issues/4215#issuecomment-658344415,https://api.github.com/repos/pydata/xarray/issues/4215,658344415,MDEyOklzc3VlQ29tbWVudDY1ODM0NDQxNQ==,2448579,2020-07-14T18:36:37Z,2020-07-14T18:37:17Z,MEMBER,"`formula_terms` might make more sense here: https://github.com/xarray-contrib/cf-xarray/issues/34

> Is that ""putting the variables in these attributes in coords is out of scope for XArray"" or ""putting the variables in these attributes in coords is out of scope for decode_coords"" or something else?

I think this is ""we should put things in `coords` without adding a new flag"". It is a behaviour change though. So maybe we should starting issuing a warning now.

> I would say no however to ancillary_variables, since those are not really about coordinates and instead about linked data variables (like uncertainties).

The only way to link variables in xarray objects is to set them as `coords`. So I think it still makes sense in xarray-world to do this.

> should preserving encoding be a separate PR?

Separate PR. It will be a reasonably big change throughout the code base.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654889988
https://github.com/pydata/xarray/issues/4215#issuecomment-658329779,https://api.github.com/repos/pydata/xarray/issues/4215,658329779,MDEyOklzc3VlQ29tbWVudDY1ODMyOTc3OQ==,22566757,2020-07-14T18:07:05Z,2020-07-14T18:07:05Z,CONTRIBUTOR,"`formula_terms` is another attribute with variable names, although it requires a bit more parsing.

> > Question: Should we allow `decode_coords` to control whether variables mentioned in these attributes are set as coordinate variables?
>
> I don't think this is necessary. It's easy to explicitly set or reset coordinates afterwards if desired.

Is that ""putting the variables in these attributes in `coords` is out of scope for XArray"" or ""putting the variables in these attributes in `coords` is out of scope for `decode_coords`"" or something else?

> I would say no however to ancillary_variables, since those are not really about coordinates and instead about linked data variables (like uncertainties).

I tend to think of uncertainties and status flags as important for the interpretation of the associated variables that should stay with the data variables unless a decision is explicitly made to drop them.  On the other hand, since XArray seems to associate coordinates with dimensions rather than with variables, I can see why this might be less than desirable.  This argument would also apply to `grid_mapping`.

> > My one concern with #2844 is clarifying the role of `encoding` vs. `attrs`.
>
> I think we should probably ensure that xarray always propagates `encoding` exactly like how it propagates `attrs`.

Should this be part of #2844 or should preserving `encoding` be a separate PR?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654889988
https://github.com/pydata/xarray/issues/4215#issuecomment-656899749,https://api.github.com/repos/pydata/xarray/issues/4215,656899749,MDEyOklzc3VlQ29tbWVudDY1Njg5OTc0OQ==,1217238,2020-07-10T21:29:22Z,2020-07-10T21:29:22Z,MEMBER,"Sounds good to me! `coordinates` were the main example that came up when I wrote this (and we needed them for xarray's data model), but these other attributes look like they serve a similar role.

> **Question**: Should we allow `decode_coords` to control whether variables mentioned in these attributes are set as coordinate variables?

I don't think this is necessary. It's easy to explicitly set or reset coordinates afterwards if desired.

> My one concern with #2844 is clarifying the role of `encoding` vs. `attrs`.

I think we should probably ensure that xarray always propagates `encoding` exactly like how it propagates `attrs`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654889988
https://github.com/pydata/xarray/issues/4215#issuecomment-656789017,https://api.github.com/repos/pydata/xarray/issues/4215,656789017,MDEyOklzc3VlQ29tbWVudDY1Njc4OTAxNw==,3460034,2020-07-10T17:17:59Z,2020-07-10T17:41:31Z,CONTRIBUTOR,"I agree with #3689 that it makes the most sense to have `decode_coords` set those variables referenced in `bounds` as coordinates. By the same reasoning, I would think the other special variable-linked attrs of [CF Section 7](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#_data_representative_of_cells) should be treated similarly:

- `cell_measures`
- `climatology`
- `geometry`
- `node_coordinates`
- `node_count`
- `part_node_count`
- `interior_ring`

`grid_mapping` and `ancillary_variables` were also brought up. `grid_mapping` definitely makes sense to be interpreted as a coordinate variable, since it is inherently linked to the CRS of the data. I would say no however to `ancillary_variables`, since those are not really about coordinates and instead about linked data variables (like uncertainties).

My one concern with #2844 is clarifying the role of `encoding` vs. `attrs`. I don't have any good conclusions about it, but I'd want to be very cautious about not having these ""links"" defined by the CF conventions disappear unexpectedly because they were decoded by `decode_coords`, moved to `encoding`, and then erased due to some xarray operation clearing encoding on the returned data. I'd hope to keep them around in some fashion so that they are still usable by libraries like cf-xarray and MetPy, among others.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,654889988