geotiff: open_geotiff(gpu=True) silently drops window= and band= kwargs #1605

Summary

open_geotiff(source, gpu=True, window=..., band=...) silently ignores both window and band, returning the full file in full multi-band shape. The dispatch at xrspatial/geotiff/__init__.py:498-502 only forwards dtype, overview_level, name, chunks, max_pixels to read_geotiff_gpu, and read_geotiff_gpu itself does not declare window or band kwargs.

The CPU eager path (open_geotiff with gpu=False) and the dask path (read_geotiff_dask) both honor window and band. The VRT path (read_vrt) also honors them. The GPU path is the odd one out.

Reproducer

from xrspatial.geotiff import open_geotiff, to_geotiff
import numpy as np, xarray as xr

a = xr.DataArray(np.arange(100*100, dtype=np.uint16).reshape(100, 100), dims=("y", "x"))
to_geotiff(a, "/tmp/x.tif")

cpu = open_geotiff("/tmp/x.tif", window=(10, 10, 30, 30))
print("CPU window shape:", cpu.shape)            # (20, 20)

gpu = open_geotiff("/tmp/x.tif", gpu=True, window=(10, 10, 30, 30))
print("GPU window shape:", gpu.shape)            # (100, 100)  <-- bug: window silently dropped

Severity

HIGH (silent-drop, data correctness, breaks backend substitutability).

A direct call read_geotiff_gpu(source, window=...) raises TypeError (loud, fine). The bug is the open_geotiff dispatch path where the kwargs land on a function that does not accept them, and the dispatcher does not even attempt to forward them.

Proposed fix

1. Add window and band kwargs to read_geotiff_gpu for signature parity with read_geotiff_dask / open_geotiff / read_vrt.
2. Forward both from open_geotiff when gpu=True.
3. Implementation: simplest correct version is a post-decode slice on the CuPy array. The GPU pipeline still decodes all tiles, but the returned DataArray honours window / band exactly like the CPU paths. A future PR can short-circuit tile decode for partial windows.
4. Adjust coords / transform attr for the window the same way open_geotiff and read_geotiff_dask do.

Related

• Closed: geotiff: gpu keyword has three incompatible value spaces across the public API #1560 (gpu keyword value-space drift across public API)
• Closed: geotiff: backend-specific entry points silently drop kwargs of their dispatchers #1561 (backend-specific entry points dropping dispatcher kwargs)

This is the same family of issue as #1561 -- the GPU dispatch path silently drops kwargs that other backends accept.