From lists at borysjurgiel.pl  Sun Mar  1 15:28:04 2026
From: lists at borysjurgiel.pl (Borys Jurgiel)
Date: Mon, 2 Mar 2026 00:28:04 +0100
Subject: [QGIS-Developer] 
 =?utf-8?q?Plugins=E2=80=99_Dual_QGIS_3_and_QGIS?=
 =?utf-8?q?_4_Compatibility?=
In-Reply-To: <CA+3oMjt=JZMbeYFRimX+B4tC5YZOL21NDdf-DfRL=OfqFyQjpQ@mail.gmail.com>
References: <e7c26bf5-b893-4727-8632-025c7800f931@borysjurgiel.pl>
 <44433d5b-9267-4400-b076-0d2e43ac3d17@duif.net>
 <CA+3oMjt=JZMbeYFRimX+B4tC5YZOL21NDdf-DfRL=OfqFyQjpQ@mail.gmail.com>
Message-ID: <85fbe932-8c26-45f9-bfac-77bd57b583a9@borysjurgiel.pl>

Thanks Richard and Werner for your thoughts on this. In this case it's 
pretty straightforward - see https://github.com/qgis/QGIS/pull/65146

Best regards,
Borys


W dniu 26.02.2026 o?12:34, Werner Macho pisze:
> Hi Borys, all,
> 
> I also made it through the mail and would prefer option?2.
> In such cases I prefer taking away the automation things and make the 
> developers of the plugin responsible again.
> metadata updating should only be a matter of minutes for every plugin dev.
> 
> regards
> Werner
> 
> On Thu, Feb 26, 2026 at 11:40?AM Richard Duivenvoorde via QGIS-Developer 
> <qgis-developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> 
> wrote:
> 
>     Hi Borys,
> 
>     I fully agree with your analysis (cc'ing lova which is doing current
>     plugins server software).
> 
>     My choice would be your option 2: dropping the Qt6 tag etc etc
> 
>     So what about doing this for QGIS4 only? Would that be an option?
>     When we move to QGIS4/Qt6 metadata and plugins have to be updated
>     anyway.
> 
>     Others?
> 
>     Regards.
> 
>     Richard Duivenvoorde
> 
> 
>     On 2/24/26 21:35, Borys Jurgiel via QGIS-Developer wrote:
>      > I just realized that our mess with the `qgis_maximum_version` tag
>     is escalating, and this may be the last moment to rethink whether we
>     really want it to be set automatically.
>      >
>      > Years ago, I introduced this tag to the plugin installer in order
>     to extend the compatibility range to more than one major version,
>     which is exactly our current case. At the same time, @ElPaso
>     implemented it in the repository application, but somehow we didn?t
>     fully align on the idea: for me it was optional and not meant to be
>     set by default. When it is missing, the plugin installer assumes
>     compatibility up to the very end of the same major version. On the
>     other hand, the repository always sets it to x.99 if it is not
>     present. Many authors then assumed it was mandatory and started
>     tagging plugins as x.99 or x.98. I guess we never really discussed
>     this topic, and now we have a full variety of `qgis_maximum_version`
>     values: either explicitly set by authors or automatically added by
>     the repository. Furthermore, in recent years, the `qt6_compatible`
>     tag was introduced, which made perfect sense at the time. However,
>     it is now redundant if at least one of the version bounds is set
>      > to >= 4.0.
>      >
>      > Everything worked well as long as the PyQGIS API version was
>     3.99. When it was bumped to 4.0 last year (not to be confused with
>     the general QGIS version), all Qt6-compatible plugins without
>     `qgis_maximum_version` explicitly set to 4 became broken:
>      >
>      > https://github.com/qgis/QGIS/issues/62359 <https://github.com/
>     qgis/QGIS/issues/62359>
>      >
>      > @JEF partially fixed this in:
>      >
>      > https://github.com/jef-n/QGIS/commit/
>     eac401c009f11f58c0ac2253c98d35ec6338ca60 <https://github.com/jef-n/
>     QGIS/commit/eac401c009f11f58c0ac2253c98d35ec6338ca60>
>      >
>      > However, this only fixed loading plugins that were already
>     installed in QGIS 3. In QGIS 4, they are not available from the
>     official repository, so it is impossible to (re)install them. This
>     happens because the condition `if not qgisMaximumVersion (...) and
>     supports_qt6`: fails twice, as the official repository always
>     returns the `qgis_maximum_version` and never returns `supports_qt6`.
>      >
>      > This is very unexpected behaviour, so many plugin authors
>     explicitly set `qgis_maximum_version` to 4.99 in their plugins, what
>     is actually how the tag was originally intended to be used in the
>     installer. Currently, there are 171 or 182 such plugins in the
>     official repository with `qgis_maximum_version` explicitly set to >=
>     4.0 (I don't know how many Qt6-compatible plugins are in the repo in
>     total).
>      >
>      > I can see two straightforward ways to fix this issue, but they
>     raise a strategic question: do we really want `qgis_maximum_version`
>     to be completed automatically?
>      >
>      > 1: If we want the function of forcibly bumping Qt6 plugins from
>     3.x to 4.99 to work properly, it simply needs to be implemented in
>     the official repository application as well, so that such plugins
>     are exposed to the installer as 4.99 rather than 3.99.
>      > Pros: everything will work as expected.
>      > Cons: we introduce that rather nasty hardcoded 4.99 for a couple
>     of years, and anybody will understand how it works in detail.
>      >
>      > 2: Or should we return to the original idea: make
>     `qgis_maximum_version` optional, stop adding it in the repository
>     when it is not present (and only handle it internally when resolving
>     the version filter), and strictly require plugin authors to set this
>     tag if they want to support dual major versions? In this scenario,
>     we should also drop the qt6_compatible tag.
>      > Pros: we keep things simple and unambiguous.
>      > Cons: we break unprepared plugins until their metadata are updated.
>      >
>      > Personally, I?m fine with either solution, but with this rather
>     long story I just wanted to provide some context on how we ended up
>     here. Thanks to anyone who made it to the end :)
>      >
>      > Borys
>      > _______________________________________________
>      > QGIS-Developer mailing list
>      > QGIS-Developer at lists.osgeo.org <mailto:QGIS-
>     Developer at lists.osgeo.org>
>      > List info: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>      > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
>     developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 


From snigdha.lee75 at gmail.com  Mon Mar  9 03:39:03 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Mon, 9 Mar 2026 16:09:03 +0530
Subject: [QGIS-Developer] =?utf-8?q?GSoC_2026_=E2=80=94_Enhancing_ogrinfo?=
	=?utf-8?q?_Processing_Algorithms_in_QGIS?=
Message-ID: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>

Hi Valentin,

My name is Sionigdha and I'm interested in contributing to QGIS through
GSoC 2026.

While exploring the QGIS codebase I looked at OgrInfo.py in the GDAL
processing algorithms and noticed that several GDAL ogrinfo capabilities
are not exposed as typed parameters  specifically -fid, -where, -spat,
-geom, -fields, and -limit. Users currently have to use the raw EXTRA
string field to access these, which is undiscoverable and unusable in
processing models.

This caught my attention because I've been contributing to GDAL for the
past 3 months with multiple merged PRs including #13904 (adding --fid to
gdalinfo/GDALVectorInfo, merged in GDAL 3.13.0), #13812 (WMS/WMTS
network-dependent test improvements), and several documentation fixes. Full
list: https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged

I've also been contributing directly to QGIS including PR #64620 (merged
into QGIS 4.0.0) clarifying QgsLogger behavior, and several other
documentation PRs targeting 4.0.0. Full list:
https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged

I'm currently working on building QGIS from source as per Exercise 0  my
machine has hardware constraints but I'm working through them.
I've been working on a prototype patch that adds -where, -fid, and -spat as
proper typed parameters to both ogrinfo and ogrinfojson, happy to share it
shortly.

My proposed project for GSoC would be:
1. Expose all missing ogrinfo parameters as typed, modelable inputs in both
ogrinfo and ogrinfojson
2. Make ogrinfojson output structured and chainable within the processing
framework  field count, feature count, geometry type, extent as named
outputs
3. Add a new ogrfeatureinfo processing algorithm that takes a layer + FID
or WHERE clause and returns structured per-feature output  field values,
geometry type, WKT  usable as inputs in processing models
4. Full test coverage for all additions targeting QGIS 4.x

I'm comfortable in Python and PyQGIS, and I understand this targets QGIS
4.x with GDAL 3.13.0 as the baseline ? which aligns directly with my GDAL
work.

Would you be open to discussing this as a GSoC 2026 proposal?

Best,
Sionigdha Sadhukhan
GitHub: https://github.com/Sionigdha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260309/4b31b7b8/attachment.htm>

From andreaerdna at libero.it  Mon Mar  9 06:41:00 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Mon, 9 Mar 2026 14:41:00 +0100
Subject: [QGIS-Developer] 
 =?utf-8?q?GSoC_2026_=E2=80=94_Enhancing_ogrinfo?=
 =?utf-8?q?_Processing_Algorithms_in_QGIS?=
Message-ID: <3efd5c0f-92e7-48ff-9c8c-4a73fbf467ed@libero.it>

Il 09/03/2026 11:39, Sionigdha Sadhukhan via QGIS-Developer ha scritto:
> Users currently have to use the raw EXTRA 
> string field to access these, which is undiscoverable and unusable in 
> processing models.

Hi Sionigdha,
for your information, such EXTRA parameter is an "Advanced parameter" 
and thus it can be displayed and used in processing models just clicking 
on the "Show advanced parameters" button available in the processing 
algorithms editing dialog window in the Model Designer.

Regards.

Andrea Giudiceandrea

From valentin.buira at gmail.com  Mon Mar  9 13:02:52 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Mon, 9 Mar 2026 21:02:52 +0100
Subject: [QGIS-Developer] 
 =?utf-8?q?GSoC_2026_=E2=80=94_Enhancing_ogrinfo?=
 =?utf-8?q?_Processing_Algorithms_in_QGIS?=
In-Reply-To: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>
References: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>
Message-ID: <9fe2d8e6-aeb3-460c-85f8-738ef71741ab@gmail.com>

Hi Sionigdha

First off congrats to your first PR(s) merged, and taking on the 
challenge of a GSoC !

As Andreas said the missing ogrinfo parameter are already exposed as an 
advanced parameter. And you could theoretically achieve what you want 
with the "string concatenation" tool in modeler albeit with more 
difficulty than what you propose.
Also remember we can't outright remove an existing parameter. because it 
would break the API, but it can be set as deprecated and kept around, 
see [1 
<https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30#diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191>]
But overall I think it's a good idea to have them as separate parameters.

 > Make ogrinfojson output structured and chainable within the processing
 > framework ?field count, feature count, geometry type, extent as named
 > outputs

* I think that's also a good idea to have more outputs like that in 
general. One thing that could be improved is that in the modeler, there 
is no specific output for extent, or CRS, we rely on a string output (
`QgsProcessingOutputString`) with a specific format to connect further 
in the parameters. I would like to see a One to One mapping between 
parameter and output type.

* Another way you could improve the output of the ogrinfo json is to 
take a step back and improve json handling in general in the processing. 
with a dedicated output and algorithms : ?to flatten json, extract 
values etc...

It's up to you which direction you want to go. At the moment I think 
it's a bit light to be a GSoC proposal on it's own (And since you 
already?contributed to GDAL/QGIS you might complete it too quickly :-)? 
).? But it is good to have your own idea and I encourage you to build 
upon it, and to get more feedbacks on it.

If you want to lean more on the GDAL side, it is absolutely fine. But 
GDAL is not my area of expertise, I need to dive into the code a bit 
more myself before giving you confirmation that I can mentor you on this 
project. (Or maybe another person in the community could step in as a 
mentor ? )

Kind regards,
Valentin Buira

[1] 
https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30#diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191 
<https://github.com/qgis/QGIS/commit/5bde6fec42ccc10b9fd1c4fc822fbe1a4ae05a30#diff-2f887124009e37c4f965e787aee9ac3c82f892ff2472580e037ab546d8369102R191>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260309/c4637892/attachment.htm>

From david at opengis.ch  Tue Mar 10 03:13:05 2026
From: david at opengis.ch (David Signer)
Date: Tue, 10 Mar 2026 11:13:05 +0100
Subject: [QGIS-Developer] Announcing QEP 410: Layer Name in
 GetFeatureInfo JSON Result
In-Reply-To: <CAETFtHkTczLditXY_DEB4Hc=XNHJ4SYfy7X=UtbEW8QpKg=9Bg@mail.gmail.com>
References: <CAETFtHkTczLditXY_DEB4Hc=XNHJ4SYfy7X=UtbEW8QpKg=9Bg@mail.gmail.com>
Message-ID: <CAETFtHny_kNiVdd3N4YsN_Bt_WYiQoqyktQgexG6bCawMuKnEA@mail.gmail.com>

Hi there

This QEP has passed the discussion threshold. Please cast your vote.

https://github.com/qgis/QGIS-Enhancement-Proposals/pull/365

I look forward to integrating this feature.

Thank you and have a nice day
Dave


On Thu, Feb 19, 2026 at 3:36?PM David Signer <david at opengis.ch> wrote:

> Hi everyone
>
> We would like to improve the WMS GetFeatureInfo JSON response with
> reliable layer name information. Please see my QEP here - your feedback is
> appreciated.
>
> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/365
>
> Have a nice day and cheers
> Dave
>
> ---
> David Signer
> Senior Developer & INTERLIS Architect
> Team QGIS & Industry Solutions
>
> david at opengis.ch
> opengis.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260310/1d1ce1f5/attachment.htm>

From benoit.de.mezzo at oslandia.com  Tue Mar 10 03:46:04 2026
From: benoit.de.mezzo at oslandia.com (Benoit D.-M.)
Date: Tue, 10 Mar 2026 11:46:04 +0100
Subject: [QGIS-Developer] Announcing QEP 412: 3d edition support
Message-ID: <03863005-4efc-4bb4-8359-2d94b23b261f@oslandia.com>

Hi,

We would like to improve the 3D edition support in the 3D view.

Please see our QEP here: 
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/367

Your feedback is appreciated.

Have a nice day,

Benoit.



From snigdha.lee75 at gmail.com  Tue Mar 10 10:02:47 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Tue, 10 Mar 2026 22:32:47 +0530
Subject: [QGIS-Developer] 
	=?utf-8?q?GSoC_2026_=E2=80=94_Enhancing_ogrinfo?=
	=?utf-8?q?_Processing_Algorithms_in_QGIS?=
In-Reply-To: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>
References: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>
Message-ID: <CAGCrGoOuT9WJ06qer5truEir+=SvCeAVqKVPPY=82=CjAuLyoQ@mail.gmail.com>

Hi Valentin,

Thank you ,and thank you to Andrea as well. You're both right that EXTRA is
available as an advanced parameter in models. I overstated the problem and
will correct that framing.

Your point about scope is also fair. I've been thinking about the direction
you mentioned in improving JSON handling in the processing framework more
generally  and I think that's the right way to expand this. The rough shape
I'm exploring:

   - Extend ogrinfo/ogrinfojson: expose the missing typed parameters
   (-where, -fid, -sql, -spat, -geom, -fields, -limit) as proper inputs
   alongside EXTRA rather than replacing it
   - Add JSON handling algorithms to the processing framework along the
   lines of: LoadJSONFile (bring JSON data into a model), ExtractJSONValue
   (pull a specific value by key path for use in downstream steps),
   JSONToLayer (convert a JSON array to a vector layer with attributes)
   - ogrinfo jason's structured outputs  feature count, geometry type,
   extent  would serve as the first concrete demonstration: pipe the JSON
   output into ExtractJSONValue, feed the result into a conditional branch in
   the model

Since this direction is entirely Python and the processing framework, no
GDAL internals.I wanted to check whether you'd be comfortable mentoring it,
or whether you'd suggest someone else in the community to approach.

Happy to share a rough outline before writing a full draft.

Best, Sionigdha

On Mon, 9 Mar 2026 at 16:09, Sionigdha Sadhukhan <snigdha.lee75 at gmail.com>
wrote:

> Hi Valentin,
>
> My name is Sionigdha and I'm interested in contributing to QGIS through
> GSoC 2026.
>
> While exploring the QGIS codebase I looked at OgrInfo.py in the GDAL
> processing algorithms and noticed that several GDAL ogrinfo capabilities
> are not exposed as typed parameters  specifically -fid, -where, -spat,
> -geom, -fields, and -limit. Users currently have to use the raw EXTRA
> string field to access these, which is undiscoverable and unusable in
> processing models.
>
> This caught my attention because I've been contributing to GDAL for the
> past 3 months with multiple merged PRs including #13904 (adding --fid to
> gdalinfo/GDALVectorInfo, merged in GDAL 3.13.0), #13812 (WMS/WMTS
> network-dependent test improvements), and several documentation fixes. Full
> list: https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged
>
> I've also been contributing directly to QGIS including PR #64620 (merged
> into QGIS 4.0.0) clarifying QgsLogger behavior, and several other
> documentation PRs targeting 4.0.0. Full list:
> https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged
>
> I'm currently working on building QGIS from source as per Exercise 0  my
> machine has hardware constraints but I'm working through them.
> I've been working on a prototype patch that adds -where, -fid, and -spat
> as proper typed parameters to both ogrinfo and ogrinfojson, happy to share
> it shortly.
>
> My proposed project for GSoC would be:
> 1. Expose all missing ogrinfo parameters as typed, modelable inputs in
> both ogrinfo and ogrinfojson
> 2. Make ogrinfojson output structured and chainable within the processing
> framework  field count, feature count, geometry type, extent as named
> outputs
> 3. Add a new ogrfeatureinfo processing algorithm that takes a layer + FID
> or WHERE clause and returns structured per-feature output  field values,
> geometry type, WKT  usable as inputs in processing models
> 4. Full test coverage for all additions targeting QGIS 4.x
>
> I'm comfortable in Python and PyQGIS, and I understand this targets QGIS
> 4.x with GDAL 3.13.0 as the baseline ? which aligns directly with my GDAL
> work.
>
> Would you be open to discussing this as a GSoC 2026 proposal?
>
> Best,
> Sionigdha Sadhukhan
> GitHub: https://github.com/Sionigdha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260310/5f326fbc/attachment.htm>

From rdmailings at duif.net  Wed Mar 11 08:54:41 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 11 Mar 2026 16:54:41 +0100
Subject: [QGIS-Developer] Maintaining Flatpak version(s) QGIS: help needed
Message-ID: <8497cff0-fb5f-46b3-a79d-22f8b7d46aff@duif.net>


Currently 'aleixpol' maintains a QGIS Flatpak build on flathub.
https://github.com/flathub/org.qgis.qgis
and
https://flathub.org/en/apps/org.qgis.qgis

Earlier you could install 2 branches, a LTR (our LTS) and a stable branch (our latest).
But the use of 2 different branches for 1 application is not possible anymore.

But Aleix does not have time to maintain 2x a QGIS applications, see:
https://github.com/flathub/org.qgis.qgis/pull/933#issuecomment-4040057036

So the solution would be to create 2 'applications'.
Current one is named "org.qgis.qgis".
If we keep that the LTR/S one.
Anybody here flatpak/hub active enough to create/maintain/package a "org.qgis.qgis.latest" or so?

Or has better idea's?

Regards,

Richard Duivenvoorde



From clhermansen at gmail.com  Thu Mar 12 10:50:05 2026
From: clhermansen at gmail.com (chris hermansen)
Date: Thu, 12 Mar 2026 10:50:05 -0700
Subject: [QGIS-Developer] Ubuntu 25.10 apt upgrade to QGIS 4.0 fail
Message-ID: <CACc2_6901pVLmk3wBoB7mm7cC-x_gBOt-k3qHYghTd2Orkx_UQ@mail.gmail.com>

Hello and apologies for cross-posting;

This morning (Pacific daylight time) my automated Ubuntu 25.10 apt upgrade
to QGIS 4.0 failed with the following two issues:

Title
   package python3-qgis 1:3.44.7+43questing [origin: QGIS project] failed
to install/upgrade:
ErrorMessage
   trying to overwrite '/usr/share/qgis/python/qsci_apis/PyQGIS.api' which
is also in package python3-qgis-common (1:3.44.7+43questing)

and

Title
   package qgis-providers 1:3.44.7+43questing [origin: QGIS project] failed
to install/upgrade:
ErrorMessage
   trying to overwrite '/usr/lib/qgis/plugins/libauthmethod_oauth2.so'
which is also in package qgis (1:3.44.7+43questing)

I did not look deeply into the cause for this (as a wild guess, something
about the apt configuration), but I did determine:

   1. a way to avoid it;
   2. a way to work around it once not avoided.

In terms of avoiding it:

   1. once computer is booted and running and BEFORE running daily / weekly
   software updates / upgrades
   2. uninstall qgis 3.44
   3. use apt autoclean && apt autoremove -f to remove all 3.44 dependencies
   4. run daily / weekly software updates / upgrades
   5. install qgis 4.0

If, like me, you ran your daily / weekly updates / upgrades and the upgrade
broke, here is what worked for me:

   1. uninstall qgis 3.44 and qgis 4.0
   2. use apt autoclean && autoremove -f to remove all 3.44 dependencies
   3. re-run daily / weekly software updates / upgrades
   4. install qgis 4.0


-- 
Chris Hermansen ? clhermansen "at" gmail "dot" com

C'est ma fa?on de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260312/0fce943d/attachment.htm>

From lnicola at dend.ro  Thu Mar 12 10:51:43 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Thu, 12 Mar 2026 19:51:43 +0200
Subject: [QGIS-Developer] Ubuntu 25.10 apt upgrade to QGIS 4.0 fail
In-Reply-To: <CACc2_6901pVLmk3wBoB7mm7cC-x_gBOt-k3qHYghTd2Orkx_UQ@mail.gmail.com>
References: <CACc2_6901pVLmk3wBoB7mm7cC-x_gBOt-k3qHYghTd2Orkx_UQ@mail.gmail.com>
Message-ID: <1a7a41fc-6dbd-42c9-8b20-2d64d5244e59@app.fastmail.com>

Haven't tried it, but apt dist-upgrade works in some of these cases.

On Thu, Mar 12, 2026, at 19:50, chris hermansen via QGIS-Developer wrote:
> Hello and apologies for cross-posting;
> 
> This morning (Pacific daylight time) my automated Ubuntu 25.10 apt upgrade to QGIS 4.0 failed with the following two issues:
> 
> Title
>    package python3-qgis 1:3.44.7+43questing [origin: QGIS project] failed to install/upgrade:
> ErrorMessage
>    trying to overwrite '/usr/share/qgis/python/qsci_apis/PyQGIS.api' which is also in package python3-qgis-common (1:3.44.7+43questing)
> 
> and
> 
> Title
>    package qgis-providers 1:3.44.7+43questing [origin: QGIS project] failed to install/upgrade:
> ErrorMessage
>    trying to overwrite '/usr/lib/qgis/plugins/libauthmethod_oauth2.so' which is also in package qgis (1:3.44.7+43questing)
> 
> I did not look deeply into the cause for this (as a wild guess, something about the apt configuration), but I did determine:
>  1. a way to avoid it;
>  2. a way to work around it once not avoided.
> In terms of avoiding it:
>  1. once computer is booted and running and BEFORE running daily / weekly software updates / upgrades
>  2. uninstall qgis 3.44
>  3. use apt autoclean && apt autoremove -f to remove all 3.44 dependencies
>  4. run daily / weekly software updates / upgrades
>  5. install qgis 4.0
> If, like me, you ran your daily / weekly updates / upgrades and the upgrade broke, here is what worked for me:
>  1. uninstall qgis 3.44 and qgis 4.0
>  2. use apt autoclean && autoremove -f to remove all 3.44 dependencies
>  3. re-run daily / weekly software updates / upgrades
>  4. install qgis 4.0
> 
> --
> Chris Hermansen ? clhermansen "at" gmail "dot" com
> 
> C'est ma fa?on de parler.
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260312/e95cd797/attachment-0001.htm>

From sebastic at xs4all.nl  Thu Mar 12 11:04:06 2026
From: sebastic at xs4all.nl (Sebastiaan Couwenberg)
Date: Thu, 12 Mar 2026 19:04:06 +0100
Subject: [QGIS-Developer] Ubuntu 25.10 apt upgrade to QGIS 4.0 fail
In-Reply-To: <1a7a41fc-6dbd-42c9-8b20-2d64d5244e59@app.fastmail.com>
References: <CACc2_6901pVLmk3wBoB7mm7cC-x_gBOt-k3qHYghTd2Orkx_UQ@mail.gmail.com>
 <1a7a41fc-6dbd-42c9-8b20-2d64d5244e59@app.fastmail.com>
Message-ID: <66526b05-03b6-46dd-9a4e-9766269e066b@xs4all.nl>

On 3/12/26 6:51 PM, Lauren?iu Nicola via QGIS-Developer wrote:
> Haven't tried it, but apt dist-upgrade works in some of these cases.

It only works if you first remove the conflicting package.

The fix is proper Breaks/Replaces:

  https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

Kind Regards,

Bas

-- 
  PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

From snigdha.lee75 at gmail.com  Thu Mar 12 23:16:50 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Fri, 13 Mar 2026 11:46:50 +0530
Subject: [QGIS-Developer] 
	=?utf-8?q?GSoC_2026_=E2=80=94_Enhancing_ogrinfo?=
	=?utf-8?q?_Processing_Algorithms_in_QGIS?=
In-Reply-To: <CAGCrGoOuT9WJ06qer5truEir+=SvCeAVqKVPPY=82=CjAuLyoQ@mail.gmail.com>
References: <CAGCrGoOtCftTMipL7VYAg5oghgBk4Dny7JtUeYywFbZkfaLRLw@mail.gmail.com>
 <CAGCrGoOuT9WJ06qer5truEir+=SvCeAVqKVPPY=82=CjAuLyoQ@mail.gmail.com>
Message-ID: <CAGCrGoMt443YwDh0v5Gfi4mS1FMwtXvn6D-jBUvYU8jm7twMsg@mail.gmail.com>

Hi all,
Following up on my previous email , I?ve put together a rough draft
proposal following the JSON handling direction Valentin suggested. Happy to
share it here or however is most convenient if early feedback would be
useful before I submit on the portal.
Best,
Sionigdha


On Tue, 10 Mar 2026 at 10:32?PM, Sionigdha Sadhukhan <
snigdha.lee75 at gmail.com> wrote:

> Hi Valentin,
>
> Thank you ,and thank you to Andrea as well. You're both right that EXTRA
> is available as an advanced parameter in models. I overstated the problem
> and will correct that framing.
>
> Your point about scope is also fair. I've been thinking about the
> direction you mentioned in improving JSON handling in the processing
> framework more generally  and I think that's the right way to expand this.
> The rough shape I'm exploring:
>
>    - Extend ogrinfo/ogrinfojson: expose the missing typed parameters
>    (-where, -fid, -sql, -spat, -geom, -fields, -limit) as proper inputs
>    alongside EXTRA rather than replacing it
>    - Add JSON handling algorithms to the processing framework along the
>    lines of: LoadJSONFile (bring JSON data into a model), ExtractJSONValue
>    (pull a specific value by key path for use in downstream steps),
>    JSONToLayer (convert a JSON array to a vector layer with attributes)
>    - ogrinfo jason's structured outputs  feature count, geometry type,
>    extent  would serve as the first concrete demonstration: pipe the JSON
>    output into ExtractJSONValue, feed the result into a conditional branch in
>    the model
>
> Since this direction is entirely Python and the processing framework, no
> GDAL internals.I wanted to check whether you'd be comfortable mentoring it,
> or whether you'd suggest someone else in the community to approach.
>
> Happy to share a rough outline before writing a full draft.
>
> Best, Sionigdha
>
> On Mon, 9 Mar 2026 at 16:09, Sionigdha Sadhukhan <snigdha.lee75 at gmail.com>
> wrote:
>
>> Hi Valentin,
>>
>> My name is Sionigdha and I'm interested in contributing to QGIS through
>> GSoC 2026.
>>
>> While exploring the QGIS codebase I looked at OgrInfo.py in the GDAL
>> processing algorithms and noticed that several GDAL ogrinfo capabilities
>> are not exposed as typed parameters  specifically -fid, -where, -spat,
>> -geom, -fields, and -limit. Users currently have to use the raw EXTRA
>> string field to access these, which is undiscoverable and unusable in
>> processing models.
>>
>> This caught my attention because I've been contributing to GDAL for the
>> past 3 months with multiple merged PRs including #13904 (adding --fid to
>> gdalinfo/GDALVectorInfo, merged in GDAL 3.13.0), #13812 (WMS/WMTS
>> network-dependent test improvements), and several documentation fixes. Full
>> list:
>> https://github.com/OSGeo/gdal/pulls?q=author%3ASionigdha+is%3Amerged
>>
>> I've also been contributing directly to QGIS including PR #64620 (merged
>> into QGIS 4.0.0) clarifying QgsLogger behavior, and several other
>> documentation PRs targeting 4.0.0. Full list:
>> https://github.com/qgis/QGIS/pulls?q=author%3ASionigdha+is%3Amerged
>>
>> I'm currently working on building QGIS from source as per Exercise 0  my
>> machine has hardware constraints but I'm working through them.
>> I've been working on a prototype patch that adds -where, -fid, and -spat
>> as proper typed parameters to both ogrinfo and ogrinfojson, happy to share
>> it shortly.
>>
>> My proposed project for GSoC would be:
>> 1. Expose all missing ogrinfo parameters as typed, modelable inputs in
>> both ogrinfo and ogrinfojson
>> 2. Make ogrinfojson output structured and chainable within the processing
>> framework  field count, feature count, geometry type, extent as named
>> outputs
>> 3. Add a new ogrfeatureinfo processing algorithm that takes a layer + FID
>> or WHERE clause and returns structured per-feature output  field values,
>> geometry type, WKT  usable as inputs in processing models
>> 4. Full test coverage for all additions targeting QGIS 4.x
>>
>> I'm comfortable in Python and PyQGIS, and I understand this targets QGIS
>> 4.x with GDAL 3.13.0 as the baseline ? which aligns directly with my GDAL
>> work.
>>
>> Would you be open to discussing this as a GSoC 2026 proposal?
>>
>> Best,
>> Sionigdha Sadhukhan
>> GitHub: https://github.com/Sionigdha
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260313/fc2712ab/attachment.htm>

From zulfadhil.hakim at shortcut.io  Sun Mar 15 18:26:59 2026
From: zulfadhil.hakim at shortcut.io (Zulfadhlil Hakim)
Date: Mon, 16 Mar 2026 08:26:59 +0700
Subject: [QGIS-Developer] [URGENT] QGIS Integration
Message-ID: <CANosNBvViCUrq-SAZvEuprx7_mgM7=k_5PPE2n=AY=FtzcXzYg@mail.gmail.com>

Hello QGIS Devs,

I urgently request support implementing integration points with the QGIS
system for one of our client. Since we're on a tight timeline, prompt
support will be very much appreciated. Our backend tech stack runs on
NestJS. Our use case will be as follows:

1. Push or pull coordinates from QGIS.
2. Push or pull maps from QGIS.

It would be ideal if we could have a working session. For now pointing us
to the correct documentation will suffice.

Regards,
Zul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260316/deb3d4ec/attachment.htm>

From gdt at lexort.com  Mon Mar 16 06:15:15 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 16 Mar 2026 09:15:15 -0400
Subject: [QGIS-Developer] [URGENT] QGIS Integration
In-Reply-To: <CANosNBvViCUrq-SAZvEuprx7_mgM7=k_5PPE2n=AY=FtzcXzYg@mail.gmail.com>
 (Zulfadhlil Hakim via's message of "Mon, 16 Mar 2026 08:26:59 +0700")
References: <CANosNBvViCUrq-SAZvEuprx7_mgM7=k_5PPE2n=AY=FtzcXzYg@mail.gmail.com>
Message-ID: <rmildfrkja4.fsf@s1.lexort.com>

You seem to be confusing the discussion list for developers with an
address that you would write to within the context of some pre-existing
paid-for support contract that you have with some entity.

It sounds like you need a consultant.


From anitagraser at gmx.at  Mon Mar 16 10:12:52 2026
From: anitagraser at gmx.at (Anita Graser)
Date: Mon, 16 Mar 2026 18:12:52 +0100
Subject: [QGIS-Developer] Call for Grant Proposals 2026
Message-ID: <93979807-2820-41c0-a57d-92803dc8f3e8@gmx.at>

Dear QGIS Community,

Our previous rounds of grant proposals have been a great success. We are 
very pleased to announce that this year?s round of grants is now 
available. The call is open to anybody who wants to make a funded 
contribution to QGIS, subject to the call conditions outlined in the 
application form. The deadline for this round is on Monday 13 April.

For more details, please read:
https://blog.qgis.org/2026/03/16/qgis-grants-11-call-for-grant-proposals-2026/

We look forward to seeing all your great ideas for improving QGIS!

Regards,

Anita



From snigdha.lee75 at gmail.com  Mon Mar 16 12:36:15 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Tue, 17 Mar 2026 01:06:15 +0530
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling Toolkit
 for the QGIS Processing Framework
Message-ID: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>

Hello,

I?ve prepared a draft of my GSoC proposal for improving JSON handling in
the QGIS Processing framework and wanted to share it here and
recieve your valuable feedback.

I?ve attached the current version.I tried to incorporate the earlier
suggestion about looking at JSON handling more broadly in the processing
framework rather than focusing only on the ogrinfo parameters. If there?s
anything that seems unclear, unrealistic, or that should be approached
differently, I would really appreciate any feedback.

Thanks for your time.

Kind regards,
Sionigdha.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/e8f540e9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSOC_PROPOSAL_2026.pdf
Type: application/pdf
Size: 640902 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/e8f540e9/attachment-0001.pdf>

From nyall.dawson at gmail.com  Mon Mar 16 22:59:54 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 17 Mar 2026 15:59:54 +1000
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling
 Toolkit for the QGIS Processing Framework
In-Reply-To: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
References: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
Message-ID: <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>

On Tue, 17 Mar 2026 at 15:52, Sionigdha Sadhukhan via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hello,
>
> I?ve prepared a draft of my GSoC proposal for improving JSON handling in
> the QGIS Processing framework and wanted to share it here and
> recieve your valuable feedback.
>
> I?ve attached the current version.I tried to incorporate the earlier
> suggestion about looking at JSON handling more broadly in the processing
> framework rather than focusing only on the ogrinfo parameters. If there?s
> anything that seems unclear, unrealistic, or that should be approached
> differently, I would really appreciate any feedback.
>

Thanks for sending this through Sionigdha!

Just FYI you'll need to submit a QEP before doing any of this work -- see
https://github.com/qgis/QGIS-Enhancement-Proposals. One sticking point that
stood out to me is that you're proposing to implement the new algorithms in
Python. That's explicitly blocked now, we want all new algorithms to be
written in c++ (unless they rely on a specific python library).

Kind regards,
Nyall


Thanks for your time.
>
> Kind regards,
> Sionigdha.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/8a7d7eaf/attachment.htm>

From valentin.buira at gmail.com  Tue Mar 17 04:44:00 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Tue, 17 Mar 2026 12:44:00 +0100
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling
 Toolkit for the QGIS Processing Framework
In-Reply-To: <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>
References: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
 <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>
Message-ID: <CANrSSZkBNN4_Az7vDpUDutAvaDpkYen-WqZKM_v+mxjA5vvAtw@mail.gmail.com>

Hi Sionigdha,

I concur with Nyall on the technical part, new algorithms require a c++
implementation, thought you don't have to write a json parser from scratch,
take a look at how json is handled in Qt [1]

On  another note, I know you were initially interested in GDAL, but you run
the risk to have a "two headed proposal" . Maybe changing the input
parameters of GDAL algorithms is not the core of your proposal ? And more
JSON integration / algorithms would be more suitable for the proposal ?

>  Just FYI you'll need to submit a QEP before doing any of this work --
see https://github.com/qgis/QGIS-Enhancement-Proposals.

An accepted QEP would certainly weigh in your favor for your proposal. But
the deadline for submission of the GSoC is on 31 March, which makes it
really tight for the QEP process to go through.

When I advertised GSoC[2] I did not mention the QEP process, and I would
prefer not changing the requirements midway.



Lastly a note for potential mentors and the QGIS maintainers :

The articulation between GSoC and QEP needs to be clarify:

* Historically on the last two GSoC proposals we had  (2024 and 2019),
there were no QEP
* OSGeo requires it's own template for a proposal that is different from
our QEP
* I'd like to keep GSoC as a space of freedom of experimentation, sandbox
for idea etc... which could clash with the consensus nature of the QEP
* But... At the same time a GSoC without a QEP runs the risk of not getting
merged in the end.
* When I wrote the GSoC ideas this year I took care of not diving into
technical details nor writing a QEP because I believe it's the student's
job to write it and gain insight of the source code from it.
* Do we want students to invest time in a QEP while they are not sure of
being accepted ? Or just improve their initial proposal instead ? Should we
reserve the QEP for the community bounding periods ?

 Maybe we could change the GSoC process for next year ? Any thoughts on
this @Nyall ?

Kind regards,
Valentin

[1] https://doc.qt.io/qt-6/json.html
[2] https://github.com/qgis/QGIS/wiki/Google-Summer-of-Code-2026-Ideas

Le mar. 17 mars 2026, 07:00, Nyall Dawson <nyall.dawson at gmail.com> a ?crit :

>
>
> On Tue, 17 Mar 2026 at 15:52, Sionigdha Sadhukhan via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>> Hello,
>>
>> I?ve prepared a draft of my GSoC proposal for improving JSON handling in
>> the QGIS Processing framework and wanted to share it here and
>> recieve your valuable feedback.
>>
>> I?ve attached the current version.I tried to incorporate the earlier
>> suggestion about looking at JSON handling more broadly in the processing
>> framework rather than focusing only on the ogrinfo parameters. If
>> there?s anything that seems unclear, unrealistic, or that should be
>> approached differently, I would really appreciate any feedback.
>>
>
> Thanks for sending this through Sionigdha!
>
> Just FYI you'll need to submit a QEP before doing any of this work -- see
> https://github.com/qgis/QGIS-Enhancement-Proposals. One sticking point
> that stood out to me is that you're proposing to implement the new
> algorithms in Python. That's explicitly blocked now, we want all new
> algorithms to be written in c++ (unless they rely on a specific python
> library).
>
> Kind regards,
> Nyall
>
>
> Thanks for your time.
>>
>> Kind regards,
>> Sionigdha.
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/fd3ed658/attachment.htm>

From Mike.Elstermann at itc-halle.de  Tue Mar 17 07:24:43 2026
From: Mike.Elstermann at itc-halle.de (Elstermann, Mike)
Date: Tue, 17 Mar 2026 14:24:43 +0000
Subject: [QGIS-Developer] Editing CSV files?
Message-ID: <2BA96B92-41FF-4847-8950-52AE0CA67911@itc-halle.de>

Hello everyone,

when I load a CSV file (without geometry) via the ?Data Source Manager? in QGIS 3 and QGIS 4, I cannot edit it in the attribute table. However, if I drag the CSV file into the project, the attribute table can be edited just as easily as with other datasets.

Is this normal? If so, why? Or can this perhaps be adjusted so that the CSV file is always editable?

Thanks, mikeE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/370c376c/attachment-0001.htm>

From alexander.bruy at gmail.com  Tue Mar 17 07:45:11 2026
From: alexander.bruy at gmail.com (Alexander Bruy)
Date: Tue, 17 Mar 2026 14:45:11 +0000
Subject: [QGIS-Developer] Editing CSV files?
In-Reply-To: <2BA96B92-41FF-4847-8950-52AE0CA67911@itc-halle.de>
References: <2BA96B92-41FF-4847-8950-52AE0CA67911@itc-halle.de>
Message-ID: <CALuHMPAzAmpp40ZCs+xzJTkCHPHE3e9xaRbiAmWOHVD1Q0ovHg@mail.gmail.com>

Hi Mike,

I think you are loading CSV via Data Source Manager using the
delimited text data provider, while when you drag-and-drop it the OGR
provider is used. These providers have different capabilities,
so this is a normal situation.

??, 17 ???. 2026??. ? 14:39 Elstermann, Mike via QGIS-Developer
<qgis-developer at lists.osgeo.org> ????:
>
> Hello everyone,
>
> when I load a CSV file (without geometry) via the ?Data Source Manager? in QGIS 3 and QGIS 4, I cannot edit it in the attribute table. However, if I drag the CSV file into the project, the attribute table can be edited just as easily as with other datasets.
>
> Is this normal? If so, why? Or can this perhaps be adjusted so that the CSV file is always editable?
>
> Thanks, mikeE.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alexander Bruy

From nick at nickbearman.com  Tue Mar 17 08:19:40 2026
From: nick at nickbearman.com (Nick Bearman)
Date: Tue, 17 Mar 2026 15:19:40 +0000
Subject: [QGIS-Developer] Editing CSV files?
In-Reply-To: <CALuHMPAzAmpp40ZCs+xzJTkCHPHE3e9xaRbiAmWOHVD1Q0ovHg@mail.gmail.com>
References: <2BA96B92-41FF-4847-8950-52AE0CA67911@itc-halle.de>
 <CALuHMPAzAmpp40ZCs+xzJTkCHPHE3e9xaRbiAmWOHVD1Q0ovHg@mail.gmail.com>
Message-ID: <4272dcb8-4c34-44f3-b804-4f725f90653f@nickbearman.com>

Thanks for your question Mike.

I hope Alexander's answer helped.

To develop this slightly further, to get consistent options, best 
practice would be to save your CSV file to some other format within QGIS 
- perhaps as a table without geometry in a geopackage - and then you 
will be able to edit it to your heart's content.

Whether this is suitable depends on your wider workflow - and why you 
are bringing in a CSV file, which you don't specify.

Good luck!

Best wishes,
Nick.

On 17/03/2026 14:45, Alexander Bruy via QGIS-Developer wrote:
> Hi Mike,
>
> I think you are loading CSV via Data Source Manager using the
> delimited text data provider, while when you drag-and-drop it the OGR
> provider is used. These providers have different capabilities,
> so this is a normal situation.
>
> ??, 17 ???. 2026??. ? 14:39 Elstermann, Mike via QGIS-Developer
> <qgis-developer at lists.osgeo.org> ????:
>> Hello everyone,
>>
>> when I load a CSV file (without geometry) via the ?Data Source Manager? in QGIS 3 and QGIS 4, I cannot edit it in the attribute table. However, if I drag the CSV file into the project, the attribute table can be edited just as easily as with other datasets.
>>
>> Is this normal? If so, why? Or can this perhaps be adjusted so that the CSV file is always editable?
>>
>> Thanks, mikeE.
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-- 
Nick Bearman
+44 (0) 7717745715
nick at nickbearman.com

Please let me know if I can make any adjustments related to disability or neurodivergence to improve how we interact.

Due to my own life/work balance, you may get emails from me outside of normal working hours. Please do not feel any pressure to respond outside of your own working pattern.



From strk at kbt.io  Tue Mar 17 11:19:52 2026
From: strk at kbt.io (Sandro Santilli)
Date: Tue, 17 Mar 2026 19:19:52 +0100
Subject: [QGIS-Developer] Announcing QEP 413: PostGIS Topology support in
 Browser
Message-ID: <abmbSBZucML65t_c@liz.localdomain>

As an contribution to the long migration of features from DBManager to
core I'm proposing porting the TopoViewer support to the Browser.

Find QEP here:
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/360

Comments welcome, thanks !

--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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260317/c61254cf/attachment.sig>

From snigdha.lee75 at gmail.com  Tue Mar 17 21:23:09 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Wed, 18 Mar 2026 09:53:09 +0530
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling
 Toolkit for the QGIS Processing Framework
In-Reply-To: <CANrSSZkBNN4_Az7vDpUDutAvaDpkYen-WqZKM_v+mxjA5vvAtw@mail.gmail.com>
References: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
 <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>
 <CANrSSZkBNN4_Az7vDpUDutAvaDpkYen-WqZKM_v+mxjA5vvAtw@mail.gmail.com>
Message-ID: <CAGCrGoMgeG+Khp0Yi8N0azZMPpZOhi5A0jOuwOXX7ToBXASkCw@mail.gmail.com>

Subject: Re: GSoC 2026 Draft Proposal : JSON Handling Toolkit for the QGIS
Processing Framework

Hi Valentin,
Thank you for the detailed feedback it's very helpful, and thanks for
guiding through.
The point about the two-headed proposal makes complete sense. I've already
started reworking the proposal to make the JSON toolkit the clear centre of
gravity. The ogrinfo typed parameter work is out I'm replacing those weeks
with 2 additional JSON algorithms (JSONFromAttributes and MergeJSONArrays),
bringing the total to 6 C++ algorithms that together cover the full JSON
data lifecycle inside a QGIS model.On the QEP I understand the timing issue
you raised and appreciate you flagging it. I'll draft the QEP during the
community bonding period and submit it for community review before coding
begins, so it doesn't block the proposal submission if that is fine?
I also went through the Qt JSON documentation you linked. The
implementation plan is built entirely around Qt's built-in JSON classes
QJsonDocument, QJsonObject, QJsonArray, and QJsonValue no third-party
libraries needed.
I'll share the updated proposal with you .Please let me know if there's
anything else you'd like me to address.
Kind regards,
Sionigdha

On Tue, 17 Mar 2026 at 17:14, Valentin Buira <valentin.buira at gmail.com>
wrote:

> Hi Sionigdha,
>
> I concur with Nyall on the technical part, new algorithms require a c++
> implementation, thought you don't have to write a json parser from scratch,
> take a look at how json is handled in Qt [1]
>
> On  another note, I know you were initially interested in GDAL, but you
> run the risk to have a "two headed proposal" . Maybe changing the input
> parameters of GDAL algorithms is not the core of your proposal ? And more
> JSON integration / algorithms would be more suitable for the proposal ?
>
> >  Just FYI you'll need to submit a QEP before doing any of this work --
> see https://github.com/qgis/QGIS-Enhancement-Proposals.
>
> An accepted QEP would certainly weigh in your favor for your proposal. But
> the deadline for submission of the GSoC is on 31 March, which makes it
> really tight for the QEP process to go through.
>
> When I advertised GSoC[2] I did not mention the QEP process, and I would
> prefer not changing the requirements midway.
>
>
>
> Lastly a note for potential mentors and the QGIS maintainers :
>
> The articulation between GSoC and QEP needs to be clarify:
>
> * Historically on the last two GSoC proposals we had  (2024 and 2019),
> there were no QEP
> * OSGeo requires it's own template for a proposal that is different from
> our QEP
> * I'd like to keep GSoC as a space of freedom of experimentation, sandbox
> for idea etc... which could clash with the consensus nature of the QEP
> * But... At the same time a GSoC without a QEP runs the risk of not
> getting merged in the end.
> * When I wrote the GSoC ideas this year I took care of not diving into
> technical details nor writing a QEP because I believe it's the student's
> job to write it and gain insight of the source code from it.
> * Do we want students to invest time in a QEP while they are not sure of
> being accepted ? Or just improve their initial proposal instead ? Should we
> reserve the QEP for the community bounding periods ?
>
>  Maybe we could change the GSoC process for next year ? Any thoughts on
> this @Nyall ?
>
> Kind regards,
> Valentin
>
> [1] https://doc.qt.io/qt-6/json.html
> [2] https://github.com/qgis/QGIS/wiki/Google-Summer-of-Code-2026-Ideas
>
> Le mar. 17 mars 2026, 07:00, Nyall Dawson <nyall.dawson at gmail.com> a
> ?crit :
>
>>
>>
>> On Tue, 17 Mar 2026 at 15:52, Sionigdha Sadhukhan via QGIS-Developer <
>> qgis-developer at lists.osgeo.org> wrote:
>>
>>> Hello,
>>>
>>> I?ve prepared a draft of my GSoC proposal for improving JSON handling in
>>> the QGIS Processing framework and wanted to share it here and
>>> recieve your valuable feedback.
>>>
>>> I?ve attached the current version.I tried to incorporate the earlier
>>> suggestion about looking at JSON handling more broadly in the processing
>>> framework rather than focusing only on the ogrinfo parameters. If
>>> there?s anything that seems unclear, unrealistic, or that should be
>>> approached differently, I would really appreciate any feedback.
>>>
>>
>> Thanks for sending this through Sionigdha!
>>
>> Just FYI you'll need to submit a QEP before doing any of this work -- see
>> https://github.com/qgis/QGIS-Enhancement-Proposals. One sticking point
>> that stood out to me is that you're proposing to implement the new
>> algorithms in Python. That's explicitly blocked now, we want all new
>> algorithms to be written in c++ (unless they rely on a specific python
>> library).
>>
>> Kind regards,
>> Nyall
>>
>>
>> Thanks for your time.
>>>
>>> Kind regards,
>>> Sionigdha.
>>>
>>> _______________________________________________
>>> QGIS-Developer mailing list
>>> QGIS-Developer at lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/02f2f0bd/attachment-0001.htm>

From nyall.dawson at gmail.com  Tue Mar 17 21:34:25 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 18 Mar 2026 14:34:25 +1000
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling
 Toolkit for the QGIS Processing Framework
In-Reply-To: <CAGCrGoMgeG+Khp0Yi8N0azZMPpZOhi5A0jOuwOXX7ToBXASkCw@mail.gmail.com>
References: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
 <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>
 <CANrSSZkBNN4_Az7vDpUDutAvaDpkYen-WqZKM_v+mxjA5vvAtw@mail.gmail.com>
 <CAGCrGoMgeG+Khp0Yi8N0azZMPpZOhi5A0jOuwOXX7ToBXASkCw@mail.gmail.com>
Message-ID: <CAB28AshejaSTh09Eggor8Z+QKx=d6J9h-wxs9Yg3ChunazA=YQ@mail.gmail.com>

On Wed, 18 Mar 2026 at 14:23, Sionigdha Sadhukhan <snigdha.lee75 at gmail.com>
wrote:

> Subject: Re: GSoC 2026 Draft Proposal : JSON Handling Toolkit for the QGIS
> Processing Framework
>
> Hi Valentin,
> Thank you for the detailed feedback it's very helpful, and thanks for
> guiding through.
> The point about the two-headed proposal makes complete sense. I've already
> started reworking the proposal to make the JSON toolkit the clear centre of
> gravity. The ogrinfo typed parameter work is out I'm replacing those weeks
> with 2 additional JSON algorithms (JSONFromAttributes and MergeJSONArrays),
> bringing the total to 6 C++ algorithms that together cover the full JSON
> data lifecycle inside a QGIS model.On the QEP I understand the timing issue
> you raised and appreciate you flagging it. I'll draft the QEP during the
> community bonding period and submit it for community review before coding
> begins, so it doesn't block the proposal submission if that is fine?
> I also went through the Qt JSON documentation you linked. The
> implementation plan is built entirely around Qt's built-in JSON classes
> QJsonDocument, QJsonObject, QJsonArray, and QJsonValue no third-party
> libraries needed.
>

Can you flip that to use the utilities from QgsJsonUtils? Those use the
nlohmann library, which is faster then Qt's classes.

Nyall

>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/4483556d/attachment.htm>

From snigdha.lee75 at gmail.com  Tue Mar 17 23:39:10 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Wed, 18 Mar 2026 12:09:10 +0530
Subject: [QGIS-Developer] GSoC 2026 Draft Proposal : JSON Handling
 Toolkit for the QGIS Processing Framework
In-Reply-To: <CAB28AshejaSTh09Eggor8Z+QKx=d6J9h-wxs9Yg3ChunazA=YQ@mail.gmail.com>
References: <CAGCrGoML4vaTmirEo9EB7tApNmg0d3N68CAE_KgJ1g=1zxTn5A@mail.gmail.com>
 <CAB28AsjE+5tt89DQmFw=XNofL2F39QUu21YcaNGPr09=zDT5ig@mail.gmail.com>
 <CANrSSZkBNN4_Az7vDpUDutAvaDpkYen-WqZKM_v+mxjA5vvAtw@mail.gmail.com>
 <CAGCrGoMgeG+Khp0Yi8N0azZMPpZOhi5A0jOuwOXX7ToBXASkCw@mail.gmail.com>
 <CAB28AshejaSTh09Eggor8Z+QKx=d6J9h-wxs9Yg3ChunazA=YQ@mail.gmail.com>
Message-ID: <CAGCrGoNLsLtP9ecYksvqECThJ8dwE+SQLJCALcai8Z3u_FCwjQ@mail.gmail.com>

Hi Nyall,
Thank you for the pointer to QgsJsonUtils I wasn't aware it was already in
the codebase. I'll *switch the implementation plan to use nlohmann::json
via QgsJsonUtils *throughout, dropping the Qt JSON classes plan entirely.
I can see that* QgsJsonUtils::exportAttributesToJsonObject() *would make
the JSONFromAttributes algorithm significantly cleaner. I'll build that
algorithm around it directly.
*One follow-up question: for the read-side algorithms (LoadJSONFile,
ExtractJSONValue, FlattenJSON, JSONToTable), the plan is to accept a JSON
string as input and parse it internally using nlohmann::json::parse(). Is
that the right approach, or are there existing QgsJsonUtils helpers on the
read side I should be using instead?*
I'll update the proposal to reflect the switch to *QgsJsonUtils* and
*nlohmann*.
Kind regards,
Sionigdha

On Wed, 18 Mar 2026 at 10:04, Nyall Dawson <nyall.dawson at gmail.com> wrote:

>
>
> On Wed, 18 Mar 2026 at 14:23, Sionigdha Sadhukhan <snigdha.lee75 at gmail.com>
> wrote:
>
>> Subject: Re: GSoC 2026 Draft Proposal : JSON Handling Toolkit for the
>> QGIS Processing Framework
>>
>> Hi Valentin,
>> Thank you for the detailed feedback it's very helpful, and thanks for
>> guiding through.
>> The point about the two-headed proposal makes complete sense. I've
>> already started reworking the proposal to make the JSON toolkit the clear
>> centre of gravity. The ogrinfo typed parameter work is out I'm replacing
>> those weeks with 2 additional JSON algorithms (JSONFromAttributes and
>> MergeJSONArrays), bringing the total to 6 C++ algorithms that together
>> cover the full JSON data lifecycle inside a QGIS model.On the QEP I
>> understand the timing issue you raised and appreciate you flagging it. I'll
>> draft the QEP during the community bonding period and submit it for
>> community review before coding begins, so it doesn't block the proposal
>> submission if that is fine?
>> I also went through the Qt JSON documentation you linked. The
>> implementation plan is built entirely around Qt's built-in JSON classes
>> QJsonDocument, QJsonObject, QJsonArray, and QJsonValue no third-party
>> libraries needed.
>>
>
> Can you flip that to use the utilities from QgsJsonUtils? Those use the
> nlohmann library, which is faster then Qt's classes.
>
> Nyall
>
>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/d4b92787/attachment.htm>

From Mike.Elstermann at itc-halle.de  Wed Mar 18 03:02:32 2026
From: Mike.Elstermann at itc-halle.de (Elstermann, Mike)
Date: Wed, 18 Mar 2026 10:02:32 +0000
Subject: [QGIS-Developer] Editing CSV files?
Message-ID: <646afe57d03e48e788fb75327641e3c2@itc-halle.de>

Thank you for your responses.
Alexander's explanation clarified the observed effect. Now I understand the causes.

Nick's explanations are correct, but I already understood that part. That's how we handle it, too. By the way, the request came from one of my users. And why does he import a CSV? Well, because he likes to do everything in his favorite GIS without using other software, and his favorite GIS can actually be a good CSV editor under certain circumstances ;-)

THX, mikeE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/46faf640/attachment.htm>

From nick at nickbearman.com  Wed Mar 18 03:51:21 2026
From: nick at nickbearman.com (Nick Bearman)
Date: Wed, 18 Mar 2026 10:51:21 +0000
Subject: [QGIS-Developer] Editing CSV files?
In-Reply-To: <646afe57d03e48e788fb75327641e3c2@itc-halle.de>
References: <646afe57d03e48e788fb75327641e3c2@itc-halle.de>
Message-ID: <6c49b634-a5b0-40cc-ad2f-755a37cc14e4@nickbearman.com>

Thanks Mike, always interesting to close the loop!

:-)

On 18/03/2026 10:02, Elstermann, Mike via QGIS-Developer wrote:
>
> Thank you for your responses.
>
> Alexander?s explanation clarified the observed effect. Now I 
> understand the causes.
>
> Nick?s explanations are correct, but I already understood that part. 
> That?s how we handle it, too. By the way, the request came from one of 
> my users. And why does he import a CSV? Well, because he likes to do 
> everything in his favorite GIS without using other software, and his 
> favorite GIS can actually be a good CSV editor under certain 
> circumstances ;-)
>
> THX, mikeE.
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Nick Bearman
+44 (0) 7717745715
nick at nickbearman.com

Please let me know if I can make any adjustments related to disability or neurodivergence to improve how we interact.

Due to my own life/work balance, you may get emails from me outside of normal working hours. Please do not feel any pressure to respond outside of your own working pattern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/a75a980a/attachment-0001.htm>

From joona.p.laine at gmail.com  Wed Mar 18 05:12:25 2026
From: joona.p.laine at gmail.com (Joona Laine)
Date: Wed, 18 Mar 2026 14:12:25 +0200
Subject: [QGIS-Developer] QGIS 4.0.0 docker images
Message-ID: <CAKmgki6uvqS7XbazaWxBSP2d11obxeU-ZiJXHz7xxgU4rg=N6g@mail.gmail.com>

Hi all,

Is QGIS 4.0.0 docker images going to be published to
https://hub.docker.com/r/qgis/qgis at some point? I have been using QGIS
images in CI of all my QGIS related projects and it has been critical part
of QA to run tests with the newest versions. With 4.0.0 it would be even
more so, but unfortunately the image has not been released yet.

If I can hep somehow to get images published, please let me know, I would
be happy to help getting QGIS 4 images available.

Cheers,
Joona

PS: flake8-qgis==2.0.1 with QGIS4 compatibility rules has been just
released if someone wants to check that out... :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260318/3b52bf93/attachment.htm>

From custard at thornbill.net  Wed Mar 18 20:43:59 2026
From: custard at thornbill.net (ramon)
Date: Thu, 19 Mar 2026 03:43:59 +0000
Subject: [QGIS-Developer] Open Sans failed with VPN
Message-ID: <9B4B01B6-2558-4D7D-A068-5A9A0A96E7D6@thornbill.net>

Hi,

Just noting that with a fresh QGIS 4 on windows *and* my VPN on I was getting an error that looked a lot like https://github.com/qgis/qgis/issues/58988

Installed fine with the VPN off.

Totally sure this is GitHub objecting to the VPN and not a QGIS issue, but something to be aware of - and maybe note somewhere.

Regards,
Ramon.

From shivambharti02405 at gmail.com  Thu Mar 19 02:56:08 2026
From: shivambharti02405 at gmail.com (B#Sharp)
Date: Thu, 19 Mar 2026 15:26:08 +0530
Subject: [QGIS-Developer] Application for contribution in QGIS
Message-ID: <CALPoWh+KvpoYD3w1qNEmCc7wLfSWuSZN-ypLjYP=zdKV-Qnsew@mail.gmail.com>

Hello , I am Shivam Bharti, an ex - GIS Engineer. I am currently pursuing a
masters in Computer Applications. I have experience with Python, Java, and
SQL.
I saw that there are projects available for python in QGIS ; so I wanted to
introduce myself to this group.

I want to apply for the gsoc 2026 if I am accepted as a contributor in this
project. I have not applied to any other projects. Please guide me
regarding the steps to how I can contribute to the project.

I am looking forward to a reply. Thank you :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260319/b32b4ee6/attachment.htm>

From gdt at lexort.com  Thu Mar 19 05:37:16 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 19 Mar 2026 08:37:16 -0400
Subject: [QGIS-Developer] Open Sans failed with VPN
In-Reply-To: <9B4B01B6-2558-4D7D-A068-5A9A0A96E7D6@thornbill.net> (ramon via
 QGIS-Developer's message of "Thu, 19 Mar 2026 03:43:59 +0000")
References: <9B4B01B6-2558-4D7D-A068-5A9A0A96E7D6@thornbill.net>
Message-ID: <rmildfoq9kz.fsf@s1.lexort.com>

ramon via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> Just noting that with a fresh QGIS 4 on windows *and* my VPN on I was getting an error that looked a lot like https://github.com/qgis/qgis/issues/58988
>
> Installed fine with the VPN off.
>
> Totally sure this is GitHub objecting to the VPN and not a QGIS issue, but something to be aware of - and maybe note somewhere.

I'd say qgis downloading from github is a qgis issue :-)   In general
it's a bug to phone home at all.


From shivambharti02405 at gmail.com  Thu Mar 19 23:17:24 2026
From: shivambharti02405 at gmail.com (B#Sharp)
Date: Fri, 20 Mar 2026 11:47:24 +0530
Subject: [QGIS-Developer] Inquiry for application as a gsoc contributor
Message-ID: <CALPoWhLVDKHLR6iFW6OEUir8vFDqYM6_J16kvoLaicpQhxCGGQ@mail.gmail.com>

Hi , my name is Shivam Bharti. I am an ex GIS Engineer and I am currently
pursuing my master's in Computer Application.

I have experience with Python / Java and SQL. I don't have any custom ideas
but If you are still taking gsoc students and there are projects available
in those languages , then please let me know. I will be happy to contribute
with a long term stay.

Thanking you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260320/6cf8c15e/attachment.htm>

From tim at kartoza.com  Mon Mar 23 02:20:16 2026
From: tim at kartoza.com (Tim Sutton)
Date: Mon, 23 Mar 2026 09:20:16 +0000
Subject: [QGIS-Developer] Reducing the size of our download packages
Message-ID: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>

Hi all

Here in the infrastructure management club for QGIS we have been embarking
on a plan to slowly divest ourselves of 'big tech'. At the end of last year
we switched off cloudflare CDN and implemented our own caching servers. At
that time we were doing around 130TB of throughput (including what was
being soaked up by Cloudflare). As of last month we did 430TB of throughput
without the help of Cloudflare.

We are trying to optimise costs - that bandwidth alone cost us in the
neighbourhood of 500? per month. To reduce costs we can approach the
problem in two way:

1. optimise the infrastructure - we (QGIS Devops team) are busy looking
into ways to do that...
2. reduce the download size...

We are wondering if the datum shift files could be split out from the main
installer and fetched as an optional extra? Or maybe on demand as you need
them? We could set up some infrastructure for hosting them, but we would
need some help on the application side to implement logic to go and grab
shift files that are not locally cached. Is anyone able to help with this?

Regards

Tim




-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim at kartoza.com          *W* :
kartoza.com



*This email and any attachments are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you *
*have received this email in error, please notify the sender immediately
and delete it from your system. Unauthorised use, disclosure, or copying*
*of the contents is prohibited.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260323/5a467882/attachment.htm>

From snigdha.lee75 at gmail.com  Sun Mar 22 23:59:44 2026
From: snigdha.lee75 at gmail.com (Sionigdha Sadhukhan)
Date: Mon, 23 Mar 2026 12:29:44 +0530
Subject: [QGIS-Developer] GSoC 2026 :JSON Handling Toolkit for QGIS (Updated
 Proposal)
Message-ID: <CAGCrGoOQV+ptm2mLS=9EzaDtAPRHWgcem864U36SB1TUvk6D2w@mail.gmail.com>

Hi all,

I have updated my GSoC 2026 proposal based on the feedback from Valentin
and Nyall. All suggestions have been incorporated  the project is now a
single-headed JSON toolkit with 6 C++ algorithms (LoadJSONFile,
ExtractJSONValue, FlattenJSON, JSONToTable, JSONFromAttributes,
MergeJSONArrays) using nlohmann::json via QgsJsonUtils.

 A working prototype of LoadJSONFile compiled against libqgis_analysis has
also been added to validate the implementation approach.

Updated proposal attached. Any feedback is welcome before the March 31
deadline.

Kind regards, Sionigdha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260323/ab262a5d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSOC 2026.pdf
Type: application/pdf
Size: 603843 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260323/ab262a5d/attachment-0001.pdf>

From nyall.dawson at gmail.com  Mon Mar 23 14:45:54 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 24 Mar 2026 07:45:54 +1000
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
Message-ID: <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>

On Mon, 23 Mar 2026 at 19:20, Tim Sutton via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi all
>
> Here in the infrastructure management club for QGIS we have been embarking on a plan to slowly divest ourselves of 'big tech'. At the end of last year we switched off cloudflare CDN and implemented our own caching servers. At that time we were doing around 130TB of throughput (including what was being soaked up by Cloudflare). As of last month we did 430TB of throughput without the help of Cloudflare.
>
> We are trying to optimise costs - that bandwidth alone cost us in the neighbourhood of 500? per month. To reduce costs we can approach the problem in two way:
>
> 1. optimise the infrastructure - we (QGIS Devops team) are busy looking into ways to do that...
> 2. reduce the download size...
>
> We are wondering if the datum shift files could be split out from the main installer and fetched as an optional extra? Or maybe on demand as you need them? We could set up some infrastructure for hosting them, but we would need some help on the application side to implement logic to go and grab shift files that are not locally cached. Is anyone able to help with this?

Well, we already have quite a user friendly existing workflow in place
for advising the user when they should have a grid shift file that
isn't currently installed, and a friendly automated GUI based approach
for doing the download and install.

So IMO we could rip out all the shift files from the installer and
fallback to this for everyone. The only downside would be that it
relies on internet access, and the download would happen once per user
(as opposed to once per organisation if they're bundled).

<sarcastic> Or we just embrace the 2026 view of analysis slop[1] and
stop caring if results are out by ~50m or have any relation to
real-world locations, and rip out the whole proj grid handling logic.
No one seems to care about accuracy and quality in mapping or coding
anymore anyway. </sarcastic>

Nyall

[1] eg https://mapdesign.icaci.org/tag/365daysofmaps/

>
> Regards
>
> Tim
>
>
>
>
> --
>
> Tim Sutton
> Kartoza Cofounder
> Tim is a member of the QGIS Project Steering Committee
>
> T : +27(0) 87 809 2702          E : tim at kartoza.com          W : kartoza.com
>
>
>
> This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you
> have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying
> of the contents is prohibited.
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

From even.rouault at spatialys.com  Mon Mar 23 14:53:51 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 23 Mar 2026 22:53:51 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
Message-ID: <88f49093-04f6-4697-b92e-d6b8a9c9b856@spatialys.com>

What about having a qgis installer without the grids, and an additional 
optional installer with the grids bundled into it, which could be 
decoupled from QGIS releases themselves and tied to PROJ-data releases ?

Le 23/03/2026 ? 22:45, Nyall Dawson via QGIS-Developer a ?crit?:
> On Mon, 23 Mar 2026 at 19:20, Tim Sutton via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>> Hi all
>>
>> Here in the infrastructure management club for QGIS we have been embarking on a plan to slowly divest ourselves of 'big tech'. At the end of last year we switched off cloudflare CDN and implemented our own caching servers. At that time we were doing around 130TB of throughput (including what was being soaked up by Cloudflare). As of last month we did 430TB of throughput without the help of Cloudflare.
>>
>> We are trying to optimise costs - that bandwidth alone cost us in the neighbourhood of 500? per month. To reduce costs we can approach the problem in two way:
>>
>> 1. optimise the infrastructure - we (QGIS Devops team) are busy looking into ways to do that...
>> 2. reduce the download size...
>>
>> We are wondering if the datum shift files could be split out from the main installer and fetched as an optional extra? Or maybe on demand as you need them? We could set up some infrastructure for hosting them, but we would need some help on the application side to implement logic to go and grab shift files that are not locally cached. Is anyone able to help with this?
> Well, we already have quite a user friendly existing workflow in place
> for advising the user when they should have a grid shift file that
> isn't currently installed, and a friendly automated GUI based approach
> for doing the download and install.
>
> So IMO we could rip out all the shift files from the installer and
> fallback to this for everyone. The only downside would be that it
> relies on internet access, and the download would happen once per user
> (as opposed to once per organisation if they're bundled).
>
> <sarcastic> Or we just embrace the 2026 view of analysis slop[1] and
> stop caring if results are out by ~50m or have any relation to
> real-world locations, and rip out the whole proj grid handling logic.
> No one seems to care about accuracy and quality in mapping or coding
> anymore anyway. </sarcastic>
>
> Nyall
>
> [1] eghttps://mapdesign.icaci.org/tag/365daysofmaps/
>
>> Regards
>>
>> Tim
>>
>>
>>
>>
>> --
>>
>> Tim Sutton
>> Kartoza Cofounder
>> Tim is a member of the QGIS Project Steering Committee
>>
>> T : +27(0) 87 809 2702          E :tim at kartoza.com          W : kartoza.com
>>
>>
>>
>> This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you
>> have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying
>> of the contents is prohibited.
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From gdt at lexort.com  Mon Mar 23 14:54:06 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 23 Mar 2026 17:54:06 -0400
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
 (Nyall Dawson via's message of "Tue, 24 Mar 2026 07:45:54 +1000")
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
Message-ID: <rmicy0uciv5.fsf@s1.lexort.com>

Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> Well, we already have quite a user friendly existing workflow in place
> for advising the user when they should have a grid shift file that
> isn't currently installed, and a friendly automated GUI based approach
> for doing the download and install.
>
> So IMO we could rip out all the shift files from the installer and
> fallback to this for everyone. The only downside would be that it
> relies on internet access, and the download would happen once per user
> (as opposed to once per organisation if they're bundled).

In pkgsrc, we have proj, which is the code w/o grids, capable of using
the proj CDN, and we have proj-data, which is over 1 GB.   qgis has
nothing to do with whether proj-data is installed.

I think being able to operate offline is important.  That can be for
security purposes, or because you are someplace without Internet or with
a very thin or expensive pipe.

I'm not really clear on "installer" and if that's sort of it's own
packaging system, but I'm assuming it's not just qgis but everything it
depends on that isn't part of the base OS, for some small set of OSes
:-)

It seems obvious that it would be sensible to have the main installer
not have grid shift files and to have a second installer that only has
grid shift files (or also similar bits for other things in the qgis
world), so that if you have also installed the "data for offline use"
thing, then qgis can access grids w/o doing network.

It is less obvious to me that this "two installers, not colliding, but
cooperating" is workable.

From even.rouault at spatialys.com  Mon Mar 23 14:54:44 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 23 Mar 2026 22:54:44 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <88f49093-04f6-4697-b92e-d6b8a9c9b856@spatialys.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
 <88f49093-04f6-4697-b92e-d6b8a9c9b856@spatialys.com>
Message-ID: <8932591c-3167-4821-822c-92f73cb1bc92@spatialys.com>

to be clear, I meant:

> What about having a qgis installer without the grids, and an 
> additional optional installer with *only* the grids bundled into it, 
> which could be decoupled from QGIS releases themselves and tied to 
> PROJ-data releases ?

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From alexander.bruy at gmail.com  Tue Mar 24 01:33:16 2026
From: alexander.bruy at gmail.com (Alexander Bruy)
Date: Tue, 24 Mar 2026 08:33:16 +0000
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
Message-ID: <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>

If I'm not wrong, our standalone installer is based on the OSGeo4W and
installs the latter. So users can easily
use the OSGeo4W installer to download any additional dependencies they
want/need.

Another option would be to add an option to the standalone installer to
download grids, similarly to what we had
in the old NSIS installer for Alaska dataset.

??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer <
qgis-developer at lists.osgeo.org> ????:

> Hi all
>
> Here in the infrastructure management club for QGIS we have been embarking
> on a plan to slowly divest ourselves of 'big tech'. At the end of last year
> we switched off cloudflare CDN and implemented our own caching servers. At
> that time we were doing around 130TB of throughput (including what was
> being soaked up by Cloudflare). As of last month we did 430TB of throughput
> without the help of Cloudflare.
>
> We are trying to optimise costs - that bandwidth alone cost us in the
> neighbourhood of 500? per month. To reduce costs we can approach the
> problem in two way:
>
> 1. optimise the infrastructure - we (QGIS Devops team) are busy looking
> into ways to do that...
> 2. reduce the download size...
>
> We are wondering if the datum shift files could be split out from the main
> installer and fetched as an optional extra? Or maybe on demand as you need
> them? We could set up some infrastructure for hosting them, but we would
> need some help on the application side to implement logic to go and grab
> shift files that are not locally cached. Is anyone able to help with this?
>
> Regards
>
> Tim
>
>
>
>
> --
>
> Tim Sutton
>
> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>
> *T *: +27(0) 87 809 2702          *E *: tim at kartoza.com          *W* :
> kartoza.com
>
>
>
> *This email and any attachments are confidential and intended solely for
> the use of the individual or entity to whom they are addressed. If you *
> *have received this email in error, please notify the sender immediately
> and delete it from your system. Unauthorised use, disclosure, or copying*
> *of the contents is prohibited.*
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
Alexander Bruy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/5383fc86/attachment-0001.htm>

From nick at nickbearman.com  Tue Mar 24 02:28:37 2026
From: nick at nickbearman.com (Nick Bearman)
Date: Tue, 24 Mar 2026 09:28:37 +0000
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <rmicy0uciv5.fsf@s1.lexort.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CAB28AshDAAYVicsT7VQkVtgcm3UL8hwTEPQUh7X2Jm8S9ADxtw@mail.gmail.com>
 <rmicy0uciv5.fsf@s1.lexort.com>
Message-ID: <a6a34974-34dc-45fe-8296-be8c0c4ff942@nickbearman.com>

Hi all,

Thanks for the discussion, and it sounds like it is progressing well.

As someone who often trains new QGIS users, I am keen to make the 
'on-ramp' to using QGIS as easy as possible so please can we keep this 
in mind. I am very happy to try things out and give my feedback.

I didn't know QGIS already had the user friendly workflow for adding 
grid shift files (thanks Nyall for mentioning it). I would like to try 
this out to see how it works, how can I make it download a new grid 
shift file? (I guess which CRS do I need to ask it to use to prompt the 
download please).

Thanks!
Nick.

On 23/03/2026 21:54, Greg Troxel via QGIS-Developer wrote:
> Well, we already have quite a user friendly existing workflow in place
> for advising the user when they should have a grid shift file that
> isn't currently installed, and a friendly automated GUI based approach
> for doing the download and install.

-- 
Nick Bearman
+44 (0) 7717745715
nick at nickbearman.com

Please let me know if I can make any adjustments related to disability or neurodivergence to improve how we interact.

Due to my own life/work balance, you may get emails from me outside of normal working hours. Please do not feel any pressure to respond outside of your own working pattern.



From matthias at opengis.ch  Tue Mar 24 02:29:17 2026
From: matthias at opengis.ch (Matthias Kuhn)
Date: Tue, 24 Mar 2026 10:29:17 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
Message-ID: <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>

Hi all,

Thanks for raising this discussion, Tim.
There recently was a discussion about that on a github issue.
The new macOS packages didn't ship grid packages out of the box in the
beginning and this was a blocker for some users so I ended up bundling
the data files again with the macOS packages. The full discussion can be
seen here https://github.com/qgis/QGIS/issues/64486

Key takeaways for me: If we want to split this apart, we need to make it
very easy for users to install missing bits, the current process would need
some improvements. If this is shipped as a separate installer package, we
need to make sure it works across all platforms.

Kind regards
Matthias

On Tue, Mar 24, 2026 at 9:33?AM Alexander Bruy via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> If I'm not wrong, our standalone installer is based on the OSGeo4W and
> installs the latter. So users can easily
> use the OSGeo4W installer to download any additional dependencies they
> want/need.
>
> Another option would be to add an option to the standalone installer to
> download grids, similarly to what we had
> in the old NSIS installer for Alaska dataset.
>
> ??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer <
> qgis-developer at lists.osgeo.org> ????:
>
>> Hi all
>>
>> Here in the infrastructure management club for QGIS we have been
>> embarking on a plan to slowly divest ourselves of 'big tech'. At the end of
>> last year we switched off cloudflare CDN and implemented our own caching
>> servers. At that time we were doing around 130TB of throughput (including
>> what was being soaked up by Cloudflare). As of last month we did 430TB of
>> throughput without the help of Cloudflare.
>>
>> We are trying to optimise costs - that bandwidth alone cost us in the
>> neighbourhood of 500? per month. To reduce costs we can approach the
>> problem in two way:
>>
>> 1. optimise the infrastructure - we (QGIS Devops team) are busy looking
>> into ways to do that...
>> 2. reduce the download size...
>>
>> We are wondering if the datum shift files could be split out from the
>> main installer and fetched as an optional extra? Or maybe on demand as you
>> need them? We could set up some infrastructure for hosting them, but we
>> would need some help on the application side to implement logic to go and
>> grab shift files that are not locally cached. Is anyone able to help with
>> this?
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>
>> --
>>
>> Tim Sutton
>>
>> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>>
>> *T *: +27(0) 87 809 2702          *E *: tim at kartoza.com          *W* :
>> kartoza.com
>>
>>
>>
>> *This email and any attachments are confidential and intended solely for
>> the use of the individual or entity to whom they are addressed. If you *
>> *have received this email in error, please notify the sender immediately
>> and delete it from your system. Unauthorised use, disclosure, or copying*
>> *of the contents is prohibited.*
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
> Alexander Bruy
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/2f4acac1/attachment.htm>

From jef at norbit.de  Tue Mar 24 02:38:12 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Tue, 24 Mar 2026 10:38:12 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
Message-ID: <20260324093812.wjwsdc5ym6xq7u4r@norbit.de>

Hi Tim,

On Mon, 23. Mar 2026 at 09:20:16 +0000, Tim Sutton via QGIS-Developer wrote:
> Here in the infrastructure management club for QGIS we have been embarking
> on a plan to slowly divest ourselves of 'big tech'.

Sidenote: The MSIs weren't relying on big tech.  The download came from
OSUOSL's and OSGeo's download servers and norbit.de - with download.qgis.org
randomly redirecting to one of the three.

> We are wondering if the datum shift files could be split out from the main
> installer and fetched as an optional extra? Or maybe on demand as you need
> them? We could set up some infrastructure for hosting them, but we would
> need some help on the application side to implement logic to go and grab
> shift files that are not locally cached. Is anyone able to help with this?

The dependency of proj to proj-data was dropped in OSGeo4W (which is what
brought proj-data into the installer) and a new package was introduced called
qgis-full-grids, that depends on qgis-full (which is what the default installer
packages) and proj-data.

qgis-full also includes proprietary extensions (oracle, sql server, ecw, mrsid,
filegdb and hdf5), so basing the "lean" installer on qgis-full-free would be an
option too and would make it even smaller (but may force people to download the
"fat" package).

The idea is to create MSIs for qgis-full as usual (but now without the grids)
and qgis-full-grids including the grids and make both available.

The MSIs also ship the OSGeo4W installer so installing proj-data afterwards
would still be possible (although that requires admin rights like the MSI).

BTW the MSIs are currently signed with an expired certificate - OSGeo (ie.
Mike Smith) renewed the certificate, but it's somehow tied to a hardware key
now and Mike is still figuring out how to get if off there to make it
available.


J?rgen

-- 
J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                  Matrix: @jef:osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/6ec98d56/attachment.sig>

From denis.rouzaud at gmail.com  Tue Mar 24 02:46:33 2026
From: denis.rouzaud at gmail.com (Denis Rouzaud)
Date: Tue, 24 Mar 2026 10:46:33 +0100
Subject: [QGIS-Developer] QGIS 4 Docker images
Message-ID: <CAMtsY+Z7E-HCN7-fEw8gV6DfU+hKf-z5EmHLXKzpRrvpbi+syA@mail.gmail.com>

Dear all,

A small note to let you know that I have updated qgis-docker to have QGIS 4
images.

You have to specify the distribution suffix (either questing or trixie) to
get it.

That's because the default image is still noble (24.04 LTR). When the next
LTR is out in a month (Resolut), I'll switch the default image to it,
meaning that the default (latest) tag will lead to get QGIS 4.0.

https://github.com/qgis/qgis-docker
https://hub.docker.com/r/qgis/qgis/tags?name=4.0

Kind regards,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/be351ad8/attachment-0001.htm>

From regis.haubourg at gmail.com  Tue Mar 24 03:01:49 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Tue, 24 Mar 2026 11:01:49 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
Message-ID: <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>

Maybe we could add a mechanism where proj grid files can be imported to 
the user profile, so any user could download grids.

Some caveats to avoid with multi profile management. I'd be in favor of 
storing proj grids once per user $APPDATA profile, not in each QGIS profile

Bien cordialement,
R?gis Haubourg

On 24/03/2026 10:29, Matthias Kuhn via QGIS-Developer wrote:
> Hi all,
>
> Thanks for raising this discussion, Tim.
> There recently was a discussion about that on?a github issue.
> The new macOS packages didn't ship grid packages out of the box in the 
> beginning and this was a blocker for some users so I ended up bundling 
> the?data files again with the macOS packages. The full discussion can 
> be seen here https://github.com/qgis/QGIS/issues/64486
>
> Key takeaways for me: If we want to split this apart, we need to make 
> it very easy for users to install missing bits, the current process 
> would need some improvements. If this is shipped as a separate 
> installer package, we need to make sure it works across all platforms.
>
> Kind regards
> Matthias
>
> On Tue, Mar 24, 2026 at 9:33?AM Alexander Bruy via QGIS-Developer 
> <qgis-developer at lists.osgeo.org> wrote:
>
>     If I'm not wrong, our standalone installer is based on the OSGeo4W
>     and installs the latter. So users can easily
>     use the OSGeo4W installer to download any additional dependencies
>     they want/need.
>
>     Another option would be to add an option to the
>     standalone?installer to download grids, similarly to what we had
>     in the old NSIS installer for Alaska dataset.
>
>     ??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer
>     <qgis-developer at lists.osgeo.org> ????:
>
>         Hi all
>
>         Here in the infrastructure management club for QGIS we have
>         been embarking on a plan to slowly divest ourselves of 'big
>         tech'. At the end of last year we switched off cloudflare CDN
>         and implemented our own caching servers. At that time we were
>         doing around 130TB of throughput (including what was being
>         soaked up by Cloudflare). As of last month we did 430TB of
>         throughput without the help of Cloudflare.
>
>         We are trying to optimise costs - that bandwidth alone cost us
>         in the neighbourhood of 500? per month. To reduce costs we can
>         approach the problem in two way:
>
>         1. optimise the infrastructure - we (QGIS Devops team) are
>         busy looking into ways to do that...
>         2. reduce the download size...
>
>         We are wondering if the datum shift files could be split out
>         from the main installer and fetched as an optional extra? Or
>         maybe on demand as you need them? We could set up some
>         infrastructure for hosting them, but we would need some help
>         on the application side to implement logic to go and grab
>         shift files that are not locally cached. Is anyone able to
>         help with this?
>
>         Regards
>
>         Tim
>
>
>
>
>         -- 
>
>         Tim Sutton
>         *Kartoza Cofounder
>         *Tim is a member of the QGIS Project Steering Committee*
>         *
>         *
>         *
>         *T *:?+27(0) 87 809 2702 *E *:**tim at kartoza.com *W*?:
>         kartoza.com <http://kartoza.com/>
>
>         /
>         /
>         /
>         /
>         /This email and any attachments are confidential and intended
>         solely for the use of the individual or entity to whom they
>         are addressed. If you /
>         /have received this email in error, please notify the sender
>         immediately and delete it from your system. Unauthorised use,
>         disclosure, or copying/
>         /of the contents is prohibited./
>         _______________________________________________
>         QGIS-Developer mailing list
>         QGIS-Developer at lists.osgeo.org
>         List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>         Unsubscribe:
>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>     -- 
>     Alexander Bruy
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/8df38ba8/attachment.htm>

From jef at norbit.de  Tue Mar 24 03:55:46 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Tue, 24 Mar 2026 11:55:46 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
 <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
Message-ID: <20260324105546.7evnlybos4acdkdn@norbit.de>

On Tue, 24. Mar 2026 at 11:01:49 +0100, R?gis Haubourg via QGIS-Developer wrote:
> Maybe we could add a mechanism where proj grid files can be imported to the
> user profile, so any user could download grids.

https://proj.org/en/stable/apps/projsync.html


J?rgen

-- 
J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                  Matrix: @jef:osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/aa15fad2/attachment.sig>

From nyall.dawson at gmail.com  Tue Mar 24 04:02:05 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 24 Mar 2026 21:02:05 +1000
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
 <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
Message-ID: <CAB28Asg_1NLm7hMPP45GRRDKxH93VeRSR-7FJSE7PyfjXjMq0Q@mail.gmail.com>

On Tue, 24 Mar 2026, 8:02?pm R?gis Haubourg via QGIS-Developer, <
qgis-developer at lists.osgeo.org> wrote:

> Maybe we could add a mechanism where proj grid files can be imported to
> the user profile, so any user could download grids.
>

Well, we already have https://github.com/qgis/QGIS/pull/31622

Is that what you mean?

Nyall

Some caveats to avoid with multi profile management. I'd be in favor of
> storing proj grids once per user $APPDATA profile, not in each QGIS profile
>
> Bien cordialement,
> R?gis Haubourg
>
> On 24/03/2026 10:29, Matthias Kuhn via QGIS-Developer wrote:
>
> Hi all,
>
> Thanks for raising this discussion, Tim.
> There recently was a discussion about that on a github issue.
> The new macOS packages didn't ship grid packages out of the box in the
> beginning and this was a blocker for some users so I ended up bundling
> the data files again with the macOS packages. The full discussion can be
> seen here https://github.com/qgis/QGIS/issues/64486
>
> Key takeaways for me: If we want to split this apart, we need to make it
> very easy for users to install missing bits, the current process would need
> some improvements. If this is shipped as a separate installer package, we
> need to make sure it works across all platforms.
>
> Kind regards
> Matthias
>
> On Tue, Mar 24, 2026 at 9:33?AM Alexander Bruy via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>> If I'm not wrong, our standalone installer is based on the OSGeo4W and
>> installs the latter. So users can easily
>> use the OSGeo4W installer to download any additional dependencies they
>> want/need.
>>
>> Another option would be to add an option to the standalone installer to
>> download grids, similarly to what we had
>> in the old NSIS installer for Alaska dataset.
>>
>> ??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer <
>> qgis-developer at lists.osgeo.org> ????:
>>
>>> Hi all
>>>
>>> Here in the infrastructure management club for QGIS we have been
>>> embarking on a plan to slowly divest ourselves of 'big tech'. At the end of
>>> last year we switched off cloudflare CDN and implemented our own caching
>>> servers. At that time we were doing around 130TB of throughput (including
>>> what was being soaked up by Cloudflare). As of last month we did 430TB of
>>> throughput without the help of Cloudflare.
>>>
>>> We are trying to optimise costs - that bandwidth alone cost us in the
>>> neighbourhood of 500? per month. To reduce costs we can approach the
>>> problem in two way:
>>>
>>> 1. optimise the infrastructure - we (QGIS Devops team) are busy looking
>>> into ways to do that...
>>> 2. reduce the download size...
>>>
>>> We are wondering if the datum shift files could be split out from the
>>> main installer and fetched as an optional extra? Or maybe on demand as you
>>> need them? We could set up some infrastructure for hosting them, but we
>>> would need some help on the application side to implement logic to go and
>>> grab shift files that are not locally cached. Is anyone able to help with
>>> this?
>>>
>>> Regards
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Tim Sutton
>>>
>>> *Kartoza Cofounder *Tim is a member of the QGIS Project Steering
>>> Committee
>>>
>>> *T *: +27(0) 87 809 2702          *E *: tim at kartoza.com          *W* :
>>> kartoza.com
>>>
>>>
>>>
>>> *This email and any attachments are confidential and intended solely for
>>> the use of the individual or entity to whom they are addressed. If you *
>>> *have received this email in error, please notify the sender immediately
>>> and delete it from your system. Unauthorised use, disclosure, or copying*
>>> *of the contents is prohibited.*
>>> _______________________________________________
>>> QGIS-Developer mailing list
>>> QGIS-Developer at lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> --
>> Alexander Bruy
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/502ef62c/attachment-0001.htm>

From gdt at lexort.com  Tue Mar 24 05:29:22 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 24 Mar 2026 08:29:22 -0400
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 (Alexander Bruy via's message of "Tue, 24 Mar 2026 08:33:16 +0000")
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
Message-ID: <rmitsu5becd.fsf@s1.lexort.com>

Alexander Bruy via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> If I'm not wrong, our standalone installer is based on the OSGeo4W and
> installs the latter. So users can easily
> use the OSGeo4W installer to download any additional dependencies they
> want/need.

perhaps the windows installer.

The real problem here is that this 'installer' thing is properly the job
of packaging systems, and qgis has gone down the path of packaging, only
partway.

From regis.haubourg at gmail.com  Tue Mar 24 05:38:05 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Tue, 24 Mar 2026 13:38:05 +0100
Subject: [QGIS-Developer] Reducing the size of our download packages
In-Reply-To: <CAB28Asg_1NLm7hMPP45GRRDKxH93VeRSR-7FJSE7PyfjXjMq0Q@mail.gmail.com>
References: <CAES-DZQsKeRE43vpmpD8A5uKE11k3BMcehsvv1FpQm7_ROj1UQ@mail.gmail.com>
 <CALuHMPCUJw6mXaDs95uxhSba-_Eydjjw87d50S==G0YgBsR3Hw@mail.gmail.com>
 <CAC7zN95yo1ShvAQih1AxeM93PQvr722PjvOwD4V873O5jD62hg@mail.gmail.com>
 <bf4f5f3b-2502-496a-88c3-9953a40f6612@gmail.com>
 <CAB28Asg_1NLm7hMPP45GRRDKxH93VeRSR-7FJSE7PyfjXjMq0Q@mail.gmail.com>
Message-ID: <abec0b1f-5396-4419-80f0-acbcd4225a93@gmail.com>

Haaa laughing of myself :)

Sorry for the noise.

Bien cordialement,
R?gis Haubourg

On 24/03/2026 12:02, Nyall Dawson wrote:
>
>
> On Tue, 24 Mar 2026, 8:02?pm R?gis Haubourg via QGIS-Developer, 
> <qgis-developer at lists.osgeo.org> wrote:
>
>     Maybe we could add a mechanism where proj grid files can be
>     imported to the user profile, so any user could download grids.
>
>
> Well, we already have https://github.com/qgis/QGIS/pull/31622
>
> Is that what you mean?
>
> Nyall
>
>     Some caveats to avoid with multi profile management. I'd be in
>     favor of storing proj grids once per user $APPDATA profile, not in
>     each QGIS profile
>
>     Bien cordialement,
>     R?gis Haubourg
>
>     On 24/03/2026 10:29, Matthias Kuhn via QGIS-Developer wrote:
>>     Hi all,
>>
>>     Thanks for raising this discussion, Tim.
>>     There recently was a discussion about that on?a github issue.
>>     The new macOS packages didn't ship grid packages out of the box
>>     in the beginning and this was a blocker for some users so I ended
>>     up bundling the?data files again with the macOS packages. The
>>     full discussion can be seen here
>>     https://github.com/qgis/QGIS/issues/64486
>>
>>     Key takeaways for me: If we want to split this apart, we need to
>>     make it very easy for users to install missing bits, the current
>>     process would need some improvements. If this is shipped as a
>>     separate installer package, we need to make sure it works across
>>     all platforms.
>>
>>     Kind regards
>>     Matthias
>>
>>     On Tue, Mar 24, 2026 at 9:33?AM Alexander Bruy via QGIS-Developer
>>     <qgis-developer at lists.osgeo.org> wrote:
>>
>>         If I'm not wrong, our standalone installer is based on the
>>         OSGeo4W and installs the latter. So users can easily
>>         use the OSGeo4W installer to download any additional
>>         dependencies they want/need.
>>
>>         Another option would be to add an option to the
>>         standalone?installer to download grids, similarly to what we had
>>         in the old NSIS installer for Alaska dataset.
>>
>>         ??, 23 ???. 2026??. ? 09:20 Tim Sutton via QGIS-Developer
>>         <qgis-developer at lists.osgeo.org> ????:
>>
>>             Hi all
>>
>>             Here in the infrastructure management club for QGIS we
>>             have been embarking on a plan to slowly divest ourselves
>>             of 'big tech'. At the end of last year we switched off
>>             cloudflare CDN and implemented our own caching servers.
>>             At that time we were doing around 130TB of throughput
>>             (including what was being soaked up by Cloudflare). As of
>>             last month we did 430TB of throughput without the help of
>>             Cloudflare.
>>
>>             We are trying to optimise costs - that bandwidth alone
>>             cost us in the neighbourhood of 500? per month. To reduce
>>             costs we can approach the problem in two way:
>>
>>             1. optimise the infrastructure - we (QGIS Devops team)
>>             are busy looking into ways to do that...
>>             2. reduce the download size...
>>
>>             We are wondering if the datum shift files could be split
>>             out from the main installer and fetched as an optional
>>             extra? Or maybe on demand as you need them? We could set
>>             up some infrastructure for hosting them, but we would
>>             need some help on the application side to implement logic
>>             to go and grab shift files that are not locally cached.
>>             Is anyone able to help with this?
>>
>>             Regards
>>
>>             Tim
>>
>>
>>
>>
>>             -- 
>>
>>             Tim Sutton
>>             *Kartoza Cofounder
>>             *Tim is a member of the QGIS Project Steering Committee*
>>             *
>>             *
>>             *
>>             *T *:?+27(0) 87 809 2702 *E *:**tim at kartoza.com *W*?:
>>             kartoza.com <http://kartoza.com/>
>>
>>             /
>>             /
>>             /
>>             /
>>             /This email and any attachments are confidential and
>>             intended solely for the use of the individual or entity
>>             to whom they are addressed. If you /
>>             /have received this email in error, please notify the
>>             sender immediately and delete it from your system.
>>             Unauthorised use, disclosure, or copying/
>>             /of the contents is prohibited./
>>             _______________________________________________
>>             QGIS-Developer mailing list
>>             QGIS-Developer at lists.osgeo.org
>>             List info:
>>             https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>             Unsubscribe:
>>             https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>>         -- 
>>         Alexander Bruy
>>         _______________________________________________
>>         QGIS-Developer mailing list
>>         QGIS-Developer at lists.osgeo.org
>>         List info:
>>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>         Unsubscribe:
>>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>     _______________________________________________
>>     QGIS-Developer mailing list
>>     QGIS-Developer at lists.osgeo.org
>>     List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>     Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/91f15ed4/attachment-0001.htm>

From denis.rouzaud at gmail.com  Tue Mar 24 06:11:03 2026
From: denis.rouzaud at gmail.com (Denis Rouzaud)
Date: Tue, 24 Mar 2026 14:11:03 +0100
Subject: [QGIS-Developer] QGIS 4 Docker images
In-Reply-To: <CAMtsY+Z7E-HCN7-fEw8gV6DfU+hKf-z5EmHLXKzpRrvpbi+syA@mail.gmail.com>
References: <CAMtsY+Z7E-HCN7-fEw8gV6DfU+hKf-z5EmHLXKzpRrvpbi+syA@mail.gmail.com>
Message-ID: <CAMtsY+YXzkcZ+GEVcY41PsGKhd4FmV3-pbM687PHzhyKDggAhg@mail.gmail.com>

Hi again,

I have finally switched the default image to questing. This change ensures
that the "latest" tag will now point to QGIS 4.x instead of 3.99.

Kind regards,

Denis Rouzaud

Le mar. 24 mars 2026 ? 10:46, Denis Rouzaud <denis.rouzaud at gmail.com> a
?crit :

> Dear all,
>
> A small note to let you know that I have updated qgis-docker to have QGIS
> 4 images.
>
> You have to specify the distribution suffix (either questing or trixie) to
> get it.
>
> That's because the default image is still noble (24.04 LTR). When the next
> LTR is out in a month (Resolut), I'll switch the default image to it,
> meaning that the default (latest) tag will lead to get QGIS 4.0.
>
> https://github.com/qgis/qgis-docker
> https://hub.docker.com/r/qgis/qgis/tags?name=4.0
>
> Kind regards,
> Denis
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/8496f28f/attachment.htm>

From rdmailings at duif.net  Tue Mar 24 11:15:18 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Tue, 24 Mar 2026 19:15:18 +0100
Subject: [QGIS-Developer] Different QGIS icons and desktop files for LTR and
 stable?
Message-ID: <d071a2d9-d6ed-4794-b8bd-31df08f91fb2@duif.net>

Hi,

In the Flatpak/Linux packaging world I'm trying to convince people to distribute 2 different QGIS versions:
Stable: org.qgis.qgis
and LTR:  org.qgis.qgis.ltr

In one of the discussions people were suggesting to create 2 desktop files, AND 2 different icons, so people could install them next to each other and could distinguish the versions based on the icon.
I think that would be usefull for other OS's too?
Anybody idea's for this (just a green LTR in it?) or time?

When trying to 'create' the LTR version [1] I stumbled upon the script and template which create the desktop files.
Anybody has knowledge where in the build process we could put some flag, to either create a LTR-desktop file vs a 'stable' desktop file (including nice icon ;-) )?
I do not even know how to call this script (via Make ?) to create the normal desktop file.

And yes, I know there are some shortcomings on the Flatpak, but as a user in a very constraint environment I fully depend on this... So that's why :-)

Regards,

Richard Duivenoorde


[0] https://github.com/flathub/org.qgis.qgis/issues
[1] https://github.com/flathub/org.qgis.qgis/pull/1046#issuecomment-4055611394




From dmarteau at 3liz.com  Tue Mar 24 14:20:27 2026
From: dmarteau at 3liz.com (David Marteau)
Date: Tue, 24 Mar 2026 22:20:27 +0100
Subject: [QGIS-Developer] QgsMessageLog signals are broken in pyQGIS with
 QGIS 4
Message-ID: <35cde695-fbc4-4194-b68c-c6b36e311de9@3liz.com>

Hi,

We have noticed that the QgsMessageLog signals (`messageReceived`, 
`messageReceivedWithFormat`) are not received anymore in Python callback 
slots.

This is an important api break and from this, one may suspect that other 
(bad) surprise are waiting at the corner.

There is mention of this in the python tests from QGIS sources, so the 
problem was known at some point.

What are the positions on the subject ?? ?Is there some hints toward a 
fix (so that we could give some help)? ?

Thanks

-- 

David Marteau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/07b6c707/attachment.htm>

From dmarteau at 3liz.com  Tue Mar 24 15:05:16 2026
From: dmarteau at 3liz.com (David Marteau)
Date: Tue, 24 Mar 2026 23:05:16 +0100
Subject: [QGIS-Developer] QgsMessageLog signals are broken in pyQGIS
 with QGIS 4
In-Reply-To: <35cde695-fbc4-4194-b68c-c6b36e311de9@3liz.com>
References: <35cde695-fbc4-4194-b68c-c6b36e311de9@3liz.com>
Message-ID: <b0a9743e-fd06-4699-b6e2-3285d6fe2abb@3liz.com>

I Answer to myself.

Found that `messageReceivedWithFormat` indeed work but `messageReceived` 
is blocked for any reason (seems to be a feature of QGIS 4)

Sorry for the noise...

David Marteau

Le 24/03/2026 ? 22:20, David Marteau via QGIS-Developer a ?crit?:

> Hi,
>
> We have noticed that the QgsMessageLog signals (`messageReceived`, 
> `messageReceivedWithFormat`) are not received anymore in Python 
> callback slots.
>
> This is an important api break and from this, one may suspect that 
> other (bad) surprise are waiting at the corner.
>
> There is mention of this in the python tests from QGIS sources, so the 
> problem was known at some point.
>
> What are the positions on the subject ?? ?Is there some hints toward a 
> fix (so that we could give some help)? ?
>
> Thanks
>
> -- 
>
> David Marteau
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260324/d14f981a/attachment.htm>

From benter.jci at gmail.com  Wed Mar 25 08:31:08 2026
From: benter.jci at gmail.com (John Carlo Benter)
Date: Wed, 25 Mar 2026 23:31:08 +0800
Subject: [QGIS-Developer] GSoC QGIS Project Proposal
Message-ID: <CAGTM+5K6wpU+-bCOOtLH2kB4j4kFF76t03Cm5xp+cKcaFrYK=Q@mail.gmail.com>

Greetings,

I?m a 3rd-year Computer Science student at the University of Santo Tomas.
Right now, I?m deep into my thesis which focuses on urban analytics and
mapping accessibility in Quezon City. I?ve been looking into the GSoC
projects for OSGeo and I have an idea I?d love to get some feedback on.

I want to build a plugin called Q-Access that brings that workflow directly
into the QGIS interface. The goal is to let a user pick a study area,
define some POIs like schools or hospitals from OSM tags, and have the
plugin calculate the accessibility scores on the fly.

I?m planning to use OSMnx and NetworkX for the heavy lifting and QgsTask to
make sure the UI stays responsive during the calculations. I think it fits
well into the 175-hour slot, and I?m already using the city from my thesis
as my test case to make sure it handles high-density urban data well.

Looking forward to hearing your response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260325/dac622e5/attachment.htm>

From valentin.buira at gmail.com  Sun Mar 29 13:51:15 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Sun, 29 Mar 2026 22:51:15 +0200
Subject: [QGIS-Developer] GSoC QGIS Project Proposal
In-Reply-To: <CAGTM+5K6wpU+-bCOOtLH2kB4j4kFF76t03Cm5xp+cKcaFrYK=Q@mail.gmail.com>
References: <CAGTM+5K6wpU+-bCOOtLH2kB4j4kFF76t03Cm5xp+cKcaFrYK=Q@mail.gmail.com>
Message-ID: <8fda44a1-fac0-4212-9e52-407f72b87c11@gmail.com>

Hi John,

Unfortunately, I don't think your project quite fit the requirements of 
the QGIS project as GSoC projects are intended to improve the core of 
QGIS instead of adding new plugins. Moreover, I would say the question 
to ask yourself when adding a new feature to the core of QGIS is: "Is 
this feature going to be helpful for at least three different fields? ?"

Since it looks like you are interested in graph theory, an example of 
GSOC would be? "Improve network analysis algorithms in QGIS"

However your master thesis does look interesting (I also did my master 
thesis on accessibility and walkability so I am looking forward to try 
it out if you do a plugin)

Kind regards,
Valentin Buira

PS: Take a look at the existing plugins on accessibility : 
https://plugins.qgis.org/plugins/tags/accessibility/ maybe you can 
build/improve upon pre-existing work


From miguelenricoimperial at gmail.com  Mon Mar 30 07:30:03 2026
From: miguelenricoimperial at gmail.com (Miguel Imperial)
Date: Mon, 30 Mar 2026 22:30:03 +0800
Subject: [QGIS-Developer] Configurable limit for "Identify Features" tool
Message-ID: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>

Hello. I?m Miguel, a developer from the Philippines.

First time to contribute to QGIS and I?d like to take on https://github.com/qgis/QGIS/issues/60567.

Is there anyone working on this already?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260330/7e66ad67/attachment.htm>

From lfi at ign.ku.dk  Tue Mar 31 00:05:02 2026
From: lfi at ign.ku.dk (Lene Fischer)
Date: Tue, 31 Mar 2026 07:05:02 +0000
Subject: [QGIS-Developer] QGIS meeting October?
In-Reply-To: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>
References: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>
Message-ID: <05ca799d6e404f51986e69f5c2673db3@ign.ku.dk>

Hi,
Will there be a QGIS meeting in October 2026 in Laax ?
Regards
Lene Fischer


Lene Fischer
Associate Professor

University of Copenhagen
Department of Geosciences and Natural Resource Management
Forest and Landscape College
N?debovej 77a
3480 Fredensborg

MOB +45 40115084
lfi at ign.ku.dk<mailto:lfi at ign.ku.dk>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/2cdfad50/attachment.htm>

From rdmailings at duif.net  Tue Mar 31 00:08:06 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Tue, 31 Mar 2026 09:08:06 +0200
Subject: [QGIS-Developer] QGIS meeting October?
In-Reply-To: <05ca799d6e404f51986e69f5c2673db3@ign.ku.dk>
References: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>
 <05ca799d6e404f51986e69f5c2673db3@ign.ku.dk>
Message-ID: <ffdea335-47cc-47d9-8ce9-c135cfb02b93@duif.net>

On 3/31/26 09:05, Lene Fischer via QGIS-Developer wrote:
> Hi,
> 
> Will there be a QGIS meeting in October 2026 in Laax ?

Yep:

https://conference.qgis.org/

Regards,
Richard



From imajimatika at gmail.com  Tue Mar 31 00:23:48 2026
From: imajimatika at gmail.com (Ismail Sunni)
Date: Tue, 31 Mar 2026 14:23:48 +0700
Subject: [QGIS-Developer] GSoC QGIS Project Proposal
In-Reply-To: <8fda44a1-fac0-4212-9e52-407f72b87c11@gmail.com>
References: <CAGTM+5K6wpU+-bCOOtLH2kB4j4kFF76t03Cm5xp+cKcaFrYK=Q@mail.gmail.com>
 <8fda44a1-fac0-4212-9e52-407f72b87c11@gmail.com>
Message-ID: <CAEh5jtH+djH7rNkJ2dMa9f0fksgH9ma8cqhaSyOMOj_rqLLRMQ@mail.gmail.com>

Hi John and Valentin,

Actually, there was a QGIS GSoC project that developed a QGIS Plugin. It
was the QGIS Resource Sharing Plugin
<https://github.com/QGIS-Contribution/QGIS-ResourceSharing/> (started as
GSoC 2016, and the development is now taken over by the community).

But I agree with Valentin, the idea of the new plugin is perhaps not so
fitting for the GSoC Project for QGIS unless it can improve the QGIS
project/ecosystem in general, like the QGIS Resource Sharing Plugin.

And yes, I also agree that the network analysis might be a good idea. But
not sure if most users prefer to use other tools as the "engine" and use
QGIS as the interface only.

Good luck anyway!

Best regards.

On Mon, Mar 30, 2026 at 3:51?AM Valentin Buira via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi John,
>
> Unfortunately, I don't think your project quite fit the requirements of
> the QGIS project as GSoC projects are intended to improve the core of
> QGIS instead of adding new plugins. Moreover, I would say the question
> to ask yourself when adding a new feature to the core of QGIS is: "Is
> this feature going to be helpful for at least three different fields  ?"
>
> Since it looks like you are interested in graph theory, an example of
> GSOC would be  "Improve network analysis algorithms in QGIS"
>
> However your master thesis does look interesting (I also did my master
> thesis on accessibility and walkability so I am looking forward to try
> it out if you do a plugin)
>
> Kind regards,
> Valentin Buira
>
> PS: Take a look at the existing plugins on accessibility :
> https://plugins.qgis.org/plugins/tags/accessibility/ maybe you can
> build/improve upon pre-existing work
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
Ismail Sunni
Software Engineer
ismailsunni.id
ismailsunni.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/da50cccf/attachment-0001.htm>

From carlo.bertelli at gmail.com  Tue Mar 31 05:44:17 2026
From: carlo.bertelli at gmail.com (Carlo A. Bertelli (Charta s.r.l.))
Date: Tue, 31 Mar 2026 14:44:17 +0200
Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS
 databases in v. 4.0.0
Message-ID: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>

I understand that GDAL declares

> Starting with GDAL 3.9, only PostgreSQL >= 9 and PostGIS >= 2 are
> supported.

but version 3.44 still can open layers from a v. 8.4 database and PostGIS
1.5.
Now version 4 does not open layers from this database.
GDAL v. 3.12.3 per se can open these layers, ogrinfo works well, ogr2ogr
lets me upload data from files to the same database.
What happened with the new version? I cannot even change parameters per
table. Is there a solution for this?
Unfortunately I cannot change the database nor upgrade it, even if I would
like very much.
c

-- 
--------------------------------------------------------------------------
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
          Dipendenze del palazzo Doria,
          vc. alla Chiesa della Maddalena 9/2 16124      Genova (Italy)
          tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: bertelli at chartasrl.eu      http://www.chartasrl.eu
--------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/2332d3ae/attachment.htm>

From even.rouault at spatialys.com  Tue Mar 31 05:54:58 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 31 Mar 2026 14:54:58 +0200
Subject: [QGIS-Developer] Reduced compatibility with old
 PosgreSQL/PostGIS databases in v. 4.0.0
In-Reply-To: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>
References: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>
Message-ID: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com>

Carlo,

you're conflating two different things:

- PostgreSQL & PostGIS version support in GDAL.? It might still semi 
work for you with dropped supported version by chance/accident.

-?PostgreSQL & PostGIS version support in QGIS PostgreSQL provider. 
Looking quickly at git log, I don't see anything explicit abut dropping 
them. I suppose that support for those older versions broke by accident 
or wasn't explicitly mentionned.

In any case those ancient versions aren't supported, have likely unfixed 
security issues, and it would be hard for us to test against them.

So use older QGIS versions if you really need to stick with your ancient 
PostgreSQL & PostGIS version. There's hardly no chance you can convince 
us (at least me for the code I'm responsible of) to bring back support 
for them

Even

Le 31/03/2026 ? 14:44, Carlo A. Bertelli (Charta s.r.l.) via 
QGIS-Developer a ?crit?:
> I understand that GDAL declares
>
>     Starting with GDAL 3.9, only PostgreSQL >= 9 and PostGIS >= 2 are
>     supported.
>
> but version 3.44 still can open layers from a v. 8.4 database and 
> PostGIS 1.5.
> Now version 4 does not open layers from this database.
> GDAL v. 3.12.3 per se can open these layers, ogrinfo works well, 
> ogr2ogr lets me upload data from files to the same database.
> What happened with the new version? I cannot even change parameters 
> per table. Is there a solution for?this?
> Unfortunately I cannot change the database nor upgrade it, even if I 
> would like very much.
> c
>
> -- 
> --------------------------------------------------------------------------
> Carlo A. Bertelli
> ?? Charta servizi e sistemi per il territorio e la storia ambientale srl
> ? ? ? ? ? Dipendenze del palazzo Doria,
> ? ? ? ? ? vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)
> ? ? ? ? ? tel./fax +39(0)10 2475439? +39 0108566195 mobile:+39 393 1590711
> ?? e-mail: bertelli at chartasrl.eu http://www.chartasrl.eu
> --------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/52c9985f/attachment.htm>

From lfi at ign.ku.dk  Tue Mar 31 07:31:30 2026
From: lfi at ign.ku.dk (Lene Fischer)
Date: Tue, 31 Mar 2026 14:31:30 +0000
Subject: [QGIS-Developer] QGIS meeting October?
In-Reply-To: <ffdea335-47cc-47d9-8ce9-c135cfb02b93@duif.net>
References: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>
 <05ca799d6e404f51986e69f5c2673db3@ign.ku.dk>
 <ffdea335-47cc-47d9-8ce9-c135cfb02b93@duif.net>
Message-ID: <05e8df12ae6745a8a39ce9c892571a63@ign.ku.dk>

But no tickets or price announced.

Regards
Lene Fischer
  





-----Oprindelig meddelelse-----
Fra: Richard Duivenvoorde <rdmailings at duif.net> 
Sendt: 31. marts 2026 09:08
Til: Lene Fischer <lfi at ign.ku.dk>; qgis-developer at lists.osgeo.org
Emne: Re: [QGIS-Developer] QGIS meeting October?

On 3/31/26 09:05, Lene Fischer via QGIS-Developer wrote:
> Hi,
> 
> Will there be a QGIS meeting in October 2026 in Laax ?

Yep:

https://conference.qgis.org/

Regards,
Richard



From uclaros at gmail.com  Tue Mar 31 09:14:11 2026
From: uclaros at gmail.com (Stefanos Natsis)
Date: Tue, 31 Mar 2026 19:14:11 +0300
Subject: [QGIS-Developer] Reduced compatibility with old
 PosgreSQL/PostGIS databases in v. 4.0.0
In-Reply-To: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com>
References: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>
 <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com>
Message-ID: <CADBCwLbPGMaF5HTJ=Zf1NENYhr2Zsg=a85wKTT8SWp1imy+rvA@mail.gmail.com>

Hi,

One breaking change I'm aware of in QGIS 4 is that we've used the `CREATE
TABLE IF NOT EXISTS` idiom for the `qgis_projects` table (for storing
projects in the database) which was introduced in PostgreSQL 9.1

Best,
Stefanos

On Tue, 31 Mar 2026 at 15:55, Even Rouault via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Carlo,
>
> you're conflating two different things:
>
> - PostgreSQL & PostGIS version support in GDAL.  It might still semi work
> for you with dropped supported version by chance/accident.
>
> - PostgreSQL & PostGIS version support in QGIS PostgreSQL provider.
> Looking quickly at git log, I don't see anything explicit abut dropping
> them. I suppose that support for those older versions broke by accident or
> wasn't explicitly mentionned.
>
> In any case those ancient versions aren't supported, have likely unfixed
> security issues, and it would be hard for us to test against them.
>
> So use older QGIS versions if you really need to stick with your ancient
> PostgreSQL & PostGIS version. There's hardly no chance you can convince us
> (at least me for the code I'm responsible of) to bring back support for them
>
> Even
> Le 31/03/2026 ? 14:44, Carlo A. Bertelli (Charta s.r.l.) via
> QGIS-Developer a ?crit :
>
> I understand that GDAL declares
>
>> Starting with GDAL 3.9, only PostgreSQL >= 9 and PostGIS >= 2 are
>> supported.
>
> but version 3.44 still can open layers from a v. 8.4 database and PostGIS
> 1.5.
> Now version 4 does not open layers from this database.
> GDAL v. 3.12.3 per se can open these layers, ogrinfo works well, ogr2ogr
> lets me upload data from files to the same database.
> What happened with the new version? I cannot even change parameters per
> table. Is there a solution for this?
> Unfortunately I cannot change the database nor upgrade it, even if I would
> like very much.
> c
>
> --
> --------------------------------------------------------------------------
> Carlo A. Bertelli
>    Charta servizi e sistemi per il territorio e la storia ambientale srl
>           Dipendenze del palazzo Doria,
>           vc. alla Chiesa della Maddalena 9/2 16124      Genova (Italy)
>           tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393
> 1590711
>    e-mail: bertelli at chartasrl.eu      http://www.chartasrl.eu
> --------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/b789a3a4/attachment-0001.htm>

From imajimatika at gmail.com  Tue Mar 31 09:46:30 2026
From: imajimatika at gmail.com (Ismail Sunni)
Date: Tue, 31 Mar 2026 23:46:30 +0700
Subject: [QGIS-Developer] QGIS meeting October?
In-Reply-To: <05e8df12ae6745a8a39ce9c892571a63@ign.ku.dk>
References: <F968CA0B-814C-46FF-BD78-269D6B271B36@gmail.com>
 <05ca799d6e404f51986e69f5c2673db3@ign.ku.dk>
 <ffdea335-47cc-47d9-8ce9-c135cfb02b93@duif.net>
 <05e8df12ae6745a8a39ce9c892571a63@ign.ku.dk>
Message-ID: <CAEh5jtEoy38g35Ae-XvKGkjQDu6T67bR=eeoowreLgqMvVHKZQ@mail.gmail.com>

Ah yes, you are right Lene. No tickets are announced yet. But it says it
will start selling in March.

In my location, there is still 15 minutes left before March ends. So, there
is still enough time :)

Best regards

--

Ismail Sunni
Software Engineer
ismailsunni.id
ismailsunni.wordpress.com

On Tue, Mar 31, 2026, 21:32 Lene Fischer via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> But no tickets or price announced.
>
> Regards
> Lene Fischer
>
>
>
>
>
>
> -----Oprindelig meddelelse-----
> Fra: Richard Duivenvoorde <rdmailings at duif.net>
> Sendt: 31. marts 2026 09:08
> Til: Lene Fischer <lfi at ign.ku.dk>; qgis-developer at lists.osgeo.org
> Emne: Re: [QGIS-Developer] QGIS meeting October?
>
> On 3/31/26 09:05, Lene Fischer via QGIS-Developer wrote:
> > Hi,
> >
> > Will there be a QGIS meeting in October 2026 in Laax ?
>
> Yep:
>
> https://conference.qgis.org/
>
> Regards,
> Richard
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/849a3f47/attachment.htm>

From regis.haubourg at gmail.com  Tue Mar 31 11:26:12 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Tue, 31 Mar 2026 20:26:12 +0200
Subject: [QGIS-Developer] Reduced compatibility with old
 PosgreSQL/PostGIS databases in v. 4.0.0
In-Reply-To: <CADBCwLbPGMaF5HTJ=Zf1NENYhr2Zsg=a85wKTT8SWp1imy+rvA@mail.gmail.com>
References: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>
 <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com>
 <CADBCwLbPGMaF5HTJ=Zf1NENYhr2Zsg=a85wKTT8SWp1imy+rvA@mail.gmail.com>
Message-ID: <bfc6962c-0207-491f-910c-b952b98a45ea@gmail.com>

9.1 has reached end of life 10 years ago!
I'm with Even here. A Postgres server out of maintenance period must be 
considered insecure and outdated and must totally be upgraded anyway.

Cheer, R?gis

On 31/03/2026 18:14, Stefanos Natsis via QGIS-Developer wrote:
> One breaking change I'm aware of in QGIS 4 is that we've used the 
> `CREATE TABLE IF NOT EXISTS` idiom for the `qgis_projects` table (for 
> storing projects in the database) which was introduced in PostgreSQL 9.1

From carlo.bertelli at gmail.com  Tue Mar 31 13:00:13 2026
From: carlo.bertelli at gmail.com (Carlo A. Bertelli (Charta s.r.l.))
Date: Tue, 31 Mar 2026 22:00:13 +0200
Subject: [QGIS-Developer] Reduced compatibility with old
 PosgreSQL/PostGIS databases in v. 4.0.0
In-Reply-To: <bfc6962c-0207-491f-910c-b952b98a45ea@gmail.com>
References: <CALc8-V+_KB-aY11mkc=KJrXi2-nwzdhROoQyyPfAr2i0wUti5A@mail.gmail.com>
 <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com>
 <CADBCwLbPGMaF5HTJ=Zf1NENYhr2Zsg=a85wKTT8SWp1imy+rvA@mail.gmail.com>
 <bfc6962c-0207-491f-910c-b952b98a45ea@gmail.com>
Message-ID: <CALc8-VJ6b9uki==Oc-dhQ5ugr24CSB+X-XO2TLv5eH7H_MgV9g@mail.gmail.com>

Thanks to everyone for replying so quickly to this problem.
I totally agree with you about the necessity to upgrade PostgreSQL and I
think it's not a good idea to risk adding bugs to a foundation library as
GDAL.
Anyway, I tried version 3.12.3 and it supports reading from a table and
writing to it without problems. But something changed at least on version
4.0.0 for MacOS.
While the DBManager recognized the table structure, the datasource browser
doesn't and complains:

> Error retrieving fields information for uri: bname='mydb' host=d
> b.myclientshost.com port=5432 user='mypooruser' sslmode=disable
> checkPrimaryKeyUnicity='O' table="oneschema". "mypolytable"

when browsing fields.
Maybe it has something to do with *uri: *bname which obviously means *uri:
dbname* but the typo would break something if it is used in the code.
This is the PostGIS error I get when retrieving this layer:

2026-03-31T21:39:29     WARNING    Erroneous query: SELECT
> has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function
> pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              ]
> 2026-03-31T21:39:29     WARNING    Unable to determine table access
> privileges for the "oneschema". "mypolytable" relation.
>              The error message from the database was:
>              ERROR: function pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              .
>              SQL: SELECT has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),'f'
> 2026-03-31T21:39:29     WARNING    Erroneous query: SELECT
> has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function
> pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              ]
> 2026-03-31T21:39:29     WARNING    Unable to determine table access
> privileges for the "oneschema". "mypolytable" relation.
>              The error message from the database was:
>              ERROR: function pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              .
>              SQL: SELECT has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),'f'
> 2026-03-31T21:46:13     WARNING    Erroneous query: SELECT
> has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),has_column_privilege('"oneschema".
> "mypolytable"','GEOMETRY','UPDATE') returned 7 [ERROR: function
> pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              ]
> 2026-03-31T21:46:13     WARNING    Unable to determine table access
> privileges for the "oneschema". "mypolytable" relation.
>              The error message from the database was:
>              ERROR: function pg_is_in_recovery() does not exist
>              LINE 1: ...vilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_r...
>               ^
>              HINT: No function matches the given name and argument types.
> You might need to add explicit type casts.
>              .
>              SQL: SELECT has_table_privilege('"oneschema".
> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema()
> ,has_any_column_privilege('"oneschema".
> "mypolytable"','INSERT'),has_table_privilege('"oneschema".
> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema".
> "mypolytable"','UPDATE'),has_column_privilege('"oneschema".
> "mypolytable"','GEOMETRY','UPDATE')


while getting the same data by gdalinfo does not need any special
privilege. I should be able to understand what this repeated error means on
the SQL side, but it seems a complete nonsense to me. I'm sure someone
would detect the reason for it.
Is there a way to mitigate it? I was trying to use a virtual ogr file to
handle misbehaving columns; I could convert some specific table to
Spatialite, but I think solving my problem could be useful to someone else.
Thanks in advance for any hint provided.
c

On Tue, Mar 31, 2026 at 8:26?PM R?gis Haubourg via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> 9.1 has reached end of life 10 years ago!
> I'm with Even here. A Postgres server out of maintenance period must be
> considered insecure and outdated and must totally be upgraded anyway.
>
> Cheer, R?gis
>
> On 31/03/2026 18:14, Stefanos Natsis via QGIS-Developer wrote:
> > One breaking change I'm aware of in QGIS 4 is that we've used the
> > `CREATE TABLE IF NOT EXISTS` idiom for the `qgis_projects` table (for
> > storing projects in the database) which was introduced in PostgreSQL 9.1
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260331/e21d8494/attachment-0001.htm>

From nyall.dawson at gmail.com  Tue Mar 31 16:24:21 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 1 Apr 2026 09:24:21 +1000
Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from
 non-core developers?
Message-ID: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>

Hi list,

I'd like to float an idea for discussion: that we explicitly block all AI
based contributions from non-core developers.

As background, currently we have the "human in the loop" policy in place
regarding AI contributions (see
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
). This policy was already locked in, with the feeling that it was a good
first step that we could later refine and build upon.

I've been giving this a lot of thought, and I personally now think that we
need to further tighten our AI policy. To be clear upfront, I am not
approaching this from societal or environmental perspectives, but rather
from my own direct experience with using and testing these tools. In my
direct experience, regardless of the tool used (including Claude, gemini,
etc), the results are NOT reliable in all situations. There's still massive
amounts of hallucinations, missteps, convoluted and unstable code generated.

Yes, in the *right hands* these tools can be a time saver. But to do this
safely you *have* to have a thorough understanding of the code you're
working on. And that doesn't mean just understanding the small piece of the
code that you're feeding into the tool, but rather a wide understanding of
the WHOLE codebase and architecture.

QGIS isn't some little toy hobby project that's appropriate for people to
learn open-source, git, vibe coding, or to build their personal portfolio
from. It's a *professional tool* which is used for real world applications,
and those applications potentially impact projects with million $$ budgets,
or with potential risk to human life and safety. That's not hyperbole --
it's exactly what GIS is for!

So, as a practical way to protect the QGIS application and its users, I
think we could refine our AI policy to be "contributions using AI tools for
development are banned for all non-core contributors".

By wording things this way, we don't explicitly prevent AI driven
development from all contributors. Rather we limit it to the subset of
contributors who we've formally recognised as having an extensive
understanding of QGIS code, architectural design and development practices.
These contributors are those who *do* have the skills required to
critically analyse the output of LLMs and guide them when the results they
give are unsuitable.

I fully admit that this isn't a perfect policy. But I can't think of any
other practical way to differentiate AI developed contributions which HAVE
been critically assessed vs someone just slopping together a fix for their
immediate needs. It would be a ridiculously huge burden and responsibility
on the overworked review team to expect them to do this at review time ?.

Soo.... before I try to propose it as a formal revision to QEP 408, what's
everyones thoughts on this? Does anyone have any alternative policy ideas
to propose?

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260401/27f62cbe/attachment.htm>

From gdt at lexort.com  Tue Mar 31 17:21:33 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 31 Mar 2026 20:21:33 -0400
Subject: [QGIS-Developer] Floating an idea: ban AI based contributed
 from non-core developers?
In-Reply-To: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>
 (Nyall Dawson via's message of "Wed, 1 Apr 2026 09:24:21 +1000")
References: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>
Message-ID: <rmiy0j7r0mq.fsf@s1.lexort.com>

Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> I'd like to float an idea for discussion: that we explicitly block all AI
> based contributions from non-core developers.
>
> I've been giving this a lot of thought, and I personally now think that we
> need to further tighten our AI policy. To be clear upfront, I am not
> approaching this from societal or environmental perspectives, but rather

Well, I'm not happy about RAM and disk prices :-)

> from my own direct experience with using and testing these tools. In my
> direct experience, regardless of the tool used (including Claude, gemini,
> etc), the results are NOT reliable in all situations. There's still massive
> amounts of hallucinations, missteps, convoluted and unstable code generated.

In 1 out of 1 LLM PRs I reviewed (in a project that has the same Free
Software norms, but in a different technical field), the PR was poor
quality.  It turned out to be technically wrong, and it had lots of
wordy but mostly not-really-content commentary.  That's a certified
anecdatum!

> So, as a practical way to protect the QGIS application and its users, I
> think we could refine our AI policy to be "contributions using AI tools for
> development are banned for all non-core contributors".
>
> By wording things this way, we don't explicitly prevent AI driven
> development from all contributors. Rather we limit it to the subset of
> contributors who we've formally recognised as having an extensive
> understanding of QGIS code, architectural design and development practices.
> These contributors are those who *do* have the skills required to
> critically analyse the output of LLMs and guide them when the results they
> give are unsuitable.

I strongly support your proposal as an incremental change.  It will
avoid a lot of LLM submissions, while (assuming for the moment that any
LLM use is ok, ethically, legally, useful on balance etc.) giving room
for understanding/experimenting among people that already have knowledge
and already have human-to-human working relationships.

I remain skeptical of AI/LLM even from core contributors, but I suspect
that will be self-policing or at least on balance (understanding about
policy, benefits of code) worth the cognitive load in review/discussion.

Greg

From even.rouault at spatialys.com  Tue Mar 31 18:28:47 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 1 Apr 2026 03:28:47 +0200
Subject: [QGIS-Developer] Floating an idea: ban AI based contributed
 from non-core developers?
In-Reply-To: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>
References: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>
Message-ID: <a21f6d23-797c-49d9-a104-9ef926537d36@spatialys.com>

Nyall,

As often with that topic, I'm undecided about the best course of action.

For the sake of the discussion, let me play a bit the devil advocate so 
we have counter points to consider:

- restricting AI tool use to core contributors will make the process of 
becoming core contributor harder. Core contributors would be able to 
improve their capabilities further (questionable claim in terms of 
quality. But in quantity&speed, definitely), which will make it harder 
to grow new core contributors.?There's a high chance the new generation 
learning coding today will not be able to produce any working code 
without such tools (like I'm 100% dependent on Valgrind to write working 
non-trivial C++ code).

- besides the issue with new comers to the project, we most certainly 
have regular experienced contributors who haven't the status of core 
contributor, probably because nobody thought about proposing them (btw, 
I've no idea how to determine who is a core contributor and who 
isn't...? is there a public list somewhere ?). Why would they be 
discriminated further?

- I would say that we should restrict your proposal even further: "only 
core contributors are allowed to use AI tools, only in the areas where 
they (feel they) are experts? ", possibly relaxed with "or for 
contributions involving non-production code (e.g. CI scripts (*), 
etc.)". If I use a AI tool in a part of QGIS I've never touched, there's 
a high risk I will produce low quality code with it.

- There's an increased risk that non-core contributors would still use 
AI tools, but without telling us. Naive ones will be easily caught; 
smarter?ones will go under?our detection radar. But is there a 
difference between good/non-perfect/bad code written with or without AI 
assistance that still passes CI and human review...??At the PR unitary 
level, I'd say none.?The issue is more the about the increased volume?of 
bad contributions with AI help that can saturate our review bandwidth.

- Side point: I'm wondering if the nature of the tool would make a 
difference. I haven't personally used AI tools that can operate on a 
whole code base (Claude code and the like), only chat tools that can 
work/produce limited code fragments. I'd suspect the former are the ones 
where you can vibe code an entire feature, whereas with chatty ones, you 
need to iterate much more and thus have hopefully more critical eye. On 
the other hand, maybe tools that operate at the whole code base level 
can have a better global view... Likely none of those approaches is 
fundamentally better than the other one. Different drawbacks.

To me it looks like we are caught in an arm race we haven't decided to 
be part of but can't easily escape.? So, half joking/half serious,?let's 
use AI tools to detect bad AI output ?!? (ignoring who has used the 
tool). I suspect that AI companies would love such outcome...? Or maybe, 
until the AI industry collapses entirely, let's temporarily go back to 
sending patches on 3.5 inches floppy disks (1.44 MB ones only, not 
extended 2.88 MB ones)? through (post) mail.

At the same time I'm writing this, I'm caught in a situation where I'm 
questioning the need for a GDAL PR whose quality isn't necessarily bad 
(I haven't done the in-depth analysis), but which is likely not strictly 
needed (premature optimization/complication), and would have most 
certainly not be submitted at all if AI didn't exist. From my experience 
with recent AI assisted PRs to GDAL, that's actually the main problem. 
Too much code being written in a too short period of time, that will 
make us totally dependent on AI tools to be able to contribute further.

So, all in all, not opposed to your proposal, but we need to be careful 
how we phrase it to not scare away non-core contributors or increase 
unwanted discrimination.

Even

(*) Because I've just played this afternoon with Gemini chat to come up 
with some python clang AST code to write custom code checkers to verify 
project specific code rules (like pairing Reference() in constructor and 
Release() in destructor). The result is .. well... AI typical. Mostly 
sort of works after a couple iterations, but definitely not something 
that would be of the quality that clang-tidy or similar serious tools 
would expect. But good enough for the purpose it was created. Or at 
least I was tricked into believing it was good enough...

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From vincent.ml at oslandia.com  Tue Mar 31 22:38:23 2026
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Wed, 1 Apr 2026 07:38:23 +0200
Subject: [QGIS-Developer] Floating an idea: ban AI based contributed
 from non-core developers?
In-Reply-To: <a21f6d23-797c-49d9-a104-9ef926537d36@spatialys.com>
References: <CAB28Ashf8h+TAQa_cXh=vm1i+Kka+qLd-VE85gAG-WLQfbUzyQ@mail.gmail.com>
 <a21f6d23-797c-49d9-a104-9ef926537d36@spatialys.com>
Message-ID: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com>

Hi,

I second all the wise words from Even. I am particularly worried by the impact it would have on growing our contributor base. QGIS already has a problem with welcoming new contributors, and a policy giving more special rights to core contributors will only make the situation worse. Especially while the rules for core contributors are not really well defined. A retired core contributor could launch an agent to throw slop PRs at QGIS while a recurrent non-core contributor would not even be allowed to review his own code with an LLM ?

I also note that the current situation is bad for our community atmosphere : the "AI slop" label seems really offensive for newcomers if not sustained with explanation and clear rules on expectations. I have recently seen contributors feeling bad after their work has been marked as slop without any discussion and care.

I have already casted my opinion recently, but let me restate it : I personally think we should ban any LLM-generated code entirely from QGIS codebase.

Right now the legal risk is really high, and while there is still no real legal law case which would indicate that we actually have the right to include LLM-generated code as GPL into an OpenSource software as QGIS, each week show new signs that this topic is risky ( supreme court refusing to handle copyright issue, new laws coming for AI legal control in France and Europe, the chardet debacle, new law cases and settlements, wikipedia banning AI-aided contributions?).

We should keep a look at Debian policy. For now they said it was too early for a position, but I guess as for all risks, when in doubt then no doubt.

I would be in favor of having a - at least - temporary ban on AI-generated code for all.

Vincent


On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote:
> Nyall,
>
> As often with that topic, I'm undecided about the best course of action.
>
> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider:
>
> - restricting AI tool use to core contributors will make the process of becoming core contributor harder. Core contributors would be able to improve their capabilities further (questionable claim in terms of quality. But in quantity&speed, definitely), which will make it harder to grow new core contributors.?There's a high chance the new generation learning coding today will not be able to produce any working code without such tools (like I'm 100% dependent on Valgrind to write working non-trivial C++ code).
>
> - besides the issue with new comers to the project, we most certainly have regular experienced contributors who haven't the status of core contributor, probably because nobody thought about proposing them (btw, I've no idea how to determine who is a core contributor and who isn't...? is there a public list somewhere ?). Why would they be discriminated further?
>
> - I would say that we should restrict your proposal even further: "only core contributors are allowed to use AI tools, only in the areas where they (feel they) are experts? ", possibly relaxed with "or for contributions involving non-production code (e.g. CI scripts (*), etc.)". If I use a AI tool in a part of QGIS I've never touched, there's a high risk I will produce low quality code with it.
>
> - There's an increased risk that non-core contributors would still use AI tools, but without telling us. Naive ones will be easily caught; smarter?ones will go under?our detection radar. But is there a difference between good/non-perfect/bad code written with or without AI assistance that still passes CI and human review...??At the PR unitary level, I'd say none.?The issue is more the about the increased volume?of bad contributions with AI help that can saturate our review bandwidth.
>
> - Side point: I'm wondering if the nature of the tool would make a difference. I haven't personally used AI tools that can operate on a whole code base (Claude code and the like), only chat tools that can work/produce limited code fragments. I'd suspect the former are the ones where you can vibe code an entire feature, whereas with chatty ones, you need to iterate much more and thus have hopefully more critical eye. On the other hand, maybe tools that operate at the whole code base level can have a better global view... Likely none of those approaches is fundamentally better than the other one. Different drawbacks.
>
> To me it looks like we are caught in an arm race we haven't decided to be part of but can't easily escape.? So, half joking/half serious,?let's use AI tools to detect bad AI output ?!? (ignoring who has used the tool). I suspect that AI companies would love such outcome...? Or maybe, until the AI industry collapses entirely, let's temporarily go back to sending patches on 3.5 inches floppy disks (1.44 MB ones only, not extended 2.88 MB ones)? through (post) mail.
>
> At the same time I'm writing this, I'm caught in a situation where I'm questioning the need for a GDAL PR whose quality isn't necessarily bad (I haven't done the in-depth analysis), but which is likely not strictly needed (premature optimization/complication), and would have most certainly not be submitted at all if AI didn't exist. From my experience with recent AI assisted PRs to GDAL, that's actually the main problem. Too much code being written in a too short period of time, that will make us totally dependent on AI tools to be able to contribute further.
>
> So, all in all, not opposed to your proposal, but we need to be careful how we phrase it to not scare away non-core contributors or increase unwanted discrimination.
>
> Even
>
> (*) Because I've just played this afternoon with Gemini chat to come up with some python clang AST code to write custom code checkers to verify project specific code rules (like pairing Reference() in constructor and Release() in destructor). The result is .. well... AI typical. Mostly sort of works after a couple iterations, but definitely not something that would be of the quality that clang-tidy or similar serious tools would expect. But good enough for the purpose it was created. Or at least I was tricked into believing it was good enough...
>