issues

What happened?

xr.where(..., keep_attrs=True) overrides coordinate attributes of the result with global attributes from one of its inputs.

What did you expect to happen?

The coordinate attributes to remain unchanged.

Minimal Complete Verifiable Example

```Python import xarray as xr

x_coord = xr.DataArray( [1, 2, 3], dims="x", attrs={"units": "m"} ) a = xr.DataArray( [1, 2, 3], dims="x", coords={"x": x_coord}, attrs={"units": "K"} ) res = xr.where(a > 1, a, 0, keep_attrs=True) assert res.coords["x"].attrs["units"] == "m" # Fails, overridden with "K" ```

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [ ] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

No response

Anything else we need to know?

Not sure if this is a duplicate of https://github.com/pydata/xarray/issues/2245. If so, feel free to close :)

Environment

What happened: A linear DataArray.polyfit seems to fail if there are less than 3 non-NaN elements along the fitting dimension.

I've played around with the degree a little bit and the error seems to occur as soon as (# of non-NaN values - degree) < 2

What you expected to happen:

The fit to succeed - I think two non-NaN values should be enough for a linear fit. I also noticed that there is no RankWarning: Polyfit may be poorly conditioned if the degree is larger than the number of non-NaN values.

Minimal Complete Verifiable Example:

```python import xarray as xr import numpy as np

arr = xr.DataArray([np.nan, 1, 2], dims='x', coords={'x': [0, 1, 2]}) arr.polyfit(dim='x', deg=1) ```

Anything else we need to know?:

Environment:

MCVE Code Sample

```python import xarray as xr

ds = xr.Dataset({'data': ('x', [1, 2]), 'x': ('x', [1, 2]), 'x_bnds': (('x', 'bnds'), [[0.5, 1.5], [1.5, 2.5]])}) ds['x'].attrs['bounds'] = 'x_bnds' ds = ds.expand_dims({'time': [0]}) ```

Output: <xarray.Dataset> Dimensions: (bnds: 2, time: 1, x: 2) Coordinates: * time (time) int64 0 * x (x) int64 1 2 Dimensions without coordinates: bnds Data variables: data (time, x) int64 1 2 x_bnds (time, x, bnds) float64 0.5 1.5 1.5 2.5

Expected Output

<xarray.Dataset> Dimensions: (bnds: 2, time: 1, x: 2) Coordinates: * time (time) int64 0 * x (x) int64 1 2 Dimensions without coordinates: bnds Data variables: data (time, x) int64 1 2 x_bnds (x, bnds) float64 0.5 1.5 1.5 2.5

Problem Description

Dataset.expand_dims expands dimensions on coordinate bounds (referenced via the bounds attribute of a coordinate variable). Since coordinates are not expanded I would expect their bounds to remain unchanged, too. At the moment you'd have to expand dimensions before adding bounds to achieve that.

Output of xr.show_versions()

Code Sample, a copy-pastable example if possible

```python import xarray as xr

data1 = [[1, 2], [3, 4]] y1 = [1, 2] x1 = [1, 2]

data2 = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] y2 = [1, 2, 3] x2 = [1, 2, 3]

dataset1 = xr.Dataset({'data1': xr.DataArray(data1, dims=('y', 'x'), coords={'y': y1, 'x': x1})}) dataset2 = xr.Dataset({'data2': xr.DataArray(data2, dims=('y', 'x'), coords={'y': y2, 'x': x2})}) dataset1.to_netcdf('test.nc', mode='w', group='grp1', engine='h5netcdf') dataset2.to_netcdf('test.nc', mode='a', group='grp2', engine='h5netcdf')

xr.open_dataset('test.nc', group='grp1', engine='h5netcdf') # works xr.open_dataset('test.nc', group='grp1', engine='netcdf4') # fails ```

Traceback:

Output of ncdump test.nc ``` ncdump test.nc netcdf test {

group: grp1 { dimensions: y = 3 ; x = 3 ; variables: int64 data1(y, x) ; int64 x(x) ; int64 y(y) ; data:

data1 = NetCDF: Start+count exceeds dimension bound Location: file vardata.c; line 478 ```

Problem description

If datasets with different coordinates have been written to different netCDF groups using the h5netcdf engine, the generated file cannot be read by ncdump or the netcdf4 engine. The file is readable by the h5netcdf engine, though.

If the file is generated using the netcdf4 engine, it is readable by both ncdump and the netcdf4/h5netcdf engines. Also, if the datasets have identical coordinates, there is no such problem.

Expected Output

Since the file is readable by the h5netcdf engine, I'm not sure whether this is actually a bug. But at least I would expect the output file to be readable by ncdump - independent of the engine.

Output of xr.show_versions()