New Variable to set GPS quality threshold for routing

[aerostitch]

Issue migrated from trac ticket # 931

component: core | priority: major | keywords: gps, fix, routing

2011-09-03 22:00:46: spielraum@web.de created the issue

---

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

[aerostitch]

2011-09-12 09:35:09: antenna commented

---

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.

[aerostitch]

2011-09-25 14:01:03: openid@bokomoko.de commented

---

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.

[aerostitch]

2011-09-25 23:05:31: tegzed commented

---

Hello,

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.

[aerostitch]

2011-09-26 04:41:19: spielraum@web.de commented

---

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?

[aerostitch]

2013-07-09 11:20:06: usul

[aerostitch]

2013-07-09 11:20:06: usul commented

---

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

[aerostitch]

2013-07-12 07:38:19: @mvglasow commented

---

Tracking doesn't help.

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

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.

[aerostitch]

2013-07-12 20:56:51: spielraum@web.de commented

---

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)

[aerostitch]

2013-07-14 06:54:41: @mvglasow commented

---

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).

[aerostitch]

2014-08-10 10:20:38: thomas.maus@gmx.de changed severity from * to normal*

[aerostitch]

2014-08-10 10:20:38: thomas.maus@gmx.de commented

---

Please take a look at [http://trac.navit-project.org/ticket/1232], if this might be a viable solution for the "jumping position" problem.

[aerostitch]

2017-12-02 04:08:44: @jkoan

[aerostitch]

2017-12-02 04:08:44: @jkoan commented

---

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