Various user tracking mode corrections

[1ec5]

This PR fixes a variety of minor issues around user tracking mode and camera animation that were discovered while attempting to make use of the user dot alignment option introduced in #3589.

I’ve also added a “targeted” user tracking mode: when following the user’s course, you can specify a targetCoordinate. As the user nears the target, the map continually recalculates the viewport to fit both the user and the target in a vertical orientation.

Fixes #1145.

/cc @friedbunny @bsudekum

[friedbunny]

Changing/enabling userTrackingMode with a non-center vertical alignment is still animating to the center position on the map, while keeping the dot at the expected screen location (bottom, in this case) but wrong geographic location... until the next location update(?).

[1ec5]

Changing/enabling userTrackingMode with a non-center vertical alignment is still animating to the center position on the map, while keeping the dot at the expected screen location (bottom, in this case) but wrong geographic location... until the next location update(?).

Fixed in 7b820ab. Indeed, the initial animation (which uses flyTo, unlike incremental updates) failed to account for the vertical alignment.

[mb12]

The dot seems to be lagging behind the map a lot upon panning.

[1ec5]

@mb12, does it appear to be worse than in 3.0.1? I don’t know of any changes in 3.1.0-pre.1 that would’ve exacerbated the issue being tracked in #1125.

3.1.0-pre.1 and this PR only affect the user dot in user tracking mode. In this mode, the dot isn’t even supposed to move relative to the screen anymore. #1582 would affect the user dot outside user tracking mode; the remaining work in that PR is to eliminate the lagging you’re experiencing.

[mb12]

I haven't tried the latest update yet. I will try and let you know.
The lag in the attached animation seemed a lot more than what I've noticed on the device(one from a really old repo). That's why I mentioned it.

[1ec5]

Let’s continue tracking the lag issue in #3683.

[friedbunny]

Rotating the device while in heading tracking mode, with bottom-alignment, causes the map to move incorrectly:

[1ec5]

That was fixed in fb8d336. I just forgot to push. 😉

[friedbunny]

That was fixed in fb8d336.

Yup!

Now I've got another one for ya': rotating the screen (portrait↔landscape) with non-center alignment causes the user dot location to shift incorrectly, then animate back to the correct location.

[1ec5]

Something similar also happens when the user puck is not shifted in course tracking mode. Probably a regression from the latest refactoring.

[friedbunny]

rotating the screen (portrait↔landscape) with non-center alignment causes the user dot location to shift incorrectly, then animate back to the correct location.

I'm still seeing this on the second rotation; i.e., portrait → landscape (👍) → portrait (👎, dot shifts geographically).

[1ec5]

portrait → landscape (👍) → portrait (👎, dot shifts geographically).

Fixed in b5f1b9e1cf93f6afc08d15721347746ff69e588e.

The Travis failure is unrelated to these changes, by the way.

[friedbunny]

I'm starting to get into edge cases, but animated setting of non-center alignment while also turning on heading tracking will result in some slightly geographically incorrect intermediate animations until heading mode completely engages.

diff --git a/ios/app/MBXViewController.mm b/ios/app/MBXViewController.mm
index fddab78..7f3e7c9 100644
--- a/ios/app/MBXViewController.mm
+++ b/ios/app/MBXViewController.mm
@@ -442,9 +446,11 @@ static const CLLocationCoordinate2D WorldTourDestinations[] = {
     switch (self.mapView.userTrackingMode) {
         case MGLUserTrackingModeNone:
             nextMode = MGLUserTrackingModeFollow;
+            [self.mapView setUserLocationVerticalAlignment:MGLAnnotationVerticalAlignmentCenter animated:YES];
             break;
         case MGLUserTrackingModeFollow:
             nextMode = MGLUserTrackingModeFollowWithHeading;
+            [self.mapView setUserLocationVerticalAlignment:MGLAnnotationVerticalAlignmentBottom animated:YES];
             break;
         case MGLUserTrackingModeFollowWithHeading:
             nextMode = MGLUserTrackingModeFollowWithCourse;

[friedbunny]

When initializing with some tracking mode enabled (but no explicit .showsUserlocation), the user dot won't be shown until the map is interacted with or the camera changes.

It's necessary to disable [self restoreState:nil] in iosapp for this to occur.

[1ec5]

animated setting of non-center alignment while also turning on heading tracking will result in some slightly geographically incorrect intermediate animations until heading mode completely engages.

Either I was unable to reproduce this, or the errors were very minor. I’m comfortable punting on this issue. If a developer needs both the user tracking mode and the alignment to be animated, the alignment can be set in -[MGLMapViewDelegate mapView:didChangeUserTrackingMode:animated:].

When initializing with some tracking mode enabled (but no explicit .showsUserlocation), the user dot won't be shown until the map is interacted with or the camera changes.

Fixed in fb7de377a280a68c0a3b29987d591b82fab62b48.

[friedbunny]

animated setting of non-center alignment while also turning on heading tracking will result in some slightly geographically incorrect intermediate animations until heading mode completely engages.

I'm not seeing this anymore — the dot moves to the correct position, then rotates to the correct heading. 🤷

[1ec5]

c087b485e2d38e6834e796fd55a8f7a4a97b5db7 fixes the tilt gesture to respect the content insets and a non-center-aligned user dot. The gesture feels a lot better now. However, if you tilt the map during targeted course tracking mode, the map iteratively zeros in on the correct bounds. It’s a pretty jarring experience, one that will only be addressed by fixing #2259.