[gdal-dev] gdal-dev Digest, Vol 258, Issue 14

[Mark Johnson]

<gdal-dev-request at lists.osgeo.org> schrieb am Fr., 14. Nov. 2025, 03:43:

> Send gdal-dev mailing list submissions to
>         gdal-dev at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.osgeo.org/mailman/listinfo/gdal-dev
> or, via email, send a message with subject or body 'help' to
>         gdal-dev-request at lists.osgeo.org
>
> You can reach the person managing the list at
>         gdal-dev-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gdal-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: GDAL CLI converting to output datatype before performing
>       calculation (Daniel Baston)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Nov 2025 21:42:55 -0500
> From: Daniel Baston <dbaston at gmail.com>
> To: Henry Walshaw <henry at floodmapp.com>
> Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] GDAL CLI converting to output datatype before
>         performing calculation
> Message-ID:
>         <CA+K_q_p3KD9JTs+qznP1r6utx81bSuL1SSghTAR0yf0BJN=
> 47w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ------------------------------
>
> End of gdal-dev Digest, Vol 258, Issue 14
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251114/f00b693e/attachment.htm>