Reinvent the course tracking wheel

[1ec5]

This PR reimplements MGLMapView’s course tracking mode in MapboxNavigation. Various hacks that we previously employed to force-snap MGLMapView’s user puck have been removed. The puck continues to look like a puck during turn-by-turn navigation after panning away.

The developer can customize the user puck by setting the NavigationMapView.userCourseView property, which is easier to work with than a delegate method. The default user puck now looks more similar to what the Android navigation SDK displays: a larger disc that lies flatter against the map (with a halo instead of a shadow).

The developer can also customize the user puck’s location on screen by implementing the NavigationViewControllerDelegate.navigationViewController(_:mapViewUserAnchorPoint:) method.

More to come:

• Move off MGLUserTrackingModeFollowWithCourse (to fix Bespoke course tracking #352)
• Align the camera with the location view’s bottom-weighted position
• Make the user puck’s position customizable (to fix Allow updating location puck bottom offset #323)
• Implement a better-looking user puck (or port the relevant parts of MGLFaux3DUserLocationAnnotationView)
• Avoid automatically tracking the user location when in non-tracking mode
• Avoid bouncing back and forth between overview and front-facing views when in overview mode
• Override pinch and tap gesture recognizers to center on the user puck
• Disable animated camera transition while on battery power (to fix Throttle map rendering when device unplugged #370)
• Hide Recenter button while tracking user course
• Interpolate between location updates (not as much as 60fps, but more than 1fps)
• Disable implicit animations of the user course view when not tracking course
• Update example application to customize the new-style user course view

/cc @frederoni @bsudekum

[1ec5]

For #370, we need to turn animation off, at least when the device is on battery power. If we leave animation on, we’d also need to enable a linear timing curve and stretch out the animation for one second to eliminate the jumping that currently occurs.

[frederoni]

Note that this PR currently only builds with a custom build (mapbox/mapbox-gl-native#9651) of the iOS Maps SDK that exposes -[MGLMapView setCamera:withDuration:animationTimingFunction:edgePadding:completionHandler:]

[bsudekum]

Wow, this rebase is rough times.

[bsudekum]

The rebase was so rough I just started fresh. @frederoni @1ec5 let me know if you want me to force push this branch over this one: https://github.com/mapbox/mapbox-navigation-ios/compare/bs-bespoke-course-352.

Also, do we want to move some of this logic to core? I sort of remember this being part of the conversion around this PR but I'm seeing a lot import UIKit.

[1ec5]

That branch missed some changes and undid part of #408. The rebase doesn’t seem so daunting in any case, although I’m getting some compiler errors in unrelated code.

Also, do we want to move some of this logic to core? I sort of remember this being part of the conversion around this PR but I'm seeing a lot import UIKit.

No, we shouldn’t have Core Navigation depend on the map SDK nor on UIKit if we can help it.

[1ec5]

OK, I’ve rebased the PR. Currently there are two MGLMapView categories containing forward declarations, one in MapboxNavigation and the other in the Swift example application. Hopefully we can eliminate the former by taking advantage of mapbox/mapbox-gl-native#9651 and MGLMapViewDelegate.

[ericrwolfe]

@1ec5 what're the next steps to finishing this PR out?

[1ec5]

what're the next steps to finishing this PR out?

I’ve been keeping the original post updated with the remaining work. Currently we have the following to-do items:

• Avoid automatically tracking the user location when in non-tracking mode.
  • You can pan the map, but the viewport goes right back to the front-facing view on every location update. This should be pretty simple to fix.
• Avoid bouncing back and forth between overview and front-facing views when in overview mode.
  • When you tap Overview, the viewport switches back to the front-facing view on every location update, only to immediately zoom back out to the overall route.
• Override pinch and tap gesture recognizers to center on the user puck.
  • You don’t really notice this effect given the two issues above, but zoom and tap gestures are currently centered on the center of the map instead of the bottom-weighted puck. This may require exposing an additional MGLMapView internal method.
• Interpolate between location updates.
  • With a 1fps frame rate, it’s just barely possible to follow where the camera is going. But at turns, the camera’s rotation can change significantly, easily causing the user to get disoriented. We’ll need to use a timer in addition to whatever timer the location manager may be using.

[frederoni]

@1ec5 How do you feel about migrating the user puck to runtime styling? Porting the relevant parts from mapbox/mapbox-plugins-android#22?

It would solve the issue we are seeing when starting navigation and going from landscape to portrait where the user puck floats around because the camera and UIView animations are not in sync. I think it could also simplify course tracking. Though, styling it would be slightly more limited.

[1ec5]

It would solve the issue we are seeing when starting navigation and going from landscape to portrait where the user puck floats around because the camera and UIView animations are not in sync.

I don’t think this behavior is inherent to using a UIView. In fact, 049814b nearly eliminates the initial jump by making the various cameras more consistent with each other. The remaining minor jump seems to correspond to a view’s height – I wonder if we’re initially forgetting to account for a view in the edge padding.

I think it could also simplify course tracking. Though, styling it would be slightly more limited.

There are pros and cons to using runtime styling for the user puck:

• Con: In user tracking mode, the user dot or user puck must remain fixed on the screen while the camera moves. Mapbox GL has no concept of UI elements that behave completely independently of the map. If we implement the user puck as style layers, as the Android navigation SDK does, we’d have to work around this mismatch by manually updating the puck’s geometry on every frame. That isn’t unreasonably difficult, but it isn’t simpler than what we’re already doing.

  Part of the motivation behind this PR is to reduce battery usage by putting less work onto mbgl’s shoulders. But if you’ve ever played with the Add Animated Annotation demo in macosapp, you know how resource-intensive it can be to frequently change a single point feature’s coordinate in a shape source, and that’s without moving the camera.

• Weak pro: Once Update shaders: get 'icon-pitch-alignment' and fix for issue #9456 mapbox-gl-native#9479 makes it into a release, we’d get a realistic tilting effect using iconPitchAlignment, something I’ve struggled with for view-backed annotations ([WIP] Configurable degrees of freedom for annotation views mapbox-gl-native#5245). However, the difference would only be noticeable if we were using a rectangular user puck as opposed to the round one we’re using now.

• Con: Mapbox GL has no concept of 3D models (Add support for rendering 3d models  mapbox-gl-js#3996), whereas a SceneKit model can already be used as a user puck. (Think 3D car model.)

[bsudekum]

Per chat yesterday, @frederoni is going to see what can be done to modify the zoom level without leaving followWithCourse.

[bsudekum]

@frederoni would it be possible to disable animation so the puck is more stuck to the route to fix ^?

[frederoni]

Fixed user puck while swiping #402 (comment)

[1ec5]

The merge was redone without squashing as b141077.