indexing via any coordinate label values

[michaelaye]

Giving this discussions a good try, looks good so far! :)

So, the indexing docs say a lot that indexing by label values is a good and supported way of indexing.
I am puzzled then why da.sel() requires to be used with the dimension name and not the coordinate name?

In this example:

I have assigned lat/lon coordinates to the corresponding x/y dimensions that came "natively" from the open_rasterio call, and while I understand the difference (I think) between dimension coordinate labels and non-dimension coordinate labels, I don't understand why it is not straightforward to work with newly assigned coordinates?

dem.data.sel(lat=slice(80, -80))
[...]
ValueError: dimensions or multi-index levels ['lat'] do not exist

Am I wrong to assume that assigning new coordinates is usually motivated by either:

• plotting data over the new labels
• index data using the new labels

but I don't find a single clear mentioning how to continue working with the new coordinates after assigning them?
Digging further into the docs, I find the section on set_index and reindex, which maybe is the only way to make the new coordinates indexable (?), but the first sentence immediately talks about multi-indexes which feels like overly complex and not appropriate to my given simple problem? Maybe I'm missing something?

If set_index is really the only way to .sel for newly assigned coordinate labels, could .sel maybe dynamically do the set_index for us?

[ahuang11]

At the moment, since lon and x coordinates share the same dimension, x, you can swap_dims so that lon becomes the dimension:
dem.swap_dims({'x': 'lon'}).sel(lat=slice(80, -80))
I believe there is an ongoing effort to refactor index
#475 (comment)

[michaelaye]

Actually, what would be cool is a keyword arg in assign_coords to do the swap_dims on top, as I presume that's often the motivation to add a new coord in the first place? Wouldn't make it default of course, but would be nice to have the option.

[keewis]

This should appear somewhere near the assign_coords docs

It does (in the See Also section), but a example would certainly help.

what would be cool is a keyword arg in assign_coords to do the swap_dims on top

I think we'll want to wait with a decision until after the indexing refactor is done: we might remove the distinction between dimension coordinates and non-dimension coordinates (see #1603 (comment)), and then we would have to deprecate that option.

[atreguier]

Hi, I would be interested to know if this discussion is related with a problem I have... I don't seem to be able to make dataset.sel work, when the coordinate name differs from the dimension name, e.g. dimension = x, and coordinate = longitude(x).
In most (almost all?) the examples provided in the xarray documentation, dimension name and coordinate name seem to be the same, like time(time) or space(space), but this is not the case of all netcdf files. Is dataset.sel supposed to work when dimension name and coordinate name differ?

[michaelaye]

Yes, that's the same issue and what I didn't understand either. For .sel to work the coordinate must be a dimension coordinate, but the docs here http://xarray.pydata.org/en/stable/terminology.html#terminology fail to mention that a coordinate only is a dimension coordinate when it has the same name as the dimension. I was really hoping that one could designate a coordinate to become indexable, simpy via set_index but I couldn't make that work.
The work around is the one above, for any coordinate you need to swap the dimension and then you can .sel with it.

[dcherian]

I was really hoping that one could designate a coordinate to become indexable, simpy via set_index but I couldn't make that work.

This is on the near-term roadmap.