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
