Incorrect distance in track stats and graphs

[eliotb]

At least the last couple of tracks I recorded have incorrect distance information shown.

For example today I walked about 9km, OpenTracks reports

• Distance: 6.42km
• Moving time: 1:48
• Total time: 2:30
• Max speed: 5.9km/h
• Avg moving speed: 3.6km/h
• Avg speed 2.6km/h

The By time graph appears to be correct, but the By distance graph shows the wrong distance 6.42km. The profile of the distance graph looks right i.e. doesn't appear to be missing a big chunk.

When I export the GPX to other apps, it is correct, covering the entire route, with distance calculated correctly.
Apps were OsmAnd on mobile, and Viking on linux.

E.g viking

• Distance: 9.06km
• Moving time: 2:05
• Total time: 2:30
• Max speed: 5.9km/h
• Avg moving speed: 4.33km/h
• Avg speed 3.63km/h

To Reproduce

1. Record a track

• I'm happy to share the track privately

Technical information

• Device: Samsung s9+
• OS: //e// os 1.15 (Android 10)
• OpenTracks version: 4.11.1

[dennisguse]

Sounds like #1862.

V4.11.1 is broken.
Solution: either down or upgrade.
FDroid may take some more days.

[dennisguse]

I just checked an v4.11.2 is noe on FDroid.

[eliotb]

This does not seem to be the same as #1862? The recording is not stopping; the track is recorded correctly and the GPX export is correct, but the stats and graph horizontal scales appear incorrect. It seems more like some sort of scaling problem.

Are the stats and graphs cached? I.e. would I have to do something to clear the cache and have them recalculated by a new version of OpenTracks?

Sadly 4.11.2 hasn't fixed this problem

As always, thanks for your work on OpenTracks

[dennisguse]

Could be the same as #1870?

[eliotb]

I don't think there are gaps in the track. GPS settings are sample 10s, distance 10m, max distance 200m, accurac 50m, idle threshold 10s

Attached gpx of track described in first comment gpx1865.zip

[dennisguse]

GPX files contain less infos than KML (eg. gaps due to idle) will not be shown.
Can you check with OSMDashboard using the recorded track?

[Cubly]

I have a similar issue, did a 7.75km walk, reported as 5.47km in Stats, Graph and OSMDashboard. Exported GPX shows the correct distance.

[eliotb]

I have 4.11.2 installed now and recorded a new track, it has the same problem.
Viewing in OSM Dashboard, the track looks to be made of ? coffee cups ?
Going back over old tracks, last one without 'coffee' is recorded on 2023-09-16, then 2023-10-26 and subsequent are full of coffee.

[pstorch]

The coffe cup symbolizes the pauses which OpenTracks recognized. 😉

[dennisguse]

@eliotb How OpenTracks handles pauses was changed last year (may have been around September).
Before it was based upon the reported speed (threshold configurable) and now it is time-based (aka less than X meters moved in Y seconds).
Default is 10m for 10s => 3.6kmh, but GPS data maybe noisy...

If you are in areas with bad GPS reception (mountains, forest) or rather move slowly (e.g., walking upstairs) that leads to the false assumption of pauses (therefore coffee cups).
Adjust the configuration according to your needs ;)

PS/ OpenTracks does not count the distance when switching from pause to moving.
So, if pausing happens to often, you will see a significant reduction in overall distance.

[Cubly]

The total distance of the walk is still incorrect though, even if I stand still, the total distance walked is still the same, but OpenTracks is reporting a much shorter distance.

So the idle system is kind of flawed. Could you add an option to disable it completely? Perhaps with a quicker way to pause a track too, so I can manually tell OT when I am idle?

Knowing how far I have walked at a glance is pretty important to me and having the idle system interfere with that is less than ideal. For now I have cranked the idle timeout and will see how it works next time I get out.

Thanks for your continued development!

[dennisguse]

@Cubly yes, but no.

Please check my comments:

• Incorrect distance in track stats and graphs #1865 (comment)
• Incorrect distance in track stats and graphs #1865 (comment)

If you want to almost disable the idle detection, then just set the idle threshold to the maximum.

[Cubly]

Tested it out again with idle threshold on max, OpenTracks still displays a very incorrect distance of 2.65km in this case, where exported to OsmAnd or FitoTrack they show closer to the correct distance of 4.5km.

OpenTracks does give me least hassle for recording though and it shows correct elevation where other apps are like 20-30m too high from reality.

I'll probably still use OpenTracks to record, but just export to view tracks elsewhere. I'd still like to disable idle altogether, as I would rather clean the track up myself later if I actually stopped for a break. Maybe I still dont fully understand how it works though!

[dennisguse]

@Cubly can you open the track in OSMDashboard and check for pause markers (coffee signs) as well as gaps?
As I said: GPX does not contain all the infos.

[Cubly]

@dennisguse In OSMDashboard it shows 5 idle points and they are accurate to be fair (where I remember standing for a moment), but it still displaying 2km less than the actual distance on there.

[dennisguse]

@Cubly are there any gaps in the track?

[Cubly]

@dennisguse Sorry! No, not that I can see.

[dennisguse]

@eliotb do you have some more insights into this problem?
I might have some time to look into this in the next days, but I need some more information (e.g., a KML of an affected track).

[eliotb]

On 2/05/24 05:47, Dennis Guse wrote: @eliotb <https://github.com/eliotb> do you have some more insights into this problem? I might have some time to look into this in the next days, but I need some more information (e.g., a KML of an affected track).

Hi Dennis, I'm happy to share some tracks privately (I'll email the address given on your website). I increased my idle threshold to 30s, that makes the problem mostly go away. When I look at the problem tracks in OSM Dashboard, I see lots of pause markers, before each marker is a red segment, which I guess represents the "lost" distance.

…

-- Eliot