We’ve had a lot of harmful and counterproductive gatekeeping surrounding the lanes=* tag over the years, and it’s creating some problems. Namely excluding lanes for single-tracked vehicles.
Having lanes=* exclude single tracked vehicle lanes breaks the plain-language use of what a lane is. It also creates problems for lane access tagging and validating this, as now you will always have more lane access values than lanes.
We don’t have this problem with other kinds of reserved lanes, such as for HOV or bus lanes.
We have changed the meaning of tags in the past in live use (highway=trunk comes to mind in the US); this isn’t a barrier to fixing the issue.
Can we agree that all lanes are lanes and tag accordingly going forward to make it easier on everyone involved?
We’ve had a lot of harmful and counterproductive gatekeeping surrounding the lanes=* tag over the years, and it’s creating some problems
I agree that it is quite unfortunate that lanes=* was created so car-centric (or dual-tracked-motor-vehicles-centered to be more politically correct) when it was created.
Having lanes=* exclude single tracked vehicle lanes breaks the plain-language use of what a lane is
Sure, but OSM tags and values are not (not have ever been) English sentences. highway=street_lamp or shop=hairdresser and tons of other tags are completely bonkers from English language standpoint. Street lamps are not types of highways, nor do we buy or sell people who specialize working with scissors on people heads. One should really learn to live with that.
We have changed the meaning of tags in the past in live use (highway=trunk comes to mind in the US); this isn’t a barrier to fixing the issue.
I don’t think that handwaving away serious blocker is a way to go, though.
Even today, USA has only about 232k highway=trunk roads. There is more than 15620k lanes=*. That is two orders of magnitude more. (e.g. all things being equal, if USA trunk situation was solved out in 1 year, it would require about 100 years to sort out lanes issue – and getting worldwide consensus is usually way harder then getting country-wide one).
Namely excluding lanes for single-tracked vehicles.
Single-tracked vehicles are far from the only problem. See for example Pedestrian lane on the road about issue with on-road lanes dedicated to pedestrians. Also from the top of my head there is issue with shoulders (often used by 4-wheeled vehicles), difference between “hard/soft shoulders” and verges and what should count and what not too, as well as issue of parking lanes.
Can we agree that all lanes are lanes and tag accordingly going forward to make it easier on everyone involved?
As much as I’d love it, judging by my attempt at “pedestrian lanes” discussion above (with over hundred posts), which is just tiny part of this proposal, I’d guess the answer would be resounding “no” - even in that much simpler case, I was unable to reach a consensus, so best I was able to do was document multiple current ways of doing it. Things are always much more complicated then they look.
What might have a fighting chance however would be a well-defined and detailed proposal for alternative to lanes=*, as mentioned in this comment.
What might be good enough for @Baloo_Uriza (it you’re primarily about two-wheelers), is simply using :lanessuffix, as defined on Lanes - OpenStreetMap Wikiinstead oflanes=* tag, e.g. see the example there of:
That’s a bit of an overshoot. There’s about 483k ways worldwide that have cycleway=* and lanes=* tagged right now, worldwide.
(e.g. all things being equal, if USA trunk situation was solved out in 1 year, it would require about 100 years to sort out lanes issue – and getting worldwide consensus is usually way harder then getting country-wide one).
I don’t see a need to rush to fix the existing errors as much as a need to stop introducing new ones as being the bigger problem.
No, but this is exactly what I mean by bringing lanes=* orthogonal to everything else. lanes=* is playing by a different set of rules than the lane attribute keys do for any other vehicular mode, and it breaks being able to readily validate these against at least the lowest common denominator that a lane is for vehicular travel that most tools quite reasonably expect. As it is, lane guidance is off-by-one wherever a data consumer is unaware of this “is this a lane or not” guessing game the existing idea of “lanes are only for double-tracked vehicles” because it’s plainly obvious nobody’s expecting the definition of lanes to be that weird. They do get this right when told the correct number of lanes with their lane attributes.
I’m not opposed to being completionist for the edge cases and go with “any key that works as an access key can potentially have its own designated lane”, though most places would call a “pedestrian lane” a “sidewalk” even if it is just paint. And for that, I don’t think it’s necessary to do that.
No, because data consumers like Magic Earth and Osmand appear to already be consuming the data without the assumption that lanes are only for doubletracked vehicles, and reasonably so. The wiki’s supposed to be descriptive of how the tag’s actually being used, not prescriptive. Just because the original concept was a bit carbrained doesn’t mean it needs to remain that way, especially when it’s actively not being consumed that way.
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.
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.
(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:
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?
It is not really viable to redefine lanes= tags as it would be necessary to recheck/resurvey millions of places. And no, “just check aerial” is not sufficient anyway.
To say nothing about changing software - editors and data consumers, documentation, mappers etc.
Introducing new tag (all_lanes ?) tag would be viable, but it would still need to handle somehow foot lanes, pseudo-lanes such as “suggested cycleway lanes” pseudoinfrastructure* and so on.
* in some places you have painted bicycle lines that can be completely ignored by car drivers, sometimes can be ignored also by cyclists - is it also a lane?
But just redefining lanes tag will not work well.
and that is why you cannot just change wiki definition (or how StreetComplete tags lanes) and declare that meaning of lanes is now changed
you are assuming that all lanes= with bicycle lane, motorcycle lane, footway lane or other small/non-motor lanes have cycleway= tagged
this assumption is wrong
For start, there are ways with lanes tagged and no cycleway tagged at all, despite bicycle lane being present. Or tagged with cycleway:both or cycleway:left or cycleway:right
following tagging scheme that is not matching your ideal is not a tagging error
maybe lanes= is subotimally defined or named (we have plenty of that!) but its meaning is clearly defined
what you mean by that? Can you provide detail on why you think so?
as made evident by fact that people invented and followed such car-centric tagging scheme it is not true
likely people using lane assist would be surprised by bicycle lanes being counted
IMHO the simple and least troublesome way forward is to introduce a new tag for the overall lane count, lets say: all_lanes (with all_lanes:forward and all_lanes:backward for bi-directional roads).
PS: and let lanes die out.
PPS: I don’t think the fuzziness wrt bicycle “sublanes”/ vs a proper bicycle lane is going to be solvable in a foolproof fashion.
This can easily be remedied by treating bicycle lanes as lanes.
I’d call that a lane, just one that’s closed certain hours. If travel is never allowed, I’d call that a shoulder or median.
Same situation, opposite problem. Fixing one region’s overly specific definition of lanes that got applied globally in favor of using the definition of lanes already in active use by data consumers.
You did.
And there’s the incorrect lane guidance. There are two through lanes, not one.
Looks like the street got repainted but the lane guidance did not. The correct sign would include a bike lane between the left and right turn lane signs.
OK, maybe we need to formally work on deprecating lanes=*, work on removing it entirely and tell data consumers not to use it. I’m still more on “let’s fix lanes instead” side because it’s way less work for data consumers, given that they’re already consuming data the way I’m suggesting we use the lanes tag. Like, I’m only suggesting this because this is already how it’s being actively consumed and validated. Is the wiki not supposed to be descriptive of how things are being used? Because if that’s the case, it should read more like this and folks gatekeeping the wiki need to get over themselves.
Where in the MUTCD or California MUTCD does it say that this sign is incorrect? To the contrary, even a “Yield to Bikes” symbol sign that combines a lane use sign with a yield symbol, like the one I pointed to earlier, is explicitly disallowed by the Federal Highway Administration. The next edition of the MUTCD is slated for publication by the end of the year, which gives you some time to lobby Washington for a change to the R3-8 sign series. Until that happens, you’re going to have an uphill battle convincing navigation software developers to include the extra lane use arrow, even if OSM starts counting that in lanes.
Anywhere there’s a bicycle lane, globally, yes. If the bicycle lanes are not included in the lane tagging, the lane guidance is wrong by however many bicycle lanes are present. If the bicycle lanes are excluded, then there’s no way to validate the number of access/turn lanes is correct if the lane counts aren’t including bicycle lanes.
OSM is not the MUTCD, and the provisional late 1990s/early 2000s yield to bicycles signs Portland used are not germane to this discussion except as a destructive diversion. Please be constructive or refrain from participating in this discussion.
The primary purpose of lanes is to indicate the number of travel lanes, so that for example a renderer can draw a realistically wide roadway. lanes is not primarily about validating whether turn:lanes has the right number of slots. If a key is guaranteed to be the sum of a set of other keys, we’d probably be discussing its deprecation.
You’re probably referring to Portland’s traffic study into blue bike lanes paired with blue bike lane symbol signs. However, these signs have also been posted elsewhere, including in Washington, D.C., and, as I have demonstrated, in the San Francisco Bay Area. I agree that this is technically a “yield to bikes” sign rather than a lane use diagram sign. But other than one-off anomalies, this is the closest thing to a regulatory sign that accounts for bike lanes. Look, I tried to find something that would bolster your case, but it isn’t adding up. Maybe reality isn’t very just from a cyclist’s perspective, but we’re here to document that state of affairs.
The MUTCD and MUTCD-compliant signs are relevant because they inform what users expect to see on screen and in voice instructions during turn-by-turn navigation – which is the main use case for turn:lanes tagging. You’ve expressed an opinion that navigation applications should depict an extra arrow representing the bike lane to motorists, and a “correct” sign on the ground would include an extra arrow as well. Maybe it would be helpful for you to provide examples of this correct software behavior in non-OSM-based applications and examples of this correct signage on the ground, so folks reading this – especially international folks – can be confident that you know what you’re talking about.
To estimate it in the absence of width and/or width:lanes, it can be used for that, but that’s not how it’s usually used.
And yet, that’s how tools are actually using it, from the JOSM lane editor, the data validator in JOSM to Magic Earth and Osmand.
The wiki is supposed to be reflecting how things are being used in reality, not preserve an oversight to a proposal. And certainly not to the arbitrary and discriminatory degree that has been done with this topic.
I see you haven’t had the pleasure of using A/B Streets or Streets GL yet.
I’m not sure what you mean by Magic Earth and OsmAnd validating lanes. I’ve pointed out that OSRM does use lanes to validate turn:lanes. However, OSRM treats lanes as a minimum floor, just like the wiki says. It also fully recognizes that some entries in turn:lanes apply only to one mode of transportation or another, as determined by keys such as bicycle:lanes and vehicle:lanes.
Apparently JOSM’s validator rule behaves as you describe, checking for strict equality, and it’s a bug. I’m unsure how this bug would’ve crept into JOSM; this old patch was never merged precisely because it misinterpreted the wiki’s definition, and the possibility of non-motorized lanes not counted in lanes also came up in this old discussion.
There are several JOSM plugins for editing and visualizing lanes, at least one of which is unmaintained and outdated in terms of tagging (being based on a failed proposal). Do you know which one you’re using?
I see this situation as kind of analogous to how when a recipe calls for eggs, it never specifies chicken eggs, it’s just understood that that’s the kind of egg that is meant by default if not otherwise specified.
Likewise, when people talk about “lanes”, it’s generally understood they mean lanes for motor vehicle travel by default if they don’t otherwise specify.
The lanes=* tag excluding things like bike lanes and parking lanes thus matches common vernacular and, ergo, matches what the casual observer will likely expect it to mean based on what it is called. Which is more useful than if it were to instead match a hyper-literal definition, which will confuse anyone who hasn’t been specifically trained to expect it. I think it’s fine as is.
Yeah, no, that’s the correct behavior, not a bug. And consistent with how all the other lane tags work. The fact that this is so pervasively used already under this understanding by consumers and editors is putting the lanes wiki page further and further out. Let’s just fix the wiki to document objective reality, not try to tell reality it’s the one that’s wrong.
Clearly not.
Let’s keep this to just people who understand what lanes are and who are tagging this, please.
- even in that much simpler case, I was unable to reach a consensus, so best I was able to do was 
