Open brncsk opened 2 years ago
Thanks for opening this issue @brncsk!
Would fitScreenCoordinates
work for your use case? Due to perspective this wouldn't work in all cases, but if the camera position is close to the goal position, then calculating the screen bounding box of your building would likely give a decent approximation.
If you do proceed with the PR we'd be happy to accept it! I personally lean toward option 2.
Motivation
For an indoor visualization use case, I'd like to be able to fit the map view to a building's 3D bounds – see the following screenshot:
I cannot currently do that, as
fitBounds()
only lets me fit 2D bounding boxes.Design
AFAICT the core functionality is already there in the form of
Camera#_cameraForBox()
– but it's only used for fitting an elevation box at non-zero pitch ATM.Possible options I can think of:
Expose
minAltitude
/maxAltitude
directly inFitBoundsOptions
.Extend
LngLatBounds
/LngLatBoundsLike
to accept three-tuples of(lng, lat, alt)
– wherealt
is in meters. (I guess this is both the more involved and the more questionable API design choice as the vertical unit of measurement differs from the horizontal ones.)As the ray marching algorithm iteratively changes the transform's
center
,zoom
,pitch
andbearing
, it may be better to expose this functionality as a new method onCamera
(and transitively onMap
), similarly to howfitScreenCoordinates()
(the only call-site for_cameraForBox()
) is also a distinct method.Mock-Up
(Original code taken from https://docs.mapbox.com/mapbox-gl-js/example/fitbounds/).
Option 1 (exposing
minAltitude
/maxAltitude
inFitBoundsOptions
):Option 2 (
LngLatBoundsLike
accepts three-tuples):Option 3 (expose a new method on
Camera
andMap
):Would you accept a PR once the design is decided on?