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?