Interpretation of Road Authority Actions
Introduction
Road authorities (and other authorities such as the police) influence the availability of road infrastructure through their maintenance tasks, roadworks, traffic flow improvements, bridge operations, etc. The execution of these tasks can result in changes to the availability status of infrastructural objects. These changes are referred to as actions, which can be planned (e.g., closures due to roadworks) or unplanned (e.g., closures due to accidents). Actions apply to a single object. The resulting information about the availability status of objects such as roads, bridges, peak lanes, on- and off-ramps, etc., are part of data services that provide status information.
The description below contains guidelines for implementing information that falls under the category "road authority actions."
How the Event Proceeds
For road authority actions, a standard process (status cycle) has been established. This process is illustrated in the image below:
The process distinguishes the following statuses:
- Rest status (until b)
- Transition from rest to active status (from b to c)
- Active status (from c to d)
- Transition from active to rest status (from d to e)
- Normal or rest status (after e)
Depending on the context, the cycle may be used in its entirety or only partially (e.g., a message indicating that the active status has commenced). When only the active status is used, it ends as soon as the message ends. If the transition statuses are unknown, the active status is considered to run from the transition from rest to active status until normal or rest status.
Use of Situation and SituationRecord
An event is described using a situation containing one or more SituationRecords for the actions associated with the event. A situation is active throughout the event, while a situationRecord is active during the course of a single action. A situationRecord of the type OperatorAction describes an action (of one object and one status cycle) within the event. The cycle of status changes may consist of repetitions from active to rest status. These active periods of status changes are recorded through two or more instances of the attribute validPeriod. Besides using validPeriod repetitions may also be included in separate situationRecords. It is important to ensure that an active record is ended as soon as the next one begins.
The status of the action is indicated within the SituationRecord using the element operatorActionStatus:
| Status | Value |
|---|---|
| Normal or rest status | approved (Only if an announcement is made) |
| Transition from rest to active status | beingImplemented |
| Active status | implemented |
| Transition from active to rest status | beingTerminated |
An action can be announced in advance with a situationRecord with the element operatorActionStatus with the value "approved" and a future start time. The termination of a situationRecord is carried out by sending a situation containing the unended SituationRecords. The recipient should assume that the referenced object has returned to its normal or rest status. The corresponding timestamp must be determined based on the received message. The termination of a situation occurs through lifeCycleManagement in the last situationRecord (or SituationRecords, in case multiple end simultaneously). The table below describes the content of the situationRecord and the lifespan of the various statuses throughout the status cycle.
Use of Validity
The Validity element in a situationRecord is intended to indicate the active period of the action. When the operatorActionStatus of an object changes from approved to beingImplemented or implemented, the following update occurs:
- For a situationRecord with only one OverallPeriod and no further detailing via multiple validPeriods, the overallStartTime must be adjusted to the moment of status change, as well as the startOfPeriod of the single validPeriod.
- For a situationRecord that includes more than one validPeriod, the following actions are taken:
- Once the start of the next validPeriod or the announcement time is reached, three actions are performed within the situation:
- A new situationRecord is created, containing a copy of the original SituationRecord. This new record includes a validityTimeSpecification (thus no valid periods) where the overallStartTime and (if known) overallEndTime are the same as the active validPeriod of the original record. This new record is processed as described above.
- The existing situationRecord is updated by removing the current validPeriod. The overallStartTime and overallEndTime remain unchanged.
- An allElementUpdate is sent, containing these two aforementioned changes.
Using exceptionPeriod is undesirable and thus rare. The semantic meaning is that during the interval within the exceptionPeriod, the status is at rest/inactive. If the event in the SituationRecord overruns, an update must be sent at the latest when the original end time is reached, either adjusting the end time to the new expectation or omitting the end time. A record reporting an active event must not have an end time in the past. To indicate that a situationRecord has overrun the originally stated end time, the sender can use the overRunning attribute.