Snapping/step advance bugs

[Archdoog]

Location snapping currently has issues when a route overlaps itself (e.g an offramp cloverleaf or out and back route). When this occurs, the snapped location can jump forward. Not sure if it causes an issue with the actual route progress, but since location pushes progress events, seems likely.

Ideas

• Trim the snap location candidates to the next n coordinates. This would long allow us to snap to coordinates that are just ahead of the last location.
• Use map matching. This seems like a long term enhancement that could be done in the future.
• Other ideas?

[ianthetechie]

Thanks for capturing this!

Trimming the search

Trim the snap location candidates to the next n coordinates

I initially thought in should be ±n, but on second thought, I think you're right (or we should limit the backward search to a smaller number). I guess the use case for snapping is primarily with cars, which can't easily reverse like a pedestrian, cyclist, etc., so this is probably a reasonable way to approach it.

After a second coffee, I think we need to consider the edge cases around a significant delay in GPS updates. The easiest example is a tunnel, where you may be skipping dozens or even a hundred points at a time (without forward progress simulation; separate topic :D). So there needs to be either selective activation or some fallback behavior.

Two ideas:

1. Check if the current step geometry self-intersects. There is probably something in the geometry library for this? If so, limit forward search so that it excludes the re-intersection and some number n coordinates leading up to it.
2. Use some static n, but extend to the entire step geometry if the snapped geometry is further than some acceptable distance from the raw user location. If the second snap is closer to the user's raw location, use that.

Map matching

I think this is what everyone ends up with long-term 😅 We have a path to doing this with valhalla-mobile, and users my of course bring their own solution. I think the thing to figure out in Ferrostar (eventually) is what a trait would look like for that, and integrating it into the core. Just riffing for a moment, it might be something like LocationSnapper (cue angry turtles :D), and we include an implementation that does what we do today + improvements we decide on. But it also offers a convenient hook point for map matching instead based on some window of previously seen locations.

[Archdoog]

#387 solves a good bit of this for the current ferrostar implementation (not the the fancy map matching). Expectation is we'll still need some out and back optimization and a final dynamic step advance system that blends them all together.