The fleet consists of your drivers. Each driver is defined by their start_location
and (optionally) an end_location
.
"fleet": {
"driver_1": {
"start_location": {
"id": "depot",
"name": "800 Kingsway",
"lat": 49.2553636,
"lng": -123.0873365
},
"end_location": {
"id": "depot",
"name": "800 Kingsway",
"lat": 49.2553636,
"lng": -123.0873365
},
"shift_start": "8:00",
"shift_end": "17:00",
"min_visits": 14,
"capacity": 10,
"type": ["A", "B"],
"strict_start": true,
"breaks" : [
{
"id": "lunch",
"start": "12:00",
"end": "13:00"
},
{
"id": "client call",
"start": "15:00",
"end": "15:30",
"in_transit": true
}
]
},
"driver_2": {
"start_location": {
"id": "depot",
"name": "800 Kingsway",
"lat": 49.2553636,
"lng": -123.0873365
},
"end_location": {
"id": "depot",
"name": "800 Kingsway",
"lat": 49.2553636,
"lng": -123.0873365
},
"shift_start": "8:00",
"shift_end": "17:00",
"capacity": 5
}
}
PROPERTY | TYPE | REQUIRED |
---|---|---|
start_location | Location object | required |
end_location | Location object | optional |
shift_start | String ("hh:mm" 24hr format) | optional |
shift_end | String ("hh:mm" 24hr format) | optional |
capacity | Number (any unit) | optional |
type | String or Array | optional |
speed | String(faster, fast, normal(default), slow, very slow, bike) or Number | optional |
strict_start | Boolean | optional |
min_visits | Number | optional |
breaks | Array of Objects | optional |
The end-location is optional and may be omitted. It may be useful in cases to have open-ended routes in some situations.
shift_start
and shift_end
specify when the driver starts driving and when he/she needs to be finished. If you have an end_location
, then the shift_end
means the latest time that the driver has to arrive there; otherwise it is the latest time that the driver can do their last job. Both parameters are optional. Without a shift_start
, the algorithm will automatically infer the best time to depart, depending on your visits' time-windows.
capacity
is an optional parameter to define the total capacity that can fit in the vehicle (using the same unit as the load
for your visits). The algorithm will make sure that this capacity will not be exceeded.
Capacity + loads
In order to use the capacity constraint, make sure that you also define the
load
parameters on the visits. If loads are not set, it is assumed that the visit does not take up any room in the capacity of the fleet.If you'd like to use capacity as a limit of x number of orders, then use
load: 1
for each visit.
Multiple capacities
You may also specify multiple load and capacity parameters if you provide an object instead of a number. This is useful if you define your capacity across multiple dimensions, for example weight and volume:
"capacity": { "weight": 1000, "volume": 200 }
You can specify your own dimensions as well. See
load
parameter on the Visits section for more examples.Note that if you specify multiple capacities, for loads to fit, it has to fit across all dimensions. So if you have plenty of weight capacity left, but in terms of volume it's already full, then the load won't fit.
If you are using type restrictions on your visits, make sure you also define the same types for your vehicles in the type
parameter. This value can be either a String — depicting a single type — or an Array of Strings for multiple types. Vehicles without any type will still be able to serve the visits that have no type restrictions.
speed
: Not all your drivers are as experienced and may cruise the roads at different speeds. Use this parameter to specify the driver's speed. The default value for speed
is normal or 1. Each step increases or decreases the vehicle speed by 25%, so for example very slow would describe a driver travelling at 50% of a normal driver's speed. For more control over the speed, you can also pass in a (decimal) number from 0.1 to 2. A speed of 0.1 would mean the vehicle is travelling at 10% speed while 2 means the vehicle is travelling at twice the speed.
If your fleet consists of bikes, you may use
bike
as thespeed
parameter, which reduces the speed to 25% of a normal vehicle.
strict_start
is a flag to force the departure time of a driver to be at shift_start
. By default this flag is set to false
, which means that the algorithm will attempt to delay the departure of a driver, if it results in reduced idle_time
along the route. Do note that if strict_start
is set to false and driver breaks are enabled, our routing algorithm will treat the problem as if you had sent strict_start: true
.
min_visits
is an optional parameter that allow you to specify a minimum number of visits that should be assigned to this vehicle. Specifying min_visits
will override the global min_visits_per_vehicle
parameter (see Options below). This is useful to balance the orders across your fleet when your drivers work different shift lengths.
Breaks
You can specify one or more breaks for your drivers. This could be a lunch break, some personal errand, or even a pre-scheduled call your driver needs to take while transiting. It basically allows you to block off parts of your shift; Routific will optimize your stops around it.
breaks
expects an array of objects. Each object requires anid
,start
andend
times of the break, and you can optionally specify that the break can be takenin_transit
– e.g. a call that you take in the car. Here's an example:"breaks" : [ { "id": "lunch", "start": "12:00", "end": "13:00", }, { "id": "client call", "start": "15:00", "end": "15:30", "in_transit": true } ]
In the solution, a break in your schedule is returned as follows:
{ id: "lunch", break: true, arrival_time: "12:11", finish_time: "13:00", start: "12:30", end: "13:00", in_transit: false }
Note: Driver breaks are not supported on our
/pdp
andpdp-long
endpoints.