Consider SwzDeviceFeed field device information used to assist in representing mobile work zones

[j-d-b]

Summary

This issue is intended to start discussion on what information could or should be added to the field devices represented in a SwzDeviceFeed to help represent and clarify mobile operations.

Currently, the ArrowBoard field device has an is_moving property (boolean) which is defined as:

A yes/no value indicating if the arrow board is actively moving (not statically placed) as part of a mobile work zone operation.

The ArrowBoard is the only type of device with this property and it is not clear if it provides any value.

Motivation

Representing mobile operations was identified as the top priority for enhancements or clarifications to the WZDx specification by SWZ Subgroup Survey results.

Items for discussion

• Is there value in adding a new value of moving-operation or mobile-operation to the MarkedLocationType enumerated type, to enable explicitly representing a mobile operation using a LocationMarker?
• It is not clear how a consumer benefits from the is_moving property on the ArrowBoard device. Also, it is confusing that only the ArrowBoard has the is_moving property. We should discuss the value of knowing a device is moving (update frequency is a separate property, the is_moving should not be used to determine how often a consumer fetched the feed)—if there is value, is_moving should possibly be added to the FieldDeviceCoreDetails so that any device can be moving.

[davidcraig4300]

I like this idea (adding the moving property). Specifically the idea of frequent updates never predicts future locations. Adding the concept of a movable work-zone, lets the user comprehend that the provided location today may not be representative of the actual work-zone location tomorrow. It allows a forecasting element to become available (not a good one, but at least a hint). At some point in the future, i can see adding a velocity and heading to this attribute.

[benafischer94]

I would agree that it makes sense to include the is_moving field to all devices. The currently defined list of devices all can, and often are employed in mobile work zones. Assuming the list continues to expand and include all types of typical ITS devices, the main one that doesn't work in a mobile operation would be vehicle detection units. Obviously, some caveats exist around certain models of other generic ITS devices, but it's simple enough to mark no for those. The biggest benefit is logic can be built to determine whether or not a specific device should be included in breadcrumbing type applications.

To discussion points:

• I think moving_operation is a bit more concise and clear language.
• is_moving should be added to all Core Details. It's simple enough to mark as no, and it's not like humans should be doing the interpretation of the data anyway. If it's not relevant at data consumption time, the consumer can choose to ignore the field.

[sergebeaudry]

A few history here. back in 2017, The ENTERPRISE Transportation Pooled Fund Study TPF-5 (231) was released. This document was the first giving a clear definition, requirements and use cases related to Smart arrow Board. The document is giving some rules related to mobile operation and one of them specifies that an arrow on a mobile operation shall provide an update status more often. An arrow board was and is still the more often traffic control device used in mobile operation. That is why it was the only one with that attribute. DMS/VMS are used but in a lesser %, probably in a ratio of 80% arrow and 20% DMS/VMS currently.

Now in 2022 I agree that this goes beyond the 2017 intent of the above document. Variable message sign, start/end of workzone, worker/truck presence beacon, why not hybrid sign (speed limit) can all become part of a mobile operation.

I agree that this should be more generic for any SWZdevicesfeed element. For that reason, maybe it should be a value of the FieldDeviceCoreDetails object.

[j-d-b]

is_moving was added in #266.

[j-d-b]

Resolved in #266.