#2032 closed enhancement (invalid)
Higher dimension support for ST_ClosestPoint
Reported by: | strk | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.1.0 |
Component: | postgis | Version: | 2.0.x |
Keywords: | Cc: |
Description
When you look for "the closest point" I think you want a point with all dimensions in it. At least Z, if the first geometry had one.
What's the closest point to 'POINT(6 0)' on 'LINESTRING(0 0 0, 10 0 40)' ?
I think it should be 'POINT(5 20)', and not 'POINT(5 0)'
Change History (3)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
We have one already. RTFM
http://www.postgis.org/documentation/manual-svn/ST_3DClosestPoint.html
comment:3 by , 12 years ago
For reference the ticket about weird result by ST_3DClosestPoint is #2034
But I'd note that ST_Intersection() returns 3dZ if any input is 3dZ…
Note:
See TracTickets
for help on using tickets.
I'm still around
First, I guess you mean that today's function returns 'POINT(6 0)' and not 'POINT(5 0)'.
Then I think that you suggest the answer 'POINT(5 0 20)' and not 'POINT(5 20)', right?
I disagree. ST_ClosestPoint is a 2d function. When I implemented ST_3dClosestPOint we had (Regina and me I think) a discussion about if we couldn't include the 3d-functionality in the ST_ClosestPoint function. The reason we didn't is that you should be aware about what dimensions is used in the calculation. You can work on data sets where you are not aware of the z-value. And then you will just get very strange 2d-results. If you want the z-value in the calculation you should use ST_3DClosestPoint. But I see htt ST_3DClosestPoint is handling this situation in a strange way. I will open a ticket on that.