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
add another time window interpretation? #233
Comments
Hmm. I can't say that the current definition of time windows has ever been a problem. Maybe I'm not understanding something here, but I'd say this change isn't worth it. |
Do you mean that with the new time window definition it would be easier to enforce them where the time window duration is not known up front? Do you have an example when this would be the case? |
Thanks, @PGWelch, @karussell. I do not plan to change the current time window definition. I only thought loud whether it might be good additional feature to add another specification, i.e. to add an option to change definition from [earliest_start,latest_start] to [earliest_start,latest_end].
This should be always known. However, duration might be dependent on the driver/vehicle. Driver A can make it in 1h, driver B only takes 30min. |
The difference between [earliest_start,latest_start] and [earliest_start,latest_end] is that in the first case act_start <= latest_start and in the latter case act_start + act_duration <= latest_end |
Ah, ok. Then this newer definition would make indeed more sense. |
Hello Has this feature been put up in the current version of Jsprit ? |
No, it has not been merge into the master. |
Currently time windows in jsprit are specified with earliest START and latest START of activity, e.g. if there is an activity that takes 30min and has the following time window: [10:00,12:00], then the latest START is 12:00. If one starts at 12:00, activity ends at 12:30.
However, in some cases, it would be better to specify time windows with earliest START and latest END. In the example above, 12:00 would be the latest end, i.e. latest START would be 11:30. This shows also that as long as service times/activity durations are static, refining time windows is easy. However, if service times are dependent on vehicles, this redefinition would not be so easy anymore. This must be done then on state and constraint level.
Would this be a reasonable feature?
The text was updated successfully, but these errors were encountered: