Opened 10 years ago

Closed 9 years ago

#922 closed enhancement (fixed)

Have ST_Union aggregate use UnaryUnion from GEOS-3.0.0

Reported by: strk Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: main
Keywords: Cc:

Description

Current code of PostGIS uses GEOSUnionCascaded only for polygons, and that's even correct because the GEOS C-API GEOSUnionCascade would throw an exception if anything but (multi)Polygons are given.

Instead the new GEOSUnaryUnion interface from GEOS-3.0.0 accepts any kind of geometry. Internally uses Cascaded union for polygons but also does special handling of points and lines. See http://trac.osgeo.org/geos/ticket/392 for an example case in which the UnaryUnion? works whereas normal union doesn't.

Always using UnaryUnion? when build against GEOS-3.3.0 would then simplify the code and improve union robustness.

Change History (3)

comment:1 Changed 9 years ago by pramsey

I've got this implemented, but it has a single regression "failure" in topology.

--- regress/legacy_query_expected       2012-01-25 09:31:33.000000000 -0800
+++ /var/folders/vQ/vQpcmrOZEXuINbyg+7Jj4k+++TI/-Tmp-//test_5_out       2012-02-06 14:54:43.000000000 -0800
@@ -41,7 +41,7 @@
 E25|7|MULTILINESTRING((9 35,13 35))
 R1a|8|MULTILINESTRING((9 14,21 14,35 14))
 S1S2|MULTIPOINT(21 14,35 14)
-R1R2|MULTILINESTRING((36 38,38 35,41 34,42 33,45 32,47 28,50 28,52 32,57 33,57 36,59 39,61 38,62 41,47 42,45 40,41 40),(9 14,21 14,35 14))
+R1R2|MULTILINESTRING((9 14,21 14,35 14),(36 38,38 35,41 34,42 33,45 32,47 28,50 28,52 32,57 33,57 36,59 39,61 38,62 41,47 42,45 40,41 40))
 R4|MULTILINESTRING((25 30,25 35))
 P1P2|MULTIPOLYGON(((21 6,9 6,9 14,9 22,21 22,35 22,35 14,35 6,21 6)))
 P3P4|MULTIPOLYGON(((47 14,47 6,35 6,35 14,35 22,47 22,47 14)),((25 30,17 30,17 40,31 40,31 30,25 30)))

As you can see this isn't really a regression failure. Unfortunately, the topology regression suite is so tightly coupled together it's quite hard for me to exempt this case while also allowing this functionality to be conditional on GEOS 3.3. Basically if GEOS 3.3 is present the test will fail, if not it will pass. Or the reverse if I change the expected.

comment:2 Changed 9 years ago by pramsey

Nevermind, of course topology can only be enabled with GEOS >= 3.3 so since this only kicks it with GEOS >= 3.3 we should be fine if I just change the expected.

comment:3 Changed 9 years ago by pramsey

Resolution: fixed
Status: newclosed

Done at r9056

Note: See TracTickets for help on using tickets.