[postgis-users] Call for Semantics (ST_CollectionTypes())

[Martin Davis]

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
> <mark.cave-ayland at siriusit.co.uk> 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
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>     
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022