[QGIS-Developer] QGIS project maintainability, forms and styles, xml verbosity

[Régis Haubourg via QGIS-Developer]

Hi devs,


I'm trying to maintain a QGIS project
I am hit by some issues that I was already aware of, but this time it is 
way more painful than I faced before.


In short, with the growing qgis features, but also datasets becoming 
larger (more columns) too, QGIS projects are becoming heavier and 
heavier, and require a lot of effort to maintain when trying to ship 
them as part of applications or with datasets.


My dataset has around a dozen of tables, and one has a lot of columns, 
around 200 columns.  I know this is an not optimal data normalization to 
have so many columns. But as datascience grows, shipping gpkg or 
geoParquet files with lots of columns tends to be more frequent.


My main layer has 6 styles and each style has the same form definition 
to make it easy to read those attributes, and offer some 1-n relation 
nested forms (buildings and postal addresses).


## First issue, forms are considered as being a part of each style.

This make the qgs xml replicate 6 times the same form, in my case. It 
makes it very hard to maintain a single source of truth for this form 
also. The idea of having on form per style could be elegant, but it is a 
path full of caveats and I suspect very few of us are using this as a 
feature.


## Second issue, verbosity of the xml

The properties of those forms have grown in time, with many new features 
(default values, data defined fonts etc.. ). This is cool.


However in average day use, most of those settings are left as default 
values, still QGIS will write every property for each column in the 
xml.  Ex: default value, hidden status, LabelonTop, etc.  This is highly 
denormalized and verbose, mostly for unset properties.  It is so much 
denormalized that a simple QGIS xml can weight 18MB and be zipped down 
to 977 KB.



## So I would like to open a debate here about how to handle this.

As for the form being replicated in each style, I would propose to plan 
moving form definition up in the layer definition, not in style 
definition. This will probably imply an API break and retrocompatibility 
issues, so my best guess is that the only time frame to make it happen 
is QGIS 4.



Regarding the xml verbosity, suppose we probably could find solutions:


 - don't write properties that are left untouched or default (which may 
lead to strange behavior when defaults change)
 - don't repeat unuseful informations. ie, layer tree block repeats 
provider and datasource even if it is not used. Confusion appears from 
time to time when user try to save or modify the xml file because of this
 - find a less verbose xml serialization if QT allows this. For 
instance, instead of on xml block per property, why not have on block 
per field. For instance :


```xml

    
    [here dozen of fields]
    
    
    
    [here dozen of fields, again]
    name="adedpe202006_l_ch_gen_princ">

    
```

could be

```xml
```

  ...
   
    editable="1" >

   


```


To be fair, I have no funding at the moment, but I can try to make it 
happen, if we reach a technical consensus here. Any cofunding or grant 
proposal would obviously help here. I'm pretty sure companies editing 
desktop apps using QGIS could find an interest here.  This thread will 
probably raise the question of a new generation project file, but that 
is not my intent ;)


Let me know what you think

Cheers

Régis


[0] qgs available in those open data sets here with a GPKG database 
https://open-data.s3.fr-par.scw.cloud/bdnb_millesime_2023-01-a/millesime_2023-01-a_dep19/open_data_millesime_2023-01-a_dep19_gpkg.zip
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Government CAC PKI Support for web services

[Régis Haubourg via QGIS-Developer]

Hi Greg,
first time I hear about PCKS11 here, maybe just because it is mostly used
and required in the US.
Doing a quick search, it seems the Qt QCA lib supports this protocol, cf.
[0]

My guess, and Alessandro knows more than I do on this front, is that this
needs to be implemented in QGIS, or maybe via a dedicated plugin. I think
that would mean also packaging the qt plugin qt-pkcs11 with your QGIS
install.

Is this a mandatory requirement or optional? If mandatory in your context,
you should probably get in touch with a developper and gather funds to have
this implemented. Maybe others have more informations than I do.

[0]
https://github.com/OpenSC/OpenSC/wiki/Creating-applications-with-smart-card-support/ba9b1848c1ce0dcc5647f8903632713adcd8fd1d#qca

Cheers

Le dim. 28 juil. 2024 à 14:09, Greg Troxel via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> "Catania, Luke A ERDC-RDE-GRL-VA CIV via QGIS-Developer"
>  writes:
>
> > Is there support in QGIS for accessing web services (WFS, WMS, etc)
> requiring a gov't CAC?
>
> Translating this to internet standards terminology from US Government,
> the question is
>
>   Can one configure a WFS etc. in qgis, when the service has a
>   requirement to authenticate using a PCKS11 smartcard?
>
> On POSIX-like systems one would probably use https://pcsclite.apdu.fr/
>
> I suspect this comes down to what library is used for web fetches and if
> there is config support for pkcs11 in it.
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Projected Milestone for Qt6 Official Windows Support?

[Régis Haubourg via QGIS-Developer]

Hi Jeffrey,

Qt6 is being worked on actively. This is a huge project and QGIS.org is 
spending funds, and  volunteer developpers spend also countless hours on 
making this happen.


Be assured that this will happen.

Furhermore, QGIS project also funded some upstream fixes and features in 
Qt6. We definitely want to benefit from them.


Cheers

Régis

On 15/04/2024 17:33, Jeffrey Leifer via QGIS-Developer wrote:

Hi,
Is there a planned release timeline for official Qt6 support? This is 
critical for customers who rely on Qt LTS for bug and security fixes 
(Qt5 is past its EOF for non commercial users and ends for commercial 
users in ~1 year). Many thanks to all the people who have worked 
towards this goal.


/To follow ISTI news and updates please subscribe to our newsletter 
"the isti letter" at https://www.isti.com/newsletter-sign-up 
./



___
QGIS-Developer mailing list
QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Documentation Writer - Report

[Régis Haubourg via QGIS-Developer]

Hi Tim.
I am cooked. You made me want to try NixOs now. :)

Le lun. 8 avr. 2024, 14:03, Tim Sutton  a écrit :

> Hi Regis (and others curious about NixOS)
>
> On Mon, Mar 25, 2024 at 2:28 PM Selma Vidimlic via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hello Régis,
>>
>> Thank you for your response and interest in my transition from Windows to
>> NixOS. The change is indeed significant, but I didn't do it alone. Tim
>> helped me set up the system. The thing is, on my PC where I work every day,
>> Windows started causing problems with constant updates, and after one of
>> the updates, the system failed to boot. I tried everything I knew (it's not
>> the first time this has happened), but it didn't work, so I decided to
>> switch to NixOS. As I mentioned, the change is significant, but for now, I
>> still have access to a laptop that is still on Windows, so I'm combining
>> the two. And Tim is of great help, I wouldn't be able to make this change
>> alone.
>>
>
> Yes, I will give Selma all the support she needs :-). For those curious
> about NixOS as a desktop / day to day productivity environment, yes you can
> 100% use it for this. And you don't need to be a guru to use it. Since
> April 2022 there is a nice graphical installer (
> https://www.phoronix.com/news/NixOS-22.05-Released) and they have
> probably one of the largest repositories of packages of any Linux
> distribution (around 80k packages), including QGIS and QGIS LTR which are
> always current. There are many other popular GIS packages too (see
> https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/gis with
> an active community that maintains them and more are elsewhere in the
> package repo). For novice users, installing a package is no more difficult
> than the equivalent in ubuntu:
>
> apt-get install qgis
>
> becomes
>
> nix-env -i qgis
>
> In fact it is easier since you don't need to set up QGIS 3rd party repo
> first in NixOS.
>
>
> A number of our (Kartoza) team who are not linux gurus use NixOS on their
> desktops - if you ever watched a QGIS Open Day event, it was orchestrated
> by Amy on her NixOS laptop :-P
>
> Have fun!
>
> Regards
>
> Tim
>
>
>
>
>
>>
>> Selma.
>>
>> On Fri, 22 Mar 2024 at 18:09, Régis Haubourg 
>> wrote:
>>
>>> Hi Selma,
>>> As usual we are all a bit silent, there is so much to follow. Your work
>>> is much appreciated. Keep on this way 👍
>>>
>>> About transitionning to NixOs, you talk about your computer for
>>> everyday's work ?
>>> I've never seen NixOs used as a desktop main setup, mainly for getting
>>> reproducible environment as an alternative to docker on servers. Let us
>>> know how it goes, but maybe the jump from windows to Nix is high ?
>>>
>>> Le ven. 22 mars 2024, 15:33, Selma Vidimlic via QGIS-Developer <
>>> qgis-developer@lists.osgeo.org> a écrit :
>>>
 Hello everyone,

 Here is the latest report:

- Organize table - toggle selection

- Insert/Edit expression button - display properties

- Relation Reference


 Additionally, I was focused on transitioning from WindowsOS to NixOS.

 Next week, I will continue documenting the 3.36 features. After that is
 finished, I will move on to the 3.38 features.

 Have a nice weekend,
 Selma.

 On Fri, 1 Mar 2024 at 17:37, Selma Vidimlic  wrote:

> Hello everyone,
>
> Here is the documentation report.
>
> Merged pull requests:
>
>- Identify tool inside the "Working with vector data" chapter
>
>- Identify tool in "Working with raster data" chapter
>
>- Issue #8231 - Container type
>
>- Temporal Controller
>
>
> Still open:
>
>- Style database
>
>
> Working on:
>
>- Identify tool for other data types
>- 3.36 features
>
>
> Have a nice weekend,
> Selma.
>
> On Fri, 16 Feb 2024 at 17:58, Selma Vidimlic 
> wrote:
>
>> Hello everyone,
>>
>> Here is the new report.
>>
>> Pull request that are merged this week:
>> New checkboxes 
>> MSSQL 
>> Field properties
>> 
>>
>> This week, and I will continue next week (point cloud and mesh), I
>> have been working on creating a new section for Identify results dialog 
>> for
>> ind

Re: [QGIS-Developer] [Qgis-user] Announce - migrate our mailing lists to Discourse

[Régis Haubourg via QGIS-Developer]

Hi Greg,
Of course you are free to react !
I'm interested in understanding why you feel this would reduce engagement.
I've been testing Discourse a lot in the past years. From french spaces
around open data and numeric commons, to a first test with QGIS french user
lists.
What I have observed is :
- new users jump in more easily than with our obscure mailing list habits.
- I just don't see any usage difference once I changed my settings from the
default digest setting to "one mail per interaction"
- it is a lot easier to subscribe to a category than to subscribe in
mailman to a new mailing list.
- finding topics via search engine is so much more normal. Remember we
needed Nabble to offer this and it was not an easy experience. And Nabble
died.
- as a list administror, mailman backoffice interface does not make it
easy. It has been designed in the early stages of the web. This is so hard
to understand, read and maintain. And don't try on a phone.

On the downsides, I just had to explore notification settings and
understand how categories work a bit more than I would have expected. But a
lot less time than the numerous hours struggling with mailman admin
interfaces.

So if you have tangible ideas or facts we are really interested.  Discourse
is open source and really full of features, settings or plugins to tune it
to our needs.

Cheers
Régis

Le mer. 3 avr. 2024, 17:34, Greg Troxel via QGIS-User <
qgis-u...@lists.osgeo.org> a écrit :

> Régis Haubourg via QGIS-User  writes:
>
> > With this move, we hope that we can counter the current fragmentation
> > and streamline our discussions. Please fell free to react.
>
> I'm unhappy about this, as I suspect are others who have been in the
> Free Software world a long time.  I expect that this will lead to
> reduced engagement by the longer-term-FS people.  Part of this is that
> tools that encourage post-and-only-see-answers lead to a help desk
> feeling that than a community.
>
> I don't expect to be listened to in any serious way, but you said "feel
> free to react" :-)
> ___
> QGIS-User mailing list
> qgis-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Announce - migrate our mailing lists to Discourse

[Régis Haubourg via QGIS-Developer]

[Message sent to all QGIS's lists. Sorry for crossposting - **please 
reply only in PSC list**  ]



Hi all,

as you may know, we traditionally use mailing lists a lot in QGIS 
project as well as for other OSGEO projects.


All those mailing lists are server by mailman, a venerable piece of code 
written by Richard Stallman. Those mailing lists are hosted by OSGEO 
team (System Administration Committee known as SAC).


Mailman is end of life and all FOSS project are looking to its successor 
, like  GNOME project for instance [0] .


Additionally, mailing lists are not used anymore by younger folks.

Reason for this are numerous, from competition with instant messenger 
tools, the lack of a nice responsive interface, difficulty to search and 
explore mails on the web, or simply because the monopolistic Outlook 
client does not make it easy to use mailing list correctly.


OSGEO team has deployed a Discourse instance, and after 4 months of 
tests with some early adopter -like QGIS-FR list - we think the project 
is mature enough to start discussing about migrating QGIS's main lists.


With this move, we hope that we can counter the current fragmentation 
and streamline our discussions. Please fell free to react.


Any help in this migration move will be more than welcome, from testing 
and spreading the word, to buying a beer after this move ;-)



## What is Discourse ?

Discourse [1]  is an open source only project built to support community 
discussions, started in 2013 and thought to address the gap between 
dying mailing list, forums and the rising instant messenger tools 
dragging all discussions into private and locked-in spaces.


It allows advanced moderation, advanced notification settings, and is 
thought to streamline discussions.


It is already used by tons of community projects, you probably already 
know it, from Gnome to Mozilla.


Want to have a look ? The already migrated lists are there : 
https://discourse.osgeo.org/


## What are the benefits of using Discourse ?

It is searchable on the web, and can be explored lot better than our 
mailman archives.


It is extremely easy to subscribe to a category. No more need to have 
one subscription per list.


Receiving mails and answering from your mail client is fully supported.

You can copy paste images, videos, code and can react via emojis.

There is a basic instant chat, based on matrix. We prefer at this stage 
to use a dedicated channel to avoid confusion. (We are already present 
on IRC and Matrix - see [3] )


## What if I prefer mailing lists ?

Discourse offers options that are very close to mailing lists. See 
Mozilla's tutorial :


https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279

## What calendar and steps for this migration ?

With the System Administration Committee we agreed to  :

- Prepare archive import for a zero downtime migration in June.
- Start with PSC list first, which is smaller
- Announce the  several times for a month we are going to switch, and 
ask everyone to create an account on Discourse via OSGEO LDAP connector. 
Channels will be lists themselves, blog, QGIS desktop feed, and asks for 
communities and user groups to relay in their dedicated channels.

- Do some tutorials about how to handle notifications and advanced options
- Do the switch list per list during june
- Put old mailing list in archive mode with disclaimers.


## What about private lists ?

We currently have private lists like QGIS-voting-members or 
PSC-Private.  We did not tested this yet, but Discourse has options for 
this [2]



Any thought from you is more than welcome, from ranting against 
modernity to thanking SAC for their hard work.


Best regards ,


Régis on behalf of your beloved PSC



[0]https://discourse.gnome.org/t/common-questions-re-mailman-to-discourse/11841 



[1] https://www.discourse.org/

[2] 
https://meta.discourse.org/t/understanding-groups-and-category-permissions-security-settings/87678 



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Documentation Writer - Report

[Régis Haubourg via QGIS-Developer]

Hi Selma,
As usual we are all a bit silent, there is so much to follow. Your work is
much appreciated. Keep on this way 👍

About transitionning to NixOs, you talk about your computer for everyday's
work ?
I've never seen NixOs used as a desktop main setup, mainly for getting
reproducible environment as an alternative to docker on servers. Let us
know how it goes, but maybe the jump from windows to Nix is high ?

Le ven. 22 mars 2024, 15:33, Selma Vidimlic via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hello everyone,
>
> Here is the latest report:
>
>- Organize table - toggle selection
>
>- Insert/Edit expression button - display properties
>
>- Relation Reference
>
>
> Additionally, I was focused on transitioning from WindowsOS to NixOS.
>
> Next week, I will continue documenting the 3.36 features. After that is
> finished, I will move on to the 3.38 features.
>
> Have a nice weekend,
> Selma.
>
> On Fri, 1 Mar 2024 at 17:37, Selma Vidimlic  wrote:
>
>> Hello everyone,
>>
>> Here is the documentation report.
>>
>> Merged pull requests:
>>
>>- Identify tool inside the "Working with vector data" chapter
>>
>>- Identify tool in "Working with raster data" chapter
>>
>>- Issue #8231 - Container type
>>
>>- Temporal Controller
>>
>>
>> Still open:
>>
>>- Style database
>>
>>
>> Working on:
>>
>>- Identify tool for other data types
>>- 3.36 features
>>
>>
>> Have a nice weekend,
>> Selma.
>>
>> On Fri, 16 Feb 2024 at 17:58, Selma Vidimlic  wrote:
>>
>>> Hello everyone,
>>>
>>> Here is the new report.
>>>
>>> Pull request that are merged this week:
>>> New checkboxes 
>>> MSSQL 
>>> Field properties 
>>>
>>> This week, and I will continue next week (point cloud and mesh), I have
>>> been working on creating a new section for Identify results dialog for
>>> individual data formats:
>>> Raster 
>>> Vector 
>>> There were also some updates in Style database
>>> .
>>>
>>> Have a nice weekend,
>>> Selma.
>>> --
>>> Selma Vidimlic Husic
>>> QGIS Documentation Writer
>>> Visit http://kartoza.com to find out about open source:
>>> * Desktop GIS programming services
>>> * Geospatial web development
>>> * GIS Training
>>> * Consulting Services
>>> Phone: +387 61 933 651
>>>
>>
>>
>> --
>> Selma Vidimlic Husic
>> QGIS Documentation Writer
>> Visit http://kartoza.com to find out about open source:
>> * Desktop GIS programming services
>> * Geospatial web development
>> * GIS Training
>> * Consulting Services
>> Phone: +387 61 933 651
>>
>
>
> --
> Selma Vidimlic Husic
> QGIS Documentation Writer
> Visit http://kartoza.com to find out about open source:
> * Desktop GIS programming services
> * Geospatial web development
> * GIS Training
> * Consulting Services
> Phone: +387 61 933 651
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS & field computer and unauthorized DB structure change

[Régis Haubourg via QGIS-Developer]

Hi Mike,

well, this is questionnable. One could just add columns during the 
session and save the table in another provider.


This should probably be only a soft warning and not something blocking 
those features.


Please feel free to open an issue with the tag "feature request". 
Implementation though will not appear by magic (sometimes it does 
though, we have some magic elves), feature are usually funded by users 
having this on their critical path.


Best regards

Régis


On 04/03/2024 16:14, Elstermann, Mike via QGIS-Developer wrote:

Hello everyone,
I have noticed the following: if I have read and write access (DML) to a 
PostgreSQL table, but no access to structure changes (DDL), then I can, for 
example, add new columns with the field calculator and fill them with results. 
Everything seems to run normally, I do not get a warning that I am not allowed 
to change the structure, the results generated in the field calculator are OK. 
After saving, all new columns including the data are gone. Can a corresponding 
preliminary check with warning be added here please?

If a new column is explicitly added, a message appears whose content does not 
match the situation.
"Could not add field 'Test' of type 'text'. Is the field name unique?“
A warning regarding missing authorizations for DB structure changes would be 
better.

As far as I know, there is no QGIS ticket or change 
request(https://github.com/qgis/QGIS/issues) to improve the user guidance for 
these two cases.

There are currently two relevant sections in the error 
messages(https://github.com/qgis/QGIS/blob/master/i18n/qgis_de.ts).

  
 
 Failed to add field '%1' of type '%2'. Is the field name 
unique?
 Could not add field '%1' of type '%2'. Is the field name 
unique?
 
 
 
 Failed to add field '%1' of type '%2'. Is the field name 
unique?
 Could not add field '%1' of type '%2'. Is the field name 
unique?
 

Many thanks in advance.
Mike Elstermann


___
QGIS-Developer mailing list
QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS "prêt" mais ne s'ouvre pas

[Régis Haubourg via QGIS-Developer]

Bonjour Lolita,

pour de l'aide utilisateur, le mieux est d'utiliser la liste qgis-user, 
majoritairement anglophone, ou de basculer sur la section QGIS du forum 
Georezo Francophone.


Bonne journée

Régis

On 01/03/2024 09:21, Lolita Tibeuf via QGIS-Developer wrote:

Bonjour à tous,

J'ai un petit soucis avec QGIS et ce, peu importe la version (3.34.4 
ou encore 3.22.9).


Lorsque je lance l'application (depuis un Windows 11, connectée en 
réseau par un câble ethernet), j'ai la boite de démarrage qui s'ouvre 
jusqu'au message "QGIS prêt", mais celle-ci ne se lance jamais.
J'ai donc forcé l'application à s'ouvrir en l’exécutant en tant 
qu'administrateur.
L'application s'ouvre. Mais je ne peux pas travailler sur mes 
projets/données qui sont stockées sur notre serveur.

L'application ne les trouve pas.

Avez-vous déjà résolu ce type de problème ? Si oui, quelles actions 
permettent de résoudre ça ?


Merci pour votre aide

Bonne journée

--
*TIBEUF Lolita*
+ 33 6 12 36 65 09
lolita.tib...@andromede-ocean.com

ANDROMEDE OCEANOLOGIE 
7 place Cassan, Carnon-plage
34 130 MAUGUIO / FRANCE
Tél: + 33 4 67 66 32 48

___
QGIS-Developer mailing list
QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Qgis 3.34.4 LTR ?

[Régis Haubourg via QGIS-Developer]

We are in the process of building a new website, I think you're right we
should simplify the roadmap page and communicate more on the binary release
date than on source code in our phrasing.

As for external communication, indeed many posts are launched individually
when source code is branched. I hope this is not a race to be the first to
communicate and gather traffic.  I'll raise the issue to the PSC.
Thanks a lot!

Le mar. 27 févr. 2024 à 10:20, Nick Bearman via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Régis, Luca, list,
>
> I think some of the confusion might be over the term of "Release". I read
> this as release of the binaries, i.e. something we can download and install
> from the QGIS website as a user. From what you said Luca, it seems you view
> "Release" as release of the source code before packaging into binaries. Do
> I understand this correctly?
>
> I've always found the Road Map page slightly confusing. Is there space on
> the website for a "simpler" explanation of this process somewhere? Yes, I
> am happy to have a go at writing a first draft!
>
> Also - I think the release process is complicated by OSGeo4W Network
> installer. I used this to install both LTR and current versions of QGIS
> yesterday (26th Feb) and got 3.36.0 (branded as Release Candidate) and
> 3.34.3 (branded at LTR) which I think is a bit ahead of the game.
>
> I think Kurt's post on LinkedIn (
> https://www.linkedin.com/feed/update/urn:li:activity:7167793362815717376/)
> may have also made some people this 3.36 is available when it is not.
>
> Hope this is useful!
>
> Best wishes,
> Nick.
> On 27/02/2024 08:58, Régis Haubourg via QGIS-Developer wrote:
>
> Hi Luca, as always, there is a delay between source code releases events,
> and the packaging can only start, as per
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release
>
> QGIS website indicates that packaging is on its way.
>
> Official communication including the changelog and binaries are on their
> way.
>
> How do you think we could improve our communication to clarify this ? You
> are not the only one asking, so I think we still have work to improve.
>
> Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Good morning,
>>
>> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
>> february, but on the site I see that the latest LTR is still 3.28
>>
>>
>>
>>
>> --
>>
>> Comune di Trento
>>
>> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>>
>> tel. +39 0461.884111 | www.comune.trento.it
>> --
>> *Informativa privacy*
>> I dati contenuti nella presente e-mail sono raccolti e trattati nel
>> rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati possono
>> rivolgersi in qualsiasi momento al Titolare del trattamento, Comune di
>> Trento, per esercitare i diritti previsti dal GDPR. I dati di contatto del
>> RPD e del Titolare oltre che l’informativa completa sono disponibili al
>> link https://www.comune.trento.it/ sotto la voce “Privacy”.
>> Si precisa inoltre che le informazioni contenute nel presente messaggio,
>> e negli eventuali allegati, sono riservate e per uso esclusivo del
>> destinatario. In caso di ricezione dello stesso per errore, siete pregati
>> di informare immediatamente il mittente e di cancellarlo dal vostro
>> archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni
>> trattamento della presente mail che non sia quello del destinatario reale è
>> inteso come non autorizzato dal mittente. Inoltre, in quanto non
>> destinatari reali, Vi informiamo che il mittente si oppone alla copia, la
>> diffusione e la rivelazione anche parziale dei dati in esso contenuti alle
>> persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art.
>> 21 del GDPR.
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@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-develo...@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) 7717745715n...@geospatialtrainingsolutions.co.uk
>
> Please let me kn

Re: [QGIS-Developer] Qgis 3.34.4 LTR ?

[Régis Haubourg via QGIS-Developer]

Hi Luca, as always, there is a delay between source code releases events,
and the packaging can only start, as per
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release

QGIS website indicates that packaging is on its way.

Official communication including the changelog and binaries are on their
way.

How do you think we could improve our communication to clarify this ? You
are not the only one asking, so I think we still have work to improve.

Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Good morning,
>
> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
> february, but on the site I see that the latest LTR is still 3.28
>
>
>
>
> --
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.it
> --
> *Informativa privacy*
> I dati contenuti nella presente e-mail sono raccolti e trattati nel
> rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati possono
> rivolgersi in qualsiasi momento al Titolare del trattamento, Comune di
> Trento, per esercitare i diritti previsti dal GDPR. I dati di contatto del
> RPD e del Titolare oltre che l’informativa completa sono disponibili al
> link https://www.comune.trento.it/ sotto la voce “Privacy”.
> Si precisa inoltre che le informazioni contenute nel presente messaggio, e
> negli eventuali allegati, sono riservate e per uso esclusivo del
> destinatario. In caso di ricezione dello stesso per errore, siete pregati
> di informare immediatamente il mittente e di cancellarlo dal vostro
> archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni
> trattamento della presente mail che non sia quello del destinatario reale è
> inteso come non autorizzato dal mittente. Inoltre, in quanto non
> destinatari reali, Vi informiamo che il mittente si oppone alla copia, la
> diffusione e la rivelazione anche parziale dei dati in esso contenuti alle
> persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art.
> 21 del GDPR.
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin update

[Régis Haubourg via QGIS-Developer]

Hi Zoltán,
unfortunately no, we can't do anything to take over an unmaintained plugin.

Did you try to contact the authoss by other means than github ? They could
decide to transfer the ownership to a more opened user group so that
benevolent people can maintain it.
If they explicitly stop maintaining this plugin, you can try to make a call
for maintainers in the developper's list and try to set up a way to
maintain this, or try to get funds to implement this feature in QGIS core.

regards,
Régis


Le lun. 26 févr. 2024 à 07:08, Zoltán Siki via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Dear Developers,
>
> I have made a pull request one and half year ago to the MapSwipeTool
> plugin, but the developer of the plugin didn't do anything with it. I made
> only a minor change in the code, caused by the change in QLine parameters.
> The latest version of the plugin, available from the plugins.qgis.org
> repo is useless, it fails after activation. Some users react to my pull
> request, that it solves the issue (
> https://github.com/lmotta/mapswipetool_plugin/pulls). This plugin is/was
> popular, more than hundred thousand downloads.
> I don't want to take over the development and the maintenance of this
> plugin, just make the workable version available for the users as a new
> version in the plugin repo. Can it be done somehow without being the owner
> of the plugin?
> --
> Thanks,
> Zoltan Siki
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] GSoC 2024 proposal : QGIS improve the graphical modeler UI and UX

[Régis Haubourg via QGIS-Developer]

Hi Valentin , this is a great proposal and commitment !

The landscape of ETL is changing a lot these days with the end of Talend
open source and the costs explosion of FME.
One component we miss in our graphical modeler is the field mapping tool.
It allows to really quickly remap fields between source and destination
data sources.
This is something you could explore if you start designing new components.
See you in Grenoble !
Régis

Le jeu. 22 févr. 2024, 08:38, Valentin BUIRA via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi qgis developers
>
> My name is Valentin Buira, I'm a french student in urban planning and I'm
> interested in participating in this year Google Summer of Code to improve
> the graphical modeler.
>
> In particular I am interested in improving the user interface(UI) and user
> experience (UX) of the graphical modeler based on my previous experience
> with other node-based applications. If you are familiar with Blender the
> inspiration will be obvious to you but I tried to adapt to the identity and
> features of Qgis like the expression engine.
>
> You can find the proposal at the url :
> https://docs.google.com/document/d/1iXHMTylTHLljfHBITfuIfJzi4_4hpQifEvj5GkM8OCc/edit?usp=sharing
>
> So far I am happy with my proposal but I'm looking for feedback and
> suggestions, and also tips on the technical feasibility and the schedule of
> the proposal.
>
> On a side note, I will be attending the local code sprint in Grenoble the
> 26 mars. Where I will also discuss this proposal in person.
>
> Best regards,
> Valentin Buira
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] Theoretical discussion: A QGIS paid plugin marketplace? (was: sponsored plugin)

[Régis Haubourg via QGIS-Developer]

Hi all,
I have been sleeping over this thread a bit.

We already have a lot of paid plugins and in the psc we try to contact
vendors to have them aware of the GPL licence obligations. This is a lot of
manual work, and this does not scale up obviously.
Offering a marketplace in our plugin management system can be really
interesting, since this would give us a way to explain GPL obligations to
authors and offer them a place to advertise their products a lot better
than letting them deal with their own systems.

That said, the same question for QGIS.org general funding and
sustainability also applies.
We have been having a better fundings this year thanks to marketing efforts
of Marco and Andreas, which allows us to consolidate some tasks, but we
still live on a very low budget compared to the size of the project.

Ideas have been thrown about using existing marketplaces (Windows store for
instance) to collect regular incomes via notarized QGIS installers, but
this is not an easy move given that we don't have permanent staff to handle
with the administrative work this gives.
Developing our own marketplace for plugins could indeed be a way to let
users do a voluntary contribution to the project when buying a plugin, or
even trade a very small percentage on sales to maintain the platform. Most
payment associative tools I know always offer this possibility, I wouldn't
be shocked personaly.

If we keep a mandatory link to a repository in plugin metadata,  where
source code is available, I think we preserve users that can't afford to
pay. We might write down market place terms of use where we ask plugin
authors for fair uses (no ads, no illegal use, security rules etc, no fake
repository that would not really allow users to get the real source code..)

And I agree with Alessandro here, having public sources availables will
still let a large audience to the payment system. QGIS' audience is so
large.

All in all, this kind of system requires more efforts to maintain
everything in place, and I would be in favor of growing up the budgets to
have dedicated persons able to handle this, just like we already manage to
do with documentation and infrastructure management (Thanks Kartozo, Lova
and Selma, you do a great job)

In short, I would be in favor of going this way, but we need to handle this
as it is: grow up QGIS.org core to be able to handle those tasks. And
growing the budget is the first thing missing maybe.

Best regards
Régis


Le ven. 2 févr. 2024 à 02:01, Emma Hain via QGIS-PSC <
qgis-...@lists.osgeo.org> a écrit :

> Hi All
> The economics of this is very interesting.
>
> As a community, we want to give something to our fellow members that they
> need. It allows for our creativity in scratching an itch, and sharing that
> solution. However, we can break the mold and work out a novel way to
> deliver. The open-source pledge North Road uses goes some way to doing
> this. Whilst there a lot of tools are within the licensed (paid) version,
> those tools are available for release once production costs are met. This
> enables the plugin to continue to deliver to those who cannot pay for the
> licensed version, whilst funding further work as technology organically
> develops or additional needs pop-up. Also note that the remuneration funds
> our support for the FOSS4G community, whether via sponsorship or applying
> resources on the committee. So the funding for the plugin gets recycled in
> the community, as well as going someway to providing a living wage.
>
> Shutting out people from the use of desired services should not be what we
> are about - there has to be another way.
>
> In regards to taking over a plugin, this is how FOSS continues, if someone
> is passionate about it, they can ask the creator to take it over. As part
> of the marketplace, the community should also have this as a service, a
> page listing the plugins that are not maintained or won't be maintained and
> is anyone available to take them over. This is a great way for up and
> coming developers to learn the craft from mentors.
>
> Keep the discussion going - this community is so creative that I think we
> will come up with an option.
>
> Cheers
> Em
>
> On Thu, 1 Feb 2024 at 22:33, C Hamilton via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi Nyall,
>>
>> First, thank you for all that you have done over the years. You have
>> helped me a number of times in answering questions. Open source software is
>> an interesting beast. There is so much donated time without compensation
>> yet people need to feed themselves. My first QGIS plugin was in 2016 and I
>> now have 12 QGIS plugins that are published (several more that are
>> unpublished), but I am facing a dilemma. My work has funded all my
>> development except for one plugin which I did for myself. Unfortunately, I
>> was never really able to break into the ESRI culture here and a year or so
>> ago was told to stop doing further QGIS development and to focus on other
>> 

Re: [QGIS-Developer] [FR] Code Sprint avant Rencontres Utilisateurs Francophones de QGIS à Grenoble - 26 mars 2023

[Régis Haubourg via QGIS-Developer]

Hi, very good news Loïc!

I suggest you use the existing wiki to reference the event and let
participants edit it to centralize the information in one place.


Le mar. 12 déc. 2023 à 10:56, Loïc Bartoletti via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Disclaimer: This message is in French as it pertains to a Francophone
> event. However, all "local" and/or interested individuals are welcome to
> join.
>
> Hi Devs,
>
> Salut, les dév' de QGIS,
>
> Je voulais simplement vous informer qu'avant les Rencontres Utilisateurs
> Francophones de QGIS prévues les 27 et 28 mars 2024 à Grenoble (locaux
> de l'Institut d'Urbanisme et de Géographie Alpine), un code sprint aura
> lieu le 26 mars à Grenoble.
>
> Ce sera l'occasion de nous retrouver et collaborer, échanger des idées
> et contribuer à QGIS durant ce temps. Votre participation serait très
> appréciée.
>
> Plus de détails sur l'organisation du code sprint suivront. Tous les
> développeurs intéressés sont invités à se joindre à nous le 26 mars.
>
> Pour des questions logistiques, merci de bien vouloir m'envoyer un
> message pour m'informer de votre participation.
>
> Bien à vous,
>
> Loïc
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Paste geometry functionality

[Régis Haubourg via QGIS-Developer]

Oh I get it now, you want to change in place the geometry of a select 
object. I tend to use spatial SQL myself for this kind of stuff as it 
starts to sound like spatial analysis. You can also use the 
geoprocessing toolbox with the "edit in place" flag. But that would not 
be a manual click and point scenario.


What you describe could find its place in advanced digitizing toolbar 
and edit menu as two actions : - "paste as a geometry part" / "paste and 
replace existing geometry".


This way you could add the new geometry, and remove the old one 
afterwards and in the meantime reconciliate eventually the two geometries.


It is already something quite advanced. If you decide to start 
implementing this, I suggest you write a feature request where you 
describe the behavior of this edit tool and play with advanced editing 
options to see how you want it to behave when you have overlapping 
features, etc...


Another way might be to experiment this as a python plugin as a proof of 
concept.


Thanks for raising this!

Régis


On 29/11/2023 16:14, Tomas Straupis wrote:

2023-11-29, tr, 15:53 Régis Haubourg via QGIS-Developer rašė:

Can you be more precise on your use case scenario ?

   Let's say we have a layer L (PostgreSQL/PostGIS) with features A, B
and C with corresponding attribute values set.
   Now some external party sends us a shapefile S with an updated
geometry G which we want to apply to feature B.

   We want to:
   1. Select G in layer S and press Ctrl+C
   2. Select feature B in layer L (layer is in edit mode).
   3. Do "Paste geometry" which should change geometry of feature B but
leave all attribute values intact. This must be an update (not
delete/insert) operation for record B in database table, as database
would usually have different sequences, triggers with business logic
etc.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Paste geometry functionality

[Régis Haubourg via QGIS-Developer]

Hi Tomas,

copy-paste geometric features is implemented for years now, and copying 
to a spreadsheet or text file also.


There is a setting if you don't want the geometry to be pasted as a WKT 
column in text/ spreadsheet format.


The behavior of attribute forms can also be tuned by options regarding 
the attribute of newly created features


Can you be more precise on your use case scenario ?

Regards

Régis

On 28/11/2023 21:37, Tomas Straupis via QGIS-Developer wrote:

Hello

   I was wondering, is there any reason why "paste geometry" (for
vector features) is not implemented in QGIS? Or is it simply because
nobody implemented it (I'm thinking of trying to do that)?

   The use case is different government cadastres where geometry is
provided by external institutions and institution responsible for
maintaining the cadastre is adding the attribute values. While they
can use full feature paste (with attributes) for initial record
creation, updating requires the possibility to paste geometry only
without changing any attribute values.

   Thank you

P.S. I am aware of a python plugin for that but it does not work for
large geometries as clipboard size limit is reached pretty fast on
windows.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Embedded styling in some datatypes

[Régis Haubourg via QGIS-Developer]

Hi Bo,
Regarding MapInfo, I know the french ministry of environment has tried
something like this years ago.
It was an attempt to handle the transition period between M and Q.

But honestly the style specifications of each proprietary format are really
hard to interoperate. This leads to partially compatible styles, and data
loss.

SLD was a promise to have a common standard but I think all the developers
that tried to implement conversion utilities have been having hard days.
Maybe except for Slyr by Nyall.

Data can be shared across systems. But styles can be shared with very
limited support and this somewhat negates the work of talented
cartographers.



Le jeu. 23 nov. 2023, 11:51, Bo Victor Thomsen via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi list -
>
> I'm wondering about how to use embedded styling in certain types of file
> formats (like MapInfo Tab). I know its possible to read the embedded
> styling from a Tab fil and then convert it to a styling object in QGIS.
>
> However, what about the other direction ? Take a specific QGIS style
> from the layer styling of a tab file, and and write the specific style
> into the feature, so it will be present if you later open the tab file
> in (gasp!) MapIno ?
>
> The use case would be organisations that have a mixed environment of
> QGIS and MapInfo installations. It would allow QGIS users to create and
> update object in a .tab file and save the file. Later this file - if
> opened in MapInfo (or QGIS) - would be shown with the correct embedded
> styling.
>
> --
> Med venlig hilsen / Best regards
>
> Bo Victor Thomsen
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Enhancing QGIS Development and Security Features Proposition

[Régis Haubourg via QGIS-Developer]

Hi Rhea,
Adding some points to the very good answers above.

QGIS is already deployed in very security sensitive organizations and has
been assessed against vulnerabilities. I obviously can't list them publicly
here. Some are public, like the NSA, that even publishes some plugins, but
also funded some parts of the authentication system.

Its desktop component stays however a generic desktop tool, and as such
will be able to interact with the OS it is installed on. Just like blender
or FME or Arcxx that also have python scripting.
I have seen deployment in sanboxes through virtualization tools that can
help too. Like QGIS served through web streaming or as a remote app (
VMware stuff or vnc or similar stuff)

There are several ways of addressing your concerns in QGIS itself.  Most
will rely on creating a specific configuration for your organisation. You
will be able to deploy a preconfigured QGIS that can almost handle all this

 A few examples

- configure QGIS with a dedicated user agent name and have the IT team
filter the trafic they allow using their firewall
- audit the plugins you will use and ship them with your install packages,
or deploy an internal repository
- use the awesome "constrained settings" script funded by a french ministry
to prevent users from drifting away from this configuration
- you can customize the UI so that average user just can't launch the
python console. Any advanced user will be able to circumvent this, but it's
a good start.
-if you are really into security, don't focus on your customer's fears, but
on the real criticity of a GIS infrastructure.  Securing the data source
connections, configuring mandatory encrypted keyrings is often the weakest
part. Python scripting capabilities us present in most software.and must be
secured by the OS and the IT. You can secure QGIS and have user send QGIS
projects by mail with plain text credentials if you don't handle this. This
should fear your customer more than potential python scripts.


Another point. I have seen over constrained QGIS based deployments for
"security reasons" .  They showed  up some side effects:
- user were too constrained, when GIS work supposes to be able to handle
quite complex tools (SQL queries, cli tools, heavy geospatial computing).
They were so locked that they ended up in really trying shadow IT
solutions.
- the configuration work was too heavy and done as a one time project.  the
IT department could not follow the security updates of QGIS and it's
dependencies , leading to severely outdated software in production.
Security is also a matter of being able to update frequently to fix
vulnerabilities, which we offer in every monthly release.


I've conducted a few of such enterprise wide deployment and I confirm you
that you can find professional support in the commercial companies that
provides such services. You can find them listed on our website.
(Disclaimer, I have no direct interest here and speak as a steering
committee member)

Best regards , and let us know how it goes

Régis




Le ven. 3 nov. 2023, 10:11, B. De Mezzo via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Rhea,
>
> same as Johannes "I am in no way able to officially answer but maybe I
> can give some thoughts and rhetoric questions":
>
> * QGIS is not designed to handle such security restrictions, it is not
> its purpose
>
> * the best way, IMHO, is to limit its network accesses by using
> dedicated security software as selinux for linux or advanced firewall
> configuration for windows
>
> * the best to discuss these features is "to create QGIS Enhancement
> Proposals at https://github.com/qgis/QGIS-Enhancement-Proposals/issues.";
>
> Regards.
>
> Le 03/11/2023 à 09:35, Johannes Kröger (WhereGroup) via QGIS-Developer a
> écrit :
> > Hi Rhea,
> >
> > I am in no way able to officially answer but maybe I can give some
> > thoughts and rhetoric questions:
> >
> > To me those improvements sound like good ideas. I am not sure how far
> > you could lock down Python extensibility considering the existing API.
> > And I am not sure if you are aware of the many ways that a QGIS
> > environment might use network calls, e.g. a tool like Proj might
> > download grids from the internet in some cases, GDAL might try to
> > fetch schemas specified in local files, etc. Sandboxing the system
> > from the outside is probably much easier and secure.
> >
> > Are those 40 extensions existing extensions? Are you aware that you
> > can strip out the official repository and use your own instead?
> >
> > It would probably be best to create QGIS Enhancement Proposals at
> > https://github.com/qgis/QGIS-Enhancement-Proposals/issues.
> >
> > And it would be good to proof commitment to maintaining the new
> > features in some way or enter the sustaining membership program with
> > significant, recurring contributions so that other developers paid by
> > the QGIS project can maintain them.
> >
> > Cheers, Hannes
> > ___

Re: [QGIS-Developer] Dropping "render" checkbox from status bar

[Régis Haubourg via QGIS-Developer]

Same here. I use this when playing with huge datasets.
Cheers
Régis

Le dim. 15 oct. 2023, 23:39, Nicolas Cadieux via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi,
>
> Still useful on my side when rendering very heavy stuff and then decide to
> zoom to another part of the map…
>
> Nicolas Cadieux
>
> > Le 15 oct. 2023 à 15:30, Nyall Dawson via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
> >
> > Hi list,
> >
> > Question: are there still any valid use cases for the "render"
> > checkbox in the status bar? It's been around forever, and DID have a
> > strong use case when map rendering used to block the QGIS interface.
> > But is there any reason to keep this around in modern QGIS versions?
> >
> > Nyall
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@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@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FME to QGIS functionality mapping

[Régis Haubourg via QGIS-Developer]

Hi there,
That's good new, especially given the new policy of SAFE software on
licence costs.

On my view, here is the wishlist :

- as stated before, be aware of the datasource structure in a model, with
the ability to refresh it, or read it from a config ressources (file,
database etc..)
- have the magic graphical field autobinder widget. It is a massive
productivity gain having this. Autobind / show un-mapped fields with a
color indicator , replace the match by an expression is 90% of what I used
- have an internal model that is less strict than pure GIS ressources. If
you want to be able to parse JSON / GIS / OSM tags / multigeométry
objectfs, we probably need an internal abstraction that is less constrained
than current WKT + typed table we have currently. I'm not sure if plans are
to go this way, but this is a major feature of FME (except multigeometries
that are not handled)
- Be able to store a cache of object to debug transformers.
- A very strong, clear and readable log. Currently most modeler errors are
just not giving userful informations.
- A graphical tool to drag and drop elements of the modele and enable /
disable them.

All the best !


Le lun. 12 juin 2023 à 10:17, Denis Rouzaud via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi all,
>
> We are currently evaluating work to improve QGIS processing to a closer
> experience to FME.
> There is already some information here from Nyall.
> Our memories are a bit loose, is there any other work done on requirements
> or a wishlist?
>
> Is there any work already started so we don't hijack?
>
> Thanks a lot,
> Denis
>
> Le mar. 7 avr. 2020 à 12:22, Nyall Dawson  a
> écrit :
>
>> On Tue, 7 Apr 2020 at 17:35, Andreas Neumann  wrote:
>> >
>> > Hi Nyall,
>> >
>> > Thank you for sharing this interesting document.
>> >
>> > I have questions and remarks:
>> >
>> > 1. One fundamental difference between FME and QGIS modeler, as far as I
>> > understand it, is the fact that FME data sources are much more tightly
>> > coupled with the model than in QGIS modeler. This has the advantage,
>> > that the data readers, transformers and writers always know what
>> > geometry types and attributes they have. The disadvantage is that it is
>> > harder to exchange data sources with sources that have other attributes.
>> > In my experience the FME approach is what most users prefer. They like
>> > the fact that they can always see at each transformer what attributes
>> > are available at this stage. Would you see an improvement - perhaps
>> > another modeler mode - where also QGIS modeler would be more tightly
>> > coupled with the data sources and that the model and algorithms would
>> > always know at any step what attributes are available at this stage? Or
>> > is this a fundamental difference between the two approaches that
>> > couldn't be bridged?
>>
>> I think it's totally possible -- we just need to know how each
>> algorithm transforms its inputs into an output data set in advance
>> (i.e. the crs, wkb type, and fields).  API which permits this was
>> recently added, but it's not yet hooked into the modeler.  There's
>> still considerable work to do for that, but it's far from impossible!
>>
>> > 2. One aspect where FME shines is the ability to graphically debug
>> > models. One can at every step in the model get the view (map and table)
>> > of the intermediate step. One can also see at each branch in the model
>> > how many features take this route and how many the other route. I know
>> > this doesn't have anything to do with the transformer list you shared,
>> > but this an aspect that I think, many users like about FME.
>>
>> A recent improvement is that after running a model in the designer,
>> you can now see the actual values of inputs and outputs which were
>> used for each child algorithm in the model. It's a partial step
>> towards the FME approach. To get the rest of the way we'd need:
>> 1. to ensure that every algorithm has numeric outputs for the number
>> of features processed
>> 2. ideally to allow the model to run on a background thread inside the
>> designer, so that you'd see these input/output values populate
>> instantly as the model runs (would also allow us to color-code child
>> algorithms by state, e.g. completed/running/pending/skipped).
>>
>> 1. is pretty straightforward, just a lot of grunt work. 2. is more
>> complex (and I suspect only achievable in builds based on qt 5.10+
>> (since we'd need to invoke the child algorithm prepare steps on the
>> main thread)... but its probably time to bump the minimum anyway).
>>
>> Anyway, definitely achievable in the near future.
>>
>> > I agree that there would a lot of "low hanging" fruits and I'm looking
>> > forward to more feature parity between the two. And to the discussion
>> > around it.
>>
>> Me too! When 3.14 is released the model capabilities in QGIS will be
>> much much improved vs previous releases. Just the fact that **every**
>> parameter for child algorithms (i

Re: [QGIS-Developer] Structured list of QGIS versions with flags?

[Régis Haubourg via QGIS-Developer]

Okay, what's your need in the end? Having such a file / webservice could be
discussed for sure. I'm pretty sure an archive page would be nice in QGIS
website.
All the best


Le ven. 26 mai 2023 à 13:23, Julien Moura  a
écrit :

> Hi Régis,
>
> So, the answer is no but good news: the information is publicly available!
> Thanks for your answer and point me to these files :). I was looking to the
> schedule.ics but it's incomplete (no flags).
>
> I'm going to work with it (github tags) and see if I can automatically
> generate a JSON file.
>
> Regards
> Le 26/05/2023 à 12:37, Régis Haubourg a écrit :
>
> Hi Julien,
> not sure if this is the real source of truth, but the git history of this
> file seems pretty structured :
> https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py
>
> OIherwise git tags of main repo may do the trick.
> Ciao
>
>
> Le ven. 26 mai 2023 à 10:58, Julien Moura via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Hello QGIS dev community,
>>
>> Is there a publicly accessible structured file (JSON, CSV, etc.) that
>> lists QGIS versions and their status: deprecated, development, LTR, etc.?
>>
>> Regards,
>> Julien
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Structured list of QGIS versions with flags?

[Régis Haubourg via QGIS-Developer]

Hi Julien,
not sure if this is the real source of truth, but the git history of this
file seems pretty structured :
https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py

OIherwise git tags of main repo may do the trick.
Ciao


Le ven. 26 mai 2023 à 10:58, Julien Moura via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hello QGIS dev community,
>
> Is there a publicly accessible structured file (JSON, CSV, etc.) that
> lists QGIS versions and their status: deprecated, development, LTR, etc.?
>
> Regards,
> Julien
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS QT6 meeting minutes

[Régis Haubourg via QGIS-Developer]

A big +1 for me too !
Régis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS plugin - update rejected

[Régis Haubourg via QGIS-Developer]

Hi Tim,
I can testify Benjamin is legitimate here, as a very well known and famous
figure of geomatics here in France. Go for giving him the plugin's
ownership 😄.
Régis

Le dim. 13 nov. 2022 à 00:33, Tim Sutton via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Benjamin
>
> For the maintainership by multiple people, we should be able to do this by
> setting multiple owners. Normally you should ask the outgoing maintainer to
> do this in the plugin management areas. If they are not available, you can
> always contact me - ideally from the address originally listed in the
> contact details and I can manually add you. If you cant use the original
> address contact AT datagrandest.fr then please provide some other way to
> verify that you are a legitimate manager for the plugin.
>
> Regards
>
> Tim
>
> On Thu, Nov 10, 2022 at 8:47 AM Benjamin Chartier - Pro via QGIS-Developer
>  wrote:
>
>> Hello,
>>
>> I attempted to update a plugin
>> (https://plugins.qgis.org/plugins/datagrandest/ - for which I am one of
>> the maintainers) on the official OSGeo plugin repo using the online form
>> (https://plugins.qgis.org/plugins/add/).
>> This was unsuccessful.
>> I only got the following short message:
>>
>>  You cannot modify this plugin.
>>
>> I suppose this is due to the fact I am not the original uploader of this
>> plugin.
>> arichard is the one who first uploaded the plugin.
>>
>> Is there a way to allow more than one person to upload updates for a
>> plugin?
>>
>> Thank you for your help.
>>
>> --
>> Benjamin
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
>
> --
> ​
>
> Tim Sutton
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
> * GIS Training
> * Consulting Services
> Tim is a member of the QGIS Project Steering Committee
>
> ---
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Revolt Chat Community Server

[Régis Haubourg via QGIS-Developer]

Hi Greg,

On 03/11/2022 01:20, Greg Troxel via QGIS-Developer wrote:

Régis Haubourg via QGIS-Developer
writes:
I think it's really unfortunate that people object to using email, for
reasons that to me border on fashion.

Besides archives, mailinglists have another important point, which is
that the set of subscribers to a list are a community, a group that
makes some effort to belong, and people tend to remain.   I don't see
this with other mechanisms.


Agreed. I think - hoping I am not rewriting history - that Discourse was 
created to address these issues, with keeping the advantages of the 
mailing lists.




I agree about too much traffic.  Between it being easy to type, vs an
expectation of thoughtfulness in email, and people popping into chats,
expecting help, and then leaving, I find it too much and only follow a
few.


Same here.


- we also have issues, Pull requests and potential GitHub discussions
to not forget here :)

We do, but that's proprietary software and relying on it more raises the
cost of leaving.


Clearly, but if we had gitea or a self hosted gitlab, the problem of 
having a good part of the discussions there would be the same, even with 
FOSS versions.



- adding a new communication channel without stating officially which
is the main channel just breaks the single source of truth principle
we had with mailing lists. I have seen recently two feedback from
community users thinking that there was no debate on major topics,
just because the discussion on the mailing list topics stalled. But
those discussions in fact did occur, but spread across those new
channels, and we didn't have enough bandwidth to summarize the
decision on the mailing list (and we also forgot). This is the most
annoying issue.

I think this should be  fixed by declaring the mailinglist to be the
communication method of record.


Discourse is a modern forum, that can act as a chat if you are inline,
or a mailing list, and let users tune their notifications levels
pretty nicely.  Just have a look to the main page, stating the
principles of this tool [0]

This is interesting and I don't have experience with it.  I suspect that
means the kinds of projects I tend to participate in are either
mailinglist culture projects or github only.


  - Discourse as one organized and persistent place, including the
osgeo history discussions. This would be the main communication
channel. I will contact OSGEO to see if the system administration
committee want to go this way for all the osgeo mailing lists.

I am open to considering this if it functions as a non-broken
mailinglist.  That's a tall order, with From: fields correct without
messing up DKIM/DMARC, but maybe there is good enough.


- We choose on main chat tool for instant messaging. Discord or Revolt
could be the choice. I would vote for open source first. So this would
be Element-Matrix or Revolt. Revolt is a bit too much overlapping
Discourse feature to me. Element Matrix is already bridged to IRC and
exists.

I would say that open source, clients and server should be an absolute
requirement, and there should be a very strong bias to federated and
already in use.  And, I'd include "people who avoid Google push services
do not have a second-class experience".
I agree, as long as it doesn't divert too much our workforce from 
focusing on QGIS and that we don't fall into vendor locking traps. But I 
know we have a diversity of opinions in the project.

You say Element Matrix, but I think it's really "Matrix" and people can
use whatever clients they want (and I get it that most use Element).


Yep, sorry for this shortcut. I link both because many non tech don't 
even know about Matrix protocol.




Also, revolt's terms contain:

   You are responsible for maintaining the confidentiality of your account
   and password, including but not limited to the restriction of access to
   your computer and/or account. You agree to accept responsibility for any
   and all activities or actions that occur under your account and/or
   password, whether your password is with our Service or a third-party
   service.

which seems like it is trying to be an indemnification, and it is
clearly unreasonable.  I don't think it's ok for osgeo projects to ask
people to sign contracta with third parties as part of participating.
But, I realize I am likely viewed as an extremist.

That said, revolt's terms (for their site) are less troublesome than
many other centralized services.


Interesting. I had a look at the project info. The idea is really to 
offer a FOSS Discord alternative but the number of contributors is not 
that high (8). and the rationale behind this project is really to fill 
this FOSS alternative gap. When Discourse offers something radically 
different.


All the best and thanks a lot for those constructive thoughts. I'll 
raise this discussion to the next PSC.

Re: [QGIS-Developer] Revolt Chat Community Server

[Régis Haubourg via QGIS-Developer]

Hi Ethan,

thanks for the work with Revolt. I tried it during the developer meeting 
in Firenze, but I did not persist in using it. Let me explain why and 
please excuse me in advance, this is a pretty long mail!


First, before jumping to a tool, I would like that we discuss globally 
the communication challenges that all those new tools bring for all 
online communities - QGIS included.


I experienced the very same situation with mailing list and a spontaneus 
Discord server ( at my paragliding club) and I learned a few things, 
both positive and negative.


# Where are we now ?

- mailing lists are dying. Younger won't jump in. Being at ease suppose 
a good email client and filter rules. And this is a pain. What is really 
unique is that they are indexed by search engine and accessible via 
public archives. We built a knowledge base each time we post a mail. 
Osgeo also offers a central hub where one can't explore existing mailing 
lists, and this was a really nice to me.  Now that Nabble is dead, there 
is no more forum-like web access. And let's not forget that some people 
just don't want to use apps, and would like to stick to mail forever.  
So we can't stay without decision here.


- Chats are fun, but messy, and they break our community in sub parts. 
Telegram / IRC / Element -Matrix / Gitter / Signal / WhatsApp etc...  
Furthermore, there are multiple channels that you can't be aware if 
you're not invited into. This is a serious regression, because 
transparency and public discussion is a key principle of Free software.


- Chats aren't efficient and generate too much traffic. I personnaly 
just don't have enough bandwidth to follow 10% of the channels I should 
follow. And I am pretty involved. Furthermore, each country seems to 
have its preferences on which too to use. I ended up in having 6 apps on 
my phone only for those channels. This is far from ideal. Let's not 
forget that some people will never leave IRC too :) (and some have older 
phones not supporting so many apps).


- Discord / Revolt are organized chats, with topics. They have nice 
apps.  They are still it is some kind of private place if this can't be 
found via a search engine. Maybe Revolt can be indexed?  At one point, I 
think they also start to be messy and require so clear rules for 
category / topics management, and archiving discussions. The Revolt 
instance has too much categories IMO.


- we also have issues, Pull requests and potential GitHub discussions to 
not forget here :)


- adding a new communication channel without stating officially which is 
the main channel just breaks the single source of truth principle we had 
with mailing lists. I have seen recently two feedback from community 
users thinking that there was no debate on major topics, just because 
the discussion on the mailing list topics stalled. But those discussions 
in fact did occur, but spread across those new channels, and we didn't 
have enough bandwidth to summarize the decision on the mailing list (and 
we also forgot). This is the most annoying issue.


- Side note, I didn't have a good user experience with Revolt, the app 
seems still a bit young. But I am pretty sure it will get more mature.


- Last but not least, after discussing this issue in the French OSGeo 
local chapter and with open data groups, I discovered (yet) another 
option, which is Discourse.


Discourse is a modern forum, that can act as a chat if you are inline, 
or a mailing list, and let users tune their notifications levels pretty 
nicely.  Just have a look to the main page, stating the principles of 
this tool [0]


There are tools to migrate mailman history archives to Discourse. Gnome 
project just chose this path recently. [1] (thanks Marco for your 
pointers here)


S, we are all now facing the "too much choice" situation and user's 
confusion.


# How to adress this situation ?

So I would like to propose the following approach, which is basically 
the Gnome's project strategy.


 - Discourse as one organized and persistent place, including the osgeo 
history discussions. This would be the main communication channel. I 
will contact OSGEO to see if the system administration committee want to 
go this way for all the osgeo mailing lists.


- We choose on main chat tool for instant messaging. Discord or Revolt 
could be the choice. I would vote for open source first. So this would 
be Element-Matrix or Revolt. Revolt is a bit too much overlapping 
Discourse feature to me. Element Matrix is already bridged to IRC and 
exists.


- We let community driven channels be impulsed by groups (user groups, 
thematic groups), but let's be clear that it tends to break the 
community and should not be advertised as the official channels


I am sorry if this not goes the way you want, and we are here to debate 
and find a consensus. Adding more channels without removing others is 
confusing for all of us.


All the best

Régis

[0] https://www.discourse.org/

[1] 
https:

Re: [QGIS-Developer] Fwd: [Qgis-user] Latest development version of QGIS as a .msi standalone installer ?

[Régis Haubourg via QGIS-Developer]

Nice, I'll work on this on the train back home on Saturday.
Fabiano did some magic css tricks only web developers know about . That
should be nice :)

Le jeu. 25 août 2022 à 10:00, Matthias Kuhn  a écrit :

> Hi
>
> On Thu, Aug 25, 2022 at 8:50 AM Richard Duivenvoorde via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> On 8/24/22 16:23, Régis Haubourg via QGIS-Developer wrote:
>> > Do you have opinions on such a much ?
>> > (that would require to stress translators so that we don't brake
>> translations for a too long time for such an important landing page )
>>
>> No strong opinion,I just wanted to help someone, who complained that it
>> was not visible that we do not support Windows7 anymore...
>>
>> If you think the google strategy will work: go for it :-)
>>
>
> +1
>
>
>>
>> If you give me a hint when it is merged, I'll update the transifex
>> strings.
>> If you wait until the github-build/action is done, this will not be
>> necessary anymore (I think?)
>>
>
> That is already done and functional.
> Transifex will be updated within 2 hours. If it's not please ping me.
>
> Matthias
>
>
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> [image: https://qfield.org/get/] <https://qfield.org/get/>
> QFIELD 2.0 IS HERE! - Hold the power of QGIS in your hand - learn more
> <https://www.opengis.ch/2022/04/05/qfield-2-0-is-here/> - get it now
> <https://qfield.org/get>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Fwd: [Qgis-user] Latest development version of QGIS as a .msi standalone installer ?

[Régis Haubourg via QGIS-Developer]

Hi guys,
in the same time during the sprint, we started to explore how to declutter
the main download page, which is being work in progress in PR
https://github.com/qgis/QGIS-Website/pull/1037

This would end up in removing all those warnings from the main page. As we
still need these informations, my thought was to add the standalone and
osgeo4w detailed specifications to the "all_download" page.  This way,
users wouldn't see them at first download, but at last it would be indexed
by google and they could find it.

Do you have opinions on such a much ?
(that would require to stress translators so that we don't brake
translations for a too long time for such an important landing page )

Best
Régis

Le mer. 24 août 2022 à 16:07, Jürgen E. Fischer via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Richard,
>
> On Wed, 24. Aug 2022 at 15:47:53 +0200, Richard Duivenvoorde via
> QGIS-Developer wrote:
> > On 8/24/22 15:09, Jürgen E. Fischer via QGIS-Developer wrote:
> > >
> https://github.com/qgis/QGIS-Website/commit/e37bbf2a530f9ad482331d211077e2d5104ad7fd
> > Ok, thanks. used it to add the following note (just below Download for
> Windows, as it is valid for ALL Windows installs):
> > NOTE: You will need Windows 8 or higher (as QGIS needs Python 3.9, and
> Windows 7 is not supported anymore by Python 3.9)
> > Hope this is fine/clear.
>
> LGTM
>
>
> 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 IRC: jef on Libera|OFTC
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Contributor meeting Firenze - last call for accommodation at CX place

[Régis Haubourg via QGIS-Developer]

Done for me.
Thanks a lot to QGIS.org to cover the room expenses, that was unexpected to
me. I should be able to put these charges on my employer's budget and save
some euros to QGIS.org budget if this does not add too much administrative
burden.

See you soon all!
Régis

Le mar. 9 août 2022 à 15:31, Andreas Neumann via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Dear QGIS contributor meeting attendees,
>
> We need to finalize the list of people who want to use the accommodation
> at the CX-place (the venue in Firenze where the contributor meeting takes
> place). QGIS.ORG will pay for these rooms. If you still want to use one
> of the QGIS.ORG paid rooms, please let us know until tomorrow evening.
> After that, we can't take any new reservations.
>
> --
>
> In addition, if you haven't done it yet, please fill in your arrival and
> departure times at the wiki page
> https://github.com/qgis/QGIS/wiki/24th-Contributors-Meeting-in-Firenze,
> so that we can plan the nr of people who want to take part in lunch and
> dinner for the individual meeting days.
>
> Thank you, greetings and looking forward to see you in Firenze,
>
> Andreas
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Is Trello OK for plugins?

[Régis Haubourg via QGIS-Developer]

I would contact them before deapproving, all this is a pedagogy effort for
person not aware of the open collaboration pillars.
I'm sure they will move, maybe not fast. If you can have them participate
in this mail thread, I'll be happy to help .
Best
Régis

Le mer. 6 juil. 2022 à 08:58, Paolo Cavallini  a
écrit :

> Thanks Régis. These were exactly my concerns, but I feared I was missing
> something.
> Should we unapprove it then?
> Cheers.
>
> On 6 July 2022 09:49:36 EEST, "Régis Haubourg" 
> wrote:
> >Hi,
> >One blocker to me is that you need a Trello account to be able to see
> >issues. There is no public version and by consequence no search engine can
> >see those issues.
> >I would kindly ask for a real ticket manager.
> >
> >The git repository is also not being visitable as a web interface. You can
> >clone the code via git https, but it is not possible to do merge requests
> >and collaboration.
> >This is not totally fair game. I would suggest they move to a open repo
> >with code and issues, or make their own plugin repository if they want to
> >stick with their current approach.
> >
> >Bye!
> >
> >Le mer. 6 juil. 2022 à 08:40, Paolo Cavallini via QGIS-Developer <
> >qgis-developer@lists.osgeo.org> a écrit :
> >
> >> Hi all,
> >> I noticed this plugin has a Portuguese description:
> >> https://plugins.qgis.org/plugins/roof_draw/
> >> whereas we recommend to have an EN one, eventually with a translation.
> >> So I went to open a ticket, and I discovered that they use Trello for
> >> this. As I'm not used to this, do we consider it appropriate as a repo
> >> and bugtracker?
> >> Thanks.
> >> --
> >> Paolo Cavallini
> >> www.faunalia.eu - QGIS.org
> >> training, support, development on QGIS, PostGIS and more
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
>
> --
> Please excuse my brevity.
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Is Trello OK for plugins?

[Régis Haubourg via QGIS-Developer]

Hi,
One blocker to me is that you need a Trello account to be able to see
issues. There is no public version and by consequence no search engine can
see those issues.
I would kindly ask for a real ticket manager.

The git repository is also not being visitable as a web interface. You can
clone the code via git https, but it is not possible to do merge requests
and collaboration.
This is not totally fair game. I would suggest they move to a open repo
with code and issues, or make their own plugin repository if they want to
stick with their current approach.

Bye!

Le mer. 6 juil. 2022 à 08:40, Paolo Cavallini via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi all,
> I noticed this plugin has a Portuguese description:
> https://plugins.qgis.org/plugins/roof_draw/
> whereas we recommend to have an EN one, eventually with a translation.
> So I went to open a ticket, and I discovered that they use Trello for
> this. As I'm not used to this, do we consider it appropriate as a repo
> and bugtracker?
> Thanks.
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Feature count for DB provider.

[Régis Haubourg via QGIS-Developer]

Hi Rémy, There had been a lot of work for postGIS and oracle providers. A
count(*) might be really expensive for big tables, so there are options to
use db statistics instead of real count. I bet the loop you point out
occurs only in fallback situations but is not the main case.

One is here for instance by there are numerous PRs like this one
https://github.com/qgis/QGIS/pull/37619

In think @troopa81 has a clear view of the current state.
all the best
Régis

Le sam. 25 juin 2022 à 10:38, Rémi Desgrange via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi,
>
>
>
> Just launched the new QGIS 3.24, and tests the SQL debugger, I just found
> out that the “feature count” does a while loop on all features in the layer
> to count.
>
>
>
> While it’s probably necessary for shapefiles or stuff like that, it
> appears suboptimal for databases access. I found this part in the code that
> looks like to be responsible for the feature counts,
> https://github.com/qgis/QGIS/blob/master/src/core/vector/qgsvectorlayerfeaturecounter.cpp#L76-L90
>
>
>
> Do you think I could make a special case for database-based provider
> (geopackage, postgres/oracle/mysql/etc…) that launch a “SELECT count(*)
> FROM table” instead of looping on all features.
>
>
>
> Thanks.
> ___
> QGIS-Developer mailing list
> QGIS-Developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Improve postgresql network latency by using "pipeline mode" connexion ?

[Régis Haubourg via QGIS-Developer]

Hi all,
The article [0] popped today about the new pipeline mode [1] in postgresql
14 libpq.
This could improve transaction latencies with databases that could be in
slow networks or cloud hosting.
It does not improve all the use cases, but it seems possibly interesting
for editing sessions by reducing round trips between client and server.

Has anyone already explored this ?

Best regards
Régis

[0]
https://www.cybertec-postgresql.com/en/pipeline-mode-better-performance-on-slow-network/
[1] https://www.postgresql.org/docs/14/libpq-pipeline-mode.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer