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
Wrong list of coordinate when a singleton coordinate exists #6196
Comments
Thanks for raising this suggestion @lanougue .
What do you think it should return? When selecting a coordinate there seem to be only 3 options to me:
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.
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 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
but this breaks a fair number of tests - 25 failed just in
You might say "well in my example 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 Interested to hear what you think though. |
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(). 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. |
Can you perhaps use
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) |
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).
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 ! |
Yes when you index out a single location
Xarray only checks if a coordinate variable's dimensions are a subset of the extracted DataArray dimensions. for a scalar, |
What happened?
Here is some simple code:
Now calling
a['x']
ora['x'].coords
showsy
as a coordinate ofx
, which is unexpected for meWhat did you expect to happen?
I expect that a singleton coordinate of a dataset not to be a coordinate of other coordinates present in the dataset
Minimal Complete Verifiable Example
returns
Relevant log output
No response
Anything else we need to know?
No response
Environment
INSTALLED VERSIONS
commit: None
python: 3.8.12 | packaged by conda-forge | (default, Oct 12 2021, 21:57:06)
[GCC 9.4.0]
python-bits: 64
OS: Linux
OS-release: 3.12.53-60.30-default
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.12.1
libnetcdf: 4.8.1
xarray: 0.19.0
pandas: 1.3.5
numpy: 1.20.3
scipy: 1.6.3
netCDF4: 1.5.8
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: 1.5.1.1
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: 2021.10.0
distributed: 2021.10.0
matplotlib: 3.2.2
cartopy: None
seaborn: None
numbagg: None
pint: None
setuptools: 60.5.0
pip: 21.3.1
conda: None
pytest: None
IPython: 7.31.0
sphinx: None
The text was updated successfully, but these errors were encountered: