[postgis-users] ST_Dump-like function for simple (non-multi) geometries ?

[Kevin Neufeld]

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;
>