Hi everybody,
A few months ago I have raised the issue of floating-point inaccuracies with snapped digitising when OTF reprojection is activated (see bug report #13745). This breaks many functionalities, such as cutting features by clicking on a vertex; topological editing; removing duplicate features; topology checking, and so on. I have also proceeded to create a pull request with a proposed fix for the snapping functionality (#2434), still waiting for feedback.
Now I have noticed that Martin Dobias has introduced a new tracing framework, a couple of days ago. While it is surely a great functionality, currently the tracer object is bound to the map canvas and keeps its data in map coordinates. So here too, layer coordinates are transformed to map coordinates, tracing is performed in map coordinates, and the traced points are then converted back to layer coordinates, leading to floating-point inaccuracies. To be precise: if the active layer and the traced layer have the same CRS, but the project has a different CRS, a feature created by tracing does not exactly match the traced feature. This will again cause functions like removing duplicates and topological features not to work.
How to handle this? As I see it, it will be a bit of work to fix this. Firstly, the tracer class should perhaps be bound to layers instead of canvases. Another possibility might be to just invalidate the tracer when the active layer is changed. In any case, the tracer would need to be changed to return layer coordinates instead of / in addition to map coordinates.
But maybe anyone also has a general opinion about this whole issue of OTF reprojection and floating point inaccuracies?
Kind regards,
Daan Goedkoop
A few months ago I have raised the issue of floating-point inaccuracies with snapped digitising when OTF reprojection is activated (see bug report #13745). This breaks many functionalities, such as cutting features by clicking on a vertex; topological editing; removing duplicate features; topology checking, and so on. I have also proceeded to create a pull request with a proposed fix for the snapping functionality (#2434), still waiting for feedback.
Now I have noticed that Martin Dobias has introduced a new tracing framework, a couple of days ago. While it is surely a great functionality, currently the tracer object is bound to the map canvas and keeps its data in map coordinates. So here too, layer coordinates are transformed to map coordinates, tracing is performed in map coordinates, and the traced points are then converted back to layer coordinates, leading to floating-point inaccuracies. To be precise: if the active layer and the traced layer have the same CRS, but the project has a different CRS, a feature created by tracing does not exactly match the traced feature. This will again cause functions like removing duplicates and topological features not to work.
How to handle this? As I see it, it will be a bit of work to fix this. Firstly, the tracer class should perhaps be bound to layers instead of canvases. Another possibility might be to just invalidate the tracer when the active layer is changed. In any case, the tracer would need to be changed to return layer coordinates instead of / in addition to map coordinates.
But maybe anyone also has a general opinion about this whole issue of OTF reprojection and floating point inaccuracies?
Kind regards,
Daan Goedkoop
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
