Currently, trip paths are drawn as straight lines between the raw (accuracy-filtered) GPS points - there's no map-matching/fitting against the actual road/path network. Path simplification (pathSimplificationEnabled/pathSimplificationTolerance) only removes redundant points for rendering (Douglas-Peucker); it doesn't reposition anything.
This is related to #546 - that issue turned out to be a filtering-consistency bug between the route line and point clusters, not a map-matching gap. The underlying "straight lines between raw points, even where GPS drifts off the real path" behaviour is unchanged and, I think, worth addressing directly.
GPS accuracy naturally degrades under tree cover, in urban areas, tunnels, and multi-storey car parks, or even just logging interval. Since paths are drawn straight through the raw points, this drift shows up literally in the trip line - cutting across buildings, blocks, or rivers rather than following the road/path the user actually travelled.
Proposal
Optionally map-match a trip's path against the road/path network before storing/rendering it, using an existing open-source engine rather than a custom implementation. Some examples:
- OSRM's match service
- Valhalla's Meili map-matching / trace_route
- GraphHopper's map-matching module
All three are self-hostable and have mature GPS-trace-to-road matching support.
- A new, opt-in Timeline Preference (e.g.
mapMatchingEnabled) - off by default, since it adds an external dependency/service most self-hosters won't want to run unless they choose to.
- Matching applied only to the stored path geometry for display/export - doesn't need to affect stay/trip detection or movement classification, but could definitely improve both.
- Could run as a post-processing step during timeline generation, guarded by the new preference, so it's skipped entirely for instances that don't enable it.
Happy to test against real trip data if useful.
Currently, trip paths are drawn as straight lines between the raw (accuracy-filtered) GPS points - there's no map-matching/fitting against the actual road/path network. Path simplification (
pathSimplificationEnabled/pathSimplificationTolerance) only removes redundant points for rendering (Douglas-Peucker); it doesn't reposition anything.This is related to #546 - that issue turned out to be a filtering-consistency bug between the route line and point clusters, not a map-matching gap. The underlying "straight lines between raw points, even where GPS drifts off the real path" behaviour is unchanged and, I think, worth addressing directly.
GPS accuracy naturally degrades under tree cover, in urban areas, tunnels, and multi-storey car parks, or even just logging interval. Since paths are drawn straight through the raw points, this drift shows up literally in the trip line - cutting across buildings, blocks, or rivers rather than following the road/path the user actually travelled.
Proposal
Optionally map-match a trip's path against the road/path network before storing/rendering it, using an existing open-source engine rather than a custom implementation. Some examples:
All three are self-hostable and have mature GPS-trace-to-road matching support.
mapMatchingEnabled) - off by default, since it adds an external dependency/service most self-hosters won't want to run unless they choose to.Happy to test against real trip data if useful.