datexii
commented
9 months ago Comment 1918
Date: 2024-02-23 14:56:59 +0100 From: @iancornwellmottmac
In Situation, the Delays class has a delayTimeValue which is defined as:
The value of the additional travel time due to adverse travel conditions of any kind, when compared to "normal conditions", given in seconds.
The English national traffic information service has for many years used an extension of v2 Delays with an additional attribute "delayOverFreeFlow" where the intention is similar to delayTimeValue but where it relative to "free flow" conditions.
You could argue that "normal conditions" intends free flow conditions, in which case there should be no structural change to the model - but we might then change the definition.
Or you might argue that "normal conditions" means typical for that location at that time, which could be congested rather than free flow.
The English view was the second one. The service publishes BOTH delay vs profile (for which it uses the standard delayTimeValue) and delay vs freeflow.
So this issue is proposing that we support publishing both delay vs freeflow and delay vs profile. We could do that either by adding an attribute to Delay or factoring out a class for value and type. (We shouldn't just make Delays 0..* because that would result in repetition of the delayBand attribute) I prefer the former - add an attribute. We could rename delayTimeValue to delayToProfile and add delayToFreeflow.
iancornwell1
This issue was created automatically with bugzilla2github.py
Bugzilla Bug 475
Date: 2024-02-23T14:56:59+01:00 From: @iancornwellmottmac To: Bard de Vries <b.devries@u-trex.nl>
Last updated: 2024-02-23T14:58:10+01:00