# Differences between ST_ClosestPoint and ST_LineInterpolatePoint?

As a bit of context : my exact goal is taking the set of points (some GPS data) and correcting their position so that they intersect some lines (OSM roads data), to have them nicely sitting on the roads. I will then use those corrected positions to compute several things.

While working on projecting a set of points onto a set of lines, I have stumbled upon two functions : ST_ClosestPoint and ST_LineInterpolatePoint (used with ST_LineLocatePoint).

Which I used this way :

``````Create table projected_points as (
Select
p.id,
p.geom as original_pt,
ST_ClosestPoint(l.geom, p.geom) as closest_pt,
ST_LineInterpolatePoint(l.geom,
ST_LineLocatePoint(l.geom, p.geom)
) as interpolated_pt,
From points p, lines l
);
``````

I've tried out both functions, and found that both functions almost never return points that actually intersect the lines. Which in itself made me wonder what was going on, so I used an ST_Distance to try and understand what went wrong.

Using the following query :

`````` Select
ST_Distance(p.closest_pt, l.geom),
ST_Distance(p.interpolated_pt, l.geom),
From projected_points p, line l
``````

On the left is what I get with ST_ClosestPoint. On the right, what I get using ST_LineInterpolatePoint. In both cases, having a distance of "0" doesn't necessarily mean that the point intersects the line. I also notice that the distances that were computed were all the same digits.

But it seems like ST_LineInterpolatePoint works better. On the downside, it requires me to use ST_LineLocatePoint first, which makes my code very heavy.

What makes the two functions different, yet so similar ?

• all those values look like 0 to me - can you add the actual queries that generated them. Commented Apr 26, 2018 at 10:18
• @IanTurton I have added the queries. But if they do look like 0, I'm wondering why they don't count as "intersecting" according the ST_Intersects. Should I use an ST_DWithin with a tiny distance parameter as a workaround ?
– GHRF
Commented Apr 26, 2018 at 10:31
• depends on the projection are you using 4326? in which case you probably want to use `geography` objects Commented Apr 26, 2018 at 10:34
• Floating point arithmetics are not accurate en.wikipedia.org/wiki/…. Small differences in algorithms or in which order the operations are performed leads into slightly different results. A common approach is to read the geometries through ST_SnapToGrid postgis.net/docs/manual-2.0/ST_SnapToGrid.html with a small tolerance like 0.000001. Commented Apr 26, 2018 at 10:54
• ...or truncate to a realisitc precision; although a little off-topic (it´s mainly about saving storage space), this is a nice post about all those decimal digits that represent precision in dimensions where no man has gone before. in the end you can get similar results and less storage space (note the use of `ST_AsTWKB` at the very bottom). might be worth a thought, I´m currently experimenting with it a lot. Commented Apr 26, 2018 at 13:11