Describe the bug
Two public entry points accept size parameters without checking that they are positive integers:
to_geotiff(tiled=True, tile_size=0) reaches xrspatial/geotiff/_writer.py:648 where math.ceil(width / tw) divides by zero.
read_geotiff_dask(chunks=0) or chunks=(0, N) unpacks at xrspatial/geotiff/__init__.py:2051 and feeds the value to dask chunk math; negative or zero values produce confusing downstream errors.
This is not subtle data corruption, but the module aims to be watertight at the API surface.
Expected behavior
to_geotiff should raise ValueError when tile_size <= 0.
read_geotiff_dask should raise ValueError when any chunk dimension <= 0.
Both messages should name the offending parameter and the invalid value.
References
xrspatial/geotiff/_writer.py:648
xrspatial/geotiff/__init__.py:2051
Describe the bug
Two public entry points accept size parameters without checking that they are positive integers:
to_geotiff(tiled=True, tile_size=0)reachesxrspatial/geotiff/_writer.py:648wheremath.ceil(width / tw)divides by zero.read_geotiff_dask(chunks=0)orchunks=(0, N)unpacks atxrspatial/geotiff/__init__.py:2051and feeds the value to dask chunk math; negative or zero values produce confusing downstream errors.This is not subtle data corruption, but the module aims to be watertight at the API surface.
Expected behavior
to_geotiffshould raiseValueErrorwhentile_size <= 0.read_geotiff_daskshould raiseValueErrorwhen any chunk dimension<= 0.Both messages should name the offending parameter and the invalid value.
References
xrspatial/geotiff/_writer.py:648xrspatial/geotiff/__init__.py:2051