You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.flyTo and .easeTo are totally my jam, though I've been seeing more frequent use cases for doing so to follow a moving marker-- usually in-car nav, or tracking some moving thing from just-above-the-driver's eye view.
It would be cool to feed in a linestring geometry --commonly provided by a routing query-- and
automatically follow it at some configurable speed (would it be sacrilege if this were measured in mph/kph? the physical distance of a pixel is variable with zoom level)
pivot the view to the proper bearing, to stay over (and behind) the driver's shoulder
bonus: accept zoom/pitch/speed as geojson properties at certain junctures along the route, and interpolate between them. This might require geojson points instead of one linestring, as each feature can have only one set of props.
The text was updated successfully, but these errors were encountered:
I've been thinking about this too, also looking at camera flight algorithms that would make the movement smooth (without fast turns). I may take a stab at this later, likely involving Centripetal Catmull-Rom Spline.
.flyTo
and.easeTo
are totally my jam, though I've been seeing more frequent use cases for doing so to follow a moving marker-- usually in-car nav, or tracking some moving thing from just-above-the-driver's eye view.It would be cool to feed in a linestring geometry --commonly provided by a routing query-- and
The text was updated successfully, but these errors were encountered: