jsprit icon indicating copy to clipboard operation
jsprit copied to clipboard

Maximum route duration + xml

Open braktar opened this issue 8 years ago • 6 comments

That's a subject which often come back on many discussion.

The idea is to have a parameter defined on the vehicle to limit the route duration. Maybe is it more logic to add it on the Driver definition ?

Ref : https://discuss.graphhopper.com/t/maximum-trip-duration-constraint/758/6

braktar avatar Jun 01 '16 15:06 braktar

Why cant we just add the VehicleRouteDurationConstraint via the ConstraintManager?

oblonski avatar Jul 08 '16 08:07 oblonski

Is your question about the conditional add of the constraint ? If yes, I didn't want to calculate a constraint on a value which is set on any vehicle.

braktar avatar Jul 08 '16 08:07 braktar

I meant why do we need to change the core at all if you can just add your DurationConstraint via the ConstraintManager. Currently, "maxDuration" can be set with "latestArrival" and "earliestDeparture". Since departure times are not variable yet, "earliestDeparture" is actually "departure". Therefore, as long as departure time is not variable, we do not necessarily need RouteDurationConstraint since it can already be modelled. If users implement smth like variable departure on their side, they can then just use your DurationConstraint then.

oblonski avatar Jul 08 '16 09:07 oblonski

If we had flexible departures then it would make sense to add new vehicle attributes such as "maxDuration" or "maxWorkingTime". We then might think about adding "maxDrivingTime" also.

oblonski avatar Jul 08 '16 09:07 oblonski

I just add an updater in order to calculate the flexible departure time starting from the Actual End time as base. Calculate it using the ActivityTimeTracker will give any information on the compression of the different waiting time we could compress or not by leaving start later.

braktar avatar Jul 08 '16 15:07 braktar

Hi @braktar, Thanks a lot for your effort. I really appreciate it and I d love to answer and review your work immediately but often lack time. The problem with flexible start times is not as easy as you assume. Updating start time according to latest possible start time is one thing. The other important issue is always the insertion of new jobs so one needs a mechanism that can account for flexible start times when inserting a new job. Currently, start/departure times are constant so you do not need to take care of it in the insertion phase, i.e. you just take these constant departure times. This will change when dealing with flexible times. There must be a way to anticipate that start times can be shifted back and forth. Sounds easy but is not since it is also associated to waiting times etc.. However, it is definitely worth to investigating ways to come to grips this problem.

oblonski avatar Jul 21 '16 07:07 oblonski