Re: [QGIS-it-user] Distanza punto-punti

[Gabriela Osaci-Costache]

Ne sono contenta! Buon lavoro!

Gabriela



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
___
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user

Re: [QGIS-it-user] Distanza punto-punti

[Arrotino]

Grazie, era quello che cercavo.



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
___
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user

[Qgis-user] Data fom table and 1-n relations

[L.W.]

Hello,

it's me again with questions primarly for data-tables.

1st.

I used it in the past but I can not found it anymore, how to use data
from another table / layer in geometry-editor?

example: if (data.fromothertable = 1, 'A', 'B')

2nd.

I have a table / layer with features and attributes (and fid), and I
have a pure data-table with additional data in 1-n relation to the other
table/layer, how can I display all the data with 2ndtable.foreign_key =
1sttable.fid in the attribute-editor-gui?

Regards

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] saving all temporary layers?

[David Strip]

  
  
On 1/21/2021 10:13 PM, Michael Dufty
  wrote:


  Not
  exactly what you are asking for, so it may not suit, but I
  find the “memory layer saver” plugin invaluable.
  When
  using this memory layers are not lost when you close QGIS

Thanks for the pointer. I'll check whether this serves my needs.
  

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Richard Duivenvoorde]

On 1/22/21 3:54 PM, C Hamilton wrote:

> And upon restart I do not get the message anymore... So apparently 
> 'Plugin Dependencies Manager' is not working ok the first time (I started a 
> fresh profiles-path AND thus profile)
> 
> 
> I am not sure I correctly set up the plugin_dependencies tag in metadata.txt. 
> I couldn't find any examples. Here is what I have in metadata.txt. 

I had a look into the code, and concluded that is meant to be used for 
inter-plugin dependencies.
Then I googled:
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/132
so I think you can remove it from your metadata.txt (unless Alessandro maybe 
can reveal a new trick from his sleeve about Python module dependencies :-) )

> One remark: we (as The Netherlands, are currently UTC+1 (CET), but If I 
> click just outside the north of NL (Waddenzee) outside of the xx-miles zone, 
> I get +0
> As if the timeline is very east of NL there? Scandinavia is also +1 and 
> is on the same degree.. more or less
> 
> Time zone boundaries are not in bands except in the ocean and even there they 
> may shift one way or the other around Islands. They are based on political 
> and geographical boundaries. Take a look at: 
> https://github.com/evansiroky/timezone-boundary-builder 
>   

Ah, clear (I think). I loaded that shapefile and see that the data is more or 
less a buffer around the countries/islands.
I thought more that is was a combinaties of areas shaped as long lines, like 
the colored image attached.

When you click in the North sea just above The Netherlands, you end up with 
UTC. but that is probably ok as maybe a timezone is/should be undefined if you 
do not click on land?
 
> Is it possible to visualize the time-lines?
> 
> 
> What do you mean by visualize the time-lines? I am planning on showing the 
> timezone bounding box when you click on the map.

As said: I thought there were lines crossing the oceans... but live is never 
that easy :-)

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Snapping tools really slow

[Paul Wittle]

Hi,

I looks like it was something to do with the hybrid indexing method. I used the 
python code in the previous reply and presto...it works.

We had already checked and there was nothing wrong with the speed of the data 
load. You turn the layer on and it is pretty much instantly displayed so I'm 
guessing something with the way it calculates the index was the issue.

I'm told it was voted that the option should not be added to the settings 
because it would confuse people. Personally I think you should be more 
concerned about users out there who might experience similar performance and 
never mention it; potentially deciding to use other software as well.

We had been putting up with the slow performance till now but that single 
setting makes QGIS runs super-fast and smooth.

My opinion is just that, my opinion, but I hope that those discussing it will 
consider making the default something that can be configured in the global 
settings ui file. Alternatively it might be worth investigating why the hybrid 
method is so slow and just fixing that. They really are not comparable in our 
install, one is instantly available and the other takes literally 5 minutes!

Many thanks for the help everyone; I'm really really pleased with the 
performance now! 

Paul

-Original Message-
From: Philip Barlow 
Sent: 22 January 2021 13:39
To: Paul Wittle ; Julien Cabieces 

Cc: qgis-user@lists.osgeo.org
Subject: RE: [Qgis-user] Snapping tools really slow

Hi Paul,

What sort of database are you using?  MSSQL or Postgres?

We're on Postgres13 and PostGIS 3.0. A quick test with QGIS 3.10.14 digitising 
to OSMM... there is a small delay but its only around a second or two. You may 
have a larger extent than me in your database though? Mine is just the whole of 
the County of Pembrokeshire.  I haven't tried 3.16 to see if there is any 
noticeable difference.

Regards

Phil



-Original Message-
From: Qgis-user  On Behalf Of Paul Wittle
Sent: 22 January 2021 08:10
To: Julien Cabieces 
Cc: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Snapping tools really slow

Hi,

It might be best if I screen record you a video of it loading so you can see 
the performance issue as it is always difficult to discuss in text. I'll have 
to send that to you offline from this thread as I believe videos aren't 
supported by this group.

We are snapping to Ordnance Survey MasterMap because we work in the public 
sector and are permitted to do so for council business. Depending on licencing 
you may not be able to access the same level of OS data as you would probably 
have to pay for it (assuming your company is private) so I guess that would not 
be helpful in terms of replicating the issue. That said; I also tried it using 
the OS Maps API (WFS) and it was also slow so OS may be able to share that with 
you for test purposes.

In the older version 3.10 the progress bar always disappeared for some reason 
so it appeared to just hand whilst the index builds. In the new version a blue 
bar appears at the bottom but it is not a loading bar it is the one you get 
when the application doesn't know how long is left. I tried to stop the process 
because it was long running and it said 'Indexing' was running did I want to 
try and stop the process so I'm pretty sure it is the indexing that is not 
working for some reason.

Is there a way to pre-build the snapping index?

It works fine for smaller layers, things we create etc. If I can resolve this 
one layer then all my problems go away so we would be really happy to pre-cache 
the snapping index if that is possible.

Thanks,
Paul

-Original Message-
From: Julien Cabieces 
Sent: 22 January 2021 05:32
To: Paul Wittle 
Cc: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Snapping tools really slow


Hi,

I made quick tests with some dataset and I failed to see any performance issues.

Could you create an issue with some data sample and project?

Is it the index building that take a long time (there is a progress bar 
displayed at the bottom of the map close to the mouse coordinate information 
while index is currently building) or is it when you move your cursor on the 
map that the snaping information takes time to appear. Or is it when you pan 
the map?

You can enable snapping for specific range of scale, avoiding building index at 
very large scale where snapping is useless.

Regards,
Julien



> Hi,
>
> I've been using version 3.10 and 3.16 and I notice that enabling snapping is 
> extremely slow and oddly significantly slower on 3.16 than 3.10. We thought 
> it might be downloading the dataset on screen but discovered the data is back 
> from the database within seconds and the delay is because QGIS is building an 
> index.
>
> Why is it so inefficient and is there anything that can be done to get better 
> performance?
>
> It is really slow and we are trying to transfer users from MapInfo / ESRI so 
> they will not like the performance at the moment.
>
> To be 

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[C Hamilton]

>
>
> > For those who use the OSGeo4W installer you may need to include the
> scipy library. The standalone installers already have it by default.
>
> I'm on Debian, and installed the plugin.
>
> I'm shown the 'Plugin Dependencies Manager' dialog (which I've never seen
> before, is it in master or in the plugin?) See screenshot. But I cannot
> click 'Fix manually' or so...
>
> But I have scipy  installed:
>
> python3-scipy/testing,testing,now 1.5.4-1+b1 amd64 [installed,automatic]
>   scientific tools for Python 3
>
> and in QGIS I can even run the scipy-get started:
>
> import numpy as np
> print("I like ", np.pi)
>
> Ah, and after the installation, the plugin is working fine (I think)
>
> And upon restart I do not get the message anymore... So apparently 'Plugin
> Dependencies Manager' is not working ok the first time (I started a fresh
> profiles-path AND thus profile)
>

I am not sure I correctly set up the plugin_dependencies tag in
metadata.txt. I couldn't find any examples. Here is what I have in
metadata.txt.

plugin_dependencies=scipy

The Windows standalone versions have numpy and scipy already installed and
my OSGeo4W has numpy installed by default but not scipy.


>
> One remark: we (as The Netherlands, are currently UTC+1 (CET), but If I
> click just outside the north of NL (Waddenzee) outside of the xx-miles
> zone, I get +0
> As if the timeline is very east of NL there? Scandinavia is also +1 and is
> on the same degree.. more or less


Time zone boundaries are not in bands except in the ocean and even there
they may shift one way or the other around Islands. They are based on
political and geographical boundaries. Take a look at:
https://github.com/evansiroky/timezone-boundary-builder


>

Is it possible to visualize the time-lines?
>

What do you mean by visualize the time-lines? I am planning on showing the
timezone bounding box when you click on the map.


> > I would enjoy any suggestions or feedback. Also for the QGIS team, can a
> plugin this large be included into the plugin repo?
>
> If you promise not to release once a week, personally I would be ok with
> it :-)
>

Noted. Once I get more feedback back then I will create a new release and
make it available and not update it every week.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Qgis install with osgeo4w-setup-x86

[Thomas Struller]

Hallo,

tried to install qgis 3.16 with osgeo4w-setup-x86 and got the following message 
on startup of qgis:

Oops, looks like an error loading QGIS
Details:
Could not load qgis_app.dll
Windows Error: Das angegebene Modul wurde nicht gefunden (the modul could not 
be found)

Help:
Check C:\OSGeo4W64\bin\qgis-bin.env for correct enviroment paths.

Checked the enviroment paths in qgis-bin.env but they seem to be correct.

What can I do? What can be the solution?

Im on win10 pro 20H2 installed 08.01.2021; build 19042.746
AMD Ryzen 7Pro 4750U 32 GB RAM

Thanks a lot in advance for help.

Thomas


Mit freundlichen Grüßen


Thomas Struller
Diplom Geologe (Univ.), BDG, V18

Sachverständiger nach BBodSchG §18,
SG1 Historische Recherche
SG2 Pfad Boden – Gewässer
Akademischer Geoinformatiker




Tel:0049 911 12076 111
Mobil:  0049 170 33 20 494
Mail:   thomas.strul...@lga-geo.de


 LGA Institut für Umweltgeologie und Altlasten GmbH
 Christian-Hessel-Straße 1
 90427 Nürnberg
 i...@lga-geo.de
 www.LGA-geo.de








Handelsregister: AmtsG Nürnberg HRB 18895
Umsatzst.-IdNr.:DE219281492
StNr.:  241/131/30489

Geschäftsführer: Carlo Schillinger, Dr. Jürgen Kisskalt
<>___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Snapping tools really slow

[Philip Barlow]

Hi Paul,

What sort of database are you using?  MSSQL or Postgres? 

We're on Postgres13 and PostGIS 3.0. A quick test with QGIS 3.10.14 digitising 
to OSMM... there is a small delay but its only around a second or two. You may 
have a larger extent than me in your database though? Mine is just the whole of 
the County of Pembrokeshire.  I haven't tried 3.16 to see if there is any 
noticeable difference.

Regards

Phil



-Original Message-
From: Qgis-user  On Behalf Of Paul Wittle
Sent: 22 January 2021 08:10
To: Julien Cabieces 
Cc: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Snapping tools really slow

Hi,

It might be best if I screen record you a video of it loading so you can see 
the performance issue as it is always difficult to discuss in text. I'll have 
to send that to you offline from this thread as I believe videos aren't 
supported by this group.

We are snapping to Ordnance Survey MasterMap because we work in the public 
sector and are permitted to do so for council business. Depending on licencing 
you may not be able to access the same level of OS data as you would probably 
have to pay for it (assuming your company is private) so I guess that would not 
be helpful in terms of replicating the issue. That said; I also tried it using 
the OS Maps API (WFS) and it was also slow so OS may be able to share that with 
you for test purposes.

In the older version 3.10 the progress bar always disappeared for some reason 
so it appeared to just hand whilst the index builds. In the new version a blue 
bar appears at the bottom but it is not a loading bar it is the one you get 
when the application doesn't know how long is left. I tried to stop the process 
because it was long running and it said 'Indexing' was running did I want to 
try and stop the process so I'm pretty sure it is the indexing that is not 
working for some reason.

Is there a way to pre-build the snapping index?

It works fine for smaller layers, things we create etc. If I can resolve this 
one layer then all my problems go away so we would be really happy to pre-cache 
the snapping index if that is possible.

Thanks,
Paul

-Original Message-
From: Julien Cabieces 
Sent: 22 January 2021 05:32
To: Paul Wittle 
Cc: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Snapping tools really slow


Hi,

I made quick tests with some dataset and I failed to see any performance issues.

Could you create an issue with some data sample and project?

Is it the index building that take a long time (there is a progress bar 
displayed at the bottom of the map close to the mouse coordinate information 
while index is currently building) or is it when you move your cursor on the 
map that the snaping information takes time to appear. Or is it when you pan 
the map?

You can enable snapping for specific range of scale, avoiding building index at 
very large scale where snapping is useless.

Regards,
Julien



> Hi,
>
> I've been using version 3.10 and 3.16 and I notice that enabling snapping is 
> extremely slow and oddly significantly slower on 3.16 than 3.10. We thought 
> it might be downloading the dataset on screen but discovered the data is back 
> from the database within seconds and the delay is because QGIS is building an 
> index.
>
> Why is it so inefficient and is there anything that can be done to get better 
> performance?
>
> It is really slow and we are trying to transfer users from MapInfo / ESRI so 
> they will not like the performance at the moment.
>
> To be clear the data has a primary key, spatial indices and all is of good 
> quality. As I say the data downloads and displays within seconds on the map; 
> is it because I've selected snapping to segment as well as vertex?
>
> Thanks,
>
> Paul Wittle
> [cid:image001.jpg@01D6F016.C23D1CA0] >
> Business Solutions Analyst (GIS)
> ICT Operations
> Dorset Council
> 01305 228473
>  %20%20%20> dorsetcouncil.gov.uk
>
> [cid:image002.png@01D6F016.C23D1CA0] uncilUK>
> [cid:image003.png@01D6F016.C23D1CA0] ilUK>
> [cid:image004.png@01D6F016.C23D1CA0] UK>
>
> 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 

[Qgis-user] Data fom table and 1-n relations

[L.W.]

Hello,

it's me again with questions primarly for data-tables.

1st.

I used it in the past but I can not found it anymore, how to use data
from another table / layer in geometry-editor?

example: if (data.fromothertable = 1, 'A', 'B')

2nd.

I have a table / layer with features and attributes (and fid), and I
have a pure data-table with additional data in 1-n relation to the other
table/layer, how can I display all the data with 2ndtable.foreign_key =
1sttable.fid in the attribute-editor-gui?

Regards
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Richard Duivenvoorde]

On 1/21/21 4:22 PM, C Hamilton wrote:
> For those who use the OSGeo4W installer you may need to include the scipy 
> library. The standalone installers already have it by default.

I'm on Debian, and installed the plugin.

I'm shown the 'Plugin Dependencies Manager' dialog (which I've never seen 
before, is it in master or in the plugin?) See screenshot. But I cannot click 
'Fix manually' or so...

But I have scipy  installed:

python3-scipy/testing,testing,now 1.5.4-1+b1 amd64 [installed,automatic]
  scientific tools for Python 3

and in QGIS I can even run the scipy-get started:

import numpy as np
print("I like ", np.pi)

Ah, and after the installation, the plugin is working fine (I think)

And upon restart I do not get the message anymore... So apparently 'Plugin 
Dependencies Manager' is not working ok the first time (I started a fresh 
profiles-path AND thus profile)

One remark: we (as The Netherlands, are currently UTC+1 (CET), but If I click 
just outside the north of NL (Waddenzee) outside of the xx-miles zone, I get +0 
As if the timeline is very east of NL there? Scandinavia is also +1 and is on 
the same degree.. more or less
Is it possible to visualize the time-lines?

> I would enjoy any suggestions or feedback. Also for the QGIS team, can a 
> plugin this large be included into the plugin repo?

If you promise not to release once a week, personally I would be ok with it :-)

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Snapping tools really slow

[Julien Cabieces]

Hi

> Hi,
>
> It might be best if I screen record you a video of it loading so you can see 
> the performance issue as it is always difficult to discuss in text. I'll have 
> to send that to you offline from this thread as I believe videos aren't 
> supported by this group.
>

I agree, I'll wait for a video.

> We are snapping to Ordnance Survey MasterMap because we work in the
> public sector and are permitted to do so for council
> business. Depending on licencing you may not be able to access the
> same level of OS data as you would probably have to pay for it
> (assuming your company is private) so I guess that would not be
> helpful in terms of replicating the issue. That said; I also tried it
> using the OS Maps API (WFS) and it was also slow so OS may be able to
> share that with you for test purposes.

I try with some WFS, and indexing is as slow as rendering, meaning that
this probably data retrieval which slow down things under the hood.

>
> In the older version 3.10 the progress bar always disappeared for some
> reason so it appeared to just hand whilst the index builds. In the new
> version a blue bar appears at the bottom but it is not a loading bar
> it is the one you get when the application doesn't know how long is
> left. I tried to stop the process because it was long running and it
> said 'Indexing' was running did I want to try and stop the process so
> I'm pretty sure it is the indexing that is not working for some
> reason.

The progress bar disappears so the indexing is made in parallel for all
your layers and you can edit even if the index is not ready yet (snapping
would be not available until the index is ready though).

>
> Is there a way to pre-build the snapping index?
>

No. For some huge layers (millions of vertex), it's not possible to
index everything. QGIS try to guess the best reasonnable area to index
and rebuild it everytime you move outside this area.

That's why I told you about snapping range scale. QGIS would trigger
index building only in certain range scale (the relevant one for
edition), which decrease the size of index to build.

For some users who have huge amount of data, I also advice them to
change the indexing strategy using Python macros (Project > Properties >
Macro) with this code.


from qgis.utils import iface
from qgis.core import QgsSnappingUtils

def openProject():

iface.mapCanvas().snappingUtils().setIndexingStrategy(QgsSnappingUtils.IndexExtent)

def saveProject():
pass

def closeProject():

iface.mapCanvas().snappingUtils().setIndexingStrategy(QgsSnappingUtils.IndexHybrid)


It would build index only for the canvas extent. With the appropriate
snapping range scale, you manage to avoid this long time waiting for
indexing (but it built index everytime you move...).

I'm ok it's not ideal, but so far this is the only way I know to manage
spapping on huge amount of data.


> It works fine for smaller layers, things we create etc. If I can resolve this 
> one layer then all my problems go away so we would be really happy to 
> pre-cache the snapping index if that is possible.
>
> Thanks,
> Paul
>
> -Original Message-
> From: Julien Cabieces 
> Sent: 22 January 2021 05:32
> To: Paul Wittle 
> Cc: qgis-user@lists.osgeo.org
> Subject: Re: [Qgis-user] Snapping tools really slow
>
>
> Hi,
>
> I made quick tests with some dataset and I failed to see any performance 
> issues.
>
> Could you create an issue with some data sample and project?
>
> Is it the index building that take a long time (there is a progress bar 
> displayed at the bottom of the map close to the mouse coordinate information 
> while index is currently building) or is it when you move your cursor on the 
> map that the snaping information takes time to appear. Or is it when you pan 
> the map?
>
> You can enable snapping for specific range of scale, avoiding building index 
> at very large scale where snapping is useless.
>
> Regards,
> Julien
>
>
>
>> Hi,
>>
>> I've been using version 3.10 and 3.16 and I notice that enabling snapping is 
>> extremely slow and oddly significantly slower on 3.16 than 3.10. We thought 
>> it might be downloading the dataset on screen but discovered the data is 
>> back from the database within seconds and the delay is because QGIS is 
>> building an index.
>>
>> Why is it so inefficient and is there anything that can be done to get 
>> better performance?
>>
>> It is really slow and we are trying to transfer users from MapInfo / ESRI so 
>> they will not like the performance at the moment.
>>
>> To be clear the data has a primary key, spatial indices and all is of good 
>> quality. As I say the data downloads and displays within seconds on the map; 
>> is it because I've selected snapping to segment as well as vertex?
>>
>> Thanks,
>>
>> Paul Wittle
>> [cid:image001.jpg@01D6F016.C23D1CA0]> >
>> Business Solutions Analyst (GIS)
>> ICT Operations
>> Dorset Council
>> 01305 228473
>> > %20%20%20> 

Re: [Qgis-user] Snapping tools really slow

[Paul Wittle]

Hi,

It might be best if I screen record you a video of it loading so you can see 
the performance issue as it is always difficult to discuss in text. I'll have 
to send that to you offline from this thread as I believe videos aren't 
supported by this group.

We are snapping to Ordnance Survey MasterMap because we work in the public 
sector and are permitted to do so for council business. Depending on licencing 
you may not be able to access the same level of OS data as you would probably 
have to pay for it (assuming your company is private) so I guess that would not 
be helpful in terms of replicating the issue. That said; I also tried it using 
the OS Maps API (WFS) and it was also slow so OS may be able to share that with 
you for test purposes.

In the older version 3.10 the progress bar always disappeared for some reason 
so it appeared to just hand whilst the index builds. In the new version a blue 
bar appears at the bottom but it is not a loading bar it is the one you get 
when the application doesn't know how long is left. I tried to stop the process 
because it was long running and it said 'Indexing' was running did I want to 
try and stop the process so I'm pretty sure it is the indexing that is not 
working for some reason.

Is there a way to pre-build the snapping index?

It works fine for smaller layers, things we create etc. If I can resolve this 
one layer then all my problems go away so we would be really happy to pre-cache 
the snapping index if that is possible.

Thanks,
Paul

-Original Message-
From: Julien Cabieces 
Sent: 22 January 2021 05:32
To: Paul Wittle 
Cc: qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Snapping tools really slow


Hi,

I made quick tests with some dataset and I failed to see any performance issues.

Could you create an issue with some data sample and project?

Is it the index building that take a long time (there is a progress bar 
displayed at the bottom of the map close to the mouse coordinate information 
while index is currently building) or is it when you move your cursor on the 
map that the snaping information takes time to appear. Or is it when you pan 
the map?

You can enable snapping for specific range of scale, avoiding building index at 
very large scale where snapping is useless.

Regards,
Julien



> Hi,
>
> I've been using version 3.10 and 3.16 and I notice that enabling snapping is 
> extremely slow and oddly significantly slower on 3.16 than 3.10. We thought 
> it might be downloading the dataset on screen but discovered the data is back 
> from the database within seconds and the delay is because QGIS is building an 
> index.
>
> Why is it so inefficient and is there anything that can be done to get better 
> performance?
>
> It is really slow and we are trying to transfer users from MapInfo / ESRI so 
> they will not like the performance at the moment.
>
> To be clear the data has a primary key, spatial indices and all is of good 
> quality. As I say the data downloads and displays within seconds on the map; 
> is it because I've selected snapping to segment as well as vertex?
>
> Thanks,
>
> Paul Wittle
> [cid:image001.jpg@01D6F016.C23D1CA0] >
> Business Solutions Analyst (GIS)
> ICT Operations
> Dorset Council
> 01305 228473
>  %20%20%20> dorsetcouncil.gov.uk
>
> [cid:image002.png@01D6F016.C23D1CA0] uncilUK>
> [cid:image003.png@01D6F016.C23D1CA0] ilUK>
> [cid:image004.png@01D6F016.C23D1CA0] UK>
>
> 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
>