Summary
Makes a vehicle routing problem (VRP) network analysis layer and sets its analysis properties. A vehicle routing problem analysis layer is useful for optimizing a set of routes using a fleet of vehicles.
Usage
After creating the analysis layer with this tool, you can add network analysis objects to it using the Add Locations tool, solve the analysis using the Solve tool, and save the results on disk using the Save To Layer File tool.
-
When using this tool in geoprocessing models, if the model is run as a tool, the output network analysis layer must be made a model parameter; otherwise, the output layer is not added to the contents of the map.
Syntax
MakeVehicleRoutingProblemLayer_na (in_network_dataset, out_network_analysis_layer, time_impedance, {distance_impedance}, {time_units}, {distance_units}, {default_date}, {capacity_count}, {time_window_factor}, {excess_transit_factor}, {UTurn_policy}, {restriction_attribute_name}, {hierarchy}, {hierarchy_settings}, {output_path_shape})| Parameter | Explanation | Data Type |
in_network_dataset | The network dataset on which the vehicle routing problem analysis will be performed. The network dataset must have a time based cost attribute since the VRP solver minimizes time. | Network Dataset Layer |
out_network_analysis_layer | Name of the vehicle routing problem network analysis layer to create. | String |
time_impedance | 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. | String |
distance_impedance (Optional) | The distance cost attribute used to define the length along the elements of the network. The distance cost attribute is optional. | String |
time_units (Optional) | 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.
| String |
distance_units (Optional) | 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.
| String |
default_date (Optional) |
The implied date for time field values that don't have a date specified with the time. If a time field for an order object, such as TimeWindowStart1, has a time-only value, the date is assumed to be the default date. For example, if an order has a TimeWindowStart1 value of 9:00 AM and the default date is March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6, 2013. The default date has no effect on time field values that already have a date. The day of the week can also be specified as the default date using the following dates.
If your network dataset includes 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. | Date |
capacity_count (Optional) |
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. | Long |
time_window_factor (Optional) | This parameter 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 Importance parameter. The following list describes what the values mean and how the resulting VRP solution can vary:
| String |
excess_transit_factor (Optional) | This parameter 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. The VRP solution can change according to the value you choose for the Excess Transit Time Importance. The following list describes what the values mean and how the resulting VRP solution can vary:
| String |
UTurn_policy (Optional) | The U-Turn policy at junctions. Allowing U-turns implies the solver can turn around at a junction and double back on the same street. Given that junctions represent street intersections and dead ends, different vehicles may be able to turn around at some junctions but not at others—it depends on whether the junction represents an intersection or dead end. To accommodate this, the U-turn policy parameter is implicitly specified by how many edges connect to the junction, which is known as junction valency. The acceptable values for this parameter are listed below; each is followed by a description of its meaning in terms of junction valency.
If you need a more precisely defined U-turn policy, consider adding a global turn delay evaluator to a network cost attribute, or adjusting its settings if one exists, and pay particular attention to the configuration of reverse turns. Also, look at setting the CurbApproach property of your network locations. | String |
restriction_attribute_name [restriction_attribute_name,...] (Optional) | List of restriction attributes to apply during the analysis. | String |
hierarchy (Optional) |
The parameter is not used if a hierarchy attribute is not defined on the network dataset used to perform the analysis. In such cases, use "#" as the parameter value. | Boolean |
hierarchy_settings (Optional) | Network Analyst Hierarchy Settings | |
output_path_shape (Optional) |
| String |
Derived Output
| Name | Explanation | Data Type |
| output_layer |
Code sample
MakeVehicleRoutingProblemLayer example 1 (Python window)
Execute the tool using only the required parameters.
import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemLayer("Transportation/Streets_ND",
"DeliveryRoutes","Minutes")
MakeVehicleRoutingProblemLayer example 2 (Python window)
Execute the tool using all parameters.
import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemLayer("Transportation/Streets_ND",
"FridayRoutes","Minutes","Meters",
"Minutes","Miles", "1/2/1900", "1",
"High","Medium","ALLOW_DEAD_ENDS_ONLY",
["Oneway"],"USE_HIERARCHY","",
"TRUE_LINES_WITHOUT_MEASURES")
MakeVehicleRoutingProblemLayer example 3 (workflow)
The following stand-alone Python script demonstrates how the MakeVehicleRoutingProblemLayer tool can be used for servicing a set of orders with a fleet of vehicles.
# Name: MakeVehicleRoutingProblemLayer_Workflow.py
# Description: Find the best routes for a fleet of vehicles, which is operated
# by a distribution company, to deliver goods from a main
# distribution center to a set of grocery stores.
# Requirements: Network Analyst Extension
#Import system modules
import arcpy
from arcpy import env
try:
#Check out the Network Analyst extension license
arcpy.CheckOutExtension("Network")
#Set environment settings
env.workspace = "C:/data/SanFrancisco.gdb"
env.overwriteOutput = True
#Set local variables
inNetworkDataset = "Transportation/Streets_ND"
outNALayerName = "StoreDeliveryRoute"
impedanceAttribute = "TravelTime"
distanceAttribute = "Meters"
timeUntis = "Minutes"
distanceUntis = "Miles"
inOrders = "Analysis/Stores"
inDepots = "Analysis/DistributionCenter"
inRoutes = "RoutesTable"
outLayerFile = "C:/data/output/" + outNALayerName + ".lyr"
#Create a new Vehicle routing problem (VRP) layer. Since the time-based
#attributes such as ServiceTime on orders and CostPerUnitTime on routes is
#recorded in minutes, we use minutes for time_units parameter. As we are
#using cost per unti distance in routes, we have to specify a
#distance attribute. The values for CostPerUnitDistance are in miles, so we
#specify miles for distance units parameter.
outNALayer = arcpy.na.MakeVehicleRoutingProblemLayer(inNetworkDataset, outNALayerName,
impedanceAttribute,
distanceAttribute, timeUntis,
distanceUntis, "", 1,
UTurn_policy = "NO_UTURNS",
output_path_shape = "STRAIGHT_LINES")
#Get the layer object from the result object. The VRP layer can now be
#referenced using the layer object.
outNALayer = outNALayer.getOutput(0)
#Get the names of all the sublayers within the VRP layer.
subLayerNames = arcpy.na.GetNAClassNames(outNALayer)
#Stores the layer names that we will use later
ordersLayerName = subLayerNames["Orders"]
depotsLayerName = subLayerNames["Depots"]
routesLayerName = subLayerNames["Routes"]
#Load the store locations as orders. Using field mappings we map the
#TimeWindowStart1, TimeWindowEnd1 and DeliveryQuantities
#properties for Orders from the fields of store features and assign a value
#of 0 to MaxViolationTime1 property. The Name and ServiceTime properties have
#the correct mapped field names when using the candidate fields from store
#locations feature class.
candidateFields = arcpy.ListFields(inOrders)
orderFieldMappings = arcpy.na.NAClassFieldMappings(outNALayer, ordersLayerName,
False, candidateFields)
orderFieldMappings["TimeWindowStart1"].mappedFieldName = "TimeStart1"
orderFieldMappings["TimeWindowEnd1"].mappedFieldName = "TimeEnd1"
orderFieldMappings["DeliveryQuantities"].mappedFieldName = "Demand"
orderFieldMappings["MaxViolationTime1"].defaultValue = 0
arcpy.na.AddLocations(outNALayer, ordersLayerName, inOrders, orderFieldMappings,"")
#Load the depots from the distribution center features. Using field mappings
#we map the Name properties for Depots from the fields of distribution
#center features and assign a value of 8 AM for TimeWindowStart1 and a value
#of 5PM for TimeWindowEnd2 properties
depotFieldMappings = arcpy.na.NAClassFieldMappings(outNALayer, depotsLayerName)
depotFieldMappings["Name"].mappedFieldName = "Name"
depotFieldMappings["TimeWindowStart1"].defaultValue = "8 AM"
depotFieldMappings["TimeWindowEnd1"].defaultValue = "5 PM"
arcpy.na.AddLocations(outNALayer, depotsLayerName, inDepots, depotFieldMappings, "")
#Load the routes from a table containing information about routes
#In this case, since the fields on the routes table and property names for
#Routes are same, we will just use the default field mappings
arcpy.na.AddLocations(outNALayer, routesLayerName, inRoutes, "", "")
#Solve the VRP layer
arcpy.na.Solve(outNALayer)
#Save the solved VRP layer as a layer file on disk with relative paths
arcpy.management.SaveToLayerFile(outNALayer,outLayerFile,"RELATIVE")
print "Script completed successfully"
except Exception as e:
# If an error occurred, print line number and error message
import traceback, sys
tb = sys.exc_info()[2]
print "An error occurred on line %i" % tb.tb_lineno
print str(e)
Environments
Licensing information
- ArcGIS Desktop Basic: Yes
- ArcGIS Desktop Standard: Yes
- ArcGIS Desktop Advanced: Yes