message_multi_string property for DynamicMessageSign of SwzDeviceFeed (pr #208) empty string value is misleading

[dxpack]

Issue name: “message_multi_string property for DynamicMessageSign of SwzDeviceFeed (pr #208) empty string value is misleading”

Summary

In PR #208 the SwzDeviceFeed contains a DynamicMessageSign with a message_multi_string property, and states that the value can be an empty string if the NTCIP MULTIString value is an error. A non-error blank message can also be represented by an empty string value. See related: IS #218

Motivation

An empty string value for the message_multi_string property is misleading.

Proposed changes

Either:

• Change the type of message_multi_string property to allow either a String or a new integer-based enumeration and add a new integer-based enumeration value type such as ValueError where, for example, 0 = NTCIPError (this resolution would also allow for handling other NTCIP errors or other externally-sourced data errors in other portions of the WZDx specification, if applicable)
• Retain empty string values for either condition and add an additional key, such as message_multi_string_descriptor to the DynamicMessageSign object that allows for a description of the message_multi_string property value, perhaps where the value of this additional key is fixed to a new enumeration such as MULTIStringDescriptor with one possible value being, for example, "ntcip-error" (this resolution would also allow for additional descriptors as may be useful, such as "includes-binary" when a MULTIString cannot be represented by a JSON String, see related: IS#218)

[NeilBoudreau]

This issue seems to be directed towards the equipment manufacturer and vendors as to the direct operation of the DynamicMessageSign. I am wondering if we can get some feedback from @sergebeaudry @petekrikelis and other manufactures as to how much of an issue this is and does it happen frequently for us to have to make the changes? Thanks!

[Dunge]

I work at Ver-Mac with @sergebeaudry and already debated at length with @dxpack in #218. He is right by saying that the NTCIP definition of the multi string node could include binary data, but in my experience this is extremely rare. That's why I was proposing to keep the value as string because seeing the measage's content in the feeds as a readable format is preferable to seeing a byte array. This issue was created to accomodate @dxpack in the situation that he have binary data he can't display as text and still want to convey that something is displayed on the sign. In the case of our products, this isn't something possible.

Same for errors, if the multistring doesn't pass the validation state, it can't be transferred to what NTCIP call the "current buffer", so it's impossible to have an invalid/errored multistring on display. And if there's material error causing the display to get corrupted after the message was set (pixel failures or any equipment failure preventing the message to be shown), our product blank the display automatically so in our case reporting an empty string would be correct without the need for any other information. The cause of the errors themselves can be filled in the exisiting fields (status_messages) in the core_details object.

That said, even if for us this is not required, I think @dxpack suggestions is perfectly valid. I would not want to prevent anything. I have absolutely no objection at adding a description field or enumeration to accomodate other manufacturers at relaying more information.

[dxpack]

I work at Wanco, we do have scenarios where the MULTIString value contains binary data. It is rare, and particularly so for a work zone scenario. But it is possible. In addition, I generally favor allowing for error conditions. For example, as @Dunge notes it is invalid for an NTCIP compatible message board to include an invalid message in the current buffer. If such a board did include an invalid message in the current buffer, it would therefore be in an error state. As much as I wish otherwise, hardware devices sometimes get into error states.

At present, the WZDx spec would represent all of the above with a blank message or an incomplete NTCIP MULTIString value (of the ASCII portions if present), which is misleading to the consumers of the WZDx feed.

[dxpack]

Upon further consideration, the error handling is not necessary or consistent with the rest of the WZDx spec in regards to device data. Wanco currently excludes devices that would otherwise show up in our WZDx 4.0 feed, if the device is in an unhandled error state.