Zusammenfassung
Erstellt einen Netzwerkanalyse-Layer für das Vehicle Routing Problem und legt seine Analyseeigenschaften fest. Ein Analyse-Layer für das Vehicle Routing Problem ist für die Optimierung verschiedener Routen bei einer Fahrzeugflotte hilfreich.
Verwendung
Nachdem Sie den Analyse-Layer mit diesem Werkzeug erstellt haben, können Sie ihm Netzwerkanalyse-Objekte mithilfe des Werkzeugs Standorte hinzufügen hinzufügen, die Analyse mit dem Werkzeug Berechnen berechnen und die Ergebnisse mit dem Werkzeug In Layer-Datei speichern auf der Festplatte speichern.
Bei Verwendung dieses Werkzeugs in Geoverarbeitungsmodellen muss der Ausgabe-Netzwerkanalyse-Layer in einen Modellparameter geändert werden, wenn das Modell als Werkzeug ausgeführt wird. Andernfalls wird der Ausgabe-Layer dem Inhalt der Karte nicht hinzugefügt.
Syntax
MakeVehicleRoutingProblemLayer(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 | Erklärung | Datentyp |
in_network_dataset | Das Netzwerk-Dataset, für das die Analyse des Vehicle Routing Problem ausgeführt wird. Das Netzwerk-Dataset muss ein zeitbasiertes Kostenattribut aufweisen, da mit dem VRP-Solver die Zeit minimiert wird. | Network Dataset Layer |
out_network_analysis_layer | Name des zu erstellenden Netzwerkanalyse-Layers für das Vehicle Routing Problem. | String |
time_impedance | Das Zeitkostenattribut, mit dem die Routenzeit entlang der Netzwerkelemente definiert wird. Das Zeitkostenattribut ist erforderlich, da der VRP-Solver (Vehicle Routing Problem) die Zeiten minimiert. | String |
distance_impedance (optional) | Das Entfernungskostenattribut, mit dem die Länge entlang der Netzwerkelemente definiert wird. Das Entfernungskostenattribut ist optional. | String |
time_units (optional) | Die Zeiteinheiten, die von den Zeitdatenfeldern in den Sublayern und Tabellen des Analyse-Layers verwendet werden (Netzwerkanalyseklassen). Diese Einstellung muss nicht mit den Einheiten des Zeitkostenattributs übereinstimmen.
| String |
distance_units (optional) | Die Entfernungseinheiten, die von den Entfernungsfeldern in den Sublayern und Tabellen des Analyse-Layers verwendet werden (Netzwerkanalyseklassen). Diese Einstellung muss nicht mit den Einheiten des optionalen Entfernungskostenattributs übereinstimmen.
| String |
default_date (optional) |
Das implizite Datum für Zeitfeldwerte, für die kein Datum für die Uhrzeit angegeben wurde. Wenn ein Zeitfeld für ein Auftragsobjekt, z. B. TimeWindowStart1, einen reinen Uhrzeitwert enthält, wird als Datum das Standarddatum verwendet. Wenn ein Auftrag beispielsweise den TimeWindowStart1-Wert von 9:00 Uhr aufweist und als Standarddatum der 6. März 2013 festgelegt ist, wird als vollständiger Zeitwert für das Feld der Wert "9:00 Uhr, 6. März 2013" verwendet. Das Standarddatum wirkt sich nicht auf Zeitfeldwerte aus, für die bereits ein Datum festgelegt ist. Mithilfe der folgenden Datumsangaben kann auch ein Wochentag als Standarddatum angegeben werden.
Wenn das Netzwerk-Dataset Verkehrsdaten enthält, können sich die Ergebnisse der Analyse abhängig von dem hier angegebenen Datum ändern. Im Vergleich zu einer Startzeit um 8:00 Uhr am Sonntag, wenn nicht viel Verkehr ist, dauern die Routen länger, die an einem Montag um 8:00 Uhr zur Hauptverkehrszeit durchgeführt werden. Außerdem kann sich die optimale Route abhängig von den Verkehrsbedingungen ändern. | Date |
capacity_count (optional) |
Die Anzahl der Abmessungen für die zulässige Höchstlast, mit denen die jeweiligen Höchstlasten der Fahrzeuge beschrieben werden. Bei einem Lieferauftrag kann für jedes Fahrzeug eine Höchstlast oder ein Höchstvolumen gelten, das aufgrund physischer oder gesetzlicher Bedingungen auf einmal befördert werden darf. Wenn Sie die Last und das Volumen in den Aufträgen verfolgen, können Sie hier unter Verwendung dieser beiden Kapazitätswerte eine Überladung der Fahrzeuge verhindern. Die Kapazitätszahl für dieses Szenario lautet 2 (Volumen und Gewicht). Je nach Problem möchten Sie vielleicht unterschiedliche Arten von Kapazitätsmengen verfolgen. Die in die Kapazitätsfelder eingegebenen Kapazitäten ("DeliveryQuantities" und "PickupQuantities" für die Klasse "Aufträge" und "Capacities" für die Klasse "Routen") sind durch Leerzeichen getrennte numerische Zeichenfolgen, die so viele Werte enthalten können, wie in "Kapazitätszahl" festgelegt ist. Jedes Kapazitätsmaß sollte für alle Kapazitätsfeldwerte innerhalb desselben VRP-Analyse-Layers in derselben Positionsreihenfolge angezeigt werden. Die Kapazitäten selbst sind nicht benannt. Um eine versehentliche Verschiebung der Kapazitätsparameter zu vermeiden, stellen Sie sicher, dass die durch Leerzeichen getrennten Kapazitätslisten für alle Kapazitätsfeldwerte immer in derselben Reihenfolge eingegeben werden. | Long |
time_window_factor (optional) | Mit diesem Parameter können Sie festlegen, wie wichtig die Einhaltung von Zeitfenstern ist, ohne damit eine Zeitverletzung zu definieren. Eine Zeitfensterverletzung tritt auf, wenn eine Route nach dem Schließen eines Zeitfensters einen Auftrag, ein Depot oder eine Unterbrechung erreicht. Als Verletzung ist das Intervall zwischen dem Ende des Zeitfensters und der Ankunftszeit einer Route definiert. Die VRP-Lösung kann sich je nach dem Wert, den Sie für den Parameter Gewichtung der Zeitfensterverletzung auswählen, ändern. In der folgenden Liste wird die Bedeutung der verschiedenen Werte beschrieben und es werden mögliche Auswirkungen auf die VRP-Lösung genannt:
| String |
excess_transit_factor (optional) | Mit diesem Parameter können Sie festlegen, wie wichtig die Reduzierung von Fahrzeitüberschreitungen ist. Die Fahrzeitüberschreitung entspricht der Zeit, um die die direkte Fahrzeit zwischen den Auftragspaaren überschritten wird. Die Fahrzeitüberschreitung ergibt sich aus Unterbrechungen oder Fahrten zu anderen Aufträgen oder Depots, die zwischen den Auftragspaaren stattgefunden haben. Die VRP-Lösung kann sich je nach dem Wert, den Sie für die Eigenschaft "Gewichtung der Fahrzeitüberschreitung" auswählen, ändern. In der folgenden Liste wird die Bedeutung der verschiedenen Werte beschrieben und es werden mögliche Auswirkungen auf die VRP-Lösung genannt:
| String |
UTurn_policy (optional) | Die Wendenregel an Knoten. Das Zulassen von Wenden bedeutet, dass der Solver an einem Knoten wenden und auf der gleichen Straße wieder zurückführen kann. Da diese Knoten Straßenkreuzungen und Sackgassen darstellen können, kann es sein, dass verschiedene Fahrzeuge an manchen Knoten wenden können und an anderen wiederum nicht. Dies hängt davon ab, ob der Knoten eine Kreuzung oder eine Sackgasse darstellt. Um dies zu berücksichtigen, wird der Parameter "Wendenregel" implizit durch die Anzahl der mit der Kreuzung verbundenen Kanten angegeben. Diese Anzahl wird als Valenz der Knoten bezeichnet. Die zulässigen Werte für diesen Parameter sowie eine Beschreibung der jeweiligen Bedeutung in Bezug auf die Valenz der Knoten sind unten aufgelistet.
Falls Sie eine Wendenregel benötigen, die genauer definiert ist, können Sie einem Netzwerkkostenattribut einen globalen Evaluator für Verzögerung bei Kantenübergängen hinzufügen oder dessen Einstellungen anpassen, sofern dieser vorhanden ist, und der Konfiguration von U-förmigen Kantenübergängen einen besonderen Stellenwert einräumen. Ziehen Sie auch die Einstellung der CurbApproach-Eigenschaft Ihrer Netzwerkstandorte in Erwägung. | String |
restriction_attribute_name [restriction_attribute_name,...] (optional) | Eine Liste mit Beschränkungsattributen, die während der Analyse angewendet werden sollen. | String |
hierarchy (optional) |
Der Parameter wird nicht verwendet, wenn ein Hierarchie-Attribut nicht für das Netzwerk-Dataset definiert ist, das zum Durchführen der Analyse verwendet wird. Verwenden Sie in solchen Fällen "#" als Parameterwert. | Boolean |
hierarchy_settings (optional) | Network Analyst Hierarchy Settings | |
output_path_shape (optional) |
| String |
Abgeleitete Ausgabe
| Name | Erklärung | Datentyp |
| output_layer | Der neu erstellte Netzwerkanalyse-Layer. | Network Analyst-Layer |
Codebeispiel
MakeVehicleRoutingProblemLayer – Beispiel 1 (Python-Fenster)
Ausführen des Werkzeugs, wenn nur die erforderlichen Parameter verwendet werden.
import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemLayer("Transportation/Streets_ND",
"DeliveryRoutes","Minutes")
MakeVehicleRoutingProblemLayer – Beispiel 2 (Python-Fenster)
Führen Sie das Werkzeug unter Verwendung aller Parameter aus.
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 – Beispiel 3 (Workflow)
Mit dem folgenden eigenständigen Python-Skript wird veranschaulicht, wie das Werkzeug MakeVehicleRoutingProblemLayer verwendet werden kann, um eine Reihe von Aufträgen mit einer Fahrzeugflotte durchzuführen.
# 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)
Umgebungen
Lizenzinformationen
- Basic: Ja
- Standard: Ja
- Advanced: Ja