Respect heading while walking

[1ec5]

This PR contains these user-facing improvements to walking navigation:

• The user’s heading is used instead of the course when reorienting the camera while walking, since heading is more granular and more accurate at low speeds (i.e., walking speeds).
• When rerouting a pedestrian, avoid restricting the route’s initial heading. When driving or cycling, it makes sense to restrict the initial heading, to avoid routes that confusingly begin with a U-turn. However, a pedestrian can turn on a dime, and the direction in an initial “Head [direction] on [street]” instruction is more meaningful to a pedestrian than to a motorist or cyclist.

and these developer-facing improvements:

• Added RouteControllerNotificationUserInfoKey.headingKey to the user info dictionary of Notification.Name.routeControllerWillReroute, Notification.Name.routeControllerDidReroute, and Notification.Name.routeControllerProgressDidChange notifications. Core Location treats heading as first-class state instead of subordinating it under location, because heading updates from the magnetometer come in at a different rate than location updates from the GPS receiver.
• Both RouteController and LegacyRouteController can store a heading, so now the Router protocol requires it publicly. (Also fixed a latent issue where RouteController ignored heading updates. This issue didn’t matter previously because nothing was using RouteController.heading.)
• Deprecated the public but undocumented NavigationMapView.updateCourseTracking(location:camera:animated:) method in favor of a publicly documented NavigationMapView.updateCourseTracking(location:heading:camera:animated:) argument to the method for transitioning the map camera. (The existing method signature without the extra argument was undocumented but used in examples, so it has been retained in deprecated form.)

The user’s mode of transportation is determined by the current step’s transportMode, which is generally based on the routing profile but can be something else like train or ferry for walking and cycling routes. The improvements above affect only the walking transport mode.

To recap and to do:

• Loosen rerouting heading while walking
• Make heading a first-class piece of context alongside location
• Rotate the map by heading instead of course while walking
• Initially rotate the map by heading instead of course when enabling course tracking mode while walking
• Update heading orientation: Rotate map based on heading while walking #1942 (comment)
• Test loosened rerouting – may be challenging given the lack of heading simulation

Fixes #1942.

/cc @mapbox/navigation-ios @d-prukop

[pintonos]

Is there currently a workaround like rotating the arrow dependent of the user location heading? Or is it not possible to change the arrow orientation from outside the box?

[bsudekum]

Do you think this should also be applied to bikes?

[1ec5]

Is there currently a workaround like rotating the arrow dependent of the user location heading? Or is it not possible to change the arrow orientation from outside the box?

There isn’t currently a workaround, but this PR implements this behavior out of the box. Feel free to check out this branch and try it out – let us know what you think.

Do you think this should also be applied to bikes?

Not really, because I think it’s a bit of a sledgehammer specific to walking. A pedestrian on foot has a turning radius of 0 and can turn on a dime, whereas a cyclist may need to find a good place to turn around. Also, I’d be annoyed if I saw the map wiggle around to match my handlebar as I struggle to get going. 😅

I think there will be some opportunities for rerouting heuristics that benefit cyclists as well as pedestrians, but it probably will be orthogonal to using the magnetometer.

[JThramer]

Looks great! one comment.

[JThramer]

YAGNI?

[1ec5]

We could get rid of rawHeadingKey, but that could be problematic if we ever do need to implement heading snapping for some reason. We’d want the non-raw values to be snapped when a raw value is available. That said, the comment refers to the prospect that heading snapping may not be especially useful.

[JThramer]

Blocked by #2319

[MaximAlien]

Closing this PR in favor of #3620.