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>