ArcGIS Help 10.1 - Make Vehicle Routing Problem Layer (Network Analyst)

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.

Note:

The Make Vehicle Routing Problem Layer and Solve Vehicle Routing Problem tools are similar, but they are designed for different purposes. Use the Solve Vehicle Routing Problem tool if you are setting up a geoprocessing service; it will simplify the setup process. Otherwise, use the Make Vehicle Routing Problem Layer tool.

To create a VRP geoprocessing service using Solve Vehicle Routing Problem Layer, you only need to set up one tool and publish it as a service. In contrast, you need to create a model with the Make Vehicle Routing Problem Layer, properly connect it to various other tools, and publish the model to create a service.

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 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 table of contents in ArcMap.

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. Seconds Minutes Hours Days	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. Miles Kilometers Feet Yards Meters Inches Centimeters Millimeters Decimeters NauticalMiles	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. Today—12/30/1899 Sunday—12/31/1899 Monday—1/1/1900 Tuesday—1/2/1900 Wednesday—1/3/1900 Thursday—1/4/1900 Friday—1/5/1900 Saturday—1/6/1900 For example, to specify that the implied date for time field values should be Tuesday, specify the parameter value as 1/2/1900. 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: High —The solver tries to find a solution that minimizes time window violations at the expense of increasing the overall travel time. Choose High if arriving on time at orders is more important to you than minimizing your overall solution cost. This may be the case if you are meeting customers at your orders and you don't want to inconvenience them with tardy arrivals (another option is to use hard time windows that can't be violated at all).Given other constraints of a vehicle routing problem, it may be impossible to visit all the orders within their time windows. In this case, even a High setting might produce violations. Medium —This is the default setting. The solver looks for a balance between meeting time windows and reducing the overall solution cost. Low —The solver tries to find a solution that minimizes overall travel time, regardless of time windows. Choose Low if respecting time windows is less important than reducing your overall solution cost. You may want to use this setting if you have a growing backlog of service requests. For the purpose of servicing more orders in a day and reducing the backlog, you can choose Low even though customers will be inconvenienced with your fleet's late arrivals.	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: High —The solver tries to find a solution with less excess transit time between paired orders at the expense of increasing the overall travel costs. It makes sense to use this setting if you are transporting people between paired orders and you want to shorten their ride time. This is characteristic of taxi services. Medium —This is the default setting. The solver looks for a balance between reducing excess transit time and reducing the overall solution cost. Low —The solver tries to find a solution that minimizes overall solution cost, regardless of excess transit time. This setting is commonly used with courier services. Since couriers transport packages as opposed to people, they don't need to worry about ride time. Using Low allows the couriers to service paired orders in the proper sequence and minimize the overall solution cost.	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, 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. ALLOW_UTURNS —U-turns are permitted at junctions with any number of connected edges. This is the default value. NO_UTURNS —U-turns are prohibited at all junctions, regardless of junction valency. Note, however, that U-turns are still permitted at network locations even when this setting is chosen; however, you can set the individual network locations' CurbApproach property to prohibit U-turns there as well. ALLOW_DEAD_ENDS_ONLY —U-turns are prohibited at all junctions, except those that have only one adjacent edge (a dead end). ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY —U-turns are prohibited at junctions where exactly two adjacent edges meet but are permitted at intersections (junctions with three or more adjacent edges) and dead ends (junctions with exactly one adjacent edge). Oftentimes, networks have extraneous junctions in the middle of road segments. This option prevents vehicles from making U-turns at these locations. Tip: 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)	USE_HIERARCHY — Use the hierarchy attribute for the analysis. Using a hierarchy results in the solver preferring higher-order edges to lower-order edges. Hierarchical solves are faster, and they can be used to simulate the preference of a driver who chooses to travel on freeways over local roads when possible—even if that means a longer trip. This option is valid only if the input network dataset has a hierarchy attribute. NO_HIERARCHY —Do not use the hierarchy attribute for the analysis. Not using a hierarchy yields an exact route for the network dataset. 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)	Legacy: Prior to version 10, this parameter allowed you to change the hierarchy ranges for your analysis from the default hierarchy ranges established in the network dataset. At version 10, this parameter is no longer supported and should be specified as an empty string. If you wish to change the hierarchy ranges for your analysis, update the default hierarchy ranges in the network dataset.	Network Analyst Hierarchy Settings
output_path_shape (Optional)	TRUE_LINES_WITH_MEASURES —The output routes will have the exact shape of the underlying network sources. Furthermore, the output includes route measurements for linear referencing. The measurements increase from the first stop and record the cumulative impedance to reach a given position. TRUE_LINES_WITHOUT_MEASURES —The output routes will have the exact shape of the underlying network sources. STRAIGHT_LINES —The output route shape will be straight lines connecting orders and depot visits as per the route sequence. NO_LINES —No shape will be generated for the output routes. You will also not be able to generate driving directions.	String

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 occured on line %i" % tb.tb_lineno
    print str(e)

Environments

Current Workspace

Licensing Information

ArcGIS for Desktop Basic: Yes

ArcGIS for Desktop Standard: Yes

ArcGIS for Desktop Advanced: Yes

1/20/2015

Make Vehicle Routing Problem Layer (Network Analyst)