eli104
commented
2 years ago Hopefully, this is not too long a note:
The issue noted is the result of developer questions based on our own software which uses lane information coded from (and to) navigable map databases (such as HERE, TomTom, and others). In the noted selection (above), the navigable map data shows two travel lanes plus a breakdown lane in each direction. The passing lane DOES appear as a travel lane on each side of the roadway. This means that in the graphic above, which shows BOTH sides of the road at once, we only see 4 total lanes. But if we look at the individual sides of the road, there are three (3) travel lanes in each direction (Lanes 1, 2, and 3 appear on each side of the road).
As noted, Lane 1 is a Passing Lane, and it is normally available for travel in the "primary" direction ONLY when passing! While some might advocate for NOT including the Passing Lane as a travel lane, I would suggest that it SHOULD be included, though perhaps with a special annotation, (e.g. PL1, or Lane 1-P). This might help distinguish special purpose lanes from regular travel lanes which normally allow travel only in the primary direction. In this case, for Road Event 1, we would close "PL1", then leave open "L1" and close "L2". Then for Road Event 2, Close "PL1" and leave L1 and L2 open. So the numbering of the lanes does not change, but the additional notation helps indicate the lane use. This also means that in cases where there is a Passing area (P1) and then a No Passing area (double-yellow line), the Passing Lane (PL1) would simply disappear, leaving L1 and L2, etc. with the same numbering throughout.
While I know this goes back to the discussion of "where to start counting"... and I know no one really wants to go back to that again ;-), this may also have an effect on how other lane types are represented. For example, the Center Turn Lane noted in the Data Set ID "WZ389-SB" example should now appear as Lane 1 (see discussion: https://github.com/usdot-jpo-ode/wzdx/commit/210c004f226aefb8a908251214c80d25bbfcedd7#commitcomment-58354977). The image below is a graphic representation of what appears in the HERE map data for this location:
While there is no doubt this is a "lane," it is also a special-purpose lane and not a normal travel lane. In that example and image, we see a total of five (5) lanes across both directions of the roadway (Center Turn, Travel, Bike). The individual sides show three (3) lanes, counting the Center Turn lane as lane #1. The thought here is that the Center Turn Lane might be called "CL1" followed by Lane 1 and Lane 2. So when the Center Turn lane is no longer available, then Lane 1 and Lane 2 would remain as they are numbered. (They would only change numbering if the center turn lane disappears and a new regular travel lane is added... which often occurs near an intersection and/or a taper lane.)
IMHO, the issue is both with coding the lanes AND with being able to clearly explain/understand the lane use for both transportation specialists, AND for the motoring public who will receive this data in their navigation systems. (The end users of the coded messages we are defining). Being able to clearly align the selections with the current map and navigation providers' data is very important.
Finally, and this is probably a separate issue, there is the matter of "movable barrier" lanes: Movable Barrier lanes are often used during rush-hour to widen/narrow one direction of travel for peak usage. Movable Barrier lanes are also used for long-term and longer distance work zones where the barrier is shifted from one side of the road to the other based on where the work is ongoing (and the heavier flow of traffic expected). A direction of travel might have 4 travel lanes available in the morning, but only 3 travel lanes in the evening as the barrier is shifted. So do we re-number the available lanes (L1, L2, L3, L4 in the morning, vs. L1, L2, L3 in the evening)? Or perhaps we might consider using MB1, L2, L3, L4 in each direction... and simply close MB1 in whatever direction is appropriate as the barrier is shifted? From the standpoint of the map data, there are always four travel lanes on each side of the road... it's just a matter of where the barrier is that determines which travel lanes are open or closed at a given time.
j-d-b
This issue was created in response to the comment posted by @eli104 in https://github.com/usdot-jpo-ode/wzdx/discussions/131#discussioncomment-1508749_.
Looking over the WZDx representation of scenarios 3 and 10 in #131, I am concerned about expressing a passing lane that is primarily used by traffic in the opposite direction as
left-lane, no different from any other left lane (in WZDx v4.0, this lane would be given the typegeneral). I think this is too unclear and potentially dangerous.Example of the issue
See the following example roadway.
-- -- -- --represents a dashed yellow line, separating opposing directions or travel and allowing passing from either direction. Due to road work (shoulder closure), using the opposing lane for passing is no longer allowed:The WZDx v4.0 representation to be consistent with the examples in #131 would be:
Road Event 1 (eastbound)
Road Event 2 (westbound)
Based on this representation, there is no distinction between the passing lane and the primary travel lane. They both have the lane type
generalwhich seems confusing.Potential Solution
There are two parts to a potential solution:
no-passingwhich would allow representing that the passing lane is no longer available for use. The WZDx representation would then be:Road Event 1 (eastbound)
Road Event 2 (westbound)