Opened 16 years ago
Last modified 15 years ago
#76 closed enhancement (fixed)
ST_DumpPoints - I think we said we would add to TODO — at Version 4
| Reported by: | robe | Owned by: | robe |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 1.5.0 |
| Component: | postgis | Version: | master |
| Keywords: | Cc: |
Description (last modified by )
As described here http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003142.html
Though I would keep with the path, geom geom_dump structure we have for ST_Dump and ST_DumpRings. Though the path would be rarely used, I think there are times it comes in handy to reference back to a geometry.
Change History (5)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
I always thought so. You would definitely need to group points back with the specific Polygon/Line they came from and that is why the path is probably even more so important for ST_DumpPoints
by , 15 years ago
| Attachment: | my_st_dump_points.sql added |
|---|
A proprosed implemenation of ST_DumpPoints by Maxime van Noppen (maxime@…)
comment:4 by , 15 years ago
| Description: | modified (diff) |
|---|
I just attached an implementation of ST_DumpPoints by Maxime van Noppen (maxime@…) recently posted on postgis-users (http://postgis.refractions.net/pipermail/postgis-users/2009-August/024118.html)
At first glance it looks promising. Would a C implementation really be noticeably faster?
Thoughts, team?
Wow. An actual use case for the 'path' part of ST_DumpRings. http://postgis.refractions.net/pipermail/postgis-users/2009-February/022674.html
I guess it would good to have a similar datatype for ST_DumpPoints.
— Kevin