-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API to access the camera parameters when using terrain #12040
Comments
Thank you for opening this issue @Pessimistress! In the case of consistently recreating transform, would the Free Camera API be of any help?
I agree that this is a troubling issue. I think that much of the cause for this stems from our attempts to avoid breaking existing mapswhile adding new 3d features. If we were building from scratch, we might have considered preventing clipping by capping zoom at high elevation areas. Instead, in order to allow for a smooth update from existing 2d maps, we changed the behavior of zoom and added complexity under the hood. (We've more recently done the same for globe.) I'm not sure what we can do about this without introducing breaking changes, but simplifying the transform API to prioritize 3d use cases would be a great thing to include in v3.0.0. |
Thank you @SnailBones for the pointer. I can successfully calculate the "real zoom" from camera position, center and pitch: |
Motivation
To use deck.gl (or other visualization overlays / custom layers) with Mapbox's terrain feature, we need to be able to construct viewport matrices that match those of the base map. Currently deck.gl accesses transform properties via
Map
class methodsgetCenter
,getZoom
,getPitch
,getBearing
andgetPadding
. These are not sufficient to match the camera if terrain is used.Design
Unsure, see discussion below
Implementation
In my experiment, I have attempted to match the Mapbox view matrix with the following:
However it does not seem to match what
map.transform
uses to target the camera. I observe thatgetZoom()
returns different values before and after dragging ends (i.e. before and after the pointerup event, without the camera moving), possibly due to the manipulation here and alikemapbox-gl-js/src/ui/handler_manager.js
Lines 485 to 489 in d7e1beb
IMO this behavior is at odds with the documented definition for zoom level, which should not be dependent on some internal interaction state.
A higher-level issue I have experienced as a maintainer of Mapbox-dependent libraries, is that the more recent features, including terrain and projection, are very much hostile to library developers. I am seeing the increasing behavior of
setCenter
,setZoom
etc. become dependent on map states that are manipulated in the input handlers and the render call. The matrices oftransform
cannot be predictably reproduced from public getters/setters. As a result, we are not able to take a snapshot of a transform instance using public API, and replay that snapshot later. Here are some examples of our desperate struggle trying to chase down private transform mutations:visgl/react-map-gl#1894
visgl/react-map-gl#1855
visgl/react-map-gl#1831
I am personally very excited about these new features coming to Mapbox, and the users of my libraries expect to be able to use them as they become available. The only way I can make Mapbox integrations forward-compatible, by eliminating all hacks, is if
transform
can be consistently reproduced via public APIs.The text was updated successfully, but these errors were encountered: