Osrm-backend: Matching breaks the route into separate routes !

[PooyaRaki]

Hi.

My snapped points are already fine and accurate enough. This is the route without using osrm:

Have a look at my instance of osrm match response here: https://bit.ly/2MWHGoe

Look at the results after calling osrm and decoding matchings.geometry polyline:

The original route is already kind of Ok but matching is needed to make the result even better.

As you can see in the picture the distance between points is definitely < 2000 m.

It seems like osrm is trying to find a suitable route instead of just matching the points. However using the tracepoints from the response doesn't make such a mess.

Any solution to this problem would be highly appreciated. Thanks in advance :)

[danpat]

@PooyaRaki Try adding a radiuses= parameter to your request. The default value is "5", which means a maximum 15m search radius (3 standard deviations), I think you should increase it to 10 or 15.

I think the coordinate that I've higlighted below is the problem - it looks like this point might be >15m away from the real route, so the map-matching algorithm isn't considering that, but is finding the off-ramp. This is causing the large loop, because the off-ramp is one-way, there is no other way to get to the next coordinate that is closer to the correct road.

[PooyaRaki]

@danpat Thanks so much for the quick response.
I had already provided radiuses= and the accuracy for that specific point according to the gps is 1m. You know it is not possible to change the accuracy of points by hand but i send GPS-given data to osrm api.

Beside, that's not the only problem. Take a look at these pictures:

The one in red is the actual path and the green spots are the points but the blue one is map-matched one. I don't really understand why osrm breaks the route and take another route to the destination point!

• Osrm returns 10 different routes and i draw them all on the map. Do you think it's a good practice to draw all the given routes?

[danpat]

@PooyaRaki So, your GPS may be 1m accurate, but OSRM is matching to the geometry that is drawn in OpenStreetMap, which is often the centerline of a road, drawn by a human, from satellite imagery of unknown quality. In addition, OSRM does not take road width into consideration when finding nearby road geometry.

If the road is 20m wide, and you are in the furthest lane from the middle, your 1m accurate point will be 9m away from the line drawn in OSM. Using the GPS accuracy is probably not the right thing to do here, at least, not without multiplying it by some scaling factor to account for road width.

I would guess that most of these matching problems are caused by using too precise GPS accuracy as the radius.

[PooyaRaki]

@danpat Perfect. I can't thank you enough.
I just gave it a try and manipulated the accuracy value of each point manually and it worked like a charm.
Just another question:

Using the GPS accuracy is probably not the right thing to do here, at least, not without multiplying it by some scaling factor to account for road width.

what do you mean by

some scaling factor to account for road width

what is that? how can i calculate the correct accuracy of each point? Right know i remove the ones which are farther than 100m, should i also remove those with the accuracy of let's say < 10m?

[danpat]

@PooyaRaki Practically, I would just set the radiuses= to 15 or 20 and leave it at that.

The parameter is supposed to represent "1 standard deviation of position confidence", and OSRM, following the https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule, will search up to 3x that value, to give 99.7 confidence that we've found a nearby road.

There are two issues that you need to consider: 1) It's probably not super well defined what the value you're getting from your GPS system represents (is it a similar 1 standard deviation or something else? I know Apple/iOS do not define what their accuracy value means. Android does (https://developer.android.com/reference/android/location/Location.html#getAccuracy()) say it's "68% confidence interval", which is basically the same as we expect here).

The second issue though is centerline mapping - you need to allow for the way OSM maps road centerlines - by adding a worst-case buffer. If a road could be 25m wide, and your "real" position is on the side of the road, and the GPS point has an error of 15m even further away, you need to search 27.5m to actually find the road (which means radiuses= would need to be at least 9.2 to work in this scenario).

I'd just set it to 15 or 20 or whatever value makes your traces work.