Mobile Work Zones

[davidcraig4300]

There is no current method of describing a mobile (moving) work zone, except for updating the position on some regular cadence and describing the work zone for that entire distance it will cover during that time-frame.

Would it be beneficial to add a couple attributes for mobile work zones: 1. the average speed that the work zone moves, 2. the time that the position was updated? For example, if there is a re-striping work zone that moves at 1mph, and the operator can only update the work zone every hour. Currently, the operator must indicated that this work zone is 1 mile long. However, if this could be annotated as a moving work zone, the operator could indicate this as a 50 meter long work zone that is moving at 1mph and was at "X" position at a certain time.

Would this be beneficial?

[sknick-iastate]

I think this would be beneficial. We have been working on using the AVL data from our maintenance vehicles to update our maintenance information to show where they are currently at. We currently are cluster the data every minute to show where they were but adding the speed would allow consumers to know how far it has potentially moved.

Some indicator of a moving operation in the spec would be beneficial in general since these operate much differently than a static work zone. Their is a maintenance enumeration in the types_of_work but I don't know if this would also be used for mobile operations.

[davidcraig4300]

Since the interest on this issue appears to be low right now, The subcommittee is recommending that this issue be tabled until the specification can be updated to include reoccurring events. Please provide input on Issue #6 Reoccurring Events.
#6

Once that issue gets solved, then this issue will be tackled.

[davidcraig4300]

Issue #6 Recurrent Events was closed on 12/16/21.

Therefore, this issue is once again a stand alone issue. Please feel free to add comments/suggestions on this issue here.

[davidcraig4300]

I was on a call this morning with an IOO. They expressed a desire for some method of providing a WZDx event for a mobile restriping activity with infrequent 2-4 times per day updates. Should this be rescoped to just cover mobile restriping to keep the scope small, vs trying to capture all mobile work activities?

[rdsheckler]

iCone is the conduit for much of the striping truck data and minute by minute data can be available. While agency reporting mechanisms may need up dating accurate and timely updates are very achievable.

[tfoster-vm]

The new SWZ Device Feed addresses this for smart/connected arrow boards with an optional field "is_moving?" (Yes or No). The option is not to be utilized for unknown. This is a start. If we need to extend this to truck mounted Message Signs, that could happen. If we want more detail, we need to decide with stakeholders what is of value. Currently we offer information for this field with our connected arrow boards and we sample the location information 6X more often to accommodate the frequent relocations. I think it would be very difficult to predict where a device will be next with high accuracy, as operations and pause and restart or switch paths.

[j-d-b]

As discussed in the February Spec Update Subgroup meeting 2022-02-23, WZDx v4.0 supports representing mobile work zones. This can be done by using two road events:

How to represent a mobile work zone in a WZDxFeed

1. Use a planned road event with estimated start and end locations to represent the extend of where the mobile work zone will be occurring within; and
2. Once work is occurring, if real-time data is available, use a shorter road event with verified locations to define where exactly the work area is.

What's missing?

What is missing is the ability to clarify that the road event representing the mobile work zone extent is different than any other planned, estimated work zone road event.

Potential changes

Below are some options for potential changes, I'm not specifically advocating for any of them at this time, but wanted to record what has been discussed:

Option 1. No change

The first option is to make no changes to the specification. This option assumes:

• Consumers don't need to know that the planned mobile work zone extent is a mobile work zone extent. It is fine for consumers to process this event the same way as any other planned even with an estimated location.
• There is no difference between the verified active work area that is moving and a verified road event that doesn't move, except for how frequently information is updated, which is already reflected in the FeedInfo or FeedDataSource update_frequency.

Option 2. Add a new value to the EventType enumerated type

Currently, EventType includes work-zone, detour, and restriction. Each directly corresponds to a road event object, such as WorkZoneRoadEvent. This option proposes adding an event type of mobile-work-zone-extent.

Option 3. Add a new property subtype or event_subtype to the WorkZoneRoadEvent object

sub_type would be used for providing additional information about the type of work zone road event. The new property would be optional and values would be restricted to a new enumerated type: WorkZoneType. It would have at least the following value: mobile-work-zone-extent. It could also have moving-work-zone or mobile-work-zone to describe the road event that represents the active area of work that is moving.

Option 4. Add is_moving to the WorkZoneRoadEvent object

This option involves adding an is_moving property to the WorkZoneRoadEvent which would be a boolean value used to determine if the work zone is moving.

[brookesc4]

So I'm not sure how to code this but the notification of a mobile work zone is needed. The example is when we have a mobile operation we will have no traffic control in place. So it will just be trucks on the roadway. This mobile work zone should be closing this area from the first vehicle to the last vehicle. If we just have this a points, then these are all separately reported work zones. If you have a striping crew with 8-10 vehicles what is that going to look like to a driver? I think we would need it to come across as one work zone. So if we had a device feed defined as moving pick up any other device within a set range, connect that feed and send it as a single closure that would cover the vehicle cutting into the work convoy. This could also identify the expected closure time for exit and entrance ramps, as access to those will be shut down while the operation goes past that area. If a vehicle cuts in to this area the problems would range from tracking of wet paint to hitting and killing a worker on foot patching pot holes (as two examples). The human driver should also be made aware that they can not cut into the area and that the lanes are closed even though there is no actual traffic control device such as a drum, marking the lane closure.

There are a few other reasons that this is a benefit to have in place, most of which get into the long term re-routing of traffic and diversion around the work area. Which would be different based on the duration that closure is expected to be in place,

[sergebeaudry]

@brookesc4 is giving some fuel for this discussion:

when we have a mobile operation we will have no traffic control in place

This impacts the safety aspect of such operation versus a typical work zone with barrel, concreate wall ,etc... As the goal of WZDx is to increate safety convey of that information would be a great addition to the feed.

This definition also opens some use cases for mobile operation:

• The paint stripping that just move at a specific speed
• the crack filling, that stop and go periodically.
• A minor guard rail repair where just a small team are handling
• an more

To address all this, I think that the devices such as arrowboard, location marker, message signs (swzdevicesfeed) shall report more often their location when they are part of a mobile operation ref issue #257 & the WZDx feed shall indicate that a mobile operation is going on a segment of road. (ref: @j-d-b option 4 above) and update that feed often as well. Is this would be enough to help mapping and car OEM data users?

[sknick-iastate]

This issue is resolved partially by PR #322 by allowing data producers to relate two road events where one represents the planned extents of the mobile operation and the other represents the actual location of the mobile operations.

What still needs to be addressed is how mobile work zones can be shown when the actual location of the mobile work zone is not known. Currently, if a data producer does not have the actual location of the mobile work zone then the related road event in #322 can not be used and there is no other ability to distinguish that the work zone is a mobile operation.

Potential solutions discussed so far include adding a specific field for mobile operations or utilizing the existing event_type.

[j-d-b]

Proposed option based on co-chairs discussion on 2022-09-09 is to add an optional work_zone_type property to the WorkZoneRoadEvent object, restricted to a value from a new WorkZoneType enumerated type (see below). This property can be used to provide information about the specific type of the work zone, such as the planned extent of a mobile operation.

See below for a draft implementation.

---

WorkZoneRoadEvent Object

New Property

Name	Type	Description	Conformance
work_zone_type	WorkZoneType (see above)	The type of work zone road event, if applicable.	Optional

WorkZoneType Enumerated Type

Describes a specific type of WorkZoneRoadEvent.

Value	Description
planned-moving-area	The planned extent of a moving operation. The active work area will be somewhere within this road event. The road event geometry is typically not actively changing.
moving	The road event is actively moving on the roadway.
static	The road event statically placed—not moving.

[j-d-b]

Implemented in v4.2.