-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom indexes and coordinate (re)ordering #7002
Comments
I like option (4). If a multi-coordinate index needs to care about order, it can implement that logic itself. |
Agreed. Option 4 would be nice indeed but it might be difficult to implement in the current Another (easier) option would be to sort the names of the coordinates of each unique index before using it as a hash for finding the list of indexes to compare together, i.e., SortedCoordNamesAndDims = tuple[tuple[Hashable, tuple[Hashable, ...]], ...]
MatchingIndexKey = tuple[SortedCoordNamesAndDims, type[Index]] instead of xarray/xarray/core/alignment.py Lines 87 to 88 in 42d42ba
|
What is your issue?
(From #5647 (comment)).
The current alignment logic (as refactored in #5692) requires that two compatible indexes (i.e., of the same type) must relate to one or more coordinates with matching names but also in a matching order.
For some multi-coordinate indexes like
PandasMultiIndex
this makes sense. However, for other multi-coordinate indexes (e.g., staggered grid indexes) the order of the coordinates doesn't matter much.Possible options:
Index.create_variables()
, to ensure consistent orderIndex.matching_key
abstract property in order to support re-indexing and alignment.Index.join
andIndex.equals
, e.g., forPandasMultiIndex
maybe reorder the levels beforehand.The text was updated successfully, but these errors were encountered: