|
GEOS 3.11.1
|
Unions MultiPolygons efficiently by using full topological union only for polygons which may overlap by virtue of intersecting the common area of the inputs. More...
#include <OverlapUnion.h>
Public Member Functions | |
| OverlapUnion (const geom::Geometry *p_g0, const geom::Geometry *p_g1, geounion::UnionStrategy *unionFun) | |
| OverlapUnion (const geom::Geometry *p_g0, const geom::Geometry *p_g1) | |
| std::unique_ptr< geom::Geometry > | doUnion () |
Unions MultiPolygons efficiently by using full topological union only for polygons which may overlap by virtue of intersecting the common area of the inputs.
Other polygons are simply combined with the union result, which is much more performant.
This situation is likely to occur during cascaded polygon union, since the partitioning of polygons is done heuristically and thus may group disjoint polygons which can lie far apart. It may also occur in real world data which contains many disjoint polygons (e.g. polygons representing parcels on different street blocks).
The overlap region is determined as the common envelope of intersection. The input polygons are partitioned into two sets:
The Overlapping set is fully unioned, and then combined with the Disjoint set. Performing a simple combine works because the disjoint polygons do not interact with each other (since the inputs are valid MultiPolygons). They also do not interact with the Overlapping polygons, since they are outside their envelope.
In the general case the Overlapping set of polygons will extend beyond the overlap envelope. This means that the union result will extend beyond the overlap region. There is a small chance that the topological union of the overlap region will shift the result linework enough that the result geometry intersects one of the Disjoint geometries. This case is detected and if it occurs is remedied by falling back to performing a full union of the original inputs. Detection is done by a fairly efficient comparison of edge segments which extend beyond the overlap region. If any segments have changed then there is a risk of introduced intersections, and full union is performed.
This situation has not been observed in JTS using floating precision, but it could happen due to snapping. It has been observed in other APIs (e.g. GEOS) due to more aggressive snapping. And it will be more likely to happen if a snap-rounding overlay is used.
DEPRECATED: This optimization has been removed, since it impairs performance.
1.9.4