html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/6196#issuecomment-1450762730,https://api.github.com/repos/pydata/xarray/issues/6196,1450762730,IC_kwDOAMm_X85WeOHq,2448579,2023-03-01T19:54:47Z,2023-03-01T19:54:47Z,MEMBER,"Yes when you index out a single location `z` becomes a scalar (similar with numpy). if you want to keep the dimension use `.sel(z=['0'])`.

> I expect that a singleton coordinate of a dataset not to be a coordinate of other coordinates present in the dataset

Xarray only checks if a coordinate variable's dimensions are a subset of the extracted DataArray dimensions. for a scalar, `.dims` is an empty set, and an empty set is a subset of every set.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1115166039
https://github.com/pydata/xarray/issues/6196#issuecomment-1450036767,https://api.github.com/repos/pydata/xarray/issues/6196,1450036767,IC_kwDOAMm_X85Wbc4f,32069530,2023-03-01T12:09:21Z,2023-03-01T12:09:40Z,NONE,"Hello @TomNicholas ,

Reopening this issue 1 year later ! To answer your last question, singleton dimension seems to have, indeed, a unique behavior since they are reattached systematically to other coordinates (even if they naturally do not share any dimension with other coordinates).
These singleton dimensions introduce some strange behavior. This is another example:
```
a = xr.DataArray(np.random.rand(2,3,2), dims=('x','y','z'), coords={'x':[1,2], 'y':[3,4,5],'z':['0','1']})
b = xr.DataArray(np.random.rand(2,3,2), dims=('x','y','z'), coords={'x':[1,2], 'y':[3,4,5],'z':['0','1']})
res1 = a.sel(z='0')/b
res2 = a.sel(z='0').expand_dims('z')/b
```
res1 and res2 do not have the same size on dimension ""z"". In res1, dimension ""z"" is not considered anymore as a dimension at all !

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1115166039
https://github.com/pydata/xarray/issues/6196#issuecomment-1027064212,https://api.github.com/repos/pydata/xarray/issues/6196,1027064212,IC_kwDOAMm_X849N8GU,35968931,2022-02-01T16:59:51Z,2022-02-01T16:59:51Z,MEMBER,"> For now, I wasn't able to reproduce a minimalist example because the error disappears with minimalist example. I wasn't able to find the fundamental difference between the dataset causing the error and the minimalist one. Printing them are exactly the same.

Can you perhaps use [`ncdump`](https://www.unidata.ucar.edu/software/netcdf/workshops/2011/utilities/Ncdump.html) to show the differences?

> However, I do not understand why it should also be a ""label"" of the other coordinates of the dataset. A singleton dimension should not be ""more important"" than the other (not singleton) dimensions. Why the singleton dimension should become a ""label"" of another dimension while the other dimensions are not. This do not seem logical to me.

I'm not quite sure I understand what you mean - currently aren't all coordinates reattached to any coordinate extracted from a DataArray? (so long as they have compatible dimensions)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1115166039
https://github.com/pydata/xarray/issues/6196#issuecomment-1026774266,https://api.github.com/repos/pydata/xarray/issues/6196,1026774266,IC_kwDOAMm_X849M1T6,32069530,2022-02-01T12:07:51Z,2022-02-01T12:07:51Z,NONE,"Thanks for the enlightening.

Actually, this coordinates dependency with singleton dimension caused me a problem when using the to_netcdf() function. No problem playing whith the xr.Dataset but I get some error when trying to write on disk using to_netcdf().
For now, I wasn't able to reproduce a minimalist example because the error disappears with minimalist example. I wasn't able to find the fundamental difference between the dataset causing the error and the minimalist one. Printing them are exactly the same. I have to do deeper inspection.

Concerning the philosophy of what a coordinate should be: For me the ""label"" idea is understandable at a dataset level. A singleton dimension become a (shared) ""label' for the whole dataset. This is ok for me. However, I do not understand why it should also be a ""label"" of the other coordinates of the dataset. A singleton dimension should not be ""more important"" than the other (not singleton) dimensions. Why the singleton dimension should become a ""label"" of another dimension while the other dimensions are not. This do not seem logical to me.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1115166039
https://github.com/pydata/xarray/issues/6196#issuecomment-1023511142,https://api.github.com/repos/pydata/xarray/issues/6196,1023511142,IC_kwDOAMm_X849AYpm,35968931,2022-01-27T18:16:01Z,2022-01-27T18:41:30Z,MEMBER,"Thanks for raising this suggestion @lanougue .

> I expect that a singleton coordinate of a dataset not to be a coordinate of other coordinates present in the dataset

What do you think it should return? When selecting a coordinate there seem to be only 3 options to me:

1) **Coordinate variables retain all coordinates from the parent object.** 

This is what it currently does. It's a bit counter-intuitive, but it prioritises keeping coordinates available for use by users. It also means you can pull out a coordinate variable and then use other coordinates to index into it.

2) **Coordinate variables retain no coordinates at all.**

We could drop all of them, which makes some sense (why should a coordinate have coordinates?). We can try that out naively by adding a `drop_vars` call to `DataArray._getitem_coord`:

```python
def _getitem_coord(self, key):
    from .dataset import _get_virtual_variable

    try:
        var = self._coords[key]
        coord_da = self._replace_maybe_drop_dims(var, name=key)
        return coord_da.drop_vars(coord for coord in coord_da.coords)
```
which makes your example return
```
Coordinates:
    *empty*
```
but this breaks a fair number of tests - 25 failed just in `test_dataarray.py` (although mostly parametrizations of one test):

```
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_isel_fancy - AssertionError: Left and right DataArray objects are not identical
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_sel_dataarray - ValueError: One or more of the specified variables cannot be found in this dataset
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_coord_coords - AssertionError: Left and right DataArray objects are not identical
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_coords_non_string - AssertionError: Left and right DataArray objects are not identical
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_coordinate_diff - AssertionError: Left and right DataArray objects are not equal
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x0-5-2-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x1-5-2-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x2-5-2-1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x3-5-2-1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x4-nan-nan-0] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmin[False-x5-0-1-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x0-5-2-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x1-5-2-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x2-5-2-1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x3-5-2-1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x4-nan-nan-0] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce1D::test_idxmax[False-x5-0-1-None] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmin[False-x0-minindex0-maxindex0-nanindex0] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmin[False-x1-minindex1-maxindex1-nanindex1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmin[False-x2-minindex2-maxindex2-nanindex2] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmin[False-x3-minindex3-maxindex3-nanindex3] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmax[False-x0-minindex0-maxindex0-nanindex0] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmax[False-x1-minindex1-maxindex1-nanindex1] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmax[False-x2-minindex2-maxindex2-nanindex2] - KeyError: ""'x' is not a coordinate variable.""
FAILED xarray/tests/test_dataarray.py::TestReduce2D::test_idxmax[False-x3-minindex3-maxindex3-nanindex3] - KeyError: ""'x' is not a coordinate variable.""
```

3) ***Coordinate variables retain only coordinates with which they share some dimensions**

You might say ""well in my example `'y'` doesn't depend on dimension `'x'`, so why is it still there? We should keep the `'x'` coord and drop the `'y'` one."" But I don't really think this option makes sense if you think of all coordinates as labels: the `'y'` coord is a label for all values in the DataArray, that just happens to be independent of 'x'. Why drop one and not the other?

---

I agree this is a little counterintuitive, but it is actually causing you problems? Because I think there is a rationale for the current behaviour, and changing it would be a breaking change. In other words, it's not obvious to me that this is a bug rather than an implicit feature.

(One might also argue that if `xr.Variable` were first-class public API (as in our roadmap), then `da.coords[var]` should return a `Variable`, which has no coordinates. At the moment `da._coords[key]` returns either a `Variable` or `IndexVariable`, which then gets wrapped back up into a new `DataArray`.)

Interested to hear what you think though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1115166039