Fix fit to bounds

[1ec5]

This PR reimplements “fit to bounds” functionality to take advantage of MGLCoordinateBounds and additionally exposes the method publicly. I started by re-porting Camera.prototype.fitBounds() in mapbox/mapbox-gl-js to ensure correct baseline behavior. Then I wrote some logic for edge insets and rotation. Along for the ride, I added a bunch of public utility functions related to MGLCoordinateBounds.

• Refactor the method to use MGLCoordinateBounds
• Derive center and zoom level from projected pixels (to fix [MGLMapView zoomToSouthWestCoordinate:northEastCoordinate:] not coordinates deterministic #1433)
• Expose the method publicly (to fix allow region-based viewport setting #1092)
• Push the logic down into mbgl
• Stop resetting the user tracking mode (to fix iOS: Zooming out beyond ~z10 with tracking mode enabled will force zoom in, reset tracking #1256)
• Account for rotation (ref Allow custom bearing/rotation while using fitBounds() mapbox-gl-js#1338)
• Adjust the viewport to account for top and bottom layout guides
• Take an edgePadding parameter for parity with MapKit and mapbox-gl-js (to fix Expose MGLMapView's zoomToSouthWestCoordinate:northEastCoordinate:animated: method in public header #1775)
• Test “round-tripping” the visible bounds

@friedbunny @incanus, can you try out this implementation and see if there are any other edge cases that MapKit and Google Maps handle differently?

[1ec5]

Adjust the viewport to account for top and bottom layout guides

In light of #1781, maybe it doesn’t make sense for MGLMapView to handle this itself. What does MKMapView do with top and bottom bars?

[jfirebaugh]

I'd like to move the core native API towards gl-js's Camera. How hard would it be to push the calculations down into GL core via Map::fitBounds()?

[1ec5]

How hard would it be to push the calculations down into GL core via Map::fitBounds()?

Done in ed99904. That was pretty easy, actually, because I was relying on mbgl::Map instead of the view for all the calculations. That change also neatly avoids an erroneous call to -setCenterCoordinate:animated: instead of -setCenterCoordinate:animated:preservingTracking:, so that fixes #1256 (and obviates part of #1257).

[friedbunny]

This works well so far. I'll test again once the layout guides adjustments are in, that's the biggest difference between MapKit/Google and us right now.

[1ec5]

Note that fitting to bounds forcefully resets the direction back to north, without animation.

Also, in 31d2918, I adapted the fit to bounds method to account for top and bottom bars, but it appears that MapKit does not. So I’m probably going to roll back that change. It’s easy enough to handle manually in client code.

[1ec5]

If you try to fit an MKMapView to any empty rect, MKMapView zooms way into the top-left corner of the map (in the Arctic Sea, above the Bering Strait). With this PR, however, MGLMapView centers on the empty coordinate bounds (which may originate anywhere) – I think that’s better behavior.

[1ec5]

The fit to bounds method now respects the current rotation. That turned out to require a lot less trig than I feared. 😃

[friedbunny]