This feature is configurable via .json
input, without the need for code customization and is available for both the Marketplace app and Platform. You can find a list of all available features here.
The format for timestamps should be RFC3339
, e.g.: "2023-01-01T00:00:00Z"
.
This how-to guide assumes you already completed the get started with vehicle routing tutorial.
Field name | Required | Data type | SI Unit | Defined on | Example | Configurable via defaults |
---|---|---|---|---|---|---|
start_time_window | No | array of timestamp or array of array of timestamp | NA | stop | {"start_time_window": [["2023-01-01T12:00:00Z", "2023-01-01T12:05:00Z"], ["2023-01-01T12:30:00Z", "2023-01-01T13:35:00Z"]]} | ✅ |
In vehicle routing problems stops often have to be serviced within specific time windows. E.g., in a bike sharing problem the stations have to be filled up with bikes while they are empty or bikes have to be picked up while they are full.
The start_time_window
feature allows you to define a time window (or multiple time windows) for when a stop must start to be serviced. The time window is an array
of two timestamps (or array
of array
of two timestamps), defined by the earliest and latest times at which a stop can start service.
A vehicle may arrive before the start_time_window
opens, in which case it will have to wait to start servicing the stop. The waiting time can be limited by using the max_wait
feature.
Here is an example that defines time windows on stops. A sample output obtained after solving the problem is also shown.
Here is an example using multiple time windows on stops.