Would you consider outputting OSM's hov:lanes and hov:minimum as raw Text on MapdOut, the way conditionalSpeedLimit passes its tag through untouched?
The reason for raw rather than parsed: whether an HOV lane is usable depends on occupancy, tolling and local rules, none of which mapd should have to reason about. Your note on the conditional speed limit work says it best, that the tag is output so forks can evaluate what mapd does not handle itself. This is the same situation, and it keeps the ask to one Text field with no lane indexing in your code.
What it is for: my fork suggests lane changes to pass slower traffic, and today nothing in it knows an express lane exists. The leftmost lane is exactly where a pass goes.
Format, from 573 tagged ways on I-15 in Utah:
hov:lanes = "designated||||" 172 hov:minimum present on all 573
"designated|||" 157 pipe count always matches lanes
"designated|||||" 149
"designated||||||" 92
designated is the first entry on every single one, so where the tag exists the HOV lane is the leftmost lane.
Coverage, measured along the whole corridor rather than one metro, because I got this wrong once already in another issue here:
I-15 Utah 1269 ways 45%
I-15 Arizona/Nevada 500 ways 22%
I-15 California 544 ways 0%
Worldwide, taginfo puts hov:lanes at 19,306 objects and hov:minimum at 11,419, so this is a US-and-Canada tag rather than a common one. lanes:hov is 212 objects and not worth reading.
Two honest caveats, since they bound what this buys you:
The California zero is not missing data. There the HOV lane is mapped as its own separate carriageway, and I measured 419 of 501 bare-hov ways in the LA basin carrying only 1 or 2 lanes. So hov:lanes on the matched way genuinely does not describe those roads, and exposing it would not help a consumer there. It helps where HOV is a lane inside the main carriageway, which is the Utah and Nevada pattern.
And this is squarely optional for you. It is a modest tag, in one region, and I would put it behind the overtaking work I mentioned in the other issue if you are choosing.
Would you consider outputting OSM's
hov:lanesandhov:minimumas raw Text onMapdOut, the wayconditionalSpeedLimitpasses its tag through untouched?The reason for raw rather than parsed: whether an HOV lane is usable depends on occupancy, tolling and local rules, none of which mapd should have to reason about. Your note on the conditional speed limit work says it best, that the tag is output so forks can evaluate what mapd does not handle itself. This is the same situation, and it keeps the ask to one Text field with no lane indexing in your code.
What it is for: my fork suggests lane changes to pass slower traffic, and today nothing in it knows an express lane exists. The leftmost lane is exactly where a pass goes.
Format, from 573 tagged ways on I-15 in Utah:
designatedis the first entry on every single one, so where the tag exists the HOV lane is the leftmost lane.Coverage, measured along the whole corridor rather than one metro, because I got this wrong once already in another issue here:
Worldwide, taginfo puts
hov:lanesat 19,306 objects andhov:minimumat 11,419, so this is a US-and-Canada tag rather than a common one.lanes:hovis 212 objects and not worth reading.Two honest caveats, since they bound what this buys you:
The California zero is not missing data. There the HOV lane is mapped as its own separate carriageway, and I measured 419 of 501 bare-
hovways in the LA basin carrying only 1 or 2 lanes. Sohov:laneson the matched way genuinely does not describe those roads, and exposing it would not help a consumer there. It helps where HOV is a lane inside the main carriageway, which is the Utah and Nevada pattern.And this is squarely optional for you. It is a modest tag, in one region, and I would put it behind the
overtakingwork I mentioned in the other issue if you are choosing.