geometry intersects edge on TopoGeo_addLinestring with tolerance 0.001

[strk]

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);

[strk]

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

[strk]

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 !!

[strk]

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.

[strk]

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.

[strk]

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.

[strk]

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

[strk]

I confirm a recursive snap implementation fixes this ticket.

[strk]

This PR shows the fix: ​https://github.com/postgis/postgis/pull/83

[strk]

(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+)

[strk]

(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+)

[strk]

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