-
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
WZDx v4.0 #221
WZDx v4.0 #221
Conversation
to unlink from the `source` property
Modified the entrance lane and entrance ramp descriptions to better clarify what they represent.
Modify the entrance lane description to say ingress to current roadway.
Formatted road events section to display as a table. Modified the corresponding objects for each property in the "Object Properties using Enumerated Types".
Fix object link for restrictions in "Object Properties using Enumerated Types" table.
Update used by object to new work zone and detour road event for time verification
Update used by object to new work zone and detour road event for direction
Update used by object to new work zone and detour road event for event status
Update used by object to new work zone and detour road event for event type
Update used by object to new work zone and detour road event for location method
Update used by object to new work zone and detour road event for restrictions
Update used by object to new work zone and detour road event for spatial accuracy
Update used by object to new work zone and detour road event for vehicle impact
Update used by object to new work zone for type of work
update used by object to new work zone road event
Update used by object to new core details object
Updated data source to renamed FeedDataSource
Updated RoadEvent-level restriction on 121388-WB example in comprehensive linestring file
with Scenario 3 and multipoint examples
…into field-devices
I would like that, but I brought that up at a spec update co-chairs meeting (near the end of the meeting) and at that time the consensus was (which I understood) that it was another breaking change for minimal reason. However seeing that we don't want to do another major release anytime soon and the change would great greater consistency and less stuff that is only that way for historical reasons, I think we should do it. It's a trivial from a development perspective. @mark-mockett, @sknick-iastate I think if you both are for it (renaming the WZDxFeed |
Just throwing it out there but what are your thoughts on changing the restriction to |
Since the properties use the same object (the FeedInfo object), I think it is more clear to have the property name be the same for all feeds. In addition, the WZDxFeed could be expanded to include things that are not road events and then the |
@j-d-b @sknick-iastate I agree that it'd be cleaner to have each feed info property called the same thing. But I'm also reluctant to make several last-minute revisions that don't improve functionality of the spec (applies to this requiring LineString geometry for detours) |
…into v4.0-release
@j-d-b I need some help understanding what I (accidentally) did with the "Merge branch v4.0 release" commit and its reversion - I switched over to the desktop version of GitHub, and it looks like the first commit just redid all the changes that have been made since the last merge (even though they were already committed). I reverted it but now all those changes are gone. Do I revert the reversion?? |
@j-d-b should the |
…ot-jpo-ode/wzdx into v4.0-release"" This reverts commit 81aad1d.
I think the only revisions we should make right now are those that don't change the functionality of the spec! As for the specific proposal of renaming
Good thought and I'd like to continue the discussion but I think this is too major of a change to make now. Can you make an issue for this? |
@j-d-b sounds good on the MarkedLocation issue. I have a couple others written out as well but was waiting for v4.0 release to be merged so I can link to the relevant information directly. |
@mark-mockett I see you reverted the revert commit. That was the right call. It looks like the merge commit was just catching up/combining your local copy to what was new on remote since last time you were working locally. |
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.
A couple small things to resolve but generally everything is looking good.
examples/WZDxFeed/scenario3_shoulder_bidirectional_linestring_example.geojson
Show resolved
Hide resolved
…into v4.0-release
…into v4.0-release
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.
I was able to review all of the SwzDevice and most of the WZDx. Looks good to me!
WZDx v4.0
WZDx version 4.0 implements clean up and small additions in functionality to the WZDx feed and adds definitions for two new feeds, the SwzDeviceFeed and RoadRestrictionFeed. Until version 4.0, the WZDx specification defined only one feed, the WZDxFeed.
Features
some-lanes-closed-merge-left
some-lanes-closed-merge-right
all-lanes-open-shift-left
all-lanes-open-shift-right
some-lanes-closed-split
flagging
temporary-traffic-signal
lane_restriction_
prefix from its properties.units
property tounit
.parking
andmedian
to the LaneType enumerated type.SwzDeviceFeed
contains a new feature type, the FieldDeviceFeature, which contains information about a specific type of field device. The following field devices are defined in WZDx v4.0:ArrowBoard
: An electronic, connected arrow board which can display an arrow pattern to direct traffic.Camera
: A camera device deployed in the field, capable of capturing still images.DynamicMessageSign
: An electronic traffic sign deployed on the roadway, used to provide information to travelers.FlashingBeacon
: A flashing beacon light of any form (e.g. trailer-mounted, vehicle), used to indicate something or capture driver attention.HybridSign
: A hybrid sign that contains static text (e.g. on an aluminum sign) along with a single electronic message display, used to provide information to travelers.LocationMarker
: Describes any GPS-enabled ITS device that is placed at a point on a roadway to dynamically know the location of something (often the beginning or end of a work zone).TrafficSensor
: A traffic sensor deployed on a roadway which captures traffic metrics (e.g. speed, volume, occupancy) over a collection interval.workers_present
property on the WorkZoneRoadEvent object toworker_presence
; change the type from "boolean" to a new WorkerPresence object which enables providing more nuanced information about worker presence in work zones.Refactoring
RoadEventCoreDetails
via acore_details
property; update the RoadEventFeatureproperties
property to be one of the specific road events types.location_method
property from the FeedDataSource object to the WorkZoneRoadEvent object.reduced_speed_limit
property on the WorkZoneRoadEvent toreduced_speed_limit_kph
; change its type from "integer" to "number" and clarify that the value should be in kilometers per hour.lane_number
property on the Lane object.lrs_type
andlrs_url
properties on the FeedDataSource object.alternating-one-way
from the LaneStatus enumerated type.road_event_id
road_number
road_name
total_num_lanes
left-lane
right-lane
middle-lane
center-lane
right-shoulder
left-shoulder
right-second-exit-ramp
left-second-exit-ramp
right-entrance-exit-ramp
left-entrance-exit-ramp
hov-lane
alternating-flow-lane
reversible-lane
right-entrance-lane
left-entrance-lane
left-entrance-ramp
right-merging-lane
left-merging-lane
right-second-entrance-ramp
left-second-entrance-ramp
road_names
property on the RoadEventCoreDetails.id
property on the RoadEventFeature.lane
togeneral
.right-turning-lane
andleft-turning-lane
.right-exit-lane
andleft-exit-lane
.exit-lane
.right-exit-ramp
andleft-exit-ramp
.exit-ramp
.right-entrance-ramp
andleft-exit-ramp
.entrance-ramp
.entrance-lane
.location_verify_method
property on the FeedDataSource.