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/pull/4979#issuecomment-790967872,https://api.github.com/repos/pydata/xarray/issues/4979,790967872,MDEyOklzc3VlQ29tbWVudDc5MDk2Nzg3Mg==,1828519,2021-03-04T21:45:53Z,2021-03-04T21:45:53Z,CONTRIBUTOR,"> 2D lat/lon arrays could be as expensive to store as the image itself, even though the values can be computed on the fly with very cheap arithmetic.

Just wanted to mention in case it comes up later, this is true for some datasets and for others the lon/lats are not uniformly spaced so they can't be calculated (just based on the way the satellite instrument works). They have to be loaded from the original dataset (on-disk file). For a while in the Satpy library we were storing 2D dask arrays for the lon/lat coordinates until we realized xarray was sometimes computing them and we didn't want that.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,819062172
https://github.com/pydata/xarray/pull/4979#issuecomment-790936823,https://api.github.com/repos/pydata/xarray/issues/4979,790936823,MDEyOklzc3VlQ29tbWVudDc5MDkzNjgyMw==,8699967,2021-03-04T20:58:29Z,2021-03-04T20:58:29Z,CONTRIBUTOR,"For reference for how rioxarray does things: https://corteva.github.io/rioxarray/stable/getting_started/crs_management.html

```
>>> import xarray, rioxarray
>>> xda = xarray.DataArray(1)
>>> xda.rio.write_crs(4326, inplace=True)
<xarray.DataArray ()>
array(1)
Coordinates:
    spatial_ref  int64 0
Attributes:
    grid_mapping:  spatial_ref
>>> xda.spatial_ref
<xarray.DataArray 'spatial_ref' ()>
array(0)
Coordinates:
    spatial_ref  int64 0
Attributes:
    crs_wkt:                      GEOGCS[""WGS 84"",DATUM[""WGS_1984"",SPHEROID[""...
    semi_major_axis:              6378137.0
    semi_minor_axis:              6356752.314245179
    inverse_flattening:           298.257223563
    reference_ellipsoid_name:     WGS 84
    longitude_of_prime_meridian:  0.0
    prime_meridian_name:          Greenwich
    geographic_crs_name:          WGS 84
    grid_mapping_name:            latitude_longitude
    spatial_ref:                  GEOGCS[""WGS 84"",DATUM[""WGS_1984"",SPHEROID[""...
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,819062172
https://github.com/pydata/xarray/pull/4979#issuecomment-789146762,https://api.github.com/repos/pydata/xarray/issues/4979,789146762,MDEyOklzc3VlQ29tbWVudDc4OTE0Njc2Mg==,3460034,2021-03-02T19:13:38Z,2021-03-02T19:13:38Z,CONTRIBUTOR,"It's great to be able to follow along with the discussion here! I'm definitely interested in seeing where the duck array index support ends up.

One use-case motivated question: the flexible indexes refactoring has also been pointed to as the resolution to https://github.com/pydata/xarray/issues/2233, where multidimensional coordinates have the same name as one of their dimensions. I wasn't quite able to tell through the narrative here if that has been addressed along the way yet or not (""A. only 1D coordinates with a name matching their dimension name"" for implicit index creation does seem to get close though). So, would it be worth directly addressing https://github.com/pydata/xarray/issues/2233 here, or should that wait?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,819062172