-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New/updated lane types (further LaneType refactoring) #149
Comments
For reference, these are the enumerations TxDOT uses for it's lanes on highways.
|
@j-d-b "Ramp" is used generally without the need for a change in elevation. |
As long as we have the standards across the board, we should use these lane-types. The problem is enumerated types have the risk of having that one value for a DOT that does not belong (due to their own definitions) and that will break the bank and adoption of the system will suffer. I agree with @j-d-b - we should go with a standard if it exists (or) we should stay at a higher level that can accommodate every potential value as a "sub" value. The additional question to be asked here is who would be interested in this data point? I can see some decisions being made based on the lane type. |
The following is copied from #147 for reference here: Here is an incomplete proposal for even simpler lane types, for discussion:
Compared to the list in the above comment, this list drops the ability to tell the direction of egress/ingress of an exit/entrance ramp/lane from the lane type (maybe this doesn't matter) and drops the ability to tell ramp from lane. It also removes the turning lanes, which are incomplete and not too helpful anyway as there is a lot of functionality missing ("left turn only", "straight only", "right or left turns" etc.). As done in SAE J2735, perhaps the turns (what maneuvers are allowed) should not be part of the lane type and maybe we don't need to address that level of detail in WZDx. Update: Painted median was chosen instead of a generic "median" as if the median is not able to be driven on, the roadway on each side of the median should be represented with a separate road event. |
What remains for discussion before I do the implementation and PR is:
|
Not that I'm advocating for using this, necessarily, but wanted to provide the TMDD v3 LaneRoadway type. My feeling is that TMDD v3 decided to be super specific about everything and is very complicated. But, since it's a national standard, throwing it in the mix. It also unions with a "local" version which means it can contain even more than this. I'm going to leave another, separate comment.
|
|
@lynnerandolph WZDx was initially based on TMDD, see for reference the lane type enumerated type from WZDx v1.1. WZDx LaneType has moved away from TMDD the past few releases, most notably after WZDx added the Edit: see also #137, #94 and linked issues for more background. |
@lynnerandolph regarding the above, the
I think this is a bit confusing and unnecessarily specific, which is support for dropping the left/right prefix. |
Wisconsin is reviewing this and will provide some feed backs in a couple of weeks. |
I like General and Normal. The others (Travel, Main, Vehicle) don't really make sense to me. I believe our internal map terminology uses Normal, but i believe General would also work well. |
Implemented in #188. |
Lanes and lane types have been a topic of discussion in the past three WZDx development cycles. Much of the effort was focused on cleaning up the existing lane types—there is still work to be done in this realm.
In addition to cleanup, v3.0 saw the inclusion of three new lane types,
hov-lane
,center-left-turn-lane
, andreversible lane
. These were added to enable functionality that was present in previous versions.In recent subgroup discussions, many members proposed ideas for more lane types; this issue is meant to be the place to discuss those.
Some examples for consideration below:
exit-only-lane
right-turn-only-lane
left-turn-only-lane
The text was updated successfully, but these errors were encountered: