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:
>
>
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
Thank you!
On Sat, Jun 7, 2025, 7:09 PM Even Rouault
wrote:
> Now fixed
> Le 07/06/2025 à 13:58, Denis Rykov via gdal-dev a écrit :
>
> Hi,
>
> When a GeoTIFF has an associated auxiliary *.aux.xml file, running
> gdalinfo lists both the TIFF and the XML file:
>
> $
Hi,
When a GeoTIFF has an associated auxiliary *.aux.xml file, running gdalinfo
lists both the TIFF and the XML file:
$ gdalinfo test.tif
Driver: GTiff/GeoTIFF
Files: test.tif
test.tif.aux.xml
However, if there's a *.vat.dbf file, gdalinfo includes the RAT information
in the output, but t
That's fantastic! Thank you Even!
On Sun, Sep 1, 2024 at 3:08 PM Even Rouault
wrote:
> Fixed per https://github.com/OSGeo/gdal/pull/10709 in 3.9 branch, and
> more extensive fix in master in https://github.com/OSGeo/gdal/pull/10708
>
> Even
>
> --
> http://www.spatialys.com
> My software is free
Please disregard my previous message with the gdalinfo output. Here is the
correct one:
$ gdalinfo "dem.tif"
Driver: GTiff/GeoTIFF
Files: dem.tif
Size is 1541, 1335
Coordinate System is:
GEOGCRS["WGS 84",
ENSEMBLE["World Geodetic System 1984 ensemble",
MEMBER["World Geodetic System 198
$ gdalinfo dem.tif
Driver: GTiff/GeoTIFF
Files: dem.tif
Size is 1541, 1335
Coordinate System is:
GEOGCRS["WGS 84",
ENSEMBLE["World Geodetic System 1984 ensemble",
MEMBER["World Geodetic System 1984 (Transit)"],
MEMBER["World Geodetic System 1984 (G730)"],
MEMBER["World G
Issue Report Rephrased:
For certain rasters with an *Int16* data type, calling AutoCreateWarpedVRT
changes the dataset type to *Int32*. For example:
>>> ds1 = gdal.Open("dem.tif", gdalconst.GA_ReadOnly)
>>> ds1.GetRasterBand(1).DataType
3
>>> ds2 = gdal.AutoCreateWarpedVRT(ds1)
>>> ds2.GetRasterB
he overview will be used as the output size.”
>
>
>
> Maybe the thing to do is to improve the documentation of the gdalwarp
> option https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-ovr and
> mention that this option does not have on effect on the size of the output.
>
>
>
&g
I'd anticipate that both commands would yield the same outcome:
$ gdalwarp -oo OVERVIEW_LEVEL=1 -dstalpha input.vrt ovr1.tif
$ gdalwarp -ovr 1 -dstalpha input.vrt ovr1.tif
However, the reality is different. The first command behaves as intended,
utilizing overviews from *.vrt.ovr, while the secon
Hi,
I spotted a slow calculation of overviews and I'm wondering what could be
the reason.
$ gdal_create in.tif -if 20240602_230818_SN26_RR_VISUAL_MS.vrt
$ time gdaladdo -ro in.tif
gdaladdo -ro in.tif 4,25s user 6,23s system 34% cpu 30,623 total
But on the file of the same size and num of bands
14 matches
Mail list logo
