Opened 3 years ago

Closed 3 years ago

#3265 closed defect (fixed)

ST_GetFaceEdge: ERROR: No edge (among 3) found to be defining geometry of face 2

Reported by: strk Owned by: strk
Priority: blocker Milestone: PostGIS 2.2.0
Component: topology Version: trunk
Keywords: Cc: esseffe

Description

The pl/pgsql version is fine, while the C version fails with:

ERROR:  No edge (among 3) found to be defining geometry of face 2

Testcase:

SELECT CreateTopology('topo');                                                  
SELECT ST_AddIsoNode('topo', NULL, ST_MakePoint(150, 150));
SELECT ST_AddIsoNode('topo', NULL, ST_MakePoint(180, 180));
SELECT ST_AddIsoEdge('topo', 1, 2, 'LINESTRING(150 150,  180 150, 180 180)');
SELECT ST_AddEdgeNewFaces('topo', 1, 2, 'LINESTRING(150 150, 180 180)');
SELECT ST_AddIsoNode('topo', NULL, ST_MakePoint(178, 170));
SELECT ST_AddEdgeModFace('topo', 3, 3, 'LINESTRING(178 170, 178 161, 170 161, 178 170)');
SELECT ST_GetFaceGeometry('topo', 2); -- ok
SELECT ST_GetFaceEdges('topo', 2); -- fails

Change History (2)

comment:1 Changed 3 years ago by strk

I made the mistake of changing the algorithm while porting to C, guess I'll have to revert to the original plpgsql algorithm for a "quick" fix (won't be so quick either).

comment:2 Changed 3 years ago by strk

Resolution: fixed
Status: newclosed

I found the problem. The code finding the edge covering "next portion" of ring was not early failing on first non-common vertex. I've also spotted another bug which was failing to return a single clockwise edge as the shell of a face (due to the "next edge finder" code not considering the possibility of a closed edge).

No need to revert to original algorithm ! (slower)

Full test for all these cases added in 2.1 branch with r14006 and in 2.0 branch with r14008. Trunk got fix and tests with r14007.

Note: See TracTickets for help on using tickets.