Total distance does not include segments with no GPS data

[MarkWieczorek]

Describe the bug In comparing the total distance of a track generated by OpenTracks and google maps, OpenTracks provided a number that was considerably lower. Looking at the track, it appears that the distance driving in tunnels was not counted. Many GPS tracking apps simply connect the points with a straight line when there are gaps in GPS data, but OpenTracks does not appear to do this: it instead produces a segmented track that is not continuous.

In my opinion, ignoring the segment with no GPS data is probably the worst option to use, but I understand why someone might want to do this. A solution would be to add a preference to the app that lets the user decide what to do in this circumstance.

To Reproduce Drive in a tunnel with no GPS, and then look at the track.

Technical information

• Device: /e/OS 1.10
• OS: Adnroid 10
• OpenTracks version: v4.3.4

[dennisguse]

Yes. Distance between segments is not counted. The threshold for automatic segment creation is configurable; default 200m.

Proposed solution:

https://github.com/OpenTracksApp/OpenTracks/issues/1454#issuecomment-1485769080

[dennisguse]

Actually none of the data between segments is counted. And that brings up some question:

1. For total time, we were wondering if these should be taken into consideration.
2. What do we do with the distance?
3. What do we do with moving time?

I am not sure what the right thing to do is here. Total time seems to be okay as the user didn't stop. Does the same apply for the others as well?

[nutpantz]

Actually none of the data between segments is counted. And that brings up some question:

1. For total time, we were wondering if these should be taken into consideration.

2. What do we do with the distance?

3. What do we do with moving time?

I am not sure what the right thing to do is here. Total time seems to be okay as the user didn't stop. Does the same apply for the others as well?

If a tree falls on the forest and no one is around to hear it does it make a sound?

In this case i feel even if you are not being tracked, you are in fact still moving.
If you want to get crazy technical the app could check if the average travel speed has drastically reduced or increased since loss of signal in the distance traveled. But that is wasted effort for an app that is used to track your total movement. (Movement being the key word, it's not about tracking your breaks) Pretty much every app i have used just assumed you were still moving during the lost signal and just fills in the lost places as straight lines. Total time is always total time. Total distance is the total from the start to the end. Moving time could go either way, but its safer to assume that people are moving more often while being tracked then taking a break under every tree and in every tunnel.

[dennisguse]

@MarkWieczorek @nutpantz If you want to test this: #1575 However, somebody needs to to all the still mentioned tasks ... and I have no time to spare.

[nutpantz]

Just point me to a apk

[dennisguse]

@nutpantz :point_right: https://github.com/OpenTracksApp/OpenTracks/actions/runs/5134738299/jobs/9239163784?pr=1575 As build by Github themself.

[nutpantz]

@nutpantz point_right https://github.com/OpenTracksApp/OpenTracks/actions/runs/5134738299/jobs/9239163784?pr=1575 As build by Github themself.

Maybe i am blind, but i don't see s downloadable apk there.

[nutpantz]

4.40 nightly showed up on fdroid, assuming it has the fix. The nightly recorded 9.13 km total distance vs older versions (3.74&3.15)recording 10.1km (roughly) and what i have been using as the benchmark had 10.1 km also. So the nightly newest is still 1 km behind. If you need the files i can upload them

And it still has the red gps disabled flashing

[dennisguse]

The nightly is build from the main branch (which does not yet contain this change).

Sadly, Github hides the file pretty well. Here is the guide to download it https://docs.github.com/en/actions/managing-workflow-runs/downloading-workflow-artifacts

[nutpantz]

8.54km GL- 8.30 km OT 3.7.4 - 8.28 OT km 3.15 vs the test build at 7.74km

[nutpantz]

trackd.zip

Recorded tracks

[dennisguse]

@nutpantz Thanks for testing. This would still solve the tunnel situation.

[nutpantz]

If it is inaccurate and losing distance under trees then i don't see how it will do better in tunnels. Maybe if there is only one tunnel.