Prevent panning to NaN territory

[kkaefer]

Rapid panning and rotation sometimes lets the map view end up in a state where both x and y coordinates are NaN. Typically, the only thing rendering will be the background color. Once you're in this state, you can set a breakpoint at Painter::render() and inspect state's x and y variables.

[kkaefer]

[mb12]

This should be consistently reproducible using the steps described in issue #1294. (Panning with animation and zoom).

#1294

[1ec5]

Once centerCoordinate becomes (NaN, NaN), even Map::resetPosition() (Reset Position in the gear menu) fails to bring the user back to a valid location.

[kkaefer]

Looks like UIPinchGestureRecognizer sometimes returns NaN for velocity:

[1ec5]

Maybe if the pinch starts out and winds up in the same place? In any case, this looks like a pretty good fix to put in. Want to do the honors and convert this screenshot into a PR, @kkaefer?

[jfirebaugh]

Any idea where the NaNs come from (other than UIPinchGestureRecognizer)? I'm happy taking the Transform guard clauses for b1 but finding and eliminating the upstream causes would be better long term.

[mb12]

@jfirebaugh isnan check also needs to be done in to be done handlePanGesture: selector as well.

[kkaefer]

I believe they're only coming from the gesture recognizer. I have never observed NaN issues in anything but the iOS app.

[mb12]

handlePanGesture also calls [UIPanGestureRecognize velocity].

I see this consistently with the following steps on iOS:

1. Trigger pan animation using fast flick.
2. Zoom in using a stepper control.

[1ec5]

@mb12, are you seeing -[UIPanGestureRecognizer velocity] itself return NaN for a standard flick? #1294 could’ve been caused by the lower-level transform issues that @kkaefer fixed in this PR.

[mb12]

Sorry for the confusion. Everything looks good.