I would add that, especially with plpgsql or sql wrappers to PostGIS that
others might find useful, there is the user contributed plpgsql section on
the wiki: http://trac.osgeo.org/postgis/wiki/UsersWikiMain
On Fri, Jul 31, 2009 at 1:20 PM, Kevin Neufeld <kneuf...@refractions.net>wrote:
> Unfortunately, I think your solution is overly simplistic. I think the
> community is after something that mimics the ST_Dump and ST_DumpRings
> functionality.
>
> ie.
> SELECT (ST_Dump('MULTILINESTRING((0 0, 1 1),(2 2, 3 3))'::geometry)).*;
> path | geom
>
> ------+------------------------------------------------------------------------------------
> {1} |
> 01020000000200000000000000000000000000000000000000000000000000F03F000000000000F03F
> {2} |
> 0102000000020000000000000000000040000000000000004000000000000008400000000000000840
> (2 rows)
>
> In order to extract all the points from every geometry in a table we would
> need to be able to have this example query work that also returns a SETOF
> geometry_dump:
>
> SELECT (ST_DumpPoints(the_geom)).*
> FROM my_spatial_table;
>
> The path portion of the geometry_dump datatype is important because users
> know the index of POINT in the geometry. It'll be possible then, for
> example, to extract all but the endpoints. Additionally, users could group
> the points back together to rebuild the original geometry from whence they
> came.
>
> Also, your function would need to be a lot more robust (ie. ideally, able
> to accept all geometry types, POINT, LINESTRING, MULTIPOLYGON,
> GEOMETRYCOLLECTION, etc).
>
> I agree, the st_dump code does indeed look a little overwhelming. I don't
> think we're tied to having the function written in C (there are many plpgsql
> functions in PostGIS). If you think you can come up with something that
> meets the desired specifications, please, by all means, feel free to propose
> something to the postgis-devel list. We'd love the help!
>
> Cheers,
> Kevin
>
>
> Maxime van Noppen wrote:
>
>> I was looking to PostGIS source code to see how hard it is to implement
>> and if I could be of any help but the st_dump function implementation is
>> quite complicated (at least for somebody exterior to the project).
>>
>> Is there any reason not to provide the function as an plpgsql
>> function ? Would a C implementation run really faster ?
>>
>> The SQL code seems quite simple, I currently use something like :
>>
>> CREATE FUNCTION dump_line(l geometry) RETURNS SETOF geometry AS $$
>> BEGIN
>> FOR i IN 1..ST_NumPoints(l) LOOP
>> RETURN NEXT ST_PointN(l, i);
>> END LOOP;
>> END
>> $$ LANGUAGE plpgsql;
>>
>> _______________________________________________
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
--
************************************
David William Bitner
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
