issue_comments

@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.

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).

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).