How to denote traffic patterns: alternating traffic, closed road/ramps, etc

[Hoedic]

Currently, in the event_subtypes, a value obtained by TMDD supports single alternating traffic, but not the others

On top of that, open511 might have a weakness to notify a road closure: in theory one would have to use the lane_status and set all lanes to 0. But it seems that in many cases, the systems managing the data has no information about the number of lanes. In fact, it seems that nobody plans to use the lane_status for the moment.

Based on the current model, I would propose 2 options (obviously, none of them would stick with TMDD which not very coherent here)

1. Add all the missing values (closure, off/on-ramp closure, etc) to the event_subtype. It is a sort of perversion of the subtype, but even in TMDD this field has a lot of various signification, either cause or impact. (Note that subevent is a list, so one can have several subtypes.
2. Create a lane_pattern or traffic_pattern field at the same level as the current lane_status and take from TMDD values coming from various fields to have a coherent model to denote the pattern coming with the event. In this case, the lane_status would become superfluous.

[michaelmulley]

Perhaps this discussion would be easier if we put together a list of traffic-pattern use cases? The ones mentioned so far are:

• road closure (which currently can be indicated only if the data producer also knows and indicated the number of lanes)
• ramp closure
• single-lane alternating traffic

Which other use cases are there?

(Of those, at first glance ramp closure seems like it might best be indicated as a type of road closure, e.g. <road><road_name>I-85 exit #40</road_name><status>CLOSED</status></road>)

[Hoedic]

For more understanding of what TMDD can support (and more generally what might be the type of traffic patterns we would like to support:

subevent type related to traffic patterns are the following:

• opposing traffic
• narrow lanes
• construction traffic merging
• single line traffic alternating directions

The closure types also support (closure type can be applied to an event or to a road segment):

• closed
• blocked
• reduced to one lane
• reduced to two lanes
• reduced to three lanes (The list is much longer, but everything can be summed up with the list above)

There is no simple way to say that ramps are closed. In the TMDD world, ramp would be a road segment and one would apply the "closed" closure type to that specific segment.

[Hoedic]

Change to be implemented as discussed in the open511 mailing list.

• Remove the current lane_status (a bit field meant to specify the which lane was open and closed). Knowing which lane is closed/open is not very useful and it appear that the lane affected and the number of lane available always known. So this bit field would have been difficult to use.
• Add in the road structure a new optional field traffic_pattern that could have the following values: CLOSED (complete closure) PARTIALLY_CLOSED, ALTERNATING (single lane alternating)
• Add in the road structure a 2 new optional fields closed_lanes and open_lanes to provide the number of open/closed lanes (mainly with the PARTIALLY_CLOSED traffic_pattern.)

This design does not solve the question of ramp closures. Since we did not get significant input about ramp management, the case is difficult to manage. From most of the discussions, the ramp closure does not fit in the traffic_pattern logic. So the solution we see for the moment is that ramps should be considered as roads (so a ramp closure should have its own road structure with corresponding information)

[michaelmulley]

Let's confirm that traffic_pattern is the standard term used within transportation departments for this. (I know DriveBC uses it, but there it's also a broader field with many other potential meanings related to traffic flow.) Intuitively, it seems like a weird name to to me: I'd never describe a road being closed as a "traffic pattern", and I'd be inclined to use a tag name like state or something instead. But of course if that is the standard term used across transportation departments, then it's the right choice.

[Hoedic]

Field should be road_state. Get the same logic as lanes-status from TDMM, but a little less confusing (lanes gives the impression that we will have a status for individual lanes while here we get an overall status for the road.

[michaelmulley]

Should we discuss the pros/cons of using

<road>
  <road_name>...</road_name>
  <road_state>...</road_state>
</road>

vs.

<road>
  <name>...</name>
  <state>...</state>
</road>

[Hoedic]

Let's remove the road_ prefix to be consistent with other element names we used.

[michaelmulley]

Potential value list for state:

• CLOSED
• SOME_LANES_CLOSED
• SINGLE_LANE_ALTERNATING
• ALL_LANES_OPEN

Compared to what we've discussed before, this is a slight change in wording and the addition of an option to indicate that the road is fully open.

[michaelmulley]

Changes made to spec