# From trajectory of GPS points to multiline segment?

Given a trajectory as a sequence of GPS points I would like to create a smooth linestring representing a path where a car drove. The data is stored in postgresql: the input trajectory in a table, where each row represents an individual GPS point, the output in a table, where each row represents the whole smooth tragectory. All points are stored in WGS84.

My approach for this would be the following:

• implement everything in C++
• retrieve the whole trajectory from the DB, convert it to UTM32N (as this is where the trajectories are coming from), flatten the points with the help of GDAL library
• compute a some sort of approximate spline
• linearize the approximate spline
• transform it back to WGS84
• send the data back to Postgres

What would be the best tools/libraries to use for approximate splines and linearization?

Java/C++/Postgis solutions are preferable, as currently we are using only these subsystems.

I suppose this is a very common task people need to do in gis environment, however I haven't found close matches to similar questions on gis stackexchange.

An alternative would be to:

• collect all points into linestring
• ST_LineToCurve
• apply Bezier smoothening to the curve
• ST_CurveToLine

The best solution up till now implements everything in SQL with postgres. It uses moving averages (windowing function) to smoothen out the trajectory plus some simplification of the computed path. Here's the SQL code:

``````  select
--    st_simplify(
st_curvetoline(st_linetocurve(st_makeline(the_geom)),1000)
--    ,0.00001)
from (
select orderid, st_makepoint(avg(x) over w, avg(y) over w) as the_geom
from (
select orderid, x(the_geom) as x, y(the_geom) as y
from tracepoints
) as moving_averages
window w as (order by orderid rows between 1 preceding and 1 following)
) as make_the_line
``````

uncomment some lines to remove simplification. One may also decide to drop the curvetoline and linetocurve functions

• This seems reasonable. The best approach I think depends to some extent on the shape of your data. You'll have some jitter around the "true path" that a smoothing will take out. You might also have some outliers, which you would rather ignore than add to the average path. These would require some other sort of smarts to handle. Apr 15 '13 at 21:53
• @PaulRamsey: thanks for the useful comment. In fact, I noticed that our trajectories jitter around the "true path" as you mentioned above. We have collected quite a number of trajectories and frankly, we haven't seen any outliers. The smoothing works quite nicely for the jittering errors, however messes up things if a car drives through a round about or makes a sudden turn. Any ideas what can be done in these cases? Apr 16 '13 at 9:28
• The moving average is probably at fault for taking out the sharp corners. Such is the nature of averages. I don't know what the linetocurve and curvetoline are doing for you, they aren't really built to be used in that way. Jun 14 '13 at 21:05