Lane guidance from OSRM intersections[].lanes (Valhalla) — sanity-check on approach

[JFDionne]

Hi! We're using Ferrostar (MapLibre + Valhalla, self-hosted) on a ~6–8k-vehicle fleet and want lane guidance. I have it working end-to-end and would like your read on the approach before opening PRs.

Problem. Valhalla (and OSRM generally) report turn lanes in intersections[].lanes, not as a bannerInstructions[].sub lane component. Ferrostar currently only reads lanes from the sub-banner, and the OSRM Lane model even has a // TODO: active / valid_indication — so for Valhalla routes, lanes are silently dropped.

What I did (2 small commits, core + UI):

1. core — parse the active / valid_indication lane extensions, and surface the lanes nearest the maneuver onto the maneuver's primaryContent.lane_info.
2. compose — a LanesView (one cell per lane, an arrow per permitted direction, reusing ManeuverIcon/the Mapbox direction_* drawables), rendered above the maneuver in InstructionsView when lane info is present. Active lanes use the theme icon tint, others dimmed. Tests: a Rust parser test + Paparazzi snapshots.

Design question for you — where should lanes live in the model?

• I put them on primaryContent.lane_info (existing field), which keeps your existing tests/snapshots untouched.
• Alternative: a dedicated lanes field on VisualInstruction (cleaner semantically, but a wider FFI change touching every constructor + the SwiftUI side).

Which do you prefer? I'd rather align now than polish snapshots for a shape you'd change.

iOS: the core change is shared, so iOS gets the data for free; the SwiftUI InstructionsView render is the remaining piece (happy to follow up).

Screenshots

[ianthetechie]

Thanks for opening a discussion proactively @JFDionne!

core — parse the active / valid_indication lane extensions, and surface the lanes nearest the maneuver onto the maneuver's primaryContent.lane_info.

Makes sense. Yeah, we just never got around to parsing these for whatever reason (probably indecision about how to use them). One quick note on these is that they should be optional fields, as they are an extension to the OSRM API.

Design question for you — where should lanes live in the model?

• I put them on primaryContent.lane_info (existing field), which keeps your existing tests/snapshots untouched.
• Alternative: a dedicated lanes field on VisualInstruction (cleaner semantically, but a wider FFI change touching every constructor + the SwiftUI side).

I think these should map to the sub content rather than primary. That's how these are typically returned from servers which support lane indications in banners (to be honest, I don't know if Valhalla does this, but it should). Here's an example of how Mabpox handles it in their API.

We'll need to specify what to do if the API response includes the lane guidance via the sub component already. As I was typing this out, I realized this may not be as obvious as I had thought... I expect that many APIs will return banners with lane guidance activating only near the maneuver point. Depending on your use case though, it could be useful to include banners that activate with lane guidance for each intersection. Is this what you had in mind? If so, we should probably make it configurable in some way. And even if you're only thinking of using this as a fallback for missing banner guidance at the maneuver point itself, we'll need to make sure the lane guidance doesn't activate too early (e.g. 10km away from the turn).

Hopefully that all makes sense; there's a lot to this, and we're somewhat tied by the existing APIs 😅 Just adding lane_info might not be enough / the correct approach depending on what you're envisioning. (Incidentally, @Archdoog and I have a side project aimed at improving banner and narrative generation, but progress is much more sporadic than Ferrostar.)

Finally, I don't remember if moving it to a sub component automatically changes the visual position rendering, but @Archdoog and I just discussed and we think the lane arrows probably work better below the main banner content rather than above it.

[JFDionne]

Appreciate the detailed reply, this is exactly the back-and-forth I was hoping for. Let me knock out the easy ones, then the two I actually need you on.

Optional fields: yeah, already the case. active/valid_indication are optional and the whole lane path just no-ops when they're missing, so existing responses don't change at all.

Position: no problem, I'll drop the arrows below the banner.

Early activation: totally with you, and it's an easy one, the core already hands me distance_to_next_maneuver, so I can gate the lanes to pop in near the maneuver instead of hanging around the whole step. Do you see that living in core, or is it a UI thing? I'd lean UI, but your call.

sub vs primary, I can move to sub, but heads up first, 'cause it's the crux. Valhalla/OSRM don't actually put lanes in a sub banner at all, they live in intersections[].lanes. So "put them on sub" isn't really a re-map, it's me synthesizing a sub_content to park them in. That's literally what my first commit did, and I pulled it back since synthesizing sub_content messed with your existing parse_valhalla_asserting_sub_maneuvers snapshot. Sticking them on primaryContent.lane_info was just the path of least resistance to keep your tests happy :)

Big picture, honestly this is the one I care most about your read on. If a lane_info bolt-on is just gonna get reworked into whatever you and @Archdoog are cooking up for banners/narrative, say the word and I'll shape it to fit.
We've got it running live on the fleet off a fork already, so no pressure on my end. I'd just rather ship something you won't have to rip out later.

[JFDionne]

Hi @ianthetechie, did you received my reply ?