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

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

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

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: > >

[gdal-dev] Redundant band number in gdalinfo json

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

[gdal-dev] RAT appears at root level in gdalinfo json

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? __

[gdal-dev] Inconsistent noDataValue formatting in gdalinfo output

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

Re: [gdal-dev] vat.dbf is not listed by gdalinfo

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: > > $

[gdal-dev] vat.dbf is not listed by gdalinfo

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

Re: [gdal-dev] AutoCreateWarpedVRT changes Int16 raster to Int32

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

Re: [gdal-dev] AutoCreateWarpedVRT changes Int16 raster to Int32

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

Re: [gdal-dev] AutoCreateWarpedVRT changes Int16 raster to Int32

$ 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

[gdal-dev] AutoCreateWarpedVRT changes Int16 raster to Int32

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

Re: [gdal-dev] Discrepancy in utilizing overviews with gdalwarp

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

[gdal-dev] Discrepancy in utilizing overviews with gdalwarp

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

[gdal-dev] gdaladdo slowness for VRTs

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

Re: [gdal-dev] OAPIF Unexpected Content-Type

t-Type header. > > Le 01/06/2023 à 01:52, Denis Rykov a écrit : > > I'm getting "ERROR 1: Unexpected Content-Type: (null)" in the middle > > of the ogrinfo output. What does this mean? I can adjust server > > configuration but it is not clear which endpoint is

[gdal-dev] OAPIF Unexpected Content-Type

I'm getting "ERROR 1: Unexpected Content-Type: (null)" in the middle of the ogrinfo output. What does this mean? I can adjust server configuration but it is not clear which endpoint is failing because apart from that message everything seems to be working fine. $ ogrinfo OAPIF:http://localhost:808

Re: [gdal-dev] gdal.Warp behaves differently comparing to gdalwarp

ds_img.FlushCache() did the trick! On Fri, Aug 5, 2022 at 4:44 PM Denis Rykov wrote: > Hi, > > I would expect these 2 ways of running GDAL warp should produce the same > results. > > gdalwarp -t_srs EPSG:3857 \ > -te 558728 5789851 1242296 7544030 \ &

[gdal-dev] gdal.Warp behaves differently comparing to gdalwarp

Hi, I would expect these 2 ways of running GDAL warp should produce the same results. gdalwarp -t_srs EPSG:3857 \ -te 558728 5789851 1242296 7544030 \ -ts 500 500 \ "WMS: http://127.0.0.1:8080/api/resource/5840/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=test_ro

Re: [gdal-dev] Custom geometric transformation

: > Denis, > Le 05/12/2021 à 00:09, Denis Rykov a écrit : > > According to rasterio's documentation > <https://rasterio.readthedocs.io/en/latest/topics/reproject.html> > "reproject" is a geospatial-specific analog to SciPy’s geometric_transform > <https:/

[gdal-dev] Custom geometric transformation

According to rasterio's documentation "reproject" is a geospatial-specific analog to SciPy’s geometric_transform

Re: [gdal-dev] Is it possible to have an external Color Table definition for GeoTIFF rasters?

Thanks, Even! I've filed an issue: https://github.com/OSGeo/gdal/issues/4897 On Wed, Nov 24, 2021 at 11:57 AM Even Rouault wrote: > Denis, > > But the same approach (having a color table in external .aux.xml PAM file) > doesn't work for GeoTIFF rasters. According to the output of gdal_translate

[gdal-dev] Is it possible to have an external Color Table definition for GeoTIFF rasters?

For example it works in case of ASCII rasters: $ cat test.ascii.aux.xml Palette < Entry c1="1" c2="2" c3="3" c4="4" /> < Entry c1="3" c2="6" c3="9" c4="12" />4 1.75 0 1.4790199457749 $ gdalinfo test.ascii Driver: AAIGrid/Arc/Info ASCII Grid Files: test.ascii test.ascii.aux.xml Size i

Re: [gdal-dev] Resampling causes change of max value

ps your input_raster_to_resize_with_max_val_92.tiff file has a > .aux.xml with outdated stats (gdalinfo -stats doesn't regenerate stats if > already found) > > Even > Le 20/05/2021 à 21:42, Denis Rykov a écrit : > > $ gdalinfo -stats -json input_raster_to_

[gdal-dev] Resampling causes change of max value

$ gdalinfo -stats -json input_raster_to_resize_with_max_val_92.tiff | jq '.bands[0].metadata[""].STATISTICS_MAXIMUM' "92" $ gdal_translate -outsize 1% 1% input_raster_to_resize_with_max_val_92.tiff output.tif Input file size is 6845, 10302 0...10...20...30...40...50...60...70...80...90...100 - done

Re: [gdal-dev] RPC to geotransform converting

Finally I solved the issue by adding "-to RPC_HEIGHT=XXX" to gdalwarp. It seems gdalwarp doesn't take this parameter into account even if it is presented in the RPC *.txt file. Should I file the ticket or was it done by purpose? On Tue, May 18, 2021 at 11:26 PM Denis Rykov w

Re: [gdal-dev] RPC to geotransform converting

to get accurate results. > > Even > Le 18/05/2021 à 22:50, Denis Rykov a écrit : > > Hi, > > I have a GeoTIF file and file with RPC information next to it (*.txt). Is > there a way to transform this raster to a normal geotiff without > displacement (with geotransform inside)

[gdal-dev] RPC to geotransform converting

Hi, I have a GeoTIF file and file with RPC information next to it (*.txt). Is there a way to transform this raster to a normal geotiff without displacement (with geotransform inside) or is it fundamentally impossible? I've tried to achieve it with gdalwarp but in this case the result of the transf

Re: [gdal-dev] Overviews are not taken into account while reading with specified resampling method

buf_xsize=10, >>> buf_ysize=10, resample_alg=gdalconst.GRIORA_Cubic) >>> image.shape (3, 10, 10) On Thu, Aug 27, 2020 at 7:30 PM Denis Rykov wrote: > Hi Sean. I patched rasterio as you suggested and intermediate file now > looks like this (I'm trying now with a pu

Re: [gdal-dev] Overviews are not taken into account while reading with specified resampling method

could explain why GDAL behaves differently depending on resample_alg. On Thu, Aug 27, 2020 at 6:39 PM Sean Gillies wrote: > Hi Denis, Even, > > On Thu, Aug 27, 2020 at 8:08 AM Even Rouault > wrote: > >> On jeudi 27 août 2020 15:08:02 CEST Denis Rykov wrote: >> >

Re: [gdal-dev] Overviews are not taken into account while reading with specified resampling method

ing. Any ideas how to overcome that? On Thu, Aug 27, 2020 at 12:41 PM Denis Rykov wrote: > I was able to reproduce this issue with pure GDAL. When you read data with > boundless=True in rasterio it creates an intermediate VRT file. This is the > example of file that being c

Re: [gdal-dev] Overviews are not taken into account while reading with specified resampling method

earestNeighbour If I do the same but using resample_alg=gdalconst.GRIORA_Cubic then GDAL sends a huge amount of requests to the server (~1k) because overviews are not used: ds = gdal.OpenEx("/tmp/rasterio.vrt") image = ds.ReadAsArray(xoff=0, yoff=0, xsize=5671, ysize=5648, buf_xsize=383

[gdal-dev] Overviews are not taken into account while reading with specified resampling method

I have remote *.vrt raster and *.vrt.ovr accessible through HTTP. When I run the following script with rasterio: with rasterio.open("http://*.vrt"";) as src: image = src.read(indexes=[1, 2, 3], **{ "window": Window(col_off=6961, row_off=105176, width=5671, height=5648), "resamp

[gdal-dev] Rotate raster

Hi! Is there a way to rotate raster (physically as gdalwarp does) around its center and reflect this rotation in Affine GeoTransform? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Setting up a source resolution for TMS

14 PM Even Rouault wrote: > On vendredi 15 mai 2020 19:23:30 CEST Denis Rykov wrote: > > > Hello, > > > > > > I'm using gdal_translate to convert a certain area of TMS service (WMS > > > driver) to GeoTIFF. Is there a way to set up a zoom level for GD

[gdal-dev] Setting up a source resolution for TMS

Hello, I'm using gdal_translate to convert a certain area of TMS service (WMS driver) to GeoTIFF. Is there a way to set up a zoom level for GDAL to be used for building an image? By now GDAL picks zoom level with closest resolution. For example, if I want to get image of 1 meter resolution ( "-tr

Re: [gdal-dev] Storing mask as part of the *.ovr file

Thanks! Could you please explain the meaning of INTERNAL_MASK_FLAGS_1=2? I couldn't find it in the documentation. On Thu, Apr 23, 2020, 12:44 AM Even Rouault wrote: > > But if I do: > > > > > > gdal_translate rgbmask.vrt rgb_with_external_msk.vrt -mask none -b 1 -b > > > 2 -b 3 -of VRT > > > > I

Re: [gdal-dev] Storing mask as part of the *.ovr file

askBand 2) Each VRTRasterBand has many SimpleSource elements with various DstRect. So it seems if we don't tell to GDAL not to use mask it copies it by default. But why the structure of VRTRasterBand is different? On Wed, Apr 22, 2020 at 12:09 PM Even Rouault wrote: > On mardi 21 avril 2

[gdal-dev] Storing mask as part of the *.ovr file

Hello, I'm using *.vrt file that is built atop of COG rasters with internal mask (PER_DATASET) + external overview file *.vrt.ovr. These files are stored on Azure Blob Storage and I get access to them using /vsiaz scheme. I've found out that when I read data from this VRT GDAL does few requests to

Re: [gdal-dev] gdal_translate is slow

Thanks guys for clarification! On Wed, Sep 4, 2019, 5:53 PM Even Rouault wrote: > On mercredi 4 septembre 2019 17:26:14 CEST Denis Rykov wrote: > > Thanks for quick reply, I've uploaded grib file here: > > https://transfer.sh/5JCVX/download.grib > > Turns out that my

Re: [gdal-dev] gdal_translate is slow

Thanks for quick reply, I've uploaded grib file here: https://transfer.sh/5JCVX/download.grib On Wed, Sep 4, 2019 at 5:04 PM Even Rouault wrote: > On mercredi 4 septembre 2019 08:50:09 CEST Sean Gillies wrote: > > Hi Denis, > > > > rio-convert lacks some of the features of gdal_translate (advanc

[gdal-dev] gdal_translate is slow

Why gdal_translate so slow compared to rio translate from rasterio? rio convert: $ time rio convert download.grib download.tif Warning: Inside GRIB2Inventory, Message # 15 ERROR: Ran out of file reading SECT0 Warning: Inside GRIB2Inventory, Message # 15 ERROR: Ran out of file reading SECT0 rio co

Re: [gdal-dev] Using pseudo-field FID as ID_FIELD for GeoJSON

Thanks, that did the trick! On Thu, Jun 13, 2019 at 9:31 AM jratike80 < jukka.rahko...@maanmittauslaitos.fi> wrote: > Hi, > > Have you tried "-preserve_fid" > https://gdal.org/programs/ogr2ogr.html#ogr2ogr ? > > -Jukka Rahkonen- > > > dr wrote > > Is it possible to reflect fids values of features

[gdal-dev] Using pseudo-field FID as ID_FIELD for GeoJSON

Is it possible to reflect fids values of features of original layer while exporting it to GeoJSON? Usage of "-lco ID_FIELD=FID" doesn't help. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Error of reading data stored on NFS

$ gdal_translate /scratch/abel/UPM000_PILO00/DATA_SOURCES/raw_data/IMG_rebrotes_Guaviyu_191218.tif output.tif Input file size is 60613, 75538 0...10...20...30...40...50...60...70...80...90...ERROR 1: _tiffSeekProc:Invalid argument ERROR 1: TIFFFillTile:Seek error at row 45440, col 75392, tile 27954

Re: [gdal-dev] Having overview URL inside VRT

bre 2018 23:18:05 CEST Denis Rykov wrote: > > Hi all, > > > > I know that it possible using GDAL VRT describe overviews with > > tag. > > But it is not very convenient way in many cases. I'm wondering whether it > > is possible to put a link to overview *.ovr

[gdal-dev] Having overview URL inside VRT

Hi all, I know that it possible using GDAL VRT describe overviews with tag. But it is not very convenient way in many cases. I'm wondering whether it is possible to put a link to overview *.ovr file inside a VRT? In some scenarios we cannot use a relative path and assumption that *.ovr should be

[gdal-dev] Create dummy internal mask

Hi, I need to add dummy internal mask to 1-band GeoTIFF for further processing. The drawback of the following approach is that it mask legitimate 0 pixels: gdal_translate --config GDAL_TIFF_INTERNAL_MASK YES -mask 1 nomask.tif > mask.tif The workaround to come over this issue looks like: gdal_

Re: [gdal-dev] gdalwarp and internal transparency masks

Even, thanks for the answer. I have filed an issue at GitHub to track the possible progress on this task: https://github.com/OSGeo/gdal/issues/794 On Sat, Jul 21, 2018 at 11:17 PM, Even Rouault wrote: > On samedi 21 juillet 2018 19:40:54 CEST Denis Rykov wrote: > > Hi, > > >

[gdal-dev] gdalwarp and internal transparency masks

Hi, I have a GeoTIFF raster with internal mask. Is it possible to retain this mask while warping? Mask is not retained now: $ gdalinfo -json original.tif | jq .bands [ { "band": 1, "block": [ 3, 2 ], "type": "Byte", "colorInterpretation": "Gray", "mask": {

[gdal-dev] How to set layer name in SQL query?

When I perform the following command: $ ogrinfo -dialect SQLITE -sql "SELECT COUNT(*) summary FROM Export_Output_4" Export_Output_4.shp I get result: INFO: Open of `Export_Output_4.shp' using driver `ESRI Shapefile' successful. Layer name: SELECT Geometry: None Feature Count: 1 Layer SRS

[gdal-dev] Export HDF-EOS to GeoTIFF

I'm trying export raster from HDF-EOS to GeoTIFF. At result I have GeoTiff with 143 numbers of GCP. There are some thousands GCP at HDF-EOS geolocation SDS. Is OGR drivers support only 143 GCP? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lis

[gdal-dev] Gdal_merge

Hi! I need merge two images - the first image is mutiband and second image is singleband. Can I do this operation with gdal_merge or gdal_merge works only with images with same number of bands? What utility from gdal library I can use for separate multiband image into some singleband images? Thanks