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

[Daniel Baston]

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 <henry at floodmapp.com> 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 <
> 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
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251113/68dd5567/attachment-0001.htm>