This PR adds the coordinate name to the test failure printout in assert_allclose() when cycling through the coordinates . Specifying the coordinate makes test failures much easier to diagnose just based on the message.

• [ ] Closes #xxxx
• [x] Tests added / passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #2412
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Dataset.apply allows passing positional arguments to func as args=(), whereas DataArrayGroupBy.apply and DatasetGroupBy.apply do not. The documentation also incorrectly suggests that the reverse is true:

Dataset.apply: https://github.com/pydata/xarray/blob/4de8dbc3b1de461c0c9d3b002e55d60b46d2e6d2/xarray/core/dataset.py#L2832-L2840

DataArrayGroupBy.apply: https://github.com/pydata/xarray/blob/4de8dbc3b1de461c0c9d3b002e55d60b46d2e6d2/xarray/core/groupby.py#L473-L478

DatasetGroupBy.apply: https://github.com/pydata/xarray/blob/4de8dbc3b1de461c0c9d3b002e55d60b46d2e6d2/xarray/core/groupby.py#L580-L585

I feel that funcs passed to GroupBy objects are generally equally deserving of positional arguments, and I don't see a reason why this isn't the case.

The problem

When opening an ENVI file directly using rasterio, (some) metadata from the header file is available through tags(): python import rasterio src = rasterio.open(file) src.tags() # dict of metadata for the whole array src.tags(1) # same for band 1 Opening the same file through open_rasterio, the metadata is not carried through to the returned DataArray, neither as attributes nor as coordinates (which is the use case I'm interested in, since the metadata usually contains corresponding wavelengths for the bands).

Solutions?

I don't know what kind of data tags() might contain in general. For my use case, parsing the tags for each band as coordinates is necessary at some point. It might be better generally if the tags are stored as an attribute and munged afterwards, but this is complicated by the fact that there's tags for the whole file as well as for separate bands.

For a non-georeferenced dataset, open_rasterio() results in y-coordinates from the raster height to two times the height, instead of the expected 0 .. height range:

```python import numpy as np import rasterio from xarray import open_rasterio

tmp_file = 'no_transform.tif' nx, ny, nz = 4, 3, 3 data = np.arange(nxnynz, dtype=rasterio.float32).reshape(nz, ny, nx) with rasterio.open( tmp_file, 'w', driver='GTiff', height=ny, width=nx, count=nz, dtype=rasterio.float32) as s: s.write(data)

open_rasterio(tmp_file) ```

<xarray.DataArray (band: 3, y: 3, x: 4)>
array( ... )
Coordinates:
  * band     (band) int64 1 2 3
  * y        (y) float64 3.5 4.5 5.5
  * x        (x) float64 0.5 1.5 2.5 3.5
Attributes:
     res:        (1.0, -1.0)
     is_tiled:   0
     transform:  (0.0, 1.0, 0.0, 0.0, 0.0, 1.0)

Passing transform=from_origin(0,3,1,1) (from rasterio.transforms) to rasterio.open() in the above code seems to give the expected result with y running down from 2.5:

<xarray.DataArray (band: 3, y: 3, x: 4)>
array( ... )
Coordinates:
  * band     (band) int64 1 2 3
  * y        (y) float64 2.5 1.5 0.5
  * x        (x) float64 0.5 1.5 2.5 3.5
Attributes:
    res:        (1.0, 1.0)
    is_tiled:   0
    transform:  (0.0, 1.0, 0.0, 3.0, 0.0, -1.0)

I'm not sure whether there's something amiss in the xarray coordinate calculations or the rasterio default transform logic. Looking at the code, I feel like there's some mismatch between the rasterio res property logic and the xarray coordinate generation (namely, the sign of res[1]):

https://github.com/mapbox/rasterio/blob/fcd361c49cca9c4ad32a2ac1f5d66b967f4b6cd4/rasterio/_base.pyx#L611-L619

https://github.com/pydata/xarray/blob/f83361c76b6aa8cdba8923080bb6b98560cf3a96/xarray/backends/rasterio_.py#L131-L139

I'm not quite sure if the xarray code is quite correct for georefenced data, since it doesn't utilize the given coordinate transform. I don't' have files to test it with though.

Proof of concept for reading info from rasterio tags() in open_rasterio. Not quite a solution to #1582, but possibly workable to a more general solution.

Currently implements the following: - Reads tags(band_idx) for each band and extracts the wavelength values from the result dictionaries as a coordinate for the returned DataArray. - Reads the wavelength_units from tags(1) and sets it as an attribute (assumes it's the same for each band, which it is for ENVI format files)

• [x] Closes #1582 (Maybe?)
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

The rasterio backend tests each currently have a netcdf roundtrip test without the appropriate requires_scipy_or_netCDF4 decorator, which causes them to always fail when ran without either. They also do not seem to be necessary for testing the rasterio backend functionality, and just add an extra dependency to the tests. The netCDF roundtrip also seems to be already better tested by the other tests in the same file.

• [x] Tests added / passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API