Certain Match requests will freeze/crash osrm-routed

[YoshiWalsh]

Hi,

We're using OSRM in our production environment, but we've noticed that it can be somewhat unstable. Certain requests cause it to timeout (after 60 seconds) and stop accepting future requests.

Here's the simplest example of a problem request that we could find:

/match/v1/driving/polyline(h_umEe_{y[??)?timestamps=1528274382;1528274400&radiuses=500;500&tidy=true

The same thing happens even if the tidy parameter is excluded.

The expectation is that this request should return a distance of 0. It's not always 0-distance matches that cause problems, sometimes the problematic matches should return several kilometres. If I come across any more examples of problematic requests I'll add them here.

Thanks,

Josh

[daniel-j-h]

500 meter radius looks suspicious; ideally you would scale it with the gps error.

Standard deviation of GPS precision used for map matching. If applicable use GPS accuracy.

A high radius increases the candidate set; check #3184 for details.

[YoshiWalsh]

The radius is based on the GPS accuracy, the accuracy was just very poor for this trip.

EDIT: I can see that if I remove 'radiuses', the request succeeds. I'm not sure the best way to handle this, sometimes our users don't have good GPS reception (or their phones are in power saving mode) and we still need to accept this data.

[TheMarex]

@YMIndustries the way this is usually handled is by adding a hard limit on the GPS accuracy. If it is more than say 50 or 100 meters it is not a good idea to try to map match.

[YoshiWalsh]

If that's the case, should points with radius>100 be excluded from the dataset, or should I clamp the radius before I sent it to OSRM?

Also, surely OSRM should reject a request like this instead of crashing?

[TheMarex]

@YMIndustries clamping is fine, the map matcher should remove the point automatically if it doesn't find a good match.

The problem with a big radius is that there are too many candidates so the calculation just takes too long, it shouldn't crash. The 500 you see is from a timeout on a load balancer I would guess?

[YoshiWalsh]

I don't get a 500 response from osrm-routed, I just don't get any response. Maybe if I kept waiting then eventually I'd get a response, but my request timeout is configured for 60 seconds. The 'crashing' might actually just be my automatic health checks flagging the VM as unhealthy and terminating it.

Is there a way to configure OSRM to have its own timeout? My client will stop waiting for a response after 60 seconds, but OSRM keeps trying in the background. It'd be nice if OSRM gave up at the same time as my client did.

I'll add radius clamping to my client, thanks.

[timotew]

I have similar issue as @JoshuaWalsh, I was able to solve it by removing the radiuses that are greater than 100. requests that take 12min now take 14ms. I think this issue can be closed. @TheMarex .

[danpat]

Specifying large radiuses basically makes the algorithm infeasible in dense road networks. The approach only really works if there are a few candidates per point. If you use a large radius and each point has hundreds of nearby candidates, then the number of combinations to check explodes, and the algorithm takes a long time to complete.

If you have poor quality GPS data with very large error margins, then the odds of these points being correctly matched greatly decrease. You are likely better off filtering out very poor data like this.

The general advice here is - keep the radius as small as possible for fastest response time. The default is 5m.