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

Lane level traffic sensor data restrictions #225

Closed sknick-iastate closed 2 years ago

sknick-iastate commented 2 years ago

Issue name: “Lane level traffic sensor data restrictions”

Summary

The TrafficSensor Object allows for summary data to be collected as well as individual lane data. The restriction on the lane-level data is that it can only be provided if the data producer knows the road event it is assigned to. See the note below in the TrafficSensorLaneData Object:

Note this structure allows a single TrafficSensor to provide data across lanes on multiple road events. It does not allow for lane data to be provided when a road event is not known.

This seems overly restrictive at this point. I think it should be strongly recommended to provide the road_event_id but I would prefer to receive the lane level data even if the data producer wasn't aware of what road event it is assigned to. I can also see situations where certain lanes are not associated to a work zone (i.e. ramps or opposite direction of travel) that the sensor is collecting data for that would be missed in the current implementation.

Proposed changes

Recommend making the road_event_id optional in the TrafficSensorLaneData Object and remove notes about needing an associated road event for lane level data.

Dunge commented 2 years ago

I also would vote to make road_event_id optional.

To add to that, I have issues representing sensors giving speeds for multiple directions since a single physical sensor (same UUID) can collect speeds for both directions.

When representing the global speed/volume/occupancy values, as it is designed now those would represent the average of both directions which don't have much value in representing. In our system, we are used to have an average per direction, which we call "upstream" and "downstream". And each "stream" have a direction (north/south/east/west-bound) associated. So in a road with two lanes in each directions, you have a value for the average of the two lanes going south, and average of the two lanes going north, and also values for each individual lanes. But having the average of all lanes globally isn't really meaningful.

When presenting the lanes, currently with two direction you have two entries that will have lane_order to the same value (since it represent the position starting from the left), and only the road_event_id can serve at distinguishing each direction they represent, having to cross-reference with the lane structure in the other feed. I don't have a perfect proposition to fix that, but having a direction field could help.

Currently in my implementation I just listed the same device twice, once per direction, but it have the same Id, so it might not be the best solution.

j-d-b commented 2 years ago

See #267 which implements the simple change of changing the conformance of road_event_id to optional, as discussed above.

j-d-b commented 2 years ago

Resolved in #267.