[AlainKnaff]

📝 Only log point if new point is further away from previous than its accuracy

🛠️ Issue

• No issue closed

🛠️ Related issues (if applicable)

📖 Description

This adds a new settings option "Log only points where distance > accuracy".
If enabled, points are only logged if their distance from the previous point is greater than its accuracy. The intent is to avoid "balls of wool" effect when pausing for picnic and forgetting to stop the track.

Example: if a GPS receiver signals new point B, only 10 meters away from previous point A, then B is only logged if its accuracy is less than 10 meters.

N.B. Changing the setting only works if briefly stopping and restarting recording. But that's basically the same as for existing "GPS loggin interval" and "GPS logging distance" settings

🖼️ Screenshots (if applicable)

• Include any relevant screenshots or examples of the changes made. This helps reviewers visualize the updates

not applicable

✅ Pull Request Checklist

• The PR is proposed to the DEVELOP branch.
• The changes have been tested on the target Android API and minimum Android API.
• Automated tests have been added (if applicable).
• The feature is well documented.
• There is a reference to the original ISSUE and related work.

📝 Additional Notes

• Any additional context, questions, or considerations for the reviewers:
  Please add a small comment when you've seen this PR. Thanks.
• Take a look at our Contributing Guide before submitting your PR:
  this guides mentions feature/* branches, but there are none so far, so I'm submitting this against develop instead.

[jamescr]

Thanks for taking the time to work on this and for opening the PR. Avoiding the "balls of wool" effect is a worthwhile goal for improving track quality.

Before we can consider this PR for merge, please note that the current implementation passes gps.logging.interval as minTimeMs and gps.logging.min_distance as minDistanceM to LocationManager.requestLocationUpdates, already filtering updates by both time and distance before onLocationChanged is called. The accuracy-based check proposed here would be an additional filter applied after that, and it's not obvious from the implementation how the three settings compose; in particular, whether a separate option is needed at all or whether raising the minimum logging distance already reduces the effect. Unit tests around this logic would help us validate the behavior and make future changes safer.

To keep the discussion organized, could you open an issue describing the problem and the proposed approach first? There's an existing conversation about GPS accuracy in #444, though it focuses on accuracy at the start of recording rather than during it. That gives us room to discuss the design and the expected behavior before we land the implementation. Thanks again for your contribution, we appreciate you helping improve the tool.

[AlainKnaff]

Done: issue #718