The vehicle routing problem analysis layer stores the inputs, parameters, and results for a given vehicle routing problem. Once the layer is created it appears in the Contents window 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. The vehicle routing problem analysis layer is made up of 13 network analysis classes comprising nine feature layers (Orders, Depots, Routes, Breaks, Route Zones, Depot Visits, Point Barriers, Line Barriers, and Polygon Barriers) and four tables (Route Specialties, Order Specialties, Order Pairs, and Route Renewals). They contain the network analysis objects that are 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 problem
Learn more about creating a network analysis layer
To support VRP workflows starting ArcGIS Pro 2.6, a few schema changes have been introduced. To learn more see VRP schema changes.
Note:
When referencing ArcGIS.com or a portal for the VRP layer's network dataset, if the solve fails, only the violated constraint fields will be updated. All other fields, both input and output, will remain unchanged.
Learn more about the VRP solver
Orders
The Orders feature class stores the orders that are part of a given vehicle routing problem analysis layer. An order can be a delivery to a customer, a pickup from a customer, or some other type of work. Examples include a furniture delivery, a grease pickup from a restaurant, or an inspection visit.
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 or combination of measurements you want, such as weight, volume, or number of units. Some orders, such as 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.
The VRP solver is not designed to solve problems over one year in duration. Therefore, all service times and time windows need to be less than a year.
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: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
Shape | The geometry field indicating the geographic location of the network analysis object. | Geometry |
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 Order Pairs and the Orders Specialties table. Order names are case insensitive and cannot be empty, even if the order is excluded from the solve operation. | Text |
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. | Text |
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. A zero or null value indicates 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. | Double |
TimeWindowStart | 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 table of properties for more information.) | Date |
TimeWindowEnd | The ending time of the first time window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this table of properties for more information.) | Date |
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 TimeWindowStart and TimeWindowEnd fields, the second time window must also be null. If both time windows are nonnull, they can't overlap. Also, the second time window must occur after the first. (See the note below this table of properties for more information.) | Date |
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 table of properties for more information.) | Date |
|
MaxViolationTime | A time window is considered violated if the arrival time occurs after the time window has ended. 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. When there are two time windows for an order, the first time window will always be treated as a hard time window with a MaxViolationTime of zero. 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 value set for MaxViolationTime is surpassed. | Double |
|
MaxViolationTime2 | The maximum allowable violation time for the second time window of the order. This field is analogous to the MaxViolationTime field. | Double |
InboundArriveTime | Defines when the item to be delivered to the order will be ready at the starting depot. The order can be assigned to a route only if the inbound arrive time precedes the route's latest start time value; this way, the route cannot leave the depot before the item is ready to be loaded onto it. This field can help model scenarios involving inbound-wave transshipments. For example, a job at an order requires special materials that are not currently available at the depot. The materials are being shipped from another location and will arrive at the depot at 11:00 a.m. To ensure a route that leaves before the shipment arrives isn't assigned to the order, the order's inbound arrive time is set to 11:00 a.m. The special materials arrive at 11:00 a.m., they are loaded onto the vehicle, and the vehicle departs from the depot to visit its assigned orders. Notes:
| Date |
OutboundDepartTime | Defines when the item to be picked up at the order must arrive at the ending depot. The order can be assigned to a route only if the route can visit the order and reach its end depot before the specified outbound depart time. This field can help model scenarios involving outbound-wave transshipments. For instance, a shipping company sends out delivery trucks to pick up packages from orders and bring them into a depot where they are forwarded on to other facilities, en route to their final destination. At 3:00 p.m. every day, a semitrailer stops at the depot to pick up the high-priority packages and take them directly to a central processing station. To avoid delaying the high-priority packages until the next day's 3:00 p.m. trip, the shipping company tries to have delivery trucks pick up the high-priority packages from orders and bring them to the depot before the 3:00 p.m. deadline. This is done by setting the outbound depart time to 3:00 p.m. Notes:
| Date |
| The size of the delivery. You can specify size in any dimension such as weight, volume, or quantity. If there are multiple delivery quantities, specify them using the DeliveryQuantity_1 through DeliveryQuantity_9 fields as needed. | Double |
| The size of the pickup. You can specify size in any dimension such as weight, volume, or quantity. If there are multiple pickup quantities, specify them using the PickupQuantity_1 through PickupQuantity_9 fields as needed. | Double |
|
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 field in the route class never includes revenue in its output; however, revenue weights the relative importance of servicing orders. | Double |
|
AssignmentRule | This field 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. | Long |
|
Network location fields
|
Together, these 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):
| Long |
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 TimeWindowEnd field.
The time zone for the time window fields can be specified using the time_zone_for_time_fields parameter on the Make Vehicle Routing Problem Analysis Layer geoprocessing tool.
The time window fields 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, 8:00 a.m.), 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 a.m.) allows you to set time windows that span multiple days.
The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time.
If you're using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge on which the network location is located.
Orders: Input/Output fields
| Input/Output field | Description | Data type |
|---|---|---|
|
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 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. | Text |
|
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 non-negative and unique for each route (shared across depot visits, orders, and breaks), but do not need to start from 0 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. | Long |
Status |
Indicates the status of the point with respect to its location on the network and the outcome of the analysis. The possible values are the following:
If time windows are used and the route arrives early or late, the value changes to Time window violation (6). | Long |
Note:
If the order has an AssignmentRule field value of Exclude, the input values for the Status, RouteName, and Sequence fields are not changed during the solve operation.
Orders: Output fields
| Output field | Description | Data type |
|---|---|---|
| These fields contain a summary of violated constraints and are set after a solve operation. Each field will contain one violation. If an order has more than one violation the next ViolatedConstraint_# field will be used.
Learn more about troubleshooting network analyses Note:The violated constraint field 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, the violation is noted in violated constraint fields, and the solver continues to consider the order. Any further violations such as these are added to the violated constraint fields until either the solver finds a violation that prematurely stops the solve process for that particular order, or the solver finds an overall solution to the problem. | Long |
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. | Double |
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. | Double |
CumulTravelTime | The cumulative travel time for the route up to arrival at the order. The unit for this field value is specified by the Time Field Units property of the analysis layer. | Double |
CumulDistance | The cumulative travel distance for the route up to 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. | Double |
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. | Double |
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. | Long |
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. | Long |
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 on which the order is located. | Date |
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 on which the order is located. | Date |
ArriveTimeUTC | The date and time value indicating the arrival time in coordinated universal time (UTC) at the order. | Date |
DepartTimeUTC | The date and time value indicating the departure time in coordinated universal time (UTC) from the order. The route departs from the order upon completion of service. | Date |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
Depots
The Depots feature 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.
Depots: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Objecy ID |
Shape | The geometry field indicating the geographic location of the network analysis object. | Geometry |
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, Route Renewals table, and Depot Visits feature layer to refer to depots. Depot names are case insensitive and have to be nonempty and unique. | Text |
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. | Text |
TimeWindowStart | 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 table of properties for more information.) | Date |
TimeWindowEnd | The ending time of the first time window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this table of properties for more information.) | Date |
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 TimeWindowStart and TimeWindowEnd fields, the second time window must also be null. If both time windows are nonnull, they can't overlap. Also, the second time window must occur after the first. (See the note below this table of properties for more information.) | Date |
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 table of properties for more information.) | Date |
|
Network location fields
|
Together, these 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:
| Long |
Note:
The time window fields 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, 8:00 a.m.), 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 a.m.) allows you to set time windows that span multiple days.
The time zone for the time window fields can be specified using the time_zone_for_time_fields parameter on the Make Vehicle Routing Problem Analysis Layer geoprocessing tool.
The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time.
If you're using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge on which the network location is located.
Depots: Input/Output fields
| Input/Output field | Description | Data type |
|---|---|---|
Status |
Indicates the status of the point with respect to its location on the network and the outcome of the analysis. The possible values are the following:
If time windows are used and the routed vehicle arrives early or late, the value changes to Time window violation (6). | Long |
Routes
The Routes feature class stores the routes that are part of a given vehicle routing problem analysis layer. A route specifies the vehicle and driver characteristics, and it represents the traversal between depots and orders. In 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, 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, other linear features, or tables.
Routes: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
Name | The name of the network analysis object. This field is the primary key and is used as a foreign key in the Orders, Breaks, Route Zones, Depot Visits, and feature layers; and Route Renewals and RouteSpecialty tables. 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. | Text |
Description | The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness. | Text |
|
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 value 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 StartDepotName is null, EndDepotName cannot also be null. Virtual start depots are not allowed if orders or depots are in multiple time zones. If the route is making deliveries and StartDepotName is null, it is assumed the cargo is loaded on the vehicle at a virtual depot before the route begins. For a route that has no renewal visits, its delivery orders (those with a nonzero value in the DeliveryQuantity_# fields 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. | Text |
|
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. | Text |
|
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. | Double |
|
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. | Double |
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 a.m.; the default value is interpreted as 8:00 a.m. on the date given by the Default Date property of the analysis layer. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. 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 on which the starting depot is located. | Date |
|
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 a.m.; the default value is interpreted as 10:00 a.m. on the date given by the Default Date property of the analysis layer. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. 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 on which the starting depot is located. | Date |
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 value, the VRP solver is deterred from sending many routes to service physically coincident orders. The cost for this property is incurred between visits to non-coincident 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 value is not added between them since the vehicle doesn't need to move. If the route travels to a route renewal, the value is added to the travel time again. Although a vehicle needs to slow down and stop for a break and accelerate afterward, 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. | Double |
| The maximum amount (for instance, volume, weight, quantity) that can be carried by the vehicle. If there are multiple capacities, specify them using the Capacity_1 through Capacity_9 fields as needed. Note:An empty string or null value is equivalent to infinity. Capacity values can't be negative. | Double |
|
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. | Double |
|
CostPerUnitTime | The monetary cost incurred—per unit of work time—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 unit for this field value is specified by the Time Field Units property of the analysis layer. | Double |
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. | Double |
|
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. If including an OvertimeStartTime value, it should be greater than zero and less than the MaxTotalTime value. The unit for this field value 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, OvertimeStartTime is specified as 8 if the Time Field Units property of the analysis layer is set to Hours. | Double |
|
CostPerUnitOvertime | The monetary cost incurred per time unit of overtime work. This can only contain a null value if OvertimeStartTime is also null. Otherwise it must be a positive value greater than the CostPerUnitTime. | Double |
|
MaxOrderCount |
The maximum allowable number of orders on the route. This field can't contain null values and has a default value of 30. | Long |
|
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. | Double |
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. | Double |
|
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. | Double |
|
AssignmentRule | This specifies whether or not the route can be used when solving the problem. This field is constrained by a domain of values, and the possible values are the following:
| Long |
Routes: Output fields
| Output field | Description | Data type |
|---|---|---|
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. | Geometry |
| These fields contain a summary of violated constraints and is set after a solve operation. If a route causes a constraint to be violated, the violations listed below could be assigned to the fields, one violation per field.
| Long |
OrderCount | The number of orders assigned to the route. | Long |
TotalCost | The total operating cost of the route, which is the sum of the following field values:
| Double |
RegularTimeCost | The cost of regular work time, excluding any unpaid breaks. | Double |
OvertimeCost | The cost of overtime work, excluding any unpaid breaks. | Double |
DistanceCost | The distance cost component obtained by multiplying the TotalDistance and CostPerUnitDistance field values. This field value is null if the Distance Attribute property is not specified for the analysis layer. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Date |
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. | Date |
StartTimeUTC | The start time of the route in coordinated universal time (UTC). | Date |
EndTimeUTC | The end time of the route in coordinated universal time (UTC). | Date |
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. | Double |
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. | Double |
RenewalCount | For a route with renewals, this is equal to the number of visits to depots for renewing. | Long |
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. | Double |
Breaks
The Breaks feature class 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. Time-window breaks are not allowed if orders or depots are in multiple time zones. If a break is needed in this situation, use the maximum-work-time break setup.
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 and 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 maximum-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.
Breaks: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
|
TimeWindowStart |
The starting time of the break's time window. Half-open time windows are invalid for Breaks. 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 p.m.), 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/2012 12:00 p.m.) 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. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. | Date |
|
TimeWindowEnd | The ending time of the break's time window. Half-open time windows are invalid for Breaks. 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. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. See the description for TimeWindowStart (above) for more information. | Date |
|
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. | Double |
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 15 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 maximum-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. | Double |
|
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. | Text |
|
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. | Long |
|
ServiceTime |
The duration of the break. This field can't contain a null value. The unit for this field value is specified by the Time Field Units property of the analysis layer. | Double |
|
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. | Double |
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. | Long |
Breaks: Input/Output fields
| Input/Output field | Description | Data type |
|---|---|---|
|
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. | Long |
Breaks: Output fields
| Output field | Description | Data type |
|---|---|---|
Shape | The geometry field indicating the designated break locations for a route. | Geometry |
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. | Double |
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. | Double |
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. | Double |
CumulTravelTime | The cumulative travel time for the route up to arrival at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer. | Double |
CumulDistance | The cumulative travel distance for the route up to 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. | Double |
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. | Double |
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 a network dataset with multiple time zones, the time is reported in the time zone of the actual break location. | Date |
DepartTime | The time the break is completed. If using a network dataset with multiple time zones, the time is reported in the time zone of the actual break location. | Date |
ArriveTimeUTC | The date and time value indicating the arrival time in coordinated universal time (UTC). | Date |
DepartTimeUTC | The date and time value indicating the departure time in coordinated universal time (UTC). | Date |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
Route Zones
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.
Route Zones: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
Shape | The geometry field indicating the geographic location of the network analysis object. | Geometry |
|
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 list. | Text |
|
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 (1). A False value (0) 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. | Long |
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.)
Depot Visits
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 the 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: Output fields
| Output field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
Shape | The geometry field indicating the geographic location of the network analysis object. | Geometry |
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, DepotName is null. | Text |
RouteName | The name of the route containing this visit. This field is a foreign key to the Name field in the Routes feature layer. | Text |
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. | Long |
VisitType | The reason this depot was visited. This field is constrained by a domain of values:
| Long |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Double |
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. | Date |
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. | Date |
ArriveTimeUTC | The date and time value indicating the arrival time in coordinated universal time (UTC) at the depot. | Date |
DepartTimeUTC | The date and time value indicating the departure time in coordinated universal time (UTC) from the depot. | Date |
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. | Double |
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. | Double |
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. | Double |
| The amount (for instance, volume, weight, quantity) being loaded at the depot. If there are multiple capacities, the amounts in the LoadedQuantity_1 through LoadedQuantity_9 fields correspond to the matching Capacity_1 through Capacity_9 fields in the Routes input table. | Double |
| The amount (for example, volume, weight, quantity) being unloaded at the depot. If there are multiple capacities, the amounts in the UnloadedQuantity_1 through UnloadedQuantity_9 fields correspond to the matching Capacity_1 through Capacity_9 fields in the Routes input table. | Double |
Note:
There is no ViolationTime output field on the Depot Visits feature layer because depots have hard time windows.
Specialties
Order Specialties and Route Specialties are the two tables that 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 Order Specialties table. Next, you add the specialties that are supported by a route to Route Specialties. When the VRP analysis is solved, orders that require certain specialties are matched with routes that can provide them.
Order Specialties: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
OrderName | 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 to refer to order specialties. | Text |
SpecialtyName | The name of the specialty. This indicates the required specialty for the order. Only a single specialty is listed per line. If an order requires more than one specialty, create a new row. Specialty names can't contain spaces. For example, a senior technician specialty should be entered as SeniorTechnician. | Text |
Route Specialties: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
RouteName | The name of the network analysis object. This field is the primary key and is used as a foreign key in Routes feature layer to refer to route specialties. | Text |
SpecialtyName | The name of the specialty. This indicates the specialty that the route supports. Only a single specialty is listed per line. If a route supports more than one specialty, create a new row. Specialty names can't contain spaces. For example, a senior technician specialty should be entered as SeniorTechnician. | Text |
Order Pairs
The Order Pairs 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 Pairs: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
|
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 list. | Text |
|
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 list. The first order in the pair must be a pickup order; that is, the value for its delivery quantity fields are null. The second order in the pair must be a delivery order; that is, the value for its pickup quantity fields are 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. | Text |
|
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 at 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: minimize the overall excess transit time, regardless of the increase in travel cost for the fleet; find a solution that balances overall violation time and travel cost; or 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 value is surpassed. | Double |
Route Renewals
The Route Renewals table 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 it. 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 renewals:
- 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 Renewals: Input fields
| Input field | Description | Data type |
|---|---|---|
ObjectID | The system-managed ID field. | Object ID |
|
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 list. | Text |
|
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 list. | Text |
|
ServiceTime | The service time for the renewal. 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 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. | Double |
Route Renewals: Input/output fields
| Input/Output field | Description | Data type |
|---|---|---|
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, 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. | Text |
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.
VRP analysis layer properties
The following subsections list parameters you can set on the analysis layer. They are found on the VRP Layer tab, which is available only if your VRP layer or one of its sublayers is selected in the Contents pane.
Analysis
Use the options in this section to estimate the credits and run the analysis.
Run
Once you load input features and set analysis properties, click the Run button to run the analysis. If the analysis uses credits, and the number of credits estimated for the solve exceeds the available credits, an error message appears that blocks the solve or a warning message that allows you to choose whether to proceed with the solve.
The run button may appear different based on the source of the network dataset.
—The network analysis layer is referencing a local network data source.
—The network analysis layer is referencing a network data source in ArcGIS Online.
—The network analysis layer is referencing a network data source in an ArcGIS Enterprise portal.
Estimate Credits
You can use the Estimate Credits button to estimate the number of service credits that will be consumed by running the analysis on the selected network analysis layer. When this button is enabled, it indicates that the network analysis layer will consume credits when solved.
The Estimate Credits button is enabled when the following occur:
- The network analysis layer's network data source is hosted in ArcGIS Online.
- Your ArcGIS Enterprise portal routing services are configured from ArcGIS Online.
The Estimate Credits button is disabled when the following occur:
- The network analysis layer's network data source is stored on a local machine.
- You're using your own services published on your ArcGIS Enterprise portal.
When you click the Estimate Credits button, a dialog box appears with an estimate of the number of credits that are likely to be consumed solving the current analysis. The credit estimate is based on the number of input locations used in the analysis. The actual credits consumed may change based on the output generated by the Solve operation. Depending on how your organization has set up the credit budgeting and allocation settings, the available credits may not be shown. Also, credit estimation may not always be possible if the network data source is an ArcGIS Enterprise portal with routing services configured from ArcGIS Online.
Learn more about the credit usage by each analysis type
Note:
Depending on the configuration of the ArcGIS Online organization account and the signed-in user, solving the analysis may be blocked or may show a warning if the estimated credits exceed the available credits.
Input Data
Use the options in this section to import the input features to participate in the analysis.
Import Orders
Click the Import Orders button 
to load features from another data source, such as a point feature layer, into the Orders feature class.
Import Depots
Click the Import Depots button 
to load features from another data source, such as a point feature layer, into the Depots feature class.
Import Routes
From the drop-down menu, you can choose to import the routes or add routes.
- Import Routes
—Use this control to load features from another data source, such as a line feature layer or a stand-alone table, into the Routes feature class. - Add Routes
—Use this control to create multiple routes at once using the Add Vehicle Routing Problem Routes geoprocessing tool.
Import Breaks
From the drop-down menu, you can choose to import the breaks or add breaks.
- Import Breaks
—Use this control to load features from another data source, such as a point feature layer or stand-alone table, into the Breaks feature class. - Add Breaks
—Use this control to create multiple breaks at once using the Add Vehicle Routing Problem Breaks geoprocessing tool.
Import Barriers
Use the Import Point Barriers 
, Import Line Barriers 
, or Import Polygon Barriers buttons 
to load features from another data source, such as another feature layer, into one of the barriers feature classes (point barriers, line barriers, or polygon barriers).
Create Features
Use the Create Features button 
to open the Create Features pane. Select from the available templates to create features in the current map.
Import Route Zones
Use the Import Route Zones button 
to load features from another data source, such as a polygon feature layer, into the Route Zones feature class.
Import Order Pairs
Use the Import Order Pairs button 
to load features from another data source, such as a stand-alone table, into the Order Pairs table.
Import Route Renewals
Use the Import Route Renewals button 
to load features from another data source, such as a stand-alone table, into the Route Renewals table.
Import Order Specialties
Use the Import Order Specialties button 
to load features from another data source, such as a stand-alone table, into the Order Specialties table.
Import Route Specialties
Use the Import Route Specialties button 
to load features from another data source, such as a stand-alone table, into the Route Specialties table.
Travel Settings
Use the options in the Travel Settings section to select the travel mode.
Mode
Use the Mode drop-down list to choose a travel mode, which is a group of settings that together model the movement of pedestrians, cars, trucks, or other travel mode. The choices available in the drop-down list depend on the travel modes that are configured on the network data source that the network analysis layer is referencing.
Time Field Units
The time units used by the temporal fields of the analysis layer's sublayers and tables. The following options are available from the drop-down list:
- Seconds
- Minutes
- Hours
- Days
Distance Field Units
The distance units used by distance fields of the analysis layer's sublayers and tables. The following options are available from the drop-down list:
- Meters
- Kilometers
- Feet
- Miles
- Nautical Miles
- Centimeters
- Millimeters
- Decimeters
- Yards
- Inches
Default Date
Use the options from this section to specify the date, time, and day to be used in the analysis.
Learn more about date and time
Default Date Type
The default date is used in the date and time fields when only a time is provided. The options in the Default Date Type drop-down list are as follows:
Date—Specify the calendar date.
Day of Week—Specify a day of the week:
- Sunday
- Monday
- Tuesday
- Wednesday
- Thursday
- Friday
- Saturday
Today—The day is assumed to be the current date.
Reference Time Zone
From the Reference Time Zone drop-down list 
, you can choose the time zone to use in the analysis. The options are as follows:
- Local Time at Locations
- UTC (Universal Coordinated Time)
Output Geometry
Use the options from the drop-down menu to choose how the output will display in the map.
Output Geometry Linear Shape Type
The analysis always solves least-cost paths along the network using the settings you specify, but in addition to displaying these true paths along the network on the map, you can also choose to represent the routes on a map using simple straight lines between stops or no lines at all.
- No Lines—No output linear shapes are generated.
- Straight Lines—Output simplified geometry as straight lines.
- Along Network—Generate true paths along the network on the map.
Note:
The Straight Lines option is not available when the VRP layers are referencing a VRP service or Portal.Drawing
Use the Symbology button 
to access the symbology pane for the active network analysis layer. You can configure the symbology for the sublayers of the active network analysis layer by choosing one of the following options:
- Single Color—This option is available for all network analysis layer types. All feature sublayers in the active network analysis layer except barriers will use the same single symbol with the specified color. For example, choosing a single color of blue for a Route layer will convert all the Stops and Routes features to the same color of blue.
- Color Linked—This option is available for Route, Last Mile Delivery, and Vehicle Routing problem layers. It applies a color scheme to the sublayers such that related features are symbolized with the same color. This symbology configuration symbolizes related features with the same color, making it easier to visually distinguish different routes and their associated features in the map. For example, for a Route layer with multiple routes, each route and the stops assigned to that route will be assigned matching colors.
Filtering
You can filter the network analysis sublayers to only show features related to the selected features in the primary layer.
Add Filters
—Applies filters to sublayers of the network analysis layer to only show features related to the selected feature of the primary sublayer. Definition queries are automatically created and applied on the relevant sublayers. Every time the Add Filters button is clicked, a new definition query is created with the same name replacing the previous definition query. When a feature is selected in the primary sublayer Routes, a definition query called Routes is created on the Routes sublayer (primary layer) and the related Orders, Breaks, Depot Visits, and Route Zones sublayers.
Remove Filters
—Deletes the definition query on the primary and the related sublayers.
Advanced
Use controls in this section to specify advanced settings for the analysis.
Time Window Importance
You can configure the importance of minimizing time window violations while running the analysis using the Time Window Importance setting 
. With a higher preference for meeting the time windows, the solver will generate a solution that will reduce time window violations but increase the overall solve cost. You can choose from the following options:
 | High—Choose this setting if arriving on time at orders is more important than minimizing your overall solution cost. On setting the time window importance to high, the control changes to reflect the selection. |
 | Medium—The solver looks for a balance between meeting time windows and reducing the overall solution cost. On setting the time window importance to medium, the control changes to reflect the selection. |
 | Low—Choose this setting if respecting time windows is less important than reducing your overall solution cost. On setting the time window importance to low, the control changes to reflect the selection. |
Transit Time Importance
The parameter is only relevant if using Order Pairs. The Transit Time Importance setting 
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.
You can choose from the following options:
 | High—Choose this setting to find a solution with less excess transit time between paired orders at the expense of increasing the overall travel costs. On setting the transit time importance to high, the control changes to reflect the selection. |
 | Medium—The solver looks for a balance between reducing excess transit time and reducing the overall solution cost. On setting the transit time importance to medium, the control changes to reflect the selection. |
 | Low—Choose this setting to find a solution that minimizes the overall solution cost. On setting the transit time importance to low, the control changes to reflect the selection. |
Cluster
Use the Cluster property 
to allow you to use spatial clustering.
 | Cluster—The orders assigned to an individual route will be spatially clustered. Clustering orders tends to keep routes in smaller areas and reduce how often route lines intersect one another; yet, clustering can increase overall travel times. |
 | Do Not Cluster—The solver will not prioritize spatially clustering orders and the route lines might intersect. Choose this option if route zones are specified. |
Directions
Use the options from the Directions section to specify whether directions should be generated.
Note:
The VRP solver uses a time-neutral Origin Destination Cost Matrix (OD) to determine the route assignment and sequencing. The values from this time-neutral OD are used to populate the time and distance costs for the Orders, Depot Visits, and Routes fields, for consistency with the optimization logic used to solve the problem. After the sequence of stops and depot visits is finalized for each route, the Route solver is used to generate directions and uses the actual starting time of the route, allowing the directions fields to be populated with more accurate arrival times based on traffic.
Output on Solve
Turn on this option to generate directions upon solve for the current network analysis layer.
Show Directions
When the Output on Solve option is checked, when you click the Show Directions button 
, the Directions pane appears with turn-by-turn directions for each route in the
solution.
Share As
Share the output of the analysis by using the available option of Route Layers.
Share as Route Layers
Use the Route Layers button 
to share the results from the analysis as route layers. This button opens the Share as Route Layers geoprocessing tool. After it runs, the results from the analysis are shared as route layer items in the portal.
Limitations
Listed below are some limitations when running the analysis on a VRP layer:
- The maximum number of orders on a route cannot exceed 1,000.
- All the cost-based fields cannot be over 1 billion—for example, FixedCost in the Routes table.
- All the distance fields cannot exceed 1 million kilometers—for example, MaxTotalDistance in the Routes table.
- The difference between the largest and smallest date value in the input cannot exceed one year.
- The maximum number of breaks for each route is five, and the precedence value for any break cannot exceed 5.
- The value of time duration fields cannot exceed 365.25 days. The value is in the units specified by the Time Units parameter. For example, the Service time value cannot exceed 31,557,600 if the Time Units parameter is Seconds.
The following limitations apply in addition to the ones stated above if a VRP layer is being solved using an ArcGIS Online portal:
- You can specify up to 250 features to act as point barriers.
- If the number of street features intersected by all the line barriers exceeds 500, the tool returns an error.
- If the number of street features intersected by all the polygon barriers exceeds 2,000, the tool returns an error.
- The straight-line distance between all the stops and the start and end locations for the route cannot be greater than 27 miles (43.45 kilometers) when the travel mode is Walking Time or Walking Distance.