Opened 9 years ago
Last modified 3 years ago
#760 new defect
Snapping leaves segments below tolerance
Reported by: | strk | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 3.11.0 |
Component: | Default | Version: | 3.5.0 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
Snapping a geometry to another should result in an output that does not move again on subsequent snapping to the same geometry. At least, I'd think such behaviour would be to be preferred, for stability.
In the following case it takes two iterations to reach that point:
WITH inp AS ( SELECT 0.001 as tol, 'LINESTRING(599671.37338031 4889182.65265274,599671.369855744 4889982.62878372)' ::geometry as src, 'LINESTRING(599671.37 4889664.32,599665.52 4889680.18,599671.37 4889683.4,599671.37 4889781.87)' ::geometry as tgt ) SELECT ST_AsText(ST_Snap(src , tgt , tol)), ST_AsText(ST_Snap(ST_Snap(src , tgt , tol), tgt, tol)), ST_AsText(ST_Snap(ST_Snap(ST_Snap(src , tgt , tol), tgt, tol), tgt, tol)) FROM inp;
Change History (7)
comment:1 by , 9 years ago
comment:4 by , 6 years ago
Milestone: | 3.5.2 → 3.8.0 |
---|
comment:5 by , 5 years ago
Milestone: | 3.8.0 → 3.9.0 |
---|
comment:6 by , 4 years ago
Milestone: | 3.9.0 → 3.10.0 |
---|
Note:
See TracTickets
for help on using tickets.
I shell note the problem is dependent on order of vertices in the target point set. Here's a simpler input:
Take the target in the given order and snapping is final after first iteration. Reverse the target and it takes 3 iterations to fully snap: