Re: [QGIS-Developer] Why so many database calls?

[Cory Albrecht via QGIS-Developer]

So after getting very frustrated with QGIS taking literally hours to simply
delete vertices, I made a bug report

https://github.com/qgis/QGIS/issues/53973




When doing anything with vertices, QGIS makes the following set of exactly
the same (except or the cursor id) SQL queries 1 or more times for each
vertex being worked on:

Jul 27 16:54:17 postgresql-3 postgres[97809]: [2219-1] ::>[2023-07-27
16:54:17.743 EDT][64c2d4bf.17e11][97809/] 
LOG:  duration: 0.323 ms  statement: BEGIN READ ONLY;DECLARE qgis_571
BINARY CURSOR FOR SELECT
"id","names"::text,"main_rgb"::text,"border_rgb"::text,"stripe_rgb"::text,"start_date"::text,"end_date"::text,"sovereign"::text,"category"::text,"predecessors"::text,"successors"::text
FROM "bop"."timeline_level_0" WHERE "id"=143

Jul 27 16:54:17 postgresql-3 postgres[97809]: [2220-1] ::>[2023-07-27
16:54:17.744 EDT][64c2d4bf.17e11][97809/] 
LOG:  duration: 0.059 ms  statement: FETCH FORWARD 2000 FROM qgis_571

Jul 27 16:54:17 postgresql-3 postgres[97809]: [2221-1] ::>[2023-07-27
16:54:17.744 EDT][64c2d4bf.17e11][97809/] 
LOG:  duration: 0.049 ms  statement: CLOSE qgis_571;COMMIT

To remove 600 vertices selected with the vertex tool from a feature, that
set of calls was made more than 800 times.

With a second deletion of 514 vertices, there was a pause of ~34 seconds
before QGIS started making these repeated queries. It started off of pretty

Here is the PostgreSQL for doing the delete, plus the canvas redraw when
finished

queries.log <https://github.com/qgis/QGIS/files/12188596/queries.log>

Since the vertices are being removed from the in-memory copy of the feature
and and nothing is being written, it would seem the query (for whatever
reason it is being used), only needs to be done once since the result from
the database will never change.

What is the point of these excessive, seemingly needless queries?

in a later comment, I talk about how QGIS took about 28 hours to delete
roughly 2,400 vertices from a roughly 23,200 vertex feature and how the
ever increasing delay between the repetitive calls was 90 seconds, making
these unnecessary database calls the likely culprit for making it take so
long.



On Sun, Jun 25, 2023 at 3:04 PM Cory Albrecht  wrote:

> I wasn't asking anybody to fix a problem, so, no, there is no ticket. I
> was asking why the QGIS code makes thousands of SQL reads for a very simple
> operation. If all that is being done is moving a single vertex, why is
> there even a need to read from the database at all?
>
>
> On Sat, Jun 24, 2023 at 5:12 PM Alessandro Pasotti 
> wrote:
>
>> Hi Cory,
>>
>> I think many developers have one or two ideas about where to look,
>> they probably didn't have the time to look into it.
>>
>> Is there a ticket already?
>>
>>
>> On Sat, Jun 24, 2023 at 8:46 PM Cory Albrecht via QGIS-Developer
>>  wrote:
>> >
>> > So, nobody knows why QGIS makes all those seemingly wasteful SQL reads?
>> >
>> > On Fri, Jun 16, 2023 at 1:18 PM Cory Albrecht 
>> wrote:
>> >>
>> >> So QGIS took almost 2.5 hours to delete those 1,000-ish vertices,
>> spitting out those seemingly unnecessary transaction blocks every second or
>> so. Judging by the numbers of the named blocks, roughly 5,000 of them were
>> done just to delete those 1,000-ish vertices.
>> >>
>> >> Right now, on that same feature, I went to add a new vertx in the
>> middle of the gap created by the deletion of the 1,000-ish last night, drag
>> it to a new spot, and right clock to place. Those same seemingly
>> unnecessary read-only transactions with a single select are being done, but
>> at the rate of roughly 100 per second and the process takes about 7-8
>> minutes after the right click before QGIS becomes responsive again. I've
>> done it a few times this morning, exiting QGIS without saving, and same
>> thing each time.
>> >>
>> >> Why so many of these database queries?
>> >>
>> >>
>> >> On Thu, Jun 15, 2023 at 5:40 PM Cory Albrecht 
>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> So I've been trying to track down why my postgresql server was
>> getting so many Signal 10 (SUG BS, memory bus) errors. So far I have
>> figured out that they are only happening when QGIS is connecting to it
>> using GSS/Kerberos encryption. No clue yet as to which side is the culprit
>> (e.g. bad QGIS kerberised data flow, or bad PostgreSQL handling of the
>> connection). QGIS cinnectio with SSL encryption is fine.
>> >>>
>> >>> Anyways,

Re: [QGIS-Developer] Why so many database calls?

[Cory Albrecht via QGIS-Developer]

So, nobody knows why QGIS makes all those seemingly wasteful SQL reads?

On Fri, Jun 16, 2023 at 1:18 PM Cory Albrecht  wrote:

> So QGIS took almost 2.5 hours to delete those 1,000-ish vertices, spitting
> out those seemingly unnecessary transaction blocks every second or so.
> Judging by the numbers of the named blocks, roughly 5,000 of them were done
> just to delete those 1,000-ish vertices.
>
> Right now, on that same feature, I went to add a new vertx in the middle
> of the gap created by the deletion of the 1,000-ish last night, drag it to
> a new spot, and right clock to place. Those same seemingly unnecessary
> read-only transactions with a single select are being done, but at the rate
> of roughly 100 per second and the process takes about 7-8 minutes after the
> right click before QGIS becomes responsive again. I've done it a few times
> this morning, exiting QGIS without saving, and same thing each time.
>
> Why so many of these database queries?
>
>
> On Thu, Jun 15, 2023 at 5:40 PM Cory Albrecht 
> wrote:
>
>> Hello,
>>
>> So I've been trying to track down why my postgresql server was getting so
>> many Signal 10 (SUG BS, memory bus) errors. So far I have figured out that
>> they are only happening when QGIS is connecting to it using GSS/Kerberos
>> encryption. No clue yet as to which side is the culprit (e.g. bad QGIS
>> kerberised data flow, or bad PostgreSQL handling of the connection). QGIS
>> cinnectio with SSL encryption is fine.
>>
>> Anyways, while doing this I've been watching a lot of PostgreSQL server
>> logs, and I noticed the following behaviour of QGIS:
>>
>> When using the vertex editor to delete a whole slew (1,000-ish) vertices
>> from a polygon feature, I saw that QGIS was making repeated DB cals like
>> this:
>>
>> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3204-1] ::>[2023-06-15
>> 17:14:19.289 EDT][648b7d94.15460][87136/]  LOG:
>>  duration: 0.330 ms  statement: BEGIN READ ONLY;DECLARE qgis_1062 BINARY
>> CURSOR FOR SELECT
>> "feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
>> FROM "Balance of Power"."timeline_level0" WHERE
>> "feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
>> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3205-1] ::>[2023-06-15
>> 17:14:19.290 EDT][648b7d94.15460][87136/]  LOG:
>>  duration: 0.628 ms  statement: FETCH FORWARD 2000 FROM qgis_1062
>> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3206-1] ::>[2023-06-15
>> 17:14:19.291 EDT][648b7d94.15460][87136/]  LOG:
>>  duration: 0.045 ms  statement: CLOSE qgis_1062;COMMIT
>>
>> An example of the QGIS console output:
>>
>> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [4ms] 2023-06-15T17:37:08
>> PostGIS[1] NOTICE: LOG:  duration: 0.399 ms  statement: FETCH FORWARD 2000
>> FROM qgis_2017
>> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023-06-15T17:37:08
>> PostGIS[1] NOTICE: LOG:  duration: 0.035 ms  statement: CLOSE
>> qgis_2017;COMMIT
>> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [3ms] 2023-06-15T17:37:08
>> PostGIS[1] NOTICE: LOG:  duration: 0.240 ms  statement: BEGIN READ
>> ONLY;DECLARE qgis_2018 BINARY CURSOR FOR SELECT
>> "feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
>> FROM "Balance of Power"."timeline_level0" WHERE
>> "feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
>> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [2ms] 2023-06-15T17:37:08
>> PostGIS[1] NOTICE: LOG:  duration: 0.406 ms  statement: FETCH FORWARD 2000
>> FROM qgis_2018
>> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023

Re: [QGIS-Developer] Why so many database calls?

[Cory Albrecht via QGIS-Developer]

So QGIS took almost 2.5 hours to delete those 1,000-ish vertices, spitting
out those seemingly unnecessary transaction blocks every second or so.
Judging by the numbers of the named blocks, roughly 5,000 of them were done
just to delete those 1,000-ish vertices.

Right now, on that same feature, I went to add a new vertx in the middle of
the gap created by the deletion of the 1,000-ish last night, drag it to a
new spot, and right clock to place. Those same seemingly unnecessary
read-only transactions with a single select are being done, but at the rate
of roughly 100 per second and the process takes about 7-8 minutes after the
right click before QGIS becomes responsive again. I've done it a few times
this morning, exiting QGIS without saving, and same thing each time.

Why so many of these database queries?


On Thu, Jun 15, 2023 at 5:40 PM Cory Albrecht  wrote:

> Hello,
>
> So I've been trying to track down why my postgresql server was getting so
> many Signal 10 (SUG BS, memory bus) errors. So far I have figured out that
> they are only happening when QGIS is connecting to it using GSS/Kerberos
> encryption. No clue yet as to which side is the culprit (e.g. bad QGIS
> kerberised data flow, or bad PostgreSQL handling of the connection). QGIS
> cinnectio with SSL encryption is fine.
>
> Anyways, while doing this I've been watching a lot of PostgreSQL server
> logs, and I noticed the following behaviour of QGIS:
>
> When using the vertex editor to delete a whole slew (1,000-ish) vertices
> from a polygon feature, I saw that QGIS was making repeated DB cals like
> this:
>
> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3204-1] ::>[2023-06-15
> 17:14:19.289 EDT][648b7d94.15460][87136/]  LOG:
>  duration: 0.330 ms  statement: BEGIN READ ONLY;DECLARE qgis_1062 BINARY
> CURSOR FOR SELECT
> "feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
> FROM "Balance of Power"."timeline_level0" WHERE
> "feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3205-1] ::>[2023-06-15
> 17:14:19.290 EDT][648b7d94.15460][87136/]  LOG:
>  duration: 0.628 ms  statement: FETCH FORWARD 2000 FROM qgis_1062
> Jun 15 17:14:19 postgresql-3 postgres[87136]: [3206-1] ::>[2023-06-15
> 17:14:19.291 EDT][648b7d94.15460][87136/]  LOG:
>  duration: 0.045 ms  statement: CLOSE qgis_1062;COMMIT
>
> An example of the QGIS console output:
>
> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [4ms] 2023-06-15T17:37:08
> PostGIS[1] NOTICE: LOG:  duration: 0.399 ms  statement: FETCH FORWARD 2000
> FROM qgis_2017
> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023-06-15T17:37:08
> PostGIS[1] NOTICE: LOG:  duration: 0.035 ms  statement: CLOSE
> qgis_2017;COMMIT
> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [3ms] 2023-06-15T17:37:08
> PostGIS[1] NOTICE: LOG:  duration: 0.240 ms  statement: BEGIN READ
> ONLY;DECLARE qgis_2018 BINARY CURSOR FOR SELECT
> "feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
> FROM "Balance of Power"."timeline_level0" WHERE
> "feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [2ms] 2023-06-15T17:37:08
> PostGIS[1] NOTICE: LOG:  duration: 0.406 ms  statement: FETCH FORWARD 2000
> FROM qgis_2018
> ./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023-06-15T17:37:08
> PostGIS[1] NOTICE: LOG:  duration: 0.034 ms  statement: CLOSE
> qgis_2018;COMMIT
>
>
>
> That is repeated 4 times every couple of seconds as I wait for QGIS to
> finish deleting these 1,000-ish vertices. So far it's at begin block
> qgis_2058 (increasing sequentially) and it's been 20+ minutes that QGIS has
> been frozen, CPU usage for the process jumping around betwe

[QGIS-Developer] Why so many database calls?

[Cory Albrecht via QGIS-Developer]

Hello,

So I've been trying to track down why my postgresql server was getting so
many Signal 10 (SUG BS, memory bus) errors. So far I have figured out that
they are only happening when QGIS is connecting to it using GSS/Kerberos
encryption. No clue yet as to which side is the culprit (e.g. bad QGIS
kerberised data flow, or bad PostgreSQL handling of the connection). QGIS
cinnectio with SSL encryption is fine.

Anyways, while doing this I've been watching a lot of PostgreSQL server
logs, and I noticed the following behaviour of QGIS:

When using the vertex editor to delete a whole slew (1,000-ish) vertices
from a polygon feature, I saw that QGIS was making repeated DB cals like
this:

Jun 15 17:14:19 postgresql-3 postgres[87136]: [3204-1] ::>[2023-06-15
17:14:19.289 EDT][648b7d94.15460][87136/]  LOG:
 duration: 0.330 ms  statement: BEGIN READ ONLY;DECLARE qgis_1062 BINARY
CURSOR FOR SELECT
"feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
FROM "Balance of Power"."timeline_level0" WHERE
"feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
Jun 15 17:14:19 postgresql-3 postgres[87136]: [3205-1] ::>[2023-06-15
17:14:19.290 EDT][648b7d94.15460][87136/]  LOG:
 duration: 0.628 ms  statement: FETCH FORWARD 2000 FROM qgis_1062
Jun 15 17:14:19 postgresql-3 postgres[87136]: [3206-1] ::>[2023-06-15
17:14:19.291 EDT][648b7d94.15460][87136/]  LOG:
 duration: 0.045 ms  statement: CLOSE qgis_1062;COMMIT

An example of the QGIS console output:

./src/core/qgsmessagelog.cpp:29 : (logMessage) [4ms] 2023-06-15T17:37:08
PostGIS[1] NOTICE: LOG:  duration: 0.399 ms  statement: FETCH FORWARD 2000
FROM qgis_2017
./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023-06-15T17:37:08
PostGIS[1] NOTICE: LOG:  duration: 0.035 ms  statement: CLOSE
qgis_2017;COMMIT
./src/core/qgsmessagelog.cpp:29 : (logMessage) [3ms] 2023-06-15T17:37:08
PostGIS[1] NOTICE: LOG:  duration: 0.240 ms  statement: BEGIN READ
ONLY;DECLARE qgis_2018 BINARY CURSOR FOR SELECT
"feature_uuid"::text,"name"::text,"start_date"::text,"end_date"::text,"main_rgb"::text,"realm_uuid"::text,"stripe_rgb"::text,"border_rgb"::text,"border_shade"::text,"sovereign"::text,"type"::text,"info_url"::text,array_out("predecessors")::text,array_out("successors")::text,boolout("visible")::text,boolout("has_children")::text,"full_name"::text,"alternate_name"::text,"flag_url"::text
FROM "Balance of Power"."timeline_level0" WHERE
"feature_uuid"::text='fbbec581-eb8f-4068-8729-8f9d63896bd5'
./src/core/qgsmessagelog.cpp:29 : (logMessage) [2ms] 2023-06-15T17:37:08
PostGIS[1] NOTICE: LOG:  duration: 0.406 ms  statement: FETCH FORWARD 2000
FROM qgis_2018
./src/core/qgsmessagelog.cpp:29 : (logMessage) [1ms] 2023-06-15T17:37:08
PostGIS[1] NOTICE: LOG:  duration: 0.034 ms  statement: CLOSE
qgis_2018;COMMIT



That is repeated 4 times every couple of seconds as I wait for QGIS to
finish deleting these 1,000-ish vertices. So far it's at begin block
qgis_2058 (increasing sequentially) and it's been 20+ minutes that QGIS has
been frozen, CPU usage for the process jumping around between 100% and 300%.

(Before you ask, Fall 2021 Dell XPS 9510, 11th Gen Intel Core i9-11900H @
2.50GHz 8 cores, 64GB RAM.)

So why is it repeatedly making database calls to get the non geometry
attributes of that same singular feature? Why can't it just use the cached
data instead of making all these wasteful DB queries?

And why is it taking so long to delete the vertices? Is it related to all
the unnecessary DB queries?
___
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] bug 48946

[Cory Albrecht via QGIS-Developer]

Hello,

Does anybody know when bug 48946 will get looked at? It's a
temporal controller regression with an example project provided six weeks
ago.

https://github.com/qgis/QGIS/issues/48946

Thanks in advance.
___
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] Donations

[Cory Albrecht]

> Honestly, whether this is a bug or a feature request is debatable, I
personally think that it is a bug because a user would not expect that a
basic software action like editing gets broken when the temporal controller
is active: we should either disable editing in that case or make editing
work with the controller.

That was my thought, too. Also, what is the point of having a
presentation-only tool for temporal data in QGIS if you cannot practically
or effectively edit that temporal data in QGIS as well?

On Mon, Jan 17, 2022 at 10:38 AM Alessandro Pasotti 
wrote:

>
> Hi,
>
> Honestly, whether this is a bug or a feature request is debatable, I
> personally think that it is a bug because a user would not expect that a
> basic software action like editing gets broken when the temporal controller
> is active: we should either disable editing in that case or make editing
> work with the controller.
>
> Anyway, I just wanted to underline that if this is to be considered a
> feature request it wouldn't be eligible for a grant (that explicitly
> forbids new features).
>
> Kind regards.
>
>
> On Mon, Jan 17, 2022 at 4:28 PM Andreas Neumann  wrote:
>
>> Hi Cory,
>>
>> Yes - I would also think that this is not a bug, but a feature request.
>> It was never claimed that the temporal controller works fine in conjunction
>> with editing tools. The temporal controller was designed as a presentation
>> tool and not for editing.
>>
>> To improve the situation you would have to consult with one of the core
>> contributor companies listed at
>> https://www.qgis.org/en/site/forusers/commercial_support.html
>>
>> You could write a specification, ask one of the core contributor
>> companies for a quote and finance it yourself. Or you could try to write a
>> QEP (QGIS enhancement proposal) and submit it as a QGIS grant project.
>> Incidentally, Anita just issued the "Call for participation
>> <https://blog.qgis.org/2022/01/16/qgis-grants-7-call-for-grant-proposals-2022/>"
>> for the 2022 QGIS grants. If you could find a company that is interested in
>> working on this, and team up with them to write a QEP, it could be
>> submitted as a QGIS grant. The deadline for the QGIS grants is February 13.
>>
>> This would definitely be more work than what could be covered by smaller
>> donations.
>>
>> Hope this helps,
>> Andreas
>>
>> On Mon, 17 Jan 2022 at 01:21, Cory Albrecht  wrote:
>>
>>> I filed a number of bugs a year ago about various digitising tools that
>>> no longer worked correctly as a result of the newly implemented Dynamic
>>> Temporal Controller. Things like the vertex tool and the snapping tool that
>>> continue to react to invisible features outside of temporal scope making it
>>> difficult, if not impossible to use those tools with temporal data.
>>>
>>> The bugs were, unfortunately, reclassified as feature requests, and have
>>> not been fixed since. I'd like to see them fixed because they cause me much
>>> difficulty and frustration when I am using QGIS.
>>>
>>> On Sun, Jan 16, 2022 at 12:54 PM Andreas Neumann 
>>> wrote:
>>>
>>>> Hi Cory,
>>>>
>>>> We don't offer targeted donations where you can influence a specific
>>>> bug fix. If you need that - please contact one of the QGIS commercial
>>>> support providers - see
>>>> https://www.qgis.org/en/site/forusers/commercial_support.html
>>>>
>>>> Primarily one of the "core contributors".
>>>>
>>>> What specific issue do you want to see fixed?
>>>>
>>>> Andreas
>>>>
>>>> On Sun, 16 Jan 2022 at 18:46, Cory Albrecht 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Whom do I contact to make sure that a donation goes for development
>>>>> work on a specific bug or feature? The Donations doesn;t list any contacts
>>>>> except for tax deductions.
>>>>> ___
>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --
>>>> Andreas Neumann
>>>> QGIS.ORG board member (treasurer)
>>>>
>>>
>>
>> --
>>
>> --
>> Andreas Neumann
>> QGIS.ORG board member (treasurer)
>> ___
>> 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
> 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] Donations

[Cory Albrecht]

Hello,

Whom do I contact to make sure that a donation goes for development work on
a specific bug or feature? The Donations doesn;t list any contacts except
for tax deductions.
___
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] Temporal controller issues

[Cory Albrecht]

me frame and seeing that only matching features were drawn on
the map canvas?


> 3. If you're asking for the pace of feature development to be slowed

then that problem was addressed years ago when the LTR releases were

introduced.


No, not at all. That was purely a semantics comment about not using
standard terminology, which makes things confusing.


> The QGIS website is quite clear in advertising the LTR as the officially
recommended version for stability and for mission critical work, while the
non-LTR releases are clearly branded as "bleeding edge".


I would disagree about that clarity. When you go to the main page, for
example, there's just a download button with text underneath saying
"Version 3.16.2 Version 3.10.13 LTR". On the download page it just says
"riches on features" and "most stable". And the user manual for 3.16 itself
says "We recommend that you use this version over previous releases."


I couldn't find anything with the qgis.org search feature that says what
you say here.


> I'd make the case that in the situation you've described you should never
have been using the non-LTR release


Unfortunately I've been somewhat forced into using master because other
bugs I have reported about how QGIS handles array fields in PostGIS layers.
Without those fixes I sometimes couldn't even work on my maps because I
couldn't save features without data corruption, or sometimes not even save
at all. Those fixes, when they finally got done (and some still aren't),
took a while to end up in the LTR.


> So I ask again, in the full spirit of reconciliation and moving forward:
what concrete, practical changes do YOU think the project should make?


Testing, like I mentioned above. Better testing.


The NTC affects what gets displayed on the map canvas, therefore other
tools that operate on features on the map canvas should have been tested to
see how the interacted with the NTC. "Does my new capability hide features
from the map canvas? I should test the tools that one can use on features
on the the map canvas to make sure it doesn't operate on the features
hidden by my new capability.” Do you see how it looks like that type of
testing was not done before the branch with the NTC got merged with master?

On Tue, Jan 5, 2021 at 5:00 AM Nyall Dawson  wrote:

> On Tue, 5 Jan 2021 at 05:42, Cory Albrecht  wrote:
> >
> > > Please be very wary of your language in future -- every piece of
> feedback worded like this directly equates to a developer losing interest
> in volunteering their time on QGIS, to the harm of all.
> >
> > I hear what you're saying, Nyall, I apologise if it sounded harsh, but
> what do you want me to say after I find out that the latest of several bugs
> has compromised my data and now I have to hunt down an unknown number of
> duplicates silently created over the last few months of work? If you
> empathise, do you understand how all these bugs and my data being
> compromised might make me feel that this feature was not done very well and
> that there was a lack of adequate testing?
> >
> > > As background, I implemented time handling for vector layers as a
> VOLUNTEER (completely unpaid). Would you have preferred I didn't do this,
> and we had no time support for vectors at all?
> >
> > As to what I would have preferred, well, I've reverted back to 3.10 to
> use the old TimeManager plugin to avoid using the NTC. I would have
> preferred that the feature branch you used to implement the NTC had not
> gotten merged and the feature included in release versions until it had
> been checked to work with and not break basic features like the selection
> tool. So now I have to work under some Damoclean time limit for a couple of
> months until 3.16 replaces 3.10 and I will have no choice but to move to a
> version with the NTC and these bugs.
>
> Full disclosure: I don't even really consider these issues as bugs.
> Functionality gaps, yes, but it's important to keep in mind that the
> new temporal framework was designed primarily around visualisation of
> time based data, and that using it for data analysis has been a
> secondary goal which has been slowly chipped away at since the initial
> implementation. The selection tool was NEVER broken, it was just never
> upgraded to be time aware. There's plenty of features in  QGIS which
> don't completely work alongside each other, and these are not always
> bugs but often are feature requests.
>
> I'd rather shelve that part of the discussion now, because I suspect
> we'll just keep going around in circles here at increasing levels of
> emotion, and I don't think that's healthy. I realise there's hurt
> here, but I DO think you are a valuable member of this community and
> I've much appreciated your previous diligence with submitting

Re: [QGIS-Developer] Temporal controller issues

[Cory Albrecht]

> I hear what you're saying, Nyall, I apologise if it sounded harsh, but
what do you want me to say after I find out that the latest of several bugs
has compromised my data and now I have to hunt down an unknown number of
duplicates silently created over the last few months of work? If you
empathise, do you understand how all these bugs and my data being
compromised might make me feel that this feature was not done very well and
that there was a lack of adequate testing?

And now I just found that I have data loss as well, not just a bunch of
duplicates.

On Mon, Jan 4, 2021 at 2:40 PM Cory Albrecht  wrote:

> > Please be very wary of your language in future -- every piece of
> feedback worded like this directly equates to a developer losing interest
> in volunteering their time on QGIS, to the harm of all.
>
> I hear what you're saying, Nyall, I apologise if it sounded harsh, but
> what do you want me to say after I find out that the latest of several bugs
> has compromised my data and now I have to hunt down an unknown number of
> duplicates silently created over the last few months of work? If you
> empathise, do you understand how all these bugs and my data being
> compromised might make me feel that this feature was not done very well and
> that there was a lack of adequate testing?
>
> > As background, I implemented time handling for vector layers as a VOLUNTEER
> (completely unpaid). Would you have preferred I didn't do this, and we
> had no time support for vectors at all?
>
> As to what I would have preferred, well, I've reverted back to 3.10 to use
> the old TimeManager plugin to avoid using the NTC. I would have preferred
> that the feature branch you used to implement the NTC had not gotten merged
> and the feature included in release versions until it had been checked to
> work with and not break basic features like the selection tool. So now I
> have to work under some Damoclean time limit for a couple of months until
> 3.16 replaces 3.10 and I will have no choice but to move to a version with
> the NTC and these bugs.
>
> On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson 
> wrote:
>
>> On Sat, 2 Jan 2021 at 10:23, Cory Albrecht  wrote:
>> >
>> > Can somebody help me under the basics of how things work inside QGIS
>> starting from when it loads all the features for a layer through the steps,
>> and then finally drawing them on the map canvas, specifically with respect
>> to the new temporal controller (NTC)?
>> >
>> > The issues caused by the NTC have been very frustrating for me as I
>> make mostly (historical) timeline maps and I relied heavily on the old
>> TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now
>> much more laborious or difficult because so many tools are just not
>> time-aware.
>> >
>> > Was it not possible to add the NTC in such a way that would have still
>> let all the other features work as before with the filtered feature set
>> before being made time-aware, rather than confusingly operating on the
>> unfiltered set? Or perhaps it shouldn't have been turned on until the
>> infrastructure was there for the tools to be time-aware right away?
>> >
>> > Because I've just submitted yet another bug about the NTC, this time
>> for the selection tool, and it has me more than a little annoyed. As a
>> result of this bug I now have an unknown number of duplicate objects in
>> multiple layers across multiple databases/projects that I unknowingly
>> pasted into them over the past several months since the NTC was added to
>> QGIS.
>> >
>> > I feel that the NTC was both poorly thought out and badly implemented
>> as all these bugs would indicate.
>>
>> I can empathise with your frustration, but this is a very complex
>> discussion!
>>
>> As background, I implemented time handling for vector layers as a
>> VOLUNTEER (completely unpaid). Would you have preferred I didn't do
>> this, and we had no time support for vectors at all? Please be very
>> wary of your language in future -- every piece of feedback worded like
>> this directly equates to a developer losing interest in volunteering
>> their time on QGIS, to the harm of all.
>>
>> I've fixed two of your issues here
>> https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER.
>> Without funding I'm just not interested in fixing the snapping related
>> issues. I don't personally have any need for these, and the QGIS
>> snapping code isn't something I'm motivated in getting involved with
>> at all. Perhaps there's another developer interested in looking at
>> this, or per

Re: [QGIS-Developer] Temporal controller issues

[Cory Albrecht]

> Please be very wary of your language in future -- every piece of feedback
worded like this directly equates to a developer losing interest in
volunteering their time on QGIS, to the harm of all.

I hear what you're saying, Nyall, I apologise if it sounded harsh, but what
do you want me to say after I find out that the latest of several bugs has
compromised my data and now I have to hunt down an unknown number of
duplicates silently created over the last few months of work? If you
empathise, do you understand how all these bugs and my data being
compromised might make me feel that this feature was not done very well and
that there was a lack of adequate testing?

> As background, I implemented time handling for vector layers as a VOLUNTEER
(completely unpaid). Would you have preferred I didn't do this, and we had
no time support for vectors at all?

As to what I would have preferred, well, I've reverted back to 3.10 to use
the old TimeManager plugin to avoid using the NTC. I would have preferred
that the feature branch you used to implement the NTC had not gotten merged
and the feature included in release versions until it had been checked to
work with and not break basic features like the selection tool. So now I
have to work under some Damoclean time limit for a couple of months until
3.16 replaces 3.10 and I will have no choice but to move to a version with
the NTC and these bugs.

On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson  wrote:

> On Sat, 2 Jan 2021 at 10:23, Cory Albrecht  wrote:
> >
> > Can somebody help me under the basics of how things work inside QGIS
> starting from when it loads all the features for a layer through the steps,
> and then finally drawing them on the map canvas, specifically with respect
> to the new temporal controller (NTC)?
> >
> > The issues caused by the NTC have been very frustrating for me as I make
> mostly (historical) timeline maps and I relied heavily on the old
> TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now
> much more laborious or difficult because so many tools are just not
> time-aware.
> >
> > Was it not possible to add the NTC in such a way that would have still
> let all the other features work as before with the filtered feature set
> before being made time-aware, rather than confusingly operating on the
> unfiltered set? Or perhaps it shouldn't have been turned on until the
> infrastructure was there for the tools to be time-aware right away?
> >
> > Because I've just submitted yet another bug about the NTC, this time for
> the selection tool, and it has me more than a little annoyed. As a result
> of this bug I now have an unknown number of duplicate objects in multiple
> layers across multiple databases/projects that I unknowingly pasted into
> them over the past several months since the NTC was added to QGIS.
> >
> > I feel that the NTC was both poorly thought out and badly implemented as
> all these bugs would indicate.
>
> I can empathise with your frustration, but this is a very complex
> discussion!
>
> As background, I implemented time handling for vector layers as a
> VOLUNTEER (completely unpaid). Would you have preferred I didn't do
> this, and we had no time support for vectors at all? Please be very
> wary of your language in future -- every piece of feedback worded like
> this directly equates to a developer losing interest in volunteering
> their time on QGIS, to the harm of all.
>
> I've fixed two of your issues here
> https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER.
> Without funding I'm just not interested in fixing the snapping related
> issues. I don't personally have any need for these, and the QGIS
> snapping code isn't something I'm motivated in getting involved with
> at all. Perhaps there's another developer interested in looking at
> this, or perhaps a developer will take a look at this during the 3.18
> bug sprint. Or maybe someone will pay for this fix and financial gain
> will be the motivation.
>
> I like making the world a better place through volunteering my time on
> making a first-class desktop mapping application, but I'm far from
> being a slave to this, and my family, garden, and drum kit want my
> time too!
>
> 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] Temporal controller issues

[Cory Albrecht]

> I understand your frustration,

Thank you.

> the usual recommendation is to use the
LTR version (currently 3.10) if you want stability, any other version
(especially master) is risky.

Using a version labelled as "release" shouldn't be risky, though. Calling
it a "release" implies that a level of testing has been done so that users
can trust that no existing functionality that was not changed has been
broken. A release is what you would give out to paying customers if this
were a for-profit company. You'd never give out a release version with a
new feature that broke so many other features to paying customers, would
you? No. You'd call that a "public beta" or "pre-release" or a "release
candidate" that you give them for free to help find those unexpected use
cases. (And I reiterate—long-standing internal tools like selection,
vertex editor, and identify features should not be "unexpected use cases".)

So if 3.16, referred to as a "release", is really a risky public beta that
you cannot trust to be stable, as you imply here that it is, might I
suggest that non-standard and therefore confusing terminology was adopted?

On Sat, Jan 2, 2021 at 12:48 PM Alessandro Pasotti 
wrote:

> On Sat, Jan 2, 2021 at 6:34 PM Cory Albrecht  wrote:
> >
> > > Let's try to stay positive. NTC is still young, and rapidly evolving.
> It is hard to keep up with all (possible) use cases.
> >
> > I didn't say all possible use cases though. Basic tools—like identify,
> select, and the vertex editor—should not break when one adds a new feature
> as they are commonly used tools and easy enough to test during development.
> "Hey, I'm making a new feature that altes what is shown on the map canvas.
> I should do a few tests with common tools that a person uses on the visible
> items on the map canvas."
> >
> > My day job is that of a medical software developer and I have to think
> multiple steps ahead like that when working on a new feature branch or if I
> am reviewing somebody elses new branch before it gets merged with master.
> If I don't, I get poor performance reviews. When I file new bugs almost
> every day that I use QGIS about something else being broken by the NTC, can
> you understand how it looks to me like it was not up to snuff in the
> quality department before merging into master?
>
> Hi Cory,
>
> Unfortunately we are not a company and we don't have "departments" but
> there is an ongoing effort to start a community driven QA team:
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/180, it
> looks very promising to prevent this kind of issue.
>
> I understand your frustration, the usual recommendation is to use the
> LTR version (currently 3.10) if you want stability, any other version
> (especially master) is risky.
>
> Kind regards.
>
> >
> > On Sat, Jan 2, 2021 at 6:17 AM Richard Duivenvoorde 
> wrote:
> >>
> >> On 1/2/21 1:17 AM, Cory Albrecht wrote:
> >> > Can somebody help me under the basics of how things work inside QGIS
> starting from when it loads all the features for a layer through the steps,
> and then finally drawing them on the map canvas, specifically with respect
> to the new temporal controller (NTC)?
> >> >
> >> > The issues caused by the NTC have been very frustrating for me as I
> make mostly (historical) timeline maps and I relied heavily on the old
> TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now
> much more laborious or difficult because so many tools are just not
> time-aware.
> >> >
> >> > Was it not possible to add the NTC in such a way that would have
> still let all the other features work as before with the filtered feature
> set before being made time-aware, rather than confusingly operating on the
> unfiltered set? Or perhaps it shouldn't have been turned on until the
> infrastructure was there for the tools to be time-aware right away?
> >> >
> >> > Because I've just submitted yet another bug about the NTC, this time
> for the selection tool <https://github.com/qgis/QGIS/issues/40818>, and
> it has me more than a little annoyed. As a result of this bug I now have an
> unknown number of duplicate objects in multiple layers across multiple
> databases/projects that I unknowingly pasted into them over the past
> several months since the NTC was added to QGIS.
> >> >
> >> > I feel that the NTC was both poorly thought out and badly implemented
> as all these bugs would indicate.
> >>
> >> Hi Cory,
> >>
> >> Let's try to stay positive. NTC is still young, and rapidly evolving.
> It is hard to keep up with all

Re: [QGIS-Developer] Temporal controller issues

[Cory Albrecht]

> Let's try to stay positive. NTC is still young, and rapidly evolving. It
is hard to keep up with all (possible) use cases.

I didn't say all possible use cases though. Basic tools—like identify,
select, and the vertex editor—should not break when one adds a new feature
as they are commonly used tools and easy enough to test during development.
"Hey, I'm making a new feature that altes what is shown on the map canvas.
I should do a few tests with common tools that a person uses on the visible
items on the map canvas."

My day job is that of a medical software developer and I have to think
multiple steps ahead like that when working on a new feature branch or if I
am reviewing somebody elses new branch before it gets merged with master.
If I don't, I get poor performance reviews. When I file new bugs almost
every day that I use QGIS about something else being broken by the NTC, can
you understand how it looks to me like it was not up to snuff in the
quality department before merging into master?

On Sat, Jan 2, 2021 at 6:17 AM Richard Duivenvoorde 
wrote:

> On 1/2/21 1:17 AM, Cory Albrecht wrote:
> > Can somebody help me under the basics of how things work inside QGIS
> starting from when it loads all the features for a layer through the steps,
> and then finally drawing them on the map canvas, specifically with respect
> to the new temporal controller (NTC)?
> >
> > The issues caused by the NTC have been very frustrating for me as I make
> mostly (historical) timeline maps and I relied heavily on the old
> TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now
> much more laborious or difficult because so many tools are just not
> time-aware.
> >
> > Was it not possible to add the NTC in such a way that would have still
> let all the other features work as before with the filtered feature set
> before being made time-aware, rather than confusingly operating on the
> unfiltered set? Or perhaps it shouldn't have been turned on until the
> infrastructure was there for the tools to be time-aware right away?
> >
> > Because I've just submitted yet another bug about the NTC, this time for
> the selection tool <https://github.com/qgis/QGIS/issues/40818>, and it
> has me more than a little annoyed. As a result of this bug I now have an
> unknown number of duplicate objects in multiple layers across multiple
> databases/projects that I unknowingly pasted into them over the past
> several months since the NTC was added to QGIS.
> >
> > I feel that the NTC was both poorly thought out and badly implemented as
> all these bugs would indicate.
>
> Hi Cory,
>
> Let's try to stay positive. NTC is still young, and rapidly evolving. It
> is hard to keep up with all (possible) use cases. In my case it was nice
> that the select tool DID return ALL features (as I needed it to create a
> graph in time of measurements in one point). So I proposed earlier (cannot
> find it now), to make this an option in the select tools: "use/not use Time
> Filter". But this all takes time ;-)
>
> In the meantime:
> - you can maybe use "Delete duplicate geometries" [0] to remove the
> duplicates?
> - if really in need of the old TimeManager, you can change the
> metadata.txt so OTM will still work in current master. In this line:
> https://github.com/anitagraser/TimeManager/blob/master/metadata.txt#L7
> change '3.12' to '3.18'
> - if you need MemoryLayers to work (like I did), then you have to add
> another patch. Let me know if you need that.
>
> In the meantime: everybody involved in TimeBased data: let's discuss
> use-cases and make NTC better... in time...
>
> Regards,
>
> Richard Duivenvoorde
>
> [0]
> https://gis.stackexchange.com/questions/133207/removing-overlapping-duplicate-polygons-in-same-layer-using-qgis/133221
> ___
> 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] Temporal controller issues

[Cory Albrecht]

Can somebody help me under the basics of how things work inside QGIS
starting from when it loads all the features for a layer through the steps,
and then finally drawing them on the map canvas, specifically with respect
to the new temporal controller (NTC)?

The issues caused by the NTC have been very frustrating for me as I make
mostly (historical) timeline maps and I relied heavily on the old
TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now
much more laborious or difficult because so many tools are just not
time-aware.

Was it not possible to add the NTC in such a way that would have still let
all the other features work as before with the filtered feature set before
being made time-aware, rather than confusingly operating on the
unfiltered set? Or perhaps it shouldn't have been turned on until the
infrastructure was there for the tools to be time-aware right away?

Because I've just submitted yet another bug about the NTC, this time for
the selection tool , and it has
me more than a little annoyed. As a result of this bug I now have an
unknown number of duplicate objects in multiple layers across multiple
databases/projects that I unknowingly pasted into them over the past
several months since the NTC was added to QGIS.

I feel that the NTC was both poorly thought out and badly implemented as
all these bugs would indicate.
___
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

[Cory Albrecht]

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 <https://github.com/qgis/QGIS/commit/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] QGIS Website down

[Cory Albrecht]

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?
___
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] New version notifications

[Cory Albrecht]

Except I got the package from QGIS's *own* repo, as I indicated. If QGIS is
going to be alerting me that there is a new version, shouldn't that new
version be available in the QGIS repo?

On Mon, Jun 3, 2019 at 12:11 PM Tim Sutton  wrote:

> It takes the version status from QGIS.org not from the repositories. When
> the actual package arrives depends on your package repo etc.
>
> Regards
>
> Tim
>
> On 3 Jun 2019, at 00:16, Cory Albrecht  wrote:
>
> Why does QGIS alert about newer versions before the version is even
> available in something like the Debian/Ubuntu repos at
> http://qgis.org/ubuntu-nightly-release ?
> ___
> 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
> <https://calendly.com/timlinux> 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] New version notifications

[Cory Albrecht]

Why does QGIS alert about newer versions before the version is even
available in something like the Debian/Ubuntu repos at
http://qgis.org/ubuntu-nightly-release ?
___
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] Why was selection tool behaviour changed in 3.x?

[Cory Albrecht]

> It's not true to say that QGIS is an outlier:

I think it's quite fair to say that it is the outlier, and I gave a bunch
of example where click+drag is the norm and aI gave anumber of exmaples.
Click+drag is ubiquitous. Next time you go into a text field of the feature
attributes form to edit that text attribute, let me know how much text you
select by doing click-move-click instead of click+drag. :-)

> along with the reasons Jo mentions and increasing the ability to be more
accurate if you don't have to hold down the button

I would disagree that having to hold the button down while selecting makes
it less accurate as it doesn't affect how much you are able to flex your
wrist or add to stress on the carpal tunnel. Click or no click, you wrist
would make the same movements. Given the ubiquity of click+track in the
computer world, choosing that offer the better UX experience to the users
because it doesn't requires them to relearn how they do simple, common
actions for just one application.

Especially the regular "Select Feature(s)" tool (not polygon, freehand or
radius) does requires you to click and drag. If carpal tunnel issues and
accuracy were actual issues/reasons, then this tool also should have been
change to click, move, left-click to end just like the other selection
tools were changed. That lack of consistency leads to a frustrating
experience for the user, ask any UX designer.

> was to align with the behaviour of CAD, which does use "click-click",
rather than click-and-drag.

How many people who start using QGIS were CAD users beforehand? I suspect
that even minimally experienced CAD users are in the minority. If there is
a decent chunk that could benefit from such a UX/UI change, perhaps it
would have been more appropriate to make that a switch in the settings that
would change the behaviours?

On Wed, Apr 10, 2019 at 6:40 AM Tom Chadwin  wrote:

> Hi Cory
>
> From memory, there was a lot of discussion about making this change in the
> vertex editor. It's not true to say that QGIS is an outlier: the rationale
> behind the change - along with the reasons Jo mentions and increasing the
> ability to be more accurate if you don't have to hold down the button - was
> to align with the behaviour of CAD, which does use "click-click", rather
> than click-and-drag.
>
> Tom
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.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

Re: [QGIS-Developer] Why was selection tool behaviour changed in 3.x?

[Cory Albrecht]

> I would like to see a mode where the node that will be moved is
autoselected based on proximity to the mouse pointer.

That would be a UX prone to mistakes unless it had to be explicitly turned
on and very visible when on. :-)

On Mon, Apr 8, 2019 at 11:23 PM Jo  wrote:

> I guess the rationale was making it easier on the tendons in the carpal
> tunnel. Click, hold/move, click became click, move, click.
>
> I would like to see a mode where the node that will be moved is
> autoselected based on proximity to the mouse pointer. Then it would become
> move, click, move, click. Obviously this needs to be guided by a
> rubberband, whowing which node will be moved.
>
> In JOSM this "improve way accuracy" also allows Ctrl-Click for adding
> nodes, I mean vertices.
>
> Polyglot
>
> On Tue, Apr 9, 2019 at 2:54 AM Cory Albrecht  wrote:
>
>>
>> Cory Albrecht 
>> 8:14 PM (37 minutes ago)
>> to Régis
>> Hello Régis,
>>
>> Sorry for not being clear - I mean when using the selection tool in
>> freehand mode. I am definitely not talking about the identification tool,
>> assuming you're referring to the same thing that I am thinking of?
>> Ctrl+Shift+I, or the icon that is the cursor with a the letter "i" in a
>> sold blue circle. I'm not sure I would call that new as it's been part of
>> QGIS since I started using it in about 2015. Perhaps you're an old salt
>> from the 1.x days? ;-)
>>
>> As a principle of UX design, ideally, the user should do the same action
>> - click and drag - for any type of selection, both to maintain internal
>> consistency in the application and with common ways of doing things in the
>> broader computer universe. This lets people learn new software quickly by
>> having a set of transferable actions that can get them up and running and
>> doing rudimentary things quickly. It also helps reduce unintended errors
>> caused by using common actions that get unexpectedly interpreted different
>> than the user is used to. Things like this contribute to how easy or
>> frustrating an application is to use, both for new and long time users.
>>
>> 1. For the "Select Feature(s)", click and drag to indicate the diagonally
>> opposite corners of a selection rectangle.
>> 2. For the "Select Features by Freehand", click and drag to create an
>> irregular blob of selection area.
>> 3. For the "Select Features by Radius", click and drag to indicate the
>> centre of a selection circle and it's radius.
>>
>> In 2.x the answer to all of those was yes, but in 3.x it's yes, no, no.
>>
>> In vector and raster drawing applications, drawing rectangles, circles
>> and blobs is done by click and drag, as is selecting rectangular, circular
>> or irregular blobby areas. If you release and click elsewhere then drag,
>> you start drawing a new object, or you discard the first selection and
>> start outlining a new one. Word processing and text section, video editors
>> and frame selection, sound editors and lengths of time in a track, they all
>> have the user do these conceptually similar tasks in the same way - click
>> and drag to create a selection , new click discards old selection.
>>
>> Another principle of UX design is that you don't change how a user does
>> something unless there is clear benefit that outweighs the trouble of
>> relearning, especially for action concepts that are common in the broader
>> sphere. When you make changes without benefits you cause friction in your
>> user flows (some call those "point points"), and that means people find
>> that task (and potentially the application as a whole) difficult and
>> frustrating to use.
>>
>> For those three methods of selection there's nothing to be gained by
>> making QGIS 3.x the odd one out in how this is done. There's no benefit
>> added by extra functionality in these selection methods. All it does is
>> create pain points, both by being different from everybody else and by
>> being inconsistent internally.
>>
>> The exception to this is the poly gone selection tool. I've never
>> encountered it outside of QGIS and ArcGIS. Drawing applications have
>> polygon drawing tools in which you sequentially click the polygon's points,
>> just like how you create features on polygon or line layers in QGIS, but
>> there's no polygon selection analogue. As such it makes sense to take the
>> feature creation method of sequential clicks over for use in a polygon
>> selection tool rather than coming up with a whole new user flow like click
>> and drag and tapping the space bar for t

Re: [QGIS-Developer] Bug #21460?

[Cory Albrecht]

>  The best option is always come and collaborate with core team, in the
way that is most practical to you.

Well, that's why I came here because there's been no activity on that bug
for a month except my own comments. No requests for more information like
"please do X and tell me the output". I get that developer time to fix
things is not infinite (I am one myself), but good triage includes an
attempt to narrow down where in the code where the problem occurs to judge
the scope of the problem and comment to that effect so other developers
don't waste time duplicating the effort. But without any comments I don't
even seen an attempt to triage the issue.

On Tue, Apr 9, 2019 at 1:42 AM Paolo Cavallini 
wrote:

> Hi all,
>
> On 09/04/19 01:19, Nyall Dawson wrote:
> > On Tue, 9 Apr 2019 at 09:03, Cory Albrecht  wrote:
> >>
> >> Hi Paolo,
> >>
> >> Might I suggest that you consider that not everybody has time to go an
> learn the codebase of QGIS to be able to know where to start for making
> changes themselves, even if they happen to know C++? Especially if they
> have to learn the Qt framework at the same time.
> >>
> >> That consideration might be better than a snarky reply to a polite
> inquiry. Just saying.
> >
> > I don't believe Paolo's reply was ever intended to be snarky. Instead,
> > he's just trying to inform you of how development occurs in
> > open-source projects like QGIS in order to empower you to be able to
> > get this bug fixed.
> sorry Cory, I did not mean to be impolite. I think the page cited
> depicts accurately the sheer reality behind bug fixing, and effectively
> answers your question.
> A Peter pointed out, thanks to our sponsors and donors we are able to
> fix many bugs before each release, but there cannot be a guarantee. The
> best option is always come and collaborate with core team, in the way
> that is most practical to you.
> 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] Why was selection tool behaviour changed in 3.x?

[Cory Albrecht]

Cory Albrecht 
8:14 PM (37 minutes ago)
to Régis
Hello Régis,

Sorry for not being clear - I mean when using the selection tool in
freehand mode. I am definitely not talking about the identification tool,
assuming you're referring to the same thing that I am thinking of?
Ctrl+Shift+I, or the icon that is the cursor with a the letter "i" in a
sold blue circle. I'm not sure I would call that new as it's been part of
QGIS since I started using it in about 2015. Perhaps you're an old salt
from the 1.x days? ;-)

As a principle of UX design, ideally, the user should do the same action -
click and drag - for any type of selection, both to maintain internal
consistency in the application and with common ways of doing things in the
broader computer universe. This lets people learn new software quickly by
having a set of transferable actions that can get them up and running and
doing rudimentary things quickly. It also helps reduce unintended errors
caused by using common actions that get unexpectedly interpreted different
than the user is used to. Things like this contribute to how easy or
frustrating an application is to use, both for new and long time users.

1. For the "Select Feature(s)", click and drag to indicate the diagonally
opposite corners of a selection rectangle.
2. For the "Select Features by Freehand", click and drag to create an
irregular blob of selection area.
3. For the "Select Features by Radius", click and drag to indicate the
centre of a selection circle and it's radius.

In 2.x the answer to all of those was yes, but in 3.x it's yes, no, no.

In vector and raster drawing applications, drawing rectangles, circles and
blobs is done by click and drag, as is selecting rectangular, circular or
irregular blobby areas. If you release and click elsewhere then drag, you
start drawing a new object, or you discard the first selection and start
outlining a new one. Word processing and text section, video editors and
frame selection, sound editors and lengths of time in a track, they all
have the user do these conceptually similar tasks in the same way - click
and drag to create a selection , new click discards old selection.

Another principle of UX design is that you don't change how a user does
something unless there is clear benefit that outweighs the trouble of
relearning, especially for action concepts that are common in the broader
sphere. When you make changes without benefits you cause friction in your
user flows (some call those "point points"), and that means people find
that task (and potentially the application as a whole) difficult and
frustrating to use.

For those three methods of selection there's nothing to be gained by making
QGIS 3.x the odd one out in how this is done. There's no benefit added by
extra functionality in these selection methods. All it does is create pain
points, both by being different from everybody else and by being
inconsistent internally.

The exception to this is the poly gone selection tool. I've never
encountered it outside of QGIS and ArcGIS. Drawing applications have
polygon drawing tools in which you sequentially click the polygon's points,
just like how you create features on polygon or line layers in QGIS, but
there's no polygon selection analogue. As such it makes sense to take the
feature creation method of sequential clicks over for use in a polygon
selection tool rather than coming up with a whole new user flow like click
and drag and tapping the space bar for the points.

And so I wonder - what was the rationale behind making this change?

On Mon, Apr 8, 2019 at 6:00 AM Régis Haubourg 
wrote:

> Hi Cory,
> I must say I didn't notice any difference on the selection tool behavior
> on my side.
> I don't think there was any explicit attempt to homogenize the selection
> behavior with the node tool new ergonomy.
>
> Just a check, in the maptool dropdown list for selection tool, are your
> using the freehand selection tool or the classical clic and drag selection
> tool?
>
> I've seen similar surprising issues with the new "identify" tool that now
> can interrogate features in a polygon. Users got confused when they changed
> this behavior by mistake. Could that be your case?
> Cheers
> Régis
>
> Le lun. 8 avr. 2019 à 01:09, Cory Albrecht  a
> écrit :
>
>> I was wondering why the selection tool behaviour in 3.x was changed from
>> the implementation in 2.18?
>>
>> In 2.18.x when you wanted to select features in a layer, you clicked the
>> primary mouse button, held it, and moves the mouse cursor over the items
>> you wanted to select - known as "click and drag". To help, a shape was
>> drawn on screen for the user to know what they had already dragged the
>> mouse over top of. To add to the selection you used shift plus click and
>> drag, to remove, Ctrl plus click and drag. I

Re: [QGIS-Developer] Bug #21460?

[Cory Albrecht]

Hello Nyall,

Oh, I am well familiar with the vicissitudes of getting work done in open
source projects - It's why I have donated to many opensource projects over
the decades that I have been using them, including QGIS. But just telling
people "go fix it yourself" is not helpful. To be frank, it makes me wonder
if I should have made that donation elsewhere rather than making me willing
to contribute to the project by trying to fix a bug or two instead. How do
I know that I wouldn't just get another snarky brush off were I to ask for
help because my lack of familiarity with the QGIS codebase and the Qt
framework?


On Mon, Apr 8, 2019 at 7:19 PM Nyall Dawson  wrote:

> On Tue, 9 Apr 2019 at 09:03, Cory Albrecht  wrote:
> >
> > Hi Paolo,
> >
> > Might I suggest that you consider that not everybody has time to go an
> learn the codebase of QGIS to be able to know where to start for making
> changes themselves, even if they happen to know C++? Especially if they
> have to learn the Qt framework at the same time.
> >
> > That consideration might be better than a snarky reply to a polite
> inquiry. Just saying.
>
> I don't believe Paolo's reply was ever intended to be snarky. Instead,
> he's just trying to inform you of how development occurs in
> open-source projects like QGIS in order to empower you to be able to
> get this bug fixed.
>
> Nyall
>
>
>
> >
> > On Mon, Apr 8, 2019 at 4:30 AM Paolo Cavallini 
> wrote:
> >>
> >> Hi Cory,
> >>
> >> On 08/04/19 00:57, Cory Albrecht wrote:
> >> > I was wondering when Bug #21460
> >> > <https://issues.qgis.org/issues/21460> was going to get some
> attention?
> >> > It's about  QGIS not forming proper PostGIS SQL updates correctly,
> >> > specifically for null values.
> >>
> >> may I suggest you an interesting read?
> >>
> https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/
> >> 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
>
___
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 #21460?

[Cory Albrecht]

Hi Paolo,

Might I suggest that you consider that not everybody has time to go an
learn the codebase of QGIS to be able to know where to start for making
changes themselves, even if they happen to know C++? Especially if they
have to learn the Qt framework at the same time.

That consideration might be better than a snarky reply to a polite inquiry.
Just saying.

On Mon, Apr 8, 2019 at 4:30 AM Paolo Cavallini 
wrote:

> Hi Cory,
>
> On 08/04/19 00:57, Cory Albrecht wrote:
> > I was wondering when Bug #21460
> > <https://issues.qgis.org/issues/21460> was going to get some attention?
> > It's about  QGIS not forming proper PostGIS SQL updates correctly,
> > specifically for null values.
>
> may I suggest you an interesting read?
>
> https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/
> 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

[QGIS-Developer] Why was selection tool behaviour changed in 3.x?

[Cory Albrecht]

I was wondering why the selection tool behaviour in 3.x was changed from
the implementation in 2.18?

In 2.18.x when you wanted to select features in a layer, you clicked the
primary mouse button, held it, and moves the mouse cursor over the items
you wanted to select - known as "click and drag". To help, a shape was
drawn on screen for the user to know what they had already dragged the
mouse over top of. To add to the selection you used shift plus click and
drag, to remove, Ctrl plus click and drag. It the way select tools work
broadly across computer world and is intuitive because of it's ubiquity -
learn it once, use it everywhere.

In 3.x, however, instead of using that common method, it has changed to
click and release and move the mouse around. This is a common UI method to
set focus to an item for subsequent actions but still be able to move the
mouse around without selecting or affecting any other items. I know things
would work slightly different in QGIS because of having a distinct
selection tool that one must activate, but this removes intuitiveness from
the application and makes it more difficult to use without any
corresponding gain in functionality.

A similar change has also happened in the vertex editor where in 2.18.x
single clicking on a vertex used to mean select, and you had to drag (click
and hold) to move it. Now, if you click and release, it unexpectedly drags
the vertex around as you move the mouse.

QGIS having it's own, non-standard mouse actions for tasks that are common
(select, copy, delete, etc…) across all types of data (text in a
wordprocessor, frames in a movie editor, features in a map editor, etc…) is
counter-intuitive and confusing, especially if those non-standard actions
are already commonly used for other common user interface actions.

It's almost like the QGIS development team has decided that Ctrl+V will now
mean "Cut", Ctrl+X will mean "Copy", and to copy have to use Alt+F1 for
"Paste". Extending common user interface actions for something in QGIS that
has no exact parallel but is still conceptually similar to that common
action, like how Ctrl+Alt+V means paste what was copied into the buffer
into a brand new layer, that makes sense. But ignoring decades of common UI
actions that are in the muscle memory of probably all users makes the
programme frustrating and tedious to use as one has to constantly remind
themselves that QGIS is different.
___
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] Bug #21460?

[Cory Albrecht]

I was wondering when Bug #21460  was
going to get some attention? It's about  QGIS not forming proper PostGIS
SQL updates correctly, specifically for null values.

Thanks in advance.
___
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