Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maximum route duration + xml #246

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

braktar
Copy link
Contributor

@braktar braktar commented Jun 1, 2016

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

@oblonski
Copy link
Member

oblonski commented Jul 8, 2016

Why cant we just add the VehicleRouteDurationConstraint via the ConstraintManager?

@braktar
Copy link
Contributor Author

braktar commented Jul 8, 2016

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.

@oblonski
Copy link
Member

oblonski commented Jul 8, 2016

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
Copy link
Member

oblonski commented Jul 8, 2016

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.

@braktar braktar force-pushed the duration branch 2 times, most recently from ccbed2a to 6e76032 Compare July 8, 2016 14:38
@braktar
Copy link
Contributor Author

braktar commented Jul 8, 2016

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.

@oblonski
Copy link
Member

oblonski commented Jul 21, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants