Situation impact could include more detail about when things may return to normal. (Bugzilla Bug 474)

[datexii]

This issue was created automatically with bugzilla2github.py

Bugzilla Bug 474

Date: 2024-02-23T14:34:14+01:00 From: @iancornwellmottmac To: Bard de Vries <b.devries@u-trex.nl>

Last updated: 2024-02-23T14:34:14+01:00

[datexii]

Comment 1917

Date: 2024-02-23 14:34:14 +0100 From: @iancornwellmottmac

The English national traffic information service for many years has used an extension of Situation where Impact is extended to include a class called ReturnToNormalStatus Definition: Information regarding the return to normal status of the situation.

Attributes

• predictedTimeToClear DateTime 0..1 The time that the situation/event is predicted to no longer have any material impact on the road network.
• actualTimeToClear DateTime 0..1 The actual time that the situation/event is no longer having any material impact on the road network.
• predictedReturnToProfile DateTime 0..1 The time that the road section affected by a situation/event is predicted to return to profile (expected/normal traffic conditions).
• actualReturnToProfile DateTime 0.. 1 The actual time that the road section affected by a situation/event has returned to profile (expected/normal traffic conditions).
• predictedReturnToFreeFlow DateTime 0..1 The time that the road section affected by a situation/event is predicted to return to free flow conditions.

This has some similarity to the "persistence" concept recently discussed by the Netherlands, but the construct above is for the road operator to give their prediction and is not related to observation reporting. (Ian had held back suggesting this change until we reached v4 discussions)

[iancornwell1]

TB meeting 4 Sep agreed we should add this, albeit we might simplify and clarify. It is interesting that it was considered part of Impact - an argument could be made for that, or an argument could be made that it's really related to the Situation's link to TimeValidity. Discussion may identify that the value of this depends on policy about Situation elements - say that a closure will stop at 1pm and we estimate that traffic will return to normal by 2pm. The service that used this construct might just have a Closure with ReturnToNormalStatus, whereas another service might have a Closure ending at 1pm and an AbnormalTraffic in the same Situation, ending at 2pm. Taking the latter approach, the need for ReturnToNormalStatus might be questioned - although the 2nd approach described doesn't distinguish between clear/profile/free-flow - but whether we need all these 3 concepts is also not clear. Although NL + UK were tentatively in support of this change, I now think that we should analyse further, and decide whether to introduce the change at TC review. IC will seek further clarification about usage from the UK service that uses the extension.

[iancornwell1]

There are further clarifying definitions in NTIS interface documentation. For time to clear, it adds "That is, the original traffic impediment has been removed, but there still may be residual effects on the traffic." For return to free flow it adds "Free flow is ... where traffic flow is constrained only by the speed limit imposed on the carriageway". For return to profile there is only the very slightly more explicit statement "The profile is the normal traffic flow conditions expected at the current time and day". There is a clear difference between all 3 concepts. Considering the difference between return to free flow and return to profile - where the profile would be somewhat congested then only return to profile seems appropriate for a Situation publication, because that is when the impact ends; however when the profile is very sparse traffic then return to free flow happens before return to profile, and that is an interesting stage in the lifecycle of impact of the Situation. So I am persuaded that all of the concepts belong in Situation publication. There is still the thought that "time to clear" would be handled instead by having multiple elements by some services in some countries, so I think I will keep the initial model to the freeflow and profile concepts and possibly raise a TC review comment to discuss "time to clear" [the original impediment] which is more contentious.