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

[Daniel Baston]

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/799d2331/attachment.htm>