ERROR: ptarray_scroll_in_place: input POINTARRAY does not contain the given point

[strk]

Attempts to load ​https://catalogue.data.gov.bc.ca/dataset/wsa-third-order-and-greater-watersheds-50-000 dataset into a PostGIS Topology, using toTopoGeom, resulted in this error:

        strk=# update wsa_ws_svw_polygon set tg = toTopoGeom(geom, 'wsa_ws_svw_polygon_topology', 1);
        ERROR:  ptarray_scroll_in_place: input POINTARRAY does not contain the given point
        Time: 1079507.342 ms (17:59.507)

Unfortunately I did not enforce an order of conversion so I'm not sure how easy it would be to reproduce the issue.

The scrolling was added to fix #2175

[strk]

I'm still getting these errors, I think a fix should be backported up to 3.2

[strk]

In my new case the problem occurs when the input closed line becomes a multiline. In that case the code that re-computes the start/endpoint after noding/snapping does not try to re-compute them (maybe it should)

[strk]

TopoGeo_addLinestring() is enough to trigger the problem, passing a closed linestring with more than 1 self-intersection should be enough to trigger the problem (only 2 resulting closed lines would contain the original start point)

[strk]

WIP merge request: ​https://git.osgeo.org/gitea/postgis/postgis/pulls/109

[strk]

I was wrong: 2 self-intersections are not enough to trigger the problem. Problem arises when the input line is closed but looses the original starting point during snapping and gets back to closed after all of that, but without the original starting point, so cannot be scrolled there anymore. I've yet to succeed in producing a focused small testcase for this.

[strk]

Figured finally: problem is that we're ONLY scrolling the intersection between the new line and the existing linework, leaving out any NEW portions. Here's the smalles repro:

SELECT NULL FROM CreateTopology('b5081');
SELECT 'b5081.0', 'E' || TopoGeo_addLinestring('b5081', $$
  LINESTRING(0 0, 10 10,10 -10,0 0)
$$);

SELECT 'b5081.1', 'edges', count(*) FROM (
  SELECT TopoGeo_addLinestring('b5081', $$
    LINESTRING(
      -10 0,
      0 0, 10 10,10 -10,0 0,
      -10 0
    )
  $$)
) foo;

I'm surprised this doesn't show up more often.

[strk]

I guess the reason why this doesn't happen often is because it is rare that the intersection between an incoming *closed* line and pre-existing lines is also closed, as that is only possible when the incoming line is non-simple (self-intersecting)

[Sandro Santilli <strk@…>]

In ef4e85d4/git:

Fix bogus target of closed linestring scroll in TopoGeo_addLineString

References #5081 in master branch (3.4.0dev)
Includes regression testcase

[Sandro Santilli <strk@…>]

In 1936ac7/git:

Fix error in topology import of self-intersecting rings

References #5081 in 3.3 branch (3.3.2dev)
Includes regression testcase

[Sandro Santilli <strk@…>]

In c2a5b06/git:

Fix error in topology import of self-intersecting rings

Closes #5081 in 3.2 branch (3.2.4dev)
Includes regression testcase