Repository navigation
VRT source reads do not honor max_pixels safety limit #1796
Description
Describe the bug
read_vrt(..., max_pixels=...) caps the assembled VRT output and some resample intermediates, but it does not pass max_pixels into the source GeoTIFF reads. A VRT can request a small output or destination rect while forcing a much larger source SrcRect decode, bypassing the caller's safety budget.
Expected behavior
The max_pixels limit should apply to every materialized source window and intermediate created while reading a VRT, not just the final VRT output.
Screenshots
Not applicable.
Desktop
Not applicable.
Smartphone
Not applicable.
Additional context
The source read in xrspatial/geotiff/_vrt.py calls read_to_array(...) without forwarding max_pixels.
Activity
Honor max_pixels for VRT source reads (#1803)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
geotiff: per-tile dim check uses default cap, not caller budget (#1823)
Make read_vrt chunks mode lazy (#1807)
geotiff: cap VRT XML read size (#1818)
geotiff: reject ambiguous 3D writer inputs (#1812) (#1820)
geotiff: apply nodata mask against post-MinIsWhite sentinel (#1809) (#…
geotiff: update #1796 and #1823 VRT tests for new minimal-read semant…
geotiff: forward missing_sources from open_geotiff to read_vrt (#1810) (
geotiff: close HTTP source when COG tile fetch raises (#1819)
geotiff: read_vrt(chunks=) builds a lazy dask graph (#1822)