Smart Work Zone Meeting #4 2022 04 25 - usdot-jpo-ode/wzdx GitHub Wiki

Purpose

The objectives of this meeting were to review and discuss the GitHub issues and pull requests for this cycle.

Agenda

  • Timeline
  • Pull Requests (PRs)
  • Issues
  • Issues not moving forward this cycle
  • Action Items and Next Steps

Notes

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 #228 – Change traffic sensor traffic data properties from Integer to Number value type

  • Resolves Issue #219.
  • This is a backwards compatible change.
  • No discussion.

Issue #273 – Add road_direction property to FieldDeviceCoreDetails

  • Resolves Issue #250.
  • No discussion.

PR #267 – Allow lane-level traffic sensor data without a defined road event

  • Resolves Issue #225.
  • This change allows a producer to provide lane-leve traffic data without needing the ID of a defined road event.
  • No discussion.

PR #266 – Add is_moving to FieldDeviceCoreDetails

  • Resolves Issue #257.
  • Jacob Brady - The definition of is_moving proposed in PR #266 is: A yes/no value indicating if the device is actively moving (not statically placed) as part of a mobile work zone operation.
  • Arrowboards is the most obvious use case for this PR.
  • Ross Sheckler – Every GPS chip has velocity on it, therefore, knowing speed of movement allows navigation/mapping companies to guesstimate its movement.
  • Jeremy Agulnek – GPS bounce should be taken into account, because a stationary asset can record a speed over 0 mph.

PR #293 – Allow a LocationMarker to represent a device that is worn or carried by a worker

  • Originates from Issue #244.
  • No discussion.

PR #292 – Add notes about HybridSign static_sign_text

  • Resolves Issue #275.
  • HybridSign static_sign_text will be a required field in the next major release. It is advisable for a user to provide this information.
  • No discussion.

Issues

Jacob Brady, Ross Sheckler, and Neil Boudreau presented the issues and facilitated discussion.

Issue #242 – Rename SwzDeviceFeed to DeviceFeed

  • PR #TBD.
  • This change will be included in this cycle.
  • No discussion.

Issue #296 – Report the velocity of equipment in mobile-operations

  • Russell Holt – From the DOT side, how much will the forecasting and prediction really be used?
  • Ross Sheckler – Waze takes the speed of a snowplow into account for its predictions, so it certainly is relevant for private sector applications. Not sure if the public sector will be updating their feed rapidly enough for it to matter.
  • Jeremy Agulnek – HAAS Alert takes speed of moving hazards into account to determine which vehicles to alert.
  • Skylar Knickerbocker – Can we get bearing in addition to speed? Is speed alone sufficient?
  • Ross Sheckler – What is recorded off the GPS? Speed and heading are usually provided. We can include both speed and heading as optional fields.
  • Jacob Brady – Toddy Foster noted in GitHub: Predicting a maintenance vehicle’s location will not be consistently predictable because they may stop randomly or exit the freeway instead of proceeding along.
  • Ross Sheckler – All these additional fields should just be optional, in order to encourage the maximum about of data points. That will increase the amount of data we’re getting without discouraging vendors from providing data they don’t have.
  • Jacob Brady – Agrees when it is data reported from a sensor, it is coming from the device hardware, so we should provide it.
  • Skyler Knickerbocker – Is in agreement, if have data available within the feed, coming from device directly so no interpretation is needed, then we should include it in the feed.

Issue #289 – Device On/Off

  • Jacob Brady – Proposed implementation, we could add ‘off’ to the FieldDeviceStatus object, rather than adding a new on/off object. Agrees that there is value in the consumer knowing a device is ‘off’. This could apply to work zones as well. Originally not included, this field is only for devices that are ‘on’. Consumers want to know if it is ‘off’, not just disappearing from the field. Value to consumers that something is ‘done’. How long you leave something in ‘off’ status is being discussed in the WZDx feed, can use the same business rule.

  • Skylar Knickerbocker - Likes the field device option.

  • Ross Sheckler – I am curious from the agency folks, how long we should leave the ‘off’ status in the feed before we remove it from the stream? Is an hour or a day long enough before removing from the field? State DOT may need to check the field.

  • Russell Holt – I think it would be case by case, depending on what work is being performed and what device it is.

  • Skylar Knickerbocker – What about the situation where a device is still on after being returned to the yard?

  • Ross Sheckler – At iCone, we send daily device reports to the owners so they can tend to their own devices.

  • Jeremy Agulnek – Would removing ‘off’ devices from the feed could introduce more complexity to the system, from a data consumer standpoint? Location of device would not change, not updating it, removing item from field, being able to identify last version versus latest feed introduces more complexity from a data consumer perspective.

  • Ross Sheckler – We usually remove ‘off’ devices from the active feed for the privacy of clients. Once equipment is off for an hour, does not continue with reporting that device in the feed. Would have to ask our chief engineer about the complexity for that one.

  • Adam Selevan – The removal of ‘off’ devices from the feed might cause problems if a client is looking for a specific device in the work zone that has been turned off.

  • Charlie Percival – We could try using geofencing to omit devices from the feed when they leave a work zone?

  • Ross Sheckler – That is a possibility in icone system. To a similar effect, we could assign a group of devices to a project number and it could be reported as the project location updates even while in the ‘off’ status. Use case: device is in work zone but in ‘off’ status, is different from a device that physically removed from a work zone. Brought of good points that need further discussion and thought.

  • Issue #286 – Specifying application of a device such as an arrow board

  • Jacob Brady – The device feed allows this already for the flashing beacon. It has a property called ‘function’ that is restricted to a list of application values. This issue is similar to that functionality, just more generally applied to potentially any field device type.

  • Ross Sheckler – A short list of applications/uses is feasible. These will be drafted for this issue.

Issue #287 – Devices should only report facts as they are known – not interpret items such as ‘road name’

  • Ben Acimovic – State agencies and road owners need to coordinate and agree on what the ‘facts’ should be. What known facts should be reported? The same stretch of road could have different names depending on the agency involved or the base map used.
  • Jacob Brady – It should allow cases where the device feed producer doesn’t want to provide road names specifically. This can be achieved by changing the road names field to optional.
  • Neil Boudreau – Recommends the move to optional is good.
  • Jeremy Agulnek – It should be noted that Waze and their incident feed requires the street name.

Issue #295 – Add Static Text for Flashing Beacons

  • Devorah Henderson – Good idea. Different flashing beacon trailers will have specific messages, it is good to be able to collect the data.

Issue #244 – Missing Important Values for MarkedLocationType enumeration

  • No discussion.

Issue #263 – Adding calibration information to SwzDeviceFeed

  • Russ Holt – Looks like a good idea.

Issue #230 – Expand connected temporary traffic signals in SwzDevice

  • Peter Stresino – Recommends Temporary Traffic Signal or Work Zone Traffic Signal.
  • Russell Holt – From a public standpoint, ‘Temporary’ doesn’t makes much of a difference, but I can see its benefit from a DOT perspective.
  • Skylar Knickerbocker – This would mainly be for DOT use. How they convey this information to the public is up to the DOT.
  • Jacob Brady – TrafficSignal is simpler, and the description can clarify that it is for temporary signals.
  • Charlie Percival – Do we need anything documenting pre-emption in this list?
  • Adam Carreon – Mode yellow, temporary or turned off is determined through status.
  • Peter Stresino – DOT dials into the controller. General public is only concerned abut if there is a traffic signal and is it functioning.
  • Skylar Knickerbocker – Details like preemption are out of scope for what we are trying to achieve at this point.

Issue #238 – Add new options to FlashingBeaconFunction enumerated type

  • Ross Sheckler – Would a work truck with a flashing beacon count for this type, or is that a separate issue? Would it be a separate device type or a subtype of this flashing beacon or the location marker?
  • Neil Boudreau – There are a lot of work trucks that might be in a work zone, some of which may leave their lights on when they shouldn’t. I think work truck lights should be a separate issue submitted to GitHub.
  • Russell Holt – Per the MUTCD, the flashing lights on a work truck are not considered beacon devices so it would not count for this. Yes, they are part of the work zone, but they are not intended to be controlling traffic as a flashing beacon device.
  • Jacob Brady – Recommends submitting this to GitHub as a new issue. It would probably be best as a location marker type.

Issues Not Moving Forward This Cycle

Ben Acimovic presented the issues not moving forward and facilitated discussion.

Issue #253 – Timestamps for Field Devices

  • No discussion.

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

  • No discussion.

Issue #224 – Marked Location Object with road_event_id

  • No discussion.

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

  • No discussion.

Action Items and Next Steps

  1. Next meeting is scheduled for Thursday, May 26, 2022 at 2PM.
  2. Review and comment on existing WZDeviceFeed issues on GitHub related to the Work Zone Device Feed.
  3. Review PRs on GitHub that are being considered in this cycle of the feed.

Participants

  • Colorado DOT – Benjamin Acimovic*
  • iCone Products – Ross Sheckler*
  • Massachusetts DOT – Neil Boudreau*
  • Arizona DOT – Adam Carreon
  • Arizona DOT – Marty Lauber
  • ATSSA – Donna Clark
  • DKS Associates – Alan Clelland
  • General Motors – David Craig
  • HAAS Alert – Jeremy Agulnek
  • Hillsborough County – James Cullins
  • IBI Group – Jacob Brady
  • IBI Group – Michelle Boucher
  • IBI Group – David Siegel
  • Illinois DOT – Peter Stresino
  • Iowa State University – Skylar Knickerbocker
  • JTI Traffic – Bob DeCarlo
  • JTI Traffic – Charlie Percival
  • JTI Traffic – Dick Kaman
  • Leidos – Will Martin
  • Minnesota DOT – Michelle Moser
  • Ohio DOT – Stephanie Marik
  • Pennsylvania Turnpike – Albert Brulo
  • Pi-Lit – Adam Selevan
  • Pi-Lit – Daniel Selevan
  • QLynx Technologies – Devorah Henderson
  • Rhode Island DOT – Russell Holt
  • Texas A&M – Christopher Poe
  • Texas DOT – Rafael Riojas
  • Volpe – Molly Behan
  • Volpe – Mark Mockett
  • Wanco – Tim Paulino
  • Washington DOT – Steve Haapala
  • Washington DOT – Tony Leingang
  • Wisconsin DOT – Erin Schwark

*Smart Work Zone Subgroup co-chair