Add new options to FlashingBeaconFunction enumerated type

[Dunge]

Summary

The SwzDeviceFeed FlashingBeacon entity have a list of FlashingBeaconFunction that is currently a bit limited.

Proposed changes

I would see a value to add a few fields, like meteorological events. Suggestions could include low-visibility, high-winds, overheight-detection, railway-crossing, pedestrian-crossing, and more importantly other or unknown.

[j-d-b]

I think that most of these are great additions. The original set was due to the input we had at the time of the WZDx v4.0 development cycle, where these were not brought up.

The one I am hesitant on with is unknown, because I am not sure the scenario where that would be used. @Dunge can you explain your though processes behind that one?

[Dunge]

Well in our system, the data set doesn't have a function property on the flashing beacon entity, we only know that it is a flashing beacon and its status. A human can deduce its function based on the owner, name, location and project it is on, but not something that can be filled from code. Even if we do add a similar property in our model, you can be certain most users won't take the time to fill it out when creating the device entity.

So in this situation, would you rather not have the device present in the feed at all if we are unable to specify its function?

In any case, just other would fill a gap. For now all of our flashing beacons serve as some of the new values I suggested, and even if I had the property for in my system to differentiy them apart, I currently can't add them in the feed because they aren't doing one of the function decided in the original list.

[j-d-b]

Got it. It is a problem that you can't add flashing beacons that aren't one of the current FlashingBeaconFunction enumerated type values.

I agree that other should be there and understand the user of unknown. The core information is that there is a flashing beacon at a precise location; having unknown lowers the effort to express that.

Edit: after further discussion, I am for keeping the function property on the FlashingBeacon required and expanding the FlashingBeaconFunction as needed to cover specific use cases.

[Dunge]

Also note that setting the function property of the object as optional would serve the same purpose. It's pretty much the same reason as why any other field can be optional.

[sergebeaudry]

Hi regarding this expressed by @j-d-b

I agree that other should be there and understand the user of unknown. The core information is that there is a flashing beacon at a precise location; having unknown lowers the effort to express that.

As an equipment provider we do not know the whole story on the usage of an equipment. The SwzDeviceFeedenabled us to confirm that a beacon is Flashing or Not and send that information to a DOT. On their side they can reference another internal system to query the event type and publish themselves an augmented SwzDeviceFeed with the corresponding events. This enabled all of us to use a defined standard with the level of information we have instead of creating separate, proprietary feeds to exchange sub-element of information.

[j-d-b]

Also note that setting the function property of the object as optional would serve the same purpose. It's pretty much the same reason as why any other field can be optional.

Thanks for bringing up this option, this is the approach taken with most properties in WZDx so I think this is what we should go with if we choose to allow unknown flashing beacons. Thus, the potential changes so far are:

• Change the conformance of the function property on the FlashingBeacon object from "required" to "optional".
• Add the following new values to the FlashingBeaconFunction enumerated type:
  • low-visibility
  • high-winds or high-wind (the latter sounds more natural to me)
  • railway-crossing
  • pedestrian-crossing
  • overheight-detection or over-height-detection (I prefer the latter because overheight isn't a word)
  • other

[rdsheckler]

ok, we have actually done quite of bit of this. The agencies and the contractors want to be able to have special designation beacons and it will be important to have the basic classes called out in this spec so that there is consistency. The beacon is a GPS enabled binary for a predefined condition, when it is 'on' the condition exists at the location. There are many uses some examples of conditions are: Closed road Closed sidewalk Flooded road Delineator

[eli104]

If the idea is to open up a list of possible uses for a flashing beacon (on either a permanent or portable sign), as @rdsheckler noted there can be any number of reasons (enumerated type) where a beacon will be turned on.

Some of the possibilities are already noted in the FlashingBeaconFunction enumerated type, and there are certainly others that perhaps should/could be added (especially considering this is optional use). But it should be acknowledged that being VERY specific may lead to a VERY long list of values. We have more than 100 Event Codes in our system for weather-related road issues, and dozens of these have Attributes that can be used as a "reason" for the Event (such as SlipperyRoads due to FreezingRain, or ReducedSpeed due to Fog, etc.).

So while I agree that all of the events and attributes mentioned are valid reasons why a FlashingBeacon might be used AND that this information is quite helpful to add to the Event detail (for those who will use it); My concern is that we might end up over-reaching into regular "traffic conditions" which are NOT specific to Work Zones? I am NOT saying that we should NOT go there... I am only raising a note that if we choose to include an extended list of detailed reasons, (as opposed to saying "other"), we may be opening a Pandora's Box where the list gets so long it becomes arguably unusable to many who this structure is focused on helping.

[NeilBoudreau]

So I think that when the Subgroup created the FlashingBeacon object the intent was to create a series of enumerated types under the FlashingBeaconFunction related to activities that are related to work zones. We created the initial listing of the enumerated types and fully expected that other use cases would create the need to expand the initial list. While there are are some good suggestions as to what would be worthwhile adding to the FlashingBeaconFunction enumerated type list as they are more common conditions, I am not in support of adding "other" or "unknown" because there needs to be a reason why a FlashingBeacon is being used. What is said FlashingBeacon signifying? What message is it being use to convey to the motorist? Plus, rather than creating an endless list of enumerated types for FlashingBeaconFunction, why not just use something relative to a traffic control device and add "WarningSign" and "RegulartorySign" to the list for those rare conditions and to serve as the catch all for the desired use of "other" or "unknown". Also, I think that it is essential to keep the FlashingBeaconFunction as a required property and not make it optional. In the end, what good are we doing if we are passing along a message to the consumer end-user that there is a flashing beacon at this location? Having a defined function that gives notification and/or direction to the motorist is what is going to make the roads safer.

[sergebeaudry]

Let me put this with a different angle. the goal of SWZdevicefeedis to provide "_Provides information (location, status, live data) about field devices deployed on the roadway in work zones.", and they main audience are the agencies

versus the WZDxFeed that has the goal of "Provides high-level information about events occurring on roadways (called "road events"), primarily work zones, that impact the characteristics of the roadway and involve a change from the default state "

As mentioned above they have hundreds of good reasons at putting flashing beacons. but is this alone give enough info to the public?

Maybe the FlashingBeaconFunction shall be removed and let the agency provides the complete story within the WZDxfeed to the public?. EX: a flashingbeacon due to speed reduction or a flood is not providing enough info by itself.. Combined with WZDx elements such as speed of 45 MPH, road closed it becomes now a usable set of data for the public.

on the others end some sort of function could be beneficial by itself.. EX: high wind. iced bridge. But those looks more for permanent installation...

Not an easy one. Maybe should keep it, targeted to Workzone functions, add the warningsign, regulatorysign proposed by @NeilBoudreau and let monitor its usage over the next few years.

[tfoster-vm]

Flashing Beacons (as proposed by the SWZ subgroup) were only intended to be for the SWZ Field Device Feed and not the WZDx feed or the Road Restriction Feed. They certainly could be added to the road restriction feed for other purposes, but our focus was for work zones and it was not to be fully inclusive, but we tried to accommodate common applications. I hope this clarification helps.

[rdsheckler]

As I see it we have a short list of uses of beacons with an 'other' free text field. As we get experience we will see that certain types of 'other' show up regularly and we can expand.

In reality the flashing light has no meaning. It is an indicator that a specific condition exists and the flashing light is just the binary for the condition. Most generally this could be replaced with an informational sign like 'stopped traffic ahead' (in Illinois) or 'workers present' (in Penn). Both have flashing beacons but the light itself is just a binary switch that makes the condition active. And as everybody has pointed out the various conditions that have flashing lights on the roads in North America are countless.

I think the best we can do is list the top five or six and leave room for growth as we progress.

[j-d-b]

Based on discussion throughout this development cycle and eventual decision from by the SWZ Subgroup co-chairs, the new options proposed for issue will not be implemented as. However, some added functionality will be addressed through resolution to #295.

We are open to adding new options for the FlashingBeaconFunction, but new values must to be scenarios where a beacon is used in a temporary setup in a work zone—the intent of the flashing beacon is not to represent all scenarios on roads.

In general, I think there is more work that needs to be done for the flashing beacon, such as clarifying the use of it over a location marker, perhaps refactoring the concept to a "conditional sign" where the sign condition is only in effect when the beacon is actively flashing—that is not the explicit use of the current flashing beacon.