-
-
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
DataArray.mean drops coordinates #9168
Comments
Can confirm that the output is the same with xarray 2024.6.0 |
I believe this may be intentional (I may be wrong, though): it is often not so useful to reduce the coordinates with the same operation as the data, and so If you really need this, you can convert them to data variables first using |
@keewis Thanks! I'm not sure if it's "often" not so useful, tho ;) Can't come up with a reasonable example from our field (2D sensor data processing), but I get the point. I did what you suggest as a work-around, but I had hoped for a better solution. A bit tedious. The thing is, data.coarsen({"dim0": data.sizes["dim0"]}).mean(dim="dim0").squeeze() would work. But reading this, imho, suggests that |
This is indeed intentional — the role of coordinates is to have things which aren't computed along. That's particularly the case when doing something like Are there times which xarray is inconsistent there? Is there an example of where something "should" be a coordinate but should also be reduced over? |
Maybe we could add an option to the reductions that allows to change this behavior? But the workaround could be sufficient here. |
Well, if you consider the behaviour I described above considering
That's a hard question, since it would depend on conventions of what people put into coords. We have time-series of 2D sensor images as data variables, where we want to do operations with, and then add coordinates containing metadata, like temperatures, time stamps, measurement-specific inputs like light-source wave-length or power. In all of those cases, when averaging over the time-series of 2D sensor data, we'd like to average the coordinates, too. Granted, given there are work-arounds, and we can implement our own wrapping for this sort of stuff, it's not a big deal. |
Yes, very reasonable @derhintze ! Good point around I would vote to retain the behavior around coords — |
Closing as unlikely to inspire change, please reopen if anyone disagrees |
just as a note, I think this should be done using a combination of |
What happened?
Averaging the data variables along some dimension drops coordinates that also have that dimension.
What did you expect to happen?
I would expect that the coordinates aren't dropped, but averaged along said dimension, too.
Minimal Complete Verifiable Example
MVCE confirmation
Relevant log output
Anything else we need to know?
I had a look at #1470 and #3510, but those appear unrelated?
Environment
INSTALLED VERSIONS
commit: None
python: 3.9.7 (default, Jan 16 2024, 12:46:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]
python-bits: 64
OS: Linux
OS-release: 3.10.0-1160.el7.x86_64
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.12.2
libnetcdf: 4.9.3-development
xarray: 2024.5.0
pandas: 2.2.2
numpy: 1.26.2
scipy: 1.13.1
netCDF4: 1.6.4
pydap: None
h5netcdf: None
h5py: None
zarr: None
cftime: 1.6.3
nc_time_axis: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: 3.9.0
cartopy: None
seaborn: None
numbagg: None
fsspec: None
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: 57.4.0
pip: 21.2.3
conda: None
pytest: 8.2.2
mypy: 1.10.0
IPython: 8.16.1
sphinx: None
The text was updated successfully, but these errors were encountered: