Describe the bug
Two related bugs live in the Dask finite-distance path of proximity (and the allocation / direction functions that share it). Both trace back to the halo-depth computation that sizes each chunk's overlap. The depth is taken from only the first row/column coordinate spacing, in xrspatial/proximity.py near lines 1251 and 437.
Bug 1: wrong results on irregular coordinates. When later coordinates sit closer together than the first pair, the halo is too thin, so chunks miss valid targets just past the chunk boundary. Cells the NumPy backend marks as in-range come back NaN under Dask.
Repro: x = [0, 100, 101, 102, 103, 104, 105, 106] (first gap 100, the rest 1), one target, chunks (4, 2), max_distance=2.5. NumPy returns 21 in-range cells, Dask returns 6.
Bug 2: crash on single-row or single-column rasters. The same code indexes y_coords[1] and x_coords[1]. A (1, N) or (N, 1) raster has only one coordinate along that axis, so the index raises IndexError. NumPy handles these shapes fine.
Expected behavior
The Dask finite-distance path should match the NumPy backend on irregular coordinates and should not crash on (1, N) or (N, 1) rasters. The halo depth should come from the densest (smallest) spacing along each axis, and an axis with a single coordinate should add no halo along that axis.
Additional context
Both the dask+numpy path (_process_dask, near line 1251) and the dask+cupy path (_process_dask_cupy, near line 437) are affected. Same root cause in both.
Describe the bug
Two related bugs live in the Dask finite-distance path of
proximity(and theallocation/directionfunctions that share it). Both trace back to the halo-depth computation that sizes each chunk's overlap. The depth is taken from only the first row/column coordinate spacing, inxrspatial/proximity.pynear lines 1251 and 437.Bug 1: wrong results on irregular coordinates. When later coordinates sit closer together than the first pair, the halo is too thin, so chunks miss valid targets just past the chunk boundary. Cells the NumPy backend marks as in-range come back NaN under Dask.
Repro:
x = [0, 100, 101, 102, 103, 104, 105, 106](first gap 100, the rest 1), one target, chunks(4, 2),max_distance=2.5. NumPy returns 21 in-range cells, Dask returns 6.Bug 2: crash on single-row or single-column rasters. The same code indexes
y_coords[1]andx_coords[1]. A(1, N)or(N, 1)raster has only one coordinate along that axis, so the index raisesIndexError. NumPy handles these shapes fine.Expected behavior
The Dask finite-distance path should match the NumPy backend on irregular coordinates and should not crash on
(1, N)or(N, 1)rasters. The halo depth should come from the densest (smallest) spacing along each axis, and an axis with a single coordinate should add no halo along that axis.Additional context
Both the dask+numpy path (
_process_dask, near line 1251) and the dask+cupy path (_process_dask_cupy, near line 437) are affected. Same root cause in both.