Lanes quest should not ask for "car lanes"

[Discostu36]

This is about the wording of the lanes quest:

According to the wiki, the lanes= tag includes all lanes for motor vehicles (excluding one-track vehicles like motorbikes). Especially bus lanes should be included.

With the current wording, users will probably exclude bus lanes from their counting, leading to wrong tagging.

Suggestion for better wording:

• How many car and bus lanes does this road have?
• How many motor vehicle lanes does this road have?

The second alternative might be problematic if there are motorcycle lanes, I don't know if they exist in some countries.

[westnordost]

Most correct would be "two-tracked vehicle traffic lanes" (i.e. excluding lanes for motorcycles, but also excluding shoulder lanes), but this is the kind of officialese I'd want to avoid in this app. The app shall speak normal English with the users. I figure it used to ask "What's the number of lanes" before someone pointed out that it could be misinterpreted to include bicycle lanes.

I reckon that the current wording can be misinterpreted to exclude bus lanes, so it is true that the wording should be improved. I wonder, in normal US-English, would "lanes" include the emergency breakdown (aka shoulder) lane? What would you say, @1ec5 ?

Another word, at least for English, could be "full-width lane"?

[pkoby]

"Car and bus driving lanes"?

I wouldn't consider the breakdown lane as a lane, and I feel like it wouldn't generally be considered such. But calling them driving lanes might clear that up.

[arrival-spring]

But as soon as you go to add lanes it gives you suitable instructions about the lane count:

[Discostu36]

Are they suitable? Why should I leave a note for bus lanes if this is only for lanes:forward and lanes:backward?

[westnordost]

Right, thanks @arrival-spring. I now remember why the quest specifically asks for car lanes and has this clarification in the selection dialog. So, this is a will not fix..

It is because just tagging lanes:forward=2 on a road with one bus lane and one car lane without also adding the information that one of these is a bus lane results in wrong data: the wrong data being that in the OSM database it looks like there are two car lanes now.

[Discostu36]

I don't agree. As the tag by itself doesn't specify which two-tracked vehicles are allowed on the lanes, it only looks like that if you misinterpret the tag.

[westnordost]

Not also specifying the bus lane is as wrong as mapping a private road without also specifying that it is not accessible. So, better word is maybe, incomplete. But incomplete in a way that leads to wrong results when the data is actually used. In that case, routing software may try to route you through inaccessible roads. In the case of missing bus lanes, it will assume that the road has a much higher traffic throughput than it actually has.

The lanes and the bus/special lanes are data points that are strongly interconnected. Just imagine yourself as a data user: When there is no information about bus lanes, you must assume that the given lanes are for general traffic to do anything useful with this information. (Because we don't tag neither the absence of bus lanes nor specifically that lanes are for general traffic.) This has nothing to do with misinterpretation of the tag.

I hope you understand this better now.

---

There are a few cases in OSM where data is more or less strongly interconnected. From the top of my head,

• width on roads is strongly interconnected with traffic lanes, shoulder, parking lanes and bicycle lanes because it specifies the curb-to-curb-width. So, calculating the actually usable width requires knowing what else is there between the curbs
• building:levels and roof:levels because together they add up to the total building:height

[Discostu36]

I see your point, thank you for the detailed explanations. But I don't think that routing software is intepreting the lanes tag in the way that you describe, so I don't think that the incompleteness of the data will lead to incorrect routing. So in my opinion it is better to add the data incompletely than not at all.

[matkoniecz]

But I don't think that routing software is intepreting the lanes tag in the way that you describe

For example software with lane assist WILL recommend to switch to right lane before turning right if it is unaware that right lane is bus-only.

[Discostu36]

I was under the impression that it does that only if it is tagged as a turn lane. But that might depend on the router.

[1ec5]

I reckon that the current wording can be misinterpreted to exclude bus lanes, so it is true that the wording should be improved. I wonder, in normal US-English, would "lanes" include the emergency breakdown (aka shoulder) lane? What would you say, @1ec5 ?

The current wording definitely excludes bus lanes and emergency breakdown lanes in probably every dialect of English.

In American English, the usual term for lanes would be “travel lanes”:

• through lanes + turn lanes = travel lanes
• travel lanes + buffer + bike lane + street parking + hard shoulder = roadway
• roadway + curb + soft shoulder + verge/berm/tree lawn + sidewalk + greenspace + noise barrier = right of way

/ref https://community.openstreetmap.org/t/pedestrian-lane-on-the-road/97086/46

[1ec5]

For example software with lane assist WILL recommend to switch to right lane before turning right if it is unaware that right lane is bus-only.

I was under the impression that it does that only if it is tagged as a turn lane. But that might depend on the router.

The current generation of OSM-based routers only considers the turn:lanes tag of the way immediately preceding the intersection (possibly validating it against lanes). This is much less sophisticated than non-OSM-based routers, which do warn in advance about lane changes.

The OSM ecosystem was held back for years by the state of limbo surrounding the transit proposal and lack of a suitable tagging scheme to express lane connectivity. By the time the connectivity relation type was approved, companies like Mapbox and Mapzen had already moved on from their efforts to map for navigation and maximize usage of OSM tagging in routing. But I’ve spoken to a number of routing engineers who believe the placement/change:lanes/connectivity scheme would be workable for improved lane guidance, if only they could be confident in good coverage of these tags.

[BalooUriza]

there's also the problem that lanes=* shouldn't exclude single-track vehicles because it creates bigger problems than it solves by doing so.

On Fri, Sep 8, 2023, 04:41 Tobias Zwick @.***> wrote:

Most correct would be "two-tracked vehicle traffic lanes" (i.e. excluding lanes for motorcycles, but also excluding shoulder lanes), but this is the kind of officialese I'd want to avoid in this app. The app shall speak normal English with the users. I figure it used to ask "What's the number of lanes" before someone pointed out that it could be misinterpreted to include bicycle lanes.

I reckon that the current wording can be misinterpreted to exclude bus lanes, so it is true that the wording should be improved. I wonder, in normal US-English, would "lanes" include the emergency breakdown (aka shoulder) lane? What would you say, @1ec5 https://github.com/1ec5 ?

— Reply to this email directly, view it on GitHub https://github.com/streetcomplete/StreetComplete/issues/5240#issuecomment-1711380339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWDFBWFECUTUI66U5SBA2DXZLR3HANCNFSM6AAAAAA4P3TPNY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[matkoniecz]

This is not a correct place to redefine widely used tag, even if that would be possible at all.

(silencing this issue for myself)