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

[Chris Hermansen]

As someone accustomed to doing my geoprocessing in ArcInfo, one of the
first things I was looking for in PostGIS was the ability to do:

    INTERSECT conserv_area forest cons_for POLY 1.0 NOJOIN

I guess I probably naively tried something like:

    CREATE TABLE cons_for AS
    SELECT

        conserv_area_id,
        forest_id,
        st_intersection(conservation_areas, forest) the_geom

    FROM conservation_areas, forest

At that point, I must have wondered about what exactly that stuff was in
the_geom in the new table

Maybe it's not too much of a stretch to wish for

    SELECT
    st_just_gimme_the_polygons(st_intersection(conservation_areas,forest))


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
>   


-- 
Regards,

Chris Hermansen         mailto:chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue  · Vancouver BC · Canada · V5Z 1E5