Union Operations returns collections containing empty elements

[nbvfgh]

Relates to: https://trac.osgeo.org/postgis/ticket/5835

Reproduce in GEOS:

geosop -a 'GEOMETRYCOLLECTION(POLYGON EMPTY, POINT EMPTY, LINESTRING(10 10, 10 10))' -b 'POINT(1 1)' union
-- reuslt:{GEOMETRYCOLLECTION (POLYGON EMPTY, POINT EMPTY, LINESTRING (10 10, 10 10), POINT (1 1))}

geosop -a 'GEOMETRYCOLLECTION(POLYGON EMPTY, POINT EMPTY, LINESTRING(10 10, 10 10), POINT(1 1))' unaryUnion
-- result:{GEOMETRYCOLLECTION (POINT (1 1), LINESTRING EMPTY)}

[dr-jts]

Interesting - in JTS the unary union gives the expected result:

POINT (1 1)

[dr-jts]

A simpler case for unary union:

bin/geosop -a 'GEOMETRYCOLLECTION(LINESTRING(10 10, 10 10), POINT(1 1))' unaryUnion 
--> GEOMETRYCOLLECTION (POINT (1 1), LINESTRING EMPTY)

The ideal result is probably

 GEOMETRYCOLLECTION (LINESTRING(10 10, 10 10), POINT (1 1))

[nbvfgh]

A simpler case for unary union:

bin/geosop -a 'GEOMETRYCOLLECTION(LINESTRING(10 10, 10 10), POINT(1 1))' unaryUnion 
--> GEOMETRYCOLLECTION (POINT (1 1), LINESTRING EMPTY)

The ideal result is probably

 GEOMETRYCOLLECTION (LINESTRING(10 10, 10 10), POINT (1 1))

Yes, dicussion in #1136 indicate that a Linestring of 0 length or a Area of 0 size should return a point or at least be retained.

[dr-jts]

The cause of the union anomaly is the heuristic code in Geometry::Union, which combines the two inputs if their envelopes are disjoint. It does not check for empty geometries (and in general does not reduce geometries to a more canonical form, which performing an explicit union would do).

This code should be enhanced to remove empty elements.

Actually I'm in favour of removing it altogether, since it creates other behaviour differences with OverlayNG (for example, it does not node disjoint sets of LineStrings). Or at least refining it significantly, and perhaps moving it into OverlayNG, since it is then available everywhere. At very least it can be moved into HeuristicOverlay.

In general I think it's better to avoid putting heuristic logic into Geometry methods, because:

• complex heuristic logic complicates the Geometry class
• it splits up the logic for operations and makes it less widely available

[pramsey]

I guess it depends on just how fast the fast path through OverlayNG is, for the "union of disjoint things"?

[dr-jts]

I guess it depends on just how fast the fast path through OverlayNG is, for the "union of disjoint things"?

It should provide similar performance, apart from a bit of overhead from a few more calls.