[gdal-dev] GDAL CLI converting to output datatype before performing calculation

[Henry Walshaw]

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 <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>> 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
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251114/ebedbfa0/attachment-0001.htm>