Traffic

[juntek]

How to implement various transit times between nodes, depending on time of day?
Let's say I already have transit times data between nodes at 8:00am, 10:00am, 12:00pm, 14:00, 16:00 etc.
How can I use the data in transit callback function? I want to return transit time from node at specific time, for example if the departure time from "from node" is 14:30 I would like to provide transit time from data at 14:00, which is more adequate to the real road situation than at 8:00am.

[jmarca]

Perhaps make multiple passes? First pass uses average travel times to get the estimated arrival times, and second pass uses those times to set the transit times correctly.   Another option is to split the locations into multiples, say three, representing peak, shoulder, and off-peak periods.  Then use disjunctions to allow just one of the three nodes to be served.  This triples the number of nodes though. The best approach in my opinion is to assume that your maximum accuracy is five minutes and just round off the travel times. JamesOn Aug 20, 2025, at 08:59, juntek ***@***.***> wrote: How to implement various transit times between nodes, depending on time of day? Let's say I already have transit times data between nodes at 8:00am, 10:00am, 12:00pm, 14:00, 16:00 etc. How can I use the data in transit callback function? I want to return transit time from node at specific time, for example if the departure time from "from node" is 14:30 I would like to provide transit time from data at 14:00, which is more adequate to the real road situation than at 8:00am. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[juntek]

@jmarca thank you for the reply. I like the first idea, but that would lead to exceeding maximum working time of the driver.
The second idea (cloning locations) is not feasible for me as my implementation is already very complicated.

[jmarca]

In my opinion, the variability due to traffic is never as important as you think it is. Make sure you really need it before you add it in.  Sometimes just knowing exogenous factors like operating hours of an origin or a destination is enough to lock down a travel time to and from a node that is close enough, given all the other variability. But I live in Los Angeles, so I’m also well aware that there can be wild swings in travel time. Good luck,JamesOn Aug 20, 2025, at 12:26, juntek ***@***.***> wrote: @jmarca thank you for the reply. I like the first idea, but that would lead to exceeding maximum working time of the driver. The second idea (cloning locations) is not feasible for me as my implementation is already very complicated. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[juntek]

Traffic variability is significant and depends not only on time of the day but also on season of the year.
Anyway, I like your first idea and I think I'll give it a try.

[0nyr]

Dear @juntek, I do agree that traffic variability can have a significant impact on solution quality and routing duration.

In fact, this field is directly covered in my PhD ongoing research. Your data (one transit-time matrix per departure slot at 8:00, 10:00, 12:00, ...) is exactly a stepwise time-dependent travel-time model, and it does not need node duplication if the solver treats travel time as a function of departure time natively (@jmarca). That is what Kayros does (MIT, pip install kayros): duration-minimization TDVRP(TW) over piecewise-linear arrival-time functions, with stepwise (value-jump) travel times supported as first-class since v1.1. It has exact and anytime modes and its values refereed by a public checker on the MAMUT-routing benchmarks.

Scoping: research solver, C++/Python, duration objective. If OR-Tools' broader constraint set is what keeps you here, the node-duplication route from #339 remains the supported OR-Tools answer; if the TD core is the blocker, happy to help convert your matrices into the arrival-time-function format.