Vehicle routing problem analysis
Various organizations service orders with a fleet of vehicles. For example, a large furniture store might use several trucks to deliver furniture to homes. A specialized company might route trucks from a facility to pick up used grease from restaurants. A health department might schedule daily inspection visits for each of its health inspectors.
 |
The problem that is common to the examples listed above is the vehicle routing problem (VRP). Each organization needs to determine which orders (homes, restaurants, or inspection sites) should be serviced by each route (truck or inspector) and in what sequence the orders should be visited. The primary goal is to service the orders and minimize the overall operating cost for the fleet of vehicles. Thus, while the Network Analyst route solver finds the best route for a single vehicle to visit many stops, the VRP solver finds the best routes for a fleet of vehicles to service many orders. In addition, the VRP solver can solve more specific problems because numerous options are available, such as matching vehicle capacities with order quantities, giving breaks to drivers, and pairing orders so they are serviced by the same route.
Solving a vehicle routing problem follows the same workflow as other network analyses.
Learn more about the network analysis workflow
Vehicle routing problem analysis layer
The vehicle routing problem analysis layer stores the inputs, parameters, and results for a given vehicle routing problem.
Creating a vehicle routing problem analysis layer
You can create the vehicle routing problem analysis layer from the Network Analyst toolbar by clicking Network Analyst > New Vehicle Routing Problem.
 |
When you create a vehicle routing problem analysis layer, it appears in the Network Analyst window along with its 13 network analysis classes—Orders, Depots, Routes, Depot Visits, Breaks, Route Zones, Route Seed Points, Route Renewals, Specialties, Order Pairs, Point Barriers, Line Barriers, and Polygon Barriers.
 |
The vehicle routing problem analysis layer also appears in the Table of Contents as a composite layer, which is named Vehicle Routing Problem or, if a vehicle routing problem with the same name already exists in the map document, Vehicle Routing Problem 1, Vehicle Routing Problem 2, and so on. There are nine feature layers—Orders, Depot Visits, Depots, Route Seed Points, Routes, Route Zones, Point Barriers, Line Barriers, and Polygon Barriers. Each of the nine feature layers has default symbology that can be modified on its Layer Properties dialog box.
Note:Since the breaks, specialties, order pairs, and route renewals are tables, they don't appear in the table of contents.
 |
Vehicle routing problem analysis classes
The vehicle routing problem analysis layer is made up of 13 network analysis classes, which are either feature layers or tables stored within the analysis layer. They contain the network analysis objects used when solving the vehicle routing problem. The relationships between various network analysis classes are shown in the following document:
Relationships between network analysis classes in the vehicle routing problemAn overview of each class and descriptions of their properties are provided in the following sections.
Learn more about network analysis classes
Orders feature layer
This feature layer stores the orders that are part of a given vehicle routing problem analysis layer. An order can be a delivery to a customer (for example, furniture delivery), a pickup from a customer (such as grease pickup from restaurants) or some other type of work (an inspection visit, for example).
If orders have items to be picked up or delivered, the items can have one or many capacities, which can be based on any form of measurement or combination of measurements you want, such as weight, volume, or number of units. Some orders, like inspection visits, may not have any deliveries or pickups associated with them.
An order can have a service time, which is the time needed to complete the work at the order. For example, a delivery truck may require a 20-minute service time to unload a piece of furniture and move it inside a home. The service time can be the same for all orders, or it can be unique for each order.
An order can have one or two time windows, which indicate when a vehicle is allowed to visit the order. For example, a wholesale foods delivery truck is only permitted to arrive at a restaurant between 8:00 and 10:00 a.m. or between 2:00 and 4:00 p.m. because arriving at any other time would disrupt the restaurant's business.
Specialties can be associated with an order. That is, an order may require a technician with a certain skill set (for example, an electrician) or a vehicle with certain capabilities (a power lift). Only a route that has the same specialty will be assigned to the order.
Order properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Shape |
The geometry field indicating the geographic location of the network analysis object. |
|
Name |
The name of the network analysis object. The name must be unique. This field acts as a primary key and is used as a foreign key to refer to orders in the OrderPairs table. Order names are case insensitive and cannot be empty, even if the order is excluded from the solve operation. |
|
Description |
The descriptive information about the order. This can contain any textual information for the order and has no restrictions for uniqueness. You may want to store a client's ID number in the Name field and the client's actual name or address in the Description field. |
|
ServiceTime |
This property specifies how much time will be spent at the network location when the route visits it. That is, it stores the impedance value for the network location. If this field value is zero or null, the network location requires no service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TimeWindowStart1 |
The beginning time of the first time window for the network location. This field can contain a null value; a null value indicates no beginning time. (See the note below this list of properties for more information.) |
|
TimeWindowEnd1 |
The ending time of the first window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this list of properties for more information.) |
|
TimeWindowStart2 |
The beginning time of the second time window for the network location. This field can contain a null value; a null value indicates that there is no second time window. If the first time window is null, as specified by the TimeWindowStart1 and TimeWindowEnd1 fields, the second time window must also be null. If both time windows are nonnull, the second time window must be after the first in time and can't overlap the first. (See the note below this list of properties for more information.) |
|
TimeWindowEnd2 |
The ending time of the second time window for the network location. This field can contain a null value. When TimeWindowStart2 and TimeWindowEnd2 are both null, there is no second time window. When TimeWindowStart2 is not null but TimeWindowEnd2 is null, there is a second time window that has a starting time but no ending time. This is valid. (See the note below this list of properties for more information.) |
|
MaxViolationTime1 |
A time window is considered violated if the arrival time falls beyond the time window. This field specifies the maximum allowable violation time for the first time window of the order. It can contain a zero value but can't contain negative values. A zero value indicates that a time-window violation at the first time window of the order is unacceptable; that is, the first time window is hard. On the other hand, a null value indicates that there is no limit on the allowable violation time. A nonzero value specifies the maximum amount of lateness; for example, a route can arrive at an order up to 30 minutes beyond the end of its first time window. The unit for this field value is specified by the Time Field Units property of the analysis layer. Time window violations can be tracked and weighted by the solver. Because of this, you can direct the VRP solver to take one of three approaches:
By assigning an importance level for the Time Window Violation setting of the analysis layer, you are essentially choosing one of these three approaches. In any case, however, the solver will return an error if the MaxViolationTime1 is surpassed. |
|
MaxViolationTime2 |
The maximum allowable violation time for the second time window of the order. This field is analogous to the MaxViolationTime1 field. |
|
DeliveryQuantities |
The amount (for example, weight, volume, quantity) being delivered to the order. If the order requires 2,000 pounds of goods, then the Capacity Count parameter in the analysis layer's Layer Properties dialog box should be set to 1, and DeliveryQuantities should be set to 2000. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, then the DeliveryQuantities values are separated by a space. For instance, when both weight and volume are known, the Capacity Count in the analysis layer's Layer Properties dialog box should be set to 2. If the order requires 2,000 pounds of goods, which occupy 100 cubic feet, DeliveryQuantities should be set to 2000 100. An empty string or null value is equivalent to all quantities being zero. If the string has an insufficient number of values in relation to the capacity count, the remaining values are treated as zeros. Delivery quantities can't be negative. |
|
PickupQuantities |
The amount (for example, volume, weight, quantity) being picked up at the order. The quantities can't be negative. This field is analogous to the DeliveryQuantities field.
Note: In the case of an exchange visit, an order can have both delivery and pickup quantities. |
|
Revenue |
The income generated if the order is included in a solution. This field can contain a null value—a null value indicates zero revenue—but it can't have a negative value. Revenue is included in optimizing the objective function value but is not part of the solution's operating cost. That is, the TotalCost property in the route class never includes Revenue in its output; however, revenue weights the relative importance of servicing orders. |
|
SpecialtyNames |
A space-separated string containing the names of the specialties required by the order. A null value indicates that the order doesn't require specialties. This field is a foreign key to the Name field in the Specialties table. Specialty objects must exist before they will appear in the SpecialtyNames drop-down list. For instance, a lawn care company may need to service an order with a pesticide that requires an applicator license. The company could create a Specialty object called License and set this property to License. |
|
AssignmentRule |
This property specifies the rule for assigning the order to a route. It is constrained by a domain of values, which are listed below (their coded values are shown in parentheses).
This field can't contain a null value. |
|
Network location fields
|
Together, these four properties describe the point on the network where the object is located. |
|
CurbApproach |
The CurbApproach property specifies the direction a vehicle may arrive at and depart from the network location. There are four choices (their coded values are shown in parentheses):
|
Note:-
A time window only states when a vehicle can arrive at an order; it doesn't state when the service time must be completed. To account for service time and leave before the time window is over, subtract ServiceTime from the TimeWindowEnd1 field.
-
The time window fields can contain a time-only value or a date and time value. If a time field such as TimeWindowStart1 has a time-only value (for example, 8:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2010 8:00 AM) allows you to set time windows that span multiple days.
-
If you are using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge that the network location is located on.
|
Input/Output field |
Description |
|---|---|
|
RouteName |
The name of the route to which the order is assigned. As an input field, this field is used to preassign an order to a specific route. It can contain a null value indicating that the order is not preassigned to any route and the solver determines the best possible route assignment for the order. If this is set to null, the sequence field must also be set to null. The RouteName field is a foreign key to the Name field in the Routes class. Route objects must exist before they will appear in the RouteName drop-down list. After a solve operation, if the order is routed, the RouteName field contains the name of the route that the order is assigned to. |
|
Sequence |
This indicates the sequence of the order on its assigned route. As an input field, this field is used to specify the relative sequence for an order on the route. This field can contain a null value specifying that the order can be placed anywhere along the route. A null value can only occur together with a null RouteName value. The input sequence values are positive and unique for each route (shared across renewal depot visits, orders, and breaks), but do not need to start from 1 or be contiguous. After a solve operation, the Sequence field contains the Sequence value of the order on its assigned route. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. So the smallest possible output Sequence value for a routed order is 2, since a route always begins at a depot. |
|
Status |
This field is constrained by a domain of values, which are listed below (their coded values are shown in parentheses).
After a solve operation, the status can be modified using one of the following status values:
If time windows are used and the route arrives early or late, the value changes to Time window violation (6). |
Note:If the order has an AssignmentRule field value of Exclude, then the input values for the Status, RouteName, and Sequence fields are not changed during the solve operation.
|
Output field |
Description |
|---|---|
|
ViolatedConstraints |
This field contains a summary of violated constraints and is set after a solve operation. A combination of one or more of the violations listed below could be assigned to the field if assigning the order to any of the routes would cause a constraint to be violated,.  Dive-in:The coded value that represents the text description is shown in the list below in parentheses. Notice that the coded values are part of a geometric sequence that increases by doubling the last value. This allows various combinations of violations to be coded. For instance, the combination of Capacities exceeded (2) and Hard route zone (128), is coded as 130 (2 +128).
Learn more about troubleshooting network analyses Note:The ViolatedConstraints value of an unrouted order may or may not describe all its violations. If the violation is severe enough to immediately exclude the order from further consideration, the solver does so, which prevents any other violations from being discovered for that order. If a violation is encountered that doesn't automatically stop a solution from being generated, then the violation is noted in ViolatedConstraints, and the solver continues to consider the order. Any further violations like these are added to the ViolatedConstraints field until either (a) the solver finds a violation that prematurely stops the solve process for that particular order or (b) the solver finds an overall solution to the problem. |
|
FromPrevTravelTime |
The travel time from the preceding visit on the route to the order. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
FromPrevDistance |
The travel distance from the preceding visit on the route to the order. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTravelTime |
The cumulative travel time for the route up to the arrival at the order. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulDistance |
The cumulative travel distance for the route up to the arrival at the order. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTime |
The cumulative route duration up to and including the order. The cumulative duration includes travel times as well as service and wait times at orders. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
ArriveCurbApproach |
Indicates which side of the vehicle the curb is on when the vehicle approaches the network location. If the network location's CurbApproach value is set to Right side of vehicle, the ArriveCurbApproach after solving is Right side of vehicle. However, if the CurbApproach value is set to Either side of vehicle or No U-Turn, the ArriveCurbApproach could be on the right or left side depending on which produces the overall shortest path. |
|
DepartCurbApproach |
Indicates which side of the vehicle the curb is on when the vehicle departs the network location. If the network location's CurbApproach value is set to Right side of vehicle, the DepartCurbApproach after solving is Right side of vehicle. However, if the CurbApproach value is set to Either side of vehicle or No U-Turn, the DepartCurbApproach could be on the right or left side depending on which produces the overall shortest path. |
|
ArriveTime |
The date and time value indicating the arrival time at the order. The route may arrive at the order before the beginning of one of the order's time windows, in which case there is a wait time at the order. For an order with soft time windows, the route may also arrive at the order after the end of one of the time windows, in which case there is a violation time at the order. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the order is located on. |
|
DepartTime |
The date and time value indicating the departure time from the order. The route departs from the order upon completion of service. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the order is located on. |
|
WaitTime |
The wait time or layover at the order. For example, you get a wait time value if a route must wait at the order for a time window to open. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
ViolationTime |
The amount of time elapsed between the end of the order's time window and the arrival of the route vehicle. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulWaitTime |
The cumulative wait time from the beginning of the route up to and including the order. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulViolationTime |
The cumulative violation time from the beginning of the route up to and including the order. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
Depots class
This network analysis class stores the depots that are part of a given vehicle routing problem analysis layer. A depot is a location that a vehicle departs from at the beginning of its workday and returns to at the end of the workday. Depots are locations where the vehicles are loaded (for deliveries) or unloaded (for pickups). In some cases, a depot can also act as a renewal location whereby the vehicle can unload or reload and continue performing deliveries and pickups. A depot has open and close times, as specified by a hard time window. Vehicles can't arrive at a depot outside this time window.
Depot properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Shape |
The geometry field indicating the geographic location of the network analysis object. |
|
Name |
The name of the network analysis object. This field is a primary key and is used as a foreign key in the Routes feature layer, RouteRenewals table, and Depot Visits feature layer to refer to depots. Depot names are case insensitive and have to be nonempty and unique. |
|
Description |
The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness. Perhaps you want to note what region a depot is in or the depot's address and telephone number; you could enter this information here rather than in the Name field. |
|
TimeWindowStart1 |
The beginning time of the first time window for the network location. This field can contain a null value; a null value indicates no beginning time. (See the note below this list of properties for more information.) |
|
TimeWindowEnd1 |
The ending time of the first window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this list of properties for more information.) |
|
TimeWindowStart2 |
The beginning time of the second time window for the network location. This field can contain a null value; a null value indicates that there is no second time window. If the first time window is null, as specified by the TimeWindowStart1 and TimeWindowEnd1 fields, the second time window must also be null. If both time windows are nonnull, the second time window must be after the first in time and can't overlap the first. (See the note below this list of properties for more information.) |
|
TimeWindowEnd2 |
The ending time of the second time window for the network location. This field can contain a null value. When TimeWindowStart2 and TimeWindowEnd2 are both null, there is no second time window. When TimeWindowStart2 is not null but TimeWindowEnd2 is null, there is a second time window that has a starting time but no ending time. This is valid. (See the note below this list of properties for more information.) |
Network location fields
| Together, these four properties describe the point on the network where the object is located. |
|
CurbApproach |
The CurbApproach property specifies the direction from which a vehicle may arrive at and depart from the depot. It is useful for vehicles that need to approach and depart a depot from a specific direction or avoid making U-turns. You can accommodate these requirements by choosing one of the following four values for CurbApproach:
|
Note:-
The time window fields can contain a time-only value or a date and time value. If a time field such as TimeWindowStart1 has a time-only value (for example, 8:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2010 8:00 AM) allows you to set time windows that span multiple days.
-
If you are using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge that the network location is located on.
|
Input/Output field |
Description |
|---|---|
|
Status |
This field is constrained by a domain of values, which are listed below (their coded values are shown in parentheses).
After a solve operation, the status can be modified using one of the following status values:
If time windows are used and the route arrives early or late, the value changes to Time window violation (6). |
Routes class
This network analysis class stores the routes that are part of a given vehicle routing problem analysis layer. A route specifies the vehicle and driver characteristics as well as represents the traversal between depots and orders. In ArcGIS Network Analyst, vehicles, routes, and drivers are synonymous, and the term "route" is used to encompass all three.
Note:The VRP solver is not designed to consider the same vehicle being used across workday shifts in a single routing solution or the changing of drivers within a workday.
A route may spend time loading or unloading at start or end depots. The amount of time spent at a depot is fixed for the route and is specified as start and end depot service times.
A route may start at a fixed time, or it may have a flexible start time; that is, it may have an earliest-to-latest start time range. The start time range and the time window of the starting depot are taken into account when determining the actual start time of the route.
The operating cost for an individual route can be made up of time-based costs, distance-based costs, and/or fixed costs that are independent of the amount of time worked or the distance driven. For example, there may be a fixed cost associated with using a vehicle if additional vehicles are to be rented to handle high-workload days. Similarly, the driver may be paid for the number of hours worked, inclusive or exclusive of overtime and lunch breaks. Such costs may be used to specify time-based costs. The fuel costs may be used to specify distance costs.
The vehicle operating on a given route may also have a capacity, which limits how much it can carry.
There may be constraints on a driver's workday such as the total distance driven or the number of hours a driver can work or drive due to state regulations or labor union agreements.
The route may include work breaks. The driver may or may not be paid for these breaks.
A vehicle may have certain capabilities, for example, a power lift or special shielding, or technicians may have different skill sets. The orders that have these specialties defined on them must be assigned to the appropriate routes.
A route may be associated with a zone if the route is restricted to work in a predefined geographic region.
Routes are line features. They can be imported from existing routes in other vehicle routing problem analysis layers, from other linear features, or from tables. They can also be created using the Add Item command.
Route properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Name |
The name of the network analysis object. This field is the primary key and is used as a foreign key in the Orders feature layer, Breaks table, Route Zones feature layer, Route Seed Points feature layer, Route Renewals table, and Depot Visits feature layer. Route names are case insensitive and cannot be empty, even if the route is not part of the solve operation. The name must be unique. |
|
Description |
The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness. |
|
StartDepotName |
The name of the starting depot for the route. This field is a foreign key to the Name field in the Depots class. Depot objects must exist before they will appear in the StartDepotName drop-down list. If the StartDepotName is null, the route will begin from the first order assigned. Omitting the start depot is useful when the vehicle's starting location is unknown or irrelevant to your problem. However, when the StartDepotName is null, the EndDepotName cannot also be null. If the route is making deliveries and the StartDepotName is null, it is assumed the vehicle is loaded at a virtual depot before the route begins. For a route that has no renewal visits, its delivery orders (those with nonzero DeliveryQuantities values in the Orders class) are loaded at the start depot or virtual depot. For a route that has renewal visits, only the delivery orders before the first renewal visit are loaded at the start depot or virtual depot. |
|
EndDepotName |
The name of the ending depot for the route. This field is a foreign key to the Name field in the Depots class. Depot objects must exist before they will appear in the EndDepotName drop-down list. If the EndDepotName is null, the route will end at the last order assigned. Omitting the end depot is useful when the vehicle's ending location is unknown or irrelevant to your problem. However, when the EndDepotName is null, the StartDepotName cannot also be null. If the route is making pickups and the EndDepotName is null, it is assumed the vehicle is unloaded at a virtual depot after completion of the route. For a route that has no renewal visits, its pickup orders (those with nonzero PickupQuantities values in the Orders class) are unloaded at the end depot or virtual depot. For a route that has renewal visits, only the pickup orders after the last renewal visit are unloaded at the end depot or virtual depot. |
|
StartDepotServiceTime |
The service time at the starting depot. This can be used to model the time spent for loading the vehicle. This field can contain a null value; a null value indicates zero service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Note:The service times at the start and end depots are fixed values (given by the StartDepotServiceTime and EndDepotServiceTime field values) and do not take into account the actual load for a route. For example, the time taken to load a vehicle at the starting depot may depend on the size of the orders. As such, the depot service times could be given values corresponding to a full truckload or an average truckload, or you could make your own time estimate. |
|
EndDepotServiceTime |
The service time at the ending depot. This can be used to model the time spent for unloading the vehicle. This field can contain a null value; a null value indicates zero service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Note:The service times at the start and end depots are fixed values (given by the StartDepotServiceTime and EndDepotServiceTime field values) and do not take into account the actual load for a route. For example, the time taken to load a vehicle at the starting depot may depend on the size of the orders. As such, the depot service times could be given values corresponding to a full truckload or an average truckload, or you could make your own time estimate. |
|
EarliestStartTime |
The earliest allowable starting time for the route. This is used by the solver in conjunction with the time window of the starting depot for determining feasible route start times. This field can't contain null values and has a default time-only value of 8:00 AM; the default value is interpreted as 8:00 AM on the date given by the Default Date property of the analysis layer. When using network datasets with traffic data across multiple time zones, the time zone for EarliestStartTime is the same as the time zone of the edge or junction that the starting depot is located on. |
|
LatestStartTime |
The latest allowable starting time for the route. This field can't contain null values and has a default time-only value of 10:00 AM; the default value is interpreted as 10:00 AM on the date given by the Default Date property of the analysis layer. When using network datasets with traffic data across multiple time zones, the time zone for LatestStartTime is the same as the time zone of the edge or junction that the starting depot is located on. |
| ArriveDepartDelay |
This field stores the amount of travel time needed to accelerate the vehicle to normal travel speeds, decelerate it to a stop, and move it off and on the network (for example, in and out of parking). By including an ArriveDepartDelay, the VRP solver is deterred from sending many routes to service physically coincident orders. The cost for this property is incurred between visits to noncoincident orders, depots, and route renewals. For example, when a route starts from a depot and visits the first order, the total arrive-depart delay is added to the travel time. The same is true when traveling from the first order to the second order. If the second and third orders are coincident, the ArriveDepartDelay is not added between them since the vehicle doesn't need to move. If the route travels to a route renewal, the ArriveDepartDelay is added to the travel time again. Although a vehicle needs to slow down and stop for a break and accelerate afterwards, the VRP solver cannot add the ArriveDepartDelay value for breaks. This means that if a route leaves an order, stops for a break, and continues to the next order, the arrive-depart delay is added only once, not twice. Say there are five coincident orders in a high-rise building, and they are serviced by three different routes. This means three arrive-depart delays would be incurred; that is, three drivers would need to find parking places and enter the same building. However, if the orders could be serviced by just one route instead, only one driver would need to park and enter the building—only one arrive-depart delay would be incurred. Since the VRP solver tries to minimize cost, it will try to limit the arrive-depart delays and thus choose the single-route option. (Note that multiple routes may need to be sent when other constraints—such as specialties, time windows, or capacities—require it.) The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
Capacities |
The maximum amount (for instance, volume, weight, quantity) that can be carried by the vehicle. If a vehicle can carry a maximum of 40,000 pounds, then the Capacity Count in the Layer Properties dialog box of the analysis layer should be set to 1, and Capacities should be set to 40000. Similarly, if a vehicle can carry 1,000 cubic feet, the Capacity Count should be set to 1, and Capacities should be set to 1000.  Caution:The VRP solver only performs a simple Boolean test to determine whether capacities are exceeded. If a route's capacity value is greater than or equal to the total quantity being carried, then the VRP solver will assume the cargo fits in the vehicle. This could be incorrect, depending on the actual shape of the cargo and the vehicle. For example, the VRP solver allows you to fit a 1,000-cubic-foot sphere into a 1,000-cubic-foot truck that is eight feet wide. In reality, however, since the sphere is 12.6 feet in diameter, it won't fit in the eight-foot wide truck. If there are multiple capacities, as specified by the Capacity Count parameter of the analysis layer, then the values of Capacities are separated by a space. For instance, when both the maximum weight and volume of the vehicle are used, the Capacity Count in the Layer Properties dialog box of the analysis layer should be set to 2; if the vehicle can carry a weight of 40,000 pounds and a volume of 2,000 cubic feet, Capacities should be set to 40000 2000. An empty string or null value is equivalent to all values being zero. Capacity values can't be negative. If the Capacities string has an insufficient number of values in relation to the capacity count, the remaining values are treated as zero. |
|
FixedCost |
A fixed monetary cost that is incurred only if the route is used in a solution (that is, it has orders assigned to it). This field can contain null values; a null value indicates zero fixed cost. This cost is part of the total route operating cost. |
|
CostPerUnitTime |
The monetary cost incurred—per unit time of work—for the total route duration, including travel times as well as service times and wait times at orders, depots, and breaks. This field can't contain a null value and has a default value of 1.0. The time unit is specified by the Time Field Units property of the analysis layer. |
|
CostPerUnitDistance |
The monetary cost incurred—per unit of distance traveled—for the route length (total travel distance). This field can contain null values; a null value indicates zero cost. The distance unit is specified by the Distance Field Units property of the analysis layer. The solver will return an error if this field is given a value and the Distance Attribute property is not specified for the analysis layer. |
|
OvertimeStartTime |
The duration of regular work time before overtime computation begins. This field can contain null values; a null value indicates that overtime does not apply. The time unit is specified by the Time Field Units property of the analysis layer. For example, if the driver is to be paid overtime pay when the total route duration extends beyond eight hours, then OvertimeStartTime is specified as 8 if the Time Field Units property of the analysis layer is set to Hours. |
| CostPerUnitOvertime |
The monetary cost incurred per unit time of overtime work. This field can contain null values; a null value indicates that the CostPerUnitOvertime value is the same as the CostPerUnitTime value. |
|
MaxOrderCount |
The maximum allowable number of orders on the route. This field can't contain null values and has a default value of 30. |
|
MaxTotalTime |
The maximum allowable route duration. The route duration includes travel times as well as service and wait times at orders, depots, and breaks. This field can contain null values; a null value indicates that there is no constraint on the route duration. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
MaxTotalTravelTime |
The maximum allowable travel time for the route. The travel time includes only the time spent driving on the network and does not include service or wait times. The unit for this field value is specified by the Time Field Units property of the analysis layer. This field can contain null values; a null value indicates there is no constraint on the maximum allowable travel time. This field value can't be larger than the MaxTotalTime field value. |
|
MaxTotalDistance |
The maximum allowable travel distance for the route. The unit for the total distance is specified by the Distance Field Units property of the analysis layer. This field can contain null values; a null value indicates that there is no constraint on the maximum allowable travel distance. The solver will return an error if this field is given a value and the Distance Attribute property is not specified for the analysis layer. |
|
SpecialtyNames |
A space-separated string containing the names of the specialties supported by the route. A null value indicates that the route does not support any specialties. This field is a foreign key to the Name field in the Specialties table. Specialty objects must exist before they will appear in the SpecialtyNames drop-down list. |
|
AssignmentRule |
This specifies whether the route can be used or not when solving the problem. This field is constrained by a domain of values, and the possible values are the following:
|
|
Output field |
Description |
|---|---|
|
Shape |
The line shape of the route. If the Output Shape Type property of the analysis layer is set to None, no shape is returned. Setting the Output Shape Type property to Straight Line returns straight route lines that connect each pair of consecutive visits. True Shape with measures and True Shape both return lines that trace their corresponding routes on the network, the difference being that True Shape with measures returns a line that is already linearly referenced by time. |
|
ViolatedConstraints |
This field contains a summary of violated constraints and is set after a solve operation. If a route causes a constraint to be violated, a combination of one or more of the violations listed below could be assigned to the field. Dive-in:The coded value that represents the text description is shown in the list below in parentheses. Notice that the coded values are part of a geometric sequence that increases by doubling the last value. This allows various combinations of violations to be coded. For instance, the combination of Capacities exceeded (2) and Hard route zone (128), is coded as 130 (2 +128).
|
|
OrderCount |
The number of orders assigned to the route. |
|
TotalCost |
The total operating cost of the route, which is the sum of the following field values:
|
|
RegularTimeCost |
The cost of regular work time, excluding any unpaid breaks. |
|
OvertimeCost |
The cost of overtime work, excluding any unpaid breaks. |
|
DistanceCost |
The distance cost component obtained by multiplying TotalDistance and CostPerUnitDistance field values. This field value is null if the Distance Attribute property is not specified for the analysis layer. |
|
TotalTime |
The total route duration. This includes travel times as well as service and wait times at orders, depots, and breaks. The TotalTime value is the sum of the following field values:
The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalOrderServiceTime |
The total service time spent at all orders on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalBreakServiceTime |
The total service time spent at all breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalTravelTime |
The total travel time for the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalDistance |
The total travel distance for the route. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
StartTime |
The starting time of the route. The route may start before the beginning of its start depot's time window, in which case there is a wait time at the starting depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the starting depot is located on. |
|
EndTime |
The ending time of the route. The route ends upon completion of service at the ending depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the ending depot is located on. |
|
TotalWaitTime |
The total wait time at all orders, depots, and breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalViolationTime |
The total violation time at all orders and breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
RenewalCount |
For a route with renewals, this is equal to the number of visits to depots for renewing. |
|
TotalRenewalServiceTime |
For a route with renewals, the total service time spent at all renewal visits on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
Depot Visits feature layer
When a route starts, renews (unloads or reloads), or ends at a depot, a depot visit is created. Depot visit objects provide information regarding why a route visited a depot and what happened there. The quantity of goods loaded on or unloaded from a vehicle at depot is recorded in the properties of a depot visit. Additional information that is useful in interpreting a vehicle routing problem solution is also included.
This is an output-only network analysis class. Depot visit features are created strictly during the solve operation; therefore, the analysis class is always empty before the solve process.
Depot Visits properties
|
Output field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Shape |
The geometry field indicating the geographic location of the network analysis object. |
|
DepotName |
The name of the visited depot. This field is a foreign key to the Name field in the Depots network analysis class. If the route uses a virtual depot, which means the route starts or ends at an order instead of a depot, the DepotName is null. |
|
RouteName |
The name of the route containing this visit. This field is a foreign key to the Name field in the Routes feature layer. |
|
Sequence |
Indicates the sequence of the visited depot on the route. The output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. |
|
VisitType |
The reason this depot was visited. This field is constrained by a domain of values.
|
|
ServiceTime |
The service time (such as loading or unloading) at the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
FromPrevTravelTime |
The travel time from the preceding visit on the route to the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
FromPrevDistance |
The travel distance from the preceding visit on the route to the depot. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTravelTime |
The cumulative travel time for the route up to the arrival at this depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulDistance |
The cumulative travel distance for the route up to the arrival at this depot. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTime |
The cumulative route duration up to and including the depot. The cumulative duration includes travel times as well as service and wait times at orders, depots, and breaks. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
ArriveTime |
The arrival time at the depot. The route may arrive at the depot before the beginning of the depot's time window, in which case there is wait time at the depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is the same as the network element that the depot is located on. |
|
DepartTime |
The departure time from the depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is the same as the network element that the depot is located on. |
|
WaitTime |
The wait time at the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulWaitTime |
The cumulative wait time from the beginning of the route up to and including the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulViolationTime |
The cumulative violation time from the beginning of the route up to and including the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
TotalLoadedQuantities |
The amount (for instance, volume, weight, quantity) being loaded at the depot. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, then they are separated by a space. For example, in case of deliveries, the value for the TotalLoadedQuantities field indicates the actual quantity of goods delivered by the vehicle before returning to a depot. This value is less than or equal to the Capacities field value for a given route, indicating that the route performs one truckload of deliveries. |
|
TotalUnloadedQuantities |
The amount (for example, volume, weight, quantity) being unloaded at the depot. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, then they are separated by a space. For example, in case of pickups or routes with renewals, the value for the TotalUnloadedQuantities field indicates the actual quantity of goods picked up by the vehicle and brought to the depot. This value is less than or equal to the Capacities field value for a given route, indicating that the route performs one truckload of pickups. |
Note:There is no ViolationTime output field on the Depot Visits feature layer since depots have hard time windows.
Breaks class
This is a nonspatial network analysis class that stores the rest periods, or breaks, for routes in a vehicle routing problem. A break is associated with exactly one route, and it can be taken after completing an order, while en route to an order, or prior to servicing an order. It has a start time and a duration, which the driver may or may not be paid for. You have three options for establishing when a break begins: you can enter a time window, a maximum travel time, or a maximum work time.
-
Time-window break—To set up a time-window break, you enter two time-of-day values to delimit a time range in which the break should begin. The TimeWindowStart and TimeWindowEnd fields hold the bounding time-of-day values. The duration, or service time, of the break is independent of the time window and, therefore, can extend beyond the end of the time window. For instance, if the time window for an hour-long break spans from 10:00 a.m. to 10:15 a.m., the break should start after 10:00 a.m. but before 10:15 a.m. If it starts at 10:10 a.m., the break will end at 11:10 a.m.
-
Maximum-travel-time break—With this kind of break, you specify how long a person can drive before the break is required. (Note that only travel time is limited, not other times like wait and service times.) If you enter four hours into the first break's MaxTravelTimeBetweenBreaks property, for example, the driver will receive a break before the accumulated travel time from the start of the route exceeds four hours. For any subsequent breaks, the travel time is accumulated from the previous break. So if you have a second break with a MaxTravelTimeBetweenBreaks value of two hours, the second break will be taken before two hours of travel time have been accumulated from the previous break, not from the start depot.
A route's final maximum-travel-time break not only limits the amount of accumulated travel time from the previous break or start of the route but also limits the travel time from the final break to the end depot. This is true even if there is only one break. The VRP solver is designed this way to prevent a route from taking all its breaks, then traveling for an extended period without taking another break. In the last example, MaxTravelTimeBetweenBreaks was set to two hours. If this is the route's final break, the route must be able to reach the end depot within two hours of travel time from the final break; otherwise, the solver will return an error.
Maximum-work-time break—This break specifies how long a person can work before a break is required. Unlike maximum-travel-time breaks, which can accumulate travel time from the end of the last break, maximum-work-time breaks always accumulate work time from the beginning of the route, including any service time at the start depot.
Note that this break limits the accumulated work time, which includes travel time and all service times; it excludes wait time, however.
A vehicle routing problem analysis layer can only be solved if all breaks are of the same type; that is, the solve process will fail if there is any combination of time-window, maximum-travel-time, and maximum-work-time breaks.
You can specify up to five breaks to a single route. For instance, assume you are using maximum-travel-time breaks for an analysis. You might assign two breaks to one route so that after two hours of travel time have been accumulated, the driver can rest for 15 minutes, and after two more hours of traveling, the driver can stop for a one-hour lunch break. You could have other routes with anywhere from zero to five breaks assigned to them.
Breaks have a Precedence field that orders them in a sequence. This way, if you want a 15-minute break to occur before a one-hour break, the precedence value of the 15-minute break should be 1, and the precedence value of the other should be 2. Precedence is required for all breaks, even though max-work-time and time-window breaks inherently have a chronological order.
If a route reaches the final destination before all maximum-travel-time or maximum-work-time breaks have been taken, the remaining breaks are ignored. If any time-window breaks remain at the end of a route, the route will wait until all breaks have been taken before finishing rather than finishing early.
Break properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
TimeWindowStart |
The starting time of the break's time window. If this field is null and TimeWindowEnd has a valid time-of-day value, the break is allowed to start anytime before the TimeWindowEnd value. If this field has a value, MaxTravelTimeBetweenBreaks and MaxCumulWorkTime must be null; moreover, all other breaks in the analysis layer must have null values for MaxTravelTimeBetweenBreaks and MaxCumulWorkTime. An error will occur at solve time if a route has multiple breaks with overlapping time windows. The time window fields in breaks can contain a time-only value or a date and time value. If a time field, such as TimeWindowStart, has a time-only value (for example, 12:00 PM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2010 12:00 PM) allows you to specify time windows that span two or more days. This is especially beneficial when a break should be taken sometime before and after midnight. When you use network datasets with traffic data across multiple time zones, the time zone for TimeWindowStart and TimeWindowEnd is assumed to be the same as the time zone of the edge or junction that the starting depot is located on. |
|
TimeWindowEnd |
The ending time of the break's time window. If this field is null and TimeWindowStart has a valid time-of-day value, the break is allowed to start anytime after the TimeWindowStart value. If this field has a value, MaxTravelTimeBetweenBreaks and MaxCumulWorkTime must be null; moreover, all other breaks in the analysis layer must have null values for MaxTravelTimeBetweenBreaks and MaxCumulWorkTime. See the description for TimeWindowStart (above) for more information. |
|
MaxTravelTimeBetweenBreaks |
The maximum amount of travel time that can be accumulated before the break is taken. The travel time is accumulated either from the end of the previous break or, if a break has not yet been taken, from the start of the route. If this is the route's final break, MaxTravelTimeBetweenBreaks also indicates the maximum travel time that can be accumulated from the final break to the end depot. This property is designed to limit how long a person can drive until a break is required. For instance, if the Time Field Units property of the analysis layer is set to Minutes, and MaxTravelTimeBetweenBreaks has a value of 120, the driver will get a break after two hours of driving. To assign a second break after two more hours of driving, the second break's MaxTravelTimeBetweenBreaks property should be 120. If this field has a value, TimeWindowStart, TimeWindowEnd, MaxViolationTime, and MaxCumulWorkTime must be null for an analysis to solve successfully. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
MaxCumulWorkTime | The maximum amount of work time that can be accumulated before the break is taken. Work time is always accumulated from the beginning of the route. Work time is the sum of travel time and service times at orders, depots, and breaks. Note, however, that this excludes wait time, which is the time a route (or driver) spends waiting at an order or depot for a time window to begin. This property is designed to limit how long a person can work until a break is required. For instance, if the Time Field Units property of the analysis layer is set to Minutes, MaxCumulWorkTime has a value of 120, and ServiceTime has a value of 15, the driver will get a 15-minute break after two hours of work. Continuing with the last example, assume a second break is needed after three more hours of work. To specify this break, you would enter 315 (five hours and fifteen minutes) as the second break's MaxCumulWorkTime value. This number includes the MaxCumulWorkTime and ServiceTime values of the preceding break, along with the three additional hours of work time before granting the second break. To avoid taking max-work-time breaks prematurely, remember that they accumulate work time from the beginning of the route and that work time includes the service time at previously visited depots, orders, and breaks. If this field has a value, TimeWindowStart, TimeWindowEnd, MaxViolationTime, and MaxTravelTimeBetweenBreaks must be null for an analysis to solve successfully. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
RouteName |
The name of the route that the break applies to. Although a break is assigned to exactly one route, many breaks can be assigned to the same route. This field is a foreign key to the Name field in the Routes class and can't have a null value. Route objects must exist before they will appear in the RouteName drop-down list. |
|
Precedence |
Precedence values sequence the breaks of a given route. Breaks with a precedence value of 1 occur before those with a value of 2, and so on. All breaks must have a precedence value, regardless of whether they are time-window, maximum-travel-time, or maximum-work-time breaks. |
|
ServiceTime |
The duration of the break. This field can contain null values; a null value indicates no service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
MaxViolationTime |
This field specifies the maximum allowable violation time for a time-window break. A time window is considered violated if the arrival time falls outside the time range. A zero value indicates the time window cannot be violated; that is, the time window is hard. A nonzero value specifies the maximum amount of lateness; for example, the break can begin up to 30 minutes beyond the end of its time window, but the lateness is penalized as per the Time Window Violations property of the analysis layer. This property can be null; a null value with TimeWindowStart and TimeWindowEnd values indicates that there is no limit on the allowable violation time. If MaxTravelTimeBetweenBreaks or MaxCumulWorkTime has a value, MaxViolationTime must be null. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
IsPaid |
A Boolean value indicating whether the break is paid or unpaid. A True value indicates that the time spent at the break is included in the route cost computation and overtime determination. A False value indicates otherwise. The default value is True. |
|
Input/Output field |
Description |
|---|---|
|
Sequence |
As an input field, this indicates the sequence of the break on its route. This field can contain null values. The input sequence values are positive and unique for each route (shared across renewal depot visits, orders, and breaks) but need not start from 1 or be contiguous. The solver modifies the sequence field. After solving, this field contains the sequence value of the break on its route. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. |
|
Output field |
Description |
|---|---|
|
RelativePosition |
The relative position of the break. Breaks are taken somewhere between two network locations (orders or depots). A value of 0.0 indicates that the break is taken right after service completion at the preceding network location; a value of 1.0 indicates the break is taken right before starting service at the subsequent network location; and a value in between indicates where along the path from the first to the second network location the break is taken. For instance, 0.25 indicates the break is taken a quarter of the way from the previous network location to the next network location. No matter how many breaks occur between two network locations, the relative position is always reported relative to the network locations, not the other breaks. |
|
FromPrevTravelTime |
The travel time from the preceding order, depot, or break to this break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
FromPrevDistance |
The travel distance from the preceding order, depot, or break to this break. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTravelTime |
The cumulative travel time for the route up to the arrival at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulDistance |
The cumulative travel distance for the route up to the arrival at the break. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters. |
|
CumulTime |
The cumulative route duration up to and including the break. The cumulative duration includes travel times as well as service and wait times at orders, depots, and breaks. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
ArriveTime |
The actual arrival time of the break. The route may arrive at the break before the beginning of the break's time window, in which case there is a wait time at the break. For a break with soft time windows, the route may also arrive at the break after the end of the time window, in which case there is a violation time at the break. If using traffic data with multiple time zones, the time is reported in the time zone of the associated route's starting depot. |
|
DepartTime |
The time that the break is completed. If using traffic data with multiple time zones, the time is reported in the time zone of the associated route's starting depot. |
|
WaitTime |
The wait time at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
ViolationTime |
The violation time at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulWaitTime |
The cumulative wait time from the beginning of the route up to and including the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
|
CumulViolationTime |
The cumulative violation time from the beginning of the route up to and including the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. |
Route Zones class
Route zones specify a work territory for a given route. A route zone is a polygon feature and is used to constrain routes to servicing only those orders that fall within or near an area. Here are some examples of when route zones may be useful:
- Some of your employees don't have the required permits to perform work in certain states or communities. You can create a hard route zone so they only visit orders in areas where they meet the requirements.
- One of your vehicles breaks down frequently so you want to minimize response time by having it only visit orders that are close to your maintenance garage. You can create a soft or hard route zone to keep the vehicle nearby.
If you use route zones in your analysis, you cannot also use route seed points.
Route zone properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Shape |
The geometry field indicating the geographic location of the network analysis object. |
|
RouteName |
The name of the route to which this zone applies. A route zone can have a maximum of one associated route. This field can't contain null values, and it is a foreign key to the Name field in the Routes feature layer. Route objects must exist before they will appear in the RouteName drop-down list. |
|
IsHardZone |
A Boolean value indicating a hard or soft route zone. A True value indicates that the route zone is hard; that is, an order that falls outside the route zone polygon can't be assigned to the route. The default value is True. A False value indicates that such orders can still be assigned, but the cost of servicing the order is weighted by a function that is based on the Euclidean distance from the route zone. Basically, this means that as the straight-line distance from the soft zone to the order increases, the likelihood of the order being assigned to the route decreases. |
Note:
- Since Euclidean distance is used in measuring the distance between the route zone and the orders, the network-based distance attribute is not required.
- Even though a route associated with a hard route zone can only service orders inside the route zone, other routes can still enter and service the orders inside the same zone. This is because route zones restrict the route, not the orders. (If you want to assign all the orders in an area exclusively to one route, don't use route zones; instead, select the orders in an area, change the orders' RouteName field to the proper route, and set their AssignmentRule field to Preserve Route.)
Route Seed Points class
This network analysis class stores the route seed points of a given vehicle routing problem analysis layer. Route seed points are used to specify point-based clustering for the routes. Typically, the closer an order is to a route's seed point, the more likely the order is to be assigned to that route—as long as other criteria are met, such as specialties and capacities. Clustering orders may result in routes that cover a smaller area and don't intersect other routes as much, but the overall cost of the solution could be more. You might want to use seed points to keep drivers in general neighborhoods or regions that they are familiar with, or you might want to have compartmentalized routes if they are easier for your organization to manage.
Here are a few rules and options to consider when working with route seed points:
- A route can have a preassigned route seed point, or the seed point can be calculated by the VRP solver.
- If you use route seed points in your analysis, you cannot use route zones.
- If route seed points are used, one route seed point must be assigned to each route.
- Route-seed-point types cannot be combined; the network analysis class must have either all dynamic or all static seed points.
Route seed points are point features; however, they are not network locations. Thus, they don't have network location fields.
Route Seed Points class
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
RouteName |
The name of the route that this seed point applies to. There is at most one route seed point per route. This field can't contain null values and is a foreign key to the Name field in the Routes class. Route objects must exist before they will appear in the RouteName drop-down list. |
|
SeedPointType |
The type of seed point. This field is constrained by a domain of values, and the possible values are Static and Dynamic. This field has a default value of Static. In the case of static seed points, you specify where the route seed point is, and the solver tries to cluster the route around the seed point location. In the case of dynamic seed points, you add the seed point anywhere on the map, orders are clustered during the solve process, then the seed point is relocated to the centroid of the route's orders. |
|
Input/Output field |
Description |
|---|---|
|
Shape |
As an input field, it indicates the location of a route seed point. For a static seed point, its input point shape is left intact throughout the solve process. On the other hand, the input shape is ignored for a dynamic seed point, and the solver modifies the Shape field during the solve process to show its new location. |
Note:Euclidean distance is used in measuring the distance between route seed points and orders; therefore, the network-based Distance Attribute in the layer properties is not required.
Route Renewals class
The Route Renewals class specifies the intermediate depots that the routes of a vehicle routing problem analysis can visit to reload and unload things they are delivering or picking up.
Specifically, a route renewal analysis object links a route object to a depot object. The relationship indicates the route can renew (reload or unload) at the associated depot.
In some industries, each route consists of one or more trips in which the vehicle delivers or picks up a full load and delivers them. Route renewals can be used to model scenarios in which a vehicle picks up a full load of deliveries at the starting depot, services the orders, returns to the depot to renew its load of deliveries, and continues servicing more orders. For example, in propane gas delivery, the vehicle may make several deliveries until its tank is nearly or completely depleted, visit a refueling point, and make more deliveries.
Here are a few rules and options to consider when working with route seed points:
- The reload/unload point, or renewal location, can be different from the start or end depot.
- Each route can have one or many predetermined renewal locations.
- A renewal location may be used more than once by a single route.
- In some cases where there may be several potential renewal locations for a route, the closest available renewal location is chosen by the solver.
Route renewal properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
DepotName |
The name of the depot where this renewal takes place. This field can't contain a null value and is a foreign key to the Name field in the Depots feature layer. Depot objects must exist before they will appear in the DepotName drop-down list. |
|
RouteName |
The name of the route that this renewal applies to. This field can't contain a null value and is a foreign key to the Name field in the Routes feature layer. Route objects must exist before they will appear in the RouteName drop-down list. |
|
ServiceTime |
The service time for the renewal. This field can contain a null value; a null value indicates zero service time. The unit for the service time is specified by the Time Field Units property of the analysis layer. Note:The time taken to load a vehicle at a renewal depot may depend on the size of the vehicle and how full or empty the vehicle is. However, the service time for a route renewal is a fixed value and does not take into account the actual load. As such, the renewal service time should be given a value corresponding to a full truckload, an average truckload, or another time estimate of your choice. |
|
Input/Output field |
Description |
|---|---|
|
Sequences |
As an input field, specifies a space-separated string of sequence values of visits to the renewal depot. This field can contain a null value and is used to preassign visits to the renewal depot. As an output field, the solver may modify and store the sequence here. After solving, this field contains the sequence values of the visits to this renewal depot for the related route. If more than one renewal visit occurs at that depot on a single route, then the sequence values are separated by a space. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. So if a route starts at a depot, visits two orders, makes a renewal visit, and continues, the sequence value at the renewal is 4. |
Specialties class
This table lists the specialties that can be required by orders and supported by routes. A route can service an order only if it supports all the specialties required for that order.
An order may require a technician with a certain skill set or a vehicle with certain capabilities. You model these skills, capabilities, and so on, by first adding them in the Specialties class. Next, you add the specialties that are supported by a route to its SpecialtyNames property. Finally, you add the specialties that an order requires to its SpecialtyNames property. When the VRP analysis is solved, orders that require certain specialties are matched with routes that can provide them.
Specialties properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
Name |
The name of the network analysis object. This field is the primary key and is used as a foreign key in the Orders and Routes feature layers to refer to specialties. Specialty names have to be unique and can't be empty. They also can't contain spaces. So, for example, a senior technician specialty should be entered as SeniorTechnician. The no-spaces requirement is necessary because orders and routes that are associated with multiple specialties list specialty names separated by spaces; for example, SeniorTechnician Lift. |
|
Description |
The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness. |
OrderPairs class
This network analysis class is a table of records that is used to pair delivery and pickup orders so they are serviced by the same route.
Sometimes it is required that the pickup and delivery for orders be paired. For example, for a courier company, a delivery of a document might involve two stops: one to pick up the document at the source and a second stop to drop it off at the destination. These related stops are assigned to the same route with the appropriate sequence. It is prohibited to assign only one of the orders to a route: either both orders are assigned to the same route, or neither order is assigned.
There may be restrictions on how long the package can stay in the vehicle; for example, a blood sample has to be transported from the doctor's office to the lab within two hours.
Some situations might require two pairs of orders. For example, suppose you want to transport a senior citizen from her home to the doctor and bring her back home. The ride from her home to the doctor is one pair of orders with a desired arrival time at the doctor, while the ride from the doctor back home is another pair with a desired pickup time.
Order pair properties
|
Input field |
Description |
|---|---|
|
ObjectID |
The system-managed ID field. |
|
FirstOrderName |
The name of the first order of the pair. This field is a foreign key to the Name field in the Orders feature layer. Order objects must exist before they will appear in the FirstOrderName drop-down list. |
|
SecondOrderName |
The name of the second order of the pair. This field is a foreign key to the Name field in the Orders feature layer. Order objects must exist before they will appear in the SecondOrderName drop-down list. The first order in the pair must be a pickup order; that is, the value for its DeliveryQuantities field is null. The second order in the pair must be a delivery order; that is, the value for its PickupQuantities field is null. The quantity that is picked up at the first order must agree with the quantity that is delivered at the second order. As a special case, both orders may have zero quantities for scenarios where capacities are not used. Note:The order quantities are not loaded or unloaded at depots. |
|
MaxTransitTime |
The maximum transit time for the pair. The transit time is the duration from the departure time of the first order to the arrival time of the second order. This constraint limits the time-on-vehicle, or ride time, between the two orders. When a vehicle is carrying people or perishable goods, the ride time is typically shorter than that of a vehicle carrying packages or nonperishable goods. This field can contain null values; a null value indicates that there is no constraint on the ride time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Excess transit time (measured with respect to the direct travel time between order pairs) can be tracked and weighted by the solver. Because of this, you can direct the VRP solver to take one of three approaches: (1) minimize the overall excess transit time, regardless of the increase in travel cost for the fleet; (2) find a solution that balances overall violation time and travel cost; and (3) ignore the overall excess transit time and, instead, minimize the travel cost for the fleet. By assigning an importance level for the Excess Transit Time setting of the analysis layer, you are in effect choosing one of these three approaches. Regardless of the importance level, the solver will always return an error if the MaxTransitTime is surpassed. |
Point, line, and polygon barriers
Barriers serve to temporarily restrict, add impedance to, and scale impedance on parts of the network. When a new network analysis layer is created, the barrier classes are empty. They are populated only when you add objects into them—but adding barriers is not required.
Barriers are available in all network analysis layers; therefore, they are described in a separate topic.
Vehicle routing problem analysis parameters
Analysis parameters are set on the Layer Properties dialog box for the analysis layer. The dialog box can be accessed different ways:
Learn about opening the network analysis Layer Properties dialog box
The Analysis Settings tab
The following subsections list parameters that you can set on the analysis layer. They are found on the Analysis Settings tab of the analysis layer's Layer Properties dialog box.
 |
Analysis Settings for a vehicle routing problem analysis layer |
Time Attribute
The time cost attribute used to define the traversal time along the elements of the network. The time cost attribute is required, since the vehicle routing problem solver minimizes time.
Distance Attribute
The distance cost attribute used to define the length along the elements of the network. The distance cost attribute is optional.
Default Date
The implied date for time-field values that don't have a date specified with the time. If a time field, such as TimeWindowStart1 for an order, has a time-only value, the date is assumed to be the one specified by the Default Date property. For example, if an order has a TimeWindowStart1 value of 9:00 AM and Default Date is March 6, 2011, then the entire time value for the field is 9:00 a.m., March 6, 2011. If the Default Date setting is changed, then the implied date for all time field values with an unspecified date is the new default date. The default date has no effect on time field values that already have a time along with a particular date.
If your network dataset includes historical traffic data, the results of the analysis could change depending on the date that you specify here. For example, if your routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus 8:00 a.m. on Monday, during rush hour, the Monday route would take longer. Furthermore, the best path could change depending on traffic conditions.
You can choose between entering a floating day (Day of Week) or a calendar day (Specific Date). For a calendar day, you provide the day, month, and year. For a floating date, you can choose Today or any day of the week (Sunday through Saturday). Floating days enable you to configure an analysis layer that can be reused, without having to remember to change the date.
Floating days are especially beneficial when used with traffic data. For example, if you choose the Day of Week and Today settings, the solver will generate results based on the historical traffic for the current day, which is determined from your computer's operating system. If, for example, you return the next day, May 5, and solve the same analysis layer again, the solution will be based on the historical traffic for the day of the week May 5 lands on. Likewise, when you choose Monday for the Day of Week property, then solve, the solution will be based on the historical traffic for the next Monday. However, if today is Monday, the solution uses today's historical traffic data.
Capacity Count
The number of capacity constraint dimensions required to describe the relevant limits of the vehicles. In an order delivery case, each vehicle may have a limited amount of weight and volume it can carry at one time based on physical and legal limitations. In this case, if you track the weight and volume on the orders, you can use these two capacities to prevent the vehicles from getting overloaded. The capacity count for this scenario is two (weight and volume). Depending on the problem, you may need to track different types or amounts of capacities. The capacities entered into the capacity fields (DeliveryQuantities and PickupQuantities for the Orders class and Capacities for the Routes class) are space-delimited strings of numbers, which can hold up to the number of values specified in Capacity Count. Each capacity dimension should appear in the same positional order for all capacity field values in the same VRP analysis layer. The capacities themselves are unnamed, so to avoid accidentally transposing capacity dimensions, ensure that the space-delimited capacity lists are always entered in the same order for all capacity field values.
Time Field Units
The time units used by the temporal fields of the analysis layer's sublayers and tables (network analysis classes). This does not have to be the same as the units of the time cost attribute.
Distance Field Units
The distance units used by distance fields of the analysis layer's sublayers and tables (network analysis classes). This does not have to be the same as the units of the optional distance cost attribute.
U-Turns at Junctions
ArcGIS Network Analyst can allow U-turns everywhere, nowhere, only at dead-ends (or culs-de-sac), or only at intersections and dead-ends. Allowing U-turns implies the route can turn around at a junction and double back on the same street.
Output Shape Type
The route features that are output by the analysis can be represented in one of four ways.
- True Shape gives the exact shape of the resulting route.
- True Shape with Measures gives the exact shape of the resulting route. Furthermore, the output includes route measurements for linear referencing. The measurements increase from the first stop and record the cumulative impedance.
- Straight Line results in a single, straight line between the stops.
- When the output shape type is set to None, no shape is returned.
In all these cases, the time-based and distance-based costs in the solution are the same, and the Routes feature layer attributes are the same as well; the only difference is in the shape of the Route output or whether or not linear referencing is automatically set up.
Use Hierarchy
If the network dataset has a hierarchy attribute, you can use the hierarchy during the analysis. Using a hierarchy results in the solver preferring higher-order edges to lower-order edges. Hierarchical solves are faster, and they can be used to simulate the driver preference of traveling on freeways instead of local roads—even if that means a longer trip. Not using a hierarchy, however, yields an exact route for the network dataset.
Restrictions
You can choose which restriction attributes should be respected while solving the analysis. Restrictions, such as Oneway, should be used when finding solutions for vehicles that must obey one-way streets (for instance, nonemergency vehicles). If your network dataset contains additional restriction attributes, such as weight limit or height limit, those could be used as well.
Restriction attributes can also be used in conjunction with dynamic attributes. For example, an edge could be restricted if the vehicle is taller than the height of a tunnel.
Directions
With the Directions properties, you can set the units for displaying distance and, optionally, time. Additionally, you can choose to open directions automatically after the generation of a route. (If you choose not to display directions automatically, you can click the Directions Window button 
to display directions.)
The Advanced Settings tab
 |
The Advanced Settings tab of the Layer Properties dialog box displays the following properties for the vehicle routing problem analysis layer. The settings you make here influence the solver's priorities when handling time window violations for routes and excess transit times for paired orders. You can assign a value of Low, Medium, or High. The higher the importance, the more the solver tries to reduce or eliminate the associated time window violations or excess transit time.
Time window violation
Time Window Violation: This property allows you to rate the importance of honoring time windows without causing violations. A time window violation occurs when a route arrives at an order, depot, or break after a time window has closed. The violation is the interval between the end of the time window and the arrival time of a route.
 |
The VRP solution can change according to the value you choose for the Time Window Violation property. The following list describes what the values mean and how the resulting VRP solution can vary:
High—The solver tries to find a solution that minimizes time window violations at the expense of increasing the overall travel time. Choose High if arriving on time at orders is more important to you than minimizing your overall solution cost. This may be the case if you are meeting customers at your orders and you don't want to inconvenience them with tardy arrivals (another option is to use hard time windows that can't be violated at all).
Given other constraints of a vehicle routing problem, it may be impossible to visit all the orders within their time windows. In this case, even a High setting might produce violations.
Medium—This is the default setting. The solver looks for a balance between meeting time windows and reducing the overall solution cost.
Low—The solver tries to find a solution that minimizes overall travel time, regardless of time windows. Choose Low if respecting time windows is less important than reducing your overall solution cost. You may want to use this setting if you have a growing backlog of service requests. For the purpose of servicing more orders in a day and reducing the backlog, you can choose Low even though customers will be inconvenienced with your fleet's late arrivals.
The next two graphics show the same set of orders and depots; however, the routes are not the same because different Time Window Violation settings were used. The graphic on the left shows the route that resulted from the Time Window Violation's importance set to Low. The route is short, but it has a time window violation. If set to High, the route meets all the time windows, but it is longer because it services the order with a time window first.
|
|
Excess travel time
This property allows you to rate the importance of reducing excess transit time. Excess transit time is the amount of time exceeding the time required to travel directly between the paired orders. The excess time results from breaks or travel to other orders or depots between visits to the paired orders.
 |
Calculating excess transit time |
The VRP solution can change according to the value you choose for Excess Transit Time. The following list describes what the values mean and how the resulting VRP solution can vary:
- High—The solver tries to find a solution with less excess transit time between paired orders at the expense of increasing the overall travel costs. It makes sense to use this setting if you are transporting people between paired orders and you want to shorten their ride time. This is characteristic of taxi services.
- Medium—This is the default setting. The solver looks for a balance between reducing excess transit time and reducing the overall solution cost.
- Low—The solver tries to find a solution that minimizes overall solution cost, regardless of excess transit time. This setting is commonly used with courier services. Since couriers transport packages as opposed to people, they don't need to worry about ride time. Using Low allows the couriers to service paired orders in the proper sequence and minimize the overall solution cost.
The next two graphics show the same set of orders and depots; however, the routes are not the same because different Excess Transit Time settings were used. The graphic on the left shows the route that resulted when the Excess Transit Time's importance was set to Low. The overall route is short, but the travel time from the first order to its paired order, the airport, is long. If the importance is set to high, the route reduces the time between the first order and the airport while maintaining the same ride time to the airport for the order on the right; however, the overall cost of the route increases.
|
|
The Network Locations tab
The parameters on the Network Locations tab are used to find network locations and set values for their properties.
Solving and interpreting the results of a vehicle routing problem
After creating a vehicle routing problem analysis layer, populating the required network analysis objects, and setting appropriate analysis properties, the solution for the vehicle routing problem analysis layer can be obtained by clicking the Solve button 
on the Network Analyst toolbar.
After solve, if the Output Shape Type property is set to True Shape, the vehicle routing problem solver draws lines along the network connecting starting depots, orders, renewal depots, and ending depots for each route.
The Network Analyst window also updates the Orders class to group all orders by the routes to which they are assigned. The Depot Visits class updates to show the starting, ending, and renewal depots for each route.
On solve, the vehicle routing problem solver ignores any route whose AssignmentRule field value is set to Exclude and any order whose AssignmentRule field value is set to Exclude.
The vehicle routing problem solver then computes an internally-managed origin-destination (OD) cost matrix between each of the orders and depot locations using the Time Attribute as impedance and Distance Attribute (if specified) as an accumulated attribute.
Learn about OD cost matrix analysis
The VRP solver creates an initial solution composed of the preassigned orders, breaks, and renewal visits if any of these network analysis objects are preassigned to routes. If a valid initial solution can't be found using this preassignment (that is, some constraints are violated), the solve process fails.
While there are unrouted orders, the VRP solver tries to insert the cheapest unrouted order into the best compatible route. The solver tries to resequence orders assigned to a route if the resequencing improves the solution, but it does not move orders whose AssignmentRule field value is set to Preserve route and relative sequence.
After successfully routing all possible orders, the vehicle routing problem solver outputs the results in the appropriate output fields of the network analysis objects. If some orders can't be routed, the violated constraints are output to the ViolatedConstraints fields in the Orders feature layer. If a route is not used in a solution, then its output fields are set to null.
Learn about violated constraints for orders and routes
Interpreting the results of a vehicle routing problem analysis
After successfully solving a vehicle routing problem analysis layer, the routing solution for each route can be assembled by reading the input and output fields of the Breaks table, Depot Visits feature layer, Orders feature layer, and Routes feature layer. For each route, searching by RouteName and looking at the Sequence values in Breaks, Depot Visits, and Orders provides the itinerary for the route. You can generate directions to compile a similar itinerary. The Routes feature layer provides a summary of each computed route.