VROOM-Project
Job Performance rate
Hi! Thank you for the great project! We use VRoom to plan fitters. It would be perfect if we could also specify a level of performance for the vehicle. Example: The service job has a duration of 15 minutes, for example. The driver of Vehicle 1 needs 100% = 15 min because he works normally. However, the driver of Vehicle 2 takes longer and only has an efficiency level of 70% = 19.5 min. He is new at his Job and not so well incorporated. Of course, someone can also work faster than the average (15min) and would then have, for example, 120%. Not everyone works as fast as the other and so it can be planned optimally. Can this feature be integrated?
Thanks for your feedback and input, I see your point here and this would probably be useful in several situations.
Technically speaking, I think this is doable without changing the way the overall solving approach works. We'd have to store a rate multiplier at the vehicle level and apply that whenever we need to evaluate time spent at a job (both for validity checks or when actually modifying a route).
The possible complication I foresee is that when evaluating potential gains related to small route changes, we currently only take into account travel time costs, because service times are, well, constants so far. Now it may require to toy with the very notion of "gain" if we need to distinguish a situation where allocating some jobs to a "fast" worker is better because of the reduced service time (e.g. in the long run it allows to fit more jobs in).
Another practical downside would be that people may then complain that a single factor at vehicle level is not enough, and would want to be able to apply a different rate based on the job type. This would come down to defining a matrix of vehicles/jobs service times, which I think would be fairly unpractical/unreasonable in term of API bloating.
Of course you can expand the topic. But I think one factor per vehicle would be a good approach. I think adding the service time to the travel time would be the right way
I'm interested in working on this and submitting a PR. To be honest (as mentioned in 358 which unfortunately got de-prioritized for now, but looking to pick it up when possible), the environment (C++ etc) is pretty unfamiliar to me, as well as most of the inner workings of the codebase, but I was hoping, @jcoupey, that you would be so kind (as usual) to potentially give some initial pointers to get started?
For the first iteration, if your opinion is that the initial solution only affecting travel times would be much simpler, I would go this route, and add a simple per-vehicle factor, without going into detail on multiple job types, as I agree it seems "bloaty". The second phase, if it makes sense, could be to cover service times as well.
Thank you again for the amazing project and support you're providing here - really looking forward to contributing.
For the first iteration, if your opinion is that the initial solution only affecting travel times would be much simpler, I would go this >route, and add a simple per-vehicle factor,
If I get it right, you have in mind to scale all travel times (instead of service times) based on this factor?
If that would require less changes and be simpler to implement for the first iteration (as I understood from your previous comments), my view is that it would bring the bulk of the benefits to a majority of use cases where service times are significantly lower than travel time. However, I would of course follow your guidance if you think otherwise or would only consider a solution that covers both.
I was just asking to make sure because in that case it's something more closely related to #394.
Jumping in from middle with my two cents.
Since there is no real bound on the ratio between total travel time and total service time of a route and it can vary significantly between routes, I think having vehicle-dependent travel time and service time separately would be a very useful extension.
I share your worry about API bloating @jcoupey and having two factors at the vehicle level might be the sweet spot for the flexibility of a general optimization API.
That sounds good to me as well, @senhalil.
@jcoupey - in relation to #394, it is very similar - however, I see 2 significant differences:
-
one use case is probably primarily tied to being able to use different vehicle profiles in one optimization, while the other (at least in our case) is tied to individual driver / vehicle performance (for example, due to differences in experience level).
-
implementation-wise, #394 would need to rely on multiple matrix requests to be able to account for other profile-specific conditions (e.g. differences in routes between trucks and bicycles), which is unfortunate given the ratio of optimization time spent on matrix calls in general, but there's hardly a way around it. This feature would, on the other hand, be able to depend on a singular matrix and scale results for a given vehicle based on the configured factors
On my side, I'm hoping implementing this could cover requirements for individual driver performance factors, but also some cases of different vehicle profiles, when routes are not necessarily that different (e.g. car vs van).
Scaling service times vs travel times, although similar in principle, would have different implications on the solving approach.
I agree that having a "speed factor" could be a work-around for plain multi-profile in some use-cases, but both are technically related to the extent that most changes required by #394 (points 2, 3 and 4 in the comments) are also a prerequisite to introducing travel time scaling. So this would be more easily handled in the scope of #394.
On the other hand, scaling service times would raise other questions regarding the optimization objective (https://github.com/VROOM-Project/vroom/issues/336#issuecomment-623926992).