You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up on #2730. There, functionality has been added to give more flexibility to manage stop times in DRT.
In particular, we show that, currently, we can have requests that have a wait time < stopDuration and that vehicles always stop exactly for the stopDuration, not longer not shorter.
The other approach, which seems more coherent, is to always require agents to wait at least stopDuration, which may inflate the time that vehicles idle at a stop.
This scenario only appears when a vehicle is already stopping (picking up / dropping off passengers) and a new pickup is dispatched into that stop task. If the stop is already ongoing for 40s and stopDuration = 60s, the new request will only wait 20s. The updated logic would be that the stop duration is inflated to 100s to make the incoming request wait for 60s.
Consequently, it may make sense to rename stopDuration to minimumStopDuration.
This functionality is already included (see #2730), the present issue is only about inquiring what people think of making this the default behaviour and renaming the config option.
The text was updated successfully, but these errors were encountered:
sebhoerl
changed the title
drt: change default behavior of stop timing (avoiding zero wait time))
drt: change default behavior of stop timing (avoiding zero wait time)
Oct 30, 2023
I think it is OK to change the default behaviour. My main concern is backward compatibility and having clear names/comments of parameters in the config group to avoid confusion.
So far stopDuration means the (minimum) stop duration for a vehicle. Changing the default behaviour means that we need a parameter that describes the (minimum) duration per each passenger (onbording or alighting). I do not think we should reuse one parameter name for different purposes.
Re (minimum): in both cases "(minimum)" means that the actual value may be bigger (e.g. a vehicle arrived early and waits for a passenger).
So I would suggest keeping the existing parameter (for the current default) and adding a new one (for the new default). Then we can decide if we want to:
ignore the old one (and add a warning or throw an exception)
require the user to provide only one of these 2 params and then, depending on which one is provided, enable the corresponding behaviour.
This is a follow-up on #2730. There, functionality has been added to give more flexibility to manage stop times in DRT.
In particular, we show that, currently, we can have requests that have a wait time
< stopDuration
and that vehicles always stop exactly for thestopDuration
, not longer not shorter.The other approach, which seems more coherent, is to always require agents to wait at least
stopDuration
, which may inflate the time that vehicles idle at a stop.This scenario only appears when a vehicle is already stopping (picking up / dropping off passengers) and a new pickup is dispatched into that stop task. If the stop is already ongoing for
40s
andstopDuration = 60s
, the new request will only wait20s
. The updated logic would be that the stop duration is inflated to100s
to make the incoming request wait for60s
.Consequently, it may make sense to rename
stopDuration
tominimumStopDuration
.This functionality is already included (see #2730), the present issue is only about inquiring what people think of making this the default behaviour and renaming the config option.
The text was updated successfully, but these errors were encountered: