Lanes: Difficult to decide, especially for unmarked lanes

[westnordost]

unmarked lanes

I tried out the lanes quest in reality and for residential roads (with parking lanes), it turns out that for many roads it is really~ difficult to decide. And after all, the same would apply for car drivers as well, some may decide it is better to wait, some may decide it will fit. Also depends on whether you drive a Smart or a Range Rover. I'll repost here a picture posted earlier by @RubenKelevra as an example of a road that may have "1 ¾" lanes

Though I have to say, this road looks still relatively orderly, in my area, people park like monkeys, so the usable width of a road is very variable along the road, which makes it even harder to decide.

---

So in short, I am concerned about the data quality produced by asking for roads that do not have marked lanes. If it is difficult to answer, the data becomes somewhat subjective. So, I am thinking about not asking the user to estimate the number of lanes if he answered that there are no lane markings but just tag that there are no lane markings. I earlier made the argument that this data would be useful in absence of width + cycle lanes + parking lanes, but of course if it is super subjective, it is less useful.

marked lanes

Unfortunately, the problem is not even limited to roads without lane markings. I understand that the lanes tag should denote the number of usable car traffic lanes. So, no parking lanes. In this photo, there are lane markings for 2 lanes.

But on the other hand, the right lane is not usable as a full lane because it is being used as a parking lane (the no-stopping signs are only temporary because someone is moving or there is a construction site). You see on this photo that even the Smart is waiting for the Audi to pass because it doesn't fit. So, de-facto this is really a "1 ½" laned road.

The wiki is not really clear about this (AFAIK) whether to tag the usable lanes (lanes=1 or lanes=1.5?) or to tag how the road is marked (lanes=2). The latter would however conflict with the definition how unmarked lanes should be tagged.

[RubenKelevra]

Yeah that's what I've seen as well.

But on the other hand I've settled with 'does two trucks fit next to each other without damaging their mirrors when driving at the posted speed limit'

As trucks I don't mean pickups but full width semi trucks.

In this case it's super easy to decide: Either its clearly two full size lanes space or not, if not it's 1 lane where cars might be able to squeeze by.

[matkoniecz]

You see on this photo that even the Smart is waiting for the Audi to pass because it doesn't fit. So, de-facto this is really a "1 ½" laned road.

In this case I would say that it is 1 lane road with one lane on the road used as a parking lane.

[matkoniecz]

Maybe provide "hard to answer how many lanes are here" option? And in such case tag solely whatever lanes are marked?

[matkoniecz]

And we definitely need tag for case of "not two lanes, but lane=1 would be misleading, mapper is unable or unwilling to measure exact width"

Cases like "two cars may pass each other, but one of cars must move a bit to side / both drive very carefully / truck and car in opposite directions will require something tricker".

So lanes=1.5 + lane_markings=no may be needed after all.

[westnordost]

Maybe provide "hard to answer how many lanes are here" option? And in such case tag solely whatever lanes are marked?

Thing is, contribution with the app should not be hard at all.

I also posted this question on the Slack #tagging channel and on OSM de telegram. I think I'll do the following:

1. StreetComplete shall not treat lanes=1.5 etc as invalid (enough) to ask again for the lanes and overwrite that information
2. StreetComplete shall only tag lane_markings=no and not ask about lane count then (or offer lanes=1.5, but I tend towards the former option)
3. Post on the mailing list about the third picture. This is a stupid edge case which however is quite common. Here is my last post from the slack tagging discussion:

My impression is that there is already quite a consensus what is part of lanes and what not (after many discussions): ✓ only full-width lanes count (not bike lanes) ✓ special lanes (bus lanes, two way left turn lanes etc) count as long as they are full-width ✓ may be set if it is unmarked - denotes the number of usable lanes

The one thing that is difficult is whether parking lanes should count or not. The wiki currently says to this point: "Parking lanes don't count". However, there are two kinds of parking lanes which are not distinguished in OSM tagging as far as I know:

1. dedicated parking lanes with appropriate lane markings and
2. just parking cars alongside a road because parking is not forbidden

This seems relevant because as the initially posted situation # 2 shows, and also the first picture on the parking:lanes wiki page... https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg ... lanes of parking cars can eat up "normal" car-traffic lane space. So, you end up having two marked lanes, but only one usable > lane. Well, maybe I'll post this on the tagging mailing list as well (with that example picture), let's see what they think is more important, whether to tag the usable space or the space marked. (edited)

[westnordost]

https://lists.openstreetmap.org/pipermail/tagging/2020-November/056322.html

[BjornRasmussen]

I think it would be best to split the roads into three categories: 1) Roads with obvious lanes in both directions. 2) Confusing narrow two way roads that sometimes fit 2 cars, sometimes fit 1 3) Only 3 meters wide / obviously one lane.

I think that options for 2 and 3 under other answers would make sense.
2) could have something like "In between 1 and 2 lanes total" 3) could be "1 lane shared by both directions.".

These options would be available for both marked and unmarked roads.

In terms of tagging, 3) should be tagged with lanes=1 and lanes:both_ways=1 to clarify that both directions share the one lane. 2) is more tricky, since there isn't a consensus on tagging, but one of these options should work:

• lanes=1.5 + lane_markings=no
• lanes=2 + narrow=yes + lane_markings=no
• width=*

My personal favorite is the first, because it's pretty clear what it means and it would only be understood by apps that are aware of what 1.5 lanes means. In those tricky urban cases with parked cars, the road doesn't look like 1.5 lanes, but clarifying that it's "Between 1 and 2 lanes" should clarify things.

[BjornRasmussen]

In terms of whether or not lanes marked for traffic and used for parking count as lanes, I think there should be another option under "Other Answers" for "There's a lane blocked by parked cars" with an explanation of either "Treat it as if there were no parked cars there" or "Don't include that lane in the total count" depending on what people on the tagging list decide.

[westnordost]

Well as I said, I plan to remove specifying the lanes for roads that do not have lane markings because it is in many (not all, but some) cases simply too difficult that it should be imposed on StreetComplete users. The width can then later be asked when the quest for that is implemented.

In case of roads that have x number of marked lanes but some of those lanes are (partly) occupied with parking cars, I hope the discussion turns out in a way that there can be a consensus that the lanes key really specifies the number of lanes as marked on the road. It would make recording the data much easier cause the users can simply answer what they see is marked rather than pondering whether parking cars are blocking enough of the road to consider it one lane less. Whether or not and how much parking cars occupy car traffic space can then be recorded in a separate quest, in a separate tag (parking:lane).

It is a pity that the mailing list as a medium promotes dissent rather than consent, since there is no way for people not actively engaged in a discussion to "nod" (to agree). In my last message to the mailing list thread, I tried to escape this by setting some criteria that a solution should at least fulfill. Let's see what comes out of it.

@BjornRasmussen since you are the author of the (new) lanes plugin, and thus you both visualize and tag the data, maybe you should involve yourself in this discussion as well. Also if the discussion is not heading in the wrong direction from your point of view.

[RubenKelevra]

@westnordost thanks for investing your time (again) on such a long discussion. I've read like 15 mails but don't want to continue actually.

I think we got hung up on details here, let's keep it simple.

There's an example in the wiki which looks basically like your picture shared, but with parked cars on both sides. The wiki states the lanes with parked cars have to be considered traffic lanes and counted.

About excluding lanes as parking lanes it states, that they have to be not counted if they are "dedicated and marked for parking". Which is not the case with curb parking. It's a normal lanes you would use when there are noone parked here.

A parking lane isn't open for traffic when noone is parked there.

So even when there are cars on a lane it has to be considered 'open for traffic', regardless if there's a center line or not.

---

For roads without lanes it does not state that we should avoid to tag them with lanes. It even gives an example that some 4 lane highways might have no lane markings and that such a detail should be added with explicit tagging in a different tag than lane instead of misuse lane with some weird values like 1.5, none or 0. As an example tag to use the wiki states lane_markings=no.

So there's no reason given to not tag the amount of lanes of a road, when there are no lane markings. The wiki just makes aware of the fact that you shouldn't misuse the lane tag in those instances but tag the info somewhere else.

My recommendation to write 'semi-trucks' is simple: Semi trucks are pretty equally sized in width around the world, since they have to transport standard shipping containers which are 2.44m wide.

A full width lane, which should be counted as one, should be able to accommodate a semi truck. So if there are "1.5" full size lanes, we should just count it as one, since two semi trucks cannot pass each other and the wiki discourages the use of non-integer numbers.

So I would recommend to readd the 'number of lanes' on unmarked roads, since that is what the wiki describes to do.

We only need to guide our users to be able to tell the difference between a road where (small) cars can pass each other and a road where two semis can pass each other.

And that cars parked on the normal road surface should be ignored when estimating if this is a one or two (or etc) way road.

Only explicit lanes only dedicated to parking should be excluded from the 'driveable space' which is tagged in the lanes tag.

---

The width of the road on the other hand is only interesting if the road is narrower than one semi truck, so some vehicles cannot drive through it.

But still, this information needs to be collected for the full width of the road, ignoring cars parked on the side of the road (or half way up on the sidewalk). Only the drive able space counts.

---

That said it's clear that this information isn't very useful for the purpose on having a full picture of what's actually available for driving - which is the important part we like to make available to the routers.

Those data consumers are only interested in 'is there enough room on the road to drive in both directions with a large vehicle or is it too narrow to pass each other.'

So in the next step we need to collect the width of the road for one lane roads. The width doesn't matter for two lane roads since per definition two lanes means that two large vehicles can pass each other.

---

To get a full picture if the lanes on the left or right might be (partly) blocked by cars parking on them we need a parking quest which would look like the bicycle quest.

There are 3 basic types of parking which the wiki knows of:

1) parking on the road 2) parking with one set of tires on the road and one set on the sidewalk 3) parking on the sidewalk Those are tagged with:

1) parking:lane:both=parallel and parking:lane:both:parallel=on_street 2)parking:lane:both=parallel and parking:lane:left:parallel=half_on_kerb 3) parking:lane:both=parallel and parking:lane:right:parallel=on_kerb

While the third one is uninteresting from a drivable space perspective, as well as any parking lanes along the road, parking cars do increase the 'business' of the road, due to parking/unparking cars holding up the traffic flow and people starting to cross the road from between them, making the traffic flow in general slower (just my own opinion / thoughts on that).

So a parking lane/parking on street quest should probable be able to capture the 3 types of parallel parking, as well as the 'not on the active traffic lanes' parking modes 'diagonal', 'perpendicular' - since I don't think there are any countries allowing parking on the road diagonal or perpendicular.

[RubenKelevra]

Hey @westnordost please have another look on what I wrote, I feel we're adding wrong data with the current approach:

On streets with street markings but parked traffic the users might end up tagging less lanes than they are supposed to.

Why not collecting as a first step lane markings vs no lane markings on roads and skipping the lane count part.

The lane count needs a better explanation, as I first starting tagging streets wrong and only after reading through the wiki page realized that.

[westnordost]

On streets with street markings but parked traffic the users might end up tagging less lanes than they are supposed to.

Why?