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
- Add
window and band kwargs to read_geotiff_gpu for signature parity with read_geotiff_dask / open_geotiff / read_vrt.
- Forward both from
open_geotiff when gpu=True.
- 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.
- Adjust coords /
transform attr for the window the same way open_geotiff and read_geotiff_dask do.
Related
This is the same family of issue as #1561 -- the GPU dispatch path silently drops kwargs that other backends accept.
Summary
open_geotiff(source, gpu=True, window=..., band=...)silently ignores bothwindowandband, returning the full file in full multi-band shape. The dispatch atxrspatial/geotiff/__init__.py:498-502only forwardsdtype,overview_level,name,chunks,max_pixelstoread_geotiff_gpu, andread_geotiff_gpuitself does not declarewindoworbandkwargs.The CPU eager path (
open_geotiffwithgpu=False) and the dask path (read_geotiff_dask) both honorwindowandband. The VRT path (read_vrt) also honors them. The GPU path is the odd one out.Reproducer
Severity
HIGH (silent-drop, data correctness, breaks backend substitutability).
A direct call
read_geotiff_gpu(source, window=...)raisesTypeError(loud, fine). The bug is theopen_geotiffdispatch 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
windowandbandkwargs toread_geotiff_gpufor signature parity withread_geotiff_dask/open_geotiff/read_vrt.open_geotiffwhengpu=True.window/bandexactly like the CPU paths. A future PR can short-circuit tile decode for partial windows.transformattr for the window the same wayopen_geotiffandread_geotiff_daskdo.Related
gpukeyword has three incompatible value spaces across the public API #1560 (gpukeyword value-space drift across public API)This is the same family of issue as #1561 -- the GPU dispatch path silently drops kwargs that other backends accept.