Opened 10 years ago

Last modified 6 years ago

#1093 new defect/bug

Improvements to "Lock on road" feature

Reported by: mvglasow (2) Owned by: KaZeR
Priority: major Milestone:
Component: core Version: git master
Severity: normal Keywords: gps, precision, routing


On a trip halfway across Europe I had repeated issues where Navit would determine that my position was next to the road rather than on it.

As I was recording a GPS trace at the same time, I was able to analyze the data. In some cases the map data was inaccurate and I corrected it. However, sometimes the error was caused by imprecisions of the GPS itself - I could see my trace was slightly off when compared to aerial imagery and also most other GPS traces. I have had the issue with both my current Nexus S and the GeeksPhone? One I had before. Conditions that seem to contribute are roads cutting through forests, possibly also high speeds and weather conditions.

When this happens, Navit will either pinpoint my location to be slightly next to the road and start rerouting (losing my previous route and leaving me without guidance for some time) or, in some occasions, put me on a small path that happens to run next to the motorway, resulting in completely erroneous routing instructions.

Suggestions to improve this:

  • Increase the tolerance margin for the "lock on road" feature
  • Choose the "right" road not only based on distance but also on other factors. This kind of "preference" can be implemented by simply decreasing the "raw" distance (or increasing it to penalize a way) and using that score to determine the best candidate way.

I suggest the following criteria:

First, give preference to ways that are part of the current route (suggestion: divide distance by 2, this should not be too difficult to do).

Also distinguish for one-way roads: when a road is one-way and its bearing differs from the vehicle's bearing by more than 90 degrees, add a penalty for that road. (On platforms that report GPS accuracy in meters, use that value; where unavailable, use HDOP multiplied by 5 to 10 meters). This is to prevent the vehicle from ending up on the opposite lane of a dual-carriageway road.

Additionally (though this might be complex), use the last known position (with "lock on road" correction applied) and give preference to the ways which can be reached from there in the time elapsed since the last position was obtained.

For example, if:

  • the last position was on a highway, obtained one second ago, and
  • the new position is halfway between the highway and a parallel road and
  • the nearest connection between the highway and the parallel road is 2 km away

then a regular road vehicle that is subject to the laws of physics is unlikely to have made it from the highway onto the parallel road, and it is more likely that it is following the highway.

Change History (4)

comment:1 Changed 9 years ago by usul

  • Keywords gps precision routing added
  • Milestone set to version 0.5.1

Sadly I'm not that familar with the internal GPS data workflow itself. But your idea sounds reasonable to me and yes, drive without a route is a very bad user experience :/

So I schedule it for next hotfix release.

comment:2 Changed 9 years ago by mvglasow (2)

See also some comments on #931, which deal with similar problems (GPS sinal degradation while routing places vehicle on wrong road, causing re-routing).

comment:3 Changed 8 years ago by nezmi

  • Severity set to normal

Please have a look at, if this might be a viable solution.

comment:4 Changed 6 years ago by

  • Milestone version 0.5.1 deleted

Removed 0.5.1 target because I think this is probably done (not tested) and even it is not a real bug.

Note: See TracTickets for help on using tickets.