<[email protected]> schrieb am Fr., 14. Nov. 2025, 03:43:
> Send gdal-dev mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Henry Walshaw <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [gdal-dev] GDAL CLI converting to output datatype before > performing calculation > Message-ID: > <CA+K_q_p3KD9JTs+qznP1r6utx81bSuL1SSghTAR0yf0BJN= > [email protected]> > 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 <[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 > >> > > ​ > > > -------------- 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > ------------------------------ > > End of gdal-dev Digest, Vol 258, Issue 14 > ***************************************** >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
