[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-users
Subject:    Re: [postgis-users] Call for Semantics (ST_CollectionTypes())
From:       Martin Davis <mbdavis () refractions ! net>
Date:       2009-01-29 16:48:23
Message-ID: 4981DDD7.1050902 () refractions ! net
[Download RAW message or body]

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@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@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>     
> _______________________________________________
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>   

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

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[prev in list] [next in list] [prev in thread] [next in thread]