[geos-devel] [GEOS] #1051: overlayng::EdgeMerger::merge(): Assertion `baseEdge->size() == edge->size()' failed.

[GEOS]

#1051: overlayng::EdgeMerger::merge(): Assertion `baseEdge->size() ==
edge->size()' failed.
------------------------+---------------------------
 Reporter:  strk        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  closed
 Priority:  blocker     |   Milestone:  3.9.0
Component:  Default     |     Version:  master
 Severity:  Unassigned  |  Resolution:  fixed
 Keywords:              |
------------------------+---------------------------

Comment (by mdavis):

 The problem turns out to be that GEOS is not sorting the `SegmentNode`s in
 a `SegmentNodeList` quite correctly.  This is shown by dumping the segment
 nodes for the B geometry:

 GEOS:
 {{{
 0: Seg 0 - 655103.66284549481 1794805.4566744049 (Segment Start vertex)
 1: Seg 0 - 655016.29615051334 1794939.965427252
 2: Seg 0 - 655016.20226531825 1794940.1099718122
 3: Seg 1 - 655016.20225819293 1794940.1099794197 <-- *** incorrectly
 sorted ***
 4: Seg 1 - 655016.20226000005 1794940.10998 (Segment Start vertex)
 }}}

 JTS:
 {{{
 0: Seg 0 - 655103.66284549481 1794805.4566744049 (Segment Start vertex)
 1: Seg 0 - 655016.29615051334 1794939.965427252
 2: Seg 0 - 655016.20226531825 1794940.1099718122
 3: Seg 1 - 655016.20226 1794940.10998 (Segment Start vertex)
 4: Seg 1 - 655016.20225819293 1794940.1099794197
 }}}

 Note that the order of the last two nodes is different, AND that in GEOS
 in segment 1 the segment start point is incorrectly sorted ''after'' the
 next node in the segment.

 The reason for this is because the `SegmentNodeComparator` algorithm is
 slightly non-commutative as it stands in GEOS. This is due to the
 assumption that the nodes being compared are very close to the segment
 they are assigned to, so that their relative octant is the same as or
 adjacent to the segment octant.  This assumption doesn't hold in some
 situations when using a snapping tolerance. I.e. a node near a segment
 endpoint may actually lie far enough from the segment that it does not lie
 in the same or an adjacent octant).

 JTS fixed this last year in [https://github.com/locationtech/jts/pull/399
 PR 399], with
 [https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/noding/SegmentNode.java#L75-L76
 this code].  I verified that this fix solves this test case.

-- 
Ticket URL: <https://trac.osgeo.org/geos/ticket/1051#comment:26>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).