#1271 closed defect (fixed)
ST_Line_Locate_Point inaccurate closest point
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
After the robustness fix in r8107 there's a regress test failing in regress_lrs. The test shows that closest_point_on_segment and lw_dist2d_distancepoint disagree on what's the projection of a far-away point onto a single-segment line.
Change History (6)
comment:1 by , 13 years ago
Owner: | changed from | to
---|---|
Priority: | medium → high |
Status: | new → assigned |
comment:2 by , 13 years ago
comment:3 by , 13 years ago
That doesn't fix. It is the equality comparison that puzzles me:
( proj.x == end.x) && (proj.y == end.y)
End should be the last point and proj would be the return from closest_point_on_segment
comment:4 by , 13 years ago
Oh.. wonder. =# SELECT 'line_locate_point_1', ST_line_locate_point('LINESTRING(709243.393033887 163969.752725768,708943.240904444 163974.593889146,708675.634380651 163981.832927298)', 'POINT(705780 15883)'); NOTICE: t:3, pa->npoints:3, end:(708943 163975)
Indeed "end" is _not_ the last point, but the second-last. It's actually the endpoint of the first segment. I guess I should be using "seg" rather than "t"
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
To better explain: the issue is that 't' is not the segment of the closest point, unless the query point is _on_the_line_.
Fixed with r8112
Thanks for looking at this, Nicklas
comment:6 by , 13 years ago
Better fix about the seg vs. npoints with r8115 (we actually had to subtract 2, not 1, from npoints)
I think you have a typo in r8107. pa->npoints is 1-based, not 0-based, right?
Then shouldn't it be instead?:
That would explain it since the answer from st_closestpoint is the same as the second last vertex, not the last.
/Nicklas