Opened 11 years ago

Last modified 4 years ago

#931 new defect/bug

New Variable to set GPS quality threshold for routing

Reported by: ah be Owned by: KaZeR
Priority: major Milestone: version 0.6.0
Component: core Version: git master
Severity: normal Keywords: gps, fix, routing
Cc: openid@…, michael@…


The current state:

  • Enter final destination
  • Navit gets a first fix from gps and starts the tts engine to give directions

The problem:

  • If you are eg. on a landline right next to a highway and the gps signal jumps in position navit is constantly recalculating the route. If you have a low powered cpu as in the neo freerunner your system crashes and (android-froyo) freezes...

Possible avoidance:

  • A new varible which let's you decide on when to start the route-calcuation after a fix: eg. gps-quality-for-fix = 0-5 eg based on the calculated lateral deviation of the position

Change History (13)

comment:1 Changed 11 years ago by antenna

Most highways can only be left on exit ramps. So another possible avoidance would be to disable jumping from highways. Apart from increasing the work load, the steady recalculation leads to confusing announcements.

comment:2 Changed 11 years ago by rainer dorsch

This is always an issue with weak GPS signals, e.g. with the bike in a forest: When approaching a 4-way crossing with the routing intention to simply cross it (no left-/right-turn), a GPS error to the right (left) can position the vehicle on the street crossing from the right (left). I this case, navit then announces turn right (left), which is clearly wrong.

Here it is unlikely, that a vehicle approaches a crossing "suddenly" from another direction.

I have seen that behavior many times, when biking on tracks in a forest.

comment:3 Changed 11 years ago by rainer dorsch

  • Cc openid@… added

comment:4 Changed 11 years ago by tegzed


I guess you problem is that you have tracking disabled. Tracking is the module in navit that assotiates an osm way to the current position and when multiple roads are in range it tries to keep the vehicle on the previously driven road. As I remember static speed only applies when tracking is enabled. So please try setting tracking="1" in your navit tag of your navit.xml and let us know if this solves your problem.

comment:5 Changed 11 years ago by ah be

I agree with you that if the signal gets weaker one will have problems on crossings. My suggestion here with this ticket though is about the initial start up:

starting the gps receiver one will usually get a fix within the first 45 seconds. if I look at the gps data of the freerunner one gets a 2d fix first (2 or 3 satelites) which shows me quite a big possibility of lateral deviation. once more satelites are present the deviation is less then 5m. this behaviour is also shown in my navit osd which shows me red,yellow and green signal strengths which most likely correspond to the lateral deviation.

So my question is if

one can add a variable for gps startup which waits for the lateral deviation to be below a set threshold before route calculation is started?

comment:6 Changed 10 years ago by mvglasow (2)

  • Cc michael@… added

comment:7 Changed 10 years ago by usul

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

Can anybody confirm, if such issues can be fixed by enabling tracking?

comment:8 Changed 10 years ago by mvglasow (2)

Tracking doesn't help.

I just examined my navit.xml, the navit tag is

<navit center="4808 N 1134 E" zoom="32" tracking="1" orientation="-1" recent_dest="250" timeout="86400">

Since I use git to merge the default navit.xml of the current version with my own customizations (layouts etc.), I can tell for a fact that I've had tracking enabled for at least a year (and I believe tracking is even enabled by default). However, I still experience the above issues.

I've opened #1093 in response, suggesting some tweaks to the "lock on road" algorithm. We might want to merge the two tickets into one.

comment:9 Changed 10 years ago by ah be

I would prefer not to merge the two tickets as in my opinion they present individual problems.

#1093 is to stay on the track you have been, even though you pass another track at some large angle to your previous path (so calculating an average direction vector might help, but uses cpu)

#931 was really about a possibility to wait for routing to be initialized only when a certain gps quality is reached (as route calculating consumes cpu/battery as well and if the route changes 5 times in 2 minutes due to gps offset that is not very satisfying)

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

Hmmm... OK, I realize we do have some overlap. You are talking about the first fix, others (including me) are talking about cases in which GPS performance degrades after startup. True, these are two distinct, albeit closely related problems.

As for startup: introducing a threshold for accuracy would probably solve re-routing issues on first fix, but it would also introduce a delay before navigation begins. That would be a degradation in user experience - I once had a satnav that seemed to do something like that, and having to wait for ages before the device starts routing can be frustrating.

This delay may be necessary when there is a dense network of roads and the position cannot be determined unambiguously from a low-precision fix. However, when the low density of the road network leaves no doubt about which road we're on, insisting on fix quality will do more harm than good. Think about a single road in the middle of the woods - the foliage will block the GPS, but even with a bad GPS signal there is only one road that we could possibly be on.

Suggestion: rather than a hard threshold, choose a dynamic one. Specifically, require the lateral error of the GPS to be lower than the distance to the next road.

That being said, it may make sense to bear in mind that the GPS signal may also degrade while routing (imagine driving on a road in open country, then entering a forest, or a narrow city street).

comment:11 Changed 8 years ago by nezmi

  • Severity set to normal

Please take a look at, if this might be a viable solution for the "jumping position" problem.

comment:12 Changed 5 years ago by

  • Milestone changed from version 0.5.1 to version 0.5.2

This ticket was pushed back in order to bring 0.5.1 out soon.

comment:13 Changed 4 years ago by

  • Milestone changed from version 0.5.2 to version 0.6.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.