Smart Work Zone Meeting #3 2022 03 28

Purpose

The objectives of this meeting were to discuss the outcome of the survey, review and discuss any GitHub issues, and to identify member advocates for prioritized issues.

Agenda

• Timeline
• Issues Discussion
• Priority Issues for PRs
• Action Items and Next Steps

Notes

GitHub Issues Link: https://github.com/usdot-jpo-ode/wzdx/issues

Development of Timeline of WZDeviceFeed

Michelle Boucher presented the WZDeviceFeed development timeline.

Discuss Issues (All Participants)

Jacob Brady presented the following issues and facilitated discussion.

Issue #218 – message_multi_string type for DMS of SwzDeviceFeed incompatible with NTCIP

• John Stanley – We could specify that the binary data needs to be ‘escaped’ by using the NTCIP character encoding for that data. It would still be compatible with the multi_string and any binary data we would want to include.
• Jacob Brady – As long as that’s feasible, that would be a good option because it involves minimal changes to the specification.

Issue #219 – Change TrafficSensor and TraffSensorLaneData traffic measure properties type to “number”

• PR #228.
• No questions or discussion.

Issue #242 – Rename SwzDeviceFeed to WorkZoneDeviceFeed

• Non-spec change, it is more organizational.
• General consensus: most on the call were in favor of simplifying from ‘SWZ Device Feed’ to simply “Work Zone Device Feed”. More general phrasing is better in the long-term, as work zone projects expand.
• Other ideas: “device feed” or “field device feed”
• We should be careful about generalizing too much though—if we go as far as just “Device Feed”, we should be able to flag data as part of a work zone to differentiate from non-work zone applications.
• Further discussion summary will be in the GitHub.

Issue #250 – Add road_direction to FieldDeviceCoreDetails

• PR #273.
• Dan Sprengeler – It should be clarified that road_direction indicates the route’s overall direction (NB, SB, EB, WB), not the roadway’s literal heading at a given location.
• Todd Foster – We may want to consider display direction as well.

Issue #225 – Lane level traffic sensor data restrictions

• PR #267.
• Change conformance from required to optional.
• No questions or discussion.

Issue #244 – Missing Important Values for MarkedLocationType enumeration

• Skylar Knickerbocker – It might be good to split these two out (delineator, ramp-closure) and make the wearable object its own object, for voting to be clearer when it happens.
• Ross Sheckler– For wearable, we should go along the lines of a personal device (phone, wearable personal device) that is a 1-to-1 representation for a worker.
• Jacob Brady – We can rename the object from wearable to personal device to apply more generally.
• Dan Sprengeler – It also needs to be fool proof, not a phone left in a truck.
• Jacob Brady – Is ramp-closure necessary or more confusing to be used separate from lane-closure, which already exists?
• Russell Holt – Any roadway closure is going to have a lane closure. No matter how many lanes a roadway has or the specific types of lanes present, if any part of a roadway is being closed, then there is going to be a lane closure.
• Jacob Brady – Until the lane closure location marker type is used and proven, I think it makes sense to leave it with just lane closure. When a ramp is closed, that is still a lane closure, it is just indicating the lane is closed where the device is located.
• Todd Foster – I recommend putting a summary of this discussion in GitHub for the originator of this issue to respond.

Issue #257 – Consider SwzDeviceFeed field device information used to assist in representing mobile work zones

• PR #266.
• There is consensus that it should be left optional.

Issue #253 – Timestamps for Field Devices

• This issue will not move forward during the next release cycle. There needs to be more discussion in GitHub before determining a solution for this issue.

Issue #230 – Expand connected temporary traffic signals in SwzDevice

• This issue needs more discussion before continuing.
• Members are interested in learning more about how Iowa is using this information. A separate meeting will be held between the Co-Chairs and the Iowa team to discuss further and report back to the subgroup at the April meeting.

Issue #238 – Add new options to FlashingBeaconFunction enumerated type

• Todd Foster – Is it just work zones, or work zones and other stuff? We should clarify that before we can decide the rest of this issue.
• Neil Boudreau – I don’t think it would be good for the specification to have an enumerated list that is unreasonably long. We should have the higher-profile values listed and then have an open string that someone can define further. This will encourage the user to be more involved.
• Ross Scheckler – We should add a work truck as the top value on this list. A work truck is the number one flashing beacon.
• Jacob Brady – Does a work truck value belong in this list, or under a different device category? That might need to be submitted as a new issue because it has not been discussed in detail yet.
• More discussion should be continued in GitHub. Issue #244 – Marked Location Object with road_event_id
• Co-chairs do not have a solution for this issue.
• More discussion should be continued in GitHub.

Issue #274 – Allow specifying transport or deployed position for dynamic message signs

• No vendors in the industry track this information.
• This information is not available through NTCIP.
• Sign should be blank when transporting.
• More discussion should be continued in GitHub.

Issue #275 – Consider conformance of HybridSign static text

• This field should be required.
• More discussion should be continued in GitHub.

Issue #187 – Add road event-level dynamic traffic metrics

• DOTs need this more than consumers need this.
• This issue will not be included in the next release of the device feed as more discussion is needed.
• More discussion should be continued in GitHub.

Action Items and Next Steps

1. Next meeting is scheduled for Monday, April 25th, 2022 at 2PM. The next meeting will be 90 minutes long.
2. Review and comment on existing WZDeviceFeed issues on GitHub related to the Work Zone Device Feed.
3. Create new issues on GitHub to be considered in the next version of the feed.

Participants

• Colorado DOT – Benjamin Acimovic*
• iCone Products – Ross Sheckler*
• Massachusetts DOT – Neil Boudreau*
• Ver-Mac – Todd Foster*
• Applied Concepts Inc. – Randy Jackson
• Arizona DOT – Adam Carreon
• Arizona DOT – Marty Lauber
• Connecticut DOT – Jennifer Petrario
• FHWA – Jawad Paracha
• Florida DOT – Daniel Smith
• HAAS Alert – Jeremy Agulnek
• Hill and Smith – Ivo Kushkiev
• Hill and Smith – Pete Krikelis
• Hill and Smith – Todd Hartnett
• Hillsborough County – Amos Castillo
• IBI Group – Jacob Brady
• IBI Group – Michelle Boucher
• IBI Group – David Siegel
• Illinois DOT – Juan Pava
• Iowa DOT – Dan Sprengeler
• Iowa DOT – Sinclair Stolle
• Iowa State University – Skylar Knickerbocker
• JTI Traffic – Charlie Percival
• JTI Traffic – Dick Kaman
• Kentucky Transportation – Brandon Saylor
• Texas A&M – Christopher Poe
• Texas DOT – Rafael Riojas
• The Middlesex Corporation – Daniel DeRoehn
• Minnesota DOT – Michelle Moser
• Pennsylvania Turnpike – Albert Brulo
• QLynx Technologies – Devorah Henderson
• Rhode Island DOT – Russell Holt
• Sanborn – John Copple
• SRF Consulting – John Stanley
• SRF Consulting – Mark Gallagher
• Volpe – Molly Behan
• Volpe – Nate Deshmukh-Towery
• Volpe – Mark Mockett
• Wanco – Tim Paulino
• Washington DOT – Steve Haapala
• Washington DOT – Tony Leingang
• Wisconsin DOT – Erin Schwark

*Smart Work Zone Subgroup co-chair