search

reinterpretcat / vrp

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

Custom conditions for jobs/fleet definition #143

Open KhDenys opened 8 months ago

KhDenys commented 8 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 8 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 8 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 8 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 8 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 8 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 8 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).