Opened 12 months ago

Closed 3 months ago

#5081 closed defect (fixed)

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

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 3.4.0
Component: topology Version: 3.2.x
Keywords: Cc:

Description

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

Change History (11)

comment:1 by robe, 5 months ago

Milestone: PostGIS 3.3.0PostGIS 3.4.0

comment:2 by strk, 3 months ago

Version: master3.2.x

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

comment:3 by strk, 3 months ago

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)

comment:4 by strk, 3 months ago

Summary: toTopoGeom: ERROR: ptarray_scroll_in_place: input POINTARRAY does not contain the given pointERROR: ptarray_scroll_in_place: input POINTARRAY does not contain the given point

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)

comment:6 by strk, 3 months ago

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.

comment:7 by strk, 3 months ago

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.

comment:8 by strk, 3 months ago

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)

comment:9 by Sandro Santilli <strk@…>, 3 months ago

In ef4e85d4/git:

Fix bogus target of closed linestring scroll in TopoGeo_addLineString

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

comment:10 by Sandro Santilli <strk@…>, 3 months ago

In 1936ac7/git:

Fix error in topology import of self-intersecting rings

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

comment:11 by Sandro Santilli <strk@…>, 3 months ago

Resolution: fixed
Status: newclosed

In c2a5b06/git:

Fix error in topology import of self-intersecting rings

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

Note: See TracTickets for help on using tickets.