Making lanes orthagonal and consistent

Terminology

For others’ reference, here’s a breakdown of plain (American, car-centric) English terminology, as opposed to our more analytical (still car-centric) tagging scheme:

Over the years, I’ve come to understand that the intent of this lanes key was to count the “travel lanes” (what the wiki calls “traffic lanes”). This is a useful attribute to record, but as with many things in OSM, someone chose a key that turned out to be a misnomer. At this point, I wouldn’t necessarily attribute the hesitation to change the definition to gatekeeping per se; there are real-world tradeoffs to consider when breaking backwards compatibility.

I can see how the definition of lanes as travel lanes can be awkward at times. For example, I happen to map in some cities that routinely build through bike lanes at intersections. According to the longstanding definitions of turn:lanes and such, I have to exclude the bike lane at the mixing zone, then include the through bike lane when it’s flanked by a car lane on either side, and then go back to excluding it after the right turn lane splits off as a slip lane.

What a mess, and this is without even considering buffers and other local oddities. If there’s anything to be said for this approach, at least routers have found ways to interpret these tags usefully, which is more than can be said about highway=trunk.

Lately, some mappers and mapping teams who are presumably influenced by validators have occasionally engaged in back-and-forth with me about counting through bike lanes in turn:lanes and change:lanes but not lanes. Sometimes they increment lanes; other times they lop off a turn:lanes value but leave the change:lanes value. It’s annoying, but I can’t blame them for being confused.

On the other hand, street parking (“parking lanes”) isn’t included in the definition of lanes either. This gets awkward when a city decides that a lane is sometimes a traffic lane and sometimes a parking lane depending on the time of day.

For what it’s worth, this was a regional change that aligned with a global definition. What you’re proposing is to change a global definition.

The decision wasn’t taken lightly. It involved plenty of debate, totaling (to date) nearly 200 posts on the talk-us mailing list, over 6,000 messages in OSMUS Slack’s #highway-classification channel, and countless more Slack threads. Even so, the work is far from done: not every state has begun the process of tailoring the guidance to the local circumstances, let alone implement all the retagging, and some mainstream routers continue to make assumptions based on the old U.S. definition.

This was not merely a redefinition. We also formally adopted @Vid_the_Kid’s 2010 expressway proposal to represent what had been encoded in highway=trunk. @NE2 had already given us a head start by comprehensively tagging some states with that key. To @Matija_Nalis’s point, a more specific replacement for lanes would make any redefinition go down more smoothly.

Towards the beginning of the reclassification effort, I wrote a hefty primer on the subject to ground the discussion in practical considerations. As annoying as it must have been to read that, maybe a similar writeup would help to win some traction on this idea about lane counting.

Can you give a specific example of these applications exposing an incorrect lane count to the user? To the contrary, OSRM and Valhalla only treat lanes as a minimum anyways. Even though OSRM discards turn:lanes values that don’t comport with its preconceived notion of intersection layouts, it has no problem returning the correct turn lanes from the user’s point of view when the angles do match those preconceived notions.

For example, this intersection in Morgan Hill, California, has a through bike lane flanked by two car lanes:

OSRM omits the through bike lane when giving driving directions:

(Unfortunately, OSRM’s cycling profile doesn’t produce lane guidance at all. This is absolutely an example of car-centrism, but not on OSM’s part.)

I can’t speak for the whole world, but at least in the U.S., this filtered view of the roadway would align with user expectations. The MUTCD still restricts lane use diagram signs to car lanes:

Approaching an intersection, a lane use diagram sign indicates two left turn lanes and a right turn lane but omits the left bike lane in between. (© 2019 ahmedalzain7, CC BY-SA 4.0)

Approaching an intersection, a lane use diagram sign indicates two left turn lanes, a through lane, and a right turn lane, but omits the short through bike lane, marked in green in the distance. (© 2021 networklanman, CC BY-SA 4.0)

That said, sometimes I encounter a nonstandard lane use diagram sign that indicates the bike lane, and some cities now routinely post a nonstandard symbolic version of the mixing zone sign that depicts the bike lane as a green stripe.

lanes is also used for counting the lanes on a high school running track around a football field. Plain English and all. But would a velodrome track necessarily be lanes=0 for consistency with street lane counts? :see_no_evil:

3 Likes