HOV lanes
According to wiki, hov=lane
is
“Deprecated and nonstandard. If seen on a way, this value should be removed; instead,
hov:lanes=*
is the preferred tagging for HOV access restrictions per lane.”
This makes sense as with this value, it’s not clear which lanes require HOV. There were ~8k road segments with the value, all in the US. I’ve systematically replaced them with the more specific hov:lanes
, here’s a history graph: https://taghistory.raifer.tech/?#***/hov/lane. Some of the ways already had hov:lanes
, so I removed hov=lane
; the majority had a comment in note:lanes
like “left lane is hov” (probably from an import), so I used it to set the lanes; and for the rest, I checked the images (Bing/Mapbox/Mapillary) to set the correct lanes. All the changes were done manually (often in bulk).
One more complicated case was in Alexandria, VA where two streets have their right lanes designated to HOV during certain times. Mapillary allowed me to update those correctly with a tag like hov:lanes:forward:conditional = ||designated @ (Mo-Fr 16:00-18:00)
: osm.org/changeset/137988567.
Contraflow HOV lanes near Boston
The last 80 segments are the most complicated yet. They are for a part of I-93 south of Boston, MA: https://overpass-turbo.eu/s/1wXB. The complication comes from this: note:lanes = during rush hours, 5 lanes (left one hov) in peak direction and 3 in off-peak direction
. This is confirmed by Southeast Expressway HOV lane, whereas Boston I-93 HOV Lane has an image of it.
I’ve mapped the permanent barriers between the directions in osm.org/changeset/138024161.
I see two ways of mapping the HOV lane:
As a separate way along the interstate
but in the opposite direction. Even though it’s one lane of the already mapped road (in the opposite direction), there is always a physical separation (present when the lane is open), so it makes sense to map it separately; also there is no interaction of these two directions. Tagging is simpler with this approach: