Smart Work Zone Meeting #5 05 26 2022 - usdot-jpo-ode/wzdx GitHub Wiki

Purpose

Purpose of the meeting is to meet with subgroup members to present finalized PRs to subgroup members.

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)

  • This is the 5th and final meeting of this cycle.
  • Currently in the April and May timeline of the WZDx Device Feed Development. The PRs have been put into GitHub.
  • In June, all the PRs will be QA/QCd.
  • In July, there will be voting.
  • In August, version 4.1 of this specification will be released.
  • In September, Cycle #3 will begin for this working group.
  • After this meeting, all commenting must be done in GitHub.

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

  • Change TrafficSenor traffic metric values (measurements for speed, volume, and occupancy) from the type of the integer to number. Number is the JavaScript type for any number whether it has decimals of any length. Results in more precision than when using integers.
  • No discussion.
  • Resolves Issue #219

PR #266 – Add is_moving to FieldDeviceCoreDetails

  • This allows the producer to say optionally whether or not a field device of any type is moving as part of a mobile operation. As part of this PR, the is_moving property on the arrow board object is being deprecating because we are pointing users to use the is_moving on the field devices core details instead. This is because it’s used by all types of devices.
  • No discussion.
  • Resolves Issue #257

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

  • Change that allows feed producers to give lane-level traffic sensor data without knowing anything about the concept of road events or road events the traffic sensor may be a part of.
  • Producers can create lane level data without road events. Gives them more flexibility.
  • No discussion.
  • Resolves Issue #225

Issue #273 – Add road_direction property to FieldDeviceCoreDetails

  • Adds functionality to all field devices to allow them to optionally specify what direction of the road that they are associated with. This is done through adding an option road_direction property to the FieldDeviceCoreDetails object.
  • No discussion.
  • Resolves Issue #250

PR #292 – Add notes about HybridSign static_sign_text

  • This is a no spec change – functionally has not impact on the specifications. It adds documentation which will set us up for making a change in a future release if desired.
  • Adds notes to the HybridSign static_sign_text property indicating that it is advisable to provide this.
  • No discussion.
  • Resolves Issue #275

PR #308 – Allow specifying the sign text for a Flashing Beacon

  • Flashing Beacons are general mounted on signs.
  • Adding a new property to FB so if it is on the sign, you can provide text of the sign the beacon is mounted on.
  • No discussion.
  • Resolves Issue #295

PR #309 – Allow providing a field device without providing a road name

  • Currently in V4 of the feed it is required to provide field device information, the producers need to give at least one road name that the field device is on. This is now changing from required to optional to provide flexibility.
  • No discussion.
  • Resolves Issue #287

PR #310 – Rename SwzDeviceFeed feed and object to DeviceFeed

  • Being renamed to Device Feed.
  • No discussion.
  • Resolves Issue #242

PR #227 – Add additional values for MarkedLocationType enumeration

  • This PR was closed and replaced by two other PRs both related to Issue #244.
  • One proposes adding “ramp-closure” and “road-closure” which allows for you to use a location marker device to specify that the location markers marking the beginning of a closed road or closed ramp. See PR #312
  • The other PR proposes adding a delineator type which allows using the location marker to mark any delineation point in a road event. This covers any intermediate case and can be put on cones or barriers just to know that there’s something there in the road event. This is a general use. See PR # 311

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

  • Add a value to the MarkedLocationType enumerated type called personal device. This defined as a connected device that is worn or carried by an individual working in a work zone such as a vest or helmet.
  • This will allow producers to use that generic location marker to represent devices carried by workers.
  • No discussion.
  • This PR originates from Issue #244

PR #311 – Allow LocationMarker to mark any delineation point in a work zone

  • Add generic “delineator” value to the MarkedLocationType enumerated type.
  • No discussion.
  • Resolves Issue #244 and supersedes Issue #227

PR #312 – Allow a LocationMarker to mark the start of a road closure or ramp closure

  • Add “ramp-closure” value to the MarkedLocationType enumerated type.
  • Add “road-closure” value to the MarkedLocationType enumerated type.
  • No discussion.
  • Resolves Issue #244

PR #313 – Enable the DeviceFeed to describe temporary traffic signals

  • Most major new addition proposed this cycle.
  • Add a new device type, traffic signal, to represent traffic signals and connected temporary traffic signals.
  • Through discussion, it was clear that it is valuable to know more than just traffic signals are there. This includes information about operation mode of traffic signals. To accommodate that, a new type of field device was created which has the core details and mode.
  • Ross Sheckler: The MUTCD treats flashing beacons as a type of traffic signal. If that’s a problem to what’s being proposed here, we need to make sure there’s no conflict.
  • Jacob Brady: The co-chairs have addressed that we need to do more clarification on the flashing beacon compared to the location marker and the traffic signal. We might transition flashing beacon to be more like a sign with a flasher on it. Not as generic because then the location marker can represent the types where you’re trying to know when something is there and what it is.
  • Neil Boudreau: The terminology “warning” needs to be added and will become a completely different object. It won’t be related to a signal.
  • Dan Sprengeler: It is a supplemental device. We don’t use them standing alone, do we?
  • Neil Boudreau: No.
  • Jacob Brady: This is something to be addressed next cycle.
  • Resolves Issue #230

Issues

Ross Sheckler and Todd Foster presented the issues not moving forward and facilitated discussion.

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

  • Ross Sheckler: Add the velocity of equipment in mobile operations as an optional choice. The intention is if you know how fast the operation is moving, you can potentially predict where it will be when you get to it. This is something we foresee needing for navigation. If it has GPS technology, velocity it is heading can be taken from the GPS. Therefore, speed can be pulled out. Is this this an optional field? Do people want it? What value will we get from it?
  • Jacob Brady: Is it fairly common that the GPS chips reports velocity?
  • Jeremy: Yes, that information is free with any GPS equipment – speed and heading.
  • Jacob Brady: Then it does make sense to be able to specify it.
  • Ross Sheckler: Part of what goes with this is that most every piece of WZ equipment can potentially be moving. So this will need to be added to a variety of equipment other than traffic signals.

Issue #289 – Device On/Off

  • Ross Sheckler: We want to add an item for whether or not the device is on or off or more specifically, has the device been turned off intentionally or is it no longer in the feed. In the field, there’s enough reporting issues that there’s a fundamental difference between something not reporting and something intentionally being turned off. Once it’s off, it will eventually be removed from the feed. There’s the question about how long should you keep it in the feed designated as turned off before it is removed from the feed. There is intentional off, and parts that can remain turned on. Intentionally off can mean that the project is finished. We need to define what “off” means, but in practice, do we need to designate an item for the device if it’s been turned off/terminated?
  • Dan Sprengler: What did we do with smart arrow boards?
  • Skyler Knickerbocker: We treat the blank pattern as off. Treat the device as off, but there’s a need to say if the device is on or off. It’s not handled currently.
  • Ross Sheckler: In the actual design of battery powered equipment, this becomes an issue. If turning if off means removing the power, how do we know it’s off and didn’t just lose its battery power. We see it all the time that something won’t report for 15 minutes in a feed that’s updated minute by minute. Did it not report because battery died, cell service died, or was it turned off? AS a practice we keep the off message in the feed for one hour after it’s turned off. It gives a clear end and definition that this is potentially going to leave the feed. In the case of arrow boards, we report where they are at all times even when it is blank. That is how signals are handled too. But it has to be built in if it is going to be done.
  • Dan Sprengler: When you hit the off switch, it will report back and intentionally shut off?
  • Ross Sheckler: Yes. As you’re designing equipment, you can’t just remove power. You have to have some way of saying this was done intentionally. Otherwise there is ambiguity in the feed o why that device is missing now.
  • Toss Foster: Feed is a moment in time, and right now, it is up to each individual agency to store historical feed so they have nothing to compare it to. Once it is gone, it is gone.
  • Ross Sheckler: Right, and you don’t have acknowledgement that is over. There is no endpoint in time. Things will disappear from the feed, and we need to know why it is terminated. Consumers of feed need historical feed for comparison feed. We feed a concept of history is important for this. How do other agencies feel about this?
  • Dan Sprengler: In Iowa, we are storing the data.
  • Jacob Brady: For MassDOT Work Zone Manager, we would store the historical data as well.
  • Russel Holt: We have not used or stored any data, but I can see it be a case by case value of potentially storing it.
  • Ross Sheckler: You need to look at a project timeline. We will need more discussion in the future. I don’t think we can leave the “is off” item in the feed forever. We need more input for people who are consuming the feed on what is appropriate here.
  • Todd Foster: For the arrow boards, they have a blank display. They don’t really power off. It is a manual thing on the backend for this specific device.
  • Ross Sheckler: If the display is down, that is essentially the same as off. The interpretation of off has to be clarified. Not intentionally operating is part of this. Possibly, intentionally discontinued. In the fall, something to think about is what problems are we solving?

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

  • Ross Sheckler: Add another field for where the device is applied like an arrow board. There are several applications for arrow boards; lane closure, sweeper, etc. They do not have the same use but are the same device. There is a recommendation that we add a field to specify what the device is being applied for.
  • Juan Pava: Are there other fields that can be used to infer the application of the device?
  • Jacob Brady: For location marker, it can be inferred from marked location type. For flashing beacon, it says what the application is for. For the hybrid sign, the function is also included. This would generalize this concept or just be a place to provide additional text/information that may be useful to some consumers. It has the potential to conflict with existing functions that are built into existing types so that must be considered.
  • Todd Foster: Is this specifically for arrow boards or other device types?
  • Ross Sheckler: It could apply to work trucks –bucket truck doing utility work vs striping truck with flashing beacon. There is value in understanding extra details about the device.
  • Russell Holt: Will add comments about the in GitHub. While it technically makes sense, the public generally doesn’t want the specifics as it doesn’t matter to them.
  • Ross Sheckler: The different descriptions for arrow boards have been listed in GitHub.

Issue #263 – Adding calibration information to SwzDeviceFeed

  • Ross Sheckler: Add calibration of radars and sensors to the device feed.
  • Toss Foster: If something isn’t calibrated correctly, then there is a larger error that doesn’t meet the specification. In theory we assume that anything allowed in the feed is properly calibrated. Who is doing the calibration verification? It is outside the scope of what we are doing here.
  • Neil Boudreau: I would hope that any public agency that is specifying the use of “smart” work zone devices (ITS in the work zone) would have a requirement for calibration of the equipment to the field conditions where it is deployed.
  • Ben Fisher: The logic behind #263 in short was ore for permanent installed devices (eg roadside detector units). Agencies may have them out there calibrated at some point. Some equipment may be able to determine when it is out of calibration. Additionally, devices that get moved around during a SWZ deployment, but not calibrated again to specification. So away to help offer additional confidence in device data.

Issue #253 – Timestamps for Field Devices

  • Ross Sheckler: Adding a location and data time stamp. We have a variety of different times we record including when data was transmitted and separate timestamp for when GPS was taken, transmitted, etc. When the location was last recording is another valid one including others we may not be thinking about. There’s a reason to know the GPS was updated a few minutes ago vs two hours ago.

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

  • Todd Foster: This hasn’t been advanced much. Right now, these messages signs don’t have a way to provide this information, but it can be added as a retrofit if the message signs are in a transport mode, that information is not being gathered. This is possible, but no manufacturers that we know of are measuring these things in the transport or deployed mode. Need clarification on how transport mode is defined – even wind affects it and can make the sign go down.
  • Ben Fischer: This is more of an issue than a solution. If the device is in transit, GPS data would solve it.
  • Todd Hartnett: There have been conversations on whether the sign is facing traffic. There have been cases where it is not facing traffic but it is in deployed mode. It is technically not being used. Should this be driven by “is the sign facing traffic”?
  • Todd Foster: With arrow boards, we give direction the board is facing with a compass bearing. We might not do that with all message boards. It is certainly doable. It is an issue that does come up. Compass direction may be a future feature set we can add, but you need to know what the road direction is to know the sign direction.
  • Toss Hartnett: If it isn’t facing traffic, it isn’t effective or in use.
  • Todd Foster: This will be in a future discussed more in the next cycle, but you can comment on it on GitHub.

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

  • Neil Boudreau: Apple, Waze, Google, OMEs have their own algorithms and methodologies for how they deal with queues. But for MassDOT, we want to capture this information so WZ performance metrics data can be shared with FHWA. The WZM app that MassDOT implemented does capture some of this data. We will continue to capture this data and use it for our purposes. If we can agree upon what is captured and how it is captured, then vendors like Ross Sheckler, Todd Foster, and Todd Hartnett that are building the devices can do it the same way. This is for the next cycle.
  • Ross Sheckler: I agree with Neil. For this to be a truly valuable to the industry as a whole, we need to add value to the agency consumer. There’s no reason not to have these kinds of items as an option so that the agencies can go ahead and consume it even if not everyone uses/consumes it. It isn’t hard to add this, and it brings real value to a whole other data consumer other than auto and map consumers.
  • Todd Foster: If that data is available and you can produce it, it is good to add.
  • Dan Sprengler: Isn’t this something you’re manipulating the data you’re collecting?
  • Todd Foster: Yes.
  • Dan Sprengler: It is up to whoever is collecting the data to manipulate it.
  • Todd Foster: The goal is to standardize how we will capture this data.
  • Dan Sprengler: Vendor collects data and feeds it to you.
  • Skylar Knickerbocker: A different perspective is who would be required to do this whether it is the agency or vendor. In Iowa, we collect the data from the vendor then we calculate a lot of these metrics ourselves because we can use sensors from the vendors and our own sensors. These are combined to calculate these metrics. There is value in a more turnkey solution.
  • Todd Foster: Majority of people aren’t doing it that way across the country.
  • Skylar Knickerbocker: I agree and see the value. Technically this is based on devices but it is dependent on more of the entire work zone. If there is a vendor providing the data, we need to be strategic on how we implement this within the specification.
  • Neil Boudreau: We want there to be options for people, but we want to ensure that every state is not doing different things. Eventually FHWA will require us to do WZ performance measures.
  • Russell Holt: In favor of it because part of the DOT.

Action Items and Next Steps

  1. Last meeting of the Cycle 2.
  • All the PRs are in and to be QA/QCd.
  • Late July, voting opens.
  • Cycle 3 for DeviceFeed will begin August/September 2022.
  1. Action Items
  • Review and comment on existing WZDeviceFeed issues on GitHub related to the Work Zone Device Feed is very encouraged.
  • Continue to review and comment on WZDeviceFeed issues on Github related to the Work Zone Device Feed

Participants

  • Colorado DOT – Benjamin Acimovic*
  • iCone Products – Ross Sheckler*
  • Massachusetts DOT – Neil Boudreau*
  • Ver-Mac – Todd Foster*
  • Arizona State University – Simon Zhou
  • ATSSA – Nagham Matout
  • Austin Transportation Department – Luke Urie
  • Butterfly Junction Technologies – Ben Fisher
  • HAAS Alert – Jeremy Agulnek
  • Hill and Smith – Todd Hartnett
  • Horizon Signal – Jay Hunter
  • IBI Group – Jacob Brady
  • IBI Group – Michelle Boucher
  • IBI Group – Shivani Kumar
  • Illinois DOT – Peter Stresino
  • Illinois DOT – Nathan Peck
  • Illinois DOT – Alex Paoni
  • Illinois DOT – Juan Pava
  • Iowa State University – Skylar Knickerbocker
  • Iowa DOT – Sinclair Stolle
  • Iowa DOT – Dan Sprengler
  • JTI Traffic – Dick Kaman
  • Kentucky DOT – Brandon Saylor
  • Leidos – William Martin
  • Minnesota DOT – Michelle Moser
  • Pi-Lit – Adam Selevan
  • Pi-Lit – James Selevan
  • Rhode Island DOT – Russell Holt
  • The Sanborn Map Company, Inc. – John Copple
  • Texas A&M – Christopher Poe
  • Texas DOT – Rafael Riojas
  • Utah DOT – Chuck Felice
  • Volpe – Mark Mockett
  • Wanco – Tim Paulino
  • Washington DOT – Steve Haapala
  • Wisconsin DOT – Erin Schwark

*Smart Work Zone Subgroup co-chair