Recommendation for more nuanced Worker Presence data structures

[kristinvirshbo]

Issue name: “Recommendations for a more nuanced definition of Worker Presence”

Summary

It is a desired goal that Worker Presence (WP) eventually becomes a required rather than optional data element in WZDX.
The current definition of Worker Presence via the workers_present property on the RoadEvent object--which is a simple Boolean (true/false)--lacks the nuance required for data producers to feel comfortable publishing it.

Motivation

By adding more nuance and detail to how Worker Presence is expressed in the WZDX specification, data producers may become more confident in including it in their feeds.

The changes proposed to the WP data structure in this Issue were developed using input gathered through an industry-wide Work Zone Data Survey conducted by the WZDX Worker Presence subcommittee in 2020. The survey report analyzes the current state of practice for collecting, publishing, and using real-time data about worker presence in work zones, and includes input about the challenges, desires, and complexities of reporting WP.

Proposed changes

workers_present is currently a boolean value in the RoadEvent object.

A RoadEvent object contains “information that describes where, when, and what activity is taking place along a road segment.” It includes details such as start time, end time, road name, direction affected, beginning and ending milepost, type of work, etc.

This Issue suggests two major revisions to how this data type is expressed. This is an initial, high-level discussion of the proposed changes. Further feedback and comments are encouraged.

1. Allow producers to define at the data feed level how workers’ presence is defined in their jurisdiction.

A new workers-presence-definition data element should be added to the WZDxFeed object to enable data producers to express what “workers present” means in their jurisdiction. Definitions vary across the US as to what “workers presence” means, and its implications.

It is proposed that this new data element be included in the high-level WZDxFeed object to avoid unnecessary redundancy at the RoadEvent level, as the definition of WP is unlikely to be different between RoadEvents instances within a single feed.

This new data element is proposed to be an enumeration that would allow data producers to construct a definition of “worker presence” for their jurisdiction using one or more building block elements. It should include the following values, at a minimum:

• Humans physically in work zone
• Humans physically in work zone but not working
• Mobile equipment in the work zone
• Mobile equipment in the work zone but not moving
• Fixed equipment in the work zone
• Humans behind barrier
• Humans in the right of way
• ...

2. Allow producers to express additional information about the presence of workers at the RoadEvent object level.

For each individual RoadEvent, data producers should be able to explain in more detail what is meant when it is expressed that workers are present in this work zone, including how that information was collected.

The following changes and additions are proposed at the RoadEvent level.

2.1 Modify the workers_present data element from a boolean to an enumeration that allows the following values:

• true
• false
• unknown

2.2 Add an optional Workers_Presence_Source data element to RoadEvent to describe the source of the WP data. It should include, at a minimum, the following values:

• Camera monitoring
• Presence of arrow board
• Presence of cones
• Presence of maintenance vehicles
• Presence of smart wearables
• Worker check-in on mobile app
• Automated detection of worker by GPS-enabled mobile device
• Worker check-in by phone
• Worker check-in by radio
• ...

2.3 Add an optional Workers_Presence_Last_Confirmed data element to RoadEvent.

This date/timestamp would allow data producers to indicate when the workers’ presence was last confirmed.

2.4 Add an optional Workers_Presence_Reliability_Score data element to RoadEvent.
This would be expressed on a scale of 0-10, with 10 being the most reliable. It is an estimate of how reliable the worker presence is likely to be, from the data producer’s perspective. This concept was inspired by the Reliability Score in the Waze for Cities Traffic Data feed specification.

[natedeshmukhtowery]

These suggested additions seem like a great expansion of the initial approach to capturing worker presence using WZDx. I'd like to get the Smart Work Zone Devices subgroup to take a close look at this, specifically at 2.2, to ensure alignment with the suggested enumerations. @j-d-b please flag this for Neil and others when you get a chance? Thanks!

[j-d-b]

@kristinvirshbo the inspiration behind these proposed changes is great. I like the line about how the boolean workers_present property

lacks the nuance required for data producers to feel comfortable publishing it.

As for implementation, I have some suggestions and comments.

Task 1: Allow producers to define at the data feed level how workers’ presence is defined in their jurisdiction

• Name the new property consistently with the rest of the specification, that is, with underscores: workers_presence_definition. Also I propose for considering naming the property workers_presence_definition_method for the name, as it is more clear—that is, the method for defining workers presence.
• Instead of adding the property to the WZDxFeed object, add it to the RoadEventDataSource object. The WZDxFeed should not have new properties added directed to it as it is the GeoJSON FeatureCollection. Feed-level values should occur on the RoadEventFeedInfo object. However, as a WZDx feed can be a combination of data from many difference sources, restricting the workers presence definition method to the feed level seems limiting, thus my suggestion of adding it to the RoadEventDataSource. For another solution, see below.

Task 2: Allow producers to express additional information about the presence of workers at the RoadEvent object level

• Changing workers_present from a boolean to an enum which includes unknown seems inelegant. The "unknown" scenario is already able to be expressed by just not including the workers_present property, as it is optional.
• The definition of reliability score should be expanded—above it is too vague for a producer to know which value to use. Perhaps an enum or a concept similar to "estimated" or "verified" would be more clear. a 1-10 score is basically an enum, so we would should define what each number means.
• Instead of adding more properties to the road event that are prefixed with workers_presence, we could make a new WorkersPresence object with all the new desired properties. I think this is cleaner because:
  - We can add more workers_presence related properties easily to the new object without bloating the RoadEvent object.
  - We can drop the workers_presence prefix from each of the property names.
  - The new properties apply to the workers presence information, not to the road event, so it is more logical for them to be members of an object that describes workers presence rather than on the road event but prefix to explain they are describing additional information about the workers presence.

So the proposed changes would be:

1. Remove workers_present property from the RoadEvent object.
2. Create new WorkersPresence object (described below).
3. Add new optional property workers_presence to the RoadEvent object, the value of the property will be the new WorkersPresence object.

New WorkersPresence object

Property Name	Type	Description	Conformance
are_workers_present	Boolean	Whether or not there currently workers present in the road event space. Note this replaces/is the same as the current workers_present on the RoadEvent. For naming consistency and clarity, I advocate for the rename to "are" workers present as it is clear what to expect for the value. This matches is_architectural_change which is the other Boolean in the spec. If we make this change all booleans are is/are prefixed.	???
source	New Enum, as described above	Describes the source of the WP data	???
last_confirmed_date	Datetime	This date/timestamp would allow data producers to indicate when the workers’ presence was last confirmed.	???
reliability_score	Integer	Needs more info on how to use	???

I left all the Conformance as optional for discussion/your input.

Also, the definition_method described in Task 1 could be added to this new WorkersPresence object rather than at the feed header level. This would keep all WP info in one place.

[j-d-b]

See #73 and #79 for background on value-less optional properties.

One comment I had was regarding the restrictions property on the road event, when there are no restrictions this should be an empty array [], which is different than the restrictions property not being included which would indicate the restrictions are unknown.

This applies to workers_present as is. If the property is not included on the RoadEvent by a producer, this indicates the value is unknown.

[kristinvirshbo]

Awesome feedback, @j-d-b ! Thank you!

[brookesc4]

The car or driver should not really change behavior if there is no law change. If the presence of workers does not change the law on the roadway, the driving environment should not be changed. The item that should be talked about and flagged is the placement, removal, or modifications taking place on the roadway. Signs and lane closures do not just appear, they have to be placed and removed and at this time, workers are in the roadway to place and remove traffic control devices. After the work zone is in place, there should be no time that a person is crossing into the live lane of traffic. You will have vehicles and equipment pulling into and out of the work zone at access points, some of which could be the entire length of the project, but the actual worker is not the key factor that should change the driving requirement. In a work zone you have limited lane widths and distances to traffic control devices, the vehicle should be operating in a way to keep them safely on the roadway and outside of the work area, with or with out workers. When personal are placing and removing the closures and accessing the roadway this needs to be flagged and alerted. At these times the signs will not be correct and the pavement markings may also not be correct. This will occur at least two times on almost every project, often times more due to the nature of the construction and staging. Flagging this event is more practical and beneficial to the safety of the road user and road worker. Is it nice to know that someone is working, yes, but the vehicle and workers should not interact, they will interact at the start, end and stage changes within the work zone. The benefit to the data users does not seem to line up with the amount of effort and difficulty of the data producers, unless you are focusing on the time frames when the two will interact or cross paths.

[natedeshmukhtowery]

@brookesc4 thanks for the thoughtful feedback. I appreciate the distinction between workers alongside vs. workers in, and welcome others' thoughts on this open issue as well!

[eli104]

Regarding the comment from @brookesc4, "the vehicle should be operating in a way to keep them safely on the roadway and outside of the work area, with or without workers" is something I believe we might want to consider more deeply.

If a work zone reduces the road capacity in some way, whether by speed, lane-width, or full closure, the data should be available to notify a driver (or automated system) that there are restrictions in place that will affect their normal use of the roadway.

While there are legal implications of workers' presence during an 'infraction' (i.e. crossing into a work zone), the fact is that it likely does not matter to the driver what level of detail they are provided. The information that there is a restriction should be sufficient to slow the driver/vehicle and keep them out of the area. If they knowingly violate that restriction, they likely do so with the firm belief that they will not get caught!

So my question is: Who is this data really for?

• If it is for an agency that wants detailed records of when/whether there are people working, then that's great! The more data the better, and standardizing the record-keeping will help all participants.
• But If the goal is to influence or change the behavior of a careless driver who already ignores lane closures and reduced speed limits, I think we might be expecting too much.
• As for automated driving (Level 2, Level 3, and above), ADAS- or ADS-equipped vehicles really don't care why there is a restriction on the roadway (animate or inanimate). Their programming should avoid crossing into closed lanes or striking anything on (what is reported as) an open lane.

[davidcraig4300]

Some of this information will be used by automated vehicles (which are on the road today). Therefore, if we know that humans are on the drivable surface and not behind a barrier, this would be a great reason to hand back control of the automated vehicle to the human driver. Automated driving systems will NOT be proficient at recognizing a flag person. Even if they are holding a sign that has a stop sign on it, these are often much smaller than official stop signs and could be totally ignored by automated driving systems. So, understanding that this construction zone has an unprotected human on the drivable surface would be a key safety element.

I really like the idea of delineating what each DOT is meaning by workers present, but these different definitions should be structured in a hierarchical manor. So, understanding that workers present behind barrier is lower in severity than workers present not behind barrier but off of drivable surface, which is lower in severity than workers present on drivable surface. Each of these 3 scenarios could have different implementations to both human drivers (an alert in the cluster or no alert) and especially to automated driving systems (hand back control to the human, or stay engaged in automated driving).

[brookesc4]

@davidcraig4300 This is a really good point about the traffic regulating operation or the flagger. (Michigan offically uses traffic regulator and others use flagger, same thing but minor side note). I agree this is an item that we would want to track and be able to. Keep in mind that there is not flagging or traffic regulating allowed on the freeway at all. So for the freeway projects and locations is what I was discussing and for those the worker presents in my opinion shouldn't change the driving conditions. The focus on the freeway needs to be on the time in which conditions are changing. We often do not close the road to open and close lanes, or shift pavement markings. This time when items are moving has a lot of miss information as things are changing, its a smaller window but at these time a driver may have to cross over solid lane lines or signs may say lane closed when thigs are open or drums haven't moved yet as we set the signs, arrow board and then the drums. For removal we take down everything in reverse order, drums, arrow board and then signs. This is pretty uniform across the US.

To your point of Traffic Regulating or a Temporary Signal or Automatic Flagger device, that type of work on non-freeway routes should have its own section to call those out. When a project has Traffic Regulating it would need to be called out that way and not workers present. This is a known work type and planned and would be easy for a data producer (DOT) to share that information.

To summarize,
-workers present on the freeway - should not change the vehicle path, may change speed limit.
-Deployment of Traffic Control or Stage Changes - This would need to change the conditions of the vehicle or alert the driver to special conditions.
-Temporary Signals - vehicle should be able to talk to or connect to temporary signal

• Traffic Regulating or flagging - vehicle or driver should be alerted to look for stop slow paddle or Automated flagging devices (MUTCD section 6E.04)
• Traffic Regulating or Flagging with a pilot vehicle - there are times a DOT may have a pace car vehicle that drivers the queue thru the work zone. Not required but could be something that is used to "set a path of travel to follow" for each pass as the project is rapidly changing with this work type.

sorry for the long post but wanted to try and cover the options

[j-d-b]

Implemented in #206.