You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thank you for this amazing tool.
I've been using max_travel_time constraint in vehicles as the "duty hours" for the vehicle, but today in one edge case realised that this constraint doesn't take into account the service time of the Job.
As a result, I'm ending up with routes whose complete job duration surpasses the supplied max_travel_time value.
I understand now that max_travel_time applies specifically to the time spent on the road, and there's a valid use case for keeping it that way: service times don't affect fuel / battery. So, this is not a bug.
But that leaves out a desired feature. Could there be a way to specify maximum full-route time inclusive of wait times when VRP'ing ?
This edge case is only coming up when I don't have any pre-defined time_window for each vehicle. If I apply a time_window, then the VRP solution factors in the service / setup time of each Job and ensures that the planned routes don't exceed the vehicle's time_window.
The text was updated successfully, but these errors were encountered:
Yeah historically we never bothered to track service times as they were always constant for a given assigned subset of jobs, so they had no contribution to the overall cost. Task times are not exactly really constant anymore since we introduced the notion of setup (the route ordering can reduce or increase the overall setup time).
Now in term of restriction, it could indeed make sense to have something like a max_task_time vehicle constraint (that would limit the total setup + service time) and a max_work_time that would be basically a limit on travel time + tasks time.
Note that the work time as mentioned above would not include waiting time, which we do not track internally as explained in other tickets.
Thats sounds great! I just came across the same issue @answerquest @jcoupey May I suggest it would also be nice to control journey time of the vehicle as a constraint? Since it almost always relates to the drivers journey time (max_journey_time) which would includes all the time the driver worked in that route from start point to end point (which will include waiting time as well).
We normally have a limit on this driver’s working hours.
The best way to monitor total journey time is to use a TW. As noted above, max_task_time and max_work_time would be straightforward additions, while max_journey_time would not.
Note that the work time as mentioned above would not include waiting time, which we do not track internally as explained in other tickets.
Hi, thank you for this amazing tool.
I've been using
max_travel_time
constraint in vehicles as the "duty hours" for the vehicle, but today in one edge case realised that this constraint doesn't take into account theservice
time of the Job.As a result, I'm ending up with routes whose complete job duration surpasses the supplied
max_travel_time
value.I understand now that
max_travel_time
applies specifically to the time spent on the road, and there's a valid use case for keeping it that way: service times don't affect fuel / battery. So, this is not a bug.But that leaves out a desired feature. Could there be a way to specify maximum full-route time inclusive of wait times when VRP'ing ?
This edge case is only coming up when I don't have any pre-defined time_window for each vehicle. If I apply a
time_window
, then the VRP solution factors in theservice
/setup
time of each Job and ensures that the planned routes don't exceed the vehicle's time_window.The text was updated successfully, but these errors were encountered: