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.
4 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.
7 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.
4 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?
I’ll revive that thread from my own experience and the existence of a similar tag since I’ve seen an increased use of lanes or at least more mappers which tend to use bicycle:lanes tagging over or at least in addition to cycleway which really makes me question the latter for cycle lanes (notice that cycleway already was used to make exceptions oneway restrictions until just recently).
Overall, cycleway implies a similar use as sidewalk in that the bicycle ROW is at the edge of the carriageway[1] when not being outside the carriageway like a sidewalk (i.e. a cycling track) which is true in 99% of all the time but falls flat in specific but still somewhat common edge cases — that being turn lanes.
It doesn’t help that bicycles are a middle ground between automobiles and pedestrians and sometimes are treated like vehicles (no cycling on sidewalks; taken by :lanes into account on OSM) and other times like pedestrians (shared use paths, may come in form of sidewalks; not taking by lanes into account, comparable tagging to sidewalks and rendered like footways on OSM).
The other point is that cycleway has a similar but semi-deprecated tag (still increasing in use, mind you), that being busway. Acceptance to use :lanes was probably easier because it’s common to see them on both outer and inner lanes and bus:lanes alone already surpasses busway:right since a couple years after the former’s introduction.
This isn’t helped by the fact I’ve come across highways where busway-tagged bus lanes either are or aren’t counted towards lanes.
Incidentally, both tags but busway in particular ultimately came about to be because of the lack of per-lane access tags in the initial days of OSM.
cycleway=share_busway is a particular offender in my eyes and belongs to be deprecated IMO (I don’t count them as proper cycling lanes, for starters, and rather see them as lanes with no car access) but that’s a topic for a different story.
Regarding updating the lane counts: It’s safe to say that the amount of highways with cycleway:*=lane is in a manageable size if you look it per city. For starters, although there are many roads with lane=*, the goal is to only look at roads with cycleway:*=lane.
The odd street with a large two-way car lane with advisory lanes at the sides also is doable if something the community has to accept and better suited by a manual edit.[2].
The punchline is that the lane count and per-lane access (if it isn’t done so already) can be mechanically retagged in most cases, especially because streets with cycling lanes (the aforementioned edge case notwithstanding) tend to have painted lanes in general.
IMO a bigger issue is to open up a transitioning phase in a good way (i.e. the confusion is avoided and how long we have to way before removing cycleway:*=lane) as well as that QA tools like StreetComplete have to know that a cycleway exists.
QA like Osmose can already differenciate between full-width and non-full-width lanes so the idea that data consumers can distinguish them shouldn’t be that difficult.
Even worse is how cycleway:*=* handles both cycling lanes and adjacent cycleways separated by some barrier (either some grass or more commonly a kerb) at the same time and QA like StreetComplete would have to know a cycleway exists as a lane or in another way (or doesn’t, obviously).
cycleway also is easy to implement wheras per-lane tagging is more complex (think of tagging bus lanes in SC and how you should create a note if you see one when asked to count the lanes) and can easily go wrong both manually and by tools. For SC specifically, counting lanes also becomes ambiguous when car lanes already exist but the cycleway tag hasn’t been set already unless a tag specifically for the former has been defined.
This, and one is sometimes able to cycle on shoulders which isn’t a proper lane and easily set by cycleway:*.
1 Like