issue_comments

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity If this issue remains relevant, please comment here; otherwise it will be marked as closed automatically

@benbovy Agreed. My thought is that 0.9.0 should focus on index improvements -- finishing up optional indexes and multi-index support.

I crossed sel_points off the TODO list.

@shoyer it would be nice if we can close this issue before the next major release (0.9.0). There is only a few (though important) issues to fix in #1028, and right after it is merged I can open a new PR for serialization to NetCDF, for which I don't see any big issue.

Given the new indexing behavior you suggest in #974, I guess that having MultiIndex support for sel_points / sel_points wouldn't be needed anymore, although MultiIndex interaction with this alternative indexing behavior must be addressed (but maybe later).

It might be worth considering making the MultiIndex levels the primary coordinates, and making the multi-index itself the "virtual" coordinate that only appears when indexed. This would suggest a repr like:

Coordinates: * level_0 (dim_0) object 'foo' 'foo' 'bar' * level_1 (dim_0) int64 0 1 2

This probably wouldn't make sense until we have support for most of the other API niceties on this list (including indexing with .sel, which I just added).

Relevant comments!

Agreed. I would suggest calling these set_index and reset_index, mirroring pandas, unless the API ends up differing enough that this would be confusing.

OK! I didn't make the link.

Thinking about serialization, a possible solution would be splitting the multi-index into separate coordinates for the same dimension, then assign some specific attributes (e.g., xarray_idx_name, xarray_idx_level) to each of these coordinates so that it is possible to further rebuild the multi-index.

I think index_level would suffice for the serialization, unless we're interested in supporting serializing multiple multi-indexes along a dimension. I don't see much use for that, so I think it's fine to only support serializing mulit-indexes that are actually used as an index.

More generally, a couple of methods acting on coordinates only can be a complement to stack/unstack methods (acting on both coordinates and dimensions). Merge/split xarray coordinates into/from a multi-index seem very straightforward to implement.

Agreed. I would suggest calling these set_index and reset_index, mirroring pandas, unless the API ends up differing enough that this would be confusing.

Similarly, a better repr would represent levels as sub-coordinates

Yes, also agreed! Here are a few ideas for the repr:

Coordinates: * dim_0 (dim_0) MultiIndex - level_0 object 'foo' 'foo' 'bar' - level_1 int64 0 1 2 - maybe use another indicator (like -) for indenting sublevels like shown above - consider writing MultiIndex as "dtype" for the upper level. Or maybe keep object as the dtype but write MultiIndex for the values. - I don't see much use in showing the integer index level in the repr. We could consider showing the number in the MultiIndex sublevel, though I can see that getting confusing (especially because the number elements per level isn't reduced when doing indexing).

Thinking about serialization, a possible solution would be splitting the multi-index into separate coordinates for the same dimension, then assign some specific attributes (e.g., xarray_idx_name, xarray_idx_level) to each of these coordinates so that it is possible to further rebuild the multi-index.

More generally, a couple of methods acting on coordinates only can be a complement to stack/unstack methods (acting on both coordinates and dimensions). Merge/split xarray coordinates into/from a multi-index seem very straightforward to implement.

Similarly, a better repr would represent levels as sub-coordinates:

<xarray.DataArray (dim_0: 3)> array([0, 1, 2]) Coordinates: * dim_0 (dim_0) object level_0 (0) object 'foo' 'foo' 'bar' level_1 (1) int64 0 1 2

Any thoughts on this (I can start PRs)?