Three of the edited ways carry lanes=3, lanes:forward=2 and lanes:reversible=1, which matches the ground truth: the span is always westbound, and only its left lane is opened to eastbound traffic during MDTA two-way operations. The other two edited ways carry only lanes=3, so nothing on them supports a reversible direction at all.
We are a routing software provider and received a customer complaint about westbound routing here. Our reading of the wiki is that oneway=reversible describes a road whose entire direction changes at set times (“tidal flow”), and that routers should not use it without knowing the schedule. Two of the three lanes never change direction, so the value does not fit. The effect on data consumers is severe: routers either refuse the way entirely or treat it as two-way, and both are wrong here.
We could not find any other way in OSM that combines oneway=reversible with lanes:reversible. Elsewhere in the US (for example the Kennedy Expressway in Chicago or Tampa’s Reversible Express Lanes) the reversible lanes are mapped as a separate way tagged oneway=reversible, usually with oneway:conditional , while the main carriageway stays oneway=yes.
The same change was made in August 2021 (changeset 109583099) and undone by two other mappers in changesets 111037831 and 119959105, because at least one westbound lane is always available and only some lanes reverse. The ways had been oneway=yes since then. The August 2026 changeset comment only mentions adding missing roads, so the change may have been unintentional.
Unless there are objections, we intend to restore oneway=yes on all five ways and keep the existing lane tags. Suggestions on how to express the contraflow hours with conditional lane tags are welcome. I will also post a link to this topic in the changeset discussion so the mapper is aware of it.
A (new) key lane:oneway would also make sense, wouldn’t it?
Or/and a specific value oneway=partial_reversible.
Strictly speaking, “the reversible lanes are mapped as a separate way” doesn’t match the usual separation of the carriageway. oneway=yes is not really right either.
A proper solution is always better that a edit war. If you revert (nothing against), then please refer to this thread.
@trial Thanks. To clarify, I was not suggesting splitting the reversible lane into a separate way here. The express-lane examples are physically separated carriageways, and I only mentioned them to show that oneway=reversible is used for a whole carriageway that reverses.
I agree oneway=yes is not a perfect description either, but together with lanes:forward=2 and lanes:reversible=1 it is the least wrong option available today, and it is what the earlier reverts settled on. A new key or value for partially reversible roads would need a proposal and support from data consumers, which is a bigger discussion than this fix.
I will wait a few days for more opinions and for the Lyft team to respond in the changeset. If we revert, I will reference this thread in the changeset comment.
oneway:lanes=* should go with oneway=no, right? Otherwise, the majority of data consumers, which don’t know about the subkey, would be biased toward only one direction, when in reality both directions operate at any given time.
@Minh_Nguyen I would argue for the opposite base value, at least for this bridge. Both directions do not operate at any given time here: the normal configuration is all three lanes westbound, and the left lane is opened to eastbound traffic only during MDTA two-way operations at peak times or incidents, at MDTA’s discretion and under their traffic control. There is no fixed schedule, so oneway:conditional=* cannot be filled in either.
With oneway=no, every consumer that does not parse oneway:lanes=* (a key with about 20 uses and no wiki page) would treat the span as two-way around the clock and send eastbound traffic onto the westbound span. With oneway=yes, the same consumers get the normal state and at worst miss the contraflow lane during two-way operations, which they could not use safely without live information anyway. That is a much safer failure mode.
oneway=reversible is the worst of the three: the wiki says routers should not route over it without knowing the schedule, so westbound traffic loses the bridge entirely. That is what triggered the complaint we received.
Our current suggestion, based on the responses, is oneway=yes as the base value, keeping lanes:forward=2 and lanes:reversible=1, plus oneway:lanes=reversible|yes|yes as @mueschel suggests for consumers that do understand per-lane tagging. For what it is worth, the existing uses of oneway:lanes=* show no convention for the base value: most have no oneway tag at all, a few have oneway=yes and one has oneway=no.
Typically we put the “most common” state into the simple tag. This way simple-minded software gets it “mostly right”. E.g. if it’s oneway during the whole day and only two-way during night hours, oneway=yes. If it’s only oneway during few hours a day, oneway=no.
Ah, so it’s basically a peak-hours contraflow lane that happens to be signal-controlled. We apparently have no documented solution for contraflow lanes, except for alternative modes of transportation such as bikes and buses.
Your explanation makes sense from a practical perspective. oneway=reversible is technically correct, but it’s more beneficial to model the contraflow lane as an exception. A clarifying note=* can help others avoid making the same mistake as the other mapper.
oneway=yes is restored on all five westbound ways (the span and its approaches).
The existing lane tags are unchanged: lanes=3,lanes:forward=2 and lanes:reversible=1 on the three ways that carry the contraflow lane.
Following @mueschel’s suggestion, those three ways now also carry oneway:lanes=reversible|yes|yes (the ways are drawn westbound, and the reversible lane is the left lane).
As @Minh_Nguyen suggested, each way has a note=* explaining why oneway=yes is kept and linking to this topic, so the next mapper does not repeat the change.
I have also left a comment on the original changeset pointing here. The Lyft team has not responded yet.
