Consider a mapper surveying a wide street without lane markings like this one that could fit maybe one parked car on each side and two or more cars moving past each other along the center. Assuming it is mapped with lane_markings=no:
Should the mapper add lanes=* if it is missing to such a street without lane markings?
Yes, estimating its value from observable cues (e.g. width)
No
0voters
In the same scenario:
How should the mapper handle an existing lanes=* in such a street without lane markings?
They should always remove it
They should remove it if unsourced and likely estimated from observable cues
They should remove it if unsourced, regardless of how it was set
They should preserve it, even if it was likely estimated from observable cues
They should estimate its value from observable cues and change it to match that
Just because there’s no paint on the ground doesn’t mean there aren’t still a set number of lanes. I’d suggest that unless there are signs indicating the road is a one-way street, then there’s at least one lane in each direction.
Even if the whole road bank-to-bank is, say, 3m wide? I wouldn’t.
Also, if it is significantly wider, is it 2 lanes, or 3, or 4, or 5? How do you estimate?
That is what I would suggest too. width=* is also more precise and (this is important) more verifiable.
Here in California, urban residential streets usually have no centerline mid-block, but there is a centerline near any intersection. These stub centerlines channel traffic into two lanes despite the lack of continuous marking. Motorists are expected to observe two lanes, without going down the middle of the street, unless there’s an obstruction like a standing vehicle making a delivery.
These barely marked residential streets can be five standard lanes wide, two standard lanes wide, or just barely four standard lanes wide with cars parked willy-nilly so that you worry about your side mirrors as you squeeze past opposing traffic. Some of the wider streets originally had horse-drawn streetcar lines or street-running railway lines running down the middle, now paved over. Or they used to serve as primitive one-way “mini-expressways” before they were bypassed by proper expressways and converted to two-way traffic.
I provided some examples in this earlier poll:
Regardless of the width, the traffic pattern is still the same: lanes=2. A data consumer cannot be expected to guess the number of lanes by dividing the width by a fixed factor. In the absence of explicit lanes, a data consumer might have to estimate the lanes based on the width, but it would be imprudent to estimate more than two lanes without more information. If it’s tagged with more than two lanes, I would really hesitate to remove that tag without understanding why it was placed there to begin with.
Elsewhere, I’ve encountered wide queuing areas for ferries and drive-throughs that have no lane markings per se but are obviously divided into lanes based on overhead pull-through signs. It would be a bad idea to remove lane tags based on aerial imagery without examining street-level imagery first.
Aside from the incomplete markings case mentioned above, and the wiki example (tyre tracks?), surface=concrete contraction joint is another possible basis. Maybe there are other surfaces that could too.
It should be remember widths and number of lanes aren’t always the same. Nowadays, narrower roads are encouraged to calm traffic, and reallocate street space, resulting in the minimal 5.8, 5.6, 5.5, etc m used for 2-lane, not all 6m. Another case is narrower lanes can be marked at junctions to provide more queue storage: Eg austere RHT left-turn lane (providing one is better than none), or signalized junctions (UK DMRB allows 2.5m, and 2.25m).
One of my ideas is to use lanes:unmarked= for counting unmarked number of lanes, if lanes= is to be reserved for marked, or it needs to be clarified. In fact, lane_markings= is a rather new invention. It jumped in late 2019, while both began in mid that year (independently I thought).
Furthermore, lanes:marked= + lanes:unmarked= could be used when there’s a mismatch: eg recently I encountered a turn:lanes=left|left|left;right|right continued with lanes:marked=2 only inside the junction=intersection , because it’s usually unmarked, but there’s a diverge immediately downstream of the turn for lane 1 & 2 to turn again, only lane 3 continues. There’s potential use for the parkings question as well.
Probably around the time StreetComplete started applying lane_markings=* in response to a quest about lane counting.
I wonder if there are any situations where a lane would be marked on one side but not the other, and signs etc. suggest the existence of all three lanes. I think you’re pointing to the need for a lane_markings:lanes=* that takes the same syntax as change:lanes=*.
Regardless, in practice, lane_markings=* is mostly about the centerline rather than any lane divider. That always seems to be overlooked in these discussions when we start talking about width=* as an alternative. There’s so very little lane_markings:forward=* or lane_markings:backward=* that a missing lane divider doesn’t seem like a very pressing problem.
In my region, in addition to expansion joints, it’s common to resurface individual lanes of asphalt on main streets instead of the entire street (to avoid completely blocking traffic). Repainting the markings can take time, but the different texture and visible marks left on the asphalt by the resurfacing clearly indicate where the lanes were/will be. There are also wide, paved local streets (sometimes designed to be main streets, but whose plans changed with urban growth) that lack horizontal markings or any other lane separation indication; drivers guess where to drive mainly based on the width of the road. (But the poll is broad, not about this specific case.)
For context, in Thailand many urban residential roads have no lane markings or signage and can vary widely in width, often anywhere between about 2 and <4 m.
Tagging these as lanes=1 (optionally with width=* and lanes:markings=no) helps routers recognize that these streets function as narrow single-lane roads with informal alternating flow and discourages routing through them as unofficial shortcuts.
It also helps avoid recurring edit conflicts with mappers who prefer service=alley. Locally we have reached consensus to map these streets at least as highway=residential + lanes=1 when they are narrow roads primarily providing access to residences.
I forget, did the local community ever consider oneway=alternating as well? Renderers and routers tend to pay more attention to that tag than lanes=1, since oneway=yeslanes=1 isn’t so difficult to traverse. I would still tag lanes=1 with it, since in principle a multilane oneway=alternating is also possible.
From what I remember, at the time router support for lanes=1 without oneway=yes was already well supported by routers and became the preferred approach, since many mappers were already using it to tag unmarked narrow roads.
I actually ran essentially the same poll back then and received very similar feedback. So locally we’re not looking to change anything for the foreseeable future.
For me, oneway=alternating is more appropriate for situations where the alternating flow is explicitly signed or traffic-controlled, rather than simply occurring informally on narrow streets.
I would disagree on this, especially in areas where motor cycles and tricycles are a dominant means of transportation. A “road” of a width=2.5 can easily be lanes=2 for those, but hardly lanes=1 for cars.
If a way is specifically designated and clearly marked for bicycles or tricycles/rickshaws, that is a different situation.
On unsigned roads that are typically used by four-wheel vehicles, lanes=* is generally understood to describe motor-vehicle traffic lanes.
I am describing the situation in Thailand, where this interpretation has already been established and voted on within the OpenStreetMap community. Note that I am not trying to impose this globally or restart that discussion here.
I’m with you that typical in “car-centrist, first-world” areas, lanes=* is meant for how many cars can drive there. I’m speaking mainly from my experiences in rural China, which might be different to yours in Thailand. If you leave the main road (usually wide and properly marked), the road turns into a concrete strip wide enough that two tricycles can pass. Since tricycles or even just overloaded scooters are the main mean of transportation. You hardly see actual cars on these roads, usually only if the kids come by for a visit. So this would be a highway=residentiallanes=2.
Now think this through from the data-user perspective. How should a router know that above road with lanes=2 is not like 5.5m wide, but barely can fit a SUV?
