Opened 9 years ago

Closed 9 years ago

#3412 closed defect (fixed)

geometry intersects edge on TopoGeo_addLinestring with tolerance 0.001

Reported by: strk Owned by: strk
Priority: blocker Milestone: PostGIS 2.2.1
Component: topology Version: 2.0.x
Keywords: Cc:

Description

Simple self-contained test:

SELECT DropTopology('case3_topo');
SELECT CreateTopology('case3_topo');
SELECT TopoGeo_AddLinestring('case3_topo',
'LINESTRING(
599671.37 4889664.32,
599665.52 4889680.18,
599671.37 4889683.4,
599671.37 4889781.87
)'
::geometry, 0);
SELECT TopoGeo_AddLinestring('case3_topo',
'0102000000020000003AB42BBFEE4C22410010C5A997A6524167BB5DBDEE4C224117FE3DA85FA75241',
0.001);

Attachments (1)

snapfail.png (4.2 KB ) - added by strk 9 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by strk, 9 years ago

Milestone: PostGIS 2.2.1

comment:2 by strk, 9 years ago

Version: 2.2.x2.0.x

2.0.8SVN is also affected, as well as 2.1.9dev, both with GEOS="3.6.0dev-CAPI-1.10.0 r4136"

comment:3 by strk, 9 years ago

I'd need some confirmation on this bug because I'm seeing a really odd behavior in the geos snapper. In particular, the 2-vertices vertical line being added fails to snap on _all_ the vertices on the existing edge that visually appear to be within tolerance distance from the line. Instead, it only snaps to the _one_ endpoint !!

comment:4 by strk, 9 years ago

I was wrong, the snapping is correct. Only the last edge point is below tolerance from input, the other two points are very close but higher than tolerance.

by strk, 9 years ago

Attachment: snapfail.png added

comment:5 by strk, 9 years ago

Alright now I see the snap problem. Initially, only the last (uppermost) target vertex is below tolerance. The snapper snaps the single input segment to this point.

The snapping moves the subject line closer to the other vertex, so it is _now_ below tolerance, but the snapper does not recurse to further snap the now-moved line.

In the picture you see a portion of the target line (existing edge, in green), the line being added before snapping (rightmost, violet) and the line being added after snapping (the red one). The distance between the green vertex and the violet line is above tolerance while the distance between the green vertex and the red line is below tolerance.

comment:6 by strk, 9 years ago

What happens after this step is that the line (now in red) is further snapped to the existing nodes, which moves it further left, to intersects with the green.

I guess a solution here could be to improve snapping so that subsequent snapping operations would not move the line anymore.

This might also be seen as a bug in the GEOS snapping routine.

comment:7 by strk, 9 years ago

I've filed the GEOS part here: https://trac.osgeo.org/geos/ticket/760

comment:8 by strk, 9 years ago

I confirm a recursive snap implementation fixes this ticket.

comment:10 by strk, 9 years ago

Priority: mediumblocker

comment:11 by strk, 9 years ago

(In [14534]) Use recursive snapping to improve predictability

Fixes geometry-intersects-edge exception when snapping twice to the same pointset. See #3412.

Includes automated testcase for both old and new geos snap (3.3.8- and 3.3.9+)

comment:12 by strk, 9 years ago

(In [14535]) Use recursive snapping to improve predictability

Fixes geometry-intersects-edge exception when snapping twice to the same pointset. See #3412.

Includes automated testcase for both old and new geos snap (3.3.8- and 3.3.9+)

comment:13 by strk, 9 years ago

Resolution: fixed
Status: newclosed

r14534 in 2.2 branch (2.2.1), r14535 in trunk (2.3.0). I will not backport to the plpgsql version.

Note: See TracTickets for help on using tickets.