From howard at hobu.co Fri May 1 07:00:06 2026 From: howard at hobu.co (Howard Butler) Date: Fri, 1 May 2026 09:00:06 -0500 Subject: [gdal-dev] GDAL Maintainers Meeting Minutes Message-ID: <5FAB9C5C-9F2A-439C-85EF-CE8422BFCB69@hobu.co> Howard Butler, Dan Baston, Alessandro Pasotti, Chris Toney, Michael Smith, Even Rouault, and Javier Jimenez Shaw held the monthly GDAL Maintainers Meeting on 04/23/2026. The following items were discussed and reported upon: # Project News ## Releases * Maintenance release GDAL 3.12.4 was released https://github.com/OSGeo/gdal/releases/tag/v3.12.4 See https://github.com/OSGeo/gdal/blob/v3.12.4/NEWS.md for bug list and details * GDAL 3.13.0b1 is now available. Preliminary release notes are available at https://github.com/OSGeo/gdal/blob/304c53e1298e3294c8b854a996103ad1ca8a131d/NEWS.md ## Conferences * Even and Seth will be giving the GDAL Workshop at FOSS4GE in Timisoara, Romania on July 3rd, 2026. See https://2026.europe.foss4g.org/schedule/workshops/ for details and get your ticket at https://pretix.geo-spatial.org/foss4ge2026/timisoara2026/ * Howard's talk "Building the GDAL Sponsorship Program" was accepted for FOSS4G Hiroshima https://talks.osgeo.org/foss4g-2026/talk/review/FNSYDBBCF7LUPB77JHSGPUMUQV3NSNWB # Maintenance activities update ## Alessandro * 27 PR reviews * CLI argument dependencies to allow linking of arguments ? no breaking change ## Seth (unable to attend but provided report via email) * finalizing the projections tutorial at https://gdal.org/en/latest/tutorials/reprojecting_data.html * updating the Conda master pipeline, so there is only one package per version (looks like it is all working now at https://anaconda.org/channels/gdal-master/packages/libgdal-core/files?versions=3.12.99) * Doc: Add SPARSE_OK example to COG page: https://github.com/OSGeo/gdal/pull/14390 * Doc: Add raster clip example and update error message: https://github.com/OSGeo/gdal/pull/14384 * CI: Strip out any \r when running on Windows for Conda uploads: https://github.com/OSGeo/gdal/pull/14342 * CI: Add channel for windows and jq: https://github.com/OSGeo/gdal/pull/14339 * CI: Conda master builds remove duplicate versions: https://github.com/OSGeo/gdal/pull/14335 * Doc: Add PAM projection example: https://github.com/OSGeo/gdal/pull/14317 * Doc: Projections tutorial: https://github.com/OSGeo/gdal/pull/14285 * Doc: Add WCS examples: https://github.com/OSGeo/gdal/pull/14239 * Documentation clarifications over available pipeline parameters: https://github.com/OSGeo/gdal/issues/14389 * Doc: gdal vector check-geometry: https://github.com/OSGeo/gdal/issues/13844 * Doc: Add MSSQL Driver examples: https://github.com/OSGeo/gdal/pull/14405 ## Dan Continuing GEOS curve support * CLI argument consist'ification to use --input/--output instead of --src/--dest[ination]. Old incantations will still be allowed but hidden to encourage usage of input/output * Polygonize, distance calc, and geometry splitting algorithms in OGR that leverage GEOS curve support ## Even * 100+ items * GDAL 3.12.4 release * GDAL 3.13.0 b1 and b2 releases * Claude Mythos security-related issues via private contact (mostly old HDF/EOS library) * Even no longer reviewing vibe-coded stuff. Too easy to generate verbose code that is difficult to maintain relative to the rest of GDAL. * Docker images now bumped to 26.06 * gdal driver geopackage validate * document explaining differences between vsicurl/vsihttp/vsicurl_streaming * libtiff security activities * Planning to attend the June 18th arrow+parquet meetup in Paris # Next Meeting The next GDAL Maintainers Meeting is 05/28/2026 at 13:00 UTC. Project contributors should contact Howard Butler for an invite. # Online Version https://gist.github.com/hobu/5e8e454c34402629e823f8212374cf36 # 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 even.rouault at spatialys.com Sat May 2 14:18:55 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 2 May 2026 23:18:55 +0200 Subject: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. In-Reply-To: References: Message-ID: <5d79a994-68f6-44f5-b0f5-1bd56d191285@spatialys.com> +1 Even (I had a successful try of the implementation PR with ubuntu 24.04) Le 27/04/2026 ? 17:06, Paul Harwood via gdal-dev a ?crit?: > I created and published RFC 112 > ?to propose that we > remove support for Mono mcs from the CMAKE scripts. > > The implementation PR is now available > > > I would?like to propose that this RFC is accepted. > > Thanks > > Paul > > _______________________________________________ > 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Sun May 3 13:17:25 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Sun, 3 May 2026 20:17:25 +0000 Subject: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. In-Reply-To: <5d79a994-68f6-44f5-b0f5-1bd56d191285@spatialys.com> References: <5d79a994-68f6-44f5-b0f5-1bd56d191285@spatialys.com> Message-ID: +1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Sunnuntai 3. toukokuuta 2026 0.18 Vastaanottaja: Paul Harwood ; gdal-dev Aihe: Re: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. ? +1 Even (I had a successful try of the implementation PR with ubuntu 24.04) Le 27/04/2026 ? 17:06, Paul Harwood via gdal-dev a ?crit?: I created and published?RFC 112?to propose that we remove support for Mono mcs from the CMAKE scripts. The implementation PR is now available I would?like to propose that this RFC is accepted. Thanks Paul _______________________________________________ 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From j1 at jimenezshaw.com Sun May 3 13:38:25 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Sun, 3 May 2026 22:38:25 +0200 Subject: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. In-Reply-To: References: <5d79a994-68f6-44f5-b0f5-1bd56d191285@spatialys.com> Message-ID: +1 Javier On Sun, 3 May 2026, 22:17 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: Sunnuntai 3. toukokuuta 2026 0.18 > Vastaanottaja: Paul Harwood ; gdal-dev < > gdal-dev at lists.osgeo.org> > Aihe: Re: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support > from the CMAKE scripts. > > > > > > HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista > l?hett?j??. > OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner > igen avs?ndaren. > NOTE! External sender. Do not open links or attachments unless you > recognize the sender. > > +1 Even (I had a successful try of the implementation PR with ubuntu 24.04) > Le 27/04/2026 ? 17:06, Paul Harwood via gdal-dev a ?crit : > > > I created and published RFC 112 to propose that we remove support for Mono > mcs from the CMAKE scripts. > > > The implementation PR is now available > > > I would like to propose that this RFC is accepted. > > > Thanks > > > Paul > > _______________________________________________ > 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. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > _______________________________________________ > 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 Sun May 3 13:48:13 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Sun, 03 May 2026 16:48:13 -0400 Subject: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. In-Reply-To: References: <5d79a994-68f6-44f5-b0f5-1bd56d191285@spatialys.com> Message-ID: <63D829C0-2FB4-4CA4-A042-EF25D568036A@gmail.com> +1 Mike -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps ?On 5/3/26, 4:17 PM, "gdal-dev on behalf of Rahkonen Jukka via gdal-dev" on behalf of 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: Sunnuntai 3. toukokuuta 2026 0.18 Vastaanottaja: Paul Harwood >; gdal-dev > Aihe: Re: [gdal-dev] Motion : Accept RFC 112 - Remove Mono MCS support from the CMAKE scripts. HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. +1 Even (I had a successful try of the implementation PR with ubuntu 24.04) Le 27/04/2026 ? 17:06, Paul Harwood via gdal-dev a ?crit : I created and published RFC 112 to propose that we remove support for Mono mcs from the CMAKE scripts. The implementation PR is now available I would like to propose that this RFC is accepted. Thanks Paul _______________________________________________ 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ 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 May 4 03:46:42 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 4 May 2026 12:46:42 +0200 Subject: [gdal-dev] GDAL 3.13.0 release candidate available Message-ID: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Hi, I have prepared a GDAL/OGR 3.13.0 "Iowa City" 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.13.0RC1/NEWS.md Pick up an archive among the following ones (by ascending size): ? https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0rc1.tar.xz ? https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0rc1.tar.gz ? https://download.osgeo.org/gdal/3.13.0/gdal3130rc1.zip A snapshot of the gdalautotest suite is also available : https://download.osgeo.org/gdal/3.13.0/gdalautotest-3.13.0rc1.zip A snapshot of the documentation is at: ? https://download.osgeo.org/gdal/3.13.0/gdal3130doc.zip The release/3.13 branch has now been created, and master is now open for 3.14.0dev. The following changes have been done since beta2: - GDALRasterBand::IRasterIO(): avoid potential int overflow (ossfuzz#506741816) - GDALAlgorithm: check Run() is called at most once per instance - gdal: make sure stdout is properly flushed (#14477) - gdal raster contour: rename --src-nodata to --input-nodata - gdal raster edit: add --color-map to set a color table on a band, and --unset-color-table to remove it - gdal raster footprint: rename --dst-crs to --output-crs - gdal raster footprint: rename --src-nodata to --input-nodata - gdal raster index: rename --dst-crs to --output-crs - gdal raster reproject: rename --src-crs and --dst-crs to --input-crs and ? --output-crs - gdal raster reproject: rename --src-nodata,--dst-nodata to --input-nodata, ? --output-nodata - gdal raster rgb-to-palette: rename --dst-nodata to --output-nodata - gdal raster scale: rename --[src/dst][min/max] to --[input/output][min/max] - gdal raster stack/mosaic: rename --src-nodata,--dst-nodata to --input-nodata, ? --output-nodata - gdal raster tile: rename --dst-nodata to --output-nodata - gdal raster viewshed: rename --dst-nodata to --output-nodata - gdal-bash-completion: make it msys2 compatible - AIG driver: avoid potential stack buffer overflow in CCITTRLE code, and a read heap buffer overflow when opening 'hdr.adf' (#14469) - GRIB driver: fix heap-Buffer-Overflow WRITE on corrupted/hostile data (#14455) - GRIB driver: avoid heap-buffer-overflow in specunpack() (#14470) - HDF4-EOS: fix various vulnerabilities (#14428, #14430, #14431, #14440) - ISIS3 driver: correctly deal with PVL keys with '/' character in JSON representation (#14443) - MRF driver: Fix against corrupted/hostile data (#14472) - NITF driver: fix potential stack buffer overflow in NITFLoadAttributeSection() (#14449) - PCIDSK driver: avoid integer overflow (ossfuzz#500171204) - TileDB driver: do not try to identify /vsis3/.../file.tif files - VRT driver: fix heap-buffer-overflow on misconfigured VRTProcessedDataset (#14462) - WMSDriverSubdatasetInfo::parseFileName(): fix crash if LAYERS= is not fully capitalized (ossfuzz#505232394) - gdal vector concat: rename --src-crs and --dst-crs to --input-crs and --output-crs - gdal vector clip: make it preserve aspatial layers in passthroug mode, rather ? than wiping out their features (#14438) - gdal vector index: rename --dst-crs to --output-crs - gdal vector make-point: rename --dst-crs to --output-crs - gdal vector materialize: fix issues with SQLite format (#14444) - gdal vector rasterize: make --tap depends on --resolution (#14458) - gdal vector reproject: rename --src-crs and --dst-crs to --input-crs and ? --output-crs - gdal vector reproject/clean-coverage/simplify-coverage: make it passthrough ? for non-spatial layers (#14446) - gdal vector set-field-type: rename --src-field-type to --input-field-type - OpenFileGDB driver: when exploring layers in GDB_Items, report deleted rows with a warning instead of a failure (#14424) - PG driver: avoid error when setting a NULL geometry field on a result layer without geometry field - Python bindings: Make gdal.alg.xxxx(...) accept aliases and hidden aliases of argument names - Python bindings: Handle numpy types in Feature.SetField Best regards, Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From gdt at lexort.com Mon May 4 08:15:33 2026 From: gdt at lexort.com (Greg Troxel) Date: Mon, 04 May 2026 11:15:33 -0400 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> (Even Rouault via gdal-dev's message of "Mon, 4 May 2026 12:46:42 +0200") References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: Even Rouault via gdal-dev writes: > I have prepared a GDAL/OGR 3.13.0 "Iowa City" release candidate. Built fine on NetBSD 10 amd64. NEWS has a pointer to MIGRATION_GUIDE.TXT, and that file contains a link to online docs (which feels like a minor bug; the migration guide should be IMHO be in the sources). But, on following the link, there is no 3.12 to 3.13 content. In NEWS, a missed newly-installed file: include/gdal_mem.h there are a lot of new gdal subcommand man pages, not mentioned in NEWS. It's not clear to me how users would find these. there are a lot of new bash completion functions, not mentoined in NEWS Not a big deal for users, but I try to line up changes in the set of installed files with NEWS to make sure I'm not making a packaging error. Removing the shlib change, the packing list changes by adding the following: +include/gdal_mem.h +include/gdal_thread_pool.h +include/ogr_refcountedptr.h +man/man1/gdal-dataset-check.1 +man/man1/gdal-raster-read.1 +man/man1/gdal-raster-write.1 +man/man1/gdal-vector-combine.1 +man/man1/gdal-vector-create.1 +man/man1/gdal-vector-dissolve.1 +man/man1/gdal-vector-export-schema.1 +man/man1/gdal-vector-read.1 +man/man1/gdal-vector-rename-layer.1 +man/man1/gdal-vector-sort.1 +man/man1/gdal-vector-update.1 +man/man1/gdal-vector-write.1 +share/bash-completion/completions/gdal2tiles +share/bash-completion/completions/gdal2xyz +share/bash-completion/completions/gdal_calc +share/bash-completion/completions/gdal_edit +share/bash-completion/completions/gdal_fillnodata +share/bash-completion/completions/gdal_merge +share/bash-completion/completions/gdal_polygonize +share/bash-completion/completions/gdal_proximity +share/bash-completion/completions/gdal_retile +share/bash-completion/completions/gdal_sieve +share/bash-completion/completions/gdalcompare +share/bash-completion/completions/gdalmove +share/bash-completion/completions/ogr_layer_algebra +share/bash-completion/completions/ogrmerge ---------------------------------------- And, with packager hat off and user hat on: GeoJSON driver: * minify output (no whitespace) for Feature objects To me, this is a regression rather than a feature. A key point for geojson to me is that it's nerd readable, and it makes it harder for what I see as a minor change in file size. I can see a switch to ask for minified output, but I really wonder who sues geojson and what they on balance care about. I can't really say that I read these files a lot, so the byte savings might well be on better across all users. On a real dataset I happen to be working on, with 234 point features: 41231 bytes 3.12.2 36338 bytes 3.13.0 126976 bytes in the geopackage storing the features I do very much appreciate that geojson as written has one feature per line. That is perhaps a compromise between full-on remove all whitspace and nerd-reading comfort. From even.rouault at spatialys.com Mon May 4 08:28:25 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 4 May 2026 17:28:25 +0200 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: <24c20b0f-0fcb-4394-9e76-8c239f093af0@spatialys.com> Le 04/05/2026 ? 17:15, Greg Troxel via gdal-dev a ?crit?: > Even Rouault via gdal-dev writes: > >> I have prepared a GDAL/OGR 3.13.0 "Iowa City" release candidate. > Built fine on NetBSD 10 amd64. > > NEWS has a pointer to MIGRATION_GUIDE.TXT, and that file contains a link > to online docs (which feels like a minor bug; the migration guide should > be IMHO be in the sources). But, on following the link, there is no > 3.12 to 3.13 content. That section will be available when 3.13 is the new default 'stable' doc branch. In the meantime this is in https://github.com/OSGeo/gdal/blob/master/doc/source/user/migration_guide.rst#from-gdal-312-to-gdal-313 > > In NEWS, > > a missed newly-installed file: include/gdal_mem.h ok, added > > there are a lot of new gdal subcommand man pages, not mentioned in > NEWS. It's not clear to me how users would find these. they are related to the new utilities mentionned in the in a nutshell section. "gdal foo bar" -> gdal_foo_bar.1" > > there are a lot of new bash completion functions, not mentoined in > NEWS Just new links for the non-py versions of the Python scripts -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From jukka.rahkonen at maanmittauslaitos.fi Mon May 4 10:17:04 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Mon, 4 May 2026 17:17:04 +0000 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: Hi, When it comes to reducing whitespace in GeoJSON and geojsonseq, I believe (and also tested with GDAL 3.13.0beta2 "Iowa City", released 2026/04/29) that the newlines between features remain. The corresponding PR is https://github.com/OSGeo/gdal/pull/13485. -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Greg Troxel via gdal-dev puolesta L?hetetty: Maanantai 4. toukokuuta 2026 18.15 Vastaanottaja: Even Rouault via gdal-dev Aihe: Re: [gdal-dev] GDAL 3.13.0 release candidate available HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. Even Rouault via gdal-dev writes: > I have prepared a GDAL/OGR 3.13.0 "Iowa City" release candidate. Built fine on NetBSD 10 amd64. NEWS has a pointer to MIGRATION_GUIDE.TXT, and that file contains a link to online docs (which feels like a minor bug; the migration guide should be IMHO be in the sources). But, on following the link, there is no 3.12 to 3.13 content. In NEWS, a missed newly-installed file: include/gdal_mem.h there are a lot of new gdal subcommand man pages, not mentioned in NEWS. It's not clear to me how users would find these. there are a lot of new bash completion functions, not mentoined in NEWS Not a big deal for users, but I try to line up changes in the set of installed files with NEWS to make sure I'm not making a packaging error. Removing the shlib change, the packing list changes by adding the following: +include/gdal_mem.h +include/gdal_thread_pool.h +include/ogr_refcountedptr.h +man/man1/gdal-dataset-check.1 +man/man1/gdal-raster-read.1 +man/man1/gdal-raster-write.1 +man/man1/gdal-vector-combine.1 +man/man1/gdal-vector-create.1 +man/man1/gdal-vector-dissolve.1 +man/man1/gdal-vector-export-schema.1 +man/man1/gdal-vector-read.1 +man/man1/gdal-vector-rename-layer.1 +man/man1/gdal-vector-sort.1 +man/man1/gdal-vector-update.1 +man/man1/gdal-vector-write.1 +share/bash-completion/completions/gdal2tiles +share/bash-completion/completions/gdal2xyz +share/bash-completion/completions/gdal_calc +share/bash-completion/completions/gdal_edit +share/bash-completion/completions/gdal_fillnodata +share/bash-completion/completions/gdal_merge +share/bash-completion/completions/gdal_polygonize +share/bash-completion/completions/gdal_proximity +share/bash-completion/completions/gdal_retile +share/bash-completion/completions/gdal_sieve +share/bash-completion/completions/gdalcompare +share/bash-completion/completions/gdalmove +share/bash-completion/completions/ogr_layer_algebra +share/bash-completion/completions/ogrmerge ---------------------------------------- And, with packager hat off and user hat on: GeoJSON driver: * minify output (no whitespace) for Feature objects To me, this is a regression rather than a feature. A key point for geojson to me is that it's nerd readable, and it makes it harder for what I see as a minor change in file size. I can see a switch to ask for minified output, but I really wonder who sues geojson and what they on balance care about. I can't really say that I read these files a lot, so the byte savings might well be on better across all users. On a real dataset I happen to be working on, with 234 point features: 41231 bytes 3.12.2 36338 bytes 3.13.0 126976 bytes in the geopackage storing the features I do very much appreciate that geojson as written has one feature per line. That is perhaps a compromise between full-on remove all whitspace and nerd-reading comfort. _______________________________________________ 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 May 4 12:44:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 4 May 2026 21:44:45 +0200 Subject: [gdal-dev] GDAL 3.13.0 RC2 available (Re: GDAL 3.13.0 release candidate available) In-Reply-To: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: <71f1657d-6f50-469b-bdc1-dcd75490d8b7@spatialys.com> Hi, here's a RC2 that fixes an issue on Windows with latest curl 8.20: ? https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0rc2.tar.xz ? https://download.osgeo.org/gdal/3.13.0/gdal-3.13.0rc2.tar.gz ? https://download.osgeo.org/gdal/3.13.0/gdal3130rc2.zip https://download.osgeo.org/gdal/3.13.0/gdalautotest-3.13.0rc2.zip Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From gdt at lexort.com Mon May 4 14:17:07 2026 From: gdt at lexort.com (Greg Troxel) Date: Mon, 04 May 2026 17:17:07 -0400 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> (Even Rouault via gdal-dev's message of "Mon, 4 May 2026 12:46:42 +0200") References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: Thanks for confirming the packing list changes are expected. Jukka: gdal 3.13.0rc1 geojson does have newlines. With RC1 (yes I know RC2 was announced just now, will update and retest), I found that pdal-lib did not build, but I had old pdal-lib (2.8.4!), and have updated to the latest release (2.10.1), and that's fine. Then, building qgis 3.44.9 (current LTR, and really, most recent code that can be viewed as stable) fails, and I think it's due to a type change in GDAL. Sending this sooner rather than later - I wonder how building qgis 3.44.9 is going for other people on other platforms. (omitting earlier part of log, NetBSD 10 amd64) [301/5656] Building CXX object src/core/CMakeFiles/qgis_core.dir/providers/ogr/qgsogrproviderconnection.cpp.o FAILED: [code=1] src/core/CMakeFiles/qgis_core.dir/providers/ogr/qgsogrproviderconnection.cpp.o /tmp/work/geography/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.9\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050800 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060f03 -DTEST_DATA_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.9/tests/testdata\" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/tmp/work/geography/qgis/work/qgis-3.44.9/cmake-pkgsrc-build/src/core/qgis_core_autogen/include -I/tmp/work/geography/qgis/work/qgis-3.44.9/cmake-pkgsrc-build -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/poly2tri -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/ept -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/copc -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/vpc -I/tmp/work/geography/qgis/work/qgis-3.44.9/cmake-pkgsrc-build/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/meshOptimizer -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/3d -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/actions -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/annotations -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/auth -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/browser -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/callouts -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/classification -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/diagram -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/dxf -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/editform -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/effects -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/elevation -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/expression -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/externalstorage -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/fieldformatter -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/geometry -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/geocoding -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/gps -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/labeling -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/labeling/rules -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/layertree -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/layout -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/locator -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/maprenderer -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/mesh -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/metadata -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/network -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/numericformats -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/painting -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/pal -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/pdf -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/plot -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/pointcloud -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/pointcloud/expression -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/processing -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/processing/models -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/proj -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/project -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/arcgis -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/memory -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/gdal -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/ogr -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/meshmemory -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/sensorthings -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/raster -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/renderer -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/scalebar -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/settings -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/sensor -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/stac -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/symbology -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/textrenderer -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/tiledscene -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/validity -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/vector -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/vectortile -I/tmp/work/geography/qgis/work/qgis-3.44.9/src/core/web -I/tmp/work/geography/qgis/work/qgis-3.44.9/external -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/delaunator-cpp -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/kdbush/include -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/nmea -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/rtree/include -I/tmp/work/geography/qgis/work/qgis-3.44.9/external/tinygltf -isystem /tmp/work/geography/qgis/work/.buildlink/include -isystem /usr/pkg/qt5/include/Qca-qt5/QtCrypto -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtCore -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/./mkspecs/netbsd-g++ -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtGui -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtXml -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtWidgets -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSvg -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtNetwork -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSql -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtConcurrent -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPositioning -isystem /tmp/work/geography/qgis/work/.buildlink/include/geos -isystem /usr/pkg/qt5/include -isystem /usr/pkg/qt5/include/QtDBus -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSerialPort -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/qt5/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/gstreamer-1.0 -I/usr/pkg/qwt-6.3.0/include -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -std=gnu++17 -fPIC -fvisibility=hidden -fPIC -MD -MT src/core/CMakeFiles/qgis_core.dir/providers/ogr/qgsogrproviderconnection.cpp.o -MF src/core/CMakeFiles/qgis_core.dir/providers/ogr/qgsogrproviderconnection.cpp.o.d -o src/core/CMakeFiles/qgis_core.dir/providers/ogr/qgsogrproviderconnection.cpp.o -c /tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/ogr/qgsogrproviderconnection.cpp /tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/ogr/qgsogrproviderconnection.cpp: In member function 'void QgsOgrProviderConnection::setDefaultCapabilities()': /tmp/work/geography/qgis/work/qgis-3.44.9/src/core/providers/ogr/qgsogrproviderconnection.cpp:422:42: error: invalid conversion from 'CSLConstList' {aka 'const char* const*'} to 'char**' [-fpermissive] 422 | char **driverMetadata = GDALGetMetadata( hDriver, nullptr ); | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ | | | CSLConstList {aka const char* const*} ninja: build stopped: subcommand failed. *** Error code 1 Stop. make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/geography/qgis *** Error code 1 Stop. make: stopped in /n0/gdt/pkgsrc-current/pkgsrc/geography/qgis From even.rouault at spatialys.com Mon May 4 14:30:49 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Mon, 4 May 2026 23:30:49 +0200 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: <0be4448e-aa22-4593-8090-485618b0e9ed@spatialys.com> > Then, building qgis 3.44.9 (current LTR, and really, most recent code > that can be viewed as stable) fails, and I think it's due to a type > change in GDAL. Sending this sooner rather than later - I wonder how > building qgis 3.44.9 is going for other people on other platforms. was fixed several months ago in QGIS master, but the backport PR got stale. Trying again with https://github.com/qgis/QGIS/pull/66016 -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From gdt at lexort.com Tue May 5 03:50:20 2026 From: gdt at lexort.com (Greg Troxel) Date: Tue, 05 May 2026 06:50:20 -0400 Subject: [gdal-dev] GDAL 3.13.0 release candidate available In-Reply-To: (Greg Troxel via gdal-dev's message of "Mon, 04 May 2026 17:17:07 -0400") References: <3ecb0c61-28d9-4429-8ffd-69a99fd962b1@spatialys.com> Message-ID: (I managed to delete the message with the PR for qgis 3.44 to build with new gdal, hence this non-thread-right reply.) Thanks for resurrecting the backport PR. I added the diff from https://github.com/qgis/QGIS/pull/66017/ to the pkgsrc entry for qgis-3.44.9, and rebuilt, with gdal 3.13.0rc1 installed. The resulting qgis starts up and displays geopackage layers, postgis layers, and WMTS/TMS layers. I don't know what the plan is in terms of cautioning packagers not to update gdal before qgis 3.44.10 (assuming the PR will land in time), or pointing out the PR, or ? But it won't bother me/pkgsrc. Greg From even.rouault at spatialys.com Tue May 5 17:38:56 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 6 May 2026 02:38:56 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release Message-ID: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From michael.smith.erdc at gmail.com Tue May 5 18:17:54 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Tue, 05 May 2026 21:17:54 -0400 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> Message-ID: <7139F2EA-9009-428B-8F27-1077CB8511E3@gmail.com> +1 Mike -- Michael Smith RSGIS Center ? ERDC CRREL NH US Army Corps ?On 5/5/26, 8:39 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" on behalf of gdal-dev at lists.osgeo.org > wrote: Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From j1 at jimenezshaw.com Wed May 6 00:57:18 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 6 May 2026 09:57:18 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: <7139F2EA-9009-428B-8F27-1077CB8511E3@gmail.com> References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> <7139F2EA-9009-428B-8F27-1077CB8511E3@gmail.com> Message-ID: +1 Javier On Wed, 6 May 2026 at 03:18, Michael Smith via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > +1 > > Mike > > > -- > > Michael Smith > RSGIS Center ? ERDC CRREL NH > US Army Corps > > > > > > ?On 5/5/26, 8:39 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" < > gdal-dev-bounces at lists.osgeo.org > on behalf of gdal-dev at lists.osgeo.org > > wrote: > > > Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release > > > Starting with my +1 > > > Even > > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev < > 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 jukka.rahkonen at maanmittauslaitos.fi Wed May 6 01:12:13 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Wed, 6 May 2026 08:12:13 +0000 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@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 6. toukokuuta 2026 3.38 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release Starting with my +1 Even -- http://www.spatialys.com/ My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From howard at hobu.co Wed May 6 08:24:45 2026 From: howard at hobu.co (Howard Butler) Date: Wed, 6 May 2026 10:24:45 -0500 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> Message-ID: <039F7FF2-2B52-49A0-BC64-74E72CD15560@hobu.co> +1 Howard > On May 6, 2026, at 3:12?AM, 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 6. toukokuuta 2026 3.38 > Vastaanottaja: gdal-dev at lists.osgeo.org > Aihe: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release > > > HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. > OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. > NOTE! External sender. Do not open links or attachments unless you recognize the sender. > > > > > Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release > > Starting with my +1 > > Even > > -- > http://www.spatialys.com/ > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania > > _______________________________________________ > 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 From even.rouault at spatialys.com Wed May 6 09:29:39 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 6 May 2026 18:29:39 +0200 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision Message-ID: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Hi, based on the experience gained from the initial policy, I propose to significantly revise it to drastically limit their use. See https://github.com/OSGeo/gdal/pull/14500 Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From dbaston at gmail.com Wed May 6 09:34:04 2026 From: dbaston at gmail.com (Daniel Baston) Date: Wed, 6 May 2026 12:34:04 -0400 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> Message-ID: +1 Dan On Tue, May 5, 2026 at 8:39?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > _______________________________________________ > 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 me at komzpa.net Wed May 6 10:14:22 2026 From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=) Date: Wed, 6 May 2026 21:14:22 +0400 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: Hello, Is it possible to get a better overview of the actual negative impact you're seeing? Like, with actual examples of annoyances that happened. I tried my own research going through several pages of merged/closed PRs to get my impression on what went wrong but really most PRs are there by Even, with disappearingly small number of PRs from other people both by count and by volume, seemingly not enough to trigger such drastic policy flip. What am I missing? On Wed, May 6, 2026 at 8:29?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > based on the experience gained from the initial policy, I propose to > significantly revise it to drastically limit their use. See > https://github.com/OSGeo/gdal/pull/14500 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > _______________________________________________ > 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 Wed May 6 10:24:38 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 6 May 2026 19:24:38 +0200 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: <2e2d7b53-924f-4d2c-98bc-ee12445ea2ed@spatialys.com> Le 06/05/2026 ? 19:14, Darafei "Kom?pa" Praliaskouski a ?crit?: > Hello, > > Is it possible to get a better overview of the actual negative impact > you're seeing? Like, with actual examples of annoyances that happened. > > I tried my own research going through several pages of merged/closed > PRs to get my impression on what went wrong but really most PRs are > there by Even, with disappearingly?small number of PRs from other > people both by count and by volume, seemingly not enough to trigger > such drastic policy flip. > > What am I?missing? I tried to give some justification in the revision, but I'm unfortunately very limited compared to LLM to give verbose details. Basically my few encounters with such contributions made me feel stressed an uneasy that I prefer to no longer dealing with them.? It is very disturbing to suggest a non trivial change to "someone" and that 10 minutes later a new revision pops up, and you need to spend an extra hour re-reading it and finding how subtlety wrong it might be, or uselessly verbose / bloated. Usually (with human output) 90%?of the sweet is for the PR author and 10% for the reviewer. With LLMs, this is reversed. Humans cannot fight against machines.? And let be frank, I hate this whole ecosystem & hype & circus. -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From jctoney at gmail.com Wed May 6 10:27:43 2026 From: jctoney at gmail.com (Chris Toney) Date: Wed, 6 May 2026 11:27:43 -0600 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: >What am I missing? Possibly a lot. As a regular observer of the repository that's not my impression at all. True a large number of PRs are by Even. Also true, so is a substantial amount of review, especially (if not entirely), of "difficult" PRs that take large review effort. Sustainability is a major concern IMO. Chris On Wed, May 6, 2026, 11:14 AM Darafei "Kom?pa" Praliaskouski via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hello, > > Is it possible to get a better overview of the actual negative impact > you're seeing? Like, with actual examples of annoyances that happened. > > I tried my own research going through several pages of merged/closed PRs > to get my impression on what went wrong but really most PRs are there by > Even, with disappearingly small number of PRs from other people both by > count and by volume, seemingly not enough to trigger such drastic policy > flip. > > What am I missing? > > > > On Wed, May 6, 2026 at 8:29?PM Even Rouault via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi, >> >> based on the experience gained from the initial policy, I propose to >> significantly revise it to drastically limit their use. See >> https://github.com/OSGeo/gdal/pull/14500 >> >> Even >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> Highly recommend OxiGDAL if you want to live in the 21th century and cure >> Bixonimania >> >> _______________________________________________ >> 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 gdt at lexort.com Wed May 6 10:49:39 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 06 May 2026 13:49:39 -0400 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: ("Darafei =?utf-8?Q?=5C=22Kom=D1=8Fpa=5C=22?= Praliaskouski via gdal-dev"'s message of "Wed, 6 May 2026 21:14:22 +0400") References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: Even: I would somehow keep the idea that it is not settled law if LLM output is a derived work of the inputs, in the discussion of legal issues. I keep hearing that people are able to get LLMs to output training data verbatim, proving it's in the model, Other than that, your revisions sound good to me. If it turns out other projects figure out a good way to interact and the legal issues are resolved, this can be changed later. Greg (with no vote) "Darafei \"Kom?pa\" Praliaskouski via gdal-dev" writes: > Is it possible to get a better overview of the actual negative impact > you're seeing? Like, with actual examples of annoyances that happened. Not gdal, but I was involved with review of an LLM PR to hamlib. It was extra verbose, made a lot of off-point changes, and ultimately was wrong. It was harder to figure out than it should have been. A (cooperative, good at sw) human would have just made the one change that was maybe needed, and not rolled in unrelated reorganization, and would have actually explained what the issue was, rather than a pagelong lecture on generalities that wasn't in the end actually on point. I also had a bad experience a long time ago, before there was broad LLM awareness, on a (non-geo project) mailinglist, with an email-submitted patch (eq to a PR), and after I commented on it, an LLM rejoinder/commentary was posted. The other thing you aren't seeing is that github service quality is plummeting under the load of all the submitted PRs, since mid-December, but that's off-point for this discussion. From even.rouault at spatialys.com Wed May 6 10:59:12 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 6 May 2026 19:59:12 +0200 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: Le 06/05/2026 ? 19:49, Greg Troxel a ?crit?: > Even: > > I would somehow keep the idea that it is not settled law if LLM output > is a derived work of the inputs, in the discussion of legal issues. I > keep hearing that people are able to get LLMs to output training data > verbatim, proving it's in the model, Please make a text suggestion in the PR if you want that point to be captured. Independently of whether the LLM would output verbatim, even if it is "creative", it looks like the legal opinion would be that it isn't copyrightable, because copyright is linked to human production. You could perhaps copyright the prompt (not sure, but why not? if it is creative enough), but not what the LLM has spit out from it. > > Other than that, your revisions sound good to me. If it turns out > other projects figure out a good way to interact and the legal issues > are resolved, this can be changed later. My main issue is not about the legal aspect, more about the weird interaction process of having a machine generating code vs a human reviewing it. I truly believe that if you accept LLM generated code, then in practice, you must also give up on human reviewing. -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From gdt at lexort.com Wed May 6 11:06:03 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 06 May 2026 14:06:03 -0400 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: (Even Rouault's message of "Wed, 6 May 2026 19:59:12 +0200") References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: Even Rouault writes: > Le 06/05/2026 ? 19:49, Greg Troxel a ?crit?: >> Even: >> >> I would somehow keep the idea that it is not settled law if LLM output >> is a derived work of the inputs, in the discussion of legal issues. I >> keep hearing that people are able to get LLMs to output training data >> verbatim, proving it's in the model, > Please make a text suggestion in the PR if you want that point to be > captured. Independently of whether the LLM would output verbatim, even > if it is "creative", it looks like the legal opinion would be that it > isn't copyrightable, because copyright is linked to human > production. You could perhaps copyright the prompt (not sure, but why > not? if it is creative enough), but not what the LLM has spit out from > it. Will do. I agree that the output itself is not eligible for copyright, because it was not created by a human. There is a separate question of whether it is a derived work of other copyrighted works, and thus if one needs permission under copyright law from those authors. consider a prompt: take the first 4 paragraphs of [famous book in copyright] and add two more that tlak about foo >> Other than that, your revisions sound good to me. If it turns out >> other projects figure out a good way to interact and the legal issues >> are resolved, this can be changed later. > > My main issue is not about the legal aspect, more about the weird > interaction process of having a machine generating code vs a human > reviewing it. I truly believe that if you accept LLM generated code, > then in practice, you must also give up on human reviewing. 100% agreed. I was merely pointing out that saying no now is not forever, and it's not dangerous to say no. From even.rouault at spatialys.com Wed May 6 15:04:08 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 7 May 2026 00:04:08 +0200 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood Message-ID: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Hi, I think it would be more efficient to grant push rights to the osgeo/gdal repository to Paul Harwood, @runette, particularly to deal with C# related pull requests which he has reviewed in the past months. Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From michael.smith.erdc at gmail.com Wed May 6 15:26:38 2026 From: michael.smith.erdc at gmail.com (Michael Smith) Date: Wed, 06 May 2026 18:26:38 -0400 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Message-ID: <7EA464D9-0578-4480-908C-D93127E0EB0A@gmail.com> +1 Mike ?On 5/6/26, 6:04 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" on behalf of gdal-dev at lists.osgeo.org > wrote: Hi, I think it would be more efficient to grant push rights to the osgeo/gdal repository to Paul Harwood, @runette, particularly to deal with C# related pull requests which he has reviewed in the past months. Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ 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 May 6 15:30:23 2026 From: norman.barker at gmail.com (Norman Barker) Date: Wed, 6 May 2026 17:30:23 -0500 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: <7EA464D9-0578-4480-908C-D93127E0EB0A@gmail.com> References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> <7EA464D9-0578-4480-908C-D93127E0EB0A@gmail.com> Message-ID: +1 Norman On Wed, May 6, 2026 at 5:26?PM Michael Smith via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > +1 > Mike > > ?On 5/6/26, 6:04 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" < > gdal-dev-bounces at lists.osgeo.org > on behalf of gdal-dev at lists.osgeo.org > > wrote: > > > Hi, > > > I think it would be more efficient to grant push rights to the > osgeo/gdal repository to Paul Harwood, @runette, particularly to deal > with C# related pull requests which he has reviewed in the past months. > > > Starting with my +1 > > > Even > > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > > _______________________________________________ > gdal-dev mailing list > gdal-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev < > 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 Wed May 6 17:28:19 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 7 May 2026 02:28:19 +0200 Subject: [gdal-dev] Re-organizing source tree regarding drivers? Message-ID: <60e6bf0e-536f-41ee-b2ec-33c60f750332@spatialys.com> Hi, with a number of drivers being raster+vector our current source tree organization is a bit messy. For example, we have: - ogr/ogrsf_frmts/gpkg: the GeoPackage driver started vector-only and then raster was added - frmts/mbtiles: the MBTiles driver started raster-only and then vector was added -?ogr/ogrsf_frmts/pmtiles: you can guess what I will write here - frmts/mem I'm hesitating between: - putting all drivers below a drivers/? directory - or having drivers/raster/ , drivers/vector/ and drivers/mixed/ This later organization avoids a bit the issue of a monolithic drivers/ with 250+ subdirectories (who knows if Windows might not limit to 256 :-)),? but it may involve moving code around when something that was raster or vector only later gains the other capability. We should likely migrate OGR_ENABLE_DRIVER_XXXX CMake variables to using the GDAL_ prefix. And C entry points for plugins would be all GDALRegisterXXXX() and shared libary names all gdal_XXXXX.dll/so While we are it: - gcore/ would be split between core/generic (driver and dataset classes) and core/raster. - gcore/multidim/ --> core/multidim/ - ogr/ and ogr/ogrsf_frmts/generic would become core/vector/? , possibly with a core/vector/geometry for core geometry classes, and core/crs/ for OSR related classes Thoughts? (I'm wondering how such a plan could be executed without freezing all pull request activity in the meantime to limit conflicts, although git might perhaps be smart enough to detect files moving around) Even -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania From even.rouault at spatialys.com Wed May 6 18:11:34 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 7 May 2026 03:11:34 +0200 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> Message-ID: <52bd4762-04a8-4c7c-88cf-81a3b9c1b597@spatialys.com> As an example of the kind of horrors LLM code can produce, look at https://github.com/OSGeo/gdal/commit/135cd919e75ed35ca384c058e083b3dbafc06a5b which undoes the bloat a previous LLM-generated commit had caused. I was really mad when I discovered this: - when you use intrinsincs, you care about (near) optimality. Here the code was doing useless manual clamping to [0, 255], which is exactly what the intrinsincs _mm_packus_epi16() does afterwards - and I was mad against myself for not having detected that at review time (but we all know that humans are terrible at reviewing code, hence they need to be eliminated) It seems very unlikely a human would have produced such code, because the cost of writing that useless clamping, and getting it right, would have been too high compared to the initial reading of the doc of the _mm_pack intrinsincs and realizing they already do the wished clamping. It looks like LLM would behave like developers payed proportionally to the number of lines of code they produce, which we all know is a terrible metrics. Le 06/05/2026 ? 19:14, Darafei "Kom?pa" Praliaskouski a ?crit?: > Hello, > > Is it possible to get a better overview of the actual negative impact > you're seeing? Like, with actual examples of annoyances that happened. > > I tried my own research going through several pages of merged/closed > PRs to get my impression on what went wrong but really most PRs are > there by Even, with disappearingly?small number of PRs from other > people both by count and by volume, seemingly not enough to trigger > such drastic policy flip. > > What am I?missing? > > > > On Wed, May 6, 2026 at 8:29?PM Even Rouault via gdal-dev > wrote: > > Hi, > > based on the experience gained from the initial policy, I propose to > significantly revise it to drastically limit their use. See > https://github.com/OSGeo/gdal/pull/14500 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century > and cure Bixonimania > > _______________________________________________ > 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. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Wed May 6 18:33:20 2026 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Wed, 6 May 2026 21:33:20 -0400 Subject: [gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision In-Reply-To: <52bd4762-04a8-4c7c-88cf-81a3b9c1b597@spatialys.com> References: <9e952c2c-9108-4ac2-ba2f-442eedbfed61@spatialys.com> <52bd4762-04a8-4c7c-88cf-81a3b9c1b597@spatialys.com> Message-ID: I've seen this in other instances... Where the generated code is doing things like argument checking before calling some library function when the function explicitly handles the case. The AI doesn't seem to read the docs :) Andrew Bell andrew.bell.ia at gmail.com On Wed, May 6, 2026, 9:11?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > As an example of the kind of horrors LLM code can produce, look at > https://github.com/OSGeo/gdal/commit/135cd919e75ed35ca384c058e083b3dbafc06a5b > which undoes the bloat a previous LLM-generated commit had caused. I was > really mad when I discovered this: > > - when you use intrinsincs, you care about (near) optimality. Here the > code was doing useless manual clamping to [0, 255], which is exactly what > the intrinsincs _mm_packus_epi16() does afterwards > > - and I was mad against myself for not having detected that at review time > (but we all know that humans are terrible at reviewing code, hence they > need to be eliminated) > > It seems very unlikely a human would have produced such code, because the > cost of writing that useless clamping, and getting it right, would have > been too high compared to the initial reading of the doc of the _mm_pack > intrinsincs and realizing they already do the wished clamping. It looks > like LLM would behave like developers payed proportionally to the number of > lines of code they produce, which we all know is a terrible metrics. > Le 06/05/2026 ? 19:14, Darafei "Kom?pa" Praliaskouski a ?crit : > > Hello, > > Is it possible to get a better overview of the actual negative impact > you're seeing? Like, with actual examples of annoyances that happened. > > I tried my own research going through several pages of merged/closed PRs > to get my impression on what went wrong but really most PRs are there by > Even, with disappearingly small number of PRs from other people both by > count and by volume, seemingly not enough to trigger such drastic policy > flip. > > What am I missing? > > > > On Wed, May 6, 2026 at 8:29?PM Even Rouault via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> Hi, >> >> based on the experience gained from the initial policy, I propose to >> significantly revise it to drastically limit their use. See >> https://github.com/OSGeo/gdal/pull/14500 >> >> Even >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> Highly recommend OxiGDAL if you want to live in the 21th century and cure >> Bixonimania >> >> _______________________________________________ >> 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. > Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania > > _______________________________________________ > 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 j1 at jimenezshaw.com Wed May 6 22:09:01 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 7 May 2026 07:09:01 +0200 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> <7EA464D9-0578-4480-908C-D93127E0EB0A@gmail.com> Message-ID: +1 Javier On Thu, 7 May 2026, 00:30 Norman Barker via gdal-dev, < gdal-dev at lists.osgeo.org> wrote: > +1 > > Norman > > On Wed, May 6, 2026 at 5:26?PM Michael Smith via gdal-dev < > gdal-dev at lists.osgeo.org> wrote: > >> +1 >> Mike >> >> ?On 5/6/26, 6:04 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" < >> gdal-dev-bounces at lists.osgeo.org >> on behalf of gdal-dev at lists.osgeo.org > >> wrote: >> >> >> Hi, >> >> >> I think it would be more efficient to grant push rights to the >> osgeo/gdal repository to Paul Harwood, @runette, particularly to deal >> with C# related pull requests which he has reviewed in the past months. >> >> >> Starting with my +1 >> >> >> Even >> >> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. >> Highly recommend OxiGDAL if you want to live in the 21th century and cure >> Bixonimania >> >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev < >> 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 jukka.rahkonen at maanmittauslaitos.fi Thu May 7 00:58:20 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Thu, 7 May 2026 07:58:20 +0000 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Message-ID: +1 -Jukka Rahkonen- ________________________________________ L?hett?j?: gdal-dev k?ytt?j?n Even Rouault via gdal-dev puolesta L?hetetty: Torstai 7. toukokuuta 2026 1.04 Vastaanottaja: gdal-dev at lists.osgeo.org Aihe: [gdal-dev] Motion: grant push rights to Paul Harwood HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista l?hett?j??. OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner igen avs?ndaren. NOTE! External sender. Do not open links or attachments unless you recognize the sender. Hi, I think it would be more efficient to grant push rights to the osgeo/gdal repository to Paul Harwood, @runette, particularly to deal with C# related pull requests which he has reviewed in the past months. Starting with my +1 Even -- http://www.spatialys.com/ My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania _______________________________________________ gdal-dev mailing list gdal-dev at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev From fwarmerdam at gmail.com Thu May 7 04:40:26 2026 From: fwarmerdam at gmail.com (Frank Warmerdam) Date: Thu, 7 May 2026 07:40:26 -0400 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Message-ID: +1 Frank On Thu, May 7, 2026 at 3:58?AM 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: Torstai 7. toukokuuta 2026 1.04 > Vastaanottaja: gdal-dev at lists.osgeo.org > Aihe: [gdal-dev] Motion: grant push rights to Paul Harwood > > > HUOM! Ulkoinen l?hett?j?. ?l? avaa linkkej? tai liitteit?, ellet tunnista > l?hett?j??. > OBS! Extern avs?ndare. ?ppna inte l?nkar eller bilagor om du inte k?nner > igen avs?ndaren. > NOTE! External sender. Do not open links or attachments unless you > recognize the sender. > > > > > Hi, > > I think it would be more efficient to grant push rights to the > osgeo/gdal repository to Paul Harwood, @runette, particularly to deal > with C# related pull requests which he has reviewed in the past months. > > Starting with my +1 > > Even > > -- > http://www.spatialys.com/ > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > _______________________________________________ > 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 > -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, fwarmerdam at gmail.com light and sound - activate the windows | and watch the world go round - Rush | Geospatial Programmer for Rent -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorissette at mapgears.com Thu May 7 05:44:25 2026 From: dmorissette at mapgears.com (Daniel Morissette) Date: Thu, 7 May 2026 08:44:25 -0400 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Message-ID: <08254dae-98e7-49a6-b525-69f8bab74182@mapgears.com> +1 Daniel On 2026-05-06 18:04, Even Rouault via gdal-dev wrote: > Hi, > > I think it would be more efficient to grant push rights to the > osgeo/gdal repository to Paul Harwood, @runette, particularly to deal > with C# related pull requests which he has reviewed in the past months. > > Starting with my +1 > > Even > -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Thu May 7 05:51:37 2026 From: dbaston at gmail.com (Daniel Baston) Date: Thu, 7 May 2026 08:51:37 -0400 Subject: [gdal-dev] Motion: grant push rights to Paul Harwood In-Reply-To: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> References: <869bc68b-52d8-48c6-a320-038bea2898b3@spatialys.com> Message-ID: +1 Dan On Wed, May 6, 2026 at 6:04?PM Even Rouault via gdal-dev < gdal-dev at lists.osgeo.org> wrote: > Hi, > > I think it would be more efficient to grant push rights to the > osgeo/gdal repository to Paul Harwood, @runette, particularly to deal > with C# related pull requests which he has reviewed in the past months. > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Highly recommend OxiGDAL if you want to live in the 21th century and cure > Bixonimania > > _______________________________________________ > 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 May 8 02:32:45 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 8 May 2026 11:32:45 +0200 Subject: [gdal-dev] Motion: approve GDAL 3.13.0 rc2 as final release In-Reply-To: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> References: <3a432c1f-f0bd-4c67-8037-5b9d4e89fae2@spatialys.com> Message-ID: Adopted with +1 from PSC members MikeS, JavierJS, JukkaR, HowardB, DanB and me. Le 06/05/2026 ? 02:38, Even Rouault via gdal-dev a ?crit?: > Motion: approve GDAL 3.13.0 rc2 as final 3.13.0 release > > Starting with my +1 > > Even > -- http://www.spatialys.com My software is free, but my time generally not. Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania