-
Notifications
You must be signed in to change notification settings - Fork 1
TravelTimeRefactor
OTP supports automobile routing fairly well at this point. However, the times are inaccurate. Here, I (mattwigway) propose a new method for modeling the travel time for automobile travel (this could also be applied to bicycle travel, although that might reach the point of diminishing returns).
A very simple model for on-street travel time is: T t o t a l = T t r a v e l + Δ T a c c e l e r a t i o n + Δ T d e c e l e r a t i o n + T i n t e r s e c t i o n + Δ T t r a f f i c
Where T_{travel} is is the on-street travel time, as defined by the length of each segment divided by the segment that is traversed,
\Delta T_{acceleration} is the additional time taken by acceleration from an intersection,
\Delta T_{deceleration} is the additional time taken by deceleration to an intersection,
T_{intersection} is the amount of actual delay at the intersection (i.e. waiting time for a light to change or traffic to clear),
and \Delta T_{traffic} is the additional time needed for traffic.
Here is how I propose to implement this in OTP:
T_{travel} is very simple; it can be calculated within PlainStreetEdge from the length of the street and the maximum traversal speed (or the global bicycle traversal speed).
T_{intersection}, T_{deceleration}, and T_{acceleration} can be calculated inside IntersectionVertex, in a function that calculates the delay at the intersection using probabilities (e.g. if there is a .5 probability of being stopped for 30 seconds, the delay is 15 seconds). It can also calculate the acceleration and deceleration times based on the speeds of the incoming and outgoing sections. It would give higher costs to left turns in countries that drive on the right, and would weight for traffic lights, &c. The acceleration and deceleration deltas would be calculated based on speed; that is a slight complication when the street segments aren't long enough for a vehicle to reach full speed.