Henry, Thanks for the example. This looks like a bug in GDAL 3.12, affecting calculations where the input has a NoData value. The simplest workaround I see for now is to rewrite the command as a pipeline:
gdal raster pipeline calc -i "A=sample.tif" --calc "A > 0 ? 1 : 0" --nodata none ! materialize ! set-type --ot Byte ! write footprint_b.tif --overwrite Dan On Thu, Nov 13, 2025 at 8:32 PM Henry Walshaw <[email protected]> wrote: > Thanks for the example Daniel. I can confirm if I try the same task as you > with the 1 pixel raster I do get the result as expected. Unfortunately for > the actual data it doesn’t hold true. Using a sample.tif available here: > https://www.dropbox.com/scl/fi/fdj4acszchg0ao132kf6g/sample.tif?rlkey=ro5mgecpdp4oqcv0kljfh0go3&st=er04s2mm&dl=0 > > I can try the following (The Q text as data tool is what I’m using to do > the quick calc at the end: https://harelba.github.io/q/ ) > > > $ gdal raster convert sample.tif --output-format XYZ cells.txt > > $ q "select count(*) from cells.txt where c3 > 0" > > 22829 > > $ q "select count(*) from cells.txt where c3 >= 0.5" > > 11518 > > $ gdal raster calc -i "A=sample.tif" -o footprint_b.tif --calc "A > 0 ? 1 : > 0" --nodata none --ot Byte > > $ gdal raster convert footprint.tif --output-format XYZ footprint_cells.txt > > $ q "select count(*) from footprint_cells.txt where c3 = 1" > > 11518 > > So you can see that the rounding in this case is happening before the > calculation. For what it’s worth I’m running GDAL off the latest alpine > container ghcr.io/osgeo/gdal:alpine-normal-latest, so > > > $ gdal --version > > GDAL 3.13.0dev-fbde9c11c976a693992f7688ecf324dd11e190f1, released 2025/11/12 > > Hopefully it’s just a bug on my end! > > On 14/11/25 01:40, Daniel Baston wrote: > > Hi Henry, > > The input values should not be rounded before doing the calculation. I get > a correct result with both 3.12 and 3.11.5: > > $ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 > depth.tif > $ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : > 0" --nodata none --ot Byte > $ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ > ERROR 6: Read or update mode not supported on /vsistdout > 0.5 0.5 1 > > Dan > > On Thu, Nov 13, 2025 at 12:49 AM Henry Walshaw via gdal-dev < > [email protected]> wrote: > >> Hi all, >> >> In the docs for gdal raster calc ( >> https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc >> <https://_>) it states >> >> Input rasters will be converted to 64-bit floating point numbers before >> performing calculations. >> >> However I’ve found that when using an integer output datatype the base >> data is rounded to an integer before performing the calculation. e.g. >> converting a flood depth input.tif raster to a simple water / no water >> footprint: >> >> >> gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" >> --nodata none --ot Byte >> >> The expected result for a value of (say) 0.1 is 1, but in the above >> calculation it comes out as 0. Obviously I can leave the output datatype >> alone so it stays the same as the input’s 64-bit float, but it seems >> unnecessary. Am I looking at a bug, or is this expected behaviour? >> >> Regards, >> >> Henry >> ​ >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > ​ >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
