Skip to content
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

trip recording - the smart way (like Garmin does) #19718

Closed
nosorozec opened this issue Apr 30, 2024 · 7 comments
Closed

trip recording - the smart way (like Garmin does) #19718

nosorozec opened this issue Apr 30, 2024 · 7 comments
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning

Comments

@nosorozec
Copy link

Describe the idea (required)

Before OsmAnd I used Garmin devices to track my adventures. They use quite smart system for points recording - if you are moving the same direction (straight line) they record less information but when you start turning there is a lot more points in the log. See below image for visualisation:

Screenshot 2024-04-30 at 19 04 48

Can we have something like this in OsmAnd?

Tell us about the expected behaviour (required)

Recording plugin automatically saves the GPX track log based on type of movement. Going in a straight line - less information logged, start turning - more information.

Tell us about alternatives you've considered (required)

No clue, tried varied setting in the recording plugin - but cannot replicate the garmin behaviour.

Context (optional)

No response

@vshcherb vshcherb added this to the future-android milestone Apr 30, 2024
@vshcherb vshcherb added the Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning label Apr 30, 2024
@albansuser
Copy link

"if you are moving the same direction (straight line) they record less information but when you start turning there is a lot more points in the log."

Am curious as to the practical advantages of such a feature?

Thanks

@pebogufi
Copy link

pebogufi commented May 1, 2024

@sonora
Copy link
Member

sonora commented May 1, 2024

We must be aware that many such (often post-processing) algotithms are usually targeted at fitting the geometric shape of a track with fewer points than their raw data has as e.g. recorded at fixed time intervals.

But this also removes other information(!), which may not be desired, e.g. time, speed, altitude, cadence etc.data, which was contained in points the geo- simplification removes or manipulates.

So what kind of track sinplification makes sense for you depends on your actual purpose and use case.

@Sonwon1
Copy link

Sonwon1 commented May 1, 2024

We must be aware that many such (often post-processing) algotithms are usually targeted at fitting the geometric shape of a track with fewer points than their raw data has as e.g. recorded at a fixed tome interval.

But this also removes other information(!), which may not be desired, e.g. time, speed, altitude, cadence etc.data, which was contained in points the geo- simplification removes or manipulates.

So what kind of track sinplification makes sense for you depends on your actual purpose and use case.

It could be an option letting the user decide which is more useful for their usage.

@sonora
Copy link
Member

sonora commented May 1, 2024

Exacttly. Just saying that "the smart way" is not necessarily "smart" for all use cases.

And perhaps optimizations like this should even be a post-processing option you can apply to a track once it's been saved, there may be little benefit enforcing a decision before recording.

@albansuser
Copy link

albansuser commented May 1, 2024

Exacttly. Just saying that "the smart way" is not necessarily "smart" for all use cases.

And perhaps optimizations like this should even be a post-processing option you can apply to a track once it's been saved, there may be little benefit enforcing a decision before recording.

I agree. No sense in unnecessarily increasing the processor load while recording, especially if external sensors are being used. Then there's also data loss.

I can't think of any benefits of such real time "optimization".

@nosorozec
Copy link
Author

Thanks for all the comments.
I agree that this is best dona as post-process optimization.

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

6 participants