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
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
wrote:
> Answering your 4 emails at once:
>
>
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 b
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?
___
gdal-dev mailing list
gdal-dev@lists.o
If I’m not mistaken, each band can have its own RAT (Raster Attribute
Table). However, in the gdalinfo JSON output, the "rat" key appears at the
root level, not within the individual "bands". It seems there's no
indication of which band the RAT belongs to. Am I missing something?
__
Hi! I just noticed that gdalinfo reports the NoData value as 255.0 in JSON
output, but as 255 in the default text output. Why is there a difference?
$ gdalinfo -json 8812.tif | jq '.bands[0]["noDataValue"]'
255.0
$ gdalinfo 8812.tif
...
Band 1 Block=256x256 Type=Byte, ColorInterp=Gray
NoData Va
