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/2308#issuecomment-408016722,https://api.github.com/repos/pydata/xarray/issues/2308,408016722,MDEyOklzc3VlQ29tbWVudDQwODAxNjcyMg==,10050469,2018-07-26T08:19:29Z,2018-07-26T08:19:29Z,MEMBER,"I'm going to leave this decision to @shoyer and @jhamman ! 

If we go forward with this, we have a couple of possibilities:

1. add ``crs`` to a coordinate variable and keep the attribute too (not so nice because doubled)
2. add ``crs`` to a coordinate variable and deprecate the ``crs`` attribute

Same with ``_FillValue``.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,344058811
https://github.com/pydata/xarray/issues/2308#issuecomment-407684501,https://api.github.com/repos/pydata/xarray/issues/2308,407684501,MDEyOklzc3VlQ29tbWVudDQwNzY4NDUwMQ==,10050469,2018-07-25T08:58:31Z,2018-07-25T08:58:31Z,MEMBER,"Again, I'm yet to be convinced that this logic should live in xarray, regardless if netCDF or rasterio is used as a backend. The job of xarray is to read the rasterio files in a ""xarray way"" (e.g. in order to leverage dask) and exposing the file attributes to the user, ideally with semantics/attribute names which are as close as possible as the underlying data model (rasterio). 

All the logic you describe could live in a dedicated library which would become a wrapper around xarray's ``open_*`` functions, and converting them to the format you describe. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,344058811