single coordinate is overwritten with dimension by set_index

[mschrimpf]

Code Sample

import xarray as xr
d = xr.DataArray([0], coords={'coord': ('dim', [0])}, dims=['dim'])
d.set_index(append=True, inplace=True, dim=['coord'])
d.sel(dim=0)  # works
d.sel(coord=0)  # doesn't work, coord does not exist anymore
print(d)

<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
  * dim      (dim) int64 0

Problem description

when a DataArray is initialized with a dimension containing only one coordinate, selection on the coordinate is not directly possible. As a workaround, we can set_index but if there is only one coordinate on a dimension, the coordinate vanishes and its values are attached to the dimension directly.

The DataArrays in my use case are generic, in some cases there are multiple coordinates and sometimes there is only one. If the one consistent coordinate is discarded for some cases, follow-up code becomes tedious.
Having a single-coordinate MultiIndex would be much more intuitive so that one can still .sel over the coordinate.

Expected Output

<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
  * dim      MultiIndex
    coord   (dim) int64 0

For more than one coordinate on the dimension, the dimension becomes a MultiIndex with all the coordinates. With only a single coordinate however, this does not happen.

Output of xr.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 3.6.6.final.0 python-bits: 64 OS: Linux OS-release: 4.4.0-137-generic machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.UTF-8 LOCALE: en_US.UTF-8 xarray: 0.10.8 pandas: 0.23.4 numpy: 1.15.1 scipy: 1.1.0 netCDF4: 1.4.1 h5netcdf: None h5py: 2.8.0 Nio: None zarr: None bottleneck: None cyordereddict: None dask: 0.19.1 distributed: None matplotlib: 2.2.3 cartopy: None seaborn: 0.9.0 setuptools: 39.1.0 pip: 10.0.1 conda: None pytest: 3.8.0 IPython: 6.5.0 sphinx: None

[max-sixty]

Thanks for the issue @mschrimpf

The coord is there:

In [2]: d
Out[2]:
<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
    coord    (dim) int64 0
Dimensions without coordinates: dim

...but .sel doesn't accept coordinate names, only on dimensions.

Is your issue that sel should accept coordinate names?

[mschrimpf]

Sorry I missed a line in the issue, added it now. You're right about the .sel -- since it does not operate on dimension levels by default, I manually set the index: d.set_index(append=True, inplace=True, dim=['coord']). However, this now gets rid of the coordinate:

<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
  * dim      (dim) int64 0

and thus d.sel(coord=0) does not work because the coord has been discarded.

[max-sixty]

Thanks @mschrimpf

Could you clarify the intended output?

[mschrimpf]

I would expect the dimension to become a MultiIndex with a single coordinate:

<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
  * dim      MultiIndex
    coord   (dim) int64 0

When there is more than one coordinate that is what happens, but not when there is only a single coordinate.

[max-sixty]

Thanks!

I agree. For a comparable case when a list of length 2 is passed:

d = xr.DataArray([0], coords={'coord1': ('dim', [0]), 'coord2': ('dim', [1])}, dims=['dim'])

In [22]: d
Out[22]:
<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
    coord2   (dim) int64 1
    coord1   (dim) int64 0
Dimensions without coordinates: dim

In [23]: d.set_index(append=True,  dim=['coord1','coord2'])
Out[23]:
<xarray.DataArray (dim: 1)>
array([0])
Coordinates:
  * dim      (dim) MultiIndex
  - coord1   (dim) int64 0
  - coord2   (dim) int64 1

I think the rule should be that if a list is passed, it's a multi-index, as per the doc-string.

[mschrimpf]

I think the issue stems from this line of code. Removing it leads to the desired MultiIndex.
But I'm not sure if it leads to downstream issues, e.g selecting over coord1 then seems to also squeeze that dimension. Perhaps @benbovy and @jhamman can chime in as the owners of that line.

[stale]

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 or remove the stale label; otherwise it will be marked as closed automatically

[mschrimpf]

still relevant