search

reinterpretcat / vrp

A Vehicle Routing Problem solver
https://reinterpretcat.github.io/vrp/
Apache License 2.0
368 stars 71 forks source link

Custom conditions for jobs/fleet definition #143

Open KhDenys opened 10 months ago

KhDenys commented 10 months ago

Hi @reinterpretcat , is it possible to set custom conditions for jobs, for example, there are jobs of three types A, B, and C. And it is necessary to specify that a vehicle can only take one job of type A, two jobs of type B, and as many jobs of type C as needed?

reinterpretcat commented 10 months ago

Hi, I think you can try to model this with job and vehicle skills, see documentation and example file:

https://reinterpretcat.github.io/vrp/concepts/pragmatic/problem/jobs.html

https://github.com/reinterpretcat/vrp/blob/master/examples/data/pragmatic/basics/skills.basic.problem.json

leobudima commented 10 months ago

This sounds like different vehicle capacities.

Vehicle has capacity: 1 A 2 B 99999 C

Job of type A has size: 1 A 0 B 0 C

KhDenys commented 10 months ago

Hi, I think you can try to model this with job and vehicle skills, see documentation and example file:

https://reinterpretcat.github.io/vrp/concepts/pragmatic/problem/jobs.html

https://github.com/reinterpretcat/vrp/blob/master/examples/data/pragmatic/basics/skills.basic.problem.json

Ok, but it isn’t clear how the skills feature works. So @reinterpretcat do you want to say that skills guarantee that each vehicle picks up only one job which requires A skill?

reinterpretcat commented 10 months ago

Seems like I missed a job amount constraint from your initial message.. If you have such constraint, then I would agree with @leobudima - multi-dimensional capacity/demand could be used here.

KhDenys commented 10 months ago

@reinterpretcat please correct me if I’m wrong. Currently, vrp does not support such problem type, and I have to do some extra manipulation with data to satisfy the constraint, correct?

Thanks for the quick response!

reinterpretcat commented 10 months ago

Such problem type directly through its pragmatic format - no. But you can model some of directly unsupported features using built-in features, like one mentioned above. This is why api design is tried to be a bit generalized: such approach unlocks more advanced scenarios to be supported out of box, through other features.

Alternative way - add your own implementation as a feature which would require you to use the library as a rust crate.

Sometimes, I can add a new feature if it seems interesting for me (and the project).