From yosh-git at riseup.net Sat Nov 1 16:46:19 2025 From: yosh-git at riseup.net (yosh) Date: Sat, 01 Nov 2025 23:46:19 +0000 Subject: [gdal-dev] Slightly-off failing tests on i686 In-Reply-To: References: Message-ID: > we do have a CI configuration for i386 using clang in debug mode. Maybe > your use of gcc in -O2 yields to slightly different results in some cases. After encountering some wild GCC results when adding -ffloat-store, I switched C(C|XX) to clang and it fared much better on almost all fronts. Thanks for that! Alas, there seems to be three remaining problems I'm encountering on i686 tests: 1. There's a few lingering multithreaded tiff test fails: - test_tiff_read_multi_threaded[False-False-100-100-3-1-creation_options11] - test_tiff_read_multi_threaded[False-False-100-100-3-1-creation_options12] 2. During test_tiff_write_17, a zombie `stat` process gets forked and lingers, locking up the test suite until I kill the `pytest` process. If I edit the target to use "-vv" on pytest, it /doesn't/ lock up the test, but rather it fails from a vague "MemoryError". This test isn't skipped by the SKIP_MEM_INTENSIVE_TEST environment variable (which I'm already setting to "YES") 3. Two asserts in gdrivers/test_gpkg_26 are off by a factor of 2. It's quite strange. Here's a debug log: https://0x0.st/KLSG.log Any ideas on what might be happening? yosh (P.S. apologies for the double-email; forgot to :reply -a in aerc for the mailing list x.x) From yosh-git at riseup.net Sat Nov 1 16:50:11 2025 From: yosh-git at riseup.net (yosh) Date: Sat, 01 Nov 2025 23:50:11 +0000 Subject: [gdal-dev] Slightly-off failing tests on i686 In-Reply-To: References: Message-ID: > we do have a CI configuration for i386 using clang in debug mode. Maybe > your use of gcc in -O2 yields to slightly different results in some cases. After encountering some wild GCC results when adding -ffloat-store, I switched C(C|XX) to clang and it fared much better on almost all fronts. Thanks for that! Alas, there seems to be three remaining problems I'm encountering on i686 tests: 1. There's a few lingering multithreaded tiff test fails: - test_tiff_read_multi_threaded[False-False-100-100-3-1-creation_options11] - test_tiff_read_multi_threaded[False-False-100-100-3-1-creation_options12] 2. During test_tiff_write_17, a zombie `stat` process gets forked and lingers, locking up the test suite until I kill the `pytest` process. If I edit the target to use "-vv" on pytest, it /doesn't/ lock up the test, but rather it fails from a vague "MemoryError". This test isn't skipped by the SKIP_MEM_INTENSIVE_TEST environment variable (which I'm already setting to "YES") 3. Two asserts in gdrivers/test_gpkg_26 are off by a factor of 2. It's quite strange. Here's a debug log: https://0x0.st/KLSG.log Any ideas on what might be happening? yosh (P.S. apologies for the double-email even; forgot to :reply -a in aerc for the mailing list x.x) From n_larsson at yahoo.com Sun Nov 2 11:14:11 2025 From: n_larsson at yahoo.com (Nicklas Larsson) Date: Sun, 2 Nov 2025 20:14:11 +0100 Subject: [gdal-dev] GDAL-GRASS driver 2.0.0 release candidate released References: <9BDF1429-470F-4C73-9CB8-0F6C680BF192.ref@yahoo.com> Message-ID: <9BDF1429-470F-4C73-9CB8-0F6C680BF192@yahoo.com> The GDAL-GRASS driver 2.0.0rc1 release provides more than 15 improvements and fixes with respect to the release 1.0.4. Notable changes include added support for GDAL 3.12 and removed support for Autotools build system. Special note for packagers: the bump of GDAL-GRASS to version 2.x introduces the potential of version conflicts from the era when the driver was part of GDAL core. Please take appropriate action to prevent that from happening. ## What's Changed ### Libraries and General Functionality * Adapt GetGeoTransform() method for GDAL 3.12 change, and avoid use of deprecated GDALGetDataTypeSize() functions (#67) by @rouault * Fix const correctness of virtual methods for GDAL 3.12 (#70) by @rouault * C++: modernize code (#37) by @nilason ### Documentation and Messages * docs: Add license file and use SPDX identifiers (#55) by @nilason ### Packaging, Configuration, Portability, and Compilation * cmake: replace deprecated 'exec_program' (#73) by @nilason * config: remove autoconf support (#56) by @nilason ### Continuous Integration, Tests, Code Quality, and Checks * checks: add pre-commit configuration file (#58) by @nilason ### Other Changes * Move source files to 'source' directory (#60) by @nilason * style: fix issues reported by pre-commit (#59) by @nilason **Full Changelog**: https://github.com/OSGeo/gdal-grass/compare/1.0.4...2.0.0rc1 The release can be downloaded from: https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0rc1.tar.gz https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0rc1.tar.gz.md5 https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0rc1.tar.gz.sha256 From j1 at jimenezshaw.com Mon Nov 3 01:13:22 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 3 Nov 2025 10:13:22 +0100 Subject: [gdal-dev] Not writing PAM files Message-ID: Hi When I read some raster files (in particular thermal JPEG files), a side car file .aux.xml appears next to it. I would like to avoid the creation of this side car file, but I want to use any .aux.xml file if it is already there. Yes, I could imagine there is a performance impact if I read it several times, but I am going to read the file only once. The config option GDAL_PAM_ENABLED seems to be completely disabling PAM functionality: https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options Reading the documentation, I would imagine that the PAM is completely disabled, not only the creation of the side car file while reading a raster. Is it posible to not create the .aux.xml, but use it if present? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard at hobu.co Mon Nov 3 03:38:02 2025 From: howard at hobu.co (Howard Butler) Date: Mon, 3 Nov 2025 05:38:02 -0600 Subject: [gdal-dev] GDAL Maintainers Meeting Minutes Message-ID: <9D3AD1AC-808B-4CF4-A0C3-234D1C95028A@hobu.co> Howard Butler, Dan Baston, Alessandro Pasotti, Michael Sumner, Even Rouault, Mike Smith, Chris Toney, and Javier Jimenez Shaw held the monthly GDAL Maintainers Meeting on 10/23/2025. The following items were discussed and reported upon: Project News ---------------------------- * A new GDAL tshirt is now available! Visit https://numfocus.myspreadshop.com/gdal+t+shirt-A68deb7db164d8905c4c1035f?productType=1130&sellable=9OeE7gVexMimlaxo9RDB-1130-7&appearance=743 and then make sure to navigate to the bottom of the page and change your country appropriately. Profits from sales go directly to the GDAL Sponsorship Program via NumFOCUS! Design and inspiration comes from Lindsey Nield observing that "Every new geospatial tool is just GDAL in a trench coat" https://www.linkedin.com/feed/update/urn:li:activity:7384648716357574656 * If you like LinkedIn-flavored social media, GDAL now has an organization page https://www.linkedin.com/company/gdalorg/ Maintenance activities update ------------------------------------------ Alessandro * PR review activity Dan * gdal raster zonal-stats CLI finalization https://gdal.org/en/latest/programs/gdal_raster_zonal_stats.html * gdal vector make-point https://gdal.org/en/latest/programs/gdal_vector_make_point.html * Riga sprint work with Seth Girvin on SWIG function signature documentation and graphics for docs * FOSS4GNA presentation preparation. See him this week in Reston, VA! https://talks.osgeo.org/foss4g-na-2025/talk/FLUEPT/ Even * GDAL 3.12.0b1 release. See upcoming release notes at https://github.com/OSGeo/gdal/blob/v3.12.0beta1/NEWS.md * 60+ PRs and tickets * GDAL 3.11.5 release preparation * gdal raster mdim mosaic https://gdal.org/en/latest/programs/gdal_mdim_mosaic.html * Collaborated with Ognyan Moore of Hobu, Inc. in Riga to automate GDAL (and PROJ) release artifact generation process with GitHub Actions. Features include GitHub Attestations, GPG signing, container build array population at https://github.com/OSGeo/gdal/pkgs/container/gdal, and container metadata pass-through * RAT storage in GeoTIFFs https://github.com/OSGeo/gdal/pull/13201 * PROJ EPSG updates to v12.033, v12.036, and v12.039 * Zarr summit participation, including defining and implementing geo definitions prototype for GDAL https://github.com/OSGeo/gdal/pull/13215 Javier * Riga attendance The next GDAL Maintainers Meeting is 11/27/2025 at 13:00 UTC. GDAL PSC members and Pull Request contributors are welcome to contact me for an invite. Howard https://gist.github.com/hobu/3193be3a8027d24d987d42e7eeb432fc From dklaus at carlsonsw.com Mon Nov 3 05:44:44 2025 From: dklaus at carlsonsw.com (David Klaus) Date: Mon, 3 Nov 2025 08:44:44 -0500 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Hi Javier, I'm not sure if this applies to your use case, but I ran into a similar issue embedding geolocation information in PDF files. Sidecar files were created, but the geolocation data wasn?t embedded directly in the PDF. At my company, we use the C++ GDAL API, and I was able to resolve it by opening the GDALDataset with the GDALAccess::GA_Update flag. As for whether GDAL reads sidecar files when present?I believe it does, but I'm not entirely certain, so I?ll defer to others on that point. Hope this helps, On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi > > When I read some raster files (in particular thermal JPEG files), a side > car file .aux.xml appears next to it. > > I would like to avoid the creation of this side car file, but I want to > use any .aux.xml file if it is already there. Yes, I could imagine there is > a performance impact if I read it several times, but I am going to read the > file only once. > > The config option GDAL_PAM_ENABLED seems to be completely disabling PAM > functionality: > > https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options > > Reading the documentation, I would imagine that the PAM is completely > disabled, not only the creation of the side car file while reading a raster. > > Is it posible to not create the .aux.xml, but use it if present? > > Thank you > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Mon Nov 3 06:12:30 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 3 Nov 2025 15:12:30 +0100 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Thank you David. Unfortunately I don't want to (a.k.a. cannot) change the original files. I don't want to write any type of file in that directory (like the .aux.xml files). (note: I am opening the files in C++ with GDALOpenEx) On Mon, 3 Nov 2025 at 14:45, David Klaus wrote: > Hi Javier, > > I'm not sure if this applies to your use case, but I ran into a similar > issue embedding geolocation information in PDF files. Sidecar files were > created, but the geolocation data wasn?t embedded directly in the PDF. > > At my company, we use the C++ GDAL API, and I was able to resolve it by > opening the GDALDataset with the GDALAccess::GA_Update flag. > > As for whether GDAL reads sidecar files when present?I believe it does, > but I'm not entirely certain, so I?ll defer to others on that point. > > Hope this helps, > > > On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi >> >> When I read some raster files (in particular thermal JPEG files), a side >> car file .aux.xml appears next to it. >> >> I would like to avoid the creation of this side car file, but I want to >> use any .aux.xml file if it is already there. Yes, I could imagine there is >> a performance impact if I read it several times, but I am going to read the >> file only once. >> >> The config option GDAL_PAM_ENABLED seems to be completely disabling PAM >> functionality: >> >> https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options >> Reading the documentation, I would imagine that the PAM is completely >> disabled, not only the creation of the side car file while reading a raster. >> >> Is it posible to not create the .aux.xml, but use it if present? >> >> Thank you >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > -- > David Klaus > Carlson Software > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dklaus at carlsonsw.com Mon Nov 3 06:19:46 2025 From: dklaus at carlsonsw.com (David Klaus) Date: Mon, 3 Nov 2025 09:19:46 -0500 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Javier, That is strange. I could be wrong and maybe someone can weigh in if I am. But, I believe that aux files are created when you try to write information about or into the file that can't be stored within the file (for one reason or another). Are you trying to generate information about the file? Perhaps a code snippet would help everyone identify the issue? On Mon, Nov 3, 2025 at 9:12?AM Javier Jimenez Shaw wrote: > Thank you David. > > Unfortunately I don't want to (a.k.a. cannot) change the original files. I > don't want to write any type of file in that directory (like the .aux.xml > files). > > (note: I am opening the files in C++ with GDALOpenEx) > > > On Mon, 3 Nov 2025 at 14:45, David Klaus wrote: > >> Hi Javier, >> >> I'm not sure if this applies to your use case, but I ran into a similar >> issue embedding geolocation information in PDF files. Sidecar files were >> created, but the geolocation data wasn?t embedded directly in the PDF. >> >> At my company, we use the C++ GDAL API, and I was able to resolve it by >> opening the GDALDataset with the GDALAccess::GA_Update flag. >> >> As for whether GDAL reads sidecar files when present?I believe it does, >> but I'm not entirely certain, so I?ll defer to others on that point. >> >> Hope this helps, >> >> >> On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < >> gdal-dev at lists.osgeo.org> wrote: >> >>> Hi >>> >>> When I read some raster files (in particular thermal JPEG files), a side >>> car file .aux.xml appears next to it. >>> >>> I would like to avoid the creation of this side car file, but I want to >>> use any .aux.xml file if it is already there. Yes, I could imagine there is >>> a performance impact if I read it several times, but I am going to read the >>> file only once. >>> >>> The config option GDAL_PAM_ENABLED seems to be completely disabling PAM >>> functionality: >>> >>> https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options >>> >>> Reading the documentation, I would imagine that the PAM is completely >>> disabled, not only the creation of the side car file while reading a raster. >>> >>> Is it posible to not create the .aux.xml, but use it if present? >>> >>> Thank you >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >> >> >> -- >> David Klaus >> Carlson Software >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> > -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fred.evans at gmail.com Mon Nov 3 06:26:28 2025 From: daniel.fred.evans at gmail.com (Daniel Evans) Date: Mon, 3 Nov 2025 14:26:28 +0000 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Hi David, I'm familiar with the sort of behaviour Javier mentions from using QGIS. Opening some file formats in read-only mode in QGIS (at least, I assume that's what QGIS defaults to if I just view a raster!) will cause "nuisance" .aux.xml sidecar files to be written with band statistics. Cheers, Daniel On Mon, 3 Nov 2025, 14:20 David Klaus via gdal-dev, < gdal-dev at lists.osgeo.org> wrote: > Javier, > > That is strange. I could be wrong and maybe someone can weigh in if I am. > But, I believe that aux files are created when you try to write information > about or into the file that can't be stored within the file (for one reason > or another). Are you trying to generate information about the file? Perhaps > a code snippet would help everyone identify the issue? > > On Mon, Nov 3, 2025 at 9:12?AM Javier Jimenez Shaw > wrote: > >> Thank you David. >> >> Unfortunately I don't want to (a.k.a. cannot) change the original files. >> I don't want to write any type of file in that directory (like the .aux.xml >> files). >> >> (note: I am opening the files in C++ with GDALOpenEx) >> >> >> On Mon, 3 Nov 2025 at 14:45, David Klaus wrote: >> >>> Hi Javier, >>> >>> I'm not sure if this applies to your use case, but I ran into a similar >>> issue embedding geolocation information in PDF files. Sidecar files were >>> created, but the geolocation data wasn?t embedded directly in the PDF. >>> >>> At my company, we use the C++ GDAL API, and I was able to resolve it by >>> opening the GDALDataset with the GDALAccess::GA_Update flag. >>> >>> As for whether GDAL reads sidecar files when present?I believe it does, >>> but I'm not entirely certain, so I?ll defer to others on that point. >>> >>> Hope this helps, >>> >>> >>> On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < >>> gdal-dev at lists.osgeo.org> wrote: >>> >>>> Hi >>>> >>>> When I read some raster files (in particular thermal JPEG files), a >>>> side car file .aux.xml appears next to it. >>>> >>>> I would like to avoid the creation of this side car file, but I want to >>>> use any .aux.xml file if it is already there. Yes, I could imagine there is >>>> a performance impact if I read it several times, but I am going to read the >>>> file only once. >>>> >>>> The config option GDAL_PAM_ENABLED seems to be completely disabling PAM >>>> functionality: >>>> >>>> https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options >>>> Reading the documentation, I would imagine that the PAM is completely >>>> disabled, not only the creation of the side car file while reading a raster. >>>> >>>> Is it posible to not create the .aux.xml, but use it if present? >>>> >>>> Thank you >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev at lists.osgeo.org >>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>>> >>> >>> >>> -- >>> David Klaus >>> Carlson Software >>> >>> >>> *Disclaimer* >>> >>> The information contained in this communication from the sender is >>> confidential. It is intended solely for use by the recipient and others >>> authorized to receive it. If you are not the recipient, you are hereby >>> notified that any disclosure, copying, distribution or taking action in >>> relation of the contents of this information is strictly prohibited and may >>> be unlawful. >>> >> > > -- > David Klaus > Carlson Software > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dklaus at carlsonsw.com Mon Nov 3 06:35:31 2025 From: dklaus at carlsonsw.com (David Klaus) Date: Mon, 3 Nov 2025 09:35:31 -0500 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Daniel, Thank you for that information. Javier, sorry I misled you. Is there a way to stop the production of these sidecar files? On Mon, Nov 3, 2025 at 9:26?AM Daniel Evans wrote: > Hi David, > > I'm familiar with the sort of behaviour Javier mentions from using QGIS. > Opening some file formats in read-only mode in QGIS (at least, I assume > that's what QGIS defaults to if I just view a raster!) will cause > "nuisance" .aux.xml sidecar files to be written with band statistics. > > Cheers, > Daniel > > On Mon, 3 Nov 2025, 14:20 David Klaus via gdal-dev, < > gdal-dev at lists.osgeo.org> wrote: > >> Javier, >> >> That is strange. I could be wrong and maybe someone can weigh in if I am. >> But, I believe that aux files are created when you try to write information >> about or into the file that can't be stored within the file (for one reason >> or another). Are you trying to generate information about the file? Perhaps >> a code snippet would help everyone identify the issue? >> >> On Mon, Nov 3, 2025 at 9:12?AM Javier Jimenez Shaw >> wrote: >> >>> Thank you David. >>> >>> Unfortunately I don't want to (a.k.a. cannot) change the original files. >>> I don't want to write any type of file in that directory (like the .aux.xml >>> files). >>> >>> (note: I am opening the files in C++ with GDALOpenEx) >>> >>> >>> On Mon, 3 Nov 2025 at 14:45, David Klaus wrote: >>> >>>> Hi Javier, >>>> >>>> I'm not sure if this applies to your use case, but I ran into a similar >>>> issue embedding geolocation information in PDF files. Sidecar files were >>>> created, but the geolocation data wasn?t embedded directly in the PDF. >>>> >>>> At my company, we use the C++ GDAL API, and I was able to resolve it by >>>> opening the GDALDataset with the GDALAccess::GA_Update flag. >>>> >>>> As for whether GDAL reads sidecar files when present?I believe it does, >>>> but I'm not entirely certain, so I?ll defer to others on that point. >>>> >>>> Hope this helps, >>>> >>>> >>>> On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < >>>> gdal-dev at lists.osgeo.org> wrote: >>>> >>>>> Hi >>>>> >>>>> When I read some raster files (in particular thermal JPEG files), a >>>>> side car file .aux.xml appears next to it. >>>>> >>>>> I would like to avoid the creation of this side car file, but I want >>>>> to use any .aux.xml file if it is already there. Yes, I could imagine there >>>>> is a performance impact if I read it several times, but I am going to read >>>>> the file only once. >>>>> >>>>> The config option GDAL_PAM_ENABLED seems to be completely disabling >>>>> PAM functionality: >>>>> >>>>> https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options >>>>> >>>>> Reading the documentation, I would imagine that the PAM is completely >>>>> disabled, not only the creation of the side car file while reading a raster. >>>>> >>>>> Is it posible to not create the .aux.xml, but use it if present? >>>>> >>>>> Thank you >>>>> _______________________________________________ >>>>> gdal-dev mailing list >>>>> gdal-dev at lists.osgeo.org >>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Klaus >>>> Carlson Software >>>> >>>> >>>> *Disclaimer* >>>> >>>> The information contained in this communication from the sender is >>>> confidential. It is intended solely for use by the recipient and others >>>> authorized to receive it. If you are not the recipient, you are hereby >>>> notified that any disclosure, copying, distribution or taking action in >>>> relation of the contents of this information is strictly prohibited and may >>>> be unlawful. >>>> >>> >> >> -- >> David Klaus >> Carlson Software >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> > -- David Klaus Carlson Software Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Mon Nov 3 07:47:00 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 3 Nov 2025 16:47:00 +0100 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: Sorry. Maybe I didn't explain myself very well. I am trying to open raster files just for reading. I don't want to modify them, or add any file to the directory. (It is not blocked by the operating system; we just don't want to modify user's data folder). It was the case, until we are reading thermal files like the one in the tests: data/jpeg/dji/DJI_M3T.JPG In that case the side car file appears. Probably due to some code in the Thermal management like SetMetadataItem("RawThermalImageWidth",... that is calling "PamInitialize()" Notice that we don't know in advance the type of file. They are just JPG files in a folder that we have to read. We want to avoid to create side car files, but we want to read them if the user created them (not us). Looking at gcore/gdalpamdataset.cpp, I can see in "GDALPamDataset::PamInitialize" if (!CPLTestBool(CPLGetConfigOption("GDAL_PAM_ENABLED", pszPamDefault))) { CPLDebugOnce("GDAL", "PAM is disabled"); nPamFlags |= GPF_DISABLED; } and later in "GDALPamDataset::TryLoadXML" it checks it: if (psPam == nullptr || (nPamFlags & GPF_DISABLED) != 0) return CE_None; So I guess that GDAL_PAM_ENABLED is not only blocking the creation of the side car file, but also reading it. Is there a way to get this with the current state of GDAL? Cheers Javier. On Mon, 3 Nov 2025 at 15:26, Daniel Evans wrote: > Hi David, > > I'm familiar with the sort of behaviour Javier mentions from using QGIS. > Opening some file formats in read-only mode in QGIS (at least, I assume > that's what QGIS defaults to if I just view a raster!) will cause > "nuisance" .aux.xml sidecar files to be written with band statistics. > > Cheers, > Daniel > > On Mon, 3 Nov 2025, 14:20 David Klaus via gdal-dev, < > gdal-dev at lists.osgeo.org> wrote: > >> Javier, >> >> That is strange. I could be wrong and maybe someone can weigh in if I am. >> But, I believe that aux files are created when you try to write information >> about or into the file that can't be stored within the file (for one reason >> or another). Are you trying to generate information about the file? Perhaps >> a code snippet would help everyone identify the issue? >> >> On Mon, Nov 3, 2025 at 9:12?AM Javier Jimenez Shaw >> wrote: >> >>> Thank you David. >>> >>> Unfortunately I don't want to (a.k.a. cannot) change the original files. >>> I don't want to write any type of file in that directory (like the .aux.xml >>> files). >>> >>> (note: I am opening the files in C++ with GDALOpenEx) >>> >>> >>> On Mon, 3 Nov 2025 at 14:45, David Klaus wrote: >>> >>>> Hi Javier, >>>> >>>> I'm not sure if this applies to your use case, but I ran into a similar >>>> issue embedding geolocation information in PDF files. Sidecar files were >>>> created, but the geolocation data wasn?t embedded directly in the PDF. >>>> >>>> At my company, we use the C++ GDAL API, and I was able to resolve it by >>>> opening the GDALDataset with the GDALAccess::GA_Update flag. >>>> >>>> As for whether GDAL reads sidecar files when present?I believe it does, >>>> but I'm not entirely certain, so I?ll defer to others on that point. >>>> >>>> Hope this helps, >>>> >>>> >>>> On Mon, Nov 3, 2025 at 4:13?AM Javier Jimenez Shaw via gdal-dev < >>>> gdal-dev at lists.osgeo.org> wrote: >>>> >>>>> Hi >>>>> >>>>> When I read some raster files (in particular thermal JPEG files), a >>>>> side car file .aux.xml appears next to it. >>>>> >>>>> I would like to avoid the creation of this side car file, but I want >>>>> to use any .aux.xml file if it is already there. Yes, I could imagine there >>>>> is a performance impact if I read it several times, but I am going to read >>>>> the file only once. >>>>> >>>>> The config option GDAL_PAM_ENABLED seems to be completely disabling >>>>> PAM functionality: >>>>> >>>>> https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options >>>>> Reading the documentation, I would imagine that the PAM is completely >>>>> disabled, not only the creation of the side car file while reading a raster. >>>>> >>>>> Is it posible to not create the .aux.xml, but use it if present? >>>>> >>>>> Thank you >>>>> _______________________________________________ >>>>> gdal-dev mailing list >>>>> gdal-dev at lists.osgeo.org >>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>>>> >>>> >>>> >>>> -- >>>> David Klaus >>>> Carlson Software >>>> >>>> >>>> *Disclaimer* >>>> >>>> The information contained in this communication from the sender is >>>> confidential. It is intended solely for use by the recipient and others >>>> authorized to receive it. If you are not the recipient, you are hereby >>>> notified that any disclosure, copying, distribution or taking action in >>>> relation of the contents of this information is strictly prohibited and may >>>> be unlawful. >>>> >>> >> >> -- >> David Klaus >> Carlson Software >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Mon Nov 3 08:04:50 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 3 Nov 2025 17:04:50 +0100 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: <62724577-6cff-4087-80d1-1d8c106791a3@spatialys.com> Hi Javier, .aux.xml file is no longer generated on opening per https://github.com/OSGeo/gdal/commit/2ad4ebf4ddcaa74af2d4cea212fb61f0ac382f20 Even Le 03/11/2025 ? 10:13, Javier Jimenez Shaw via gdal-dev a ?crit?: > Hi > > When I read some raster files (in particular thermal JPEG files), a > side car file .aux.xml appears next to it. > > I would like to avoid the creation of this side car file, but I want > to use any .aux.xml file if it is already there. Yes, I could imagine > there is a performance impact if I read it several times, but I am > going to read the file only once. > > The config option?GDAL_PAM_ENABLED seems to be?completely disabling > PAM functionality: > https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options > Reading the documentation, I would imagine that the PAM is completely > disabled, not only the creation of the side car file while reading a > raster. > > Is it posible to not create the .aux.xml, but use it if present? > > Thank you > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Mon Nov 3 08:08:47 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Mon, 3 Nov 2025 17:08:47 +0100 Subject: [gdal-dev] Not writing PAM files In-Reply-To: <62724577-6cff-4087-80d1-1d8c106791a3@spatialys.com> References: <62724577-6cff-4087-80d1-1d8c106791a3@spatialys.com> Message-ID: Thank you Even! Probably the same is needed for FLIR, as DJI logic was based in FLIR code also in jpgdataset.cpp On Mon, 3 Nov 2025 at 17:04, Even Rouault wrote: > Hi Javier, > > .aux.xml file is no longer generated on opening per > > https://github.com/OSGeo/gdal/commit/2ad4ebf4ddcaa74af2d4cea212fb61f0ac382f20 > > Even > > Le 03/11/2025 ? 10:13, Javier Jimenez Shaw via gdal-dev a ?crit : > > Hi > > > > When I read some raster files (in particular thermal JPEG files), a > > side car file .aux.xml appears next to it. > > > > I would like to avoid the creation of this side car file, but I want > > to use any .aux.xml file if it is already there. Yes, I could imagine > > there is a performance impact if I read it several times, but I am > > going to read the file only once. > > > > The config option GDAL_PAM_ENABLED seems to be completely disabling > > PAM functionality: > > > https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options > > Reading the documentation, I would imagine that the PAM is completely > > disabled, not only the creation of the side car file while reading a > > raster. > > > > Is it posible to not create the .aux.xml, but use it if present? > > > > Thank you > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at aitchison.me.uk Mon Nov 3 08:14:44 2025 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Mon, 3 Nov 2025 16:14:44 +0000 (GMT) Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025, Javier Jimenez Shaw via gdal-dev wrote: > Hi > > When I read some raster files (in particular thermal JPEG files), a side > car file .aux.xml appears next to it. > > I would like to avoid the creation of this side car file, but I want to use > any .aux.xml file if it is already there. Yes, I could imagine there is a > performance impact if I read it several times, but I am going to read the > file only once. > > The config option GDAL_PAM_ENABLED seems to be completely disabling PAM > functionality: > https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options > Reading the documentation, I would imagine that the PAM is completely > disabled, not only the creation of the side car file while reading a raster. > > Is it posible to not create the .aux.xml, but use it if present? I see that Even has just added a patch specifically for dji images. in general, one other option might be to not give the running process write permission on the directory (perhaps with a read-only (re)mount) ? -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From even.rouault at spatialys.com Mon Nov 3 08:19:19 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 3 Nov 2025 17:19:19 +0100 Subject: [gdal-dev] Not writing PAM files In-Reply-To: References: <62724577-6cff-4087-80d1-1d8c106791a3@spatialys.com> Message-ID: FLIR should be fined. It has a "PamFlagKeeper oKeeper(nPamFlags);" guard that makes sure to restore the PAM flags to its initial value after metadata has been set Le 03/11/2025 ? 17:08, Javier Jimenez Shaw a ?crit?: > Thank you Even! > > Probably the same is needed for FLIR, as DJI logic was based in FLIR > code also in?jpgdataset.cpp > > On Mon, 3 Nov 2025 at 17:04, Even Rouault > wrote: > > Hi Javier, > > .aux.xml file is no longer generated on opening per > https://github.com/OSGeo/gdal/commit/2ad4ebf4ddcaa74af2d4cea212fb61f0ac382f20 > > Even > > Le 03/11/2025 ? 10:13, Javier Jimenez Shaw via gdal-dev a ?crit?: > > Hi > > > > When I read some raster files (in particular thermal JPEG files), a > > side car file .aux.xml appears next to it. > > > > I would like to avoid the creation of this side car file, but I > want > > to use any .aux.xml file if it is already there. Yes, I could > imagine > > there is a performance impact if I read it several times, but I am > > going to read the file only once. > > > > The config option?GDAL_PAM_ENABLED seems to be?completely disabling > > PAM functionality: > > > https://gdal.org/en/stable/user/configoptions.html#persistent-auxiliary-metadata-pam-options > > Reading the documentation, I would imagine that the PAM is > completely > > disabled, not only the creation of the side car file while > reading a > > raster. > > > > Is it posible to not create the .aux.xml, but use it if present? > > > > Thank you > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From twishamishra256 at gmail.com Mon Nov 3 10:40:01 2025 From: twishamishra256 at gmail.com (Twisha Mishra) Date: Tue, 4 Nov 2025 00:10:01 +0530 Subject: [gdal-dev] Introduction to GDAL Mailing List Message-ID: Subject: Introduction - Aspiring Contributor to GDAL Hi everyone, I?m Twisha Mishra, a computer science undergraduate student from India. I recently joined the GDAL mailing list to start learning and contributing to open-source geospatial software, especially with the goal of applying for GSoC 2026 under OSGeo. I?m currently strengthening my fundamentals in HTML, CSS, and JavaScript, and I?m also learning Python to better understand GDAL?s ecosystem. My focus this month is to understand GIS concepts and explore how GDAL works with raster and vector data. I?m completely new to GIS and open-source, but I?m excited to learn, follow discussions here, and hopefully start contributing soon. Any beginner-friendly guidance or suggestions on where to start exploring issues or documentation would be greatly appreciated. Thank you for maintaining such an impactful project! Best regards, Twisha Mishra twishamishra256 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at postholer.com Mon Nov 3 11:08:36 2025 From: public at postholer.com (Scott) Date: Mon, 3 Nov 2025 11:08:36 -0800 Subject: [gdal-dev] Introduction to GDAL Mailing List In-Reply-To: References: Message-ID: <4245ba90-2b1c-4d8b-bc0a-a88e7732c943@postholer.com> Greetings Twisha! For GDAL, I'd encourage you to start with the documentation. Everything is there, commands and syntax, spatial formats, etc. https://gdal.org/en/stable/download.html#documentation In particular, look at the new GDAL CLI commands, as this is the new direction for GDAL CLI, as opposed to the tried and true GDAL 'programs'. GDAL CLI will allow you to work directly with your data, no Arc, no python, no unnecessary intermediate baggage. The power of this cannot be understated. Specific docs for GDAL CLI: https://gdal.org/en/latest/programs/index.html#gdal-application It can be a bit daunting, but don't get discouraged, just read the docs. Every command in the docs has excellent examples at the bottom. Of course, this list is a great place to ask questions. Hope that helps! Scoot On 11/3/25 10:40, Twisha Mishra via gdal-dev wrote: > Subject: Introduction - Aspiring Contributor to GDAL > > Hi everyone, > > I?m Twisha Mishra, a computer science undergraduate student from India. > I recently joined the GDAL mailing list to start learning and > contributing to open-source geospatial software, especially with the > goal of applying for GSoC 2026 under OSGeo. > > I?m currently strengthening my fundamentals in HTML, CSS, and > JavaScript, and I?m also learning Python to better understand GDAL?s > ecosystem. My focus this month is to understand GIS concepts and explore > how GDAL works with raster and vector data. > > I?m completely new to GIS and open-source, but I?m excited to learn, > follow discussions here, and hopefully start contributing soon. Any > beginner-friendly guidance or suggestions on where to start exploring > issues or documentation would be greatly appreciated. > > Thank you for maintaining such an impactful project! > > Best regards, > Twisha Mishra > twishamishra256 at gmail.com > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From even.rouault at spatialys.com Mon Nov 3 12:03:03 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 3 Nov 2025 21:03:03 +0100 Subject: [gdal-dev] GDAL 3.12.0 release candidate available Message-ID: <565b0e3a-907e-46b3-94f1-7d7e6807d28c@spatialys.com> Hi, I have prepared a GDAL/OGR 3.12.0 "Chicoutimi" release candidate. I'll call for a vote promoting it later this week if no serious problems are reported before. NEWS at: ? https://github.com/OSGeo/gdal/blob/v3.12.0RC1/NEWS.md Pick up an archive among the following ones (by ascending size): ? https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0rc1.tar.xz ? https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0rc1.tar.gz ? https://download.osgeo.org/gdal/3.12.0/gdal3120rc1.zip A snapshot of the gdalautotest suite is also available : https://download.osgeo.org/gdal/3.12.0/gdalautotest-3.12.0rc1.zip A snapshot of the documentation is at: ? https://download.osgeo.org/gdal/3.12.0/gdal3120doc.zip The release/3.12 branch has now been created, and master is now open for 3.13.0dev. The following changes have been done since beta1: - Python bindings: add a dynamically generated 'gdal.alg' module (e.g. ``gdal.alg.raster.convert(input="in.tif", output="out.tif")``) - add compatibility with PoDoFo 1.0 - GdalGenerateConfig.cmake: improve generator expression handling - GdalGenerateConfig.cmake: revise link lib flattening - /vsis3/: add credential_process support for AWS authentication (#13239) - /vsis3/: fix issue when doing a new connection using EC2 credentials would ? go through WebIdentity (#13272) - /vsicurl/: make HTTP directory listing more robust (#13293) - /vsizip/: add file size related sanity checks to avoid huge mem allocs on ? corrupted files (ossfuzz#452384655) - add GDALMDArray::GetRawBlockInfo() / GDALMDArrayGetRawBlockInfo() and implement ? it in HDF5, netCDF, ZARR and VRT - multidim: Fix GetView(["::-1"]) on a dimension of size 1 - gdal info: make it output text by default - gdal raster convert: fix issue with comma in input dataset name (#13255) - gdal raster resize: add a --resolution argument (#13259) - gdalwarp: avoid warning when using -novshift (#13313) - gdalenhance: error out if attempting VRT output - gdalenhance: do not transfer statistics from input to output (#13298) - S102: recognize boolean and date featureAttributeTable fields with proper GDAL types - S104/S111: report verticalCS in metadata - VRT multidim: fix serialization of sources w.r.t relativeToVRT attribute - Zarr V3: on creation with CHUNK_MEMORY_LAYOUT=F, no longer write ? "order":"F", but the permutation array instead - OGRUnionLayer: improve performance of GetFeature() once a full scan has ? already been made - OGRGeometryFactory::forceTo(): fix potential nullptr dereference - OGRCircularString::segmentize(): fix crash/read-heap-overflow on M geometries (#13303) - OGRGeometryFactory::transformWithOptions(): avoid warnings when options are ? set but doing geographic->projected transformation (#13310) - gdal vector reproject: fix reprojecting from polar CRS to geographic coordinates (#13222) - GPKG: implement UpdateFieldDomain() and DeleteFieldDomain() - MiraMonVector: fix uninitialized access - MVT driver: fix reading files with 0-byte padding (#13268) - MVT writer: fix encoding some polygons with almost flat inner rings (#13305) - MVT reader: auto-fix badly oriented inner rings (#13305) - Parquet writer: fix SQLite3 error when using SORT_BY_BBOX=YES but writing no features (#13328) - PMTiles: gdal vsi list/copy: fixes so that gdal_ls.py/gdal_cp.py can be replaced by gdal vsi list/copy - Shapefile: workaround bug in PROJ BoundCRS::identify for CRS based on 'NTF (Paris)' (qgis/qgis#63787) - Python Utilities as a function: consistently handle options as string (#13274) Best regards, Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Tue Nov 4 03:01:13 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 4 Nov 2025 12:01:13 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.11.5 RC1 as final 3.11.5 release In-Reply-To: <81570fb3-079c-4de3-b0eb-c42cde6702f6@spatialys.com> References: <81570fb3-079c-4de3-b0eb-c42cde6702f6@spatialys.com> Message-ID: Motion passed with +1 from PSC members JukkaR, MikeS, JavierJS, HowardB and me. Le 31/10/2025 ? 12:56, Even Rouault via gdal-dev a ?crit?: > Hi, > > Motion: approve GDAL 3.11.5 RC1 as final 3.11.5 release > > Starting with my +1 > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Tue Nov 4 03:21:18 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 4 Nov 2025 12:21:18 +0100 Subject: [gdal-dev] GDAL 3.11.5 is released Message-ID: Hi, On behalf of the GDAL/OGR development team, I am pleased to announce the release of the GDAL/OGR 3.11.5 bug fix version. This will likely be the last one in the 3.11 series, with the 3.12.0 release being expected in a few days. Consult the release notes for the list of issues addressed: ??? https://github.com/OSGeo/gdal/blob/v3.11.5/NEWS.md The sources are available at: ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.xz ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.xz.md5 ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.xz.sig or ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.gz ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.gz.md5 ??? https://download.osgeo.org/gdal/3.11.5/gdal-3.11.5.tar.gz.sig or ??? https://download.osgeo.org/gdal/3.11.5/gdal3115.zip ??? https://download.osgeo.org/gdal/3.11.5/gdal3115.zip.md5 ??? https://download.osgeo.org/gdal/3.11.5/gdal3115.zip.sig Best regards, Even Note: for those checking signatures, this is still using my personnal GPG key (contrary to 3.12 onwards that will use the GPG key I mentionned for the 3.12beta1 announcement) -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Tue Nov 4 03:21:26 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 4 Nov 2025 12:21:26 +0100 Subject: [gdal-dev] GDAL 3.12.0 release candidate available In-Reply-To: <565b0e3a-907e-46b3-94f1-7d7e6807d28c@spatialys.com> References: <565b0e3a-907e-46b3-94f1-7d7e6807d28c@spatialys.com> Message-ID: Wow. There are a lot of new things in this release! Thank you to everybody who contributed to it. On Mon, 3 Nov 2025 at 21:03, Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > I have prepared a GDAL/OGR 3.12.0 "Chicoutimi" release candidate. > > I'll call for a vote promoting it later this week if no serious problems > are > reported before. > > NEWS at: > > https://github.com/OSGeo/gdal/blob/v3.12.0RC1/NEWS.md > > Pick up an archive among the following ones (by ascending size): > > https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0rc1.tar.xz > https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0rc1.tar.gz > https://download.osgeo.org/gdal/3.12.0/gdal3120rc1.zip > > A snapshot of the gdalautotest suite is also available : > > https://download.osgeo.org/gdal/3.12.0/gdalautotest-3.12.0rc1.zip > > A snapshot of the documentation is at: > > https://download.osgeo.org/gdal/3.12.0/gdal3120doc.zip > > The release/3.12 branch has now been created, and master is now open for > 3.13.0dev. > > > > The following changes have been done since beta1: > > - Python bindings: add a dynamically generated 'gdal.alg' module (e.g. > ``gdal.alg.raster.convert(input="in.tif", output="out.tif")``) > - add compatibility with PoDoFo 1.0 > - GdalGenerateConfig.cmake: improve generator expression handling > - GdalGenerateConfig.cmake: revise link lib flattening > - /vsis3/: add credential_process support for AWS authentication (#13239) > - /vsis3/: fix issue when doing a new connection using EC2 credentials > would > go through WebIdentity (#13272) > - /vsicurl/: make HTTP directory listing more robust (#13293) > - /vsizip/: add file size related sanity checks to avoid huge mem allocs on > corrupted files (ossfuzz#452384655) > - add GDALMDArray::GetRawBlockInfo() / GDALMDArrayGetRawBlockInfo() and > implement > it in HDF5, netCDF, ZARR and VRT > - multidim: Fix GetView(["::-1"]) on a dimension of size 1 > - gdal info: make it output text by default > - gdal raster convert: fix issue with comma in input dataset name (#13255) > - gdal raster resize: add a --resolution argument (#13259) > - gdalwarp: avoid warning when using -novshift (#13313) > - gdalenhance: error out if attempting VRT output > - gdalenhance: do not transfer statistics from input to output (#13298) > - S102: recognize boolean and date featureAttributeTable fields with > proper GDAL types > - S104/S111: report verticalCS in metadata > - VRT multidim: fix serialization of sources w.r.t relativeToVRT attribute > - Zarr V3: on creation with CHUNK_MEMORY_LAYOUT=F, no longer write > "order":"F", but the permutation array instead > - OGRUnionLayer: improve performance of GetFeature() once a full scan has > already been made > - OGRGeometryFactory::forceTo(): fix potential nullptr dereference > - OGRCircularString::segmentize(): fix crash/read-heap-overflow on M > geometries (#13303) > - OGRGeometryFactory::transformWithOptions(): avoid warnings when > options are > set but doing geographic->projected transformation (#13310) > - gdal vector reproject: fix reprojecting from polar CRS to geographic > coordinates (#13222) > - GPKG: implement UpdateFieldDomain() and DeleteFieldDomain() > - MiraMonVector: fix uninitialized access > - MVT driver: fix reading files with 0-byte padding (#13268) > - MVT writer: fix encoding some polygons with almost flat inner rings > (#13305) > - MVT reader: auto-fix badly oriented inner rings (#13305) > - Parquet writer: fix SQLite3 error when using SORT_BY_BBOX=YES but > writing no features (#13328) > - PMTiles: gdal vsi list/copy: fixes so that gdal_ls.py/gdal_cp.py can > be replaced by gdal vsi list/copy > - Shapefile: workaround bug in PROJ BoundCRS::identify for CRS based on > 'NTF (Paris)' (qgis/qgis#63787) > - Python Utilities as a function: consistently handle options as string > (#13274) > > Best regards, > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at postholer.com Tue Nov 4 11:35:24 2025 From: public at postholer.com (Scott) Date: Tue, 4 Nov 2025 11:35:24 -0800 Subject: [gdal-dev] gdal mdim convert and grib2 Message-ID: <31fbe0bb-80d8-45d9-8a27-8d99c11f7581@postholer.com> Using: GDAL 3.12.0 "Chicoutimi", released 2025/11/03 The following returns almost immediately, if you know the band number. Unfortunately, with this data set, the bands and arrays aren't consistent across model runs, so I can't rely on a fixed band. A grib2.idx does exist on S3 (which is why using band works so fast): gdal raster select -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif --band 132 --co COMPRESS=DEFLATE --overwrite The following takes over 4 minutes to complete. Downloading the file locally only takes about 20 seconds. time gdal mdim convert -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif --array "QPF06_0-SFC" --co COMPRESS=DEFLATE --overwrite If I download the file first, so it's local, then it completes immediately. Any thoughts on speeding this up? Ideally, I don't want to download the file first. Thanks! Scott -- www.postholer.com From even.rouault at spatialys.com Tue Nov 4 12:21:13 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 4 Nov 2025 21:21:13 +0100 Subject: [gdal-dev] gdal mdim convert and grib2 In-Reply-To: <31fbe0bb-80d8-45d9-8a27-8d99c11f7581@postholer.com> References: <31fbe0bb-80d8-45d9-8a27-8d99c11f7581@postholer.com> Message-ID: <1c19e5e7-3f8f-4c0b-b3d5-5b91922b8ad2@spatialys.com> Scott, is the band description (the one that is used in the classic data model, and populated from the content of the .idx) somewhat predictable / usable as an user input ? ("APCP:surface:53-59 hour acc fcst" in your example). If so, gdal? raster select could potentially be extended to accept a --band-description switch to select a band from its description. Even Le 04/11/2025 ? 20:35, Scott via gdal-dev a ?crit?: > Using: > GDAL 3.12.0 "Chicoutimi", released 2025/11/03 > > The following returns almost immediately, if you know the band number. > Unfortunately, with this data set, the bands and arrays aren't > consistent across model runs, so I can't rely on a fixed band. A > grib2.idx does exist on S3 (which is why using band works so fast): > > gdal raster select -i > /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/blend.t01z.core.f059.co.grib2 > -o blend.t01z.core.f059.co.tif --band 132 --co COMPRESS=DEFLATE > --overwrite > > The following takes over 4 minutes to complete. Downloading the file > locally only takes about 20 seconds. > > time gdal mdim convert -i > /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/blend.t01z.core.f059.co.grib2 > -o blend.t01z.core.f059.co.tif --array "QPF06_0-SFC" --co > COMPRESS=DEFLATE --overwrite > > If I download the file first, so it's local, then it completes > immediately. > > Any thoughts on speeding this up? Ideally, I don't want to download > the file first. > > Thanks! > Scott > > -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Tue Nov 4 13:26:46 2025 From: public at postholer.com (Scott) Date: Tue, 4 Nov 2025 13:26:46 -0800 Subject: [gdal-dev] gdal mdim convert and grib2 In-Reply-To: <1c19e5e7-3f8f-4c0b-b3d5-5b91922b8ad2@spatialys.com> References: <31fbe0bb-80d8-45d9-8a27-8d99c11f7581@postholer.com> <1c19e5e7-3f8f-4c0b-b3d5-5b91922b8ad2@spatialys.com> Message-ID: <8d870d9a-da20-4878-8cda-394729fc674e@postholer.com> Even, While a --band-description would be helpful, it doesn't solve the problem with this data set. Here's the .idx and all occurrences of 'APCP': 71:52927388:d=2025110401:APCP:surface:53-59 hour acc fcst:prob >0.254:prob fcst 255/255 72:53775635:d=2025110401:APCP:surface:47-59 hour acc fcst:prob >0.254:prob fcst 255/255 82:62041284:d=2025110401:APCP:surface:58-59 hour acc fcst: 83:62794128:d=2025110401:APCP:surface:53-59 hour acc fcst: With a --band-description, I still wouldn't know what the QPF06 array/band equivalent is. Right now, I'm reading the .idx file, selecting lines with APCP, without the string 'prob' and doing the math on ':53-59 hour acc fcst:' to determine if it's a 6 hour or 1 hour qpf, and saving the band number, then using 'gdal raster select' to download . It's fast, but a total hack. Not cool. In a perfect world, the .idx would have the same keys as the array names. Thanks for the quick response and feedback! Scott On 11/4/25 12:21, Even Rouault wrote: > Scott, > > is the band description (the one that is used in the classic data model, > and populated from the content of the .idx) somewhat predictable / > usable as an user input ? ("APCP:surface:53-59 hour acc fcst" in your > example). If so, gdal? raster select could potentially be extended to > accept a --band-description switch to select a band from its description. > > Even > > Le 04/11/2025 ? 20:35, Scott via gdal-dev a ?crit?: >> Using: >> GDAL 3.12.0 "Chicoutimi", released 2025/11/03 >> >> The following returns almost immediately, if you know the band number. >> Unfortunately, with this data set, the bands and arrays aren't >> consistent across model runs, so I can't rely on a fixed band. A >> grib2.idx does exist on S3 (which is why using band works so fast): >> >> gdal raster select -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/core/ >> blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif --band >> 132 --co COMPRESS=DEFLATE --overwrite >> >> The following takes over 4 minutes to complete. Downloading the file >> locally only takes about 20 seconds. >> >> time gdal mdim convert -i /vsis3/noaa-nbm-para-pds/blend.20251104/01/ >> core/blend.t01z.core.f059.co.grib2 -o blend.t01z.core.f059.co.tif -- >> array "QPF06_0-SFC" --co COMPRESS=DEFLATE --overwrite >> >> If I download the file first, so it's local, then it completes >> immediately. >> >> Any thoughts on speeding this up? Ideally, I don't want to download >> the file first. >> >> Thanks! >> Scott >> >> From lorenzocurcio2 at gmail.com Tue Nov 4 16:42:25 2025 From: lorenzocurcio2 at gmail.com (Lorenzo Curcio) Date: Wed, 5 Nov 2025 01:42:25 +0100 Subject: [gdal-dev] Unsure about significance of nodata:null in raster:bands Message-ID: Hi all. When using gdal raster info I have noted that in the "raster:bands" section (with output format set to default json) the nodata value of float rasters is always reported as "null". All attempts to change or set the nodata value seem unable to fix this. It only happens with float rasters - if you convert a float raster to int with gdal_translate, nodata is correctly reported. If you convert it back to float, it becomes null again. I've tried this on a few rasters and it seems consistent. All were GTiff format. Is this a known thing? Is there any meaning or significance to it? The separate "bands" section in gdal raster info output does always correctly output the nodata value, which is a bit confusing. I was curious about this because I've been investigating an issue where raster2pgsql is seemingly refusing to recognize and not write empty tiles (as it should be without the -k flag). I was curious if this could be a bug or some other occurrence whereby it's not recognizing the nodata value of the raster properly, therefore leading to always writing the full raster. I know raster2pgsql specific questions aren't for here, I will make a similar mail to the postgis-users mailing list soon, I was just giving context. If this isn't the right place to ask this question, sorry and please let me know where the right place is. Thanks, Lorenzo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Nov 4 17:07:27 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 5 Nov 2025 02:07:27 +0100 Subject: [gdal-dev] Unsure about significance of nodata:null in raster:bands In-Reply-To: References: Message-ID: Hi, > > When using gdal raster info I have noted that in the?"raster:bands" > section (with output format set to default json) the nodata value of > float rasters is always reported as "null". All attempts to change or > set the nodata value seem unable to fix this. It only happens with > float rasters - if you convert a float raster to int with > gdal_translate, nodata is correctly reported. If you convert it back > to float, it becomes null again. I've tried this on a few rasters and > it seems consistent. All were GTiff format. This is a bug specific to the STAC relate part of JSON output. Will be fixed per https://github.com/OSGeo/gdal/pull/13333 > > I was curious about this because I've been investigating an issue > where raster2pgsql is seemingly refusing to recognize and not write > empty tiles (as it should be without the -k flag). I was curious if > this could be a bug or some other occurrence whereby it's not > recognizing the nodata value of the raster properly, therefore leading > to always writing the full raster. > > I know raster2pgsql specific questions aren't for here, I will make a > similar mail to the postgis-users mailing list soon, I was just giving > context. Not sure about the raster2pgsql issue, but definitely not related to the above bug. Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Nov 5 11:52:31 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 5 Nov 2025 20:52:31 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 Message-ID: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Hi, starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Wed Nov 5 12:03:25 2025 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 5 Nov 2025 21:03:25 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: +1 Javier On Wed, 5 Nov 2025, 20:52 Even Rouault via gdal-dev, < gdal-dev at lists.osgeo.org> wrote: > Hi, > > starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.smith.erdc at gmail.com Wed Nov 5 12:09:40 2025 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 5 Nov 2025 15:09:40 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: +1 Mike Michael Smith > On Nov 5, 2025, at 2:52?PM, Even Rouault via gdal-dev wrote: > > ?Hi, > > starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev From jukka.rahkonen at maanmittauslaitos.fi Wed Nov 5 12:44:30 2025 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Wed, 5 Nov 2025 20:44:30 +0000 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: +1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Keskiviikko 5. marraskuuta 2025 21.52 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 Hi, starting with my +1 Even -- http://www.spatialys.com/ My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From norman.barker at gmail.com Wed Nov 5 13:01:06 2025 From: norman.barker at gmail.com (Norman Barker) Date: Wed, 5 Nov 2025 15:01:06 -0600 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: +1 Norman On Wed, Nov 5, 2025 at 2:44?PM Rahkonen Jukka via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > +1 > > -Jukka Rahkonen- > > ________________________________________ > L?hett?j?: gdal-dev k?ytt?j?n Even > Rouault via gdal-dev puolesta > L?hetetty: Keskiviikko 5. marraskuuta 2025 21.52 > Vastaanottaja: gdal-dev at lists.osgeo.org > Aihe: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 > > > Hi, > > starting with my +1 > > Even > > -- > http://www.spatialys.com/ > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.malm at lfv.se Thu Nov 6 00:29:59 2025 From: paul.malm at lfv.se (paul.malm at lfv.se) Date: Thu, 6 Nov 2025 08:29:59 +0000 Subject: [gdal-dev] Georeference a pdf file Message-ID: <33bf1b4e283e464b8d98aa53c9c07d62@lfv.se> I have a PDF file with a map, but without georeferenced parameters. I know what coordinate reference system the PDF-map is drawn in. Now I would like to georeferenced that PDF file, just add needed information. I have the coordinates for the 4 corners in WGS84. I do not want to use gdalwarp as it warps the picture. I only want to add the georeferenced to the PDF file, is that possible with GDAL? Kind regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at aitchison.me.uk Thu Nov 6 01:30:17 2025 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Thu, 6 Nov 2025 09:30:17 +0000 (GMT) Subject: [gdal-dev] Georeference a pdf file In-Reply-To: <33bf1b4e283e464b8d98aa53c9c07d62@lfv.se> References: <33bf1b4e283e464b8d98aa53c9c07d62@lfv.se> Message-ID: <094b7fdc-d689-8b9d-b1c7-c261149c0aca@aitchison.me.uk> On Thu, 6 Nov 2025, Paul via gdal-dev wrote: > I have a PDF file with a map, but without georeferenced parameters. > I know what coordinate reference system the PDF-map is drawn in. > Now I would like to georeferenced that PDF file, just add needed information. I have the coordinates for the 4 corners in WGS84. > I do not want to use gdalwarp as it warps the picture. > I only want to add the georeferenced to the PDF file, is that possible with GDAL? gdal_translate has lots of options for adding a georeference. I don't know what would happen for a vector pdf, but if it is a raster there should heno problem translation from a pdf to a pdf. Note that you need the corners of the image file; many maps have a border, so the corners of the map may not be the same. -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From howard at hobu.co Thu Nov 6 03:16:59 2025 From: howard at hobu.co (Howard Butler) Date: Thu, 6 Nov 2025 06:16:59 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: <2B3423CF-80CD-42D5-B7CB-B8B285D091D9@hobu.co> +1 Howard > On Nov 5, 2025, at 4:01?PM, Norman Barker via gdal-dev wrote: > > +1 > Norman > > On Wed, Nov 5, 2025 at 2:44?PM Rahkonen Jukka via gdal-dev > wrote: >> +1 >> >> -Jukka Rahkonen- >> >> ________________________________________ >> L?hett?j?: gdal-dev > k?ytt?j?n Even Rouault via gdal-dev > puolesta >> L?hetetty: Keskiviikko 5. marraskuuta 2025 21.52 >> Vastaanottaja: gdal-dev at lists.osgeo.org > >> Aihe: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 >> >> >> Hi, >> >> starting with my +1 >> >> Even >> >> -- >> http://www.spatialys.com/ >> My software is free, but my time generally not. >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From n_larsson at yahoo.com Thu Nov 6 03:57:40 2025 From: n_larsson at yahoo.com (Nicklas Larsson) Date: Thu, 6 Nov 2025 12:57:40 +0100 Subject: [gdal-dev] GDAL-GRASS driver 2.0.0 release candidate released In-Reply-To: <9BDF1429-470F-4C73-9CB8-0F6C680BF192@yahoo.com> References: <9BDF1429-470F-4C73-9CB8-0F6C680BF192@yahoo.com> Message-ID: <479DDEED-1FE5-43CD-B2FD-D72647961C78@yahoo.com> Hi, If there are no objections raised, I will shortly prepare for a final release of the GDAL-GRASS driver. Best regards, Nicklas From dbaston at gmail.com Thu Nov 6 05:48:03 2025 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 6 Nov 2025 08:48:03 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: +1 Dan On Wed, Nov 5, 2025 at 2:52?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n_larsson at yahoo.com Fri Nov 7 12:39:50 2025 From: n_larsson at yahoo.com (Nicklas Larsson) Date: Fri, 7 Nov 2025 21:39:50 +0100 Subject: [gdal-dev] GDAL-GRASS driver 2.0.0 released In-Reply-To: <9BDF1429-470F-4C73-9CB8-0F6C680BF192@yahoo.com> References: <9BDF1429-470F-4C73-9CB8-0F6C680BF192@yahoo.com> Message-ID: <492B71AD-CEEE-483B-B034-C72598D42B03@yahoo.com> The GDAL-GRASS driver 2.0.0 release provides more than 15 improvements and fixes with respect to the release 1.0.4. Notable changes include added support for GDAL 3.12 and removed support for Autotools build system. Special note for packagers: the bump of gdal-grass to version 2.x introduces the potential of version conflicts from the era when the driver was part of GDAL core. Please take appropriate action to prevent that from happening. ## What's Changed ### Libraries and General Functionality * Adapt GetGeoTransform() method for GDAL 3.12 change, and avoid use of deprecated GDALGetDataTypeSize() functions (#67) by @rouault * Fix const correctness of virtual methods for GDAL 3.12 (#70) by @rouault * C++: modernize code (#37) by @nilason ### Documentation and Messages * docs: Add license file and use SPDX identifiers (#55) by @nilason * docs: Add missing SPDX identifier (#74) by @nilason ### Packaging, Configuration, Portability, and Compilation * cmake: replace deprecated 'exec_program' (#73) by @nilason * config: remove autoconf support (#56) by @nilason ### Continuous Integration, Tests, Code Quality, and Checks * checks: add pre-commit configuration file (#58) by @nilason ### Other Changes * Move source files to 'source' directory (#60) by @nilason * style: fix issues reported by pre-commit (#59) by @nilason **Full Changelog**: https://github.com/OSGeo/gdal-grass/compare/1.0.4...2.0.0 The release can be downloaded from: https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0.tar.gz https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0.tar.gz.md5 https://download.osgeo.org/gdal-grass/gdal-grass-2.0.0.tar.gz.sha256 -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Nov 7 14:51:38 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 7 Nov 2025 23:51:38 +0100 Subject: [gdal-dev] Motion: approve GDAL 3.12.0RC1 as final 3.12.0 In-Reply-To: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> References: <653888ab-20fa-43bb-9bd8-4b4f1e318377@spatialys.com> Message-ID: <59ce8c3d-550a-4843-947e-f82dce05aee9@spatialys.com> Motion passed with +1 from PSC members JavierJS, MikeS, JukkaR, NormanB, HowardB, DanielB and me. Le 05/11/2025 ? 20:52, Even Rouault via gdal-dev a ?crit?: > Hi, > > starting with my +1 > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Fri Nov 7 15:04:42 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 8 Nov 2025 00:04:42 +0100 Subject: [gdal-dev] Issue with deployment of Java bindings of GDAL 3.12.0 to central.sonatype.com Message-ID: Hi, up to now the bundle.jar produced when building the Java bindings was uploaded to https://oss.sonatype.org? . But going on that site, I see it has been deprecated in favor of https://central.sonatype.com . I've managed to login there using my sonatype login, but when attempting to upload bundle.jar, it fails with "Bundle has content that does NOT have a .pom file: META-INF" . I've also tried to upload gdal-3.12.0.jar and it fails with "Bundle has content that does NOT have a .pom file: META-INF, org/gdal/osr, org/gdal/gdalconst, org/gdal/gdal, org/gdal/gnm, org/gdal/ogr" Any Java guru that can help? Even -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Nov 7 16:14:09 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 8 Nov 2025 01:14:09 +0100 Subject: [gdal-dev] GDAL 3.12.0 "Chicoutimi" is released Message-ID: Hi, On behalf of the GDAL/OGR development team and community, I am pleased to announce the release of GDAL/OGR 3.12.0 "Chicoutimi". GDAL/OGR is a C++ geospatial data access library for raster and vector file formats, databases and web services. It includes bindings for several languages, and a variety of command line tools. http://gdal.org/ The 3.12.0 release is a new feature release with the following highlights: * New 'gdal' command line interface capabilities: ? - Add 'gdal raster as-features' (#12970) ? - Add 'gdal raster blend' (port of hsv_merge.py + regular alpha blending) ? - Add 'gdal raster compare' (port of gdalcompare.py) (#12757) ? - Add 'gdal raster neighbors' (#12768) ? - Add 'gdal raster nodata-to-alpha' (#12524) ? - Add 'gdal raster pansharpen' (port of gdal_pansharpen.py) ? - Add 'gdal raster proximity' (#12350) ? - Add 'gdal raster rgb-to-palette' (port of rgb2pct.py) ? - Add 'gdal raster update' ? - Add 'gdal raster zonal-stats' ? - Add 'gdal vector check-coverage' ? - Add 'gdal vector check-geometry' ? - Add 'gdal vector clean-coverage' ? - Add 'gdal vector index' (port of ogrtindex) ? - Add 'gdal vector layer-algebra' (port of ogr_layer_algebra.py) ? - Add 'gdal vector make-point' ? - Add 'gdal vector partition' ? - gdal vector pipeline: add limit step ? - Add 'gdal vector set-field-type' ? - Add 'gdal vector simplify-coverage' ? - Add 'gdal mdim mosaic' (#13208) ? - Add 'gdal dataset' port of 'gdal manage' ? - Make 'gdal pipeline' support mixed raster/vector pipelines ? - Pipeline: add support for nested pipeline (#12874) ? - Pipeline: add support for a 'tee' step (#12874) ? - Move 'gdal vector geom XXXX' utilities directly under 'gdal vector' ? - Rename 'gdal vector geom set-type' as 'gdal vector set-geom-type' ? - gdal raster reproject: add a -j/--num-threads option and default to ALL_CPUS ? - Make 'gdal raster fill-nodata/proximity/sieve/viewshed' pipeline-able ? - gdal raster mosaic/stack: allow it to be the first step of a raster pipeline ? - gdal pipeline: allow to run an existing pipeline and override/add parameters ? - Improved Bash completion ? - Python bindings: add a dynamically generated 'gdal.alg' module ??? (e.g. ``gdal.alg.raster.convert(input="in.tif", output="out.tif")``) ? - Many other improvements to existing utilities (see below) Other topics * VRT pixel functions: Add mean, median, geometric_mean, harmonic_mean, mode ?? (#12418), and handle NoData values * Add C/C++/Python API for [raster band algebra](https://gdal.org/en/latest/user/band_algebra.html): ? arithmetic operators, comparison operators, AsType(), ? gdal::abs()/sqrt()/log10()/log()/min()/max()/mean()/IfThenElse() functions * Add MiraMon raster driver: read-only support (#12293) * ADBC driver: support for ADBC BigQuery driver (requires BigQuery ADBC driver) * JSONFG driver: add read/write support for curve and measured geometries; ? update to 0.3.0 spec * Parquet: add update support using OGREditableLayer mechanism * Add C++ public header files for raster functionality * Security: avoid potential path traversal in several drivers * Various code linting, static code analyzer fixes, etc. * Significant automation of the release process * Add Docker attestation (#13066) * Bump of shared lib major version * [RFC 104](https://gdal.org/en/latest/development/rfc/rfc104_gdal_cli.html): Adding a "gdal" front-end command line interface. ? - See the [list of commands](https://gdal.org/en/latest/programs/index.html#gdal-application) ? - Includes new "gdal raster calc" and "gdal raster resclassify" utilities. ? - "gdal raster tile", C++ port of gdal2tiles, runs faster (3x to 6x in some cases) ? - Includes "gdal vsi list/copy/delete/move/sync" (ports of Python sample scripts) ? - Includes "gdal driver {driver_name}" for driver-specific commands. ? - Includes smart Bash autocompletion ? - Includes C, C++, Python API * Add [GDALG](https://gdal.org/en/latest/drivers/vector/gdalg.html) (GDAL Streamed Algorithm Format) driver: reading of on-the-fly / streamed vector dataset replaying compatible "gdal" command lines (kind of VRT). More complete information on the new features and fixes in the 3.12.0 release can be found at: https://github.com/OSGeo/gdal/blob/v3.12.0/NEWS.md Please also consult the migration guide when updating from prior releases: https://gdal.org/en/latest/user/migration_guide.html#from-gdal-3-11-to-gdal-3-12 The release can be downloaded from: ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.gz - source as .tar.gz ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.gz.md5 - md5sum ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.gz.sig - signature ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.xz - source as .tar.xz ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.xz.md5 - md5sum ? * https://download.osgeo.org/gdal/3.12.0/gdal-3.12.0.tar.xz.sig - signature ? * https://download.osgeo.org/gdal/3.12.0/gdal3120.zip - source as a zip ? * https://download.osgeo.org/gdal/3.12.0/gdal3120.zip.md5 - md5sum ? * https://download.osgeo.org/gdal/3.12.0/gdal3120.zip.sig - signature ? * https://download.osgeo.org/gdal/3.12.0/gdalautotest-3.12.0.zip - test suite ? * https://download.osgeo.org/gdal/3.12.0/gdal3120doc.zip - documentation / website Python bindings are pushed to https://pypi.org/project/GDAL/3.12.0.post1 Note the ".post1" suffix. The initial 3.12.0 was unfortunately corrupted due to a hickup in the new release process. Docker images are available: ? * ghcr.io/osgeo/gdal:ubuntu-full-3.12.0 ? * ghcr.io/osgeo/gdal:ubuntu-small-3.12.0 ? * ghcr.io/osgeo/gdal:alpine-normal-3.12.0 ? * ghcr.io/osgeo/gdal:alpine-small-3.12.0 Best regards, Even PS1: Packager comparing rc1 to final will notice a slight difference in content for the dates of the manpages, due to the generation of tarballs now being triggered on tag push. PS2: GPG signing key used: -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBGjlDXoBEACjbYUouwHnW+X/xK51AfwN1vTrJn+pZziGGLobD4Jfs4gU4PwQ dEw1bFj6tsgBrJ7hrKmcyd0bBQiKU1FTYy+tOu768t9qlC7HC3JfRBACrGn3Svz4 evinQkq5GGcZ1FkJhRKgEIxJLGppG7O45XEFYdcbCkLqC8uyu2+PbY2SYXlzlKs8 DLiAwqX670eZ78pDtynJj81CRowSqyNBOzaltR6OLCsYZrYzAYYtBqSiifKoIpm/ sV4VRvUuWaaUNNMPPRLt+mV+iIYm8cKLH2uyozZWIfOSck7I30fGIuuUhulc41bi 3WNV+QtOepPyuMolab8JNbaRJXAFxQ5Q2k5ZyzXvpuAEqwrhaFIroc7LvkQ4RLlT r6BkFUzvCCjRWG5jCFA0CjvvvYG9DPSUKdSaD2Vxfor/cwSRqnPYwRauFMuST57H exrLYJZqfeZuqV2mlI8wVvh3tO9oC/pGmggV3B1KxYvzj2I/nQ/bnugveEvD005j EcfSlmAPWcuily+rgB9xqed0tZwG0A9fjY/gveqxLVE41EIoAfkdeRl+KVOqEEYk cyiJQdFKBuGxemEP2cfDnROUawp+1XXEuA1MGkLvB+6nNIp1e+mhUtWfDY70MEz1 l7J49MUZBfPM3vy63t7ihlPLIP9IUcO9j9rfy1iW8t86qG3CnZE/rsnVZwARAQAB tCRHREFMIFJlbGVhc2UgQm90IDxnZGFsb3JnQGdtYWlsLmNvbT6JAlQEEwEKAD4W IQR7Ew6VW0TYfM4nZfDb2B/1LsKkKgUCaOUNegIbAwUJA8JnAAULCQgHAgYVCgkI CwIEFgIDAQIeAQIXgAAKCRDb2B/1LsKkKpY+D/9hVR9JIQNT3So4fg/fQx36azSf kVzO4nS0lZhSxR4/Xig5Zqq8EOFk7ipWwb4hhivPi7yR49BhVSQbHo36+jNbC5k/ jDMsZ+9CNzUjp1XSH/v06mcdSD4LB4vSvHBfLjDdV7OoOGnExkEyqBcoje53tW6p tKQGwqZ3ilZs75GkLO1UC3DNQ9VpVc7lk1Cv+npto86A6CWMAC7q+n540wC/oTj7 APn6dz1S0LAPWR9v0aBoLMoRP9YiRQSmQmyQsKe3HJd4c7hSdWyST/PIMvPZawpP BYG+JRRuRoWm6zjJIWnvqj9IZeFkQv1fKqYHKW86aITTqGGF6kcq83mf2XH26KQR mu8ArI5aLULmpKA67p2RXxyPdoSNiaiP8UuWQ18rnEA/Hedz2sgBYSvjeYYziTRm wgiRbts4MjB5pj+JGKtX7FEL6HuPDVnMYGc8n8bO8qiKctuYMwBM/KRE+2e3zx0m m5YXjjCSvBiTLYNhvrrQ5pxiUK5xiAH0G/MzPXjJToJzLrHn0vqRVHXs9F8d9zLe o6E4S8VVgyJ9zdXkYtj9nyL9jb00K+jj/g4avpnOKTuIgpsTR2ntxWz2liWU6Saz 03Vrd9mVwgU7NBnYAMXOg54eYwhyWkGvbFHvCK6ijL1+SaAkN9mVs5VTJMpGiJ9s qj7DbIY0GwZQMVSvxQ== =FY/p -----END PGP PUBLIC KEY BLOCK----- -- http://www.spatialys.com My software is free, but my time generally not. From lnicola at dend.ro Fri Nov 7 23:27:56 2025 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Sat, 08 Nov 2025 09:27:56 +0200 Subject: [gdal-dev] Issue with deployment of Java bindings of GDAL 3.12.0 to central.sonatype.com In-Reply-To: References: Message-ID: <2bfd7472-2096-48a7-a296-8c040f9c1a52@betaapp.fastmail.com> Just a guess, but https://stackoverflow.com/a/79733755 and https://central.sonatype.org/publish/publish-portal-upload/ make it sound like you're not supposed to upload a jar there. Laurentiu On Sat, Nov 8, 2025, at 01:04, Even Rouault via gdal-dev wrote: > Hi, > > up to now the bundle.jar produced when building the Java bindings was uploaded to https://oss.sonatype.org . But going on that site, I see it has been deprecated in favor of https://central.sonatype.com . I've managed to login there using my sonatype login, but when attempting to upload bundle.jar, it fails with "Bundle has content that does NOT have a .pom file: META-INF" . I've also tried to upload gdal-3.12.0.jar and it fails with "Bundle has content that does NOT have a .pom file: META-INF, org/gdal/osr, org/gdal/gdalconst, org/gdal/gdal, org/gdal/gnm, org/gdal/ogr" > > Any Java guru that can help? > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat Nov 8 05:38:17 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 8 Nov 2025 14:38:17 +0100 Subject: [gdal-dev] Issue with deployment of Java bindings of GDAL 3.12.0 to central.sonatype.com In-Reply-To: <2bfd7472-2096-48a7-a296-8c040f9c1a52@betaapp.fastmail.com> References: <2bfd7472-2096-48a7-a296-8c040f9c1a52@betaapp.fastmail.com> Message-ID: Thanks for the hint. After a few tweaks (https://github.com/OSGeo/gdal/pull/13365), I've managed to get to a step where the bundle.zip validates the consistency checks of central.sonatype.com and I'm apparently at one click away from publishing it. The content of that zip is: org/ org/gdal/ org/gdal/gdal/ org/gdal/gdal/3.12.0/ org/gdal/gdal/3.12.0/gdal-3.12.0-javadoc.jar org/gdal/gdal/3.12.0/gdal-3.12.0-javadoc.jar.asc org/gdal/gdal/3.12.0/gdal-3.12.0-javadoc.jar.md5 org/gdal/gdal/3.12.0/gdal-3.12.0-javadoc.jar.sha1 org/gdal/gdal/3.12.0/gdal-3.12.0-sources.jar org/gdal/gdal/3.12.0/gdal-3.12.0-sources.jar.asc org/gdal/gdal/3.12.0/gdal-3.12.0-sources.jar.md5 org/gdal/gdal/3.12.0/gdal-3.12.0-sources.jar.sha1 org/gdal/gdal/3.12.0/gdal-3.12.0.jar org/gdal/gdal/3.12.0/gdal-3.12.0.jar.asc org/gdal/gdal/3.12.0/gdal-3.12.0.jar.md5 org/gdal/gdal/3.12.0/gdal-3.12.0.jar.sha1 org/gdal/gdal/3.12.0/gdal-3.12.0.pom org/gdal/gdal/3.12.0/gdal-3.12.0.pom.asc org/gdal/gdal/3.12.0/gdal-3.12.0.pom.md5 org/gdal/gdal/3.12.0/gdal-3.12.0.pom.sha1 Despite it passing their tests, I'm wondering if there will not be an issue with the org/gdal/gdal/ hierarchy that reflects well the org.gdal.gdal. namespace, but not that much the org.gdal.ogr. and org.gdal.osr. ones. I tried to remove one level of hierarchy to have just "org/gdal/" but the checks didn't like it. Even Le 08/11/2025 ? 08:27, Lauren?iu Nicola via gdal-dev a ?crit?: > Just a guess, but https://stackoverflow.com/a/79733755?and > https://central.sonatype.org/publish/publish-portal-upload/?make it > sound like you're not supposed to upload a jar there. > > Laurentiu > > On Sat, Nov 8, 2025, at 01:04, Even Rouault via gdal-dev wrote: >> >> Hi, >> >> up to now the bundle.jar produced when building the Java bindings was >> uploaded to https://oss.sonatype.org . But >> going on that site, I see it has been deprecated in favor of >> https://central.sonatype.com . I've >> managed to login there using my sonatype login, but when attempting >> to upload bundle.jar, it fails with "Bundle has content that does NOT >> have a .pom file: META-INF" . I've also tried to upload >> gdal-3.12.0.jar and it fails with "Bundle has content that does NOT >> have a .pom file: META-INF, org/gdal/osr, org/gdal/gdalconst, >> org/gdal/gdal, org/gdal/gnm, org/gdal/ogr" >> >> Any Java guru that can help? >> >> Even >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From foyc at flighttactics.com Mon Nov 10 09:03:51 2025 From: foyc at flighttactics.com (Cory Foy) Date: Mon, 10 Nov 2025 12:03:51 -0500 Subject: [gdal-dev] Trouble enabling MBTiles Driver Message-ID: <5671306F-267A-497A-9FE0-F00CC3659980@flighttactics.com> Hi All, I?m trying to enable the MBTiles driver. Right now when I try to open an MBTiles file, I get: ERROR 4: `/private/var/containers/Bundle/Application/FA11C8FF-04F8-4CDB-9CBD-F6C7B8DC1F03/Test.mbtiles' not recognized as being in a supported file format. I also don?t see it in the list of drivers using GDALGetDriver after calling GDALAllRegister(): ***Found 13 drivers ***Checking Driver 0: Virtual Raster ***Checking Driver 1: GeoTIFF ***Checking Driver 2: Cloud optimized GeoTIFF generator ***Checking Driver 3: Portable Network Graphics ***Checking Driver 4: In Memory raster, vector and multidimensional raster ***Checking Driver 5: Geospatial PDF ***Checking Driver 6: Geographic Network generic file based model ***Checking Driver 7: Geographic Network generic DB based model ***Checking Driver 8: ESRI Shapefile ***Checking Driver 9: GeoJSON ***Checking Driver 10: GeoJSON Sequence ***Checking Driver 11: ESRIJSON ***Checking Driver 12: TopoJSON It does look like it?s enabled in the build, though (I?ll paste the build output below) but I wonder if some other driver I?m missing is not enabled which is causing it to not be enabled in the final build. Is there something I?m maybe missing here? Thanks, Cory ====BUILD COMMAND==== cmake --fresh -B build \ -DCMAKE_TOOLCHAIN_FILE=../../ios-cmake-4.5.0/ios.toolchain.cmake \ -DPLATFORM=OS64 \ -DENABLE_BITCODE=OFF \ -DPROJ_LIBRARY_RELEASE=/Users/foyc/Workspace/gdal/compiled/dev/libproj.a \ -DBUILD_SHARED_LIBS=ON \ -DBUILD_APPS=OFF \ -DBUILD_PYTHON_BINDINGS=OFF \ -DBUILD_TESTING=OFF \ -DGDAL_USE_ODBC=ON \ -DOGR_ENABLE_DRIVER_SQLITE=ON \ -DGDAL_USE_SPATIALITE=ON \ -DGDAL_USE_OPENJPEG=ON \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_DISABLE_FIND_PACKAGE_Arrow=ON \ -DGDAL_BUILD_OPTIONAL_DRIVERS=ON \ -DOGR_BUILD_OPTIONAL_DRIVERS=ON \ -DGDAL_USE_EXTERNAL_LIBS=ON \ -DGDAL_USE_ZLIB=OFF \ -DGDAL_USE_LIBKML=OFF \ -DGDAL_ENABLE_DRIVER_PNG=ON \ -DGDAL_ENABLE_DRIVER_JPEG=ON \ -DGDAL_USE_PNG_INTERNAL=ON \ -DGDAL_ENABLE_DRIVER_PDF=ON \ -DGDAL_USE_PDFIUM=ON \ -DGDAL_USE_SQLITE3=ON \ -DGDAL_ENABLE_DRIVER_MBTILES=ON \ -DPDFIUM_INCLUDE_DIR=/Users/foyc/Workspace/gdal/compiled/headers/pdfium \ -DPDFIUM_LIBRARY=/Users/foyc/Workspace/gdal/compiled/dev/libpdfium.a ====BUILD OUTPUT==== (Truncated to not include initial checks, though I can add them if it helps) -- Enabled drivers and features and found dependency packages -- The following features have been enabled: * gdal_JPEG, JPEG image format * gdal_RAW, Raw formats:EOSAT FAST Format, FARSITE LCP and Vexcel MFF2 Image * gdal_GTIFF, GeoTIFF image format * gdal_MEM, Read/write data in Memory * gdal_VRT, Virtual GDAL Datasets * gdal_DERIVED, Derived datasets * gdal_GTI, GDAL Tile Index * gdal_LIBERTIFF, GeoTIFF support through libertiff library * gdal_HFA, Erdas Imagine .img * gdal_NITF, National Imagery Transmission Format * gdal_GXF, GXF * gdal_AAIGRID, Arc/Info ASCII Grid Format. * gdal_CEOS, CEOS translator * gdal_SAR_CEOS, ASI CEOS translator * gdal_DTED, Military Elevation Data * gdal_JDEM, JDEM driver * gdal_ENVISAT, Envisat * gdal_L1B, NOAA Polar Orbiter Level 1b Data Set (AVHRR) * gdal_RS2, RS2 -- RadarSat 2 XML Product * gdal_ILWIS, Raster Map * gdal_RMF, RMF --- Raster Matrix Format * gdal_LEVELLER, Daylon Leveller heightfield * gdal_SRTMHGT, SRTM HGT File Read Support * gdal_IDRISI, Idrisi Raster Format * gdal_GSG, Implements the Golden Software Surfer 7 Binary Grid Format. * gdal_ERS, ERMapper .ERS * gdal_JAXAPALSAR, JAXA PALSAR Level 1.1 and Level 1.5 processed products support * gdal_DIMAP, SPOT Dimap Driver * gdal_GFF, Ground-based SAR Applitcations Testbed File Format driver * gdal_COSAR, COSAR -- TerraSAR-X Complex SAR Data Product * gdal_PDS, USGS Astrogeology ISIS Cube (Version 2) * gdal_ADRG, ADRG reader and ASRP/USRP Reader * gdal_COASP, DRDC Configurable Airborne SAR Processor (COASP) data reader * gdal_TSX, TerraSAR-X XML Product Support * gdal_TERRAGEN, Terragen™ Terrain File * gdal_MSGN, Meteosat Second Generation (MSG) Native Archive Format (.nat) * gdal_TIL, EarthWatch .TIL Driver * gdal_NORTHWOOD, NWT_GRD/NWT_GRC -- Northwood/Vertical Mapper File Format * gdal_SAGA, SAGA GIS Binary Driver * gdal_XYZ, ASCII Gridded XYZ * gdal_HEIF, HEIF * gdal_ESRIC, ESRI compact cache * gdal_HF2, HF2/HFZ heightfield raster * gdal_KMLSUPEROVERLAY * gdal_CTG, CTG driver * gdal_ZMAP, ZMAP * gdal_NGSGEOID, NOAA NGS Geoid Height Grids * gdal_IRIS, IRIS driver * gdal_MAP, OziExplorer .MAP * gdal_CALS, CALS type 1 * gdal_SAFE, SAFE -- Sentinel-1 SAFE XML Product * gdal_SENTINEL2, Driver for Sentinel-2 Level-1B, Level-1C and Level-2A products. * gdal_PRF, PHOTOMOD Raster File * gdal_MRF, Meta raster format * gdal_WMTS, OGC Web Map Tile Service * gdal_GRIB, WMO General Regularly-distributed Information in Binary form * gdal_BMP, Microsoft Windows Device Independent Bitmap * gdal_TGA, TGA * gdal_STACTA, STACTA * gdal_SNAP_TIFF, SNAP TIFF * gdal_BSB, Maptech/NOAA BSB Nautical Chart Format * gdal_AIGRID, Arc/Info Binary Grid Format * gdal_USGSDEM, USGS ASCII DEM (and CDED) * gdal_AIRSAR, AirSAR Polarimetric Format * gdal_PCIDSK, PCI Geomatics Database File * gdal_SIGDEM, Scaled Integer Gridded DEM .sigdem Driver * gdal_RIK, RIK -- Swedish Grid Maps * gdal_STACIT, STACIT * gdal_PDF, Geospatial PDF * gdal_RCM, Radarsat Constellation Mission * gdal_GDALG, GDAL Streamed Algorithm Format * gdal_PNG, PNG image format * gdal_GIF, Graphics Interchange Format * gdal_NETCDF, NetCDF network Common Data Form * gdal_ZARR, ZARR * gdal_FITS, FITS Driver * gdal_HDF5, Hierarchical Data Format Release 5 (HDF5) * gdal_WEBP, WebP * gdal_MBTILES, MBTile * gdal_POSTGISRASTER, PostGIS Raster driver * gdal_JP2OPENJPEG, JPEG2000 driver based on OpenJPEG library * gdal_EXR, EXR support via OpenEXR library * gdal_PCRASTER, PCRaster CSF 2.0 raster file driver * gdal_JPEGXL, JPEG-XL * ogr_GEOJSON, GeoJSON/GeoJSONSeq/ESRIJSON/TopoJSON drivers * ogr_TAB, MapInfo TAB and MIF/MID * ogr_SHAPE, ESRI shape-file * ogr_KML, KML * ogr_VRT, VRT - Virtual Format * ogr_AVC, AVC * ogr_GML, GML * ogr_CSV, CSV * ogr_DGN, DGN * ogr_GMT, GMT * ogr_S57, S57 * ogr_GEORSS, GEORSS * ogr_DXF, DXF * ogr_PGDUMP, PGDump * ogr_GPSBABEL, GPSBABEL * ogr_EDIGEO, EDIGEO * ogr_SXF, SXF * ogr_OPENFILEGDB, OPENFILEGDB * ogr_WASP, WAsP .map format * ogr_SELAFIN, OSELAFIN * ogr_JML, JML * ogr_VDV, VDV-451/VDV-452/INTREST Data Format * ogr_FLATGEOBUF, FlatGeobuf * ogr_MAPML, MapML * ogr_ADBC, ADBC * ogr_MIRAMON, MiraMonVector * ogr_AIVECTOR, AIVector * ogr_JSONFG, JSONFG * ogr_GPX, GPX - GPS Exchange Format * ogr_GMLAS, GMLAS * ogr_NAS, NAS/ALKIS * ogr_IDRISI, IDRISI * ogr_PDS, Planetary Data Systems TABLE * ogr_SQLITE, SQLite3 / Spatialite RDBMS * ogr_GPKG, GeoPackage * ogr_OSM, OpenStreetMap XML and PBF * ogr_VFK, Czech Cadastral Exchange Data Format * ogr_MVT, MVT * ogr_PMTILES, PMTiles * ogr_ILI, ILI * ogr_PG, PostGIS * ogr_MSSQLSPATIAL, MSSQLSPATIAL * ogr_ODBC, ODBC * ogr_PGEO, PGEO * ogr_XLSX, Microsoft Office Excel(xlsx) * ogr_XLS, Microsoft Office Excel(xls) * ogr_CAD, OpenCAD * ogr_GTFS, GTFS * ogr_ODS, ODS * ogr_LVBAG, LVBAG -- The following OPTIONAL packages have been found: * Python (required version >= 3.8) SWIG_PYTHON: Python binding * Threads * ODBC Enable DB support through ODBC * Iconv Character set recoding (used in GDAL portability library) * LibXml2 Read and write XML formats * XercesC Read and write XML formats (needed for GMLAS and ILI drivers) * Deflate Enable libdeflate compression library (complement to ZLib) * OpenSSL Use OpenSSL library * ZSTD, Zstandard - Fast real-time compression algorithm, ZSTD compression library * GIF GIF compression library (external) * JSONC json-c library (external) * PCRE2 Enable PCRE2 support for sqlite3 * SPATIALITE (required version >= 4.1.2) Enable spatialite support for sqlite3 * LibKML Use LIBKML library * HDF5 Enable HDF5 * WebP WebP compression * FreeXL Enable XLS driver * CFITSIO C FITS I/O library * NetCDF (required version >= 4.7) Enable netCDF driver * PostgreSQL * LibLZMA LZMA compression * LZ4 LZ4 compression * Blosc Blosc compression * LIBAEC Adaptive Entropy Coding implementing Golomb-Rice algorithm (used by GRIB) * JXL JPEG-XL compression * JXL_THREADS JPEG-XL threading * OpenEXR OpenEXR >=2.2 * HEIF HEIF >= 1.1 * Poppler (required version >= 0.86), A PDF rendering library, Enable PDF driver with Poppler (read side) * PDFIUM Enable PDF driver with Pdfium (read side) * JNI SWIG_JAVA: Java binding * Java * ZLIB zlib (external) * BISON -- The following RECOMMENDED packages have been found: * EXPAT Read and write XML formats * TIFF (required version >= 4.1), Support for the Tag Image File Format (TIFF)., Support for the Tag Image File Format (TIFF). gdal_GTIFF: GeoTIFF image format gdal_CALS: CALS type 1 driver * GeoTIFF libgeotiff library (external) * QHULL Enable QHULL (external) * LERC Enable LERC (external) * SQLite3 (required version >= 3.31) Enable SQLite3 support (used by SQLite/Spatialite, GPKG, Rasterlite, MBTiles, etc.) * GEOS (required version >= 3.8) Geometry Engine - Open Source (GDAL core dependency) -- The following REQUIRED packages have been found: * PROJ * JPEG JPEG compression library (external) * PNG PNG compression library (external) * OpenJPEG Enable JPEG2000 support with OpenJPEG library -- The following features have been disabled: * gdal_AVIF, AVIF * gdal_MSG, Meteosat Second Generation * gdal_WCS, OGC Web Coverage Service * gdal_HTTP, HTTP driver * gdal_DAAS, Airbus DS Intelligence Data As A Service(DAAS) * gdal_EEDA, Earth Engine Data API * gdal_PLMOSAIC, PLMosaic (Planet Labs Mosaics API) * gdal_WMS, Web Map Services * gdal_OGCAPI, OGCAPI * gdal_GTA, Generic Tagged Arrays * gdal_HDF4, Hierarchical Data Format Release 4 (HDF4) * gdal_DDS, DirectDraw Surface * gdal_KEA, Kea * gdal_TILEDB, TileDB tiledb.io * gdal_BASISU_KTX2, Basis Universal and KTX2 texture formats * gdal_JP2KAK, JPEG-2000 (based on Kakadu) * gdal_JPIPKAK, JPIP Streaming * gdal_MRSID, Multi-resolution Seamless Image Database * gdal_GEOR, Oracle Spatial GeoRaster * gdal_ECW, ERDAS JPEG2000 (.jp2) * ogr_CSW, CSW * ogr_DWG, DWG * ogr_FILEGDB, FileGDB * ogr_LIBKML, LibKML * ogr_PLSCENES, PLSCENES * ogr_SOSI, SOSI:Systematic Organization of Spatial Information * ogr_WFS, OGC WFS service * ogr_OAPIF, OGC API Features service * ogr_NGW, NextGIS Web * ogr_ELASTIC, ElasticSearch * ogr_XODR, OpenDRIVE * ogr_AMIGOCLOUD, AMIGOCLOUD * ogr_CARTO, CARTO * ogr_MYSQL, MySQL * ogr_MONGODBV3, MongoDB V3 * ogr_PARQUET, Parquet * ogr_ARROW, Arrow * ogr_OCI, Oracle OCI * ogr_IDB, IDB * ogr_HANA, SAP HANA -- The following OPTIONAL packages have not been found: * ODBCCPP odbc-cpp library (external) * MSSQL_NCLI MSSQL Native Client to enable bulk copy * MSSQL_ODBC MSSQL ODBC driver to enable bulk copy * MySQL MySQL * CryptoPP Use crypto++ library for CPL. * SFCGAL gdal core supports ISO 19107:2013 and OGC Simple Features Access 1.2 for 3D operations * OpenCAD libopencad (external, used by OpenCAD driver) * BRUNSLI Enable BRUNSLI for JPEG packing in MRF * libQB3 Enable QB3 compression in MRF * RASTERLITE2 (required version >= 1.1.0) Enable RasterLite2 support for sqlite3 * KEA Enable KEA driver * GTA Enable GTA driver * MRSID MrSID raster SDK * Armadillo C++ library for linear algebra (used for TPS transformation) * HDF4 Enable HDF4 driver * ECW Enable ECW driver * FYBA enable ogr_SOSI driver * ARCHIVE Multi-format archive and compression library library (used for /vsi7z/ * Crnlib enable gdal_DDS driver * basisu Enable BASISU driver * IDB enable ogr_IDB driver * TileDB enable TileDB driver * ExprTk Enable C++ Mathematical Expression Tooklit Library (ExprTk) for VRT expressions * MONGOCXX Enable MongoDBV3 driver * AVIF AVIF * HDFS Enable Hadoop File System through native library * Oracle Enable Oracle OCI and GeoRaster drivers * TEIGHA Enable DWG and DGNv8 drivers * FileGDB Enable FileGDB (based on closed-source SDK) driver * KDU Enable KAKADU * OpenDrive Enable libOpenDRIVE * AdbcDriverManager Enable ADBC * Dotnet * CSharp SWIG_CSharp: CSharp binding -- The following RECOMMENDED packages have not been found: * SWIG, Software development tool that connects programs written in C and C++ with a variety of high-level programming languages., * CURL (required version >= 7.68) Enable drivers to use web API * muparser Enable muparser library for VRT expressions -- Disabled components: * LIBKML component has been detected, but is disabled with GDAL_USE_LIBKML=OFF -- Internal libraries enabled: * ZLIB internal library enabled * PNG internal library enabled * OPENCAD internal library enabled -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3965 bytes Desc: not available URL: From foyc at flighttactics.com Mon Nov 10 18:58:58 2025 From: foyc at flighttactics.com (Cory Foy) Date: Mon, 10 Nov 2025 21:58:58 -0500 Subject: [gdal-dev] Trouble enabling MBTiles Driver In-Reply-To: <5671306F-267A-497A-9FE0-F00CC3659980@flighttactics.com> References: <5671306F-267A-497A-9FE0-F00CC3659980@flighttactics.com> Message-ID: <786FEB15-122E-4B90-96B4-4D61AAE0AED7@flighttactics.com> > On Nov 10, 2025, at 12:03?PM, Cory Foy wrote: > > I also don?t see it in the list of drivers using GDALGetDriver after calling GDALAllRegister(): > > ***Found 13 drivers > ***Checking Driver 0: Virtual Raster > ***Checking Driver 1: GeoTIFF > ***Checking Driver 2: Cloud optimized GeoTIFF generator > ***Checking Driver 3: Portable Network Graphics > ***Checking Driver 4: In Memory raster, vector and multidimensional raster > ***Checking Driver 5: Geospatial PDF > ***Checking Driver 6: Geographic Network generic file based model > ***Checking Driver 7: Geographic Network generic DB based model > ***Checking Driver 8: ESRI Shapefile > ***Checking Driver 9: GeoJSON > ***Checking Driver 10: GeoJSON Sequence > ***Checking Driver 11: ESRIJSON > ***Checking Driver 12: TopoJSON > > It does look like it?s enabled in the build, though (I?ll paste the build output below) but I wonder if some other driver I?m missing is not enabled which is causing it to not be enabled in the final build. Is there something I?m maybe missing here? This was my clue that something was *not* right with my build. It turns out my build was fine, but I have to kind of finish the build loop to generate the actual .a file to include in the rest of my build steps if I want the changes to make it to my application. In other words, it helps to actually _build_ the output of the first cmake command if I want the library files. Sorry for the noise! Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3965 bytes Desc: not available URL: From henry at floodmapp.com Wed Nov 12 21:49:31 2025 From: henry at floodmapp.com (Henry Walshaw) Date: Thu, 13 Nov 2025 05:49:31 +0000 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation Message-ID: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Hi all, In the docs for gdal raster calc (https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc) it states Input rasters will be converted to 64-bit floating point numbers before performing calculations. However I?ve found that when using an integer output datatype the base data is rounded to an integer before performing the calculation. e.g. converting a flood depth input.tif raster to a simple water / no water footprint: gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte The expected result for a value of (say) 0.1 is 1, but in the above calculation it comes out as 0. Obviously I can leave the output datatype alone so it stays the same as the input?s 64-bit float, but it seems unnecessary. Am I looking at a bug, or is this expected behaviour? Regards, Henry ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Thu Nov 13 06:40:24 2025 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 13 Nov 2025 09:40:24 -0500 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation In-Reply-To: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> References: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Message-ID: Hi Henry, The input values should not be rounded before doing the calculation. I get a correct result with both 3.12 and 3.11.5: $ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 depth.tif $ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte $ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ ERROR 6: Read or update mode not supported on /vsistdout 0.5 0.5 1 Dan On Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi all, > > In the docs for gdal raster calc ( > https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc > ) it states > > Input rasters will be converted to 64-bit floating point numbers before > performing calculations. > > However I?ve found that when using an integer output datatype the base > data is rounded to an integer before performing the calculation. e.g. > converting a flood depth input.tif raster to a simple water / no water > footprint: > > > gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte > > The expected result for a value of (say) 0.1 is 1, but in the above > calculation it comes out as 0. Obviously I can leave the output datatype > alone so it stays the same as the input?s 64-bit float, but it seems > unnecessary. Am I looking at a bug, or is this expected behaviour? > > Regards, > > Henry > ​ > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Thu Nov 13 06:46:04 2025 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Thu, 13 Nov 2025 14:46:04 +0000 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation In-Reply-To: References: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Message-ID: Hi, I think I do not understand something simple, but how a byte type pixel can have one half as a value? 0.5 0.5 1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Daniel Baston via gdal-dev puolesta L?hetetty: Torstai 13. marraskuuta 2025 16.40 Vastaanottaja: Henry Walshaw Kopio: gdal-dev at lists.osgeo.org Aihe: Re: [gdal-dev] GDAL CLI converting to output datatype before performing calculation Hi Henry,The input values should not be rounded before doing the calculation. I get a correct result with both 3.12 and 3.11.5:$ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 depth.tif$ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte$ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ERROR 6: Read or update mode not supported on /vsistdout0.5 0.5 1DanOn Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via gdal-dev wrote:Hi all,In the docs for gdal raster calc (https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc) it statesInput rasters will be converted to 64-bit floating point numbers before performing calculations.However I?ve found that when using an integer output datatype the base data is rounded to an integer before performing the calculation. e.g. converting a flood depth input.tif raster to a simple water / no water footprint: gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte The expected result for a value of (say) 0.1 is 1, but in the above calculation it comes out as 0. Obviously I can leave the output datatype alone so it stays the same as the input?s 64-bit float, but it seems unnecessary. Am I looking at a bug, or is this expected behaviour?Regards,Henry​_______________________________________________gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev From dbaston at gmail.com Thu Nov 13 07:02:43 2025 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 13 Nov 2025 10:02:43 -0500 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation In-Reply-To: References: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Message-ID: It's a single-pixel raster. The first two values printed are the cell center coordinates (0.5, 0.5), followed by the cell value (1). Dan On Thu, Nov 13, 2025 at 9:46?AM Rahkonen Jukka < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > I think I do not understand something simple, but how a byte type pixel > can have one half as a value? > > 0.5 0.5 1 > > -Jukka Rahkonen- > ________________________________________ > L?hett?j?: gdal-dev k?ytt?j?n Daniel > Baston via gdal-dev puolesta > L?hetetty: Torstai 13. marraskuuta 2025 16.40 > Vastaanottaja: Henry Walshaw > Kopio: gdal-dev at lists.osgeo.org > Aihe: Re: [gdal-dev] GDAL CLI converting to output datatype before > performing calculation > > Hi Henry,The input values should not be rounded before doing the > calculation. I get a correct result with both 3.12 and 3.11.5:$ gdal raster > create --size 1,1 --burn 0.1 --output-data-type Float64 depth.tif$ gdal > raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" > --nodata none --ot Byte$ gdal raster convert footprint_b.tif > --output-format XYZ /vsistdout/ERROR 6: Read or update mode not supported > on /vsistdout0.5 0.5 1DanOn Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via > gdal-dev wrote:Hi all,In the docs for gdal > raster calc ( > https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc) > it statesInput rasters will be converted to 64-bit floating point numbers > before performing calculations.However I?ve found that when using an > integer output datatype the base data is rounded to an integer before > performing the calculation. e.g. converting a flood depth input.tif raster > to a simple water / no water footprint: > gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : > 0" --nodata none --ot Byte > The expected result for a value of (say) 0.1 is 1, but in the above > calculation it comes out as 0. Obviously I can leave the output datatype > alone so it stays the same as the input?s 64-bit float, but it seems > unnecessary. Am I looking at a bug, or is this expected > behaviour?Regards,Henry​_______________________________________________gdal-dev > mailing listgdal-dev at lists.osgeo.orghttps:// > lists.osgeo.org/mailman/listinfo/gdal-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry at floodmapp.com Thu Nov 13 17:31:56 2025 From: henry at floodmapp.com (Henry Walshaw) Date: Fri, 14 Nov 2025 01:31:56 +0000 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation In-Reply-To: References: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Message-ID: Thanks for the example Daniel. I can confirm if I try the same task as you with the 1 pixel raster I do get the result as expected. Unfortunately for the actual data it doesn?t hold true. Using a sample.tif available here: https://www.dropbox.com/scl/fi/fdj4acszchg0ao132kf6g/sample.tif?rlkey=ro5mgecpdp4oqcv0kljfh0go3&st=er04s2mm&dl=0 I can try the following (The Q text as data tool is what I?m using to do the quick calc at the end: https://harelba.github.io/q/ ) $ gdal raster convert sample.tif --output-format XYZ cells.txt $ q "select count(*) from cells.txt where c3 > 0" 22829 $ q "select count(*) from cells.txt where c3 >= 0.5" 11518 $ gdal raster calc -i "A=sample.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte $ gdal raster convert footprint.tif --output-format XYZ footprint_cells.txt $ q "select count(*) from footprint_cells.txt where c3 = 1" 11518 So you can see that the rounding in this case is happening before the calculation. For what it?s worth I?m running GDAL off the latest alpine container ghcr.io/osgeo/gdal:alpine-normal-latest, so $ gdal --version GDAL 3.13.0dev-fbde9c11c976a693992f7688ecf324dd11e190f1, released 2025/11/12 Hopefully it?s just a bug on my end! On 14/11/25 01:40, Daniel Baston wrote: Hi Henry, The input values should not be rounded before doing the calculation. I get a correct result with both 3.12 and 3.11.5: $ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 depth.tif $ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte $ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ ERROR 6: Read or update mode not supported on /vsistdout 0.5 0.5 1 Dan On Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via gdal-dev > wrote: Hi all, In the docs for gdal raster calc (https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc) it states Input rasters will be converted to 64-bit floating point numbers before performing calculations. However I?ve found that when using an integer output datatype the base data is rounded to an integer before performing the calculation. e.g. converting a flood depth input.tif raster to a simple water / no water footprint: gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte The expected result for a value of (say) 0.1 is 1, but in the above calculation it comes out as 0. Obviously I can leave the output datatype alone so it stays the same as the input?s 64-bit float, but it seems unnecessary. Am I looking at a bug, or is this expected behaviour? Regards, Henry ​ _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Thu Nov 13 18:42:55 2025 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 13 Nov 2025 21:42:55 -0500 Subject: [gdal-dev] GDAL CLI converting to output datatype before performing calculation In-Reply-To: References: <40793773-1517-4c8c-a3ea-6053cec2221d@floodmapp.com> Message-ID: Henry, Thanks for the example. This looks like a bug in GDAL 3.12, affecting calculations where the input has a NoData value. The simplest workaround I see for now is to rewrite the command as a pipeline: gdal raster pipeline calc -i "A=sample.tif" --calc "A > 0 ? 1 : 0" --nodata none ! materialize ! set-type --ot Byte ! write footprint_b.tif --overwrite Dan On Thu, Nov 13, 2025 at 8:32?PM Henry Walshaw wrote: > Thanks for the example Daniel. I can confirm if I try the same task as you > with the 1 pixel raster I do get the result as expected. Unfortunately for > the actual data it doesn?t hold true. Using a sample.tif available here: > https://www.dropbox.com/scl/fi/fdj4acszchg0ao132kf6g/sample.tif?rlkey=ro5mgecpdp4oqcv0kljfh0go3&st=er04s2mm&dl=0 > > I can try the following (The Q text as data tool is what I?m using to do > the quick calc at the end: https://harelba.github.io/q/ ) > > > $ gdal raster convert sample.tif --output-format XYZ cells.txt > > $ q "select count(*) from cells.txt where c3 > 0" > > 22829 > > $ q "select count(*) from cells.txt where c3 >= 0.5" > > 11518 > > $ gdal raster calc -i "A=sample.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte > > $ gdal raster convert footprint.tif --output-format XYZ footprint_cells.txt > > $ q "select count(*) from footprint_cells.txt where c3 = 1" > > 11518 > > So you can see that the rounding in this case is happening before the > calculation. For what it?s worth I?m running GDAL off the latest alpine > container ghcr.io/osgeo/gdal:alpine-normal-latest, so > > > $ gdal --version > > GDAL 3.13.0dev-fbde9c11c976a693992f7688ecf324dd11e190f1, released 2025/11/12 > > Hopefully it?s just a bug on my end! > > On 14/11/25 01:40, Daniel Baston wrote: > > Hi Henry, > > The input values should not be rounded before doing the calculation. I get > a correct result with both 3.12 and 3.11.5: > > $ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 > depth.tif > $ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : > 0" --nodata none --ot Byte > $ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ > ERROR 6: Read or update mode not supported on /vsistdout > 0.5 0.5 1 > > Dan > > On Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi all, >> >> In the docs for gdal raster calc ( >> https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc >> ) it states >> >> Input rasters will be converted to 64-bit floating point numbers before >> performing calculations. >> >> However I?ve found that when using an integer output datatype the base >> data is rounded to an integer before performing the calculation. e.g. >> converting a flood depth input.tif raster to a simple water / no water >> footprint: >> >> >> gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 : 0" --nodata none --ot Byte >> >> The expected result for a value of (say) 0.1 is 1, but in the above >> calculation it comes out as 0. Obviously I can leave the output datatype >> alone so it stays the same as the input?s 64-bit float, but it seems >> unnecessary. Am I looking at a bug, or is this expected behaviour? >> >> Regards, >> >> Henry >> ​ >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > ​ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj10777 at googlemail.com Thu Nov 13 20:54:27 2025 From: mj10777 at googlemail.com (Mark Johnson) Date: Fri, 14 Nov 2025 05:54:27 +0100 Subject: [gdal-dev] gdal-dev Digest, Vol 258, Issue 14 In-Reply-To: References: Message-ID: schrieb am Fr., 14. Nov. 2025, 03:43: > Send gdal-dev mailing list submissions to > gdal-dev at lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > gdal-dev-request at lists.osgeo.org > > You can reach the person managing the list at > gdal-dev-owner at lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. Re: GDAL CLI converting to output datatype before performing > calculation (Daniel Baston) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Nov 2025 21:42:55 -0500 > From: Daniel Baston > To: Henry Walshaw > Cc: "gdal-dev at lists.osgeo.org" > Subject: Re: [gdal-dev] GDAL CLI converting to output datatype before > performing calculation > Message-ID: > 47w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Henry, > > Thanks for the example. This looks like a bug in GDAL 3.12, affecting > calculations where the input has a NoData value. The simplest workaround I > see for now is to rewrite the command as a pipeline: > > gdal raster pipeline calc -i "A=sample.tif" --calc "A > 0 ? 1 : 0" --nodata > none ! materialize ! set-type --ot Byte ! write footprint_b.tif --overwrite > > Dan > > On Thu, Nov 13, 2025 at 8:32?PM Henry Walshaw wrote: > > > Thanks for the example Daniel. I can confirm if I try the same task as > you > > with the 1 pixel raster I do get the result as expected. Unfortunately > for > > the actual data it doesn?t hold true. Using a sample.tif available here: > > > https://www.dropbox.com/scl/fi/fdj4acszchg0ao132kf6g/sample.tif?rlkey=ro5mgecpdp4oqcv0kljfh0go3&st=er04s2mm&dl=0 > > > > I can try the following (The Q text as data tool is what I?m using to do > > the quick calc at the end: https://harelba.github.io/q/ ) > > > > > > $ gdal raster convert sample.tif --output-format XYZ cells.txt > > > > $ q "select count(*) from cells.txt where c3 > 0" > > > > 22829 > > > > $ q "select count(*) from cells.txt where c3 >= 0.5" > > > > 11518 > > > > $ gdal raster calc -i "A=sample.tif" -o footprint_b.tif --calc "A > 0 ? > 1 : 0" --nodata none --ot Byte > > > > $ gdal raster convert footprint.tif --output-format XYZ > footprint_cells.txt > > > > $ q "select count(*) from footprint_cells.txt where c3 = 1" > > > > 11518 > > > > So you can see that the rounding in this case is happening before the > > calculation. For what it?s worth I?m running GDAL off the latest alpine > > container ghcr.io/osgeo/gdal:alpine-normal-latest, so > > > > > > $ gdal --version > > > > GDAL 3.13.0dev-fbde9c11c976a693992f7688ecf324dd11e190f1, released > 2025/11/12 > > > > Hopefully it?s just a bug on my end! > > > > On 14/11/25 01:40, Daniel Baston wrote: > > > > Hi Henry, > > > > The input values should not be rounded before doing the calculation. I > get > > a correct result with both 3.12 and 3.11.5: > > > > $ gdal raster create --size 1,1 --burn 0.1 --output-data-type Float64 > > depth.tif > > $ gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 > : > > 0" --nodata none --ot Byte > > $ gdal raster convert footprint_b.tif --output-format XYZ /vsistdout/ > > ERROR 6: Read or update mode not supported on /vsistdout > > 0.5 0.5 1 > > > > Dan > > > > On Thu, Nov 13, 2025 at 12:49?AM Henry Walshaw via gdal-dev < > > gdal-dev at lists.osgeo.org> wrote: > > > >> Hi all, > >> > >> In the docs for gdal raster calc ( > >> > https://gdal.org/en/stable/programs/gdal_raster_calc.html#cmdoption-calc > >> ) it states > >> > >> Input rasters will be converted to 64-bit floating point numbers before > >> performing calculations. > >> > >> However I?ve found that when using an integer output datatype the base > >> data is rounded to an integer before performing the calculation. e.g. > >> converting a flood depth input.tif raster to a simple water / no water > >> footprint: > >> > >> > >> gdal raster calc -i "A=depth.tif" -o footprint_b.tif --calc "A > 0 ? 1 > : 0" --nodata none --ot Byte > >> > >> The expected result for a value of (say) 0.1 is 1, but in the above > >> calculation it comes out as 0. Obviously I can leave the output datatype > >> alone so it stays the same as the input?s 64-bit float, but it seems > >> unnecessary. Am I looking at a bug, or is this expected behaviour? > >> > >> Regards, > >> > >> Henry > >> ​ > >> _______________________________________________ > >> gdal-dev mailing list > >> gdal-dev at lists.osgeo.org > >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > >> > > ​ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251113/68dd5567/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > ------------------------------ > > End of gdal-dev Digest, Vol 258, Issue 14 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.lucena at outlook.com Fri Nov 14 10:34:01 2025 From: ivan.lucena at outlook.com (Ivan Lucena) Date: Fri, 14 Nov 2025 18:34:01 +0000 Subject: [gdal-dev] Build issues in Linux, gnu GCC 8.5.0 Message-ID: Hi folks, I build GDAL 3.12 in Linux using GCC 8.5 and got 3 instance of "unique_ptr of a forward-declared class". It wasn't a big problem to solve, as you can see in the "git diff" report below. I am not sure but it seems like that issue should be resolved by updating the compile too. Anyway, for folks that might have that same problem, all I had to do is to add the following "#include" statements. It should be harmless. Everything seems to be working fine. Best regards, Ivan $ git diff diff --git a/apps/gdalalg_vector_pipeline.h b/apps/gdalalg_vector_pipeline.h index 87ed7c045c..ed44fdb513 100644 --- a/apps/gdalalg_vector_pipeline.h +++ b/apps/gdalalg_vector_pipeline.h @@ -22,6 +22,8 @@ #include #include +#include "memdataset.h" + //! @cond Doxygen_Suppress /************************************************************************/ diff --git a/frmts/vrt/vrtdataset.h b/frmts/vrt/vrtdataset.h index bcc4d30790..677b23d398 100644 --- a/frmts/vrt/vrtdataset.h +++ b/frmts/vrt/vrtdataset.h @@ -24,6 +24,8 @@ #include "gdal_vrt.h" #include "gdal_rat.h" +#include "gdalpansharpen.h" + #include #include #include diff --git a/gcore/gdal_multidim.h b/gcore/gdal_multidim.h index 8c5d9f9037..7c45a76f41 100644 --- a/gcore/gdal_multidim.h +++ b/gcore/gdal_multidim.h @@ -25,6 +25,8 @@ #include #include +#include "gdal_rat.h" + /* ******************************************************************** */ /* Multidimensional array API */ /* ******************************************************************** */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at postholer.com Fri Nov 14 12:17:03 2025 From: public at postholer.com (Scott) Date: Fri, 14 Nov 2025 12:17:03 -0800 Subject: [gdal-dev] Working with gdal mdim In-Reply-To: References: Message-ID: <52fd727b-52b3-4c19-9476-ef1477db7d66@postholer.com> Greetings, With gdal mdim convert, is it possible to get subsets using a time range with GRIB? Also, should I be concerned with these errors? The data source is a GRIB/GRIdded Binary (.grb, .grb2), using GDAL v3.12.0 Getting valid time slices remotely works fine. Part of the output is shown. Note, this file changes frequently, so the times may be different if you run this command: gdal mdim info /vsicurl/https://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/VP.001-003/ds.qpf.bin --array TIME --detailed "unit": "sec UTC", "values": [1763164800, 1763186400, 1763208000, 1763229600, 1763251200, 1763272800, 1763294400, 1763316000, 1763337600, 1763359200, 1763380800] Converting to .tif using a single time slice, I get this error, but resulting file seems to be OK. If I download the entire ds.qpf.bin first and run with the local file, no errors. gdal mdim convert /vsicurl/https://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/VP.001-003/ds.qpf.bin tst.tif --subset 'TIME("1763164800")' --array QPF_0-SFC --co COMPRESS=DEFLATE --overwrite --quiet ERROR 1: JSON parsing error: continue (at offset 0) ERROR 1: JSON parsing error: continue (at offset 0) ERROR 1: JSON parsing error: continue (at offset 0) ERROR 1: JSON parsing error: continue (at offset 0) Trying to get a range of subsets based on time always fails. Is getting a range like this correct/possible? gdal mdim convert ds.qpf.bin tst.tif --subset 'TIME("1763164800,1763251200")' --array QPF_0-SFC --co COMPRESS=DEFLATE --overwrite ERROR 1: Non numeric bound in subset specification. Thanks for any help! Scott From even.rouault at spatialys.com Fri Nov 14 15:13:37 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 15 Nov 2025 00:13:37 +0100 Subject: [gdal-dev] Working with gdal mdim In-Reply-To: <52fd727b-52b3-4c19-9476-ef1477db7d66@postholer.com> References: <52fd727b-52b3-4c19-9476-ef1477db7d66@postholer.com> Message-ID: <6651fdcd-baaf-4bfe-b3a7-72d7403cb5b6@spatialys.com> Scott, > > ?? gdal mdim convert > /vsicurl/https://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/VP.001-003/ds.qpf.bin > tst.tif --subset 'TIME("1763164800")' --array QPF_0-SFC --co > COMPRESS=DEFLATE --overwrite --quiet > > ?? ERROR 1: JSON parsing error: continue (at offset 0) > ?? ERROR 1: JSON parsing error: continue (at offset 0) > ?? ERROR 1: JSON parsing error: continue (at offset 0) > ?? ERROR 1: JSON parsing error: continue (at offset 0) You can safely ignore it (or avoid it by adding --config GDAL_SKIP ZARR, although this is not a Zarr issue, just the trigger). Fixed per https://github.com/OSGeo/gdal/commit/0f889cea1395ebee62630653bc0fa505c4f0c6df > > Trying to get a range of subsets based on time always fails. Is > getting a range like this correct/possible? > > ?? gdal mdim convert ds.qpf.bin tst.tif --subset > 'TIME("1763164800,1763251200")' --array QPF_0-SFC --co > COMPRESS=DEFLATE --overwrite > > ?? ERROR 1: Non numeric bound in subset specification. Ah this is a bit tricky. You shouldn't put double quotes around the range as this is numeric values. $ gdal mdim convert /vsicurl/https://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/VP.001-003/ds.qpf.bin tst.tif --subset 'TIME(1763164800,1763251200)' --array QPF_0-SFC --co COMPRESS=DEFLATE --overwrite But there was actually a bug, which will be fixed per https://github.com/OSGeo/gdal/pull/13420 Even -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Fri Nov 14 15:35:08 2025 From: public at postholer.com (Scott) Date: Fri, 14 Nov 2025 15:35:08 -0800 Subject: [gdal-dev] Working with gdal mdim In-Reply-To: <6651fdcd-baaf-4bfe-b3a7-72d7403cb5b6@spatialys.com> References: <52fd727b-52b3-4c19-9476-ef1477db7d66@postholer.com> <6651fdcd-baaf-4bfe-b3a7-72d7403cb5b6@spatialys.com> Message-ID: <00fa9ebf-b58b-48cb-95d2-ac0a255f0f83@postholer.com> Thanks for the quick fix, Even! Yeah, I tried everything, quotes, no quotes, colon, commas, but it would only accept 1 slice. In the end, I came up with a real hack-ish work around; reading all the GRIB_VALID_TIME's from gdal raster info | jq and building a csv band list and passing it to --bands in gdal raster select. Ironically, this worked so well you can build a band list from any meta data key=values, just changing jq params. Selecting bands by meta data would make a pretty cool feature. ;) bands=$( \ gdal raster info $rast -json \ | sed 's/"":/"item":/g' \ | jq ".bands[] \ | select((.metadata.item.GRIB_VALID_TIME \ | tonumber >= ${starttime}) and (.metadata.item.GRIB_VALID_TIME | tonumber <= ${endtime})).band" \ | tr "\n" "," |sed 's/,$//' \ ) Thanks again, Scott On 11/14/25 15:13, Even Rouault wrote: > Ah this is a bit tricky. You shouldn't put double quotes around the > range as this is numeric values. From public at postholer.com Sat Nov 15 11:45:58 2025 From: public at postholer.com (Scott) Date: Sat, 15 Nov 2025 11:45:58 -0800 Subject: [gdal-dev] gdal rasterize vs resize Message-ID: <61feccf4-0375-4b15-9512-584ab2e97e65@postholer.com> Greetings, When using gdal raster resize I can use --size 0,800 and it will compute the width. However, when using gdal vector rasterize --size 0,800 it throws the error: ERROR 1: Wrong value for -ts parameter. Having it compute the missing value is highly desirable! GDAL v3.12.0 Thanks! Scott -- www.postholer.com