Opened 11 years ago

Last modified 4 years ago

#920 new defect/bug

Filter out "garbage" bearing information when standing still

Reported by: mvglasow (2) Owned by: KaZeR
Priority: minor Milestone: version 0.6.0
Component: core Version: git master
Severity: Keywords: GPS speed tracking


When standing still (e.g. waiting at a red traffic light), the GPS will report slightly varying positions. When taking a GPX trace and examining it, you will frequently encounter two phenomena:

  • a "cloud" of trackpoints scattered randomly around the actual position
  • trackpoints gradually "drifting" off the actual position

Especially the first will give highly irregular (and incorrect) bearings. Unfortunately, since Navit does not filter these, this has two undesirable side effects:

  • If the map is set to follow the vehicle, it will twist around randomly while the vehicle is standing still, consuming resources and confusing the user.
  • In any case, the route will be recalculated as the heading changes, resulting in bogus routing instructions and confusing the user.

Proposed solution: GPS position/bearing readings are "trustworthy" only if the speed (or the distance between current and last "trustworthy" position reading) is above a certain threshold. Discard bearing information that is not "trustworthy" (maybe also position information).

The thresholds may need some experimentation (I'd start with something around 5 km/h for speed and a few meters for distance) and may also depend on the vehicle type (pedestrians are trickiest due to their low speed); it's probably best to make them configurable.

On the long run, we might use magnetic compass readings, where available (Android has an API for that). However, this is only available on some platforms and not all devices have the necessary hardware, so we still need to make the best out of the GPS signal.

Change History (12)

comment:1 Changed 11 years ago by mvglasow (2)

Also see #799, which is somewhat related − it deals with "invalid" bearings after loss of GPS signal, a comment also refers to issues when standing still

Last edited 11 years ago by mvglasow (2) (previous) (diff)

comment:2 Changed 11 years ago by tegzed


have you tried setting tracking="1" in <navit> tag and setting eg static_speed="5" in your vehicleprofile? I guess this should solve these problems.

comment:3 in reply to: ↑ description Changed 11 years ago by korrosa

Replying to


Proposed solution: GPS position/bearing readings are "trustworthy" only if the speed (or the distance between current and last "trustworthy" position reading) is above a certain threshold. Discard bearing information that is not "trustworthy" (maybe also position information).


In fact, Navit has both these options. The <vehicleprofile> tag can include the following two attributes (as alluded to by tegzed):

  • static_speed - speed in km/h
  • static_distance - distance in metres

The attributes are pretty self explanatory, but for more information see and ctrl+f for one of the attributes.

comment:4 Changed 11 years ago by mvglasow (2)

in fact, the Android build has it already defined in the XML, but WinCE doesn't seem to have it. I'll look into it; I think this should be included in the default navit.xml on all platforms.

comment:5 Changed 11 years ago by mvglasow (2)

update: the two attributes are added to all vehicleprofiles in navit_shipped.xml, so all platforms should have it. Indeed, WinCE has it as well (I checked build 4677, which I think is the one on which I was having the issues).

I'll need to check the xml I actually used, though the vehicleprofiles should be standard, to find out where the fault lies.

On my Android phone I have verified that the parameters are correct and the last "good" bearing is maintained while standing still. It's only the WinCE device on which I was having issues.

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

well, this looks odd... the XML file I used on WinCE has the attributes set correctly. I'll test it again (as I've since updated my Navit version on that device); if the issue persists, there may be a bug in the WinCE vehicle code.

comment:7 Changed 11 years ago by mvglasow (2)

On a short field test with r4710, I was unable to reproduce it. I remember experiencing the issues in a mountain area, where reception tends to be weaker, hence the error may have been greater and the readings crossed the threshold.

However, I do notice that, while the map orientation is maintained while standing still, the compass moves randomly. Apparently the compass gets the unfiltered readings while the map uses the corrected ones.

This means that while standing still, north (as reported by the compass) no longer corresponds to north on the map, which may confuse users (especially when one is used to reading maps).


  • Modify compass code to change orientation with the map (using only "good" bearing reports)
  • Review static_speed and static_distance thresholds for suitability in low-reception areas (e.g. by taking GPX traces when navigating in such areas, identifying areas in which the initially mentioned behavior is observed and analyzing readings)

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

Now, having dome some more testing, I did experience a few cases in which the display would act up while standing still. I remember these cases being between buildings where reception is poor and reflection may introduce errors.

Another possible approach would be not to use static_speed and static_distance directly but in conjunction with the HDOP. The higher the HDOP, the higher the threshold above which updates will be considered. The XML file would specify the base value (for low HDOPs), the actual threshold used would be calculated based on that and the HDOP. Maybe we'd need another parameter to control the "aggressiveness" of that HDOP adjustment.

Note that this may still not work for all cases: if we are getting a bad signal despite a decent-looking HDOP, all of this won't help.

Last edited 11 years ago by mvglasow (2) (previous) (diff)

comment:9 Changed 10 years ago by usul

  • Keywords speed tracking added; bearing removed
  • Milestone set to version 0.5.1
  • Priority changed from major to minor

So can anybody say, if this bug can be considered as fixed?

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

As far as I'm concerned it isn't fixed yet.

  • Freezing the map view works mostly, but if the GPS signal is very bad, we may get speeds or distances between last and current position which exceed the thresholds.
  • Also, only the map is frozen while the compass will move on any bearing information that comes in, regardless of quality.

So I would suggest two things:

  • Instead of using the static_speed and static_distance values directly, multiply them with HDOP. (On Android, HDOP = accuracy / 5 m). That would increase the thresholds if the GPS signal is bad. If that results in too much valid information getting discarded, use something like HDOP * 0.5 instead.
  • Implement filtering not only for the map view, but also for the compass.

comment:11 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:12 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.