Trip Recording: Do Not Discard Filtered Points

[ezemskov]

Optionally save all trackpoints (including ones filtered according to the recoding plugin settings) in a separate .gpx file.
Full tracklog is saved in /rec/unfiltered/<track_filename>_unfiltered.gpx
Saving of full tracklogs is default disabled with a new boolean flag added into the plugin settings.

Note :
Automatic purge of full tracklogs after some time interval (as suggested in #22567) is not implemented.
Size of full tracklogs shouldn't be an issue with modern amount of storage (single point is ~250 bytes, 24hrs of unfiltered tracklog recorded at 1Hz is ~21Mb), even if it's explicitly enabled by the user.

[sonora]

The intent of my original suggestion was to mitigate the cases where users played with filters not knowing what they do, and then later lose valuable data.

If we introduce one more setting to "optionally save all trackpoints", it only complicates the situation further, and this defies the purpose.

[ezemskov]

The intent of my original suggestion was to mitigate the cases where users played with filters not knowing what they do, and then later lose valuable data.

If we introduce one more setting to "optionally save all trackpoints", it only complicates the situation further, and this defies the purpose.

Ok, I 've understood the intent as "give user an option to troubleshoot the track filtering, analyzing/comparing the full tracklog".

That is - the idea is to save full tracklogs unconditionally, and then erase/purge them after some time period ?
This would require some configuration of full tracklog storage duration, anyway.
From all my experience, setting some hardcoded period (that would look extremely reasonable at the moment, like a month of tracklogs on a device with 64Gb of available storage) would eventually become a rake to step on.
Think of some industrial IMU, reporting position at 100Hz on a device with 4Gb of storage.

Can replace the "enable full tracklog saving" toggle switch with a "full tracklog storage duration" control (with an option to disable it).

[DmitryAlexei]

Some users asks for some kind of Google timeline

• i want a replacement for Google Maps Timeline, but cannot understand it #22209
• Migration from Google Maps: All-time tracking (Google Timeline) #21754

[sonora]

Yes, thanks for the PR, anyway, @ezemskov !!

Product Management decision needed how exactly it should be implemented, @vshcherb, I guess.

I vote for a solution which is active by default and cannot easily be disabled by settings etc., because this is to primarily exactly mitigate setup mistakes users make in the (recording filter) settings.

[ezemskov]

No worries
Happy to amend yhe PR if/whenever you guys decide how to implement it.
For the future - would be good to mark (at least in the issues marked as 'nice to have') wherher the scope/desired behaviour is agreed/approved, or it'a a discussion in progress.

I have some of following in mind to fix eventually - not sure of their status
#22595
#22555
#22079
#22062
#21695

[sonora]

Yes, I have the same question sometimes: Is our 'Nice to have' tag to be taken in the literal sense ("would be a nice enhancement"), or is the stress rather with "not a must-have, so let's rather not have this complication"

Probably we have examples of both...

[sonora]

How about we simply put all filtered-out points in the file as commented out <!-- FILTERED: ... -->.

• This is a rather non-intrusive code change,
• in this fashion they are out of the way automatically for all app functionality and if the file is shared,
• but are in the file visible in support cases,
• and could even be recovered in an emergency?