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
>>>><https://github.com/qgis/QGIS-Documentation/pull/8974>
>>>>- Insert/Edit expression button - display properties
>>>><https://github.com/qgis/QGIS-Documentation/pull/8980>
>>>>- Relation Reference
>>>><https://github.com/qgis/QGIS-Documentation/pull/8972>
>>>>
>>>> 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
>>>>><https://github.com/qgis/QGIS-Documentation/pull/8864>
>>>>>- Identify tool in "Working with raster data" chapter
>>>>><https://github.com/qgis/QGIS-Documentation/pull/8764>
>>>>>- Issue #8231 - Container type
>>>>><https://github.com/qgis/QGIS-Documentation/pull/8907>
>>>>>- Temporal Controller
>>>>><https://github.c

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 know if I can make any adjustmen

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 

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.







//
___
QGIS-Developer mailing

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] 

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

Re: [QGIS-Developer] [Qgis-psc] Nomination of Julien Cabieces for core committer status.

[Régis Haubourg]

I also would give a huge +1 after those years working alongside with
Julien!
Julien is deeply committed in the project and will bring a nice Toulouse
accent in the upcoming hackfests 

Régis


Le jeu. 16 sept. 2021 à 17:23, Alessandro Pasotti  a
écrit :

> Hi PSC & QGIS devs,
>
> I'd like to formally nominate Julien Cabieces (@troopa81) for core
> committer status to QGIS.
>
> Julien has been doing excellent work in several areas of QGIS. His code is
> consistently of excellent quality and his knowledge in various aspects of
> QGIS are an extremely valuable asset to the project.
>
> His history of contributions also demonstrates a clear understanding of
> not only QGIS code practices, but also modern best-practice c++ and Qt
> development.
>
> I think it would be valuable to give Julien core commit rights and allow
> him with this also to enforce the pull request review team.
>
> Thanks for this consideration!
>
> Alessandro
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
___
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] R: Google summer of code: On-the-fly raster calculator

[Régis Haubourg]

Welcome Francesco!!

On 18/05/2021 16:29, Ismail Sunni wrote:
> Good luck and have fun Francesco!
>
> On Tue, May 18, 2021, 16:05 BELGACEM NEDJIMA  > wrote:
>
> Welcome Francesco!
> Looking forward to your contributions 
>
> On Tue, 18 May 2021, 14:37 Francesco Bursi,
> mailto:francesco.bu...@hotmail.it>>
> wrote:
>
> HI to everyone,
>
> I'm Francesco and, as Martin wrote, I'll work on "on-the-fly"
> raster calculator in the next months.
> Thank you for the welcome!
>
> I'm really excited about this project and I'm looking forward
> to getting the best out of this experience and contributing to
> the QGIS project.
> I'm really  grateful and excitedabout this big opportunity and
> I hope to obtain some interesting results and to add some nice
> and useful features.
>
> Best Regards
> Francesco Bursi
> 
> 
> *Da:* QGIS-Developer  > per conto di
> Mathieu Pellerin  >
> *Inviato:* martedì 18 maggio 2021 11:52
> *A:* Martin Dobias  >
> *Cc:* qgis-dev  >
> *Oggetto:* Re: [QGIS-Developer] Google summer of code:
> On-the-fly raster calculator
>  
> Woupidou! Super excited about this.
>
> On Tue, May 18, 2021, 4:50 PM Martin Dobias
> mailto:wonder...@gmail.com>> wrote:
>
> Good news everyone,
>
> this year we will have Francesco Bursi working on his
> summer of code project to introduce on-the-fly raster
> calculator to QGIS! Please join me in welcoming him to our
> amazing community - I hope this will be another successful
> project.
>
> https://summerofcode.withgoogle.com/projects/#5286802463653888
> 
>
> Peter Petrik and myself are officially assigned as
> mentors, but of course we will appreciate if others help
> with mentoring.
>
> In an earlier thread there has been some great feedback on
> the initial proposal. From the feedback it looks like we
> should start by updating the proposal to take a slightly
> different approach than originally envisaged: to create a
> new raster data provider instead of adding a new raster
> renderer.
>
> Regards
> Martin
>
> ___
> 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
> 
>
>
> ___
> 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] A plea: more volunteers needed for reviewing backports

[Régis Haubourg]

Hi all,

I quite agree with Martin here.  That's the only way to avoid the open
source maintainer fatigue syndrom .  As a community member, I think i t
would be fair to have less expenses on Grants and more on the
backgrounnd mandatory tasks like review, packaging and documentation.
And I want to stress out we also need to ensure that at least two
persons can run the tasks, because of this bus-factor thing for sure,
but also because we all deserve vacations sometimes (included looong
ones sometimes)

Best regards

Régis


On 01/05/2021 12:33, Martin Dobias wrote:
> Hi all
>
> On Tue, Mar 23, 2021 at 12:07 AM Nyall Dawson  > wrote:
>
>
> This is a public plea for more developers who are very familiar with
> different parts of the QGIS codebase to become actively involved in
> backport PR management.
>
>
> (Nyall later clarified this is not only about backport PRs, but all
> reviews in general)
>
> Thanks for starting this thread - it is a discussion we definitely
> need to have. (And apologies for getting back to this s late!)
>
> Pull request reviews are absolutely vital part of the QGIS
> development, a chance to get bugs fixed before they even get into QGIS
> code. Quality reviews also need a good amount of expertise of the QGIS
> code - often the hardest part of a review is not the code included is
> the pull request, but figuring out what is missing...
>
> Speaking of myself, I used to review pull requests regularly... But
> after several years I have to admit I mostly gave up doing that unless
> someone asks me to do a review. The pace of QGIS development is not
> getting any slower (which is great!), so there is a constant flow of
> new pull requests and doing code reviews regularly is not something I
> want to do in my free time... I am happy to do some QGIS work in my
> free time, but only doing what I want to do :-)
>
> For a company, strictly business speaking, sparing 15 minutes a day of
> a senior developer is roughly equivalent to lost profit of few
> thousands of EUR (assuming ~50 hours / year). And many reviews need
> much more time than 15 minutes... Moreover companies doing QGIS dev
> are often already donating to QGIS as sustaining members...
>
> In a mail in the thread it was suggested that companies doing QGIS
> development should add extra cost to quotes to accommodate the time
> for reviews (of unrelated pull requests). Not sure I agree with that -
> if a company had constant income from QGIS dev, that's doable, but if
> we are talking about occasional QGIS dev work, that is hard to plan.
>
> From all of that above, my thinking is that in order to make things
> sustainable, regular pull request reviews should be ideally funded by
> QGIS.org similarly to how paid bug-fixing sprints work. It is the kind
> of project maintainance work that needs to be done, it is not always
> super fun and it requires input of someone from a small group of
> people that are already donating lots of their free time.
>
> My proposal would be therefore along these lines:
> - PSC allocates annual budget to reviews
> - core devs interested in participating would indicate their
> availability (eligibility may be the same as with paid bug fixing)
> - PSC tells devs how much paid time they can spend on reviews
> - paid devs should do reviews regularly, e.g. at least twice a week,
> ideally every day - not just once a month or so
> - paid devs would self-assign themselves to PRs and do reviews
> - if a PR is not picked up by anyone e.g. within 3 days, PR queue
> manager would assign it to one of the paid devs
> - paid devs keep track of their time in a spreadsheet and invoice
> (quarterly?) up to the amount they were allocated
>
> I believe this approach should solve our problems:
> - remove stress from growing PR queue and reviewer burnout
> - get more core devs (who otherwise may not be available) to do reviews
> - reduce frustration from devs submitting PRs when their PRs are not
> getting attention
>
> In my humble opinion, good quality reviews are even more important
> than the regular paid bug fixing or grants. A review that is rushed
> due to lack of time may omit important code details, or focus only on
> code style...
>
> We could start with a relatively small budget and compensate the
> extremely valuable work that reviewers (Nyall and others) are already
> doing.
>
> Regards
> Martin
>
>
> ___
> 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 + Cluster PostgreSQL

[Régis Haubourg]

Hi
I have never heard of such a setup and QGIS will not support this our of
the box. You might split qgis project for editors wired on 5432 and read
only projects on 5433. But nothing automatic to switch port when entering
edit mode.

Side question, I don't understand why you would use different ports.
I've used pgpool for replication / load balancing and fail over for years
and it works well. Even if it is often overkill and the reason for more
issues than a single node correctly sized.

I learnt that the simpler the better. And postgres is extremely forgiving,
so you may sometimes question if a cluster is really needed.
Best regards
Régis

Le jeu. 22 avr. 2021 à 20:08, Rebassa Oliver, Joan <
joan.reba...@imi.palma.cat> a écrit :

> Buenas tardes:
>
> Tenemos configurado un cluster de base de datos de PostgreSQL de forma que
> el nodo maestro de este cluster es el que permite las operaciones de
> escritura en base de datos a través del puerto 5432 y el resto de nodos que
> forman el cluster son nodos esclavos a los que se replican los cambios que
> se han hecho en el maestro y asumen las operaciones de lectura en base de
> datos por el puerto 5433, las aplicaciones que han de acceder a las bases
> de datos deben poder tener definidos dos datasources: uno para las
> operaciones de escritura por el puerto 5432 y otro para lectura por el
> puerto 5433, queremos saber si Qgis soporta esta configuración.
>
> Gracias.
>
> Good afternoon:
>
> We have configured a PostgreSQL database cluster so that the master node
> of this cluster is the one that allows database write operations through
> port 5432 and the rest of the nodes are slave nodes, the changes that have
> been made in the master are replicated to the slave nodes and they assume
> the database read operations through port 5433, the applications that have
> to access the databases must have two datasources configured: one for
> database write operations (port 5432) and another for read operartions
> (port 5433), we want to know if Qgis supports this configuration.
>
> 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

Re: [QGIS-Developer] Translation for french

[Régis Haubourg]

Hi Florian,

Can you try reaching the QGIS-community list
https://lists.osgeo.org/mailman/listinfo/qgis-community-team ?

I bet the transifex FR team will ear you there ;- )

Best regards

Régis

On 19/03/2021 19:53, Florian El Ahdab wrote:
> Hello everyone.
>
> I went to transifex and requested to join the QGis Desktop project a
> few days ago to help with the translation to French which is nearly
> complete.
>
> Can anyone validate my request please ?
>
> Regards.
> Florian El-Ahdab.
>
> ___
> 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] Nice to meet you

[Régis Haubourg]

Hi Damiano,
welcome here!

And thanks a lot for taking some time to share who you are.
You will love GIS for sure ;-)

Bye
Régis



Le ven. 26 févr. 2021 à 11:50, Damiano Lombardi  a
écrit :

> Dear QGIS developers,
>
> My name is Damiano Lombardi and since the beginning of February I
> started working for OpenGIS.ch and making some contributions to QGIS. I
> am very exited about working on this amazing project with people from
> all over the world!
>
> In the last eight years I programmed machine vision applications for
> robots in the pharmaceutical industry. I mainly developed using C++ and
> Qt on Windows and embedded Linux platforms. I don't have experience with
> GIS software but I am happy to learn something new!
>
> When not programming I like to go snowboarding on the slopes of my home
> town Airolo in the middle of the alps. The rest of the time I am the
> father of two young children.
>
> Tank you in advance for the work together an kind regards
> Damiano
> ___
> 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] p≡p

[Régis Haubourg]

binrFi7bHKYpV.bin
Description: application/pgp-encrypted


msg.asc
Description: Binary data
___
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 Website down

[Régis Haubourg]

Thanks so much Tim and Richard for having dealt with it !

Régis

Le dim. 8 nov. 2020 à 21:44, Cory Albrecht  a écrit :

> It is online for me, too, except the Ubunut pkg repos don't seem to be
> correct? Both "ubuntu-ltr" and "ubuntu-nightly-ltr" are giving me 3.16
> revision 43b64b13f3  instead
> of 3.10.
>
>
>
>
> On Sun, Nov 8, 2020 at 3:11 PM Tim Sutton  wrote:
>
>> It is online again
>>
>> Regards
>>
>> Tim
>>
>> On Sun, Nov 8, 2020 at 8:01 PM Richard Duivenvoorde 
>> wrote:
>>
>>> On 11/8/20 8:48 PM, Cory Albrecht wrote:
>>> > Hello,
>>> >
>>> > The QGIS.org website has been down since at least 13:30 EST. Does
>>> anybody have any details as to when it will come back online?
>>>
>>> We are busy with it
>>>
>>> https://lists.osgeo.org/pipermail/qgis-psc/2020-November/009131.html
>>>
>>> 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
>>
>>
>>
>> --
>>
>> --
>> ​
>>
>> 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
___
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] WFS-T, postgis and triggers

[Régis Haubourg]

Hi,
Le lun. 2 nov. 2020 à 07:29, Denis Rouzaud  a
écrit :

> But couldn't we just add an option to the layer to re-fetch the data once
> inserted?
>
> I think the layer dependencies options could be adapted to refetch the wfs
data when activated. They are made to refecth the data and refresh the
snapping cache for layer potentially modified on the data provider side.
That would avoir adding yet another option.
___
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] WFS-T, postgis and triggers

[Régis Haubourg]

Hi,
+1 with Denis, this is a quite common scenario, but the caching issue,
combined with the good old WFS-T implementation spatialite provider issues
looked like a big challenge.

I think the future transactional version of WFS3 - OGC APIF should speed up
and simplify a lot the protocol part. On my side, I was just waiting fo it
to happen to raise the topic again.

Concerning the client side caching, I'm not up to date with the potential
spatialite provider enhancement.

Having a reliable and efficient way to edit WFS-T would be really nice. But
as Alessandro points out, our application with a lot of database
intelligence will trigger a lot of data refresh in any case and we will
have then some lags.

Best
Régis






Le jeu. 29 oct. 2020 à 15:11, Denis Rouzaud  a
écrit :

>
>
> Le jeu. 29 oct. 2020 à 15:07, Alessandro Pasotti  a
> écrit :
>
>> On Thu, Oct 29, 2020 at 2:59 PM Denis Rouzaud 
>> wrote:
>> >
>> > Hi all,
>> >
>> > I have a WFS-T layer with a Postgis DB behind it.
>> > On my table, I have an insert trigger (before insert) which sets a
>> field.
>> > When I create a feature on this layer in QGIS, I don't get back the
>> value of this field (I have to refresh the data, by re-opening QGIS for
>> instance).
>> >
>> > Is this expected?
>>
>> Yes. The features are locally cached in a SQLite layer and a newly
>> created feature will be stored locally and not retrieve from the
>> server.
>>
>> > Is there anything we can fix?
>>
>> Of course yes but it would require re-fetching the feature(s) after an
>> insert or an update, I think it will slow things down.
>>
>
> This could be done asynchronously?
> It sounds like a quite common scenario (or not if nobody complained...).
>
> Thanks for the answer anyway.
>
>
>> Besides that there is no perfect solution to server-side changes: if
>> some other user will trigger a data change on the DB we will of course
>> miss it anyway.
>>
>>
>> > Am I doing something wrong?
>>
>> No.
>>
>> Cheers
>>
>>
>> --
>> Alessandro Pasotti
>> QCooperative:  www.qcooperative.net
>> ItOpen:   www.itopen.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] Problem with installation of qgis-server LTR on Ubuntu 20.04

[Régis Haubourg]

Le jeu. 22 oct. 2020 à 11:38, Walter Lorenzetti  a
écrit :

> Thanks guys for the help.
>
> I read the discussion, perhaps it'd be right add this indication into
> server install documentation ?
>
Good idea, we just did this in the Docker instructions at

https://docs.qgis.org/testing/en/docs/server_manual/containerized_deployment.html

I'll propose a PR for the introduction part to mention this.


> W
> Il 22/10/20 11:27, Sebastiaan Couwenberg ha scritto:
>
> On 10/22/20 10:29 AM, Walter Lorenzetti wrote:
>
> Have someone same problems?
>
> This was discussed before:
>
>  https://lists.osgeo.org/pipermail/qgis-developer/2020-May/061276.html
>
> TL;DR, it looks like Canonical did not want to support
> notification-daemon and changed libnotify4 to have gnome-shell as
> preferred dependency.
>
> Kind Regards,
>
> Bas
>
>
> --
>
> Walter Lorenzetti phD
> email: lorenze...@gis3w.it
> skype: aiki74
> twitter:w_lorenzetti 
> g+:aiki74 
> Tel/Cell: (+39) 347-6597931
> Viale Verdi 24 - 51016 Montecatini Terme (PT)
> Nuovi corsi QGIS e GFOSS
> 
> ___
> 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] Problem with installation of qgis-server LTR on Ubuntu 20.04

[Régis Haubourg]

Hi Walter,
I think you need to add the following options to avoid this giant package
pull.

apt-get install --no-install-recommends --no-install-suggest

Le jeu. 22 oct. 2020 à 10:30, Walter Lorenzetti  a
écrit :

> Hi list,
>
> when I try to install 'qgis-server' LTR package on a Ubuntu server 20.04,
> ubuntu pull down also gnome and Server-x!
>
> I look at 'qgis-server' dependances with 'qpt-redepends' but 'gnome'
> doesn't come out.
>
> I just try now with a fresh Ubuntu server 20.04 VM.
>
> Have someone same problems?
>
> Thanks in advance.
>
> W
>
>
> --
>
> Walter Lorenzetti phD
> email: lorenze...@gis3w.it
> skype: aiki74
> twitter:w_lorenzetti 
> g+:aiki74 
> Tel/Cell: (+39) 347-6597931
> Viale Verdi 24 - 51016 Montecatini Terme (PT)
> Nuovi corsi QGIS e GFOSS
> 
> ___
> 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] Heads up on GEOS Overlay New Generation

[Régis Haubourg]

Hi

Le jeu. 17 sept. 2020 à 11:31, Andreas Neumann  a
écrit :

> Hi Régis,
>
> Indeed interesting.
>
> Is there evidence that it will also be faster than previous versions? If
> yes - for certain operations or generally faster?
>
Well not yet, and this will depend a lot on the type of features, vertex
density and so on. I we trust some unit tests, and compare with ESRI on big
datasets (France 4G antennas intersect with municipalities), we could
expect something between twice and four times faster. That's a hope a that
point not a measured fact.

> We had issues in the past with the "Geometry checks" that you could define
> on a layer (Layer Properties --> Digitizing settings) - tests about
> overlays and gaps. It was always slow and not so reliable. Once you tried
> to fix one error you would get even more errors through the fix and then
> you would end up with even more errors when trying to fix the error ...
> Hopefully, this will work better then ...
>
I think this should help indeep.
Bye

> Greetings,
>
> Andreas
>
> On 2020-09-17 09:33, Régis Haubourg wrote:
>
> Hi there,
> I'm forwarding a call [0] from Paul Ramsey and the JTS-GEOS teams.
> I've been following this closely for 3 years now and we have been
> providing testing and test datasets to try to help here.
>
>
>
> In short, GEOS provides most of the geometry computations tools to PostGIS
> QGIS & al. The intersection, difference etc.. (overlay operations) suffered
> from using full numeric precision and lacked snapping and rounding
> operations.
>
> Thus our libraries were slow, and prone to topology errors due to those
> numeric precision issues. Most of us have seen intersections or union
> operations failing from time to time.
>
> The new overlay operation implements snap rounding operations (which is
> implemented in ESRI tools for instance) and will provide fast and robust
> operations.
>
> Now it is available in the 3.9 branch of GEOS.
>
> As QGIS uses GEOS extensively in editing, displaying and algorithms, we
> have to take a look seriously at the positive impacts and potential
> regressions.
>
> Paul warns that they spotted no regression in Z handling, which probably
> means the test coverage is very low in GEOS CI, and we might expect
> regressions on the Z handling here, especially for snapping I bet.
>
> Anyhow this is GREAT news for the OSGEO community because this was one
> major glass ceiling for us. We sometimes had no choice than switching to
> GRASS topological operation to do some very basic operations. Hopefully
> these times are gone :)
>
> And combined with subdividing features, we should gain a massive order of
> magnitude in speed for overlay.
>
> Time to test this big win!
>
> Best regards
>
> Régis
>
> [0]
> https://lists.osgeo.org/pipermail/geos-devel/2020-September/009670.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
>
>
>
___
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] Heads up on GEOS Overlay New Generation

[Régis Haubourg]

Hi there,
I'm forwarding a call [0] from Paul Ramsey and the JTS-GEOS teams.
I've been following this closely for 3 years now and we have been providing
testing and test datasets to try to help here.


In short, GEOS provides most of the geometry computations tools to PostGIS
QGIS & al. The intersection, difference etc.. (overlay operations) suffered
from using full numeric precision and lacked snapping and rounding
operations.

Thus our libraries were slow, and prone to topology errors due to those
numeric precision issues. Most of us have seen intersections or union
operations failing from time to time.

The new overlay operation implements snap rounding operations (which is
implemented in ESRI tools for instance) and will provide fast and robust
operations.

Now it is available in the 3.9 branch of GEOS.

As QGIS uses GEOS extensively in editing, displaying and algorithms, we
have to take a look seriously at the positive impacts and potential
regressions.

Paul warns that they spotted no regression in Z handling, which probably
means the test coverage is very low in GEOS CI, and we might expect
regressions on the Z handling here, especially for snapping I bet.

Anyhow this is GREAT news for the OSGEO community because this was one
major glass ceiling for us. We sometimes had no choice than switching to
GRASS topological operation to do some very basic operations. Hopefully
these times are gone :)

And combined with subdividing features, we should gain a massive order of
magnitude in speed for overlay.

Time to test this big win!

Best regards

Régis

[0] https://lists.osgeo.org/pipermail/geos-devel/2020-September/009670.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

Re: [QGIS-Developer] bug or feature? layer_styles table created not in the public schema

[Régis Haubourg]

Hi,
I'm my opinion, we should add a dialog to let the user choose the
destination schema. Public schema should really be left untouched by
default.
Cheers
Regis

Le dim. 6 sept. 2020 à 18:26, Giovanni Manghi  a
écrit :

> Hi all,
>
> On Sat, Sep 5, 2020 at 11:05 PM Paolo Cavallini 
> wrote:
> >
> > This follows the search_path setting.
>
> oh I see. Anyway this case seems possible (even if uncommon), and when
> it happens it leads a user to being cut off from accessing styles
> stored in public.
> So my question stands, should this be considered a bug (considered
> that the QGIS does not allows to choose the schema where to look for
> styles)?
>
> -- G --
> ___
> 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] focal eoan on https://qgis.org/ubuntugis-ltr/dists/ ?

[Régis Haubourg]

Thanks Sebastiaan,
this makes sense indeed, given that GDAL is already 3.0.2 on focal. Sorry
for the noise!

Régis

Le mar. 18 août 2020 à 10:41, Sebastiaan Couwenberg  a
écrit :

> On 8/18/20 10:31 AM, Régis Haubourg wrote:
> > Having a look to
> > http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu/dists/ they
> > seem to support also focal.
>
> Note that only grass is currently available for focal in the
> ubuntugis-unstable PPA:
>
>
> https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+packages?field.status_filter=published_filter=focal
>
> > How could we have our builds supporting focal with ubuntugis
> dependencies?
>
> That added value of focal builds with UbuntuGIS dependencies is very
> little at time of writing.
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> ___
> 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] focal eoan on https://qgis.org/ubuntugis-ltr/dists/ ?

[Régis Haubourg]

Hi Denis,
wait, I miss something, probably due to too long vacations :).
  https://qgis.org/ubuntu/dists/ <https://qgis.org/ubuntu-ltr/dists/> is
for release version right? That's what our website indicates. I would like
to have ubuntugis for LTR (current 3.10).


Le mar. 18 août 2020 à 10:36, Denis Rouzaud  a
écrit :

> The PPAs were renamed:
> https://qgis.org/ubuntu-ltr/dists/
> https://qgis.org/ubuntu/dists/ <https://qgis.org/ubuntu-ltr/dists/>
>
> Focal is here :)
>
> Le mar. 18 août 2020 à 10:32, Régis Haubourg  a
> écrit :
>
>> Hi all, (Hi Jürgen),
>>
>> I'm looking at the ubuntugis builds for ubuntu/ debian. Currently we only
>> have builds for the following
>>
>>
>>- bionic
>>- precise
>>- trusty
>>- xenial
>>
>> They look a bit old especially regarding Qt versions.
>>
>> Having a look to
>> http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu/dists/ they
>> seem to support also focal.
>> How could we have our builds supporting focal with ubuntugis
>> dependencies?
>>
>> Best regards
>>
>> 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
>
>
___
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] focal eoan on https://qgis.org/ubuntugis-ltr/dists/ ?

[Régis Haubourg]

Hi all, (Hi Jürgen),

I'm looking at the ubuntugis builds for ubuntu/ debian. Currently we only
have builds for the following


   - bionic
   - precise
   - trusty
   - xenial

They look a bit old especially regarding Qt versions.

Having a look to
http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu/dists/ they
seem to support also focal.
How could we have our builds supporting focal with ubuntugis dependencies?

Best regards

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] SVG icons in QGIS

[Régis Haubourg]

Hi,
I think we should better follow the standard for internationalizing instead
of progressively making a proprietary format.
See https://www.w3.org/TR/SVGTiny12/i18n.html
Cheers!

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a
écrit :

> Hi all,
>
> I am only loosely following this discussion.
>
> But about the internationalization: couldn't we use the same param -
> mechanism we already have for fill-color, stroke-color, opacity, etc. and
> extend it to the content of  elements?
>
> That would solve internationalization and would also be usefuly for
> dynamic text in icons anyway - there might be some use cases for this even
> without internationalization.
>
> Just an idea,
>
> Andreas
>
> On 2020-07-28 02:39, Nyall Dawson wrote:
>
> On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
>  wrote:
>
>
> Hi List,
>
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time.
>
>
> For reference: I'm totally in agreement that we need to improve the
> DEFAULT set of svg files, and that the resource sharing plugin isn't
> the best solution here. It's a great solution for some use cases, but
> we need to improve the out-of-the-box experience in this regard and
> that means extending the default set.
>
> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?)
>
>
> Yes -- we CAN'T do this. What we've got now has to stay, in its
> current structure, and without renaming.
>
> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories.
>
>
> We could potentially add tags to the svg files themselves to add this
> information.
>
> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised.
>
>
> Big +1 to this. Especially if we also add search by tag support!
>
> * Clean up the current symbols by removing duplicates.
>
>
> Again, we can't do this without risking breaking people's existing
> projects (which is off-limits!)
>
> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
>
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
>
> Thoughts?
>
>
> Sounds good to me! To clarify -- are you volunteering to lead this effort?
>
> Nyall
>
>
> Cheers,
> Jonathan
>
>
> ___
> 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
___
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 server logs

[Régis Haubourg]

Thanks Sylvain,

I tried -v /usr/bin/xdg-open:/usr/bin/xdg-open:ro with no success.

Bye

Le mer. 8 juil. 2020 à 14:26, Sylvain POULAIN 
a écrit :

> @Regis,
>
> For xdg open and docker, just map your X11 running session inside docker
> container and export DISPLAY like this :
>
> -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY
>
> It works with docker mundialis qgis 2. If not sufficient, you could map
> xdg-open to container :
>
> -v /usr/bin/xdg-open:/usr/bin/xdg-open:ro
>
>
> Why is it declared on the server version ?
>
>
> *Sylvain *
> <http://giscan.com>
>
>
> Le mer. 8 juil. 2020 à 12:19, Paolo Cavallini  a
> écrit :
>
>> Hi again,
>> on the same server I'm getting frequent:
>>
>> [Wed Jul 08 10:15:21.847370 2020] [fcgid:warn] [pid 23438] [client
>> 127.0.0.1:37450] mod_fcgid: error reading data, FastCGI server closed
>> connection
>> [Wed Jul 08 10:15:21.847989 2020] [core:error] [pid 23438] [client
>> 127.0.0.1:37450] End of script output before headers: qgis_mapserv.fcgi
>>
>> could this simply due to lack of resources (only 4Gb RAM) or there are
>> other explanations?
>> Cheers.
>>
>> Il 06/07/20 20:16, Régis Haubourg ha scritto:
>> > Hi Paolo, I have those messages too when running QGIS desktop from a
>> > docker. Xdg-runtime is used to open default app for files or urls on the
>> > system. I think this has no impact on a server use case.
>> > But I wish I could forward this xdg commands to my host so that I can
>> > open help pages from QGIS in a docker :). If someone knows some magic
>> > here please share !
>> > Cheers
>> > Régis
>> >
>> > Le lun. 6 juil. 2020 à 18:29, Paolo Cavallini > > <mailto:cavall...@faunalia.it>> a écrit :
>> >
>> > Hi all,
>> > I'm getting some messages from the log file I do'nt understand[0]
>> > I couldn't find an explanation in the manual. Does anybody have some
>> > hints?
>> > Thanks in advance.
>> > ---
>> > [0]
>> > Application path not initialized
>> > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
>> > '/tmp/runtime-www-data'
>> > ...
>> > QNetworkDiskCache::prepare() unable to open temporary file
>> >
>> > --
>> > Paolo Cavallini
>> > www.faunalia.eu <http://www.faunalia.eu> - QGIS.org
>> > training, support, development on QGIS, PostGIS and more
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org > QGIS-Developer@lists.osgeo.org>
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>>
>> --
>> 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
___
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 Server Developer Meeting - Thursday 2 July 2020 - 14:00-16:00 (UTC+2)

[Régis Haubourg]

Hi Alessandro,
Thanks a lot for setting this up. I'll be there !

Just a side note, jitsi often fails with peer <> peer strange connexions
issues. Zoom is more reliable, but we also start using Big Blue Button as
an open source alternative. It works nicely when hosted with enough
resources. This instance proves to be efficient enough for trainings:
https://ensemble-bbb.scaleway.com/




Le jeu. 25 juin 2020 à 10:00, Alessandro Pasotti  a
écrit :

> Hi,
>
> As a follow up of the recent discussion about QGIS Server market
> share we have organized a kick start meeting to discuss QGIS Server
> Development.
>
> Thursday 2 July 2020 - 14:00-16:00  (UTC+2) on
> https://meet.jit.si/qgis-server-developer-meeting-2020
>
> (but be ready to jump on Zoom kindly offered by Jorge Gustavo Rocha if
> we have any connection issue)
>
> The meeting scope is to define where we want to go with the server, in
> other words define
> our long term strategy and goals for server development.
>
> A single meeting won't probably be enough, so (also depending on how
> many people will join the works) we could split topics and create
> smaller workgroups if needed, then collect the findings in future
> meetings.
>
> IMO this is a list of the main topics that we should address:
>
> 1. define the QGIS server project goals: what kind of product we want
> to develop (we might well decide that what we currently have is all we
> need)
> 2. discuss the "market share" and the "competitors" and what QGIS Server
> lacks
>
> I started a shared online doc with a proposal for the agenda, feel
> free to edit but please let's stay focused on the big picture for the
> time being, we can discuss implementation details later:
> https://annuel2.framapad.org/p/qgis-server-meeting-2020-agenda-9he7?lang=en
>
> Kind regards.
>
> PS: many thanks to Paul Blottiere for helping with setting this up!
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.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] QGIS for Apple: Intel vs. arm

[Régis Haubourg]

Hi Andreas,
I'm also worried about this move.

But one way to forward the cost to Apple is now to stop buying macs.
Sorry to troll, but the vendor lockin' nightmare they are building is not
of the same nature as of the powerpc era.
I sold mine because they stopped to support it though it worked very well
on the hardware side. And switching to linux on Mac is made hard on
purpose.. > never again for me, even if they do really good stuff.
I found in LENOVO some durable hardware, easy to repair, hardware that
works nicely and avoid me to trash a working computer.
Best
Régis


Le mer. 24 juin 2020 à 11:11, Andreas Neumann  a
écrit :

> Hi all, esp. Peter,
>
> So I wonder what the new announcement of Apple switching everything from
> Intel to arm architecture will mean for our project? According to Apple
> they will switch all of their devices to arm over the next 2 years.
>
> Will it be a lot of work to adapt the build system to the new processor
> architecture? It will probably mean that we will need an additional Mac
> build server for arm architecture in our infrastructure and will have to
> provide packages for both systems for many years to come ...
>
> Not so nice for us as a project - can we forward these costs to Apple for
> that move?
>
> Greetings,
> 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] QGIS Server and the Grants programme

[Régis Haubourg]

Hi,
I can't agree more with Andreas.

Just note that we have major companies betting on QGIS server for
production use and considering switching from Geoserver to QGIS server to
get rid of the double administration task burden.
They fund progressively what is missing and QGIS.org helps sometimes for
OGC certification testing and documentation but the majority of the fund
are not made by QGIS.org

So yes, we have open ecosystems, I don't get the point of trying to cut
(small) funds on a solution that is useful, supported by users and funders.

Best regards
Régis


Le mar. 9 juin 2020 à 11:12, Andreas Neumann  a écrit :

> Hi Jonathan,
>
> Rest assured - the majority of QGIS funds is already (and has always been
> going) into bug fixing. Again - both Desktop and server users benefit from
> that bug fixing.
>
> We publish our financial reports here:
> https://www.qgis.org/en/site/getinvolved/governance/finance/index.html
>
> If you look into the 2019 report, you can see that around 50% of our funds
> go into bug fixing and quality assurance (in some years even more). Only
> about 10% of our funds went into the grants in 2019. And from these grants,
> server received a small fraction. So, the absolute amounts of investments
> that QGIS.ORG invests into QGIS sever is really negligible.
>
> Most investments done in QGIS server go directly from clients to QGIS
> development companies - and that has nothing to do with QGIS.ORG
>
> If you talk about the number of users of a server installation - I think
> this is debateable: if you only count the admin of a server (regardless of
> which server), then the numbers are low - no matter if we talk about ArcGIS
> server, Geoserver, UMN, QGIS, etc. But every server easily has a hundred or
> sometimes several thousand users who use these services - don't you think.
> If I look at our small province - we have maybe 100 QGIS desktop users, but
> certainly several thousand users who use our Web-GIS and OGC services -
> don't you agree? And our services integrate with a lot of other
> applications that are vital to a province level government. So in this
> perspective, (QGIS)-server installations need to be multiplied with some
> factor to compare it with QGIS desktop user numbers.
>
> Andreas
>
> On 2020-06-09 10:38, Jonathan Moules wrote:
>
> Hi Andreas, (& All),
> A fair point, but I believe this is an important point and this year I do
> have data to back up my point; in fact the grant program is what motivated
> me to finally get around to doing this analysis.
>
> It seems from the replies that while there are a few differentiators, the
> key one is indeed cartography and styling. (There's also an interesting
> conversation about vectors going on there too). Some thoughts:
> * The vast majority of WMS/WMTS layers are not cartographically
> complicated, let alone beautiful. They're "here is a layer with small green
> points for trees", and "this polygon represents conservation areas". You
> can easily play around and see what's out there here:
> http://www.geoseer.net/api-demo/
> * WFS/WCS can't be styled server side.
> * It seems like overkill to create and maintain an entire server
> distribution that fundamentally only solves one (relatively simple compared
> to what QGIS Desktop can do) problem.
> * Rendering is only one part the QGIS package (Analysis, digitisation,
> management, etc.).
>
> If I'm honest, the "competition" on this point isn't really between QGIS
> and MapServer/GeoServer. It's really between QGIS and ArcGIS. Because
> ArcGIS does exactly what QGIS Server seeks to do: offer a single integrated
> solution for Desktop-> Server. And certainly ArcGIS Server does have a huge
> number of deployments (53%), however again, there really aren't many
> cartographically complicated outputs on there. And despite the huge number
> of deployments, most services and datasets are actually served by
> MapServer/GeoServer (about 60% of datasets between them!). Basically ArcGIS
> is deployed by local government and used for bitty-stuff ("here are our
> fire stations"), but if you want a real data-service then you go with
> GeoServer/MapServer/etc.
>
> Most importantly though, I think I haven't conveyed my core point well:
> this really is a zero sum game!
> Even allowing for the above, any funds spent on QGIS Server are not spent
> on QGIS Desktop. There are 60 public facing QGIS Server deployments. Even
> assuming that there's a ratio of 10:1 for private/public servers (made up
> ratio, feels too high), any funding on QGIS Server benefits only hundreds,
> or being very generous, maybe low-thousands number of users. Funding on
> QGIS Desktop however benefits as a *minimum* tens of thousands, potentially
> millions of users (no idea how many QGIS installs there are, I can't find
> the download-stats I remember seeing in the past).
> Heck, even pretending for a second QGIS Server had 100% of the deployments
> (a 100 fold increase!), there would /still/ be orders of 

Re: [QGIS-Developer] gdal 3.1 in OSGeo4W/QGIS 3.14?

[Régis Haubourg]

Hi,

Le mar. 26 mai 2020 à 18:21, Jürgen E. Fischer  a écrit :

> Hi,
>
> On Mon, 25. May 2020 at 17:34:14 +0300, Idan Miara wrote:
> > I can't find gdal 3.1 in OSGeo4W, but only gdal 3.04 and 3.2 (gdal-dev).
> > QGIS master depends on gdal-dev (3.2), but since QGIS 3.14 supposed to be
> > released in less then a month, won't it make sense to test it against
> gdal
> > 3.1 as gdal 3.2 won't be released before QGIS 3.14?
>
> And what about PROJ7?
>
> See also
> https://lists.osgeo.org/pipermail/qgis-developer/2020-February/060259.html
>
>
according to the bug tracker, the mentionned bug has been fixed.
@Nyall Dawson  do you know about any other blocker
on PROJ side that would justify to stick with 6.x versions in OSGEO4W?

Best regards
Régis


>
> 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)  GermanyIRC: jef on FreeNode
> ___
> 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] Profiler?

[Régis Haubourg]

Le sam. 23 mai 2020 à 00:42, Nyall Dawson  a écrit :

> On Fri, 22 May 2020 at 20:01, Richard Duivenvoorde 
> wrote:
> [..]
> > I do have an issue with long startup times on Windows at a client
> > working with a cytrix setup (though I guess it is a general
> > python/startup issue there),
>
> This is EXACTLY the kind of issue this was added for! I also see
> occasional 5 minute+ startup times on Windows (bare metal installs)
> and would like to get this resolved for 3.14. (It's a bad experience
> for users, and when things are working correctly QGIS should startup
> in a couple of seconds at most. Our (usual) speedy startup is
> something which differentiates us from a certain other desktop GIS
> application ;)
>
>
Hi, this is great!

I reopened this very long standing issue (5 years) of windows slow startup
phenomenon: https://github.com/qgis/QGIS/issues/20061

regards
Régis



> >
> > 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
> ___
> 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 / FreeCAD interoperability...

[Régis Haubourg]

Hi Joel,

Just a note on the QGIS-CAD-BIM "converging" roadmap everyone dreams about.
What we see here is that many organisation up to now where using CAD
software to manage city maps and assets management, where GIS - as a true
database system - is far more accurate.
We even see public entity allowing public grant only if data are
transmitted in GIS exchange format in the end. So we see many CAD users
switching to GIS - wether they like it or not.

As a consequence, and thanks to funders who understand that free software
allows to be active contributors, QGIS as a project is influenced a lot by
CAD needs, at least for 2D editing.
We have some construction tools allowing to play with angles, parallels,
build some inference temporary lines, and a lot of new shape editing tools.
We still miss a lot of what user require, such as interactive snapping for
instance or advanced 3D computation libraries. We also reach a point where
geospatial standards draw a line with CAD world, for instance handling
spline curves is at the limits.

Concerning 3D and BIM buzz, we have a lot of questions from users, and
sometimes even from national mapping agencies. And up to now, 3D plans for
QGIS are focused on viewing datasets mainly.
We miss a lot 3D editing capabilities and FreeCAD is in my opinion the best
candidate to provide an open source solution for this.

The first bridge would be to ensure that FreeCAD deals with the main
interchange standards to be able to edit BIM data. That would probably be
cityGML and all the standards supported by the OGC, plus the main de facto
standards like STL. I think we already have a challenge here to deals with
those large datasets in reading and editing.

FreeCad being able to edit those, we could already answer to the 100% open
source BIM use case. Then an interoperability at API level between FreeCad
and QGIS to easily open a dataset or a specific feature in QGIS<>Freecad
would rock!
I would love as a user be able to view my city in 2D or 3D with QGIS, click
on a building, open it in FreeCAD, update it, go back to QGIS, refresh,
done.

Hope it helps

Best regards




Le dim. 10 mai 2020 à 23:24, Luigi Pirelli  a écrit :

> Hi Joel
>
> Since years ago a lot of new features can support a better integration. I
> did a rough investigation about integration and stopped due to the fact
> that data model were (or is) too different to imagine an integration.
> BTW probably now is more simple (at least from the qgis point of view)
> thanks to the possibility to bridge different data models using a python
> data provider [1] [2].
> I would give a try/look.
>
> cheers
>
> Luigi Pirelli
>
> [1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/122
> [2] https://www.itopen.it/qgis-vector-data-provider-python/
>
>
> **
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Book: Mastering QGIS3 - 3rd Edition
> 
> * Hire a team: http://www.qcooperative.net
>
> **
>
>
> On Sat, 9 May 2020 at 05:26, Joel Graff  wrote:
>
>> I've been a part of the FreeCAD project for the last three years or so,
>> focusing on developing Civil Engineering-related functions (specifically,
>> transportation engineering).  On occasion, discussions emerge regarding GIS
>> integration into FreeCAD, QGIS being the natural go-to.
>>
>> Recently, the GIS thread on the FreeCAD forum pointed to a github issue
>> on the QGIS repo about FreeCAD integration.  It was closed in late April,
>> citing the developer's mailing list as the place to continue the discussion.
>>
>> I cite the URL below as it contains links to relevant threads on the
>> FreeCAD forum:
>>
>> https://github.com/qgis/QGIS/issues/21623
>>
>> The issue was five years old and not much discussion has happened.
>> Admittedly, I think it's one of those "seems like a good idea, but what can
>> we really do with it?" kind of things.
>>
>> I'm not really posting here to start a discussion on any particular topic
>> or advocate for any sort of development effort.  I'm merely bringing it to
>> the developer mailing list to give it the proper exposure.
>>
>> That said, I should also mention that I and one other transportation
>> engineering professional are actively working on developing transportation
>> engineering tools for FreeCAD, specifically geomatic (survey) and highway
>> alignment design tools at the moment.
>>
>> *Joel Graff, P.E.*
>>
>> *LinkedIn:* https://www.linkedin.com/in/joelcgraff
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: 

Re: [QGIS-Developer] Exe size mismatch

[Régis Haubourg]

Hi,
qgis.exe and qgis-bin.exe are not the same beasts. Qgis.exe is a wrapper
for the real exe file, passing additional .var values to the exe.
IIRC it was done by Nathan to allow QGIS to be pinned in Windows taskbar
correctly.

Please correct me if I am wrong

Le lun. 4 mai 2020 à 14:12, Sachin Kumar  a écrit :

> I have compiled on MSVC 2015, Windows 10. Till compile and install as in
> C:/OSGeo4w/apps/qgis-test and run successful from cmd prompt.
>
> When I tried to package it using perl creatensis.pl, it gives error
> qgis_app.dll
>
> Error loading QGIS
> Oops, looks like an error loading QGIS
> Details:
> Could not load qgis_app.dll
> Windows Error: The specified module could not be found.
> Help:
> Check C:\Program Files\QGIS 3.12\bin\qgis-bin.env for correct environment
> paths
>
> What could be wrong?
>
> Regards
> Sachin
>
> On Mon 4 May, 2020, 3:21 PM Andreas Neumann,  wrote:
>
>> Hi Sachin,
>>
>> You probably used different compile options and then it would be logical
>> to me that the size of the exe is slightly different.
>>
>> Why do you worry?
>>
>> Andreas
>> Am 04.05.20 um 11:48 schrieb Sachin Kumar:
>>
>> Hi, I am compiling QGIS 3.12 successfully. It is notice that my qgis.exe
>> size 196KB where as when I installed QGIS 3.12 x64, its qgis-bin.exe size
>> is 111KB.
>>
>> Any reason?
>>
>> Regards
>> Sachin
>>
>> ___
>> 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
>>
>> ___
>> 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] Server manual

[Régis Haubourg]

Well,
Hard question depending a lot on your connection use cases. From the
benchmark E have been doing in production, NGINX seems to be better in most
situations.
I never tested caddy though.
Best
Régis

Le lun. 20 avr. 2020 à 20:49, Werner Macho  a
écrit :

> Hi Marco,
>
> Thanks for the hint with qgisserver-caddy I am going to take a look at
> it ASAP.
>
> And of course mod-fcgi in apache is available.
> The question is: which way is the fastest and uses the least
> ressources. So I wanted to try different webserver with different ways
> of starting qgisserver.
> There must be a reason why fastcgi and spawn-cgi and some others exist
> ;)
>
> regards
> Werner
>
> On Mon, 2020-04-20 at 12:44 +0200, Marco Bernasocchi wrote:
> > Hi all
> >
> > On 17.04.20 14:49, Paolo Cavallini wrote:
> > > Hi Werner,
> > >
> > > Il 17/04/20 14:45, werner.ma...@gmail.com ha scritto:
> > > > Hi Paolo,
> > > >
> > > > Thanks a lot, I overlooked that small part,
> > >
> > > so you confirm the current situation _is_confusing ;)
> >
> > I agree it is :)
> >
> > and honestly I think setting up a qgis server is not something many
> > people do. and the one who do, are probably ok with the language in
> > the user manual.
> >
> > > > but as far as I see it
> > > > covers "only" nginx.
> > >
> > > do you need spawn-fcgi for apache?
> >
> > no you don't. apache has it's own mod_fcgi
> >
> >
> >
> > werner, my last deployment was done using caddy server, super neat
> >
> > https://github.com/opengisch/qgisserver-caddy/
> >
> >
> >
> > Cheers Marco
> >
> > > cheers
> > >
> >
> > --
> > Marco Bernasocchi
> > OPENGIS.ch CEO
> > QGIS.org Co-chair
> > ma...@opengis.ch
> > +41 (0)79 467 24 70
> >
> >
>
> ___
> 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] Cancellation: QGIS Developer meeting and conference

[Régis Haubourg]

What about

QGIS "Remote"?

Or QGIS "made from homes"

Or "QGIS stayed at home"

QuarantineGIS or QGIS "COVID edition" could be good candidates but are a
bit too much of dark humor I guess.

And I imagine the banner with a nice worldmap background and a subtle image
of children passing behind the webcam?


Sorry ---> me out. Hum in fact I can't. Staying in.
Day 12.

Take care

Régis

 來浪



Le lun. 30 mars 2020 à 22:54, Giovanni Manghi  a
écrit :

> > "QGIS 3.18 L Ron Hubbard"
>
> this is hysterical :)
> ___
> 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 "fast" mode

[Régis Haubourg]

Hi, can someone explain what is the real logic currently coded for trust
option? It feels like this topic raises again each year for 5 years now,
and we have regressions and what it is supposed to do.

It was funded at start to not check at all any metadata on the datasource
and read only qgs informations
Did it change for some reason ? Why?

It should be adequate even for big databases of QGIS stores all the
required informations.

Regards
Regis

Le jeu. 19 mars 2020 à 18:05, René-Luc Dhont  a écrit :

> Hi Tomas,
>
> The way trust option works is not enough for big databases and big
> project with more than 100 layers. It is what Michaël and I experiment.
>
> Then the problem with changes data is more about the layer extent. For
> example a natural observations layer is designed to accept data on a
> territory but t the start of the project the layer extent is null and
> will growing with data inserted. The trust option cannot be used at the
> project start unless the user can set the available extent, or can
> defined the trust option for each layer.
>
> It will be great to set trust option at the layer level so QGIS can
> trust the layer information provided by the XML : QLR or QGS content
> It will also be great to can set some technical metadata like a layer
> available extent as the geographic area for which a selected CRS is
> valid for use.
>
> Regards,
> René-Luc
>
> Le 18/03/2020 à 22:01, Tomas Straupis a écrit :
> > 2020-03-18, tr, 21:41 kimaidou rašė:
> >> # only few requests are avoided as you pointed out so the performance
> improves "only" a bit
> >In large databases those few requests take minutes and sometimes
> > even hours... For servers even 30 seconds are too much when you're
> > trying to add a new QGIS server process to existing say 10 while on
> > high load doing 500 requests per second.
> >
> >> # sometimes you have some layers with changing data, and there is
> actually no way to trust only a subset of layers inside the project
> >1. If geometry types are changing by design, then checking geometry
> > type upon project loading is not enough. Then you need to ALWAYS
> > filter your results by requested geometry type. But only if it is the
> > case of varying geometry types. In my opinion, developer of the
> > layer/query should know beforehand if it is possible for geometry
> > types to variate and then create a view filtering on geometry type (or
> > it could be an option in QGIS ~"filter on geometry type").
> >
> >2. If database schemas are changing on-line then I would say
> > something is very wrong with the IT processes. Changes should start on
> > dev environment where data changes and QGIS project changes as well.
> > Then changes to db structure go to other environments up to production
> > in patches TOGETHER with updated QGIS project. System (in this case
> > QGIS) should never (in my experience) try to "fix" the problem because
> > it does not know all required information: maybe the project was
> > opened in incorrect environment, maybe it is a temporary problem,
> > maybe the real table is missing and you're accidentally trying to
> > query incorrect table which was never supposed to be queried -> strict
> > rules/control. Of course there could be a button "refresh" on a layer
> > to allow operator to re-query layer information upon manual request.
> >
> >> Do you think it would be interesting to have the trust option per layer
> and not only per project?
> >Theoretically there could be very different data sources, but in my
> > opinion if organisation uses strict IT processes then all layers will
> > be strictly managed (you would rarely/never have direct access to the
> > database of a different company/institution with different/weaker
> > processes). And vice versa.
> >
>
> ___
> 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] Geopackage FID columns: i HATE them!!!!

[Régis Haubourg]

+1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived and
allowed business logic primary keys.


Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow  a écrit :

> I agree.
>
> If there is an ID that is used internally as a unique primary key it
> should never be shown to the user. It should not be expected to be edited
> outside of the provider's control or be stable between edits.
>
> If you need a stable ID for reference you should make your own {{insert
> rant about people wanting to use increating ints as a reference ID}}
>
> On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson 
> wrote:
>
>> Hi list,
>>
>> Just wondering what everyone's thoughts are about geopackage FID
>> columns. Personally, I find them an absolute nightmare to deal with,
>> resulting in annoying (and dangerous) issues when trying to save
>> geopackage edits, such as
>> - field type issues: converting certain formats to geopackage fails,
>> because existing fields with name "fid" are of an incompatible type
>> with geopackage. Solution: manually uncheck the "fid" field from the
>> "save as" dialog.
>> - unique constraint violations: we've mostly fixed this in processing,
>> but it's still unfortunately really common to get failures when saving
>> edits to geopackage because some operation has resulted in duplicate
>> fids. This can be a nightmare to fix, if it's even possible to do so.
>>
>> I personally HATE HATE HATE these columns, and would rather I never
>> saw them ever again. Does anyone else feel the same? If so, could we
>> potentially just permanently hide these columns from QGIS and avoid
>> all these dangerous issues for users?
>>
>> 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] Size of docker images

[Régis Haubourg]

+1
For running desktop I extensively use Dockers derived from jancelin's work.
See my branches here where I upgraded the images to be able to use startup
parameters like profiles_path.

For building and running the lighter possible images, we use this stack,
mainly for server.

https://github.com/Oslandia/docker-qgis

Sorry for being short, I'm tutoring children school work !

Le jeu. 19 mars 2020 à 09:58, Denis Rouzaud  a
écrit :

> These images are built using the same base images that are used for
> testing.
> https://github.com/qgis/QGIS/blob/master/.docker/qgis.dockerfile#L6
>
> I think it would be more appropriate to create a dedicated Dockerfile with
> only what is required to run the app and not building/testing/producing the
> docs.
>
>
>
> Le jeu. 19 mars 2020 à 07:58, Etienne Trimaille <
> etienne.trimai...@gmail.com> a écrit :
>
>> Hi,
>>
>> Just for your information, I have noticed that the size of official QGIS
>> docker images are increasing:
>>
>> qgis/qgis release-3_4  4.83GB
>> qgis/qgis release-3_106.67GB
>> qgis/qgis latest6.95GB
>>
>> Is-it an issue? A known issue?
>> 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 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] The build of weekly snapshots stopped in February

[Régis Haubourg]

We would need to have a parameter to set the download location, as http or
file resource so that remote site with no internet available can still
install QGIS then...

Le jeu. 19 mars 2020 à 07:53, Nyall Dawson  a
écrit :

> On Thu, 19 Mar 2020 at 16:49, Jürgen E. Fischer  wrote:
> >
> > Hi Andrea,
> >
> > On Wed, 18. Mar 2020 at 16:18:39 -0700, Andrea Giudiceandrea wrote:
> > > it seems that the build of the weekly snapshots of qgis-dev from
> OSGeo4W as
> > > standalone installer for Windows stopped in February: the last one is
> > > QGIS-OSGeo4W-3.11.0-8 25-Feb-2020.
> >
> > Yes. proj-dev-data is to huge for NSIS.  Best install via OSGeo4W until
> grids
> > are downloadable via proj.
>
> There's no plans to use proj 7's built in auto grid download. This
> isn't designed for GUI applications like QGIS -- if we did, we'd get
> UI hangs all over the place while QGIS is trying to transform
> coordinates, and proj blocks and waits for the download to occur.
>
> What we should instead do is just fire up a background task on first
> install to download ALL THE GRIDS FOR EVERYWHERE form the proj CDN and
> install them locally. Problem solved FOREVER! ;)
>
> Nyall
>
> >
> >
> > 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)  GermanyIRC: jef on
> FreeNode
> > ___
> > 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] QGIS "fast" mode

[Régis Haubourg]

Hi Tomas.
Check the project property option named "trust". This is exactly what it is
supposed to do.
I admit the wording is not nice, any better idea is welcome.
Best regards


Le sam. 14 mars 2020 à 12:55, Tomas Straupis  a
écrit :

> Hello
>
>   I would like to know opinion of QGIS developer community on the
> question of "self-fixing queries" in the context of database layers.
>
>   When you add a new database layer, QGIS queries required data, asks
> user for other information and then saves it in the project file.
>   Now when you re-open the project, QGIS is re-querying a lot of data
> which is already saved in the project: geometry type, srid, attributes
> (table columns/types).
>   The downsides are:
>   * these "re-checking" queries take considerable time on large
> databases: with millions of records from 1minute up to several hours,
> database is tuned - WMS/WFS queries finish in ~100ms.
>   * in QGIS server environment these re-checking queries are executed
> each time when apache launches a new QGIS server process
>   * QGIS might by itself (without human interaction) decide to  work
> differently compared to what it was asked to do when the project was
> created if it finds that "something has changed"
>   * re-checking during project opening is not 100% correct, as if
> changes are possible in principle, then data/schema could change
> during the time QGIS (Desktop/Server) is open/running
>   * in environments other than development (testing, qa, production),
> database schema should never change without some clear procedure which
> should also include updating QGIS project files and testing them as
> required, therefore such re-checkings should never be required on
> testing/production environments.
>
>   I do understand that the current situation/understanding is
> different from mine, so in order to satisfy everybody, maybe it would
> be feasible to add say an environment variable like QGIS_FAST=TRUE (or
> QGIS_PRODUCTION=TRUE) and if this is set - re-checking queries could
> be skipped? We've been running modified QGIS without re-checking in
> production for months and are very happy with results. This should
> also improve the benchmarks of QGIS Server as it is known that initial
> opening of the project takes considerable amount of time.
>
>   What is your opinion?
>
>   Thank you
>
> --
> Tomas
> ___
> 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] Explicit policy re bug fixing responsibilities after new features

[Régis Haubourg]

Hi Nyall,
this sounds reasonable indeed, can we have a bit more background or
pointers to real cases?
One issue we faced these past months is that he exponential trafic on the
issues and PR makes it harder to follow issues and just have the
information that we could possibly be at stake somewhere.
Last year I was able to follow +/- 80 % of the discussions. I must admit
that lastly it became nearly impossible unless to work mostly on QGIS bug
triaging or coding.

I really don't know how we could improve our communication channels. Any
hint welcome.

Best regards
Régis

Le lun. 9 mars 2020 à 23:14, Nyall Dawson  a écrit :

> Hi list,
>
> I'm after feedback on whether or not others think an explicit
> policy/contract regarding bug fixing responsibilities for new features
> is a good idea or not.
>
> I would like to see something like this added to the developer guidelines:
>
> "Following any new feature development, it is the original developer's
> (or organisations) SOLE responsibility to implement bug fixes relating
> to the new feature (or regressions to other parts of QGIS which have
> resulted from its development). This extends up to the next major QGIS
> release following the feature being merged*. It is NOT acceptable to
> use QGIS.org sponsored bug fixing efforts to implement these fixes.
> Failure to provide fixes to all reasonable bug reports raised for a
> new feature may lead to that feature being reverted prior to release."
>
> *i.e. currently 3.14
>
> Personally, I think having this as part of our developer agreement
> would help clear up some ambiguity and source of frustration/conflict
> between developers.
>
> Thoughts?
>
> 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

Re: [QGIS-Developer] QGIS 3.10 error on startup

[Régis Haubourg]

Same feedback here.
this fails:

osgeo4w-setup-x86_64.exe -g -k --autoaccept -q -P
qgis-ltr,python3-tools,python3-pip,python3-setuptools,python3-networkx -s "
http://download.osgeo.org/osgeo4w/x86_64;

but adding qgis package seems to solve the issue.

Regards

Régis

Le lun. 24 févr. 2020 à 12:36, Paolo Cavallini  a
écrit :

> Hi all,
> I have been reported that a fresh install of the new LTR reports two
> errors:
> * missing exiv2.dll
> * could not load qgis_app.dll
> Reinstalling apparently does not help.
> Any hint?
> Cheers.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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-user] Thoughts on QGIS Development and LTR Releases

[Régis Haubourg]

Hi Chris,
I share most of your concerns, as much as I advocate the spread of QGIS in
enterprise and organisations.
It is true we need always more reliability, documentation.  I'd like also
to point that 2.x is not so far away, and that the reliability have since
improved by order of magnitude.
Let's also keep in mind that the level of expectations of users grows very
fast too, so this is a race that will never end ;-)

However, I think there is a cultural problem, and probably a pedagogy
effort we should make.

LTR does not mean stable. LTR means it will gain bugfixes longer than
releases. So it is highly expectable that installing a LTR in its early
versions will let you hit more issues.  I remember the very same situation
for ArcGIS 8 or 9 early stages. And this is the very same for linux
distributions or any software. I don't remember any  early x.0 release in
QGIS that was not followed one week later by an urgent point release. But
new users don't know this. They see a big green button "download that sexy
new version".

That said, how to improve the situation? After years of discussions in the
various events, hackfest, conferences, discussions with public or private
customers, developpers, here are the possible leads we have:

- Keep on explaining the rationale and codes of free software to users and
potential funders.

- Try to keep our "power users / early testers" population, so that we
target the right issues during bugfix sprints.

- Offer longer LTR lifespan, so that funders have a larger window to
actually find and have bug fixed.

- Keep on explaining that QGIS bugfix release should be easily deployable
in big organisations. OSGEO4W silent installs allows this. Maybe going
toward auto upgrade /  patch system could help (it's a big effort though)

- Keep on gaining more budget for QGIS.org, so that we can setup a real
semi automated Q/A acceptance test suite. This requires human tests.
Boundless did, it is possible. It is a matter of ressources. Should it be
centralized or community powered ? I have no idea, but this requires
someone to be hired all year long to do this. IMO, enterprises requiring
such reliability should really consider sponsoring this framework and
dedicate some human ressources.

- Same goes for documentation

- Same goes for code review, we need to have more reviewers. the learning
curve is steep though, and we need to find money for this

- Improve the website with a simple page, with graphics and videos on what
is the lifecycle of QGIS, and what version to use for what expectations.


A note about QGIS.org budget. To me, it is only a leverage, a catalyser,
but it can't fund itself a full QA infrastructure with the current economic
model of the association. I think, this is our responsability to spread
this word everywhere so that the user / contributor rate changes a bit.

After all, even Microsoft with its thousands of testers, and its early
testing network was able to push updates causing the famous Blue Screen Of
the Death.
So shit can happen. Packaging nightmare with major changes in underlying
libraries remains a really really complex process. How fast we are to fix
and change our ways to do is the real question. I think the QGIS and OSGeo
Community does a tremendeous work.

Best regards,
Régis




Le jeu. 20 févr. 2020 à 16:21, C Hamilton  a écrit :

> I first want to say how much I appreciate all of the QGIS developers and
> all of your hard work, but I would also like to suggest that you exercise
> caution when you label a release LTR. I work in a large organization where
> most geospatial analysts can have access to ArcGIS if they want it. The
> advantage to ArcGIS is that everyone has been trained to use it, ESRI has
> been around for a long time and there is a lot of documentation, training
> and support for it. So why would users want to use QGIS?
>
> There are always a curious few who see QGIS and realize they can download
> it for free at home. They tinker with it and come to like it and then they
> try it in the workplace. For the users who have ArcGIS at their disposal
> there must be a good reason to use QGIS instead. These tend to be the
> reasons they use QGIS: 1) It does not crash as much as ArcGIS. 2) It is
> faster than ArcGIS. 3) It can effectively processing larger data sets than
> ArcGIS. 4) There may be some workflow in QGIS that is simpler than in
> ArcGIS.
>
> I think that the QGIS community can be proud about the fact that most of
> my users who start using QGIS love it and don't want to go back to ArcGIS
> if at all possible.
>
> If a user finds that their reason for using QGIS goes away, they will be
> disappointed, but will to go back to ArcGIS. I am an advocate for QGIS in
> our work place. I think it should be used more, but it is really, really
> hard to convince most people. Most of my users are not programmers so if
> something is broken they don' t know how to fix it. We have QGIS support
> contracts which help. Users consider the QGIS 

Re: [QGIS-Developer] Reporting security related issues ?

[Régis Haubourg]

Me too!

Le mer. 12 févr. 2020 à 14:34, Alessandro Pasotti  a
écrit :

>
>
> On Wed, Feb 12, 2020 at 1:19 PM Richard Duivenvoorde 
> wrote:
>
>> FYI: I've just created an email(group) address for this:
>>
>> secur...@qgis.org
>>
>> Emails to that address will be forwarded to PSC members and members of
>> admin-group.
>>
>> If individuals/core-members want to be added, please let me know so I
>> can add you to that group.
>>
>
>
> me too please.
>
> --
> Alessandro Pasotti
> w3:   www.itopen.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] Insert data in a table with a table with a GENERATED column

[Régis Haubourg]

Oh, I see my master is old. I thought I recompiled it last week. I'll check
again. Let's compile.
Regards
Régis

Le mar. 11 févr. 2020 à 15:12, Alessandro Pasotti  a
écrit :

>
> Wierd, I thought I fixed that: there is a test too,
> https://github.com/qgis/QGIS/pull/34017/files#diff-99b101819133a316786604243f3abf6eR1432
>
> feel free to reopen and provide additional test details or test cases.
>
> https://github.com/qgis/QGIS/pull/34017
>
>
> On Tue, Feb 11, 2020 at 3:05 PM Régis Haubourg 
> wrote:
>
>> For the record here are my SQL commands:
>> drop table if exists data.pipe;
>>
>> CREATE TABLE data.pipe
>> (
>> id integer NOT NULL ,
>> label_1_text character varying(120) COLLATE pg_catalog."default",
>> _length2d numeric(8,2) GENERATED ALWAYS AS (st_length2D(geometry))
>> STORED,
>> _length3d numeric(8,2) GENERATED ALWAYS AS (ST_3DLength(geometry))
>> STORED,
>> geometry geometry(LineStringZ,3946) NOT NULL,
>> CONSTRAINT pipe_pkey PRIMARY KEY (id)
>> );
>>
>> INSERT INTO
>> "data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
>> VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),2
>> ,'test',DEFAULT, DEFAULT);
>>
>> Le mar. 11 févr. 2020 à 15:03, Régis Haubourg 
>> a écrit :
>>
>>> Hi Paolo,
>>> nice feature, thanks for the heads up !
>>>
>>> I confirm the behavior here.
>>>
>>> The documentation advises to use the `DEFAULT` keyword into the INSERT
>>> command.
>>> Here is what I get with a QGIS-like insert :
>>>
>>>  INSERT INTO
>>> "data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
>>> VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),1 ,'test',0,  0);
>>> ERREUR:  42601: ne peut pas insérer dans la colonne « _length2d »
>>> DÉTAIL : Column "_length2d" is a generated column.
>>> EMPLACEMENT : rewriteTargetListIU, rewriteHandler.c : 827
>>>
>>> With the keyword 'DEFAULT', it works
>>>
>>> INSERT INTO
>>> "data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
>>> VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),2
>>> ,'test',DEFAULT, DEFAULT);
>>>
>>> And with no data supplied for the generated columns, it also works
>>>
>>> We indeed have to upgrade the postgresql provider to check this
>>> particular column type to handle INSERT and UPDATE accordingly.
>>>
>>> Regards
>>>
>>> Régis
>>>
>>>
>>> Le mar. 11 févr. 2020 à 13:59, Paolo Cavallini 
>>> a écrit :
>>>
>>>> Hi all,
>>>> PostgreSQL 12 has the option of a GENERATED ALWAYS AS ... STORED column.
>>>> QGIS is able to load the table, but apparently it is not possible to
>>>> insert new records. Does anyone confirm that this is not a local
>>>> problem?
>>>> All the best.
>>>> --
>>>> Paolo Cavallini - www.faunalia.eu
>>>> QGIS.ORG Chair:
>>>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>>>> ___
>>>> 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
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.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

Re: [QGIS-Developer] Insert data in a table with a table with a GENERATED column

[Régis Haubourg]

For the record here are my SQL commands:
drop table if exists data.pipe;

CREATE TABLE data.pipe
(
id integer NOT NULL ,
label_1_text character varying(120) COLLATE pg_catalog."default",
_length2d numeric(8,2) GENERATED ALWAYS AS (st_length2D(geometry))
STORED,
_length3d numeric(8,2) GENERATED ALWAYS AS (ST_3DLength(geometry))
STORED,
geometry geometry(LineStringZ,3946) NOT NULL,
CONSTRAINT pipe_pkey PRIMARY KEY (id)
);

INSERT INTO
"data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),2
,'test',DEFAULT, DEFAULT);

Le mar. 11 févr. 2020 à 15:03, Régis Haubourg  a
écrit :

> Hi Paolo,
> nice feature, thanks for the heads up !
>
> I confirm the behavior here.
>
> The documentation advises to use the `DEFAULT` keyword into the INSERT
> command.
> Here is what I get with a QGIS-like insert :
>
>  INSERT INTO
> "data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
> VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),1 ,'test',0,  0);
> ERREUR:  42601: ne peut pas insérer dans la colonne « _length2d »
> DÉTAIL : Column "_length2d" is a generated column.
> EMPLACEMENT : rewriteTargetListIU, rewriteHandler.c : 827
>
> With the keyword 'DEFAULT', it works
>
> INSERT INTO
> "data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
> VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),2
> ,'test',DEFAULT, DEFAULT);
>
> And with no data supplied for the generated columns, it also works
>
> We indeed have to upgrade the postgresql provider to check this particular
> column type to handle INSERT and UPDATE accordingly.
>
> Regards
>
> Régis
>
>
> Le mar. 11 févr. 2020 à 13:59, Paolo Cavallini  a
> écrit :
>
>> Hi all,
>> PostgreSQL 12 has the option of a GENERATED ALWAYS AS ... STORED column.
>> QGIS is able to load the table, but apparently it is not possible to
>> insert new records. Does anyone confirm that this is not a local problem?
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> ___
>> 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] Insert data in a table with a table with a GENERATED column

[Régis Haubourg]

Hi Paolo,
nice feature, thanks for the heads up !

I confirm the behavior here.

The documentation advises to use the `DEFAULT` keyword into the INSERT
command.
Here is what I get with a QGIS-like insert :

 INSERT INTO
"data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),1 ,'test',0,  0);
ERREUR:  42601: ne peut pas insérer dans la colonne « _length2d »
DÉTAIL : Column "_length2d" is a generated column.
EMPLACEMENT : rewriteTargetListIU, rewriteHandler.c : 827

With the keyword 'DEFAULT', it works

INSERT INTO
"data"."pipe"("geometry","id","label_1_text","_length2d","_length3d")
VALUES (st_geomfromtext('LINESTRINGZ(1 1 1, 2 2 2)',3946),2
,'test',DEFAULT, DEFAULT);

And with no data supplied for the generated columns, it also works

We indeed have to upgrade the postgresql provider to check this particular
column type to handle INSERT and UPDATE accordingly.

Regards

Régis


Le mar. 11 févr. 2020 à 13:59, Paolo Cavallini  a
écrit :

> Hi all,
> PostgreSQL 12 has the option of a GENERATED ALWAYS AS ... STORED column.
> QGIS is able to load the table, but apparently it is not possible to
> insert new records. Does anyone confirm that this is not a local problem?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Régis Haubourg]

Wow, strange move for Qt !
We still lack a lot of detail though...
Régis



Le lun. 27 janv. 2020 à 17:25, Even Rouault  a
écrit :

> Hi,
>
> Just read this:
>
> https://www.phoronix.com/scan.php?page=news_item=Qt-Going-More-Commercial
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> 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] What to do about GDAL and PROJ for 3.10.2?

[Régis Haubourg]

+1 with postponing the minor version AND advertise largely why we do this.
Regards
Régis

Le jeu. 19 déc. 2019 à 08:00, Paolo Cavallini  a
écrit :

> Hi again,
>
> Il 19/12/19 07:57, Nyall Dawson ha scritto:
> > On Thu, 19 Dec 2019 at 16:51, Paolo Cavallini 
> wrote:
> >>
> >> Hi Nyall,
> >> thanks for clarifying this. Wouldn't it be reasonable to ask gdal+proj
> >> teams to release a new fixed version ASAP? Even if we fix this in the
> >> Windows installer, where we (Juergen) have full control, we'll still
> >> have issues on other OSs where we cannot control dependencies.
> >
> > We can, but I don't honestly see that happening before Christmas (it
> > is the holiday season after all!)
> In this case I don't see a major problem in postponing a point release,
> or even skipping it until the next one - am I wrong?
> Cheers.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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 Onboarding Day?

[Régis Haubourg]

Hi,

getting to make good documentation of how to run debug traces on windows
would be awesome, that could be a target of the hackfest.
I'm not sure that building QGIS on Windows is really an onboarding task,
it's more a really advanced one from what I understand.
Regards
Régis

Le ven. 6 déc. 2019 à 14:42, Thomas Baumann  a
écrit :

> Hi Raymond,
> I think especially getting QtCreator or Visual Studio under Windows OS up
> and running would be a good topic if the are windows users as newbies at
> your hackfest.
>
> On Linux and Windows I got the debug setup with QtCreator running with the
> help of our paid QGIS support but the setup on windows with Visual Studio
> which i tried on my own was just a nightmare.
>
> I'm still not sure if there are essential parts missing in the docs at the
> moment (adding Version.lib dependency, manually creating qgis.env) which
> were necessary for me to be able to debug in Visual studio:
> https://gis.stackexchange.com/q/340984/67477
>
>
> I can imagine that a "debug"-boarding directly from the QGIS devs would be
> helpful for many users... So I was wondering if you plan to record the
> boarding?
>
> If I wouldn't have needed the debug environment for my work I would have
> just given up after some frustrating hours and dismissed the idea of
> helping bugfixing QGIS.
>
>
> regards,
> Thomas
>
> Raymond Nijssen  schrieb am Do., 5. Dez. 2019,
> 13:19:
>
>> Dear Devs,
>>
>> Making plans for the next hackfest (13-15 March 2020, The Netherlands)
>> we are thinking of a way to attract new people to the project. Quite
>> some Dutch people are interested to come over and "see" us, but of
>> course we need to help them getting up and running.
>>
>> So we are thinking on doing an "Onboarding Day" the day prior to the HF
>> (Thursday March 12) with workshops teaching:
>>
>> - How to translate?
>> - How to write documentation?
>> - How to compile?
>> etc...
>>
>> We already noticed Alessandro's offer to do a Mentor Stream on "my first
>> pull request" which would also fit this idea.
>>
>> Just curious, what are your thoughts on this? And would you like to
>> arrive one day earlier in the lovely Netherland to warmly welcome new
>> contributors?
>>
>> Thanks,
>> Raymond (and Rosa and Aron)
>>
>>
>> https://github.com/qgis/QGIS/wiki/24th-Contributor-Meeting-in-'s-Hertogenbosch
>> ___
>> 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] Processing: questions on temporary files

[Régis Haubourg]

Le ven. 6 déc. 2019 à 14:19, Matthias Kuhn  a écrit :

> Hi Richard
> [..]
> Other proposals are very welcome as well. I don't insist on GeoPackage.
> All I do is being a bit skeptic that rolling our own format will
> magically solve problems that one hundred other formats did not solve :-)
>

Wise words. I totally agree.



Le ven. 6 déc. 2019 à 14:19, Matthias Kuhn  a écrit :

> Hi Richard
>
> On 12/6/19 2:07 PM, Richard Duivenvoorde wrote:
> > On 06/12/2019 07.58, Matthias Kuhn wrote:
> >> On 12/6/19 7:52 AM, Alexander Bruy wrote:
> >>> пт, 6 груд. 2019 о 08:44 Matthias Kuhn  пише:
>  Meanwhile, why not use a well known spatial data file format?
> >>> I can be wrong, but using spatial data formats can be lossy in some
> >>> cases,
> >>> e.g. shapefile/dbf has limits for the field name length and field
> >>> length. Some
> >>> other formats may lack support for some datatypes, like datetime etc.
> >>>
> >>> Of course is there is a format which allow fast and lossless storage
> >>> we should
> >>> use it
> >> I think GeoPackage should be fairly stable for this kind of usage.
> > Well, yes, may be, but given I've seen some issue (locks/crashes etc
> > etc) with GeoPackages, and myself having issue with true
> > DateTime/TimeZones's in it... I thought to propose an alternative :-)
>
> Since these files are created as an output and no concurrent access is
> expected, I don't think there's a risk for locking issues here.
>
> For DateTime/TimeZones etc, are we sure we will be in a better situation
> with "our own" serialized format?
>
> > My impression is that the community is experiencing some drawbacks with
> > GeoPackage/SQLite, but maybe I'm wrong.
>
> Other proposals are very welcome as well. I don't insist on GeoPackage.
> All I do is being a bit skeptic that rolling our own format will
> magically solve problems that one hundred other formats did not solve :-)
>
> Regards
>
> 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
> >
> ___
> 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] osgeo4w's qgis-dev package broken, proj_7_0.dll missing

[Régis Haubourg]

Hi,
great news.
Does that mean QGIS 3.4 LTR will continue its life as expected? Or is
3.4.14 the last one?
thanks for your lights, we need to communicate quickly if LTR is frozen
now.
Regards
Régis

Le ven. 6 déc. 2019 à 00:06, Nyall Dawson  a écrit :

> On Fri, 6 Dec 2019 at 07:54, Jürgen E. Fischer  wrote:
> >
> > Hi,
> >
> > On Thu, 05. Dec 2019 at 11:22:35 +, Pedro Venâncio wrote:
> > > But I believe that should be fixed in the next build.
> >
> > Yes, the rebuild has picked the new proj up.
> >
> > Rhere also a new qgis-ltr now - and new standalones for 3.4.13.
> >
> > As that also required updates to the build scripts in the release branch
> -
> > tomorrows 3.4.14 should be almost the same - except for some
> translations…
>
> Testing 3.4.13, it looks like you've successfully found a solution to
> use gdal < 3 and proj < 6 for the 3.4 build?
>
> Great work!!
> 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

Re: [QGIS-Developer] QGIS Onboarding Day?

[Régis Haubourg]

Hi,
that's a big +1 for the onboarding idea. And yes Andrea, a short talk on
how to contribute financially, followed by an open discussion is clearly
something helpfull. I'll be glad to participate or help.
Régis

Le jeu. 5 déc. 2019 à 14:58, Raymond Nijssen  a
écrit :

> The venue will be available for 4 days, 12-15 March. In case you want to
> arrive even earlier or stay longer please let me know and i will try to
> arrange something.
>
>
>
> On 05-12-2019 13:32, Andreas Neumann wrote:
> > Hi Raymond,
> >
> > I think it is a good idea. I was about to ask if we can already arrive
> > on the 12th - but I guess this would answer my question.
> >
> > I could talk about ways to "support" QGIS financially (just a really
> > short talk summarizing how one can contribute and how the funds are
> > used, but maybe useful).
> >
> > Greetings,
> >
> > Andreas
> >
> > On 2019-12-05 13:18, Raymond Nijssen wrote:
> >
> >> Dear Devs,
> >>
> >> Making plans for the next hackfest (13-15 March 2020, The Netherlands)
> >> we are thinking of a way to attract new people to the project. Quite
> >> some Dutch people are interested to come over and "see" us, but of
> >> course we need to help them getting up and running.
> >>
> >> So we are thinking on doing an "Onboarding Day" the day prior to the
> >> HF (Thursday March 12) with workshops teaching:
> >>
> >> - How to translate?
> >> - How to write documentation?
> >> - How to compile?
> >> etc...
> >>
> >> We already noticed Alessandro's offer to do a Mentor Stream on "my
> >> first pull request" which would also fit this idea.
> >>
> >> Just curious, what are your thoughts on this? And would you like to
> >> arrive one day earlier in the lovely Netherland to warmly welcome new
> >> contributors?
> >>
> >> Thanks,
> >> Raymond (and Rosa and Aron)
> >>
> >>
> https://github.com/qgis/QGIS/wiki/24th-Contributor-Meeting-in-'s-Hertogenbosch
> >> ___
> >> 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] [Qgis-psc] 2019 Grant Final reports: Rendering optimisation and labeling work

[Régis Haubourg]

Hi,
Nyall, this is awesome work! Thanks a lot for this.

I checked the daily performance tests for QGIS server available at
http://test.qgis.org/perf_test/graffiti/aggregate/aggregate.html and
couldn't see clear influence.
Do you have ideas of tests we could add to this framework?

Cheers
Régis


Le mar. 3 déc. 2019 à 08:43, Anita Graser  a écrit :

> Thank you for the detailed report and the excellent work, Nyall!
> I'm looking forward to testing it by upgrading some projects to the new
> labeling.
>
> Anita
> ___
> 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 & PROJ 6 & SAGA

[Régis Haubourg]

Hi, side note, I missed the existence of this SAGA plugin.
Maybe I missed some communication somewhere, and if so, I'm not the only
one.
So, It might be worth giving it another chance maybe.
Regards,
Régis

Le lun. 2 déc. 2019 à 05:43, Nyall Dawson  a écrit :

> On Mon, 2 Dec 2019 at 14:38, Sebastiaan Couwenberg 
> wrote:
> >
> > On 12/1/19 8:50 PM, William Kyngesburye wrote:
> > > I want to have PROJ 6 (and GDAL 3) for QGIS (should be fully supported
> in QGIS 3.10.1), but found a problem with SAGA.  QGIS is still using SAGA
> 2.3 (LTS) for API stability.  SAGA 2.3 is stuck on PROJ.4.  It's only the
> latest SAGA, v7.4 that finally updated for PROJ 6 support.
> >
> > SAGA 7.3.0 is the new LTS, and supports PROJ 6.
> >
> > You should upgrade to that.
> >
> > Also note: https://plugins.qgis.org/plugins/processing_saga_nextgen/
>
> I know, I made that plugin, in the hope that it would be adopted by
> motivated community members who wanted to see a newer saga version
> utilised. Spoiler: it didn't.
>
> Nyall
>
>
>
> >
> > Kind Regards,
> >
> > Bas
> >
> > --
> >  GPG Key ID: 4096R/6750F10AE88D4AF1
> > Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> > ___
> > 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] masks tooltip in Layer Properties

[Régis Haubourg]

Hi Richard
I think this one is for Hugo. This new tab is designed for the selective
masking described here: https://github.com/qgis/QGIS/pull/30747

The tooltip is obviously wrong and the feature misses some explanation in
the layer property tab. Can you raise an issue ?

Regards,
Régis

Le jeu. 28 nov. 2019 à 14:40, Richard Duivenvoorde  a
écrit :

> Using the Layer properties dialog (in master), I spotted an item
> 'Masks'. Could not find any description or clue in the stuff shown.
>
> But I saw that the tooltip of it shows (see screenie):
>
> "If the remove duplicate nodes options is activated, duplicate vertices
> will automatically be removed from geometries which are edited on this
> layer".
>
> Found a documentation item:
>
> https://github.com/qgis/QGIS-Documentation/issues/4368
>
> first question would be: what is it, but second question: is the tooltip
> the right one? Is it a copy/paste thingie? Or is it just not (yet)
> telling what this tab is for :-)
>
> 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
___
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] Labelling misplaced

[Régis Haubourg]

Cool!

Le mar. 12 nov. 2019 à 15:37, Luís Miguel Royo Pérez
 a écrit :
>
> Hi Régis,
>
> thanks a lot for your insights. Finally I caught the issue. It's easy, since 
> the labelling layer is a view, everytime this view was updated, the id, 
> changed, and then the messy thing happened. I fixed already.
> Again, thanks ^^
>
> El lun., 11 nov. 2019 a las 18:43, Régis Haubourg 
> () escribió:
>>
>> Oh ok, expression taken from label connector plugin :)
>>
>> Be aware that it can be slow with big geometries and that it is a
>> temporary approach before having a native one in core (which I'd be
>> pleased to have implemented if anyone supports it).
>>
>> So it seems you have something messing the unique id's that auxiliary
>> storage database uses to link your data and qgis projected data when
>> you add a new feature. Are you sure your ID's and foreign keys beahve
>> like expected on the database side? For the auxiliary storage, a new
>> feature shouldn't have any x-y value and thus the label should fall
>> back to the automatic labeling options. In your case, it seems the
>> newly created feature inherits from the id of another feature. This is
>> a common case in labeling, and I remember the famous Mapinfo label
>> callout mix ups that occured when compressing datasets, just because
>> it didn't use real id's, but line number to identify features.
>>
>>
>> Régis
>>
>> Le lun. 11 nov. 2019 à 17:33, Luís Miguel Royo Pérez
>>  a écrit :
>> >
>> > Of course, here is:
>> >
>> > case when "auxiliary_storage_labeling_positionx" < $x and 
>> > "auxiliary_storage_labeling_positiony" > $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) < 
>> > abs("auxiliary_storage_labeling_positionx"-$x) THEN
>> >  make_line($geometry, 
>> > make_point($x-abs("auxiliary_storage_labeling_positiony"-$y),"auxiliary_storage_labeling_positiony"),make_point("auxiliary_storage_labeling_positionx",
>> >  "auxiliary_storage_labeling_positiony"))
>> > when  "auxiliary_storage_labeling_positionx" < $x and 
>> > "auxiliary_storage_labeling_positiony" > $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) >= 
>> > abs("auxiliary_storage_labeling_positionx"-$x) then
>> >   make_line($geometry, 
>> > make_point($x,abs("auxiliary_storage_labeling_positionx"-$x)+$y),make_point("auxiliary_storage_labeling_positionx",
>> >  "auxiliary_storage_labeling_positiony"))
>> > when "auxiliary_storage_labeling_positionx" < $x and 
>> > "auxiliary_storage_labeling_positiony" < $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) < 
>> > abs("auxiliary_storage_labeling_positionx"-$x) THEN
>> >   make_line($geometry, 
>> > make_point($x-abs("auxiliary_storage_labeling_positiony"-$y),"auxiliary_storage_labeling_positiony"),make_point("auxiliary_storage_labeling_positionx",
>> >  "auxiliary_storage_labeling_positiony"))
>> > when  "auxiliary_storage_labeling_positionx" < $x and 
>> > "auxiliary_storage_labeling_positiony" < $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) >= 
>> > abs("auxiliary_storage_labeling_positionx"-$x) then
>> >   make_line($geometry, 
>> > make_point($x,$y-abs("auxiliary_storage_labeling_positionx"-$x)),make_point("auxiliary_storage_labeling_positionx",
>> >  "auxiliary_storage_labeling_positiony"))
>> > when "auxiliary_storage_labeling_positionx" >= $x and 
>> > "auxiliary_storage_labeling_positiony" > $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) > 
>> > abs("auxiliary_storage_labeling_positionx"-$x) then --quadrant ur 
>> > alternatif
>> >   make_line($geometry, 
>> > make_point($x,"auxiliary_storage_labeling_positiony"-abs("auxiliary_storage_labeling_positionx"-$x)),make_point("auxiliary_storage_labeling_positionx",
>> >  "auxiliary_storage_labeling_positiony"))
>> > when "auxiliary_storage_labeling_positionx" >= $x and 
>> > "auxiliary_storage_labeling_positiony" > $y and 
>> > abs("auxiliary_storage_labeling_positiony"-$y) < 
>> > abs("auxiliary_storage_labeling_positionx&qu

Re: [QGIS-Developer] Labelling misplaced

[Régis Haubourg]

Oh ok, expression taken from label connector plugin :)

Be aware that it can be slow with big geometries and that it is a
temporary approach before having a native one in core (which I'd be
pleased to have implemented if anyone supports it).

So it seems you have something messing the unique id's that auxiliary
storage database uses to link your data and qgis projected data when
you add a new feature. Are you sure your ID's and foreign keys beahve
like expected on the database side? For the auxiliary storage, a new
feature shouldn't have any x-y value and thus the label should fall
back to the automatic labeling options. In your case, it seems the
newly created feature inherits from the id of another feature. This is
a common case in labeling, and I remember the famous Mapinfo label
callout mix ups that occured when compressing datasets, just because
it didn't use real id's, but line number to identify features.


Régis

Le lun. 11 nov. 2019 à 17:33, Luís Miguel Royo Pérez
 a écrit :
>
> Of course, here is:
>
> case when "auxiliary_storage_labeling_positionx" < $x and 
> "auxiliary_storage_labeling_positiony" > $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) < 
> abs("auxiliary_storage_labeling_positionx"-$x) THEN
>  make_line($geometry, 
> make_point($x-abs("auxiliary_storage_labeling_positiony"-$y),"auxiliary_storage_labeling_positiony"),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when  "auxiliary_storage_labeling_positionx" < $x and 
> "auxiliary_storage_labeling_positiony" > $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) >= 
> abs("auxiliary_storage_labeling_positionx"-$x) then
>   make_line($geometry, 
> make_point($x,abs("auxiliary_storage_labeling_positionx"-$x)+$y),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when "auxiliary_storage_labeling_positionx" < $x and 
> "auxiliary_storage_labeling_positiony" < $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) < 
> abs("auxiliary_storage_labeling_positionx"-$x) THEN
>   make_line($geometry, 
> make_point($x-abs("auxiliary_storage_labeling_positiony"-$y),"auxiliary_storage_labeling_positiony"),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when  "auxiliary_storage_labeling_positionx" < $x and 
> "auxiliary_storage_labeling_positiony" < $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) >= 
> abs("auxiliary_storage_labeling_positionx"-$x) then
>   make_line($geometry, 
> make_point($x,$y-abs("auxiliary_storage_labeling_positionx"-$x)),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when "auxiliary_storage_labeling_positionx" >= $x and 
> "auxiliary_storage_labeling_positiony" > $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) > 
> abs("auxiliary_storage_labeling_positionx"-$x) then --quadrant ur alternatif
>   make_line($geometry, 
> make_point($x,"auxiliary_storage_labeling_positiony"-abs("auxiliary_storage_labeling_positionx"-$x)),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when "auxiliary_storage_labeling_positionx" >= $x and 
> "auxiliary_storage_labeling_positiony" > $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) < 
> abs("auxiliary_storage_labeling_positionx"-$x) then
>make_line($geometry, 
> make_point($x+abs("auxiliary_storage_labeling_positiony"-$y),"auxiliary_storage_labeling_positiony"),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when "auxiliary_storage_labeling_positionx" >= $x and 
> "auxiliary_storage_labeling_positiony" <= $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) > 
> abs("auxiliary_storage_labeling_positionx"-$x) THEN
>   make_line($geometry, 
> make_point($x,$y-abs("auxiliary_storage_labeling_positionx"-$x)),make_point("auxiliary_storage_labeling_positionx",
>  "auxiliary_storage_labeling_positiony"))
> when "auxiliary_storage_labeling_positionx" >= $x and 
> "auxiliary_storage_labeling_positiony" <= $y and 
> abs("auxiliary_storage_labeling_positiony"-$y) < 
> abs("auxiliar

Re: [QGIS-Developer] Labelling misplaced

[Régis Haubourg]

Hi Luis, can you share your geometry generator expression please?
regards
Régis

Le lun. 11 nov. 2019 à 09:04, Luís Miguel Royo Pérez
 a écrit :
>
> Hello everyone,
>
> I'm developing a QGIS plugin along with PostGIS and I'm facing some problems 
> with labeling. This plugin creates several layers and tables. Some of these 
> layers are views  (labeling layers), so if I edit the one fo the source layer 
> the view changes and then the label. I explain more detailed:
>
> I have the following:
>
> One layer. Let's call it layer1.
> One none spatial table. Let's call it table1.
> One spatial view from these other two layers layer1 and table1 meant for 
> labeling. Let's call it labelView1.
>
> The point is this, when I edit table1 adding a new element linked by a 
> foreign key with layer1. The label position in labelView1 changes into a 
> messy thing. The Style of labelView1 is the following:
>
> Symbol is a geometry generator. Since I want to create callouts from label to 
> the geometry, wich is a point.
> The position of the label is saved on project. In the qgd file.
>
> I have seen this behaviour in Windows10 and in Ubuntu. The QGIS version is 
> 3.4, but I tried to move to the new 3.10 version of QGIS, with the callouts 
> new feature, but is the same result.
>
> As well I tried to reproduce it in a much simple way, but without succed, 
> that's why I want to share a link with a GIF file showing this issue:
>
> https://gifyu.com/image/vMY7
>
> I've done the same but without fixed position,and the labels don't move, but 
> the geometry_generator does.
>
> Is this a bug? Is there any way to prevent it?
>
> Thanks.
> --
> Luís Miguel Royo Pérez.
> Analista-Programador GIS
> C/ Antic Regne de Valencia nº 4. Manises (Valencia)
> Teléfono:+34  679846103
> webs:
> inisig.com
> geofibra.com
>
>
> ___
> 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 Print Layouts Graphs and Charts Campaign – Complete!

[Régis Haubourg]

This is great news! Congratulations all, this will be a game changer !


Le mar. 5 nov. 2019 à 16:10, Tim Sutton  a écrit :

> Whooo - quick experimentation says ‘yes, it works in reports’.
>
> Great!
>
> Regards
>
> Tim
>
> On 5 Nov 2019, at 15:06, Tim Sutton  wrote:
>
> Hi Nyall
>
> Awesome stuff! Will those work in reports too (sorry if I asked before and
> forgot the answer :-P)?
>
> Regards
>
> Tim
>
> On 5 Nov 2019, at 06:16, Nyall Dawson  wrote:
>
> Hi all,
>
> Just a quick heads up that our recent QGIS Print Layouts Graphs and
> Charts Campaign is now complete, and you can download the results
> today via the DataPlotly plugin version 3 from your QGIS plugin
> install dialog!
>
> This work was possible thanks to our partners at Faunalia GIS and
> thanks to all the backers of the crowd-funding campaign.
>
> You can read more about the new functionality here:
>
> https://north-road.com/2019/11/05/qgis-print-layouts-graphs-and-charts-campaign-complete/
>
> Regards,
> 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
>
>
> —
>
>
> 
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org 
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> 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 server and metadata

[Régis Haubourg]

Hi,
usually I use an external tool to harvest QGIS projects and create ISO / DC
metadata and push them through CWST to the catalog that is available.

Talend metadatacrawler allows this easily.  Having this embedded into QGIS
could help indeed. I would very much like the ability to handle metadata
templates so that administrator can configure most fields and let users
deal with the essential ones.  Having the ability to convert from
Dublin-core to FDGC / ISO / INSPIRE is also necessary to me. Users tend to
use Dublin core, but legal infrastructure require more advanced formats
like ISO. Moreover, creating a UI to edit the hierarchical XML structure of
ISO is quite a nightmare, and I would avoid trying to reproduce in QGIS
what took years to achieve in Geonetwork.

long story short :
+1 for editing in Dublin core, add ISO / FDGC templates and features to
export / commit via CSW-T more advanced formats. -1 to try to reimplement
one edit form per metadata format.

Cheers
Régis


Le lun. 4 nov. 2019 à 13:36, Tim Sutton  a écrit :

> Hi Falk
>
> That plugin you mention is for QGIS 1.x. As far as I know it is not ported
> to ver 2 or ver 3 of QGIS. In the current version of QGIS a better approach
> would be to implement a convertor tool that exports QGIS’s internal format
> to FDGC. If you are interested in funding this work please chat to me, we
> have some plans to provide a generic metadata exchange library that can
> integrate with QGIS but it needs funders.
>
> Regards
>
> Tim
>
> On 4 Nov 2019, at 09:46, Paolo Cavallini  wrote:
>
> Hi Falk,
>
> Il 02/11/19 19:01, Falk Huettmann ha scritto:
>
> ...it's this one that features FGDC metadata for QGIS and which is not
> loading/dead
> http://wiki.gis-lab.info/w/Working_with_metadata_using_Metatools_for_QGIS
> but without seeing their (plugin) details my expertise ends there.
>
>
> I think you should be able to install and test the plugin on a previous
> QGIS version (2.18 should be suitable, and available through our
> archives). If this fits your needs, porting would be reasonably easy, as
> mentioned.
>
> Ideally, it needs to be updated to and include Metavist Wizard (latest
> version of the US gov)
> https://www.fgdc.gov/metadata/geospatial-metadata-tools
> listed in here:
> https://www.fgdc.gov/metadata/geospatial-metadata-tools
>
>
> let's first see if porting makes sense, then further improvements can be
> explored.
> Cheers.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> 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] too much Windows desktop notifications ?

[Régis Haubourg]

Issue opened here https://github.com/qgis/QGIS/issues/32319

Regards

Le ven. 18 oct. 2019 à 15:34, Régis Haubourg
 a écrit :
>
> Thanks Harrissou for the confirmation.
> I'll open an issue.
> Régis
>
> Le ven. 18 oct. 2019 à 15:30, DelazJ  a écrit :
> >
> > Hi Régis,
> >
> > Interesting! Just today, I told myself that I should probably open an issue 
> > report to ask to "silent" these notifications that pop up too often.
> >
> > Regards,
> > Harrissou
> >
> > Le ven. 18 oct. 2019 à 15:19, Régis Haubourg  a 
> > écrit :
> >>
> >> Hi all,
> >> we have customers raising an interesting feedback. Windows
> >> notifications are now enable since 3.4 by this PR [0]
> >>
> >> In particular, the feature count notification is raising really often
> >> and overcrowding the notification popup. See image [1]
> >>
> >> Would that be an issue to remove those feature count notifications?
> >> Or should we provide notification settings to distinguish different
> >> notifications options as we have now?
> >>
> >> [0] 
> >> https://github.com/qgis/QGIS/commit/8876270c9f1098d6c0a626c28af10a0edd9cab49
> >> [1] http://i.imgur.com/Hzj85ov.png
> >>
> >> Regards
> >> 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
___
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] too much Windows desktop notifications ?

[Régis Haubourg]

Thanks Harrissou for the confirmation.
I'll open an issue.
Régis

Le ven. 18 oct. 2019 à 15:30, DelazJ  a écrit :
>
> Hi Régis,
>
> Interesting! Just today, I told myself that I should probably open an issue 
> report to ask to "silent" these notifications that pop up too often.
>
> Regards,
> Harrissou
>
> Le ven. 18 oct. 2019 à 15:19, Régis Haubourg  a 
> écrit :
>>
>> Hi all,
>> we have customers raising an interesting feedback. Windows
>> notifications are now enable since 3.4 by this PR [0]
>>
>> In particular, the feature count notification is raising really often
>> and overcrowding the notification popup. See image [1]
>>
>> Would that be an issue to remove those feature count notifications?
>> Or should we provide notification settings to distinguish different
>> notifications options as we have now?
>>
>> [0] 
>> https://github.com/qgis/QGIS/commit/8876270c9f1098d6c0a626c28af10a0edd9cab49
>> [1] http://i.imgur.com/Hzj85ov.png
>>
>> Regards
>> 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
___
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] too much Windows desktop notifications ?

[Régis Haubourg]

Hi all,
we have customers raising an interesting feedback. Windows
notifications are now enable since 3.4 by this PR [0]

In particular, the feature count notification is raising really often
and overcrowding the notification popup. See image [1]

Would that be an issue to remove those feature count notifications?
Or should we provide notification settings to distinguish different
notifications options as we have now?

[0] https://github.com/qgis/QGIS/commit/8876270c9f1098d6c0a626c28af10a0edd9cab49
[1] http://i.imgur.com/Hzj85ov.png

Regards
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] Add support for travelling sales routing, Z-level and turn restrictions

[Régis Haubourg]

Hi again,
your points are very valid. Did your company considered in helping QGIS in
that area ?
Regards,
Régis

Le jeu. 17 oct. 2019 à 13:25, Paul Wittle 
a écrit :

> Hi,
>
> Thanks for your reply.
>
> So the rationale here is fairly simple really; we already have tools in
> QGIS but I'm not convinced they provide adequate results without turn
> restrictions and/or z-levels. The travelling sales is a completely
> different point to which I think your comments apply more directly.
>
> The tools provided as default are basic but I do think there is a
> distinction between entry level basic and simply providing a wrong answer.
> At present there is no way to stop it routing off bridges (as far as I can
> tell) so I'd like to try and fix it.
>
> The ability to do basic routing appears to be a big selling point to my
> organisation and hence my priority on it. I accept that may not be the case
> for others.
>
> The problem with pgrouting is that it relies on Postgres and we currently
> have Microsoft SQLserver and Oracle. My goal is to encourage our users to
> use QGIS but the decision about database choices is made at a high level
> and so ideally I'd like to be able to achieve something sensible without
> having to change database provider.
>
> I think it is also important to note that the existing tools appear to be
> pretty close to being able to do what I need anyway. I'm really trying to
> improve the accuracy with turn restrictions and improve the usability a
> small amount by allowing routing via waypoints. Routing via waypoints is
> basically just a slightly customisable batch function of what already
> exists and I've already achieved that using my scripts.
>
> As I said earlier, I accept that travelling sales may be a step too far
> but it seemed a logical target to me as I've spent a chunk of my career
> working as a transport planner and I see TSP routing as the entry point to
> network analysis really.
>
> I may have missed some other options as I'm not aware of routing I can use
> from GRASS etc?
>
> I completely agree with your final points and the purpose of this email /
> the proposal was to start to gather opinions on what might or might not
> work / be sensible and to gather a list of people that are interested
> really.
>
> Thanks again for your feedback as it is helpful for me to work out where
> my views sit in comparison to other QGIS users 
> Paul
>
> -Original Message-
> From: Régis Haubourg 
> Sent: 17 October 2019 11:48
> To: Paul Wittle 
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] Add support for travelling sales routing,
> Z-level and turn restrictions
>
> Hi Paul
> For my information, what is the rationale of having it 100% in QGIS? I
> tend to prefer the approach of relying on dedicated lib or tools. We
> already have pgrouting, GRASS, python libs, various projects around.
> I'm currently worried of the move we have of trying to do everything
> inside QGIS always, which starts to be a BIG project. Adding features
> should be done together by gathering maintainers, bug triagers all the time
> in mind.
> Regards
> Régis
>
> Le jeu. 17 oct. 2019 à 10:10, Paul Wittle <
> paul.wit...@dorsetcouncil.gov.uk> a écrit :
> >
> > Hi,
> >
> >
> >
> > I’ve just added an enhancement proposal (
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/159) for some
> work I would like to be involved with. I hope that is the right place to
> put it for discussion but I’m assuming there may also be some chat about it
> on here so I thought I’d start a thread.
> >
> >
> >
> > I have a young family so my intention to get developing in my spare time
> has been hampered by my lack of spare time but I think this is an area I
> would like to get involved with and I believe my current employer is
> supportive of the proposal as well so hopefully if I can kick something off
> then this might be a good starting point for me to get involved as a
> developer.
> >
> >
> >
> > I’d be keen to hear others thoughts and opinions and please accept my
> apologies if I’ve missed a similar discussion somewhere else and it turns
> out to be duplicate feature proposal.
> >
> >
> >
> > Many thanks,
> >
> > Paul
> >
> > This e-mail and any files transmitted with it are intended solely for
> > the use of the individual or entity to whom they are addressed. It may
> > contain unclassified but sensitive or protectively marked material and
> > should be handled accordingly. Unless you are the named addressee (or
> > authorised to receive it for the addressee) you may not copy or use
> 

Re: [QGIS-Developer] Add support for travelling sales routing, Z-level and turn restrictions

[Régis Haubourg]

Hi Paul
For my information, what is the rationale of having it 100% in QGIS? I
tend to prefer the approach of relying on dedicated lib or tools. We
already have pgrouting, GRASS, python libs, various projects around.
I'm currently worried of the move we have of trying to do everything
inside QGIS always, which starts to be a BIG project. Adding features
should be done together by gathering maintainers, bug triagers all the
time in mind.
Regards
Régis

Le jeu. 17 oct. 2019 à 10:10, Paul Wittle
 a écrit :
>
> Hi,
>
>
>
> I’ve just added an enhancement proposal 
> (https://github.com/qgis/QGIS-Enhancement-Proposals/issues/159) for some work 
> I would like to be involved with. I hope that is the right place to put it 
> for discussion but I’m assuming there may also be some chat about it on here 
> so I thought I’d start a thread.
>
>
>
> I have a young family so my intention to get developing in my spare time has 
> been hampered by my lack of spare time but I think this is an area I would 
> like to get involved with and I believe my current employer is supportive of 
> the proposal as well so hopefully if I can kick something off then this might 
> be a good starting point for me to get involved as a developer.
>
>
>
> I’d be keen to hear others thoughts and opinions and please accept my 
> apologies if I’ve missed a similar discussion somewhere else and it turns out 
> to be duplicate feature proposal.
>
>
>
> Many thanks,
>
> Paul
>
> This e-mail and any files transmitted with it are intended solely for the use 
> of the individual or entity to whom they are addressed. It may contain 
> unclassified but sensitive or protectively marked material and should be 
> handled accordingly. Unless you are the named addressee (or authorised to 
> receive it for the addressee) you may not copy or use it, or disclose it to 
> anyone else. If you have received this transmission in error please notify 
> the sender immediately. All traffic may be subject to recording and/or 
> monitoring in accordance with relevant legislation. Any views expressed in 
> this message are those of the individual sender, except where the sender 
> specifies and with authority, states them to be the views of Dorset Council. 
> Dorset Council does not accept service of documents by fax or other 
> electronic means. Virus checking: Whilst all reasonable steps have been taken 
> to ensure that this electronic communication and its attachments whether 
> encoded, encrypted or otherwise supplied are free from computer viruses, 
> Dorset Council accepts no liability in respect of any loss, cost, damage or 
> expense suffered as a result of accessing this message or any of its 
> attachments. For information on how Dorset Council processes your 
> information, please see www.dorsetcouncil.gov.uk/416433
> ___
> 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] 3.10 hard freeze?

[Régis Haubourg]

Hi all,

I am really confused about the hard freeze period, probably because I
am not able to explain it to anyone. Some questions:

- is there any place where the hard freeze is documented for coders and users?

- What is the expected benefit if we don't get real life testers
focused on testing?

- Isn't it a Release Candidate version we-cant'-say-its-name ? Why so?

- It seems to bring a lot of confusion between. It can cascade delays
for backports to previous LTR, if we postpone fixes, then we miss a
point release time frame, that sounds really strange to me.

- I didn't see any public announcement, so I doubt we get more tester
now than before the hard freeze tag. Did I miss something?


At this point, it doesn't look like a 'teething' problem to me.
I really start thinking we are trying to invent something that does
not exists somewhere else. We do that to try to consolidate our fixes,
which is a very valid reason.
While the attempt is nice,  I think the real issue is that we lack
beta testers. Shouldn't we rediscuss of  beta / RC releases with
installers, together with public annoucement. It is more packaging and
communication work, but I thinks this is where the most efficient
efforts rely.

I really miss a clear vision to be able to advertise it to our
funders. We are ni hard time already just explaining the roadmap and
the need for them to get in sync with it. The more complicated system
we build, the more they tend to fall back to just "wait" other test
the future LTR versions for them.
I am really concerned because I in my whole country, I identify at max
2 GIS administrators involved in testing developpement versions.

I'd appreciate any effort of explaining the rationales and how-to-use
of this hard freeze thing.

Regards
Régis


Le jeu. 17 oct. 2019 à 09:39, Nyall Dawson  a écrit :
>
> On Thu, 17 Oct 2019 at 17:35, Julien Cabieces
>  wrote:
> >
> >
> > Hi all,
> >
> > > 1. we've got one set of serious known regressions, due to the snapping
> > > threading changes. There's an open PR which may resolve these
> > > (https://github.com/qgis/QGIS/pull/31648), which still needs
> > > reviewing, merging and widespread user testing before final release.
> > > Or we can play it safe for 3.10.0 and revert the earlier threading
> > > work, pushing it back for inclusion in 3.10.1. (playing it safe would
> > > be my vote)
> >
> > Fair enough, if this work can land in 3.10.1, I will revert the initial
> > commit and push it back for 3.10.1 inclusion.
> >
> > I think I misunderstand the frozen label, I thought it was to delay
> > merging in 3.12, not in 3.10.1 ?
>
> It's used that way for features -- but otherwise it just means "don't merge!" 
> :)
>
> 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

Re: [QGIS-Developer] pyqgis - canUninstallPlugin

[Régis Haubourg]

Hi Jacky,
just put your plugin dir on a readonly file system.
Régis

Le lun. 14 oct. 2019 à 09:25, Etienne Trimaille
 a écrit :
>
> Hi,
>
> I'm adding back the QGIS dev mailing list.
>
> Le lun. 14 oct. 2019 à 08:29, VOLPES-EXT, Jacky 
>  a écrit :
>>
>> I didn’t share any code because I don’t know how to be more clear… :/
>
>
> You said your code is not working and/or not called. So without seing it, it 
> was confusing ;-)
>
>>
>> The objective would be to prevent the plugin to be uninstalled in our 
>> specific company context :
>>
>> I want every user to have a specific set of plugins already installed in 
>> their QGis environment so they don’t have to manage installations or updates 
>> of plugins (thanks to the QGIS_PLUGINPATH environment var, where I will 
>> install and update the plugins for them).
>>
>>
>>
>> But as a result, if one user decides to uninstall a plugin, it will be 
>> uninstalled for every user.
>
>
> Seems weird to change every plugin you are going to install for them by 
> adding this flag.
> So you are using a network share for all installed plugins?
> Why not a read only directory?
>
> ___
> 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] 3.10.0 in hard freeze, should we branch master as unfreeze for 3.12?

[Régis Haubourg]

Hi,
Since the hard freeze tag, I realize that many dev's didn't expect
this to happen this way. The hard freeze concept doesn't seem so
clear.
We currently have some frozen PR that we need (really) to land into
the future LTR.
We did start long time ago for each of them, it is not about late
work. But we must recognize some of those were hard work (like the
parallelized snapping cache builidng thing)
We also have features for the server waiting.
And we must recognized we need more persons for the review process to
speed up the process.

I don't think we can branch now, as it is the first time we play the
hard freeze process for real for a LTR, we have to discuss some
pending PR's.

Cheers
Régis

Le lun. 14 oct. 2019 à 09:15, Denis Rouzaud  a écrit :
>
> Hi all,
>
> I don't have a strong opinion, but it would be good to have pros and cons to 
> decide.
>
> Jürgen, since you are the release manager, are you saying it's not a good 
> idea (why?) or rather that you have to modify the procedure (meaning more 
> work)?
>
> If this situation is going to happen again, it would be nice to discuss 
> before voting and take a wise decision.
>
>
> Cheers,
> Denis
>
> Le lun. 14 oct. 2019 à 09:04, Régis Haubourg  a 
> écrit :
>>
>> Hi all,
>> Same à Jürgen , -1
>> régis
>>
>> Le lun. 14 oct. 2019 à 08:36, Jürgen E. Fischer  a écrit :
>> >
>> > Hi Nyall,
>> >
>> > On Mon, 14. Oct 2019 at 09:34:13 +1000, Nyall Dawson wrote:
>> > > (Subject says it  )
>> > >
>> > > Now that we're in hard freeze for the 3.10.0 release, should we be
>> > > branching off the release-3_10 branch now and unfreezing master for 3.12?
>> >
>> > -1 as branching is part of the release process.
>> >
>> >
>> > 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 Nordenhttps://www.norbit.de
>> > QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>> > ___
>> > 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] 3.10.0 in hard freeze, should we branch master as unfreeze for 3.12?

[Régis Haubourg]

Hi all,
Same à Jürgen , -1
régis

Le lun. 14 oct. 2019 à 08:36, Jürgen E. Fischer  a écrit :
>
> Hi Nyall,
>
> On Mon, 14. Oct 2019 at 09:34:13 +1000, Nyall Dawson wrote:
> > (Subject says it  )
> >
> > Now that we're in hard freeze for the 3.10.0 release, should we be
> > branching off the release-3_10 branch now and unfreezing master for 3.12?
>
> -1 as branching is part of the release process.
>
>
> 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 Nordenhttps://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> 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] "Needs sponsor" label? (again)

[Régis Haubourg]

Hi
I quite agree with Paolo. What about reversing the logic and add a label
"Funded by QGIS.org" when we tackle a bug or a feature with QGIS.org
ressources ?

This would also help in identifying the issues tackled by our fundings in
the long run, and help in coordinating a bit.

Regards
Régis
Le jeu. 3 oct. 2019 à 13:09, Paolo Cavallini  a
écrit :

> Hi all,
>
> On 03/10/19 09:58, Alessandro Pasotti wrote:
> >
> > Hi Nyall,
> >
> > What would be exactly the meaning of that label?
> >
> > If a developer adds that label, does that mean the she would be
> > interested in implementing the feature if she get paid for it?
> >
> > What if another developer is willing to implement it for free? She just
> > removes the label and starts working on it?
> >
> > I'm not sure we want to expose this kind of things in the issue tracker,
> > I mean we should probably use other channels and perhaps add some other
> > label that clearly indicates that there is a fundraising campaign
> > running for that particular issue/feature.
> >
> > If there is a running campaign I think it's totally fine to put a link
> > to the campaign (and a label) in the issue.
> >
> > Btw, thanks for raising the topic, in general I like very much the idea
> > to give more visibility to fund-raising campaigns (which includes
> > crowdfunding of course).
>
> in principle I'd be in favour of this, to make it clear to users that
> they can make the difference and add more responsibility upon their
> shoulders. However, I agree with Ale: what is the criteria? Every ticket
> needs resources to be fixed, so which  one would earn the label?
> If we find a reasonable (not requiring too admin work) and transparent
> (no ambiguity) way of managing this, our newsfeed in the startup window
> will be a powerful tool to implement it, as Andreas pointed out.
> Cheers.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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] No more layout page properties in contextual menu?

[Régis Haubourg]

Works here in
https://github.com/qgis/QGIS/commit/3a6cc5c2cad879d23072d756fdb9f1483aa48cad

Régis

Le lun. 30 sept. 2019 à 18:24, DelazJ  a écrit :

> Hi devs,
>
> I'm using QGIS 3.9 ea7b27ef3e and am unable to access the page properties;
> it used to be available with right-click in the layout but can't find it
> there. Browsing the menus neither shows it.
>
> Since my version is not the latest (and osgeo4w did not let me update all
> the day), can someone confirm whether it's a bug, a moved feature or me
> needing new glasses?
>
> Regards,
> Harrissou
> ___
> 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] SQL editor in DB Manager

[Régis Haubourg]

Hi Paolo,
works here with 3.4 or master 3bb77b6918
 using CTRL +

Cheers Régis

Le ven. 27 sept. 2019 à 17:51, Paolo Cavallini  a
écrit :

> Hi all,
> as far as I remember, the sql editor embedded in DB Manager had the
> capability of increasing font size with Crtl+
> Now this seems gone. I think that's a pity, as it is very useful for
> teaching purposes.
> Any hint on how to get it back?
> Thanks.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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] Performance issues while loading a big QGIS project

[Régis Haubourg]

Thanks for your feedback.
Bye!

Le mar. 24 sept. 2019 à 18:09,  a écrit :

> Hello Nyall, hello Régis,
>
>
>
> thank you for your hints. The option “Trust project when data source has
> no metadata” improved the loading time a lot. The project still needs about
> 6 minutes to load, but at least it is already an improvement. However, I
> guess, that is normal for such a large project. The plug-in “Layers menu
> from project” also looks very interesting.
>
>
>
> Kind regards,
>
> Josef
>
>
>
> *Von:* Régis Haubourg 
> *Gesendet:* Dienstag, 24. September 2019 08:30
> *An:* Nyall Dawson 
> *Cc:* Bauer.Josef extern IT-DS-TS ; QGIS Developers
> List 
> *Betreff:* Re: [QGIS-Developer] Performance issues while loading a big
> QGIS project
>
>
>
> Agreed, this should speed up the loading time of layers without metadata
> (probably postgresql views mainly in your case)
>
>
>
> If your need is to access some layers only, I recommend the
> menu_layers_from_project plugin. It will only parse the xml but not load
> the data until you choose to import some layers into a session.
>
>
>
> I also experienced that lowering the network timeout can speed up ogc
> webservice layers when the service is not responding.
>
> Regards
>
> Régis
>
>
>
> Le mar. 24 sept. 2019 à 00:49, Nyall Dawson  a
> écrit :
>
> On Tue, 24 Sep 2019 at 00:41,  wrote:
>
> >
> > Therefore, the question is, if QGIS provides a mechanism to postpone the
> initial loading of all layers from QGIS startup to the point in time when
> we actually need the layers? I.e., the layer structure is loaded but not
> the layer data.
>
> There's no such existing mechanism.
>
> Have you experiment with the setting under project properties -- data
> sources -- "Trust project when data source has no metadata"? I believe
> that was added to assist with cases like this.
>
> Nyall
>
> >
> >
> >
> > Is there a build-in QGIS mechanism that allows loading only the needed
> layers from the .qgs file and write the appropriate styles to it or is it
> planned to implement such a mechanism in QGIS?
> >
> >
> >
> > Kind regards,
> >
> > Josef
> >
> > ___
> > 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