From even.rouault at spatialys.com Mon Jun 1 07:27:55 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 1 Jun 2026 16:27:55 +0200 Subject: [gdal-dev] GDAL 3.13.1 RC1 available Message-ID: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> Hi, I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. Pick up an archive among the following ones (by ascending size): ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig A snapshot of the gdalautotest suite is also available: https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip The NEWS file is here: ? https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md Even -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Mon Jun 1 08:40:29 2026 From: public at postholer.com (Scott) Date: Mon, 1 Jun 2026 08:40:29 -0700 Subject: [gdal-dev] GDAL 3.13.1 RC1 available In-Reply-To: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> Message-ID: <6d131d79-a7d5-4f10-a651-99c7d76b0db0@postholer.com> In the NEWS file it mentions 'gdal pipeline replay'. That's new to me and I can't find it in the docs: https://gdal.org/en/latest/programs/ Any suggestions? Thanks! Scott On 6/1/26 07:27, Even Rouault via gdal-dev wrote: > Hi, > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > Pick up an archive among the following ones (by ascending size): > > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > A snapshot of the gdalautotest suite is also available: > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > The NEWS file is here: > > ? https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > 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 even.rouault at spatialys.com Mon Jun 1 08:45:24 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 1 Jun 2026 17:45:24 +0200 Subject: [gdal-dev] GDAL 3.13.1 RC1 available In-Reply-To: <6d131d79-a7d5-4f10-a651-99c7d76b0db0@postholer.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <6d131d79-a7d5-4f10-a651-99c7d76b0db0@postholer.com> Message-ID: <5cd01a67-20a3-41b0-b378-a653c9638186@spatialys.com> Le 01/06/2026 ? 17:40, Scott via gdal-dev a ?crit?: > In the NEWS file it mentions 'gdal pipeline replay'. That's new to me > and I can't find it in the docs: 'replay' is not a command, but just a shortcut in the commit message for https://gdal.org/en/latest/programs/gdal_pipeline.html#substitutions -- http://www.spatialys.com My software is free, but my time generally not. From public at postholer.com Mon Jun 1 08:57:39 2026 From: public at postholer.com (Scott) Date: Mon, 1 Jun 2026 08:57:39 -0700 Subject: [gdal-dev] GDAL 3.13.1 RC1 available In-Reply-To: <5cd01a67-20a3-41b0-b378-a653c9638186@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <6d131d79-a7d5-4f10-a651-99c7d76b0db0@postholer.com> <5cd01a67-20a3-41b0-b378-a653c9638186@spatialys.com> Message-ID: Got it, thanks! On 6/1/26 08:45, Even Rouault wrote: > > Le 01/06/2026 ? 17:40, Scott via gdal-dev a ?crit?: >> In the NEWS file it mentions 'gdal pipeline replay'. That's new to me >> and I can't find it in the docs: > > 'replay' is not a command, but just a shortcut in the commit message for > https://gdal.org/en/latest/programs/gdal_pipeline.html#substitutions > > From howard at hobu.co Mon Jun 1 12:37:13 2026 From: howard at hobu.co (Howard Butler) Date: Mon, 1 Jun 2026 14:37:13 -0500 Subject: [gdal-dev] GDAL Maintainers Meeting Minutes Message-ID: <83120CB9-66C0-4F33-BBC8-8970346A4529@hobu.co> Howard Butler, Dan Baston, Alessandro Pasotti, Chris Toney, Michael Smith, Even Rouault, Seth Girvin, Michael Sumner, and Javier Jimenez Shaw held the monthly GDAL Maintainers Meeting on 05/28/2026. The following items were discussed and reported upon: # Project News * Authenticated VSI activity within cloud organizations that are not sponsoring GDAL now emits a log message about it. See https://gdal.org/en/latest/sponsors/cloud_phone_home.html for details about it. * The GDAL LLM Project Policy is now active https://gdal.org/en/stable/community/ai_tool_policy.html * A change is going to come "fixing" advertisement of multi geometry types in the OGR shapefile driver https://github.com/OSGeo/gdal/pull/14602 ## Releases * GDAL 3.13.0 "Iowa City" is now available https://github.com/OSGeo/gdal/releases/tag/v3.13.0 Release notes are available at https://github.com/OSGeo/gdal/blob/v3.13.0/NEWS.md ## Conferences * Even and Seth will be giving the newly created GDAL Command Line Workshop at FOSS4GE in Timisoara, Romania on July 3rd, 2026. It will include exercises on tiling, merging, VSI, pixel operations, multidim, and more! See https://2026.europe.foss4g.org/schedule/workshops/ for details and get your ticket at https://pretix.geo-spatial.org/foss4ge2026/timisoara2026/ * Even will be giving "State of GDAL: What's new in GDAL 3.12 and 3.13" on June 29th, 2026 at FOSS4GE https://talks.osgeo.org/foss4g-europe-2026/talk/9AQJYA/ * Javier will be presenting "PROJ is not only about projections" on June 30th, 2026 at FOSS4GE. https://talks.osgeo.org/foss4g-europe-2026/talk/SSCMFH/ * Howard will present "Building the GDAL Sponsorship Program" at FOSS4G Hiroshima on September 1st, 2026 https://talks.osgeo.org/foss4g-2026/talk/8YFSA8/ * FOSS4GNA will be November 2-4, 2026. Call for proposals is now open! https://www.foss4gna.org/cfp-2026 # Maintenance activities update ## Alessandro * ``gdal raster proximity`` doc https://github.com/OSGeo/gdal/issues/14522 * ``gdal vector export-schema`` https://github.com/OSGeo/gdal/issues/14640 ## Seth ### Two new user- orientated pages * https://gdal.org/en/latest/user/errors.html * https://gdal.org/en/latest/user/debug.html ### Examples and testing of ``export-schema``: * https://gdal.org/en/latest/programs/gdal_vector_export_schema.html ### Updated pipeline table of contents for pipelines * https://gdal.org/en/latest/programs/gdal_raster_pipeline.html#steps * https://gdal.org/en/latest/programs/gdal_vector_pipeline.html#steps ### MSSQL driver examples * https://gdal.org/en/latest/drivers/vector/mssqlspatial.html#drivers/vector/mssqlspatial-4 ## Dan * AI security report activity ? NetCDF and GRIB * ``gdal vector read`` now supports WKT https://github.com/OSGeo/gdal/pull/14499 * ``gdal vector explode[collections]`` support for after zonal ## Even * GDAL 3.13.0 release * 100+ items. 5000+ "little attention" items since beginning of the sponsorship program! * ~10 Anthropic Mythos security topics ? concentrated in NetCDF and GRIB * PROJ ETRS89 issues and fallout continues ? EPSG now reverting incompatible changes * Shapefile multi advertisement https://github.com/OSGeo/gdal/pull/14602 * GDAL CLI Workshop preparation ? content to be made available online after the conference, potentially included directly in GDAL docs * GDAL 3.13.1 release imminent * Discussion about vendoring and maintenance of PhoenixLidar's libkml fork/updates https://github.com/phoenixlidar/libkml/ for a path forward for OGR KML * GDAL LLM Project Policy https://gdal.org/en/stable/community/ai_tool_policy.html * Planning to attend the June 18th arrow+parquet meetup in Paris # Next Meeting The next GDAL Maintainers Meeting is 06/25/2026 at 13:00 UTC. Project contributors should contact Howard Butler for an invite. # Online Version https://gist.github.com/hobu/1e65ec518b737772b24af6174ad829fd # Financial Support * Support GDAL with a new t-shirt! Visit https://gdal.org/tshirt/ to purchase. Change your country preference on the bottom of the page. Profits from swag sales go directly to the GDAL Sponsorship Program via NumFOCUS! * Make an individual or corporate donation online https://numfocus.org/donate-to-gdal * Organize a contribution to the GDAL Sponsorship Program https://gdal.org/en/latest/sponsors/index.html#sponsorship-program From mdsumner at gmail.com Tue Jun 2 08:11:47 2026 From: mdsumner at gmail.com (Michael Sumner) Date: Wed, 3 Jun 2026 01:11:47 +1000 Subject: [gdal-dev] Status and future of the GDAL GNM and image correlator In-Reply-To: <84b4fd87-22fd-43f1-b137-1b18087e1a61@spatialys.com> References: <84b4fd87-22fd-43f1-b137-1b18087e1a61@spatialys.com> Message-ID: Very recently {terra} has added SpatNetwork which utilizes/works-with GNM: https://github.com/rspatial/terra/blob/master/src/spatNetwork_gnm.cpp so that might be of interest. Cheers, Mike On Wed, May 27, 2026 at 6:26?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi Alex, > > More than ten years ago, two features were added to GDAL during GSoC > > projects: the raster correlator [0] and support for the Geographic > > Network Model (GNM) [1]. Both features seem to have remained > > limited/experimental, with almost no activity except for code > > formatting and compilation fixes. > True > > As far as I know, they also are > > rarely included in default builds by major distributions/packages, > Are you sure about that ? The raster correlator is part of the build and > cannot be disabled easily, and even if GNM can be disabled, it is on by > default. Debian or conda-forge builds include it for example > > the correlator API is not exposed via SWIG. > True > > > > I wonder what is the status and future of this code? Are there any > > plans to improve and expose it, or is the project leaning toward > > deprecation and removal to reduce maintenance overhead? > > I was also wondering lately. We also don't see bug reports or questions > related to them, so they might be little used. > > And the fact that gnmanalyze & gnmmanage haven't been ported to the new > CLI will not help build awareness around them. > > Those features don't get that much in our way so there's no immediate > need to consider deprecation > > > In the past I developed an experimental QGIS plugin that uses GDAL GNM > > via Python bindings and considered exposing the correlator as well. > In the same plugin ? > > I would love to hear your thoughts on the future of these two features > > before investing further into plugins, and potentially to the GDAL. > > It might be a chicken & egg problem: not enough exposed ==> not enough > used ==> no feedback ==> no change. > > But what's true is that the original developers are apparently no longer > available (I pinged recently for a GNM related pull request and got no > feedback). > > Even > > -- > Very grumpy about LLMs: FOSS is about increasing public capital, > not becoming enslaved to private equity of giga corporations > -- > 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 > -- Michael Sumner Research Software Engineer Australian Antarctic Division Hobart, Australia 0438489030 e-mail: mdsumner at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Jun 2 23:38:01 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 3 Jun 2026 08:38:01 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> Message-ID: <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> Hi, Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 +1 Even Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit?: > Hi, > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > Pick up an archive among the following ones (by ascending size): > > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > A snapshot of the gdalautotest suite is also available: > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > The NEWS file is here: > > ? https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > 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 -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Tue Jun 2 23:54:48 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 3 Jun 2026 08:54:48 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> Message-ID: +1 Javier On Wed, 3 Jun 2026, 08:38 Even Rouault via gdal-dev, < gdal-dev at lists.osgeo.org> wrote: > Hi, > > Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 > > +1 > > Even > > Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit : > > Hi, > > > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > > > Pick up an archive among the following ones (by ascending size): > > > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > > > A snapshot of the gdalautotest suite is also available: > > > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > > > The NEWS file is here: > > > > https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > > > 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 > > -- > 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 Jun 3 02:21:10 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 03 Jun 2026 05:21:10 -0400 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> Message-ID: +1 Mike ?On 6/3/26, 2:38 AM, "gdal-dev on behalf of Even Rouault via gdal-dev" on behalf of gdal-dev at lists.osgeo.org > wrote: Hi, Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 +1 Even Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit : > Hi, > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > Pick up an archive among the following ones (by ascending size): > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > A snapshot of the gdalautotest suite is also available: > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > The NEWS file is here: > > https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > 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 -- 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 Jun 3 14:04:05 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Wed, 3 Jun 2026 21:04:05 +0000 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <925e5b31-77a9-4990-8856-4c0777ba7e02@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 3. kes?kuuta 2026 9.38 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) Hi, Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 +1 Even Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit : > Hi, > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > Pick up an archive among the following ones (by ascending size): > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > A snapshot of the gdalautotest suite is also available: > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > The NEWS file is here: > > https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > 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 -- 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 dbaston at gmail.com Thu Jun 4 14:45:05 2026 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 4 Jun 2026 17:45:05 -0400 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> Message-ID: +1 Dan On Wed, Jun 3, 2026 at 5:04?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 3. kes?kuuta 2026 9.38 > Vastaanottaja: gdal-dev at lists.osgeo.org > Aihe: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 > available) > > > Hi, > > Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 > > +1 > > Even > > Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit : > > Hi, > > > > I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. > > > > Pick up an archive among the following ones (by ascending size): > > > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig > > > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig > > > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 > > https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig > > > > A snapshot of the gdalautotest suite is also available: > > > > https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip > > > > The NEWS file is here: > > > > https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md > > > > 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 > > -- > 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 even.rouault at spatialys.com Fri Jun 5 03:27:10 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 5 Jun 2026 12:27:10 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.1 RC1 (Re: GDAL 3.13.1 RC1 available) In-Reply-To: <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> References: <10b85119-3d94-4f60-b033-d31fe744b1f1@spatialys.com> <925e5b31-77a9-4990-8856-4c0777ba7e02@spatialys.com> Message-ID: <24d87440-b713-4c03-9dde-d7448862edb1@spatialys.com> Passed with +1 from PSC members JavierJS, MikeS, JukkaR, DanB and me Le 03/06/2026 ? 08:38, Even Rouault via gdal-dev a ?crit?: > Hi, > > Motion: approve GDAL 3.13.1 RC1 as final 3.13.1 > > +1 > > Even > > Le 01/06/2026 ? 16:27, Even Rouault via gdal-dev a ?crit?: >> Hi, >> >> I have prepared a GDAL/OGR 3.13.1 bugfix release candidate. >> >> Pick up an archive among the following ones (by ascending size): >> >> ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz >> https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.md5 >> https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.xz.sig >> >> ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz >> https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.md5 >> https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1rc1.tar.gz.sig >> >> ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip >> ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.md5 >> ? https://download.osgeo.org/gdal/3.13.1/gdal3131rc1.zip.sig >> >> A snapshot of the gdalautotest suite is also available: >> >> https://download.osgeo.org/gdal/3.13.1/gdalautotest-3.13.1rc1.zip >> >> The NEWS file is here: >> >> ? https://github.com/OSGeo/gdal/blob/v3.13.1RC1/NEWS.md >> >> 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 > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Fri Jun 5 04:38:43 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 5 Jun 2026 13:38:43 +0200 Subject: [gdal-dev] GDAL 3.13.1 is released Message-ID: <89fdad97-7806-4b5c-987b-f25d01868caa@spatialys.com> Hi, On behalf of the GDAL/OGR development team, I am pleased to announce the release of the GDAL/OGR 3.13.1 bug fix version. Consult the release notes for the list of issues addressed: ? ? https://github.com/OSGeo/gdal/blob/v3.13.1/NEWS.md The sources are available at: ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.xz ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.xz.md5 ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.xz.sig or ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.gz ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.gz.md5 ? ? https://download.osgeo.org/gdal/3.13.1/gdal-3.13.1.tar.gz.sig or ? ? https://download.osgeo.org/gdal/3.13.1/gdal3131.zip ? ? https://download.osgeo.org/gdal/3.13.1/gdal3131.zip.md5 ? ? https://download.osgeo.org/gdal/3.13.1/gdal3131.zip.sig The Docker images are currently cooking and should be soon available at: * ghcr.io/osgeo/gdal:alpine-small-3.13.1 * ghcr.io/osgeo/gdal:alpine-normal-3.13.1 * ghcr.io/osgeo/gdal:ubuntu-small-3.13.1 * ghcr.io/osgeo/gdal:ubuntu-full-3.13.1 Best regards, Even -- http://www.spatialys.com My software is free, but my time generally not. From Roman.Ploehn at and-solution.com Mon Jun 8 04:16:38 2026 From: Roman.Ploehn at and-solution.com (=?utf-8?B?Um9tYW4gUGzDtmhu?=) Date: Mon, 8 Jun 2026 11:16:38 +0000 Subject: [gdal-dev] Crash in GEOS iterating through the layers in a PBF-file loaded with the MVT driver in GDAL 3.12.4#2 Message-ID: Hello, in our company we since many years use GDAL (for building C++ software for Windows only) from VCPKG. The GDAL version used in the most recent VCPKG is 3.12.4#2, in which I encounter a reproducable crash in RELEASE builds when opening a file downloaded from a Map-Tiles server, as soon as I iterate through its layers. My main question about this problem is if this problem is already fixed in a more recent GDAL version ... if so I could send the VCPKG-maintainers a feature request to ask them to update the GDAL package in there to a version, where it doesn't crash anymore. Below is a description of the problem. If needed I can send the file in question. For us this is a serioes issue, because it hinders us from using a recent version of VCPKG at all (we even use the dependend lib mapnik, which needs GDAL). I really hope someone can help me ... Best regards, have a nice day, Roman The function I use to reproduce the crash is quite simpel: auto GetLayerFeaureFIDs( OGRLayer& layer ) -> std::vector< GIntBig > { ??????std::cout << "Processing layer '" << layer.GetName() << "'...\n"; ??????std::vector< GIntBig > fids; ??????OGRFeature* feature = layer.GetNextFeature(); ??????for ( ; feature != nullptr; feature = layer.GetNextFeature() ) ??????{ ????????????if ( nullptr == feature ) ????????????{ ??????????????????std::cout << "Got a null feature from layer '" << layer.GetName() << "'. Skipping it.\n"; ??????????????????continue; ????????????} ????????????fids.push_back( feature->GetFID() ); ??????} ??????return fids; } It doesn't happen for each layer, i.e. in my DEBUG build, where no crash happens, an error is reported about a thrown TopologyException: ????Debug: GDAL: GDALOpen(C:\Projects\TestGdal\x64\Debug\43.pbf, this=000001D7A8789410) succeeds as MVT. (code: 0) ????Processing layer 'boundary'... ????Processing layer 'landcover'... ????Failure: TopologyException: side location conflict at 3934.7142857142858 3859.8571428571427. This can occur if the input geometry is invalid. (code: 1) ????Processing layer 'landuse'... ????Failure: TopologyException: side location conflict at 494.19230769230768 2796.5769230769229. This can occur if the input geometry is invalid. (code: 1) ????... The crash is a Access Violation, the top of the call-stack looks like this: ?????[Inline Frame] geos.dll!geos::geom::CoordinateXY::equals2D(const geos::geom::CoordinateXY &) Line 106?C++ ?????[Inline Frame] geos.dll!geos::index::kdtree::KdTree::queryNodePoint(geos::index::kdtree::KdNode * currentNode, const geos::geom::Coordinate & odd, bool) Line 235?C++ ?????geos.dll!geos::index::kdtree::KdTree::query(const geos::geom::Coordinate & queryPt) Line 289????C++ ?????[Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::find(const geos::geom::Coordinate &) Line 146?????C++ ?????geos.dll!geos::noding::snapround::HotPixelIndex::addRounded(const geos::geom::CoordinateXYZM & pRound) Line 48????C++ ?????[Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::add(const geos::geom::CoordinateXYZM &) Line 90???C++ ?????[Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::addNodes::__l2::::operator()(const geos::geom::CoordinateXYZM &) Line 127??C++ ?????geos.dll!geos::geom::CoordinateSequence::forEach<>(geos::noding::snapround::HotPixelIndex::addNodes::__l2:: && fun) Line 701????C++ ?????geos.dll!geos::noding::snapround::HotPixelIndex::addNodes(const geos::geom::CoordinateSequence * pts) Line 130????C++ ?????geos.dll!geos::noding::snapround::SnapRoundingNoder::addIntersectionPixels(std::vector> & segStrings) Line 85?C++ ?????geos.dll!geos::noding::snapround::SnapRoundingNoder::snapRound(std::vector> & inputSegStrings, std::vector> & resultNodedSegments) Line 70????C++ ?????geos.dll!geos::operation::overlayng::EdgeNodingBuilder::node(std::vector> * segStrings) Line 122??C++ ?????geos.dll!geos::operation::overlayng::EdgeNodingBuilder::build(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1) Line 104??C++ ?????geos.dll!geos::operation::overlayng::OverlayNG::computeEdgeOverlay() Line 227?C++ ?????geos.dll!geos::operation::overlayng::OverlayNG::getResult() Line 195????C++ ?????geos.dll!geos::operation::overlayng::OverlayNG::overlay(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode, const geos::geom::PrecisionModel * pm) Line 100?????C++ ?????geos.dll!geos::operation::overlayng::OverlayNGRobust::overlaySR(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode) Line 295??????C++ ?????geos.dll!geos::operation::overlayng::OverlayNGRobust::Overlay(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode) Line 147??C++ ?????geos.dll!geos::geom::HeuristicOverlay(const geos::geom::Geometry * g0, const geos::geom::Geometry * g1, int opCode) Line 194??C++ ?????geos.dll!geos::geom::Geometry::intersection(const geos::geom::Geometry * other) Line 616??C++ ?????[Inline Frame] geos_c.dll!GEOSIntersection_r::__l2::::operator()() Line 1322???C++ ?????geos_c.dll!execute<`anonymous namespace'::InterruptManager,,0>(GEOSContextHandle_HS * extHandle, GEOSIntersection_r::__l2:: && f) Line 521??C++ ?????geos_c.dll!GEOSIntersection_r(GEOSContextHandle_HS * extHandle, const geos::geom::Geometry * g1, const geos::geom::Geometry * g2) Line 1326?????C++ ?????gdal.dll!BuildGeometryFromTwoGeoms(const OGRGeometry * poSelf, const OGRGeometry * poOtherGeom, GEOSGeom_t *(*)(GEOSContextHandle_HS *, const GEOSGeom_t *, const GEOSGeom_t *) pfnGEOSFunction_r) Line 3814??????C++ ?????gdal.dll!OGRMVTLayer::GetNextRawFeature() Line 1381???C++ ?????[Inline Frame] gdal.dll!OGRGetNextFeatureThroughRaw::GetNextFeature() Line 513?C++ ?????gdal.dll!OGRMVTLayerBase::GetNextFeature() Line 144???C++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Mon Jun 8 05:21:22 2026 From: dbaston at gmail.com (Daniel Baston) Date: Mon, 8 Jun 2026 08:21:22 -0400 Subject: [gdal-dev] Crash in GEOS iterating through the layers in a PBF-file loaded with the MVT driver in GDAL 3.12.4#2 In-Reply-To: References: Message-ID: Hello Roman, Could you please share your input file, either in a GitHub issue or to me by email? I don't recall a recent bug like this, so you may have found a new issue. Thanks, Dan On Mon, Jun 8, 2026 at 7:17?AM Roman Pl?hn via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hello, > > in our company we since many years use GDAL (for building C++ software for > Windows only) from VCPKG. > > The GDAL version used in the most recent VCPKG is 3.12.4#2, in which I > encounter a reproducable crash in RELEASE builds when opening a file > downloaded from a Map-Tiles server, as soon as I iterate through its layers. > > My main question about this problem is if this problem is already fixed in > a more recent GDAL version ... if so I could send the VCPKG-maintainers a > feature request to ask them to update the GDAL package in there to a > version, where it doesn't crash anymore. > > Below is a description of the problem. If needed I can send the file in > question. > > For us this is a serioes issue, because it hinders us from using a recent > version of VCPKG at all (we even use the dependend lib mapnik, which needs > GDAL). > > I really hope someone can help me ... > > Best regards, > > have a nice day, > > Roman > > > > > The function I use to reproduce the crash is quite simpel: > > auto GetLayerFeaureFIDs( OGRLayer& layer ) -> std::vector< GIntBig > > { > std::cout << "Processing layer '" << layer.GetName() << "'...\n"; > > std::vector< GIntBig > fids; > > OGRFeature* feature = layer.GetNextFeature(); > > for ( ; feature != nullptr; feature = layer.GetNextFeature() ) > { > if ( nullptr == feature ) > { > std::cout << "Got a null feature from layer '" << layer.GetName() << "'. > Skipping it.\n"; > continue; > } > > fids.push_back( feature->GetFID() ); > } > > return fids; > } > > It doesn't happen for each layer, i.e. in my DEBUG build, where no crash > happens, an error is reported about a thrown TopologyException: > > Debug: GDAL: GDALOpen(C:\Projects\TestGdal\x64\Debug\43.pbf, > this=000001D7A8789410) succeeds as MVT. (code: 0) > Processing layer 'boundary'... > Processing layer 'landcover'... > Failure: TopologyException: side location conflict at 3934.7142857142858 > 3859.8571428571427. This can occur if the input geometry is invalid. (code: > 1) > Processing layer 'landuse'... > Failure: TopologyException: side location conflict at 494.19230769230768 > 2796.5769230769229. This can occur if the input geometry is invalid. (code: > 1) > ... > > The crash is a Access Violation, the top of the call-stack looks like this: > > [Inline Frame] geos.dll!geos::geom::CoordinateXY::equals2D(const > geos::geom::CoordinateXY &) Line 106 C++ > [Inline Frame] > geos.dll!geos::index::kdtree::KdTree::queryNodePoint(geos::index::kdtree::KdNode > * currentNode, const geos::geom::Coordinate & odd, bool) Line 235 C++ > geos.dll!geos::index::kdtree::KdTree::query(const geos::geom::Coordinate > & queryPt) Line 289 C++ > [Inline Frame] > geos.dll!geos::noding::snapround::HotPixelIndex::find(const > geos::geom::Coordinate &) Line 146 C++ > geos.dll!geos::noding::snapround::HotPixelIndex::addRounded(const > geos::geom::CoordinateXYZM & pRound) Line 48 C++ > [Inline Frame] > geos.dll!geos::noding::snapround::HotPixelIndex::add(const > geos::geom::CoordinateXYZM &) Line 90 C++ > [Inline Frame] > geos.dll!geos::noding::snapround::HotPixelIndex::addNodes::__l2::::operator()(const > geos::geom::CoordinateXYZM &) Line 127 C++ > > geos.dll!geos::geom::CoordinateSequence::forEach<>(geos::noding::snapround::HotPixelIndex::addNodes::__l2:: > && fun) Line 701 C++ > geos.dll!geos::noding::snapround::HotPixelIndex::addNodes(const > geos::geom::CoordinateSequence * pts) Line 130 C++ > > geos.dll!geos::noding::snapround::SnapRoundingNoder::addIntersectionPixels(std::vector *,std::allocator> & segStrings) Line 85 C++ > > geos.dll!geos::noding::snapround::SnapRoundingNoder::snapRound(std::vector *,std::allocator> & inputSegStrings, > std::vector *,std::allocator> & resultNodedSegments) > Line 70 C++ > > geos.dll!geos::operation::overlayng::EdgeNodingBuilder::node(std::vector *,std::allocator> * segStrings) Line 122 C++ > geos.dll!geos::operation::overlayng::EdgeNodingBuilder::build(const > geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1) Line 104 > C++ > geos.dll!geos::operation::overlayng::OverlayNG::computeEdgeOverlay() > Line 227 C++ > geos.dll!geos::operation::overlayng::OverlayNG::getResult() Line 195 C++ > geos.dll!geos::operation::overlayng::OverlayNG::overlay(const > geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int > opCode, const geos::geom::PrecisionModel * pm) Line 100 C++ > geos.dll!geos::operation::overlayng::OverlayNGRobust::overlaySR(const > geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int > opCode) Line 295 C++ > geos.dll!geos::operation::overlayng::OverlayNGRobust::Overlay(const > geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int > opCode) Line 147 C++ > geos.dll!geos::geom::HeuristicOverlay(const geos::geom::Geometry * g0, > const geos::geom::Geometry * g1, int opCode) Line 194 C++ > geos.dll!geos::geom::Geometry::intersection(const geos::geom::Geometry * > other) Line 616 C++ > [Inline Frame] > geos_c.dll!GEOSIntersection_r::__l2::::operator()() > Line 1322 C++ > geos_c.dll!execute<`anonymous > namespace'::InterruptManager,,0>(GEOSContextHandle_HS > * extHandle, > GEOSIntersection_r::__l2:: && f) > Line 521 C++ > geos_c.dll!GEOSIntersection_r(GEOSContextHandle_HS * extHandle, const > geos::geom::Geometry * g1, const geos::geom::Geometry * g2) Line 1326 C++ > gdal.dll!BuildGeometryFromTwoGeoms(const OGRGeometry * poSelf, const > OGRGeometry * poOtherGeom, GEOSGeom_t *(*)(GEOSContextHandle_HS *, const > GEOSGeom_t *, const GEOSGeom_t *) pfnGEOSFunction_r) Line 3814 C++ > gdal.dll!OGRMVTLayer::GetNextRawFeature() Line 1381 C++ > [Inline Frame] > gdal.dll!OGRGetNextFeatureThroughRaw::GetNextFeature() > Line 513 C++ > gdal.dll!OGRMVTLayerBase::GetNextFeature() Line 144 C++ > _______________________________________________ > 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 dg0yt at darc.de Mon Jun 8 21:36:43 2026 From: dg0yt at darc.de (dg0yt at darc.de) Date: Tue, 9 Jun 2026 06:36:43 +0200 (CEST) Subject: [gdal-dev] Crash in GEOS iterating through the layers in a PBF-file loaded with the MVT driver in GDAL 3.12.4#2 In-Reply-To: References: Message-ID: <1198877535.375972.1780979803762@app.mailbox.org> FTR an update to the vcpkg port is waiting in https://github.com/microsoft/vcpkg/pull/51627. But it needs an update or patch to VTK, and this isn't trivial (At least not as long as I did not replace my broken desktop PC.) Regards, Kai > On 06/08/2026 1:16 PM CEST Roman Pl?hn via gdal-dev wrote: > > > Hello, > > > in our company we since many years use GDAL (for building C++ software for Windows only) from VCPKG. > > > The GDAL version used in the most recent VCPKG is 3.12.4#2, in which I encounter a reproducable crash in RELEASE builds when opening a file downloaded from a Map-Tiles server, as soon as I iterate through its layers. > > > My main question about this problem is if this problem is already fixed in a more recent GDAL version ... if so I could send the VCPKG-maintainers a feature request to ask them to update the GDAL package in there to a version, where it doesn't crash anymore. > > > Below is a description of the problem. If needed I can send the file in question. > > > For us this is a serioes issue, because it hinders us from using a recent version of VCPKG at all (we even use the dependend lib mapnik, which needs GDAL). > > > I really hope someone can help me ... > > > Best regards, > > > have a nice day, > > > Roman > > > > > > > > > The function I use to reproduce the crash is quite simpel: > > > auto GetLayerFeaureFIDs( OGRLayer& layer ) -> std::vector< GIntBig > > { > std::cout << "Processing layer '" << layer.GetName() << "'...\n"; > > > std::vector< GIntBig > fids; > > > OGRFeature* feature = layer.GetNextFeature(); > > > for ( ; feature != nullptr; feature = layer.GetNextFeature() ) > { > if ( nullptr == feature ) > { > std::cout << "Got a null feature from layer '" << layer.GetName() << "'. Skipping it.\n"; > continue; > } > > > fids.push_back( feature->GetFID() ); > } > > > return fids; > } > > > It doesn't happen for each layer, i.e. in my DEBUG build, where no crash happens, an error is reported about a thrown TopologyException: > > > Debug: GDAL: GDALOpen(C:\Projects\TestGdal\x64\Debug\43.pbf, this=000001D7A8789410) succeeds as MVT. (code: 0) > Processing layer 'boundary'... > Processing layer 'landcover'... > Failure: TopologyException: side location conflict at 3934.7142857142858 3859.8571428571427. This can occur if the input geometry is invalid. (code: 1) > Processing layer 'landuse'... > Failure: TopologyException: side location conflict at 494.19230769230768 2796.5769230769229. This can occur if the input geometry is invalid. (code: 1) > ... > > > The crash is a Access Violation, the top of the call-stack looks like this: > > > [Inline Frame] geos.dll!geos::geom::CoordinateXY::equals2D(const geos::geom::CoordinateXY &) Line 106?C++ > [Inline Frame] geos.dll!geos::index::kdtree::KdTree::queryNodePoint(geos::index::kdtree::KdNode * currentNode, const geos::geom::Coordinate & odd, bool) Line 235?C++ > geos.dll!geos::index::kdtree::KdTree::query(const geos::geom::Coordinate & queryPt) Line 289 C++ > [Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::find(const geos::geom::Coordinate &) Line 146 C++ > geos.dll!geos::noding::snapround::HotPixelIndex::addRounded(const geos::geom::CoordinateXYZM & pRound) Line 48 C++ > [Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::add(const geos::geom::CoordinateXYZM &) Line 90 C++ > [Inline Frame] geos.dll!geos::noding::snapround::HotPixelIndex::addNodes::__l2::::operator()(const geos::geom::CoordinateXYZM &) Line 127 C++ > geos.dll!geos::geom::CoordinateSequence::forEach<>(geos::noding::snapround::HotPixelIndex::addNodes::__l2:: && fun) Line 701 C++ > geos.dll!geos::noding::snapround::HotPixelIndex::addNodes(const geos::geom::CoordinateSequence * pts) Line 130 C++ > geos.dll!geos::noding::snapround::SnapRoundingNoder::addIntersectionPixels(std::vector> & segStrings) Line 85?C++ > geos.dll!geos::noding::snapround::SnapRoundingNoder::snapRound(std::vector> & inputSegStrings, std::vector> & resultNodedSegments) Line 70 C++ > geos.dll!geos::operation::overlayng::EdgeNodingBuilder::node(std::vector> * segStrings) Line 122 C++ > geos.dll!geos::operation::overlayng::EdgeNodingBuilder::build(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1) Line 104 C++ > geos.dll!geos::operation::overlayng::OverlayNG::computeEdgeOverlay() Line 227?C++ > geos.dll!geos::operation::overlayng::OverlayNG::getResult() Line 195 C++ > geos.dll!geos::operation::overlayng::OverlayNG::overlay(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode, const geos::geom::PrecisionModel * pm) Line 100 C++ > geos.dll!geos::operation::overlayng::OverlayNGRobust::overlaySR(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode) Line 295 C++ > geos.dll!geos::operation::overlayng::OverlayNGRobust::Overlay(const geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int opCode) Line 147 C++ > geos.dll!geos::geom::HeuristicOverlay(const geos::geom::Geometry * g0, const geos::geom::Geometry * g1, int opCode) Line 194 C++ > geos.dll!geos::geom::Geometry::intersection(const geos::geom::Geometry * other) Line 616 C++ > [Inline Frame] geos_c.dll!GEOSIntersection_r::__l2::::operator()() Line 1322 C++ > geos_c.dll!execute<`anonymous namespace'::InterruptManager,,0>(GEOSContextHandle_HS * extHandle, GEOSIntersection_r::__l2:: && f) Line 521 C++ > geos_c.dll!GEOSIntersection_r(GEOSContextHandle_HS * extHandle, const geos::geom::Geometry * g1, const geos::geom::Geometry * g2) Line 1326 C++ > gdal.dll!BuildGeometryFromTwoGeoms(const OGRGeometry * poSelf, const OGRGeometry * poOtherGeom, GEOSGeom_t *(*)(GEOSContextHandle_HS *, const GEOSGeom_t *, const GEOSGeom_t *) pfnGEOSFunction_r) Line 3814 C++ > gdal.dll!OGRMVTLayer::GetNextRawFeature() Line 1381 C++ > [Inline Frame] gdal.dll!OGRGetNextFeatureThroughRaw::GetNextFeature() Line 513?C++ > gdal.dll!OGRMVTLayerBase::GetNextFeature() Line 144 C++ > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > From dbaston at gmail.com Tue Jun 9 03:11:26 2026 From: dbaston at gmail.com (Daniel Baston) Date: Tue, 9 Jun 2026 06:11:26 -0400 Subject: [gdal-dev] Crash in GEOS iterating through the layers in a PBF-file loaded with the MVT driver in GDAL 3.12.4#2 In-Reply-To: References: Message-ID: Hello Roman, Unfortunately, I haven't been able to reproduce the problem either locally or on the GDAL CI builders. As the stack trace indicates a failure in the GEOS library, I would suggest updating to the latest version of that library and posting your issue to the bug tracker of that project [1] if the problem persists. Dan [1] https://github.com/libgeos/geos/issues On Mon, Jun 8, 2026 at 8:21?AM Daniel Baston wrote: > Hello Roman, > > Could you please share your input file, either in a GitHub issue or to me > by email? I don't recall a recent bug like this, so you may have found a > new issue. > > Thanks, > Dan > > On Mon, Jun 8, 2026 at 7:17?AM Roman Pl?hn via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hello, >> >> in our company we since many years use GDAL (for building C++ software >> for Windows only) from VCPKG. >> >> The GDAL version used in the most recent VCPKG is 3.12.4#2, in which I >> encounter a reproducable crash in RELEASE builds when opening a file >> downloaded from a Map-Tiles server, as soon as I iterate through its layers. >> >> My main question about this problem is if this problem is already fixed >> in a more recent GDAL version ... if so I could send the VCPKG-maintainers >> a feature request to ask them to update the GDAL package in there to a >> version, where it doesn't crash anymore. >> >> Below is a description of the problem. If needed I can send the file in >> question. >> >> For us this is a serioes issue, because it hinders us from using a recent >> version of VCPKG at all (we even use the dependend lib mapnik, which needs >> GDAL). >> >> I really hope someone can help me ... >> >> Best regards, >> >> have a nice day, >> >> Roman >> >> >> >> >> The function I use to reproduce the crash is quite simpel: >> >> auto GetLayerFeaureFIDs( OGRLayer& layer ) -> std::vector< GIntBig > >> { >> std::cout << "Processing layer '" << layer.GetName() << "'...\n"; >> >> std::vector< GIntBig > fids; >> >> OGRFeature* feature = layer.GetNextFeature(); >> >> for ( ; feature != nullptr; feature = layer.GetNextFeature() ) >> { >> if ( nullptr == feature ) >> { >> std::cout << "Got a null feature from layer '" << layer.GetName() << "'. >> Skipping it.\n"; >> continue; >> } >> >> fids.push_back( feature->GetFID() ); >> } >> >> return fids; >> } >> >> It doesn't happen for each layer, i.e. in my DEBUG build, where no crash >> happens, an error is reported about a thrown TopologyException: >> >> Debug: GDAL: GDALOpen(C:\Projects\TestGdal\x64\Debug\43.pbf, >> this=000001D7A8789410) succeeds as MVT. (code: 0) >> Processing layer 'boundary'... >> Processing layer 'landcover'... >> Failure: TopologyException: side location conflict at 3934.7142857142858 >> 3859.8571428571427. This can occur if the input geometry is invalid. (code: >> 1) >> Processing layer 'landuse'... >> Failure: TopologyException: side location conflict at 494.19230769230768 >> 2796.5769230769229. This can occur if the input geometry is invalid. (code: >> 1) >> ... >> >> The crash is a Access Violation, the top of the call-stack looks like >> this: >> >> [Inline Frame] geos.dll!geos::geom::CoordinateXY::equals2D(const >> geos::geom::CoordinateXY &) Line 106 C++ >> [Inline Frame] >> geos.dll!geos::index::kdtree::KdTree::queryNodePoint(geos::index::kdtree::KdNode >> * currentNode, const geos::geom::Coordinate & odd, bool) Line 235 C++ >> geos.dll!geos::index::kdtree::KdTree::query(const >> geos::geom::Coordinate & queryPt) Line 289 C++ >> [Inline Frame] >> geos.dll!geos::noding::snapround::HotPixelIndex::find(const >> geos::geom::Coordinate &) Line 146 C++ >> geos.dll!geos::noding::snapround::HotPixelIndex::addRounded(const >> geos::geom::CoordinateXYZM & pRound) Line 48 C++ >> [Inline Frame] >> geos.dll!geos::noding::snapround::HotPixelIndex::add(const >> geos::geom::CoordinateXYZM &) Line 90 C++ >> [Inline Frame] >> geos.dll!geos::noding::snapround::HotPixelIndex::addNodes::__l2::::operator()(const >> geos::geom::CoordinateXYZM &) Line 127 C++ >> >> geos.dll!geos::geom::CoordinateSequence::forEach<>(geos::noding::snapround::HotPixelIndex::addNodes::__l2:: >> && fun) Line 701 C++ >> geos.dll!geos::noding::snapround::HotPixelIndex::addNodes(const >> geos::geom::CoordinateSequence * pts) Line 130 C++ >> >> geos.dll!geos::noding::snapround::SnapRoundingNoder::addIntersectionPixels(std::vector> *,std::allocator> & segStrings) Line 85 C++ >> >> geos.dll!geos::noding::snapround::SnapRoundingNoder::snapRound(std::vector> *,std::allocator> & inputSegStrings, >> std::vector> *,std::allocator> & resultNodedSegments) >> Line 70 C++ >> >> geos.dll!geos::operation::overlayng::EdgeNodingBuilder::node(std::vector> *,std::allocator> * segStrings) Line 122 C++ >> geos.dll!geos::operation::overlayng::EdgeNodingBuilder::build(const >> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1) Line 104 >> C++ >> geos.dll!geos::operation::overlayng::OverlayNG::computeEdgeOverlay() >> Line 227 C++ >> geos.dll!geos::operation::overlayng::OverlayNG::getResult() Line 195 C++ >> geos.dll!geos::operation::overlayng::OverlayNG::overlay(const >> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >> opCode, const geos::geom::PrecisionModel * pm) Line 100 C++ >> geos.dll!geos::operation::overlayng::OverlayNGRobust::overlaySR(const >> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >> opCode) Line 295 C++ >> geos.dll!geos::operation::overlayng::OverlayNGRobust::Overlay(const >> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >> opCode) Line 147 C++ >> geos.dll!geos::geom::HeuristicOverlay(const geos::geom::Geometry * g0, >> const geos::geom::Geometry * g1, int opCode) Line 194 C++ >> geos.dll!geos::geom::Geometry::intersection(const geos::geom::Geometry >> * other) Line 616 C++ >> [Inline Frame] >> geos_c.dll!GEOSIntersection_r::__l2::::operator()() >> Line 1322 C++ >> geos_c.dll!execute<`anonymous >> namespace'::InterruptManager,,0>(GEOSContextHandle_HS >> * extHandle, >> GEOSIntersection_r::__l2:: && f) >> Line 521 C++ >> geos_c.dll!GEOSIntersection_r(GEOSContextHandle_HS * extHandle, const >> geos::geom::Geometry * g1, const geos::geom::Geometry * g2) Line 1326 C++ >> gdal.dll!BuildGeometryFromTwoGeoms(const OGRGeometry * poSelf, const >> OGRGeometry * poOtherGeom, GEOSGeom_t *(*)(GEOSContextHandle_HS *, const >> GEOSGeom_t *, const GEOSGeom_t *) pfnGEOSFunction_r) Line 3814 C++ >> gdal.dll!OGRMVTLayer::GetNextRawFeature() Line 1381 C++ >> [Inline Frame] >> gdal.dll!OGRGetNextFeatureThroughRaw::GetNextFeature() >> Line 513 C++ >> gdal.dll!OGRMVTLayerBase::GetNextFeature() Line 144 C++ >> _______________________________________________ >> 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 Thu Jun 11 16:24:19 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 12 Jun 2026 01:24:19 +0200 Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver Message-ID: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> Hi, We are in the situation where we are about to have our first Rust direct (optional) dependency. This is for the "pcodec" lossless codec (https://github.com/pcodec/pcodec) that is used by some Zarr datasets. It offers a "cpcodec" crate with C bindings which we can use. I've tried in https://github.com/OSGeo/gdal/pull/14779 to offer different options: - by default to satisfy "casual" developers building GDAL who are mostly seeking ease of build and are fine with automatic download of dependencies (pcodec and corrosion-rs for the CMake rust integration), using git at CMake time, - as well as offering?more control with manual settings - either by pointing directly to an already installed?cpcodec?library, or by pointing to the locations of the source tree of corrosion-rs and pcodec - that should be more compatible of policies/constraints of?packagers. Review of people who might have integrated Rust crates in CMake C/C++ projects welcome. See the PR description for details. Even -- http://www.spatialys.com My software is free, but my time generally not. From gdt at lexort.com Thu Jun 11 16:57:51 2026 From: gdt at lexort.com (Greg Troxel) Date: Thu, 11 Jun 2026 19:57:51 -0400 Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver In-Reply-To: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> (Even Rouault via gdal-dev's message of "Fri, 12 Jun 2026 01:24:19 +0200") References: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> Message-ID: Even Rouault via gdal-dev writes: > Hi, > > We are in the situation where we are about to have our first Rust > direct (optional) dependency. This is for the "pcodec" lossless codec > (https://github.com/pcodec/pcodec) that is used by some Zarr > datasets. It offers a "cpcodec" crate with C bindings which we can > use. > > I've tried in https://github.com/OSGeo/gdal/pull/14779 to offer > different options: > > - by default to satisfy "casual" developers building GDAL who are > mostly seeking ease of build and are fine with automatic download of > dependencies (pcodec and corrosion-rs for the CMake rust > integration), using git at CMake time, I am very opposed to this as a default, and really I am opposd to this at all. Programs simply should not download anything at build time. This is not allowed in packaging, and it's a lot of why we have had so many npm supply chain attacks. I don't think anybody should be ok with build-time downloads, and I don't think we should enable that. Yes, I know there might be checksums, but I think it's still a problem. If we want to let people do this, they should have to pass some argument/command to authorize downloading this library. That's not hard, and people are going to have to build, because packagers are not going to turn on download stuff at build time. Except IDK about osgeo4w. > - as well as offering?more control with manual settings - either by > pointing directly to an already installed?cpcodec?library, or by > pointing to the locations of the source tree of corrosion-rs and > pcodec - that should be more compatible of policies/constraints > of?packagers. > > Review of people who might have integrated Rust crates in CMake C/C++ > projects welcome. See the PR description for details. Now we see the violence inherent in the system. Rust acts like their crate world is ok, and it's not, and it torques everybody else around. Many languages expect everyone to accomodate their special almost-a-packaging-system silo that only works in their language, and to treat them a special. That puts you in a bad place, I realize. The philosophically right approach would be to have a C-interface* library that uses the rust-world normal build stuff (which packagers don't like but have to adapt to and have) and have that be packaged. Then it's just something to look for with cmake; it logically should not be gdal's problem that it is written in rust any more than gdal should have to know that e.g. sqlite[iff is in C. I think a good example is librsvg. It's a library, written significantl in rust, but programs that use it just look for a .h and link against it. They aren't forced to act like it's all special because it used rust. Is pcodec packaged in Debian or any place else? I can have a look at adding it to pkgsrc, and see how that goes. We certainly have a lot of things in rust. We also are set up for programs that are fully in rust to fetch crates at packaging time and add them to the manifest of source tarballs. But I am very wary of trying to go down that path for a mostly-C++ program. Deoes gdal have a prior history of dealing with dependencies that should be packaged but aren't? I wonder if the plugin system is the answer here, to say that anything with troublesome (not packaged and checkable with cmake without special help) dependencies should be a plugin maintained in a separate repo. But I am not sure if the plugin system is fully workable, in terms of if flipping it on and trying to do everything that way really works, just because I haven't tried. * I see C interface as really native ABI on the platform, more than it is C, but I realize that's an arguable point of view. From even.rouault at spatialys.com Thu Jun 11 17:34:02 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 12 Jun 2026 02:34:02 +0200 Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver In-Reply-To: References: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> Message-ID: > Yes, I know there might be checksums, but I think it's still a problem. As you've noticed by carefully reviewing the PR ??, it uses sha1sum to identify tags > I think a good example is librsvg. It's a library, written significantl > in rust, but programs that use it just look for a .h and link against > it. They aren't forced to act like it's all special because it used > rust. As you've noticed, my PR offers that possibility if someone packages cpcodec and installs pcodec.h and libpcodec.so > > Is pcodec packaged in Debian or any place else? Not that I'm aware of > Deoes gdal have a prior history of dealing with dependencies that should > be packaged but aren't? yes and no. We have a few vendored ones > > I wonder if the plugin system is the answer here, to say that anything > with troublesome (not packaged and checkable with cmake without special > help) dependencies should be a plugin maintained in a separate repo. The Zarr driver itself can be built as a plugin. But a plugin of a plugin, that's unknown territory Anyway if you or anyone else doesn't like it, GDAL_USE_PCODEC=NO will be your friend, and/or not having git or cargo in your build env. Even -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdal at aitchison.me.uk Fri Jun 12 03:23:58 2026 From: gdal at aitchison.me.uk (Andrew C Aitchison) Date: Fri, 12 Jun 2026 11:23:58 +0100 (BST) Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver Message-ID: On Thu, 11 Jun 2026, Greg Troxel via gdal-dev wrote: > Now we see the violence inherent in the system. Rust acts like their > crate world is ok, and it's not, and it torques everybody else around. > Many languages expect everyone to accomodate their special > almost-a-packaging-system silo that only works in their language, and to > treat them a special. That puts you in a bad place, I realize. Agreed. I want to think of Rust/Cargo as a new distro, although I know that the major distros have managed to fit it into theirs. > I wonder if the plugin system is the answer here, to say that anything > with troublesome (not packaged and checkable with cmake without special > help) dependencies should be a plugin maintained in a separate repo. > But I am not sure if the plugin system is fully workable, in terms of if > flipping it on and trying to do everything that way really works, just > because I haven't tried. My experience, over several years, with out-of-tree plugins in separate repos is not happy, though someone like Even might be able to make it work. The big issue is that you would want to be able to build it against several different versions of gdal but the ABI changes frequently. Packagers and self-builders would have to hope there is a git version of the plugin which matches the gdal version they are building against. #if GDAL_VERSION_NUM > 3110000 makes this possible, but is this the job of GDAL, the plugin maintainer (who needs to be active) or the packager ? GDAL exists on many platforms. Few developers have direct access to more than a few of these or the experience to set up something like github to build them all. Maybe now that we use CMake everywhere the GDAL community could set up a skeleton repo that builds plugins for every platform ? -- Andrew C. Aitchison Kendal, UK andrew at aitchison.me.uk From sebastic at xs4all.nl Fri Jun 12 06:47:13 2026 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Fri, 12 Jun 2026 15:47:13 +0200 Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver In-Reply-To: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> References: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> Message-ID: <64730774-6f00-43be-8596-2fc596663048@xs4all.nl> Greg expressed concern about being the only packager chiming in here. I didn't see anything that required me to do so, but I'll share my point of view as the Debian package maintainer. On 6/12/26 1:24 AM, Even Rouault via gdal-dev wrote: > We are in the situation where we are about to have our first Rust direct (optional) dependency. This is for the "pcodec" lossless codec (https://github.com/pcodec/pcodec) that is used by some Zarr datasets. It offers a "cpcodec" crate with C bindings which we can use. Just for the record, this is the pco crate (https://crates.io/crates/pco). > I've tried in https://github.com/OSGeo/gdal/pull/14779 to offer different options: > > - by default to satisfy "casual" developers building GDAL who are mostly seeking ease of build and are fine with automatic download of dependencies (pcodec and corrosion-rs for the CMake rust integration), using git at CMake time, This reminds me of OSSIM and how its superbuild used CMake to download dependencies, a convenient feature for those not working within the constraints of OS package build environments. > - as well as offering?more control with manual settings - either by pointing directly to an already installed?cpcodec?library, or by pointing to the locations of the source tree of corrosion-rs and pcodec - that should be more compatible of policies/constraints of?packagers. This is very welcome. As long as it remains an optional dependency, I'll simply not use it for the Debian package. If it becomes a required dependency, it will likely need to be vendored because I don't expect anyone to package the pco crate. I don't see myself doing that either as I don't use Zarr datasets, like I don't use GeoParquet and can live without the Parquet driver in GDAL. Users who do need this functionality are encouraged to help do the work to get the dependencies packaged and available on all release architectures. > Review of people who might have integrated Rust crates in CMake C/C++ projects welcome. See the PR description for details. So far I've managed to avoid Rust, we'll see how long that lasts. Python projects are increasingly following the example of python-cryptography and adopting Rust dependencies, e.g. cql2-rs for pystac-client. Kind Regards, Bas -- PGP Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 From even.rouault at spatialys.com Fri Jun 12 07:33:07 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 12 Jun 2026 16:33:07 +0200 Subject: [gdal-dev] Optional rust library as a dependency of the Zarr driver In-Reply-To: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> References: <02affe67-f45d-467c-bed4-34dee0ae0916@spatialys.com> Message-ID: <33427d2e-5db9-41a2-8b62-20b648fd58d2@spatialys.com> I've added a commit?to require GDAL_USE_PCODEC to be explicitly set to ON to trigger download from source repositories (ie when cpcodec isn't already built and available?on the build system). Mostly for license compliance, since Pcodec is Apache 2, and we want user consent before embedding such code. Le 12/06/2026 ? 01:24, Even Rouault via gdal-dev a ?crit?: > Hi, > > We are in the situation where we are about to have our first Rust > direct (optional) dependency. This is for the "pcodec" lossless codec > (https://github.com/pcodec/pcodec) that is used by some Zarr datasets. > It offers a "cpcodec" crate with C bindings which we can use. > > I've tried in https://github.com/OSGeo/gdal/pull/14779 to offer > different options: > > - by default to satisfy "casual" developers building GDAL who are > mostly seeking ease of build and are fine with automatic download of > dependencies (pcodec and corrosion-rs for the CMake rust integration), > using git at CMake time, > > - as well as offering?more control with manual settings - either by > pointing directly to an already installed?cpcodec?library, or by > pointing to the locations of the source tree of corrosion-rs and > pcodec - that should be more compatible of policies/constraints > of?packagers. > > Review of people who might have integrated Rust crates in CMake C/C++ > projects welcome. See the PR description for details. > > Even > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Jun 17 04:49:56 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 17 Jun 2026 13:49:56 +0200 Subject: [gdal-dev] Python bindings: aliasing gdal.Open and gdal.OpenEx Message-ID: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> Hi, I'd like to have a broader feedback of the community on https://github.com/OSGeo/gdal/pull/14763 . Please read it in detail. In practice, the main backwards incompatibility would be the point 1 I mention in the PR text, that is that for current users?of gdal.Open(dsname), they would now get vector datasets opened in addition to raster ones. While I see this is as a long term benefit, at least one user (https://github.com/ubarsc/rios/pull/192) had to work around it since they expected gdal.Open() to fail on vector datasets. The workaround being to use gdal.OpenEx(dsname, gdal.OF_RASTER) that will work before and after the PR,? or if targeting only post PR state, gdal.Open(dsname, gdal.OF_RASTER) PR 14763 would be potential material for a GDAL 4 if that did occur, but I don't know if it is desirable and even if it was, I don't think it would happen in a short?or medium term (mostly because the GDAL dev community is too?small to be able to gather a significant set?of backwards incompatible change in a reasonable period?of time, while not blocking features to be released at a reasonable frequency). So we're more in a situation where we land a few backwards incompatible change each (non bugfix) release. Even -- http://www.spatialys.com My software is free, but my time generally not. From strk at kbt.io Wed Jun 17 06:29:54 2026 From: strk at kbt.io (Sandro Santilli) Date: Wed, 17 Jun 2026 15:29:54 +0200 Subject: [gdal-dev] brainstorming: moving away from github? In-Reply-To: Message-ID: On Fri, Apr 24, 2026 at 13:42, Alexandre Gacon wrote: > > Have you discussed with osgeo on offering such a service, based for example on GitLab on Premise? OSGeo already offers such a service [1], based on Gitea [2]. It's been up and running for over 10 years now [3], I'm surprised it's not known by the whole community by now. [1] https://wiki.osgeo.org/wiki/SAC:Gitea [2] https://en.wikipedia.org/wiki/Gitea [3] https://lists.osgeo.org/pipermail/postgis-devel/2016-April/025776.html --strk; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From even.rouault at spatialys.com Wed Jun 17 07:10:59 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 17 Jun 2026 16:10:59 +0200 Subject: [gdal-dev] brainstorming: moving away from github? In-Reply-To: References: Message-ID: <7416bbc6-d367-4c62-bdd4-1cdb291d4407@spatialys.com> Le 17/06/2026 ? 15:29, Sandro Santilli via gdal-dev a ?crit?: > On Fri, Apr 24, 2026 at 13:42, Alexandre Gacon wrote: >> Have you discussed with osgeo on offering such a service, based for example on GitLab on Premise? > OSGeo already offers such a service [1], based on Gitea [2]. > > It's been up and running for over 10 years now [3], > I'm surprised it's not known by the whole community by now. It is, but personally I would look for a service?not administrated by the OSGeo community. IMHO?OSGeo is too small to?offer a forge?service that has similar availability, capacity, capability as a commercial service (well, speaking about the type?of availability?we expected back in?pre-AI era). It would make more sense to use a sufficiently large non-profit, with paying?offerings, that handles > thousands projects and?can offer such service with paid staff that can handle emergencies.? The CI part is the most critical part in terms?of resource?needs. Personally, I have zero?interest in putting my hands in the guts?of a forge, its CI infrastructure and related system administration. That's a different set?of skills & interests than GDAL mission.? Just seeing https://mastodon.social/@codebergstatus at social.anoxinon.de/116765466518696640 , looks like the Internet has become a very hostile territory to anyone having public servers... -- http://www.spatialys.com My software is free, but my time generally not. From strk at kbt.io Wed Jun 17 07:40:48 2026 From: strk at kbt.io (Sandro Santilli) Date: Wed, 17 Jun 2026 16:40:48 +0200 Subject: [gdal-dev] Fwd: Re: brainstorming: moving away from github? In-Reply-To: Message-ID: On Thu, 23 Apr 2026 21:11:38 +0300, Lauren?iu Nicola wrote: > > For free CI, I think GitHub is unbeatable. For free-as-in-freedom is very much beatable. For free-as-in-beer the more you can use, the more free beer you get (in PostGIS we use CI from github.com and gitlab.com and others). > If you mostly want to get better CI performance, the GitHub agent can be self-hosted And so can be agents for the OSGeo-hosted Woodpecker-CI based instance, which integrates seemlessly with the Gitea service. See "Running agents" here: https://wiki.osgeo.org/wiki/Woodie > But the orchestration is still done on GitHub's side, so self-hosted runners might still be affected by outages. Of course if you go OSGeo orchestration is done on OSGeo side, and affected by those outages (which OSGeo members can all help with reducing). --strk; Libre GIS consultant/developer ? https://strk.kbt.io/services.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From schut at satelligence.com Fri Jun 19 01:13:44 2026 From: schut at satelligence.com (Vincent Schut) Date: Fri, 19 Jun 2026 10:13:44 +0200 Subject: [gdal-dev] Python bindings: aliasing gdal.Open and gdal.OpenEx In-Reply-To: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> References: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> Message-ID: <5476ac4a-a3ed-4f27-8e00-0c63cd0df09f@satelligence.com> On 2026-06-17 1:49 pm, Even Rouault via gdal-dev wrote: > Hi, > > I'd like to have a broader feedback of the community on > https://github.com/OSGeo/gdal/pull/14763 . Please read it in detail. > In practice, the main backwards incompatibility would be the point 1 I > mention in the PR text, that is that for current users?of > gdal.Open(dsname), they would now get vector datasets opened in > addition to raster ones. While I see this is as a long term benefit, > at least one user (https://github.com/ubarsc/rios/pull/192) had to > work around it since they expected gdal.Open() to fail on vector > datasets. The workaround being to use gdal.OpenEx(dsname, > gdal.OF_RASTER) that will work before and after the PR,? or if > targeting only post PR state, gdal.Open(dsname, gdal.OF_RASTER) > > PR 14763 would be potential material for a GDAL 4 if that did occur, > but I don't know if it is desirable and even if it was, I don't think > it would happen in a short?or medium term (mostly because the GDAL dev > community is too?small to be able to gather a significant set?of > backwards incompatible change in a reasonable period?of time, while > not blocking features to be released at a reasonable frequency). So > we're more in a situation where we land a few backwards incompatible > change each (non bugfix) release. > > Even > Hi Even, (I doubted whether to reply because it was a bit unclear to me if you only wanted people with concerns to reply, or also people who don't see any issue with the proposed change.) We (as quite heavy users of gdal in our internal python software) do not see any issues with this proposal for us, and would in fact welcome this change because it will reduce ambiguity between the 2 possible ways to open raster datasets. Thanks for asking feedback, Vincent. -- Vincent Schut Remote Sensing Software Engineer +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands Linkedin ~ satelligence.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Jun 19 06:50:44 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 19 Jun 2026 15:50:44 +0200 Subject: [gdal-dev] Python bindings: aliasing gdal.Open and gdal.OpenEx In-Reply-To: <5476ac4a-a3ed-4f27-8e00-0c63cd0df09f@satelligence.com> References: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> <5476ac4a-a3ed-4f27-8e00-0c63cd0df09f@satelligence.com> Message-ID: Hi Vincent, Positive feedback is also appreciated :-) Even Le 19/06/2026 ? 10:13, Vincent Schut via gdal-dev a ?crit?: > On 2026-06-17 1:49 pm, Even Rouault via gdal-dev wrote: >> Hi, >> >> I'd like to have a broader feedback of the community on >> https://github.com/OSGeo/gdal/pull/14763 . Please read it in detail. >> In practice, the main backwards incompatibility would be the point 1 >> I mention in the PR text, that is that for current users?of >> gdal.Open(dsname), they would now get vector datasets opened in >> addition to raster ones. While I see this is as a long term benefit, >> at least one user (https://github.com/ubarsc/rios/pull/192) had to >> work around it since they expected gdal.Open() to fail on vector >> datasets. The workaround being to use gdal.OpenEx(dsname, >> gdal.OF_RASTER) that will work before and after the PR,? or if >> targeting only post PR state, gdal.Open(dsname, gdal.OF_RASTER) >> >> PR 14763 would be potential material for a GDAL 4 if that did occur, >> but I don't know if it is desirable and even if it was, I don't think >> it would happen in a short?or medium term (mostly because the GDAL >> dev community is too?small to be able to gather a significant set?of >> backwards incompatible change in a reasonable period?of time, while >> not blocking features to be released at a reasonable frequency). So >> we're more in a situation where we land a few backwards incompatible >> change each (non bugfix) release. >> >> Even >> > Hi Even, > > (I doubted whether to reply because it was a bit unclear to me if you > only wanted people with concerns to reply, or also people who don't > see any issue with the proposed change.) > > We (as quite heavy users of gdal in our internal python software) do > not see any issues with this proposal for us, and would in fact > welcome this change because it will reduce ambiguity between the 2 > possible ways to open raster datasets. > > Thanks for asking feedback, > Vincent. > -- > > > > Vincent Schut > > Remote Sensing Software Engineer > > +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands > > Linkedin ~ > satelligence.com > > > > > _______________________________________________ > 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 dbaston at gmail.com Fri Jun 19 06:58:10 2026 From: dbaston at gmail.com (Daniel Baston) Date: Fri, 19 Jun 2026 09:58:10 -0400 Subject: [gdal-dev] Python bindings: aliasing gdal.Open and gdal.OpenEx In-Reply-To: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> References: <66073f73-ba4a-48a6-8a13-c2557ebc89b4@spatialys.com> Message-ID: Hi Even, > So we're > more in a situation where we land a few backwards incompatible change > each (non bugfix) release. > A possible mitigation is to use a release model where we backport certain fixes to an LTS release, allowing users who don't need the latest-and-greatest to deal with breaking changes every N years, rather than every 6 months. Obviously that would come at a significant cost to the project, not a decision to be taken lightly. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Fri Jun 19 07:04:48 2026 From: dbaston at gmail.com (Daniel Baston) Date: Fri, 19 Jun 2026 10:04:48 -0400 Subject: [gdal-dev] Crash in GEOS iterating through the layers in a PBF-file loaded with the MVT driver in GDAL 3.12.4#2 In-Reply-To: References: Message-ID: Hi Roman, We ended up getting other reports of this problem, which appears to be associated with recent releases of the MSVC compiler. It has been fixed in GEOS main via https://github.com/libgeos/geos/pull/1453. That fix should show up in 3.14.2. Thanks, Dan On Tue, Jun 9, 2026 at 6:11?AM Daniel Baston wrote: > Hello Roman, > > Unfortunately, I haven't been able to reproduce the problem either locally > or on the GDAL CI builders. As the stack trace indicates a failure in the > GEOS library, I would suggest updating to the latest version of that > library and posting your issue to the bug tracker of that project [1] if > the problem persists. > > Dan > > [1] https://github.com/libgeos/geos/issues > > > > On Mon, Jun 8, 2026 at 8:21?AM Daniel Baston wrote: > >> Hello Roman, >> >> Could you please share your input file, either in a GitHub issue or to me >> by email? I don't recall a recent bug like this, so you may have found a >> new issue. >> >> Thanks, >> Dan >> >> On Mon, Jun 8, 2026 at 7:17?AM Roman Pl?hn via gdal-dev < >> gdal-dev at lists.osgeo.org> wrote: >> >>> Hello, >>> >>> in our company we since many years use GDAL (for building C++ software >>> for Windows only) from VCPKG. >>> >>> The GDAL version used in the most recent VCPKG is 3.12.4#2, in which I >>> encounter a reproducable crash in RELEASE builds when opening a file >>> downloaded from a Map-Tiles server, as soon as I iterate through its layers. >>> >>> My main question about this problem is if this problem is already fixed >>> in a more recent GDAL version ... if so I could send the VCPKG-maintainers >>> a feature request to ask them to update the GDAL package in there to a >>> version, where it doesn't crash anymore. >>> >>> Below is a description of the problem. If needed I can send the file in >>> question. >>> >>> For us this is a serioes issue, because it hinders us from using a >>> recent version of VCPKG at all (we even use the dependend lib mapnik, which >>> needs GDAL). >>> >>> I really hope someone can help me ... >>> >>> Best regards, >>> >>> have a nice day, >>> >>> Roman >>> >>> >>> >>> >>> The function I use to reproduce the crash is quite simpel: >>> >>> auto GetLayerFeaureFIDs( OGRLayer& layer ) -> std::vector< GIntBig > >>> { >>> std::cout << "Processing layer '" << layer.GetName() << "'...\n"; >>> >>> std::vector< GIntBig > fids; >>> >>> OGRFeature* feature = layer.GetNextFeature(); >>> >>> for ( ; feature != nullptr; feature = layer.GetNextFeature() ) >>> { >>> if ( nullptr == feature ) >>> { >>> std::cout << "Got a null feature from layer '" << layer.GetName() << "'. >>> Skipping it.\n"; >>> continue; >>> } >>> >>> fids.push_back( feature->GetFID() ); >>> } >>> >>> return fids; >>> } >>> >>> It doesn't happen for each layer, i.e. in my DEBUG build, where no crash >>> happens, an error is reported about a thrown TopologyException: >>> >>> Debug: GDAL: GDALOpen(C:\Projects\TestGdal\x64\Debug\43.pbf, >>> this=000001D7A8789410) succeeds as MVT. (code: 0) >>> Processing layer 'boundary'... >>> Processing layer 'landcover'... >>> Failure: TopologyException: side location conflict at 3934.7142857142858 >>> 3859.8571428571427. This can occur if the input geometry is invalid. (code: >>> 1) >>> Processing layer 'landuse'... >>> Failure: TopologyException: side location conflict at 494.19230769230768 >>> 2796.5769230769229. This can occur if the input geometry is invalid. (code: >>> 1) >>> ... >>> >>> The crash is a Access Violation, the top of the call-stack looks like >>> this: >>> >>> [Inline Frame] geos.dll!geos::geom::CoordinateXY::equals2D(const >>> geos::geom::CoordinateXY &) Line 106 C++ >>> [Inline Frame] >>> geos.dll!geos::index::kdtree::KdTree::queryNodePoint(geos::index::kdtree::KdNode >>> * currentNode, const geos::geom::Coordinate & odd, bool) Line 235 C++ >>> geos.dll!geos::index::kdtree::KdTree::query(const >>> geos::geom::Coordinate & queryPt) Line 289 C++ >>> [Inline Frame] >>> geos.dll!geos::noding::snapround::HotPixelIndex::find(const >>> geos::geom::Coordinate &) Line 146 C++ >>> geos.dll!geos::noding::snapround::HotPixelIndex::addRounded(const >>> geos::geom::CoordinateXYZM & pRound) Line 48 C++ >>> [Inline Frame] >>> geos.dll!geos::noding::snapround::HotPixelIndex::add(const >>> geos::geom::CoordinateXYZM &) Line 90 C++ >>> [Inline Frame] >>> geos.dll!geos::noding::snapround::HotPixelIndex::addNodes::__l2::::operator()(const >>> geos::geom::CoordinateXYZM &) Line 127 C++ >>> >>> geos.dll!geos::geom::CoordinateSequence::forEach<>(geos::noding::snapround::HotPixelIndex::addNodes::__l2:: >>> && fun) Line 701 C++ >>> geos.dll!geos::noding::snapround::HotPixelIndex::addNodes(const >>> geos::geom::CoordinateSequence * pts) Line 130 C++ >>> >>> geos.dll!geos::noding::snapround::SnapRoundingNoder::addIntersectionPixels(std::vector>> *,std::allocator> & segStrings) Line 85 C++ >>> >>> geos.dll!geos::noding::snapround::SnapRoundingNoder::snapRound(std::vector>> *,std::allocator> & inputSegStrings, >>> std::vector>> *,std::allocator> & resultNodedSegments) >>> Line 70 C++ >>> >>> geos.dll!geos::operation::overlayng::EdgeNodingBuilder::node(std::vector>> *,std::allocator> * segStrings) Line 122 C++ >>> geos.dll!geos::operation::overlayng::EdgeNodingBuilder::build(const >>> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1) Line 104 >>> C++ >>> geos.dll!geos::operation::overlayng::OverlayNG::computeEdgeOverlay() >>> Line 227 C++ >>> geos.dll!geos::operation::overlayng::OverlayNG::getResult() Line 195 >>> C++ >>> geos.dll!geos::operation::overlayng::OverlayNG::overlay(const >>> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >>> opCode, const geos::geom::PrecisionModel * pm) Line 100 C++ >>> geos.dll!geos::operation::overlayng::OverlayNGRobust::overlaySR(const >>> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >>> opCode) Line 295 C++ >>> geos.dll!geos::operation::overlayng::OverlayNGRobust::Overlay(const >>> geos::geom::Geometry * geom0, const geos::geom::Geometry * geom1, int >>> opCode) Line 147 C++ >>> geos.dll!geos::geom::HeuristicOverlay(const geos::geom::Geometry * g0, >>> const geos::geom::Geometry * g1, int opCode) Line 194 C++ >>> geos.dll!geos::geom::Geometry::intersection(const geos::geom::Geometry >>> * other) Line 616 C++ >>> [Inline Frame] >>> geos_c.dll!GEOSIntersection_r::__l2::::operator()() >>> Line 1322 C++ >>> geos_c.dll!execute<`anonymous >>> namespace'::InterruptManager,,0>(GEOSContextHandle_HS >>> * extHandle, >>> GEOSIntersection_r::__l2:: && f) >>> Line 521 C++ >>> geos_c.dll!GEOSIntersection_r(GEOSContextHandle_HS * extHandle, const >>> geos::geom::Geometry * g1, const geos::geom::Geometry * g2) Line 1326 C++ >>> gdal.dll!BuildGeometryFromTwoGeoms(const OGRGeometry * poSelf, const >>> OGRGeometry * poOtherGeom, GEOSGeom_t *(*)(GEOSContextHandle_HS *, const >>> GEOSGeom_t *, const GEOSGeom_t *) pfnGEOSFunction_r) Line 3814 C++ >>> gdal.dll!OGRMVTLayer::GetNextRawFeature() Line 1381 C++ >>> [Inline Frame] >>> gdal.dll!OGRGetNextFeatureThroughRaw::GetNextFeature() >>> Line 513 C++ >>> gdal.dll!OGRMVTLayerBase::GetNextFeature() Line 144 C++ >>> _______________________________________________ >>> 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 gdt at lexort.com Fri Jun 19 16:37:36 2026 From: gdt at lexort.com (Greg Troxel) Date: Fri, 19 Jun 2026 19:37:36 -0400 Subject: [gdal-dev] 2.5D vs Z in ogrConstants Message-ID: tl;dr: Why is "3D-ness" variantly written "25D" and "Z", in wkbPoint* constants? Is this just a historical accident? I just noticed ogrConstants for geometry types are not consistent. I have always thought of (logically) Point as a base type, with the option to add height, to add a measure field, or both. At first I thought this was POINTZ, POINTM and POINTZM (as ogrinfo prints it), with "3D" and "Measured" in the humanized description. I then found out that wkbPoint25D was what one needed to use in python, and didn't dig in, figuring that 2.5D was a 2D coordinate with a height as attribute vs a point in 3 dimensional space, as a subtle maybe-accurate maybe-off-base distinction, and I'd figure that out later. Today I wrote wkbPoint25DM and realized that was wrong and read the python code installed at /usr/pkg/lib/python3.13/site-packages/osgeo/ogr.py which refers to likely C constants of the same names wkbPoint = _ogr.wkbPoint wkbPointM = _ogr.wkbPointM wkbPointZM = _ogr.wkbPointZM wkbPoint25D = _ogr.wkbPoint25D But, a newer geometry type wkbMultiCurve = _ogr.wkbMultiCurve wkbMultiCurveZ = _ogr.wkbMultiCurveZ wkbMultiCurveM = _ogr.wkbMultiCurveM wkbMultiCurveZM = _ogr.wkbMultiCurveZM just uses Z. The WKT wikipedia article uses "3D" and "2.5D"/"25D" do not appear. Why are the (presumably original) types "25D" instead of Z? Is this meaningful, or just arbitrary naming? Sorry if I should have figured this out from reading docs - I did try. Really I'm asking if I'm failing to understand something I should understand. From even.rouault at spatialys.com Fri Jun 19 16:52:49 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 20 Jun 2026 01:52:49 +0200 Subject: [gdal-dev] 2.5D vs Z in ogrConstants In-Reply-To: References: Message-ID: <253b09b8-6fee-4714-99c0-da59f5192811@spatialys.com> Le 20/06/2026 ? 01:37, Greg Troxel via gdal-dev a ?crit?: > tl;dr: > > Why is "3D-ness" variantly written "25D" and "Z", in wkbPoint* > constants? Is this just a historical accident? yes. The 25D stuff in GDAL for the non-curve geometry types precedes ISO standardization of the Z encoding. When we added support for curve geometry types, we used the ISO Z naming and numeric encoding, but didn't dare touching existing enumeration values. A potential GDAL 4.0 clean-up topic for brave people Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Sun Jun 21 19:04:27 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 22 Jun 2026 04:04:27 +0200 Subject: [gdal-dev] End of free lunch (Re: Integrating AI assisted code review for PR in OSGeo/GDAL?) In-Reply-To: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> References: <9a74143e-3fcd-4c18-b229-be9afb55d2b4@spatialys.com> Message-ID: Hi, FYI: I've shut down Gemini review. Because I'm becoming more and more allergic to this whole nightmare, and more pragmatically, because they've announced it was going to be retired as free tier next month. Even Le 02/04/2026 ? 15:42, Even Rouault via gdal-dev a ?crit?: > Hi, > > I think it could be worth to have the *possibility* of requiring an AI > assisted review for pull requests, directly available from our > canonical repo. I've been occasionaly experimenting Gemini Code Assist > and Copilot in my personal fork. Copilot had repeated failures a few > weeks ago but seems to have been fixed recently, so I've more > experience with /gemini review. I find it useful and it has spotted > real issues, some of them would have probably went unnoticed during > classic human review, and with an acceptable rate of false positives > or debatable remarks. > > So my proposal would be to have the tool(s)? enabled in OSGeo/GDAL > repo, *on demand* (not sure if that's possible for Copilot. Is that a > setting? Although I'm not trusting github enough to be sure if we want > to increase our use of it.? Gemini review is definitely on demand and > an external github app we can disable in one click) for developers or > reviewers that want to trigger them. I don't think having them to run > systematically is a good idea, because some PRs are too trivial to get > any benefit from them, and having them enabled systematically lead to > noise as PR comments and notifications. > > I definitely don't think those tools should replace human review. AI > tools are instructed to flatter your ego and will never say your PR is > a bad idea, which a human reviewer will occasionally say. Or they lack > the global picture, etc. I see them as additional tools on top of our > CI instrumentation and human review. > > Anyone with experience in that area and thoughts? > > Even > -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot