[geos-devel] [GEOS] #962: GEOSNode is much slower that GEOSUnaryUnion

[GEOS]

#962: GEOSNode is much slower that GEOSUnaryUnion
------------------------+---------------------------
 Reporter:  komzpa      |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------

Comment (by mdavis):

 One further note is that it looks like GEOS is using a original
 [https://github.com/libgeos/geos/blob/master/src/operation/union/CascadedUnion.cpp
 Cascaded Union] approach for UnaryUnion for both polygons and lines.  In
 fact in theory using a Cascaded approach on lines doesn't provide much
 performance benefit, because unlike polygons unioning lines doesn't
 discard many if any vertices.

 JTS doesn't do this in its UnaryUnion- it just does a
 [https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/operation/union/UnaryUnionOp.java#L209
 full union] of the line with an empty geometry, which effectively forces
 the noding of the lines (but may throw a TopologyException if the noding
 can't be computed correctly due to robustness issues - this is
 demonstrated in #392).

 I guess the GEOS approach handles noding issues better, due to the
 snapping heuristic in the mix.  But this is something else that could be
 revisited when the new overlay hits the codebase.

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