8000 Trip Recording: Do Not Discard Filtered Points · Issue #22567 · osmandapp/OsmAnd · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Trip Recording: Do Not Discard Filtered Points #22567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sonora opened this issue May 13, 2025 · 10 comments
Open

Trip Recording: Do Not Discard Filtered Points #22567

sonora opened this issue May 13, 2025 · 10 comments
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning

Comments

@sonora
Copy link
Member
sonora commented May 13, 2025

I had first posted here: #22370

Suggestion: With an increasing number of inexperienced users, would we not do everybody a favor by implementing that points affected by filtering are nevertheless included in the gpx files and simply commented out.

In this fashion

  • they would be 'emergency-recoverable' and nobody loses 'important recordings' for good
  • We could much more easily detect if a particular recording issue is due to filtering or other effects like power saving issues.

(Perhaps with the exception of the displacement filter, which may be used to keep the gpx file size small, and there you do not lose essential topology of your recording.)

@yuriiurshuliak
Copy link

Your suggestion to include filtered points as comments in GPX files is interesting.

It's true that being able to see which points were filtered out could be very helpful for users trying to recover potentially important data, and for us when diagnosing whether recording gaps are due to filtering or other issues. It would offer more transparency into the recording process.

@yuriiurshuliak yuriiurshuliak added the Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning label May 14, 2025
@vshcherb
8000 Copy link
Member

Good suggestion, but we can't process it later as comments won't be read and displayed - they will be only stored

@sonora
Copy link
Member Author
sonora commented May 14, 2025

Yes, that's why I call it an 'emergency recovery'. Users would have to process the file in Notepad++ or similar, but in theory could recover their complete recording.

@vshcherb
Copy link
Member

I don't really like implementation idea as it's too complicated and could be easily lost on resave of the track. However we can definitely save filtered points with flag.

Probably we can save them into special table and implement special export in Development for example. We can also keep all points for example for 1-4 weeks and then delete them.

@vshcherb
Copy link
Member

For example 1 button that will export all complete tracks into for last 30 days rec/bak-rec/

@ezemskov
Copy link

Hi,
Keen to try adding the unfiltered gpx recording feature, but not sure what is the consensus/decision :

  • add filtered points as commented-out xml, that is <!--trkpt> ....</trkpt-->
  • export filtered track.gpx as before, but add an extra "export/write full/unfiltered gpx" feature and UI for it

Pls correct is I've misunderstood anything above

@ezemskov
Copy link

Note inspired by the discussion in
#22654 :
If we want a feature hard-to-disable, then it looks reasonabe to add some screen of hidden settings (easter-egg control like Android developer options, or smth a bit more obvious).

For desktop/PC applications, I normally put such sparsely-used settings in a config file/whatever settings contaoner used (not adding them into GUI).
Not sure if it's appicable for Android

@sonora
Copy link
Member Author
sonora commented May 27, 2025

It's valid idea. But, IMHO, less intrusive and complex is to simply include all points in the gpx file, but simply place the 'filtered' ones in <!-- ... --> comment.

With the exception of the 'minimum displacement' filter: That one is often used to keep redundant data out of the gpx to keep file size small, and these points with small displacement can always be discarded, this will not result in loosing essential data.

@ezemskov
Copy link

One last note : if filtering the small displacements separately from time/speed/accuacy - make it configurable, and-or use the accuracy.
That is - filter as an outlier if displacement is >> accuracy, or filter as stationary if displacement < threshold

@sonora
Copy link
Member Author
sonora commented May 28, 2025

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning
Projects
None yet
Development

No branches or pull requests

4 participants
0