search

usdot-jpo-ode / wzdx

The Work Zone Data Exchange (WZDx) Specification aims to make harmonized work zone data provided by infrastructure owners and operators (IOOs) available for third party use, making travel on public roads safer and more efficient through ubiquitous access to data on work zone activity.
Creative Commons Zero v1.0 Universal
89 stars 62 forks source link

Add direction to FieldDeviceCoreDetails #250

Closed j-d-b closed 2 years ago

j-d-b commented 2 years ago

Background

The RoadEventCoreDetails, used by all WZDx road events, includes a required direction property which is defined as:

The digitization direction of the road that is impacted by the event. This value is based on the standard naming for US roadways and indicates the direction of the traffic flow regardless of the real heading angle.

It's value is restricted to the Direction enumerated type.

This property is required as a single road event can only describe an impact to one direction of travel. direction allows a WZDx consumer to know which direction of the road the road event is on.

Issue

For field devices, there is no direction property. That means a consumer cannot tell what direction of travel the field device applies to. That is problematic in several cases, such as when a consumer is using the location of a device in a SwzDeviceFeed to generate a road event.

This issue was discussed in https://github.com/usdot-jpo-ode/wzdx/discussions/248

Proposed Solution

Adding direction to the FieldDeviceCoreDetails would resolve the issue. Perhaps, as discussed in #229, the property should be named road_direction or direction_of_travel for clarity (as it's the direction of the road the device is on rather than the direction of the device).

Next Steps

Dunge commented 2 years ago

+1 for adding the direction field.

Setting is optional or not should probably follow the same rules as for the wzdx road events, and is debated in #229. Personally I'm always siding with the idea of leaving more flexibility to the schema production (setting it optional) and letting the consumers filter on their side if they require that information and if it's not filled to just ignore these entries.

As for multiple direction per device, I suggest you read my comment in #225. We have the situation where the same physical speed sensor unit can read data for both directions. This end up with a single device who have two lanes readings numbered lane #1. Either we create a business rule that the same device can be present twice in the feed (in each direction), or we make the direction field a array, just like road_event_ids in the core details, and each TrafficSensorLaneData also have their direction field.

benafischer94 commented 2 years ago

Another +1 on adding the direction field.

For all feeds I've ever been apart of, the simplest solution has been to just create a second entry for the same device to handle the direction that it provides data. Since typically this is only detection units, it doesn't spiral too badly. The biggest benefit seems to come from travel time calculations since only the "detector" data for that direction has to be included. So I'm in favor of @Dunge 's proposal to just cover in business rule for the device to be present multiple times in the feed. The direction associated with the lane numbers helps to eliminate the confusion around multiple lane no. 1 to a single device.

sergebeaudry commented 2 years ago

I'm co-chair on the worker Presence subgroup. We are conducting interviews with various stakeholders these days. One comment we got is been able to include the road direction of road elements. So I'm in with this proposal

j-d-b commented 2 years ago

Resolved in #273.