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-801209397,https://api.github.com/repos/pydata/xarray/issues/4979,801209397,MDEyOklzc3VlQ29tbWVudDgwMTIwOTM5Nw==,2448579,2021-03-17T16:06:43Z,2021-03-17T16:06:43Z,MEMBER,shall we merge?,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,819062172
https://github.com/pydata/xarray/pull/4979#issuecomment-791033734,https://api.github.com/repos/pydata/xarray/issues/4979,791033734,MDEyOklzc3VlQ29tbWVudDc5MTAzMzczNA==,2448579,2021-03-04T23:43:47Z,2021-03-04T23:43:47Z,MEMBER,"> I think that for now it would be reasonable to restrict those methods to the indexes that are currently available in Xarray instead of trying to extend the API of Xarray index wrappers in order to support those special cases. 

Fully agree. We should raise nice error messages when possible. I just wanted to raise awareness about this issue (i.e. methods that use indexes in non-trivial ways).

> Are the CRSIndex and XgcmIndex examples really independent of any coordinate in the DataArray/Dataset?

Good point! I hadn't thought of it that way.

> A major advantage is that using a custom index, there's no need to encapsulate a Dataset/DataArray into a higher level structure (e.g., xgcm.Grid) and there would be more control on how it is propagated from one xarray object to another compared to an attribute or via a ""stateful"" accessor (e.g., crs)

Yes! I'm v. happy to see this discussion is happening :)

> But that can be also a downside: unless we allow multiple indexes per coordinate, such XgcmGridIndex and CRSIndex would then have the responsibility of handling selection and alignment for all their corresponding coordinates. That may not be a big deal, though: XgcmGridIndex and CRSIndex could simply encapsulate pandas.Index instances for all (or a subset) of their coordinates.

For `XgcmIndex` this is even desirable: https://github.com/xgcm/xgcm/issues/200, Re `CRSIndex` I think you're correct, it could just forward to whatever Index class it's wrapping","{""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-789773514,https://api.github.com/repos/pydata/xarray/issues/4979,789773514,MDEyOklzc3VlQ29tbWVudDc4OTc3MzUxNA==,2448579,2021-03-03T14:57:19Z,2021-03-03T16:46:07Z,MEMBER,"There are also high-level methods that *could* use indexes in non-trivial ways.  These methods become complicated when considering nD versions of `IntervalIndex` (or `CellIndex` that represents the appropriate `bounds` variable, https://github.com/pydata/xarray/issues/1475). I'm raising these so we can define the scope of the API.

1. `resample` (`CFTimeIndex` and a `DatetimeIntervalIndex`)
1. `DatetimeAccessor` & `TimedeltaAccessor` properties (`CFTimeIndex` and a `DatetimeIntervalIndex`)
1. `interp` & `interpolate_na`,
   - with `IntervalIndex`, these become regridding operations. Should we support hooks for these operations?
1. `differentiate`, `integrate`, `polyfit`
   - raise an error if not a ""simple"" 1D index? 
1. `pad`
1. `coarsen` has to make choices about output index labels.
1. `sortby`
1. plotting
    1. `plot.pcolormesh` ""infers"" interval breaks along axes, which are really inferred `bounds` for the appropriate indexes.
    1. `plot.step` again uses `bounds`. In fact, we may even want `step` to be the default 1D plotting function if the axis has `bounds` attached.

Another perhaps-unintended use-case is that various accessors will try to use `.indexes` to cache state (https://github.com/pydata/xarray/issues/3268#issuecomment-539463105). 

An example is `CRSIndex`, where the `crs` applies to all variables in a dataset but isn't associated with a dimension on any of the other variables (Maybe this is a good definition for a `PropertyIndex`). This would be used by `rioxarray`, `salem` and friends. Also consider a possible `XgcmIndex` that basically contains an `Xgcm.Grid` object (also satisfies the `PropertyIndex` definition). We would want to propagate such `PropertyIndex`es in all operations, and also optionally check them during alignment (?).","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,819062172