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/1961#issuecomment-370273091,https://api.github.com/repos/pydata/xarray/issues/1961,370273091,MDEyOklzc3VlQ29tbWVudDM3MDI3MzA5MQ==,1217238,2018-03-04T23:06:59Z,2018-03-04T23:06:59Z,MEMBER,"> Except here where, instead of a flat collection of coordinate wrappers, I was rather thinking about a 1-level nested collection that separates them depending on what they implement. Indexes would represent one of these sub-collections.

This seems messier to me. I would rather stick with adding a single OrderedDict to the data model for `Dataset` and `DataArray`.

Would it be that confusing to see an xgcm grid or xarray-simlab clock listed as in the repr as an ""Index""? Letting third-party libraries add their own repr categories seems like possibly going too far.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302077805
https://github.com/pydata/xarray/issues/1961#issuecomment-370271596,https://api.github.com/repos/pydata/xarray/issues/1961,370271596,MDEyOklzc3VlQ29tbWVudDM3MDI3MTU5Ng==,1217238,2018-03-04T22:47:22Z,2018-03-04T23:02:52Z,MEMBER,"I guess the common pattern for ""coordinate wrappers""/""indexes"" looks like:
- They are derived from/associated with one or more coordinate variables.
- Operations that preserve associated coordinates should also preserve coordinate wrappers. Conversely, operations that drop any associated coordinates should drop coordinate wrappers.
- If associated coordinates are subset, coordinate wrappers can be lazily updated (in the worst case from scratch).
- Serialization to disk netCDF entails losing coordinate wrappers, which will need to be recreated.
- Coordinate wrappers *may* implement indexing for one or more coordinates.

Possible future features for coordinate wrappers:
- A protocol for saving metadata to netCDF files to allow them to be automatically recreated when loading a file from disk.
- Implementations for other indexing based operations, e.g., resampling or interpolation.

I'm open to other names, but my inclination would be to still call all of these `indexes`, even if they don't actually implement indexing.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302077805
https://github.com/pydata/xarray/issues/1961#issuecomment-370248564,https://api.github.com/repos/pydata/xarray/issues/1961,370248564,MDEyOklzc3VlQ29tbWVudDM3MDI0ODU2NA==,1217238,2018-03-04T17:48:29Z,2018-03-04T17:48:29Z,MEMBER,"This has some similarity to what we would need for a `KDTreeIndex` (e.g., as discussed in https://github.com/pydata/xarray/issues/1603). If we can use the same interface for both, then it would be natural to support other ""derived indexes"", too.

What would the proposed interface be here?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,302077805