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.roua...@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. > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
