geotiff: reader kwarg order drift across open_geotiff/read_geotiff_gpu/read_geotiff_dask/read_vrt #1935
Description
The four public reader entry points expose name, chunks, window, overview_level in different orders. The kwargs are keyword-only so positional callers never broke, but inspect.signature, IDE autocomplete, and the Sphinx-rendered docs all show drift.
Current order after source (keyword-only):
| function | order |
|---|---|
open_geotiff |
dtype, window, overview_level, band, name, chunks, gpu, max_pixels, on_gpu_failure, missing_sources |
read_geotiff_gpu |
dtype, overview_level, window, band, name, chunks, max_pixels, on_gpu_failure, gpu |
read_geotiff_dask |
dtype, chunks, overview_level, window, band, max_pixels, name |
read_vrt |
dtype, window, band, name, chunks, gpu, max_pixels, missing_sources |
read_vrt already matches open_geotiff (modulo params it does not accept). read_geotiff_gpu has overview_level and window swapped. read_geotiff_dask has chunks and name out of order.
This mirrors the writer-side fix in #1922 / #1925: pick the canonical order (open_geotiff) and reorder the outliers. Add a regression test that pins the keyword-only parameter order for all four readers via inspect.signature.
Scope:
xrspatial/geotiff/_backends/gpu.py:read_geotiff_gpuxrspatial/geotiff/_backends/dask.py:read_geotiff_daskxrspatial/geotiff/_backends/vrt.py:read_vrt(already conforms; covered by the regression test)- New test under
xrspatial/geotiff/tests/
Activity
geotiff: reader kwarg order matches open_geotiff (#1935) (#1936)
geotiff tests: consolidate kwarg / signature cluster (Sub-PR A) (#2458)