-
Notifications
You must be signed in to change notification settings - Fork 61
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
Refactor LaneType enumeration to deprecate values that can be determined from other properties, such as order, status, and restrictions #147
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made some minor changes based on the PR description - please review my changes prior to merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chuehlien The deprecated values should not be removed as they are still allowable values. There isn't a way to indicate a value of an enum is deprecated in JSON Schema. There isn't a way for properties either (in JSON Schema draft 7 which we're using; there is in the newest version) but at least then I can write in the description.
Got it - thanks for clarifying this! I added the ramps/merging lanes that I had removed back in. |
Thinking about this more, as part of this cleanup it may be worthwhile to remove the "lane" suffix from many of the lane types. This suffix is implied in all cases and is already not used on This was inspired by #149 as this change would remove having to define the difference between a "ramp" and "lane" or choose one of the terms for the lane type.
The list of non-deprecated lane types would then be:
All types in v3.0 except We would also remove the connection to the TMDD (which is already on its way out) which would clean up the table and allow for consistency with the rest of the specification enumerated types. All, let me know thoughts on this. If we are going to make this kind of change, doing it sooner when we only have a few producers and are already deprecating many of the types is advisable. |
@sknick-iastate @DeraldDudley @CraigMoore-Sea check out the above proposal and let me know your thoughts. I'll wait for some feedback before making any changes to the PR |
@j-d-b, is there a goal to align these with SAE J2735 lane types (I guess this question could apply across all of WZDx, and other ITS standards)? If so, does DOT have permission from SAE to share relevant parts of their standards in this forum? Do we need permission to simply align the lexicon without sharing implementation details of the standards? If someone can answer these questions then I'm happy to provide feedback regarding alignment with J2735 (including lane types and attributes), but I only have access to published SAE standards and not WIP. |
@daylesworth it is a goal is to align with existing standards where it is logical and matches the intended use of the standard. The lane types were based on TMDD but that became less relevant as we are no longer using the lane types to describe the lane's location. I don't have access to the SAE J2735 document. If its possible for you to post the lane types here, that would be helpful. |
@j-d-b, I have a personally-licensed copy of the standard but it has a copyright notice that restricts any reproduction without permission from SAE, so I think DOT should request permission for this effort. Instructions can be found here... [https://www.sae.org/about/legal-policies?tab=4] That said, here are the key differences...
|
@daylesworth thanks for enumerating the key differences. My comments below:
I like that approach. In fact, in WZDx there are already HOV-related restrictions in the RoadRestriction enumerated type. Is there any value in the More generally, what are producers using these lane types for? I can answer for MassDOT, where the lane type string is used to render a lane graphic for human use.
Separating the allowed maneuver from the lane type is similar logic as treating the "hov" designation as a restriction rather than a lane "type". I support this as well. I'm hoping to make the lane type enumeration as minimal as possible. Many of the current lanes types could be removed and the functionality moved to either a restriction or the status. E.g.
This one might tie into being able to offer lane-level geometry, which is not something. Thus it is assumed that all lanes are parallel, which may mean crosswalk, striping don't have value here yet. I don't feel like tracked vehicle fits in as well. |
Re. access to J2735, USDOT is looking into access to the relevant sections for this PR - thanks for raising, and stay tuned! |
I feel that more discussion needs to happen regarding lane types—see #149 as well. Once we decide how we want to handle lane types in WZDx, then we can make a clear change and go with that going forward. |
The co-chairs have reviewed SAE J2735 and though we are not going to implement lane types as done in that standard, it is useful to see allowed maneuvers and restrictions like "hov" being treated separately from the lane's type. We next discussed what the value of the lane type is in WZDx—what is the utility of this field? Is it used to distinguish which modes of transportation are allowed (e.g. bike-lane, sidewalk, vehicle-lane)? Does it indicate if vehicles (e.g. cars, trucks) are allowed on it? What was clear is that there needs to be more discussion before we can propose a final solution for describing lanes. Thus this PR will address the simple changes of removing the "sides" of the roadway from the list of lane types and values that are addressed by either the lane's Thus the changes are now as follows:
In summary, this PR currently results in the following non-deprecated lane types:
|
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). It also drops 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. Then the question is whether we want to address that in WZDx at all... |
This PR resolves #137.
The changes were made following the most recent proposal in that issue, that is
Deprecateleft-lane
,right-lane
,middle-lane
,center-lane
and uselane
(which is already in the spec) insteadDeprecateleft-shoulder
,right-shoulder
and useshoulder
(which is already in the spec) insteadChange description forright-turning-lane
,left-turning-lane
to clarify the lane's position can be anywhere (specified byorder
) and that the "left" and "right" only refer to the direction of the turnChange description forright-exit-lane
,left-exit-lane
to clarify the lane's position can be anywhere (specified byorder
) that the "left" and "right" only refer to the direction of the exit. Additionally, note this lane can be a "ramp".Deprecateright-exit-ramp
,right-second-exit-ramp
,left-exit-ramp
,left-second-exit-ramp
; these are encompassed by the changes in 4.Add newright-entrance-lane
andleft-entrance-lane
types. Clarify in the to clarify the lane's position can be anywhere (specified byorder
) that the "left" and "right" only refer to the direction of ingress. Additionally, note this lane can be a "ramp"Deprecateright-entrance-ramp
,right-second-entrance-ramp
,left-entrance-ramp
,left-second-entrance-ramp
; these are encompassed by the changes in 6.Deprecateright-merging-lane
,left-merging-lane
; these can be specified by with the LaneStatus of a lane (merge-left
ormerge-right
)Edit: see below for the updated proposal based on discussion since the first draft PR was made.