Possibility to define a vehicle speed factor about vrp HOT 9 CLOSED

Released in 1.10.0

from vrp.

Thanks for the extra info!. From this point of view, I think it makes sense to add it too: in the end, matrices tend to be big, so it might help to save some resources (e.g. disk/memory space, deserialization size). I guess it won't take long time to add this as a new feature.

Just one question: this scale factor is only for traveling time between locations, but not for service time of a job?

from vrp.

Great, happy that it sounds useful!

In most cases where I've seen it, yes, it only gets applied to travel time, and that is probably least complicated implementation-wise. For use-cases like delivery (vs e.g. servicing equipment), travel times are probably a much bigger component of total job time and much more depend on driver "performance", than service time, which is also small comparatively.

from vrp.

Working on it in a branch: 4ccf7ff

only missing some tests so far

from vrp.

Hi,
thanks for feedback.

Regarding to a vehicle speed factor: I would say this can be modeled using different routing profiles with different matrices. See this example: https://reinterpretcat.github.io/vrp/examples/pragmatic/basics/profiles.html
So, you would need to prepare multiple matrices and use them accordingly, e.g. set to each vehicle the proper one and specify matrix paths using -m option in the order of profiles definition in the problem

from vrp.

I agree with what @reinterpretcat says. The speed of a vehicle is typically defined by the matrix generator and the profile used for for traversing the map.

You can see a bunch of provided profiles by OpenRouteService's api here. Just click on the profiles dropdown.

And here is a short list too.

from vrp.

Thanks to both for your replies! I agree that the best way to do it for a certain type / group of vehicles is through using different matrix profiles - and vrp nicely supports providing multiple matrices as input, which is amazing. In the end, you can even apply a scaling factor to travel times in already calculated matrices and manage types / groups of vehicles that way.

This feature allows adjusting those values further on individual driver level - e.g. this driver in practice takes on average 20% more time than baseline, this one is faster and needs 10% less time etc...Basically, when calculating for this vehicle, instead of using the value directly from the matrix, the factor gets applied to it first.

To re-iterate, just hoping to give additional information if you guys consider it useful, the feature set you have is quite rich and broad already! :)

Based on our customers' experiences, this is crucial for them to take into account when time-windows are very tight and deliveries dense (e.g. food delivery), as individual driver "performance" can vary up to 20-30% above and below the baseline, so it changes the overall solution completely. It exists as an input in multiple commercial solutions (e.g. Maxoptra, WorkWave...), is being added to VROOM library etc...

from vrp.

I've refactored a bit a pragmatic format to have the setting consistent: it is part of vehicle profile via fleet.vehicles.profile scale property (available in master). Ideally, it should be moved to fleet.drivers, but drivers-vehicles match feature is not yet landed.

from vrp.

Amazing, thank you very much for your support and very quick response!

from vrp.