One global threshold is how you delete valid data
GPS filters can misinterpret stationary phones as moving, adding fake miles to mileage logs. By applying context‑aware thresholds based on speed, time gaps, and recent movement history, developers can eliminate jitter without sacrificing accuracy. The solution is configurable, making tuning a simpl…
When a GPS‑enabled mileage app records a car that is actually parked, the device’s position can drift a few metres in every direction. If the app simply sums the gaps between readings, that drift turns into a quiet accumulation of kilometres. In a business context, where mileage logs translate directly into expense claims, the difference can be significant.
Why a Stationary Phone Feels Like a Moving Car
Modern smartphones use a combination of GPS, Wi‑Fi, and cell‑tower triangulation to determine location. Even when the phone is physically still, the sensor data can fluctuate due to signal multipath, atmospheric conditions, or software rounding. The result is a “phantom distance” that appears in the raw data stream. If an app naively adds every reported displacement, a parked vehicle can appear to have travelled several kilometres.
Context‑Aware Thresholds: The Core Fix
The simplest way to stop phantom miles is to ignore any step that falls below a minimum displacement. However, the minimum must adapt to how fast the user is moving. For example:
- Walking: ignore steps smaller than 2.0 m
- Cycling: ignore steps smaller than 3.0 m
- Driving: ignore steps smaller than 5.0 m
By tailoring the threshold to the expected speed, the filter can tolerate the larger jumps that come with faster travel while still rejecting the jitter that accompanies slow or stationary movement.
Time‑Gap Tiers: Speed Is Relative to Time
A displacement that seems impossible over a short interval may be perfectly reasonable if the phone was off‑screen for hours. The algorithm therefore checks the implied speed by dividing displacement by the time difference (dt) between readings:
- Displacement > 5 km or implied speed > 70 m/s (~252 km/h) is flagged if dt < 1 s
- Implied speed > 150 m/s if dt < 2 s
- Implied speed > 100 m/s if dt < 3 s
- Implied speed > 60 m/s if dt < 4 s
- Otherwise, only displacement > 10 km triggers a flag
This tiered approach distinguishes genuine jumps—such as a car passing through a tunnel or a phone being turned off—from normal movement. It also accounts for longer gaps caused by network outages or flight mode, which can produce large jumps that should not be treated as movement.
Recent Movement History: Differentiating Jitter from Real Motion
Even with time‑gap checks, a phone that has been idle for a while can still report small displacements. To avoid treating these as jitter, the algorithm looks at a rolling window of recent speed samples. If the average speed over the last five fixes is below 1.5 m/s, the device is considered stationary, and any small step is ignored. If the recent average indicates movement, the step is retained. This rolling window allows the filter to adapt to real‑world driving patterns without hard‑coding a single threshold.
Configurable, Serialisable Settings
All thresholds—walking, cycling, driving jitter limits, speed history size, and gap tiers—are stored in a single serialisable configuration object. This design makes tuning a matter of changing a config file rather than redeploying code. The default values match the original hard‑coded logic, so extracting them confirms that the new approach reproduces the old behaviour while adding flexibility.
Practical Impact and Next Steps
Implementing these context‑aware thresholds eliminates phantom distance from mileage logs, ensuring that expense claims reflect actual travel. The solution is lightweight, requires no additional hardware, and can be rolled out across existing apps with minimal effort. Future work could involve machine‑learning models to predict movement patterns, but the current rule‑based approach already provides a robust, explainable fix.
For developers, the key takeaway is that any constant threshold in a filter must be justified by context. If a threshold is applied universally, it may become a hidden bug that only surfaces under specific conditions—like a parked phone in Bangalore traffic. By making thresholds context‑dependent and configurable, you avoid delayed bugs and keep your app reliable.
Why it matters
Accurate mileage tracking prevents inflated expense claims and maintains trust between employees and employers. A small GPS glitch can translate into significant financial discrepancies over time.
Key points
- GPS drift can inflate mileage logs if not filtered.
- Thresholds must adapt to expected speed to avoid false positives.
- Time‑gap tiers help distinguish real jumps from glitches.
- Rolling history windows differentiate jitter from genuine motion.
- All thresholds are configurable, simplifying maintenance.
- The fix preserves accuracy while eliminating phantom miles.
Frequently asked questions
What causes phantom distance in GPS data?
GPS signals can reflect off buildings or atmospheric conditions, causing small positional errors that accumulate when summed.
Will this filter affect real driving data?
No. The thresholds are set to ignore only the small displacements typical of jitter, while real movement at normal speeds is preserved.
Can I adjust the thresholds for my app?
Yes. The configuration object is serialisable, so you can tweak the values without changing code.
