I imagine lanes:motor_vehicle= and lanes:vehicle= are acceptable here. all_lanes= doesn’t explain what’s “all”.
all_lanes would be the count of lanes expected to be in a *:lanes tag. See Turn lanes marked red in case of bicycle lanes · Issue #1884 · MarcusWolschon/osmeditor4android · GitHub for a longish discussion of the issues.
3 Likes
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.
can you give examples?
So far we have case where lane guidance deliberately processes data and skip bicycle lane ( Way: Cochrane Road (765715088) | OpenStreetMap + https://community-cdn.openstreetmap.org/uploads/default/original/2X/5/560e1d03587fc050e4602ef4d2533f03f5660f9e.jpeg ).
It is hardly example of treating lanes tag as including also bicycle lanes.
note that establishing alternative would need to happen first
1 Like
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.
2 Likes
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.
2 Likes
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?
2 Likes
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.
12 Likes
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.
Still looking forward to your evidence of this claim.
4 Likes
Insulting people is quite ineffective way of presenting your position.
If you actually provided this evidence, then link back to the post that you consider as presenting what you consider as evidence supporting your position would be useful.
If you think that your definition is pervasively used by data consumers and editors AND you refuse to provide evidence supporting this claim AND you consider providing evidence as unimportant and irrelevant, then convincing other is unlikely to be successful.
3 Likes
I apologize. It’s extremely difficult to assume good faith when all attempts to appease an appeal for evidence is met with a rejection of said evidence or called a bug.
TLDR: We don’t need two, very different, definitions of what a lane is. Nothing else is really relevant to this conversation except let’s standardize the definition of lanes=* with what *:lanes=* is using because that’s already intuitive enough that developers repeatedly assume it. Let’s fix the wiki to reflect this already common assumption. There’s no practical reason not to.
I can appreciate that there’s a degree of comfort associated with an early satnav lane guidance assumption level of what a lane is, but, that precludes other modes that have a use to know what lane to be in (especially if you’re somewhere that vehicular cycling in mixed traffic is the expectation, such as the US, having advance warning to get over is nice to have to plan a difficult lane change. And that’s a lot easier to do reliably when the definition that lanes=* is using and what *:lanes=* is using for what a lane is, especially when developers seem to be consistently on the *:lanes=* idea of what a lane is.
Osmose also triggers on this, though after trying to count n-1 against bicycle lanes, it now not only can’t validate lanes correctly when there’s a shared bike lane, it breaks in a new way it didn’t before. So there’s evidence right there that it’s actively harder to code for the point of “bicycle lanes and motorcycle lanes aren’t lanes except in situations where they’re mostly or only kind of lane” is needlessly more complicated than “lanes of travel are lanes”.
This weirdness about small vehicles specifically is so inobvious that both JOSM and Osmose have independently come to the more straightforward interpretation that travel lanes are lanes, regardless of mode.
And that in both cases, the lane count is being consumed by the validator to make sure the *:lanes=* have the right number of values for the lanes represented, which is extremely handy to have.
Different developers and the *:lanes=* tags wouldn’t all keep coming to the same conclusion that travel lanes are lanes if it wasn’t way easier to consume, validate and tag for consistently to start with. The wiki needs some catching up, and a few people are making some pretty bold decisions on how wide a bicycle lane is instead of checking for width:lanes (or taking lanes=* and width=* and averaging it out).
As for getting the data consistent, that’s not that far of a trip. We all seem to be in agreement that JOSM’s already doing the *:lanes=* definition
Edit: Several hours after I posted this reply, the post I had responded to was edited to ask me to refrain from responding further. Since I am unable to honor that request retroactively, consider this a general response to the topic at hand.
I pressed you for an example because, as folks around here are well aware, I value concrete examples over theory and I take an interest in how data consumers use OSM tags in practice. You also cited Magic Earth and OsmAnd a couple years ago on the talk-us list, but unfortunately that discussion ended without a resolution after insults flew. Hopefully we can keep things cooler this time.
Since you don’t seem to have any screenshots handy, here’s one where I’ve asked Magic Earth for the same driving directions as I asked OSRM earlier. As a reminder, Cochrane Road excludes the bike lane from lanes but includes it in turn:lanes, change:lanes, vehicle:lanes, and bicycle:lanes, as the wiki recommends. Indeed, Magic Earth shows all five turn:lanes values to the user, even the bike lane it knows the user can’t use due to vehicle:lanes:
Now, I happen to be of the firm opinion that showing the bike lane as a full-width standard lane presents more of a danger to cyclists, not less. But maybe Magic Earth’s developers have done usability testing to determine otherwise, or maybe they didn’t give it a whole lot of thought. (It’s always harder to tell with proprietary software.) Either way, they don’t seem to be stymied by the definition of lanes on record.
Just to make sure this isn’t an anomaly, let’s try a more complicated example. Here’s a nearby intersection along Butterfield Boulevard where the bike lane has become a shared bike lane that motorists can use to turn right. This is the usual configuration in some parts of California:
On the last way before the intersection, lanes includes the bike lane, but turn:vehicle:lanes and turn:bicycle:lanes override turn:lanes with lists filtered by vehicle:lanes and bicycle:lanes, respectively. OSRM produces lane guidance that correctly treats the shared lane as a right turn lane, rather than what would be a through-or-right lane from the cyclist’s perspective:
Let’s take a look at Magic Earth. It thinks I have to use the through lane to cut across the bike lane?
Maybe that was too ambitious; I’m not sure if these shared bike–turn lanes are even a good idea in the first place. Let’s find another example with a real bike lane. Calderon Avenue has a bike lane all the way on the right. It even has some buffer:
On the last way before the intersection, lanes includes the bike lane, and there’s no turn:vehicle:lanes or turn:bicycle:lanes as in the Butterfield Boulevard example. OSRM rejects the turn:lanes, apparently thinking this way is internally inconsistent:
Meanwhile, Magic Earth seems content with displaying lane guidance like normal:
From these admittedly few test cases, I get the impression that Magic Earth isn’t relying on lanes at all to inform its lane guidance, but it’s pretty hard to tell what exactly it’s trying to do, especially in that Butterfield Boulevard case. If the behavior of a specific navigation application is to inform a change in such a common key’s definition, I think an open-source application would make for a more dependable reference implementation. If you can document the behavior in OsmAnd, Organic Maps, or the MapLibre Navigation SDK in similar detail, I think we’d be able to touch these definitions with more confidence.
This is far from the first situation in which different applications have interpreted OSM tags in conflicting ways, and these are just two out of many applications that display lane guidance. If nothing else, the wiki should fully document the state of affairs in routers and renderers so validators can more accurately inform mappers of the consequences of tagging the lanes according to one definition or the other.
6 Likes
Feels very weird to reinvent the wheel when people are already using lanes:*=* for what this all_lanes=* would be.
The only way I see this actually working is if there’s an active effort to deprecate and kill off lanes:*=*. As evidenced that we’re almost 20 years into route relations existing and we’re still tagging road route refs on ways instead of moving that to relations.
Still seems easier to just update the wiki to reflect that people are already using the definition *:lanes=* is using to count lanes:*=*, and it’d be easier to get machines to expand abbreviations than to get a computer to work out the myriad of car-brained exceptions the wiki recommends for lanes=* that disagrees with *:lanes=*, since that’s an easy change on the wiki versus recode the world.
Given the options between “invent a new tag that does the same thing” and “update the wiki to refect reality”, I’m in the “just update the wiki” camp.
It’s the responsibility of anyone presenting their view to try to successfully persuade other conversation participants in a respectful manner. If one is not able to sway others, admit defeat and try again another day instead of giving into frustration and doling out zingers. That noted, it seems like this thread has calmed down. Thanks in advance for all those who adhere to the etiquette guidelines.
3 Likes
The github issue I linked to would indicate that that is not the case.
I didn’t see one that addresses this issue, could you clarify?