ST_Union on one-row table doesn't union

[pramsey]

What steps will reproduce the problem?

1. Make a table with a single row including a multipolygon with overlapping parts.
2. Run ST_Union on it.

[mcayland]

Paul,

Is this a 1.4 TODO?

ATB,

Mark.

[pramsey]

Increasing the priority. In cases where ST_Union is combined with GROUP BY this case will occur more frequently in common usage.

[robe]

I assume you mean it just returns the same invalid multipolygon? I ran this example that follows your steps and it returns an invalid Multipolygon. Well the input multipolygon was invalid as well.

Same issue in 3.0.3 and 1.3.5 as far as I can tell.

CREATE TABLE testunion(gid serial primary key, the_geom geometry); INSERT INTO testunion(the_geom) SELECT ST_Collect(ST_Buffer(ST_Point(1,2), 5), ST_Buffer(ST_Point(1,2), 4));

SELECT ST_IsValid(ST_Union(the_geom)) FROM testunion;

I get the same invalid multipolygon when using non-agg ST_Union as well.

SELECT ST_IsValid(ST_Union(the_geom, ST_GeomFromText('POLYGON EMPTY'))) FROM testunion;

Though this seems to behave correctly, but you knew that :)

SELECT ST_IsValid(ST_Union(geom)) FROM (SELECT (ST_Dump(the_geom)).geom FROM testunion) As foo;

[pramsey]

Thanks for testing old versions, that is clarifying. I hadn't considered that the inputs to this case had to be invalid necessarily, I was just thinking in terms of the internal code, which creates an array of simple POLYGON before unioning, so there's no such thing as invalid input.

[robe]

Paul is this really a PostGIS problem or a GEOS one. Not knowing c from a hole in the wall-- it seems we are recursing thru the polygons just to allocate enough space for a GEOS lwpoly. So its GEOS that is not dealing with unioning a single multipolygon correctly. Its probably assuming -- its already one geometry why bother.

I would have thought unioning with an empty geometry collection would solve the issue but doesn't seem too either -- get back the same dumb invalid multipolygon

SELECT ST_OrderingEquals(ST_Union(ST_GeomFromText('GEOMETRYCOLLECTION EMPTY'),the_geom),the_geom) FROM testunion;

[pramsey]

The aggregation thing is a PostGIS... not even sure it's a problem.

http://trac.osgeo.org/postgis/browser/trunk/postgis/lwgeom_geos.c#L135

The "fix" is a one-liner, but having found it I'm not sure I believe it anymore.

[robe]

Oh. How did I miss that one. I think I would have understood that line. So you don't want to fix? In theory if you union a multipolygon you expect the boundaries to dissolve.

Though if that line is the only issue - how come when I unioned with the non-agg version

ST_Union(emptygeomcollection, badgeom) --> I got back the same non-unioned multigeom or is there similar code there.

[pramsey]

It's just that it's a change in behavior... I dunno.

WRT your other question the answer is: it's a totally different code path. And yeah, it seems to be deep in the heart of GEOS. It's probably a similar short-circuit though (oh, hey, one side of my arguments is empty! i'm done!)

[robe]

Yah its not worth fixing. Its not a common thing anyway. If its deep in GEOS too many places to deal with and its just sort of unexpected behavior not necessarily wrong behavior.

I'll paste Martin's comments here for future reference and my comment --

its useful for dissolving valid multipolygons such as US States even if it is one big multipolygon (you get fewer by dissolving).

---

From: Martin Davis mbdavis@… Sent: Thu 6/4/2009 2:52 PM To: Paul Ramsey; PostGIS Development Discussion; Obe, Regina Subject: Re: [postgis-devel] Re: [PostGIS] #101: ST_Union on one-row table doesn't union

Paul, Regina:

Since valid MultiPolygons can't intersect except at points, the union of a MultiPolygon is exactly that MultiPolygon. So technically the short-circuit in the PostGIS code is reasonable.

However, it's useful behaviour to be able to use Unary Union to "clean up" self-intersecting MultiPolygons. This is the way JTS works. It *always* performs a union, even on a single geometry. This also allows Unary Union to be used as a simple way of noding a set of linestrings (since the union of linestrings doesn't merge resultants together).

So I'd vote for removing the optimization from PostGIS - or at least providing an entry point to Unary Union which always does some crunching.

Martin

[strk]

I've completed work to expose the UnaryUnion to GEOS C-API, and about to start the PostGIS side of this.

For the sake of simplicity I'll introduce a new entry-point (ST_UnaryUnion). This will be in trunk.