Method for getting map camera settings from polyline, bearing, bounds and insets

[d-prukop]

This method should accept a polyline, a bearing, a bounding rectangle in pixels and an object defining padding in pixels on all sides. It should then return a center coordinate and a zoom level appropriate for showing the given polyline in the given bounds at the given bearing.

This is basically what's already happening in fitBounds. The only difference is that this returns the calculated values so that the developer can handle the fitting of the bounds using any transition they want.

getCamera(polyline: Array<LngLat>, bounds:Array<Point>, insets: Array<Float>, bearing: Float) {
  return {zoomLevel: Float, centerCoord: LngLat, bearing: Float}
}

cc @mapbox/gl @pveugen

[1ec5]

This sounds a lot like the existing -[MGLMapView cameraFittingCoordinateBounds:edgePadding:] method, except that it takes a polyline instead of a coordinate bounds and allows the rotation to be specified. There's an mbgl::Map::cameraForLatLngs() method that does something similar. It could be exposed as -cameraFittingShape:edgePadding: or -cameraForShowingAnnotation:, playing off existing method names.

Would it be desirable to automatically choose an optimal rotation (within some threshold, to avoid overrotation)? I recall that Bing's API even goes so far as to choose an optimal pitch when the map is tilted.

[d-prukop]

except that it takes a polyline instead of a coordinate bounds

This, I believe, is the tricky part. The viewport of the device in heading-up navigation is at an arbitrary bearing. You can't simply take the northeast and southwest coordinates and make a bounding box that will work. There needs to be some translation going on in order to calculate the proper zoom level.

[d-prukop]

Would it be desirable to automatically choose an optimal rotation (within some threshold, to avoid overrotation)? I recall that Bing's API even goes so far as to choose an optimal pitch when the map is tilted.

Could you explain the overrotation problem. As for the pitch, It would be really great to have that.

[1ec5]

The viewport of the device in heading-up navigation is at an arbitrary bearing. You can't simply take the northeast and southwest coordinates and make a bounding box that will work. There needs to be some translation going on in order to calculate the proper zoom level.

mbgl::Map::cameraForLatLngs() correctly fits the polygon given the map’s current camera heading.

[1ec5]

Could you explain the overrotation problem.

I just meant that we may want to avoid rotating nearly 180° from the current camera just for something slightly more optimal than the current camera.

[d-prukop]

mbgl::Map::cameraForLatLngs() correctly fits the polygon given the map’s current camera heading.

This is great news.

[zugaldia]

cc: @cammace @danesfeder for visibility on the Android side.