bug with break

[jie31best]

it seems that BreakScheduling does not handle properly the case when 1) the vehicle has a break; 2) the route end time is after the break time window; and 3) the break cannot be inserted into the route.

see https://discuss.graphhopper.com/t/vehicle-does-not-take-break-in-a-route-that-ends-later-than-the-break-time-window/1682.

The following post seems to be another bug: the solution is not optimal and the vehicle takes unnecessary waiting before the break.

see https://discuss.graphhopper.com/t/another-bug-with-the-vehicle-break/1696.

[oblonski]

The reason why this example does not work is that a break is currently only be scheduled if inRoute.getEnd().getArrTime() > aBreak.getTimeWindow().getEnd() (see here). If one changed it to inRoute.getEnd().getArrTime() > aBreak.getTimeWindow().getStart() then this example works. However, one can still easily construct artificial cases where it fails to schedule the break even one would expect one. It is due to the sequential scheduling of job and break. It might never fail to schedule a break if one started with scheduling a break in an empty route.

[jie31best]

It might never fail to schedule a break if one started with scheduling a break in an empty route.

this might not work because, if you schedule a break in an empty route first, the break location will be fixed at the depot location when you evaluate the insertion of the next job, which could be problematic.

Actually this is a general issue. In the current job (service/shipment) insertion cost calculators, when the current route contains a break, its property that it can be at any location is ignored. This could lead to that some potentially good solutions are disallowed. See this example I posted on the forum.

a fix I can think of is 1) never really insert the break into the route until the insertion ends, and meanwhile, 2) in the job insertion cost calculators, always check if the insertion of the job activity will lead to that the break (if any) cannot be inserted.

For (1), need to remove the InsertionStartsListener and JobInsertedListener from the BreakScheduling, and add an InsertionEndsListener which inserts the break when the insertion ends.

For (2), basically just the changes I made in #332

The fix is able to resolve the issues in all the three aforementioned posts. However, the run time increases significantly when I test it on a larger problem.

Need to think of a way to make it more efficient, or a more efficient fix.

[ifle]

Unfortunately, I also encountering break bug too? Are there any plans to fix it?