Expose lanes:forward / lanes:backward

[dsaderholm]

Hi. First, thanks for v2. We're a small personal fork (Ford Fusion with retrofit Edge ADAS) and we've had it running in an observe mode alongside v1 for a couple of days, logging mapdOut at 20 Hz so we can compare the two on the same drive before switching over. The msgq rewrite has been completely painless.

One request. Would you consider carrying OSM's lanes:forward and lanes:backward into the tiles and onto MapdOut, alongside the existing lanes?

Similar in shape to #86 (expose highway rank), which I think became highwayClass in v2.1.0. Same idea, a different OSM tag that the vehicle can't infer on its own.

The reason: on a 2+1 road, lanes = 3 is ambiguous in the way that matters. The lane to your left is either your own passing lane or the oncoming carriageway's, and nothing on the vehicle can tell those apart. The camera sees identical geometry, and radar only resolves it once a car actually appears. The directional split states it directly.

We measured coverage before asking rather than assuming it's there. On US-6 in Utah, 497 way segments:

lanes:forward / lanes:backward   52.9%
turn:lanes                        1.4%
overtaking                        0.0%

So it's one of the better-covered tags on exactly the roads where the ambiguity bites, and it's the only one of the three worth your time.

It looks additive on both sides, new fields on Way and on MapdOut, so older readers ignore them and existing tiles stay valid.

If you do pick it up, I'm glad to test. I have v2 running on a device with tiles already downloaded for Utah and the I-15 corridor, so I can flash a build and confirm the values against real roads rather than just that it compiles. Equally happy to be told it's out of scope and work around it.

Either way, thanks for keeping this thing alive and hosted. Being able to read map data in the route logs at all is a step change for us.

[pfeiferj]

Yeah, I can work on adding this. I honestly didn't even know forward and backwards tags for lane counts was a thing in osm. The way I generally handle forward and backwards tags is by adding them to the offline file, but I don't add additional fields to mapdOut. Instead, I check if they exist for the direction of travel and if so then I use the correct one in the lanes output. That's how maxSpeed:forward and maxSpeed:backward are handled as the user probably doesn't care about the direction that isn't active

[dsaderholm]

That is a better shape than what I asked for, and it works for us. We only care about the active direction too.

One thing worth a line in the release notes when it lands, because it will not be visible to consumers: lanes changes meaning on two-way ways. Today it is the way total, so a 2+1 passing section reads 3. Afterwards it is the count for our direction, so the same section reads 2. Both are correct, and there is no way to tell at runtime which one you are getting.

We have a gate that reads lanes <= 2 on a two-way way as "one lane each way, so the lane to my left is oncoming". After the change that same test would refuse a pass on a real passing lane. Ours is pinned by a test now so the version bump breaks loudly rather than quietly, but other forks reading lanes may not notice.

Not asking you to change the approach, it is the right one. Just that the release note say lanes is now direction-resolved on two-way ways.

Happy to test a build when there is one.

[pfeiferj]

Gotcha, what I might do then is have a new field that is something like currentDirectionLanes that only gets filled when there is a directional lane tag and then keep lanes as a total. The current lanes tag does get used for road size calculations when attaching to a road so it might make sense to split them for this as opposed to maxSpeed where there's really not a functional reason to know the other directions maxSpeed

[dsaderholm]

That works better than the release note would have, and it means there is no release note to write. lanes keeps its meaning, so nothing downstream shifts underneath anyone who is not looking for it.

The split reason makes sense from here too. Road size when attaching to a road genuinely needs the total, so the two are different questions, which is what separates this from maxSpeed.

One thing we will assume unless you say otherwise: currentDirectionLanes of 0 means "no directional tag here", never "no lanes in your direction", so tiles built before the field read as unknown rather than as a road with nothing on it. That matches what you said on issue 86 about defaults in older map files.

Still happy to test a build.