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.