Some ideas to test if GPS speed filtering improves

[vlmendz]

Hello, here I suggest some experimental modifications to OpenTracks code related to GPS speed/locations filtering and statistics calculation (the goal is to improve location filtering and mainly get better values of current speed and maximum speed).

On TrackStatisticsUpdater:

1. Use a lower value for MAX_ACCELERATION (at least for positive acceleration). It could be around 1g by default and perhaps vary depending on the activity type.

2. Calculate the acceleration with respect to the previous received location (preferably to the last one with a valid acceleration) and not to the last one recorded.

3. Discard the use of speedBuffer_mps (with a working distance filter and a more effective acceleration filtering perhaps better speed values could be obtained).

4. Move the acceleration filter to TrackRecordingManager.onNewTrackPoint() so that all the locations filtering is done in one place and the statistics correspond to what is recorded.

P.s. The same ideas could be tested with altitude by calculating slope rather than acceleration?.

[dennisguse]

Nice digging!
Short answer: yes.

Long answer:

1. Yes, but making these activity type dependant is hard.
   We might get some profile support soon and then it is doable.

2. Yes; Requires moving it into onNewTrackPoint (aka 4.)

3. Yes, speed filtering (as we do it) is not cool.
   Time is not even taken into account.

4. Yes. As usual: I am not sure what side effects will occur (aka import from other applications) ;)
   I really like this idea as it makes the code easier.

Did not understand the PS part 🤷

[vlmendz]

Yes, I will find time to create the issue(s).

Regarding #527, I see that this problem was reported almost a year ago (I did not use OpenTracks yet) and the code related to this may have changed, however I think that this type of behavior should improve with the changes proposed here.

[vlmendz]

Quickly looking at #500 I think that to implement this, it might be useful (both for users and programmers) to create something like a "Static Mode" (mode without Tracks) of recording (could it also be a type of activity?).

In this mode/activity would not be available:

1. The options related to displaying the track on a map (there is no Track to display).

2. The export (import) of GPX and KML files (the purpose of these formats is to store/exchange geospatial data, not available in this case).

3. GPS-related options (additionally disable the use of GPS by the app and thus save energy).

For export/import in this Static/no Track mode, it would be better to use an appropriate file type to store the data on this type of devices for static training (I do not know if there is any standard file format for this)

[dennisguse]

I agree for 1. and 3., but not 2 - I want to be able to collect statistics (and export those) without any use of GPS (aka no locations at all).
This is possible with KML/KMZ as those allow points without coordinates (the standard allows this and we already do it; some applications were fixed), but GPX does not allow this.
For GPX, we can implement the track statistic extension and only export the aggregated statistics (#652).

Those tracks might be not be useful in a classic way (aka putting it on a map), but really useful for performance analytics (e.g., for sport).

[dennisguse]

#990 is also related.

[vlmendz]

Regarding export without coordinates, if it already works then forget what I said.