Yes indeed, but what should be the lanes tag?
Oh sorry I misread your message.
The wiki page Key:lanes - OpenStreetMap Wiki says that âlanes dedicated and marked for parkingâ should be excluded from the lanes count.
Yes, this looks like a typical case of conditional tagging to me. Which value is used as the default (i.e. for lanes/lanes:forward etc.) is a matter of taste - some use the value that applies âfor the longest timeâ, some use the value that applies for the longest time during the day, some use the most conservative (i.e. smallest) value, always assuming that evaluators may only consider the default but not the conditional value.
The difference is in the first you only have lanes=2 on the road, ââ. In the second you have 4 lanes on the road ââââ. In the first if no one has parked, it doesnât then create two lanes of traffic travelling in each direction, itâs still only one in each direction.
To give you another example, here you have marked lanes, lanes=2 but the parking=lane is outside the traffic lane (you canât drive in it).
Without parking=traffic_lane it canât be determined if the parking is within the lane=* count or outside of it.
Lanes dedicated and marked for [only] parking should be excluded, but traffic lanes which you can park in or drive in should be included in the lanes count.
You should use parking:side:conditional but regardless you still need a lane or traffic_lane value for that conditional.
It might be a regional thing, but because of the separation by a continuous white line, this is a shoulder for me, and not a lane.
According to the wiki, lanes dedicated for parking (meaning: forbidden to drive on) are excluded from the lanes=* count. The only open problem I can see is how to tag these dedicated parking lanes, because they are not parking:<side>=lane, as this is meant for parking that takes up space on the drivable carriageway itself. Iâve tagged them as street_side, but if I wanted to be nitpicking, thatâs not 100% correct.
However, I agree with @Supaplex030 that none of the 2 pictures provided are a candidate for such. Both are parking:both=lane, because the parked cars take up space on the lane you are allowed to drive on. Your pictures are actually very good examples of this. And yes, this will always mean that with more than 1 lane in each direction, people will have to change lanes to drive around them, and with no markings or 2 lanes in total, sometimes even have to wait to let another car pass.
You said âstreets where parking is allowed in the lane most of the timeâ, which doesnât sound like they were dedicated for parking. Maybe itâs a misunderstanding, but âdedicated for parkingâ means âyou can park there, but you are not allowed to drive thereâ to me. Maybe some pictures would help.
Yeah Iâd call that the shoulder since itâs outside the normal traffic lane. StreetComplete is missing this option so they get included in lane a bit.
I thought StreetComplete would put them on_kerb instead. But thatâs a completely different topic. Just because SC doesnât support that value (other than ignoring it), doesnât mean itâs wrong. But I can see why some people would reason that a dedicated parking lane, and a shoulder are pretty much the same thin.
lanes=2 with parking=lane outside the traffic lane, but not in a shoulder or otherwise marked parking area.
lanes=2 (two traffic lanes), but left parking outside of the traffic lanes but still within the road carraigeway, and right parking in the shoulder/marked area.
My point is that currently parking=lane is ambiguous, it could be this example where the parking is outside the traffic lane or it could be my second example at Tagging lanes that you can park or drive in - #16 by aharvey where itâs inside the traffic lane. Neither are parking=shoulder, and both per current documentation should be parking=lane, with lanes:forward=2. If we defined parking=lane as outside the traffic lane (lanes count), and parking=traffic_lane as within the traffic lane (lanes count) it would resolve the ambiguity.
1 Like
I donât see where this is a separate parking lane outside the traffic lane. Itâs just 2 very wide lanes, so usually, you wouldnât have to leave your lane in order to avoid the parking cars.
I think we have a misunderstanding what âoutside the traffic lanesâ means. You seem to interpreting this as âparking cars donât block other carsâ, but that is not the definition, and for several reasons:
Whether a parked car blocks another vehicle depends on the width of the road, the width of the parked vehicle, and the width of the driving vehicle. If you ride on a bike, and thereâs enough space next to a parked car, to pass by without having to change lanes, then it would be a different situation to a part of the carriageway reserved for parking cars and blocked for traffic.
So from your picture, the left side is regular parking:left=lane, but the right side has a dedicated parking lane, because you are not allowed to drive on it if there are no parked card. If this would constitute as parking:right=shoulder, parking:right=street_side, parking:right=on_kerb (thatâs what SC suggests), or something like parking:right=parking_lane, is something that @Supaplex030 can probably answer.
In this specific location I think the paint has just worn off and they havenât re-painted, but regardless this situation could occur.
What youâre saying is you really see the left parking as part of the lane, a really wide lane and therefore itâs the width of the lane that determines if traffic is blocked by parked cars. You also need to be absolutely sure that anytime there is a line or other marking for the parking area you donât use parking=lane.
That would make it very hard for both mappers and data consumers. Mappers would need to tag lane measurements and data consumers have to make some assumptions of what and fit. While itâs good to tag lane widths, we should in parallel have a way to say if parking=* impedes the flow of the traffic or not.
Also this example on the wiki for parking=lane you would then need to ensure you tag the lane width including the parking areas (which I donât think it right, since they arenât areas through traffic would drive on).
Correct. If there were parked motorcycles or bicycles, we probably wouldnât have this discussion, right?
Only if parking=lane was the wrong thing to use. One might argue that you can also tag this as parking:right=lane with parking:right:markings=yes. I havenât encountered these yet, but thatâs how Iâd personally tag them on a second thought. As I said, @Supaplex030 can probably chime in here.
Your point of view is very car-centric. Whether parking impedes the flow of traffic depends on whatâs parked and whatâs being blocked. My bicycle? Nope. My motorcycle? Maybe. My bicycle with a trailer? Probably. Depends on how wide it is.
The width of the street is the only objective way to determine whether parked vehicles would or would not block the routed vehicle. And given the satellite data we have available, itâs a very easy measurement to add.
Yes and no. Generally yes, but the street in the example is a oneway street with only 1 lane. Parking must not block the flow of traffic by definition. But I find this a really bad example myself.
Imho you canât or shouldnât tag lane widths, if there are no markings or other demarcations. But you can derive the width of each part of the road by interpreting the given tags.
Easiest case:
lanes=2
parking:both=lane
parking:both:orientation=parallel
width=10
Optionally, further details are possible:
parking:left:markings=no
parking:right:markings=yes
parking:right:width=2
width:lanes:forward=3
Take the width of the carriageway, subtract the width of the parking lanes (in Germany, for example, you can assume a default of 2 to 2.2 m for parallel parking, if unmarked or not specified explicitely), since there are no cycle lanes, shoulders, etc., you donât have to subtract anything else and get a usable width of 6 meters, i.e. 3 per lane. (It would even be possible to specify this explicitly with width:effective, see also Key:width - OpenStreetMap Wiki).
For the other example,
just tag
parking:both=lane
parking:both:orientation=parallel
parking:both:markings=yes
width=7.5
and you can derive an effective usable with of ~3.5 m. Alternatively, the parking lane widths could also be specified exactly, as they are marked.
(All width values estimated â you can measure them precisely on the aerial image.)
Of course, this becomes more complicated if parking is only allowed at night on a lane that is used as a traffic lane during the day. Or if there are only a few vehicles and you have to decide whether you count a lane as a traffic or a parking lane. But if the physical layout or conditional restrictions are mapped correctly, everything can be evaluated precisely.
We evaluate such taggings for the Berlin StraĂenraumkarte, for example.
The problems tend to lie in incomplete tags or poorly/undocumented standards (for example, the question of what the lane width refers to was unclear for a long time), but this can be discussed and clarified. The open question at this point could be, for example, when does a lane count as a traffic lane if it is only very rarely used for parking?
This is how Iâd actually map it too, but again this demonstraits my point exactly, a renderer will draw space for the parked cars, and space for 2 lanes of traffic to drive in.
But in my other examples where the parking is within the traffic lane, we must tag something differently so the renderer will draw the park cars within the tagged lanes=* count.
Which renderer does actually render street parking? CuriousâŚ
My one 
(see showcase above). Or A/B Street is also rendering parking lanes.
Thats the point: If there are parked cars, itâs not a lane in the sense of the lane count, itâs just a parking lane.
Just out of curiosity, would you call this abomination parking:right=lane as well?
It used to be a separate bus lane, but had to be removed, because of some regulations, and now itâs only for parked cars.
It would be a bit tricky to add widths to the lane(s) 
My whole point is that in some scenarios there are parked cars and it is a lane in the sense of the lane count. I refer back to my original post, lanes=4, parking=lane but the parking=lane is within the lanes count. You need to render those parked cars in the outer two lanes of the four lanes, and not outside the 4 lanes. A parking lane outside the lanes count is not a lane youâd coast down to travel along the road, but one inside the lane count you would.
Think of it less as a parking lane and more as you can park in the lane, hence why I suggested parking=traffic_lane.
1 Like
Why not? Itâs on the carriageway and itâs even marked. The question might rather be what width to specify for the parking lane: The marked width and possibly a buffer:right for the bicycle lane, or the entire width right of the cycle lane because most cars are wider than the fairly narrow markings anyway?
I got your point, but as said before: The common interpretation of lanes in OSM (in my perception) is that a parking lane and a driving lane are totally mutually exclusive. Because even if there are only a few cars there, this means that the lane is not generally and continuously usable for traffic. For example, the maximum possible traffic flow in heavy traffic is not the same as expected for 2 lanes in each direction. Maybe what you are looking for is some kind of tagging for parking lane âdensityââŚ?
I agree a parking lane and driving/traffic lane are mutually exclusive. You canât drive in a parking lane, itâs not designed for that, likely not legal either. Especially those marked with paint.
But you can park in a driving/traffic lane and block the whole driving/traffic lane, if parking signage permits this. In this case, itâs no longer what I would call a parking lane in the OSM sense, hence my suggestion parking=traffic_lane.
It really depends, but thatâs the point, data consumers modelling traffic flow can then say well you have lanes=2 but one of those lanes may have cars parked so really letâs treat it as lanes=1 for our traffic analysis. But still at the same time, a renderer knows to draw 2 lanes and draw parked cars inside one of those lanes.
Nope Iâm just looking for a tag like parking=traffic_lane to say there is parking available here and the space it takes up is inside the lanes=* count not outside it (which parking=lane assumes).
I think itâs best if I can try to get as many different scenarios on the wiki pages as examples, at least thatâs a start.
Well ⌠my issue is that I would describe it like this:
lanes=2
lanes:forward=1
vehicle:lanes:forward=yes|no
bicyle:lanes:forward=no|designated
width:lanes=5|3.2|2.2
You cannot add with the the actual traffic lane, without moving the bicycle lane to the outside. You could add the 2.5 m width of the parking lane to the bicycle lane, but we all know that parking on the bicycle lane is forbidden, and so is riding your bike on the parking lane. Either way, itâs a separate lane. The one thing weâre missing is something like parking:lanes:forward=no|no|designated, so can then say width:lanes=5|3.2|2.2|2.5. Back then, I tagged it as street side parking, but iâm unhappy. Can you suggest a full mapping for this one?
My interpretation has always been that parking=lane is always on a lane that is counted in lanes=*. Whether you can continue to drive on that lane without having to drive around parked cars depends on
- Whether you are a driving a car or riding a bike
- How wide the lane is
Otherwise, a oneway=yes + lanes=1 + parking:right=lane would mean that you canât get through.