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

Feature request - Accuracy filter options #591

Closed
aaaaaa111111 opened this issue Oct 12, 2017 · 5 comments
Closed

Feature request - Accuracy filter options #591

aaaaaa111111 opened this issue Oct 12, 2017 · 5 comments
Milestone

Comments

@aaaaaa111111
Copy link

Hi,

First I want to thank you for this very good gps logging app.

The feature I request here is (I hope) quite simple to implement. It is about accuracy filter:

It would be usefull to have option to not discard any point if it had at least some coordinates informations, even if it does not match the accurarcy limit fixed by user. So the ap will still wait for the time fixed by user (Duration to match accuracy) to reach the accuracy threshold, if it goes under it saves the point as usual, but if not it still keeps the best accuracy found within this duration, whatever the level and the source (gps or network). And of course it also save the accuracy value like for any point. Then later it is easy to filter out all the saved points by accuracy levels and use the levels we need.
So in this case the accuracy filter would be here to incite to find some level of accuracy winthin fixed duration, but without discarding less precise levels if there is no other choice.
The old Backitude app permits this behavior I think. Maybe there is a way to do that already in GPSLogger, if it is the case sorry but I didn't find it.

Regards

@aaaaaa111111 aaaaaa111111 changed the title Requested feature - Accuracy filter options Feature request - Accuracy filter options Oct 28, 2017
@thinrope
Copy link

I am still trying to figure out how using many filters work in combination (and poking the code). If I am right in my understanding a simple one-line change of this code near GpsLoggingService.java#L817 can make it happen:

                if (currentTimeStamp - session.getFirstRetryTimeStamp() > preferenceHelper.getLoggingRetryPeriod() * 1000) {
                    LOG.warn("Only accuracy of " + String.valueOf(loc.getAccuracy()) + " m and timeout reached." + getString(R.string.inaccurate_point_discarded));
                    //Give up for now
                    stopManagerAndResetAlarm();

Instead of giving up, record that at the and of the interval.
Now that will change the logic, so other users may be affected and thus documentation and UI needs to be changed.

This seems like a more reasonable behavior (i.e. do not loose data, even if inaccurate) than the current, @mendhak what do you think?

@mherrmann3
Copy link

This would be a very useful feature, as GPS accuracy can often vary greatly (e.g., when being in a city with large houses). Until now, I have profiles for different environments, which would not be necessary anymore with such a feature. BIG VOTE! 👍 👍 👍

@mherrmann3
Copy link

FYI: similar (if not duplicate) to #453

@mendhak
Copy link
Owner

mendhak commented Mar 1, 2024

I've been working on an accuracy option, description and test APK here: #654 (comment)

@mendhak
Copy link
Owner

mendhak commented Apr 1, 2024

v130 is now on FDroid and the releases.

The new option uses the time period to pick the best location it can find. I didn't want to make it complicated by having a range, as there is already a lot going on in there. This should help with jumpy lines and make things smoother at the expense of time. So you'll probably want to experiment here, eg, don't make the duration too long, maybe 5-10s will give it a better chance of getting a good point.

image

@mendhak mendhak closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants