QGIS » QGIS Application

Tried to test on master, and add a crash when changing default projection (was otf 3857 and layer in 2154). So ... I could not test

Tested on 2.8.4, no issue there.

It is same issue I've noticed in earlier versions (look at issue #10957 dig3.png).

More, it happens only if I have more than one legend entry to same dataset.

Recently I have come across something similar. It might be the same bug. While digitising, with snapping but without topological editing, the pink snapping "+" would suddenly appear outside of any feature and not at any existing vertex. When clicking it, the created vertex would (after finishing digitising) end up snapped to some seemingly random vertex way outside view. Interestingly, the node tool did not seem to be affected in this case.

Unfortunately I forgot to save that particular version of the shapefile and now I cannot reproduce the problem anymore.

Just now I noticed this issue again. It is not reproducible for me. For what it is worth: the problem remained after saving any edits to the shapefile. However, when I save the project, close QGis and open the project again, the problem disappeared. Does that mean that this problem is a different one, than the one described in this bug report?

This issue seems serious, but I haven't found a way to replicate. Could the reporter attach a sample project with data? Without it is difficult to at least replicate. Thanks.

Hi. I've got the same issue, and i'm able to reproduce it every time. I will provide a Qgis project with a small postgres DB.

Which snapping settings are you using? Which CRS?

The problem occurs only when "Activate topologic edition" is enable in snapping options. CRS is 2154.

Sylvain Beorchia wrote:

Here is a ZIP containing 2 shapefiles and a Qgis project.
Open the qgis project, and search for the branch id=1212. Edit the layer and try to connect the top vertex of the branch(1212) to the closest arc. You have to enable snapping, and "Enable topological editing".

Good catch Sylvain! I can reproduce it here at first try.
I never managed to reproduced the bug outside of my complex postgis project and share a sample project.
This is pretty serious indeed.

see also https://issues.qgis.org/attachments/9959/Sans_titre.png

Confirmed as of 2.14.3 -- Snap to Segment Only is enough to reproduce (#note-11)

2.8.9 is not affected, 2.12.1 supposedly was (as for original submission)

2.10.1 is NOT affected either, so new range is good:2.10.1 bad:2.12.1

9c2d70186f054b71f1b792d13133f3856c855bf3 is the first bad commit
commit 9c2d70186f054b71f1b792d13133f3856c855bf3
Author: Marco Hugentobler <[email protected]>
Date:   Wed Sep 16 05:19:26 2015 +0200

    Node tool without click-click mode

:040000 040000 eb8ad3fa7fc599731bbcb89067d32a44eef25dbd 1f3b3ce634bb47ed00837ca35a7278de83496099 M      src

Marco, could you take a look at this ? There's been lots of changes but no testcase:

commit 9c2d70186f054b71f1b792d13133f3856c855bf3
Author: Marco Hugentobler <[email protected]>
Date:   Wed Sep 16 05:19:26 2015 +0200

    Node tool without click-click mode

 src/app/nodetool/qgsmaptoolnodetool.cpp | 500 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------
 src/app/nodetool/qgsmaptoolnodetool.h   |  49 ++++++----
 src/app/nodetool/qgsnodeeditor.cpp      |  23 ++---
 src/app/nodetool/qgsnodeeditor.h        |   1 -
 src/app/nodetool/qgsselectedfeature.cpp |  53 ++---------
 src/app/nodetool/qgsselectedfeature.h   |   3 -
 6 files changed, 391 insertions(+), 238 deletions(-)

A focused testcase, pushed with f0e0ba5bb0f844e9ee28eb9572340f31ae13c6ee, does not give the same bogus result. I'm still debugging how could it be possible to obtain the bogus result (some state implied?)

Printing more digits gives a matching result between PostGIS and QGIS:

ST_Distance('POINT'::geometry, 'LINESTRING'::geometry); -- 0.143113367679915

( it's actually 3.378 which squared gives 0.1431 )

But I found that the LINESTRING part is the FID of the geometry being moved, not FID=11, so this makes me think that the distanc used for FID=11 (the one which should not move) is just a leftover value for the variable computed for FID=27) -- or something along those lines.

New finding: the distance to the fid is correct but the layer is different. We have 2 layers, both contain a fid=11.
The one bogusly snapped is from layer "arc", and is too distance. The fid=11 from the layer being moved (branch) is instead close (as we actually move the vertex right on top of it). The code gets confused as for which vector layer to snap geometries from.

Setting snapping options to "currentLayer" rather than "All Visible Layer" fixes the issue.
Adding another layer with the same geometry as fid=11 from "branch" adds another arbitrary FID to the list of those snapped in any visible layer.

Basically, if I'm seeing this right, all geometries with a given FID value are snapped from any visible layer, rather than FIDs being isolated for each layer.