How apps smooth recorded GPS tracks

What the app receives

The position stream is already an estimate.

A recorded track begins as a sequence of location updates with coordinates, timestamps and, where available, uncertainty, speed, course and altitude. Those updates are not necessarily raw satellite calculations. Android can supply a fused provider that combines several location providers. The W3C Geolocation API is deliberately agnostic about whether its position came from GNSS, Wi-Fi, mobile networks or another source.

The operating system may therefore have filtered or fused sensor evidence before the route app sees it. The app then decides which updates to accept and how to connect them. Drawing straight segments between every accepted point is itself a representation choice.

“Raw GPS track” is often casual shorthand. A genuinely raw GNSS measurement contains satellite-level timing and signal data, not merely an unsmoothed list of phone coordinates.

During the activity

A live filter trades noise for delay and assumptions.

Possible filter designs include rejecting an old fix, giving less weight to a broad accuracy estimate or comparing a new point with recent speed and direction. A design may require several observations before accepting a sudden move, or estimate a smoother current position from a run of recent fixes.

These decisions reduce visible jitter when a person is stationary and can suppress an isolated jump. The price is responsiveness. A filter that waits for supporting evidence may lag after a sharp turn. A model tuned for steady road travel may handle a tight walking switchback badly.

There is no universal smoothing algorithm for outdoor apps. Thresholds, activity assumptions and operating-system inputs vary. Without product documentation or source code, a neat moving dot does not reveal which method produced it.

After the stop button

The saved line can be cleaned again.

Post-processing can remove isolated points, trim stationary clusters, resample the line, fill short gaps or reduce the number of vertices. Pause handling may exclude parts of the elapsed stream. Elevation can be filtered separately from horizontal geometry.

These operations should not be collapsed into one word. Simplification removes selected vertices while approximating a line. Map matching chooses likely positions on a mapped network. Interpolation invents positions between observations according to a rule. Smoothing usually reduces short-range variation without necessarily constraining the line to a map.

An export may contain the processed result rather than the original accepted fixes. Moving the file to another service cannot recover observations that the first service discarded.

Useful distortion

Every correction encodes a judgement about plausible movement.

• Too little filteringStationary noise, reflected signals and isolated jumps add false distance and visual clutter.
• Too much filteringTight bends, switchbacks, brief detours and stop-start movement can be rounded or removed.
• Wrong activity modelA speed or turn that is implausible for walking may be ordinary on a bicycle.
• Strong map matchingA clean line can be confidently attached to the wrong parallel path.

The cleanest-looking track is not automatically the closest to the journey. The suitable balance depends on whether the line supports memory, statistics, navigation, analysis or public presentation.

Inspect before editing

Keep the earliest available record and compare at full scale.

1. Preserve

   Keep the original export.

   Make corrections in a copy so timing and point evidence remain available.

2. Zoom

   Inspect corners, pauses and poor-sky sections.

   A whole-route thumbnail hides the places where filtering costs most.

3. Compare

   Check time, point count and summary changes.

   A similar shape can still have different duration, distance and elevation.

4. Describe

   Name the operation honestly.

   A cleaned recording is not the untouched receiver output, and a matched line is not direct evidence of the travelled path.