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: <a href="http://trac.osgeo.org/postgis/wiki/UsersWikiMain">http://trac.osgeo.org/postgis/wiki/UsersWikiMain</a><br>

<br><div class="gmail_quote">On Fri, Jul 31, 2009 at 1:20 PM, Kevin Neufeld <span dir="ltr"><<a href="mailto:kneufeld@refractions.net">kneufeld@refractions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Unfortunately, I think your solution is overly simplistic.  I think the community is after something that mimics the ST_Dump and ST_DumpRings functionality.<br>
<br>
ie.<br>
SELECT (ST_Dump('MULTILINESTRING((0 0, 1 1),(2 2, 3 3))'::geometry)).*; <br>
 path |                                        geom<br>
------+------------------------------------------------------------------------------------<br>
 {1}  | 01020000000200000000000000000000000000000000000000000000000000F03F000000000000F03F<br>
 {2}  | 0102000000020000000000000000000040000000000000004000000000000008400000000000000840<br>
(2 rows)<br>
<br>
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:<br>
<br>
SELECT (ST_DumpPoints(the_geom)).*<br>
FROM my_spatial_table;<br>
<br>
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.<br>


<br>
Also, your function would need to be a lot more robust (ie. ideally, able to accept all geometry types, POINT, LINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION, etc).<br>
<br>
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!<div class="im">

<br>
<br>
Cheers,<br>
Kevin<br>
<br>
<br>
Maxime van Noppen wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I was looking to PostGIS source code to see how hard it is to implement<br>
and if I could be of any help but the st_dump function implementation is<br>
quite complicated (at least for somebody exterior to the project).<br>
<br>
Is there any reason not to provide the function as an plpgsql<br>
function ? Would a C implementation run really faster ?<br>
<br>
The SQL code seems quite simple, I currently use something like :<br>
<br>
CREATE FUNCTION dump_line(l geometry) RETURNS SETOF geometry AS $$<br>
BEGIN<br>
  FOR i IN 1..ST_NumPoints(l) LOOP<br>
    RETURN NEXT ST_PointN(l, i);<br>
  END LOOP;<br>
END<br>
$$ LANGUAGE plpgsql;<br>
<br>
</blockquote></div><div><div></div><div class="h5">
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>************************************<br>David William Bitner<br>