issue_comments

That can probably be closed then, since it was an intentional change.

Yes I think we can close it. Thanks for your feedback and for the issue report!

But finding information about those changes right now was not so easy, is there some resource available where I can read up about the changes to indexes and functions related to them.

Not yet, this still has to be detailed in the documentation (tracked in #6293 along with other todo items related to indexes). The Indexes API already has some basic docstrings, though: https://github.com/pydata/xarray/blob/main/xarray/core/indexes.py#L1008-L1225

Thanks for the issue report @lukasbindreiter, I opened #6987. As a workaround, you could use Indexes.group_by_index(), which shouldn't have any hash issue and which might be better fitted for your use case.

Regarding (de)serialization (from)to netCDF or other formats, I wonder if building multi-indexes or other custom indexes when opening the dataset couldn't be done via some custom Xarray IO backend (https://docs.xarray.dev/en/stable/internals/how-to-add-new-backend.html). I'm not sure how easy / hard it is to implement a custom backend on top of an existing one, though. For the serialization, Xarray doesn't support custom writable backends (yet), but since multi-index levels are now real coordinates maybe a custom backend is not really needed. Right now Xarray raises NotImplementedError when trying to save a variable wrapping a multi-index, but probably we could just get rid of the multi-index "dimension" coordinate (tuple elements) and save level coordinates like any other variable.

The change is because starting from version 2022.6.0, multi-index level coordinates are no longer "virtual" but now correspond to real coordinates. The .indexes and .xindexes properties are mappings relating coordinates to their index.

There has been some discussions prior to the explicit indexes refactor about whether those properties should return a mapping of a unique vs. non-unique index objects. We choose the latter as it simplifies a lot of things internally (and perhaps externally too).

@lukasbindreiter although it is unlikely that we'll change this in the future, it would be interesting to get your feedback! How does this choice impact your workflow?

Note that both .indexes and .xindexes return an Indexes object, which has a convenient .get_unique() method that returns a list of unique index objects. It also has other convenient methods, although those are not well documented yet.