arcpy.na.MakeVehicleRoutingProblemAnalysisLayer(network_data_source, {layer_name}, {travel_mode}, {time_units}, {distance_units}, {default_date}, {time_zone_for_time_fields}, {line_shape}, {time_window_factor}, {excess_transit_factor}, {generate_directions_on_solve}, {spatial_clustering}, {ignore_invalid_locations}, {analysis_geodatabase}, {analysis_feature_dataset_name})
|
Name
|
Explanation
|
Data type
|
|
network_data_source
|
The network dataset or service on which the network analysis will be performed.
The parameter can be specified using one of the following:
The catalog path to the network dataset
A network dataset layer object
The string name of the network dataset layer
The URL for ArcGIS Online or an ArcGIS Enterprise portal configured with standard routing services
To use a portal URL, you must be signed in to the portal with an account that has routing privileges.
Learn how to sign in to a portal in Python
Learn more about network analysis using routing services
When using ArcGIS Online or an ArcGIS Enterprise portal whose routing services are configured using ArcGIS Online as the input network, solving the analysis will consume credits and will be subject to certain limits, such as the number of allowed inputs.
Learn more about credit consumption and analysis limits in network analysis
The network must have at least one travel mode whose impedance attribute has units of time.
|
Network Dataset Layer; String
|
|
layer_name
(Optional)
|
The name of the VRP network analysis layer to create.
|
String
|
|
travel_mode
(Optional)
|
The name of the travel mode to use in the analysis. The travel mode represents a collection of network settings, such as travel restrictions and U-turn policies, that determine how a pedestrian, car, truck, or other medium of transportation moves through the network. Travel modes are defined on your network data source. An arcpy.na.TravelMode object and a string containing the valid JSON representation of a travel mode can also be used as input to the parameter.
The travel mode must have an impedance attribute with units of time.
|
String
|
|
time_units
(Optional)
|
Specifies the time units to be used by the temporal fields of the analysis layer's sublayers and tables (network analysis classes). This value does not need to match the units of the time cost attribute.
Learn more about cost attributes
Minutes—The time units will be minutes. This is the default.
Seconds—The time units will be seconds.
Hours—The time units will be hours.
Days—The time units will be days.
|
String
|
|
distance_units
(Optional)
|
Specifies the distance units to be used by the distance fields of the analysis layer's sublayers and tables (network analysis classes). This value does not need to match the units of the optional distance cost attribute.
Learn more about cost attributes
Miles—The distance units will be miles. This is the default.
Kilometers—The distance units will be kilometers.
Feet—The distance units will be feet.
Yards—The distance units will be yards.
Meters—The distance units will be meters.
Inches—The distance units will be inches.
Centimeters—The distance units will be centimeters.
Millimeters—The distance units will be millimeters.
Decimeters—The distance units will be decimeters.
NauticalMiles—The distance units will be nautical miles.
|
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 TimeWindowStart, has a time-only value, the date is assumed to be the default date. The default date has no effect on time field values that already have a date.
Configure the analysis to use one of the following special dates to model a day of the week or the current date instead of a specific, static date:
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
Learn more about how dates and times are used and interpreted in a network analysis
|
Date
|
|
time_zone_for_time_fields
(Optional)
|
Specifies the time zone to be used for the input date-time fields supported by the tool.
Specifying the date-time values in UTC is useful if you do not know the time zone in which the orders or depots are located or when you have orders and depots in multiple time zones and you want all the date-time values to start simultaneously. The UTC option is applicable only when your network dataset defines a time zone attribute. Otherwise, all the date-time values are treated as the time zone corresponding to that location.
LOCAL_TIME_AT_LOCATIONS—The date-time values associated with the orders or depots will be in the time zone in which the orders and depots are located. For routes, the date-time values are based on the time zone in which the starting depot for the route is located. If a route does not have a starting depot, all orders and depots across all the routes must be in a single time zone. For breaks, the date-time values are based on the time zone of the routes. This is the default.
UTC—The date-time values associated with the orders or depots will be in coordinated universal time (UTC) and are not based on the time zone in which the orders or depots are located.
|
String
|
|
line_shape
(Optional)
|
Specifies the shape type that will be used for the route features that are output by the analysis.
Regardless of the output shape type specified, the best route is always determined by the network impedance, not Euclidean distance. This means that only the route shapes are different, not the underlying traversal of the network.
ALONG_NETWORK—The output routes will have the exact shape of the underlying network sources. 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.
NO_LINES—No shape will be generated for the output routes.
STRAIGHT_LINES—The output route shape will be a single straight line between the stops.This option is not available if the selected network data source is a service.
|
String
|
|
time_window_factor
(Optional)
|
Specifies 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.
High—The solver searches for a solution that minimizes time window violations at the expense of increasing the overall travel time. Choose this setting if arriving on time at orders is more important than minimizing the 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 late arrivals (another option is to use rigid time windows that cannot be violated).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 may produce violations.
Medium—The solver searches for a balance between meeting time windows and reducing the overall solution cost. This is the default.
Low—The solver searches for a solution that minimizes overall travel time, regardless of time windows. Choose this setting if respecting time windows is less important than reducing the 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 this setting even though customers may be inconvenienced with your fleet's late arrivals.
|
String
|
|
excess_transit_factor
(Optional)
|
Specifies the importance of reducing excess transit time. Excess transit time is the amount of time exceeding the time required to travel directly between paired orders. The excess time results from breaks or travel to other orders or depots between visits to the paired orders. This parameter is only relevant if you're using Order Pairs.
Learn more about Order Pairs
High—The solver searches for a solution with less excess transit time between paired orders at the expense of increasing the overall travel costs. 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—The solver searches for a balance between reducing excess transit time and reducing the overall solution cost. This is the default.
Low—The solver searches for 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, ride time is not as important. Using this setting allows couriers to service paired orders in the proper sequence and minimize the overall solution cost.
|
String
|
|
generate_directions_on_solve
(Optional)
|
Specifies whether directions will be generated when running the analysis.
For an analysis in which generating turn-by-turn directions is not needed, turn directions generation off to reduce the time it takes to solve the analysis.
|
Boolean
|
|
spatial_clustering
(Optional)
|
Specifies whether spatial clustering will be used.
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; however, clustering can increase overall travel times. This is the default.
NO_CLUSTER—The solver will not prioritize spatially clustering orders and the route lines may intersect. Use this option if route zones are specified.
|
Boolean
|
|
ignore_invalid_locations
(Optional)
|
Specifies whether invalid input locations will be ignored.
SKIP—Invalid input locations will be ignored so that the analysis will succeed using only valid locations.
HALT—Invalid locations will not be ignored and will cause the analysis to fail. This is the default.
|
Boolean
|
|
analysis_geodatabase
(Optional)
|
The file geodatabase workspace where the new network analysis layer's sublayer data will be stored. When this parameter is not specified, the sublayer data will be created in the Current Workspace geoprocessing environment, which is usually the project geodatabase.
Learn more about the analysis data source of a network analysis layer
|
Workspace
|
|
analysis_feature_dataset_name
(Optional)
|
The name to use for the new feature dataset that the tool will create in the analysis geodatabase to store the network analysis layer's sublayer data. When not specified, the feature dataset will be created with a random unique name.
Learn more about the analysis data source of a network analysis layer
|
String
|
Derived output
|
Name
|
Explanation
|
Data type
|
|
out_network_analysis_layer
|
The new network analysis layer.
|
Network Analyst Layer
|
Code sample
MakeVehicleRoutingProblemAnalysisLayer example 1 (Python window)
Run the tool using only the required parameters.
import arcpy
arcpy.env.workspace = "C:/Data/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemAnalysisLayer("Transportation/Streets_ND")
MakeVehicleRoutingProblemAnalysisLayer example 2 (Python window)
Run the tool using all parameters.
import arcpy
arcpy.env.workspace = "C:/Data/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemAnalysisLayer('Streets_ND', 'FridayRoutes',
'Driving Time', 'Minutes',
'Miles', '1/2/2020',
'LOCAL_TIME_AT_LOCATIONS',
'TRUE_LINES_WITHOUT_MEASURES',
'High', 'Medium', 'DIRECTIONS')
MakeVehicleRoutingProblemAnalysisLayer example 3 (workflow)
The following stand-alone Python script demonstrates how the MakeVehicleRoutingProblemAnalysisLayer function can be used for servicing a set of orders with a fleet of vehicles.
# Name: MakeVRPAnalysisLayer_Ex3_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
import os
try:
# Set environment settings
output_dir = r"C:\Data"
# The NA layer's data will be saved to the workspace specified here
arcpy.env.workspace = os.path.join(output_dir, "Output.gdb")
arcpy.env.overwriteOutput = True
# Set local variables
input_gdb = "C:/Data/SanFrancisco.gdb"
network = os.path.join(input_gdb, "Transportation", "Streets_ND")
layer_name = "StoreDeliveryRoute"
travel_mode = "Driving Time"
time_units = "Minutes"
distance_units = "Miles"
in_orders = os.path.join(input_gdb, "Analysis", "Stores")
in_depots = os.path.join(input_gdb, "Analysis", "DistributionCenter")
in_routes = os.path.join(input_gdb, "Analysis", "Routes")
output_layer_file = os.path.join(output_dir, layer_name + ".lyrx")
# 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 unit distance in routes, we have to specify a distance
# attribute. The values for CosterPerUnitDistance are in miles, so we
# specify miles for distance units parameter
result_object = arcpy.na.MakeVehicleRoutingProblemAnalysisLayer(
network, layer_name, travel_mode, time_units, distance_units,
line_shape="STRAIGHT_LINES")
# Get the layer object form the result object. The route layer can now be
# referenced using the layer object.
layer_object = result_object.getOutput(0)
# Get the names of all the sublayers within the VRP layer.
sub_layer_names = arcpy.na.GetNAClassNames(layer_object)
# Store the layer names that we will use later
orders_layer_name = sub_layer_names["Orders"]
depots_layer_name = sub_layer_names["Depots"]
routes_layer_name = sub_layer_names["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.
candidate_fields = arcpy.ListFields(in_orders)
order_field_mappings = arcpy.na.NAClassFieldMappings(layer_object, orders_layer_name, False, candidate_fields)
order_field_mappings["TimeWindowStart"].mappedFieldName = "TimeStart1"
order_field_mappings["TimeWindowEnd"].mappedFieldName = "TimeEnd1"
order_field_mappings["DeliveryQuantity_1"].mappedFieldName = "Demand"
order_field_mappings["MaxViolationTime"].defaultValue = 0
arcpy.na.AddLocations(layer_object, orders_layer_name, in_orders, order_field_mappings, "")
# 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 5 PM for TimeWindowEnd1 properties
depot_field_mappings = arcpy.na.NAClassFieldMappings(layer_object, depots_layer_name)
depot_field_mappings["Name"].mappedFieldName = "Name"
depot_field_mappings["TimeWindowStart"].defaultValue = "8 AM"
depot_field_mappings["TimeWindowEnd"].defaultValue = "5 PM"
arcpy.na.AddLocations(layer_object, depots_layer_name, in_depots, depot_field_mappings, "")
# 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 the same, we will just use the default field mappings
routes_field_mappings = arcpy.na.NAClassFieldMappings(layer_object, routes_layer_name)
routes_field_mappings["Name"].mappedFieldName = "Name"
routes_field_mappings["StartDepotName"].mappedFieldName = "StartDepotName"
routes_field_mappings["EndDepotName"].mappedFieldName = "EndDepotName"
routes_field_mappings["StartDepotServiceTime"].mappedFieldName = "StartDepotServiceTime"
routes_field_mappings["Capacity_1"].mappedFieldName = "Capacities"
routes_field_mappings["CostPerUnitTime"].mappedFieldName = "CostPerUnitTime"
routes_field_mappings["CostPerUnitDistance"].mappedFieldName = "CostPerUnitDistance"
routes_field_mappings["MaxOrderCount"].mappedFieldName = "MaxOrderCount"
routes_field_mappings["MaxTotalTime"].mappedFieldName = "MaxTotalTime"
routes_field_mappings["MaxTotalTravelTime"].mappedFieldName = "MaxTotalTravelTime"
routes_field_mappings["MaxTotalDistance"].mappedFieldName = "MaxTotalDistance"
arcpy.na.AddLocations(layer_object, routes_layer_name, in_routes, routes_field_mappings, "")
# Solve the VRP layer
arcpy.na.Solve(layer_object)
# Save the solved VRP layer as a layer file on disk with relative paths
arcpy.management.SaveToLayerFile(layer_object, output_layer_file, "RELATIVE")
print("Script Completed Successfully")
except Exception as e:
# If an error occurred, print line number and error message
import traceback
import sys
tb = sys.exc_info()[2]
print("An error occurred on line %i" % tb.tb_lineno)
print(str(e))