I can confirm this is a useful use case. I ran into the same issues
doing soils analysis. I think a filter to extract the items you want
would be very useful.
-Steve W
Chris Hermansen wrote:
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
<[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
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
