New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snapping rounding errors with on-the-fly reprojection #21772
Comments
Author Name: Giovanni Manghi (@gioman) I just followed all the steps and on QGIS master I cannot replicate the issue. Could you please test on master and/or attach a sample project with data?
|
Author Name: Daan Goedkoop (@dgoedkoop) I have just tried it with QGIS Master on Linux, and the behaviour is as I originally described. I have attached a file with a sample project and a sample shape file that shows the problem (the line consisting of the segments 0 and 1 has not been cut exactly at the middle vertex; the line with the id 2 has not been snapped exactly to the right location either). You need to zoom in all the way to about 5000:1 in order to see the inaccuracies.
|
Author Name: Giovanni Manghi (@gioman) Now I see. Thanks.
|
Author Name: Daan Goedkoop (@dgoedkoop) It can be an annoying bug. For example, the 'split feature' tool has the feature that if you start cutting at a snapped vertex, the line is cut immediately, rather than starting to draw a cutting line. However, in case of an inaccuracy such as in this bug, this fails: the line is not cut. Probably because the cutting point ends up slightly besides the vertex. The node editor tool doesn't seem to be affected. I'm new to the Qgis code base, but I've tried to figure this out a bit. This seems to revolve around the function (declaration slightly reformatted to include the class etc.): @ /** Adds a point to the rubber band (in map coordinates) and to the capture list (in layer coordinates) */ It is called, for example, in @QgsMapToolSplitFeatures::cadCanvasReleaseEvent( QgsMapMouseEvent * e )@, as following: @addVertex( e->mapPoint() );@ On its turn, @QgsMapMouseEvent::snapPoint@ has several code paths, all with @QgsSnappingUtils::snapToMap@, to calculate the @mMapPoint@ that is returned in @Mappoint()@. Back to the function @QgsMapToolCapture::addVertex@. To create the capture list in layer coordinates, as promised in the comment, it uses @QgsMapToolCapture::nextPoint@, which contains the following line (including the comment): @Layerpoint = toLayerCoordinates( vlayer, mapPoint ); //transform snapped point back to layer crs@ Thus, if I understand it correctly, the point is snapped (and transformed) to map coordinates and then transformed back to layer coordinates. I think this might be the problem, because floating point arithmetic doesn't guarantee that you end up with exactly the original value if you perform a calculation and then the inverse calculation. |
Author Name: Giovanni Manghi (@gioman) Daan Goedkoop wrote:
would you please raise this issue in the developers mailing list or do apull request in the qgis code repo on github? thanks! |
Author Name: Daan Goedkoop (@dgoedkoop) Updated to reflect progress in pull request
|
Author Name: Bernd Eversmann (@BarneyBev) We have come across this issue as well, and the rounding errors cause other problems. For instance they affect the topology checker (which is a very crucial feature for us). I know this is a separate issue, but the tolerance setting in the topology checker doesn't seem to work, otherwise that could be a workaround. Bernd |
Author Name: Daan Goedkoop (@dgoedkoop) Other examples of affected functions are topological editing and duplicate feature removal. I have made a screencast to demonstrate this (showing the expected behaviour first, and then the current behaviour): https://youtu.be/JB-Y88EwZC4 |
Author Name: Daan Goedkoop (@dgoedkoop)
|
Author Name: Daan Goedkoop (@dgoedkoop)
Original Redmine Issue: 13745
Affected QGIS version: master
Redmine category:digitising
Assignee: Martin Dobias
The snapping function doesn't snap exactly to vertices when on-the-fly reprojection is activated.
In the attachments, images are shown with an example for reproducing this error. (1) Using the OpenLayers-plugin, the project is set to WGS84/Pseudo Mercator with on-the-fly reprojection enabled. (2) Create a new layer with a different CRS. (3) Digitise a line. (4) Enable snapping at vertices only. (5) For example, cut the line with snapping at a vertex. (6) When zooming in very far, it becomes apparent that the line was not actually cut at the vertex.
I've looked into the source code and to me it seems that the problem is the following. When digitising (whether to draw a new line or to draw a cutting path), the path is stored in memory using the coordinates of the project CRS. The snapping function converts the vertices of the target layer to the project CRS, and after finishing editing the digitised path is converted back to the target layer CRS. This back-and-forth-conversion can lead to floating-point math inaccuracies.
The text was updated successfully, but these errors were encountered: