During another discussion (1, 2), differences on tagging the number of traffic lanes have become apparent. May I ask you for a brief opinion on which value for lanes=* you would tag in the following situation?(An urban main road; oneway, as it is one direction of a dual carriageway; with on-street parking on the right side of the street at any time; OSM way/1133296877).
(There is already a similar poll in one of the discussion threads, but it is somewhat buried there. However, as this question is, in my opinion, an essential one for mapping and interpreting OSM data, I would like to bring it up here for a wider audience.)
I voted 2, but in my opinion it could be 3 as well. It depends on the regular use of the parking lane / the usability of the far right lane to drive on.
If this was a street which has parking cars only at special occasions (maybe it is close to some event venue happening only few times a year), so most of the time all three lanes were free to drive, I would tag 3.
I voted 3 but to be honest I don’t have the local knowledge to say either way.
If one day there were no cars parked on this road, would you expect to have 3 cards side by side driving along this road? Would the car on the right be in the wrong for driving on the parking area?
To me if no cars were parked, and then it’s expected for traffic to use all 3 lanes to drive in, then lanes=3, or if it’s expected that even without any cars parked you’d only drive in the left 2 lanes, then lanes=2.
Another way to think of it is typically slow cars would keep to the right in counties where you drive on the right and keep to the left in countries where you drive on the left. So if no cars were parked on this road one day, would a slow driver drive down the middle lane, or the right lane (I’m assuming this is a drive on the right country)?
lanes=* is as it is defined a measure of how much traffic a road can take and not about the width or actual number of lanes. If most of the time two lanes are free for driving, lanes=2 would be correct.
Use the *:lanes syntax to tag the actual number of lanes, their width and their usage.
The far right lane can’t be driven in at any time, as parking is allowed at any time and, in densely populated urban area, is used for parking at any time. I clearified that in the description.
If the city government would ban car parking or a magician would come along and make all parked cars disappear, a slow car would drive in the rightmost (then third) lane. (But I think both scenarios are equally unlikely here.)
That it is unfortunate how we count lanes in general and use a different scale here than for :lanes is another matter. Nevertheless, the definition of lanes=* as the number of lanes usable for (flowing?) motorized, multi-track traffic results in a coherent concept that is one of the most widely used (and perhaps evaluated) tags. A simple clarification that the count refers to moving traffic would therefore be an easily achievable added value for the OSM universe.
I would tag 3.
Reasoning is indeed the magician that gets rid of all cars, then it is legal to use the lane with any regular motor vehicle.
If there were signage making it a parking strip, or a solid line, or anything else, I’d tag 2, since it is vusually and legally different.
(Same goes for parking, and the either side only tag. Its legal to park on both sides, but not at the same time.)
I do agree that an ambiguous tag is not (as) useful.
The difference is tagging what’s physically there, and what’s usually usable.
In the same vein you can argue for a need to differnetiate tagging parking on either side, vs. a singular side where people usually park.
This implies that the rightmost lane is unusable when there are parked cars, because the remaining space next to a parked car wouldn’t be enough for a car to drive there. Given that it’s 3.2m, it’s up to the router to decide, whether the remaining space is enough for a bicycle or an e-scooter to ride there (if we ignore that cycleway in the given example). The only thing I can’t tag, is how many cars are usually parked there.
But what we should be comparing is the full tagging, including parking and lane-tags, for this picture. The current tagging seems to be (simplified)
How is a router supposed to know that cars parked here are actually on a completely separate lane, which you didn’t map?
If you want routers to assume that parking:right=lanenever blocks the flow of traffic, because you will have taken this into account with your lanes=*-tagging, this also means that you will always have to tag lanes=*, even if there are no lane markings. I’m not sure whether I like this.
It would also mean that if cars are only regularly parked on that lane at a given time (let’s say only during the day), then you’d have to work with lanes:conditional, because the number of lanes would vary throughout the day by that logic.
If people want to model lanes blocked by parked cars, then we need an agreed way of modelling this. Just reducing the lanes=* count doesn’t say anything about a third lane completely blocked by cars.
In this locality, how does a motorist know that the lane is given over to parking if, say, they’re the first one to arrive in the morning? Over here in the U.S., you can almost always tell by parking signs or meters placed every few stalls. The lane is usually set off by a road marking that looks different than the usual lane divider, but cities use the lane divider markings if the lane can turn into a normal traffic lane during rush hour or off hours. I’ve used lanes:conditional=* for those variable-operation parking lanes, though it’s a bit tedious.
Mammi71
(One feature, Six mappers and still More ways to map it)
10
In the example shown: from the German road traffic regulations. This only regulates where parking is prohibited or restricted. If parking is not restricted or prohibited by law/regulation or traffic signs, you may park on the right-hand edge of the carriageway.
So as long as no one has decided to avail themselves of that rule and park there, it’s a normal traffic lane, regardless of the time of day? I see why this case is contentious.
Off the top of my head, the closest analogy where I’m from is that delivery trucks are often allowed to double-park to make a delivery, blocking a traffic lane. But we don’t map this phenomenon at all, even though it’s so prevalent in some places that it was the subject of a wonderful children’s book.
Many school parking lots are marked for both cars and school buses, with overlapping markings, and some have baseball diamonds and marching band practice fields (which resemble American football gridirons) marked on top of that, all to be used at different times of day, but not according to a set schedule.
I map most of these things as overlapping features, and technically the capacity=* of the parking lot double-counts some of the spaces as a result. Unfortunately, in this case, mapping the street parking as a separate feature would make it more difficult for data consumers to detect the relationship between the lane’s two uses.
Off the top of my head, the closest analogy where I’m from is that delivery trucks are often allowed to double-park to make a delivery, blocking a traffic lane. But we don’t map this phenomenon at all, even though it’s so prevalent in some places that it was the subject of a wonderful children’s book.
around here, while it isn’t actually allowed afaik, it is customary at some spots and not limited to delivery vehicles, but we not map it either, although it has significant influence on the lane count during the day (or night, depending on the site).
I’m surprised that the scenario in the original post is even under consideration. Germany is quite literally the home of “Don’t map local legislation” sentiment. Given that there are no markings or signs, one would think this relation is sufficient for data consumers to infer the street parking along the right-hand side of this street. Ergo, lanes=3 with a big country-sized asterisk.
I think that’s sums things up, in your examples these lanes always have cars parked, so in practice they can never be used as traffic lanes, so you see them as dedicated parking lanes not really as traffic lanes therefore you don’t count them in lanes=, and instead mark them as parking=lane. In my example the parking is at times empty so you use it as a normal traffic lane in that case, if you encounter a parked car in the way, you just have to change lanes around it. So I see it as a traffic lane, that you’re allowed to park in hence include it in lanes=. I have no idea how things work in other parts of the world, so I’m not trying to tell you how your example should be mapped that’s for you to decide, I’m just saying sometimes you have a normal traffic lane that cars drive in, but also sometimes cars park in, and current tagging makes this indistinguishable from the parking=lane being outside of the traffic lanes vs inside. Hence why I suggested parking=lane as being for parking outside of the marked lanes=* count, and parking=traffic_lane as being for parking within the marked lanes=* count to allow data consumers to distinguish these two scenarios.
I don’t see any lane markings, so I wouldn’t tag lanes=* at all And it looks like 2 unmarked lanes to me, not 3. But that’s probably another topic.
Mammi71
(One feature, Six mappers and still More ways to map it)
18
I don’t see any lane markings! But I can clearly see marked parking lanes on the right and left. This is a completely different situation to the one above.
It’s a oneway street with only 1 lane and lane parking left and right. The whole street is about 7 to 7.5m wide, so you know parked cars won’t block the lane. I don’t think anyone would doubt this for a picture showing marked parking spaces/lanes
And it looks like 2 unmarked lanes to me, not 3. But that’s probably another topic.