Give the V2X live map its own screen, and a traffic light per SPATEM
The map was a third view mode inside the V2X Monitor's topic pane, below the use case alert panel and the DENM/CAM TX cards. On a phone that left it about a third of the display tall, which is not enough to see where anything is relative to anything else - the one thing a map is for. It is now its own destination, V2xMapScreen on route v2x_map, reached from a map button in that screen's header. The button sits in the header rather than the view-mode row so it is also reachable from the message detail pane and does not move as the available modes change with the selected hardware. The status bar and bottom nav are hidden on this route; the screen carries its own floating back button, and system back still works. Both hardware paths get the same screen: everything drawn comes from CamUseCaseRepository, which already merges the CiT One's MQTT feed and the ESP32-C5's serial feed into one set of flows. With the map gone from the toggle row, the row offers a single choice on the ESP32-C5 path - there is no broker there and `topics` is always empty - so it is hidden entirely in that mode. SPATEM markers. Hazards already drew as a warning triangle; signalised intersections did not draw at all. They now draw as a traffic light with one lamp lit. Two things are worth knowing, because neither is forced by the data: - SPATEM carries signal state but no geometry, which is MAPEM's job and MAPEM is not decoded. The only position available is the sending RSU's own CAM, so the light is drawn there, and that RSU is drawn once - as the light, not as a CAM pin with a light on top of it. An intersection whose sender has not been heard over CAM cannot be placed; the map says how many rather than dropping them silently. - Which lamp lights follows the rule DashboardScreen's SignalCard already uses, the signal group changing soonest speaking for the intersection, so the same intersection reads the same way in both places instead of inventing a second convention. Four drawables rather than one tinted at runtime: setTint recolours every path in a vector, so a single shared asset would turn the whole light one flat colour and stop it reading as a traffic light. Marker reuse. Every incoming message recomposes the map, and the update block cleared the overlay list and rebuilt every Marker, decoding and mutating a fresh Drawable per marker - at up to 10 Hz per station. It also called animateTo(own) on every update, restarting the pan animation before it could finish. Drawables are now loaded once per alert level and phase and shared (osmdroid sets the icon's bounds on each draw, so one instance across markers is safe), Markers are cached by key, and the overlay list is only reordered, which moves references without allocating. Following uses setCenter, keeping animateTo for the one move worth seeing: the rider asking for follow back. Follow-own now hands over to the rider on the first touch and returns via the location button, which lights up while following. Before this the map could not be panned at all while traffic was flowing, since the next CAM dragged the viewport back. Also on the map view: tiles scaled to DPI, the floating +/- buttons off (they sit where the thumb lands and duplicate pinch), a zoom range, and more tile threads so a pan that exposes a screenful of new tiles is not served two at a time. Compiles and the unit tests pass. None of it has been seen with live traffic; TODO.md lists the on-device checks under "Waiting on hardware", including which of the HAW RSUs send CAM alongside SPATEM.
This commit is contained in:
@@ -143,12 +143,18 @@
|
||||
<string name="gnss_no_fix">No GPS fix yet - move to an open area</string>
|
||||
<string name="map_title">Location Map</string>
|
||||
<string name="map_location_label">Current Location</string>
|
||||
<string name="v2x_map_remote_count">%1$d tracked remote road user(s)</string>
|
||||
<string name="v2x_map_own_label">Own (ego)</string>
|
||||
<string name="v2x_map_remote_plain">Remote #%1$d</string>
|
||||
<string name="v2x_map_remote_info">Remote #%1$d · Info</string>
|
||||
<string name="v2x_map_remote_awareness">Remote #%1$d · Awareness</string>
|
||||
<string name="v2x_map_remote_warning">Remote #%1$d · Warning</string>
|
||||
<string name="v2x_map_title">V2X Live Map</string>
|
||||
<string name="v2x_map_back">Back</string>
|
||||
<string name="v2x_map_follow">Centre on own position</string>
|
||||
<string name="v2x_map_legend_cam">Road users (CAM)</string>
|
||||
<string name="v2x_map_legend_denm">Hazards (DENM)</string>
|
||||
<string name="v2x_map_legend_spat">Signals (SPATEM)</string>
|
||||
<string name="v2x_map_spat_unlocated">%1$d signal(s) not shown - sender position unknown</string>
|
||||
|
||||
<!-- Settings -->
|
||||
<string name="settings_title">Settings</string>
|
||||
@@ -198,7 +204,6 @@
|
||||
<string name="mqtt_no_topics">No messages yet</string>
|
||||
<string name="mqtt_view_list">List</string>
|
||||
<string name="mqtt_view_topics">Topics</string>
|
||||
<string name="mqtt_view_map">Map</string>
|
||||
<string name="mqtt_no_topics_hint">Connect to the OBU and wait for V2X traffic</string>
|
||||
<string name="mqtt_no_messages">No messages on this topic yet</string>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user