I've been thinking for a while now that the binary overlay functions
should actually return a more structured return type for hetergeneous
return values. Something like:
GEOMETRYCOLLECTION ( MULTIPOLYGON (...), MULTILINESTRING(..),
MULTIPOINT(...))
(If any of the dimensional elements were a single component a
non-collection geometry would be used instead)
This would make it easier to parse out the desired component. It would
also indicate that the polygonal return value is in fact a valid
MULTIPOLYGON (which is the case, and which is not indicated by the
current value of "a bag o' polygons".
For PostGIS it would still be nice to have an extraction function which
would extract the geometries of a desired dimension. This would be
generally useful, I think, so should be a separate function from the
overlay functions.
I will also note that it's not in general correct to simply take a bag
o' polygons and turn them in to a MULTIPOLYGON. For this to be valid
you need to know that the input polys don't properly overlap.
Paul Ramsey wrote:
Well, right now, how do I turn a column of MULTIPOLYGON goemetries
into a single collected MULTIPOLYGON? I have to rather inefficiently
explode them, then re-collect them. Kind of a trivial example.
More fiddly for people to currently solve, the ST_Intersection()
function can spit out heterogeneous GEOMETRYCOLLETIONS as a result.
And usually, the end-user just wants one component of that... if
intersecting lines on polygons, they just want lines, and don't care
about any points. Or if doing poly-on-poly, they don't care about any
lines or points that fall out the bottom, as occasionally happens.
P.
On Wed, Jan 28, 2009 at 4:40 PM, Mark Cave-Ayland
<[email protected]> wrote:
Paul Ramsey wrote:
I would like to add a function that takes an anonymous
GEOMETRYCOLLECTION and returns something more structured:
- a GEOMETRYCOLLECTION where the first element is a MULTLIPOLYGON, the
second a MULTILINESTRING and the third a MULTIPOINT?
- a tuple, with elements 'polygons', 'linestrings', 'points', each
with one multi* of each?
- a tuple, with elements 'polygons', 'linestrings', 'point', each with
an array of singletons?
The key here is to provide a useful flat structure to pull info out
of. Some information in the GEOMETRYCOLLECTION *will be lost*, (but
that seems an acceptable price)
Another approach, which might be simpler for users to grok would be:
ST_CollectionAsMultiPolygon() returns just the polygon elements of a
collection.
... etc ...
Thoughts?
P.
Hi Paul,
I'm still struggling to get an idea of exactly what these proposed functions
are trying to achieve. Can you show some potential problems/SQL statements
showing how you would envisage these functions being used?
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
