Method to convert arbitrary CameraOptions to LatLngBounds

[1ec5]

mbgl::Map should expose a latLngBoundsForCamera() method that takes an mbgl::CameraOptions and returns the mbgl::LatLngBounds that would be visible if the camera options were applied to the map. This method wouldn’t jump to a new location; it would only calculate what the extents would be.

The iOS and macOS SDKs have an -[MGLMapViewDelegate mapView:shouldChangeFromCamera:toCamera:] method that makes it easy to constrain the map’s center to a particular area, but it isn’t easy to constrain the map so that no disallowed area is ever visible. mapbox/ios-sdk-examples#65 illustrates the problem: we’d have to perform a set-and-revert dance just to determine whether the viewable area lies beyond the designated area. With latLngBoundsForCamera() and the corresponding SDK method, the delegate would be able to essentially do a “dry run” of the camera change associated with each gesture and use the resulting bounds to make this determination.

latLngBoundsForCamera() would essentially be the reverse operation of cameraForLatLngBounds(), so it may be desirable to ensure round-trippability. On the other hand, given #2259, I’m not sure we can ensure that at the moment.

/cc @jfirebaugh @brunoabinader @fabian-guerra @tobrun

[jfirebaugh]

LatLngBounds represents an axis-aligned rectangle, which can't accurately represent the visible map region in the cases where the camera has a non-zero bearing or pitch (as mentioned in #2259). Is that an acceptable limitation in the cases where cameraOptionsForLatLngBounds is intended for use? If so, what particular behavior should the method have in those cases (e.g. should the axis aligned bound inscribe the visible region, or circumscribe it)? If not, how can we more accurately represent the visible region?

[1ec5]

(Side note: I made a major typo above. I meant to suggest latLngBoundsForCamera() as the name of the method, but I got the name backwards.)

Is that an acceptable limitation in the cases where cameraOptionsForLatLngBounds is intended for use?

I think it’d be acceptable, as long as latLngBoundsForCamera() and cameraForLatLngBounds() round-trip values consistently. It may not be perfect for the region-constraining feature, but it’s an improvement over what we have now and would accommodate future improvements without changing the API.

If not, how can we more accurately represent the visible region?

We have cameraForLatLngs() as a polygonal alternative to cameraForLatLngBounds(), although the former currently still suffers from #2259. We could implement a latLngsForCamera(), shifting the responsibility of deciding between inscribing and circumscribing to the SDK.

[brunoabinader]

@1ec5 @jfirebaugh I've implemented a naïve approach in #8510 - notice though that even this solution does not guarantee precise conversions between cameraForLatLngBounds and latLngBoundsForCamera.

[1ec5]

#8510 landed, so now it’s up to the platforms to use it. For iOS and macOS, I think we’d want to expose this functionality as -[MGLMapView coordinateBoundsVisibleFromCamera:] (or MGLMapView.coordinateBounds(visibleFrom:) in Swift).

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.