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
Providing one or more auto-pan and/or zoom for the map view is a key usability element. Because of its nature and its use cases, it cannot 1:1 mirror the way we handle that in the 2D view. This issue is a first attempt to scope this feature.
Motivating use-cases
Single entity
Think: displaying the car location on a map in the nuscenes example.
In this case, the view should track the point of interest as it moves. There is no constraint on the zoom level, so up for the users to change. A "city-block-scale default zoom level feels like a good default: perfect for an automotive; might need a little zooming in or out for smaller scale robot, resp. drone applications.
This use case highlights a fundamental difference between the 2D and Map views. The former offers no absolute positioning context at all by itself due to the uniform background. Panning to track a single entity's translation has zero visual (and thus informational) value, so our default handling of the visual bounds should aim stability. The opposite is true for the map view: in this case, it can be desirable to have an entity that is stationary in screen space (aka stuck in the middle of the view) and have the "visual bounds" constantly change.
In this case, both the position and the zoom level of the view should adjust such that everything fits on screen. To minimise distraction,, the view should pan only for large changes of the swarm's bounds/centroid (think a flock of bird going somewhere), but not due to changes of the internal swarm distribution (think the drone show where the swarm remains at the same general location).
This use case seems to be a better fit to a 2D-view-like, bounding-box-based behaviour.
Technical considerations
The view state is maintained by the walkers crate. In particular, it already supports a "track my position" vs. "user defined" mode, and automatically switches to the latter upon user interaction. Our auto-pan strategies would piggy-back on this be activating the "track my position" mode and setting "my position" as required.
MVP
For the scope of the initial map view PR (#6561), I propose to use the following approach:
track the centroid of the logged points
basically what we need for the single entity use case
not great for the swarm with potentially distracting small spurious panning / work-around: manual pan a little bit to disengage auto-pan
if unset, initialise the zoom level based on the current spread of logged points (then, no further auto-zoom)
Future work
This is mostly TBD.
Explicit modes in the UI:
"Track entity"
this requires specifying which entity (and which instance!) to consider if more than one are included in the view
"Track swarm"
"Manual"
The text was updated successfully, but these errors were encountered:
Providing one or more auto-pan and/or zoom for the map view is a key usability element. Because of its nature and its use cases, it cannot 1:1 mirror the way we handle that in the 2D view. This issue is a first attempt to scope this feature.
Motivating use-cases
Single entity
Think: displaying the car location on a map in the nuscenes example.
In this case, the view should track the point of interest as it moves. There is no constraint on the zoom level, so up for the users to change. A "city-block-scale default zoom level feels like a good default: perfect for an automotive; might need a little zooming in or out for smaller scale robot, resp. drone applications.
This use case highlights a fundamental difference between the 2D and Map views. The former offers no absolute positioning context at all by itself due to the uniform background. Panning to track a single entity's translation has zero visual (and thus informational) value, so our default handling of the visual bounds should aim stability. The opposite is true for the map view: in this case, it can be desirable to have an entity that is stationary in screen space (aka stuck in the middle of the view) and have the "visual bounds" constantly change.
Swarm of entities
Think: the air traffic data (#5449) example; or a recording of Intel drone light shows.
In this case, both the position and the zoom level of the view should adjust such that everything fits on screen. To minimise distraction,, the view should pan only for large changes of the swarm's bounds/centroid (think a flock of bird going somewhere), but not due to changes of the internal swarm distribution (think the drone show where the swarm remains at the same general location).
This use case seems to be a better fit to a 2D-view-like, bounding-box-based behaviour.
Technical considerations
The view state is maintained by the walkers crate. In particular, it already supports a "track my position" vs. "user defined" mode, and automatically switches to the latter upon user interaction. Our auto-pan strategies would piggy-back on this be activating the "track my position" mode and setting "my position" as required.
MVP
For the scope of the initial map view PR (#6561), I propose to use the following approach:
Future work
This is mostly TBD.
Explicit modes in the UI:
The text was updated successfully, but these errors were encountered: