Look at points behind user for snapping

[bsudekum]

While investigating using the instantaneous calculated user course for determining off routing, I discovered that our calculated user course at a given point can be improved. Prior to this, we were looking ahead at two points on a line. Instead of looking at two points at a given distance ahead of the user, we should look at the angles at points ahead and behind the user. This will give a smoother and more accurate representation of the route snapped course.

/cc @1ec5 @ericrwolfe @frederoni

[frederoni]

This will give a smoother and more accurate representation of the route snapped course.

To me, this sounds like something we want to achieve with the camera, not the user puck.
Smoothing out the camera position based the average course of upcoming steps.

The user puck should always (when snapped) be aligned with the route line since it's hard to drive sideways along a route.

Also, I think we should remove the guard location.speed >= 0 to avoid floating around on the route line at a stop sign.

[bsudekum]

To me, this sounds like something we want to achieve with the camera, not the user puck.
Smoothing out the camera position based the average course of upcoming steps.

I think there is merit to this, but until #402 is merged, I think we need to stick with this.

The user puck should always (when snapped) be aligned with the route line since it's hard to drive sideways along a route.

The problem with this approach is that there is no in between/grace period between being snapped and not being snapped. The truth is that between the location snapping Apple does internally, GPS noise and the difference between OSM data and real world roads, we need some breathing room. At one point we did have either the user was snapped or they were rerouted and it caused tons of rerouting that became annoying to users.

Also, I think we should remove the guard location.speed >= 0 to avoid floating around on the route line at a stop sign.

I believe @ericrwolfe wanted this in there to prevent inaccurate course values from slipping through. Perhaps it would help though if we still mutated the user course if it looks good at low speeds.

[ericrwolfe]

Also, I think we should remove the guard location.speed >= 0 to avoid floating around on the route line at a stop sign.

I believe @ericrwolfe wanted this in there to prevent inaccurate course values from slipping through. Perhaps it would help though if we still mutated the user course if it looks good at low speeds.

I agree with @frederoni's point. See my comment in #381 (comment).

[bsudekum]

Let's pull that out into a separate PR.