-
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
Utility of lane_number: time to deprecate? #153
Comments
j-d-b
added
Needs discussion
This issue needs clarification/additional discussion or is inactive
Data-content
labels
Jan 21, 2021
Every time I present the spec, I always gloss over Seeing again no new comments here, I'll move forward with the PR. |
Thumbs up. |
j-d-b
removed
the
Needs discussion
This issue needs clarification/additional discussion or is inactive
label
Jun 24, 2021
Merged
Merged
Completed in #175. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The optional
lane_number
property on the Lane object was left in the major v3.0 release as there were reservations about giving a lane with a not typically driveable lane type (e.g.shoulder
orsidewalk
) a number. For clarity and to remove connection to what individuals think of when they see "lane number", the required laneorder
property was added.order
is used as an index to identify the lanes positions (order) relative to each other. For many contributors/producers, this was the utility oflane_number
, so withorder
,lane_number
has no value. I support that conclusion and think thatlane_number
remaining in the spec just adds confusion.In summary, it is not clear that there is any utility in
lane_number
.If there are any producers or consumers who see value in
lane_number
aside from identifying the lane's position, please raise your opinions!If there is no value, the next step is to deprecate
lane_number
.The text was updated successfully, but these errors were encountered: