-
Notifications
You must be signed in to change notification settings - Fork 339
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
Breaks steps have meaningless location_index
values in output
#877
Comments
Thanks for reporting. Actually breaks are not supposed to have a location in output, see for example https://github.com/VROOM-Project/vroom/blob/master/docs/example_1_sol.json. It has always been this way, so the problem here is that we report a meaningless The problem is that we don't discriminate between steps types when serializing to json. No-one spotted this since it has been introduced back in #627. |
location_index
values in output
Actually we should probably make the |
Thanks for the fast reply (and happy new year). Originally, I assumed that the break always happens at the location of the previous step. This was true before I think - now it always seems to happen at the location of the next step for some reason. What I find a bit strange in my example is that the the vehicle is driving to the end-location after the last delivery and before the break happens at that (end-) location, there is an additional waiting time before the break begins. While technically not wrong, this seems odd. Is there a reason for that? Also, isn't it a bit tedious to have to check the 'distance' value of the break to determine its location? |
Breaks can basically happen anywhere/anytime between the adjacent tasks. Even if they can stick to the previous or next task, we want to have a lot of flexibility here. The rationale is that in a The intermediate distance value for the break has no real significance since there is no actual location. It is just computed based on travel time split for consistency here. |
For me it seems the distance value is always either the same as for the previous step or the following step. I have never seen a break with a distance in between. Is there another way of recognizing at what part of the travel the break is taken? For our algorithm I think I would need to iterate over the breaks and manually shift them back or forth so that they are always exactly after/before another step. |
It means you only encountered situations with the break right after or right before a job. Having the travel time split across a break only happens under special TW circumstances where fitting the break would otherwise be impossible.
The
Breaks are mandatory so they'll show up in routes no matter what, even if everything can be done early and the vehicle reached its end location before the break available time. If you have a business logic where the break is only meaningful if the route is long enough, then you probably want to remove the "end break" from the route plan altogether in a post-processing step. |
Alright, thank you very much. That explains a lot. I have adapted our code to post-process the break accordingly (either attach it to previous or next step). Here is how I have done it (in case someone else has the same requirements):
|
Hello,
we noticed a strange behavior using VROOM v1.13-rc1. It seems that the break (sometimes?) does not get a location attached in the result json. Instead, a
"location_index": 0
is added to the break even though we did not provide a custom location matrice or something similar.For now we fix this issue by just assuming the breaks location to be at the step happening before or afterwards depending on the distance.
Input
Output
The text was updated successfully, but these errors were encountered: