[gdal-dev] gdalinfo -stats on Int64 raster: confusing warning

[Denis Rykov]

Thanks so much for the super quick fixes, amazing work!

And sorry for the noise. I often hesitate to open an issue when I'm not
sure it's really a bug, so the mailing list felt like a safer place to ask.

On Sun, Jun 22, 2025 at 12:27 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Answering your 4 emails at once:
>
> What’s the purpose of including the band number in the gdalinfo JSON
> output? Since the "bands" key is a list, the band number is already
> implied by the index. Doesn’t this make the explicit band number redundant?
>
> Kind of, but not really. Given that JSON based indexing is 0-based, but
> GDAL band indexing in the GDAL API is 1-based, it is not useless to recall
> that 1-based index IMHO
>
> NoData JSON value fix: https://github.com/OSGeo/gdal/pull/12625
>
> RAT JSON fix: https://github.com/OSGeo/gdal/pull/12627
>
> When I run gdalinfo with -stats options on an Int64 raster, I get the
> following warning:
>
> $ gdalinfo -json -stats zzz.tif
> Warning 1: GetNoDataValue() returns an approximate value of the true
> nodata value = 9223372036854775807. Use GetNoDataValueAsInt64() instead
>
> As an end user, what am I actually supposed to do with this warning?
>
> Submit a pull request to fix statistics computation to not use double for
> Int64/UInt64 data types, or file an issue about that.
>
> Note: I believe we have ~ 2k subcribers to the mailing list. Please try to
> group together your questions and/or use github issues when appropriate
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250622/8a9e3086/attachment.htm>