-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Description
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 methods getCenter
, getZoom
, getPitch
, getBearing
and getPadding
. 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:
function getCenterElevation(map) {
return map.queryTerrainElevation(map.getCenter(), {exagerated: false});
}
However it does not seem to match what map.transform
uses to target the camera. I observe that getZoom()
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 alike
mapbox-gl-js/src/ui/handler_manager.js
Lines 485 to 489 in d7e1beb
if (eventEnded("drag") && !hasChange(combinedResult)) { | |
const preZoom = tr.zoom; | |
tr.cameraElevationReference = "sea"; | |
tr.recenterOnTerrain(); | |
tr.cameraElevationReference = "ground"; |
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 of transform
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.