Vehicle Routing Problem berechnen (Network Analyst)
Zusammenfassung
Erstellt einen Vehicle Routing Problem (VRP)-Netzwerkanalyse-Layer, legt die Analyse-Eigenschaften fest und berechnet die Analyse, was ideal für die Einrichtung eines VRP-Web-Service ist. Ein Analyse-Layer für das Vehicle Routing Problem findet die besten Routen für eine Fahrzeugflotte.
![Hinweis Hinweis](rsrc/note.png)
Die Werkzeuge Layer für Vehicle Routing Problem erstellen und Vehicle Routing Problem berechnen sind ähnlich, jedoch für unterschiedliche Zwecke konzipiert. Verwenden Sie das Werkzeug Vehicle Routing Problem berechnen, wenn Sie einen Geoverarbeitungs-Service einrichten. Der Prozess der Erstellung wird dadurch vereinfacht. Verwenden Sie andernfalls das Werkzeug Layer für Vehicle Routing Problem erstellen.
Um einen VRP-Geoverarbeitungs-Service mit Vehicle Routing Problem berechnen zu erstellen, müssen Sie nur ein Werkzeug einrichten und es als Service veröffentlichen. Im Gegensatz dazu müssen Sie mit Layer für Vehicle Routing Problem erstellen ein Modell erstellen, es mit verschiedenen anderen Werkzeugen ordnungsgemäß verbinden und das Modell veröffentlichen, um einen Service zu erstellen. Eine andere Möglichkeit stellen ArcGIS Online Vehicle Routing Problem Services dar. Die Services werden wie Geoverarbeitungswerkzeuge in ArcMap ausgeführt, können von anderen Anwendungen aufgerufen werden und enthalten qualitativ hochwertige Straßendaten für einen Großteil der Welt.
Weitere Informationen zu Lernprogrammdaten für die Einrichtung eines Beispiel-VRP-Geoverarbeitungs-Service finden Sie unter Überblick über Beispiele des ArcGIS Network Analyst-Geoverarbeitungs-Service.
Verwendung
Im Dialogfeld des Werkzeugs sind die verschiedenen optionalen Parameter in die folgenden sechs Kategorien gruppiert, um Ihnen die Verwaltung zu erleichtern:
- Erweiterte Analyse
- Barrieren
- Netzwerk-Dataset
- Netzwerkstandorte
- Ausgabe
- Service-Funktionen
Weitere Informationen zur Ausgabe von "Vehicle Routing Problem berechnen"
Syntax
Parameter | Erläuterung | Datentyp |
orders |
Die Aufträge, die die Routen der VRP-Analyse berücksichtigen sollten. Ein Auftrag kann eine Lieferung (z. B. eine Möbellieferung), eine Abholung (z. B. die Abholung eines Passagiers durch einen Airport Shuttle-Bus) oder eine Art von Service oder Prüfung (z. B. das Zurückschneiden eines Baumes oder die Prüfung eines Gebäudes) repräsentieren. Das Auftrags-Feature-Set weist eine zugeordnete Attributtabelle auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. Name: Der Name des Auftrags. Der Name muss eindeutig sein. Wenn kein Name angegeben wird, wird zum Zeitpunkt der Berechnung automatisch ein Name erstellt. ServiceTime: Diese Eigenschaft gibt an, wie viel Zeit am Netzwerkstandort verbracht wird, wenn die Route zu ihm führt. Das heißt, in ihr wird der Wert für die Impedanz des Netzwerkstandorts gespeichert. Ein 0 oder NULL-Wert weist darauf hin, dass der Netzwerkstandort keine Durchführungszeit erfordert. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. ![]()
TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass kein zweites Zeitfenster vorhanden ist. Wenn das erste Zeitfenster gemäß den Feldern "TimeWindowStart1" und "TimeWindowEnd1" NULL ist, muss das zweite Zeitfenster ebenfalls NULL sein. Wenn es sich bei beiden Fenstern um Nicht-NULL-Fenster handelt, können sie nicht überlappen. Außerdem muss das zweite Zeitfenster auf das erste folgen. TimeWindowEnd2: Die Endzeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Wenn "TimeWindowStart2" und "TimeWindowEnd2" beide NULL sind, gibt es kein zweites Zeitfenster. Wenn "TimeWindowStart2" nicht NULL ist, aber "TimeWindowEnd2" NULL ist, gibt es ein zweites Zeitfenster, das eine Startzeit, aber keine Endzeit hat. Dies ist zulässig. MaxViolationTime1: Eine Zeitfensterverletzung liegt vor, wenn die Ankunftszeit auftritt, nachdem das Zeitfensters beendet wurde. Dieses Feld gibt den maximal zulässigen Zeitverstoß für das erste Zeitfenster des Auftrags an. Es darf den Wert 0, jedoch keinen negativen Wert enthalten. Der Wert 0 gibt an, dass kein Verstoß gegen das erste Zeitfenster des Auftrags zulässig ist, d. h. das erste Zeitfenster ist ein sog. "hartes" Zeitfenster. Ein Nullwert hingegen gibt an, dass der zulässige Zeitverstoß unbegrenzt ist. Ein Wert ungleich 0 gibt die maximale Verspätung an. Beispielsweise kann ein Fahrzeug bis zu 30 Minuten nach dem Ende des ersten Zeitfensters bei einem Auftrag ankommen. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). Zeitfensterverletzungen können vom Solver verfolgt und gewichtet werden. Daher können Sie für den VRP-Solver eine von drei Strategien festlegen:
Wenn Sie für den Parameter Time Window Violation Importance (time_window_factor für Python) eine Gewichtung zuweisen, wählen Sie letztendlich eine dieser drei Strategien aus. Der Solver gibt jedoch in jedem Fall einen Fehler zurück, wenn der für "MaxViolationTime1" festgelegte Wert überschritten wird. MaxViolationTime2: Der maximal zulässige Zeitverstoß für das zweite Zeitfenster des Auftrags. Dieses Feld entspricht dem Feld "MaxViolationTime1". DeliveryQuantities: Die Größe der Lieferung. Sie können die Größe in jeder beliebigen Dimension, wie Gewicht, Volumen oder Menge, angeben. Sie können sogar mehrere Dimensionen, wie beispielsweise Gewicht und Volumen, angeben. Geben Sie Liefermengen ohne die Angabe von Einheiten ein. Beispiel: Wenn ein 135 Kilogramm schwerer Artikel geliefert werden muss, geben Sie 135 ein. Sie müssen daran denken, dass der Wert in Kilogramm angegeben ist. Wenn Sie mehrere Bemaßungen verfolgen, trennen Sie die numerischen Werte mit Leerzeichen. Wenn Sie beispielsweise das Gewicht und Volumen einer Lieferung mit einem Gewicht von 900 Kilogramm und einem Volumen von 3 Kubikmetern erfassen, geben Sie 900 3 ein. Sie müssen sich erneut die Einheiten merken, in diesem Fall Kilogramm und Kubikmeter. Sie müssen sich ferner merken, in welcher Sequenz die Werte und ihre entsprechenden Einheiten eingegeben werden. Stellen Sie sicher, dass Kapazitäten für Routen und DeliveryQuantities sowie PickupQuantities für Aufträge auf die gleiche Weise angegeben werden. Das bedeutet, dass die Werte sich in denselben Einheiten befinden müssen, und dass die Dimensionen für alle Parameter in derselben Reihenfolge aufgelistet werden müssen, wenn Sie mehrere Dimensionen verwenden. Wenn Sie Gewicht in Kilogramm gefolgt von einem Volumen in Kubikmeter für DeliveryQuantities angeben, müssen die Kapazität der Routen und die PickupQuantities der Aufträge auf die gleiche Weise angegeben werden: Gewicht in Kilogramm, gefolgt von Volumen in Kubikmeter. Wenn Sie Einheiten vermischen oder die Reihenfolge ändern, erhalten Sie unerwünschte Ergebnisse, ohne eine Warnmeldung zu empfangen. Eine leere Zeichenfolge oder ein Nullwert gibt an, dass alle Dimensionen Null sind. Wenn die Anzahl der Werte in der Zeichenfolge geringer als die Kapazitätszahl oder die Anzahl der verfolgten Dimensionen ist, werden die restlichen Werte als Nullen behandelt. Für "DeliveryQuantities" sind negative Werte nicht zulässig. PickupQuantities: Die Größe der Abholung. Sie können die Größe in jeder beliebigen Dimension, wie Gewicht, Volumen oder Menge, angeben. Sie können sogar mehrere Dimensionen, wie beispielsweise Gewicht und Volumen, angeben. Sie können jedoch keine negativen Werte verwenden. Dieses Feld entspricht dem Feld "DeliveryQuantities" für Aufträge. ![]() Bei einem Austauschbesuch kann ein Auftrag Werte für "DeliveryQuantities" und "PickupQuantities" aufweisen. Revenue: Die generierten Einnahmen, wenn der Auftrag in einer Lösung enthalten ist. Dieses Feld darf einen Nullwert (ein Nullwert steht für Einnahmen in Höhe von 0), jedoch keinen negativen Wert enthalten. "Revenue" wird beim Optimieren des Zielfunktionswertes einbezogen, ist jedoch nicht Bestandteil der Betriebskosten für die Lösung. Das bedeutet, dass das Feld "TotalCost" in der Klasse "Routen" niemals "Revenue" enthält. Jedoch wird für "Revenue" die relative Gewichtung der Ausführung von Aufträgen berücksichtigt. SpecialtyNames: Eine durch Leerzeichen getrennte Zeichenfolge mit den Namen der für den Auftrag erforderlichen Besonderheiten. Ein Nullwert gibt an, dass der Auftrag keine Besonderheiten erfordert. Die Schreibweise der Besonderheiten in den Klassen "Orders" und "Routes" muss exakt übereinstimmen, sodass der VRP-Solver sie verknüpfen kann. Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Baum und Strauchschnittarbeiten durchführt, für einen Teil ihrer Aufträge ein Fahrzeug mit einer Hebebühne benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge BucketTruck in das Feld "SpecialtyNames" ein, um auf diese besondere Anforderung hinzuweisen. Für die anderen Aufträge bleibt der Wert des Feldes "SpecialtyNames " Null. Entsprechend gibt die Firma BucketTruck auch in das Feld "SpecialtyNames" von Routen ein, die von Fahrzeugen mit hydraulischen Auslegern befahren werden. Für die anderen Routen bleibt der Wert des Feldes Null. Zum Zeitpunkt der Berechnung weist der VRP-Solver jeder Route Aufträge ohne besondere Anforderungen zu, er weist jedoch Aufträge, die Fahrzeuge mit Hebebühnen erfordern, nur den Routen zu, die darüber verfügen. AssignmentRule: In diesem Feld ist die Regel zum Zuweisen des Auftrags zu einer Route angegeben. Sie wird von einer Domäne von Werten eingeschränkt, die unten aufgeführt sind (codierte Werte werden in Klammern angegeben).
Dieses Feld darf keinen Nullwert enthalten. CurbApproach: Die Eigenschaft "CurbApproach" gibt die Richtung an, in der ein Fahrzeug am Netzwerkstandort ankommen bzw. von ihm wegfahren kann. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar:
RouteName: Der Name der Route, der der Auftrag zugewiesen wird. Als Eingabefeld dient dieses Feld zum Vorabzuweisen eines Auftrags zu einer bestimmten Route. Es kann einen Nullwert enthalten, um anzugeben, dass der Auftrag keiner Route vorab zugewiesen ist. In diesem Fall erfolgt die Zuweisung der bestmöglichen Route für den Auftrag durch den Solver. Wenn das Feld auf Null festgelegt ist, muss das Feld "Sequence" ebenfalls auf Null festgelegt werden. Wenn der Auftrag einer Route zugewiesen wurde, enthält das Feld "RouteName" nach einem Berechnungsvorgang den Namen der Route, der der Auftrag zugewiesen ist. Sequence: Gibt die Sequenz des Auftrags auf der zugewiesenen Route an. Als Eingabefeld dient dieses Feld zum Angeben der relativen Sequenz eines Auftrags auf der Route. Das Feld kann einen Nullwert enthalten, um anzugeben, dass der Auftrag an einer beliebigen Position auf der Route eingefügt werden kann. Ein Nullwert ist nur gemeinsam mit einem Nullwert für "RouteName" zulässig. Die Eingabesequenzwerte sind positiv und für jede Route eindeutig (gültig für Depotstopps zum Be-/Entladen, Aufträge und Pausenzeiten), müssen jedoch nicht bei 1 beginnen und nicht zusammenhängend sein. Nach einem Berechnungsvorgang enthält das Feld "Sequence" den Sequenzwert des Auftrags für die zugewiesene Route. Ausgabesequenzwerte für eine Route gelten für Depotstopps, Aufträge und Pausenzeiten, sie beginnen bei 1 (beim Startdepot) und sind aufeinander folgende Werte. Daher ist der kleinstmögliche Ausgabesequenzwert für einen einer Route zugewiesenen Auftrag 2, weil eine Route immer bei einem Depot beginnt. | Feature Set |
depots |
Ein Depot ist ein Standort, den ein Fahrzeug am Anfang des Arbeitstages verlässt, und zu dem es am Ende des Arbeitstages zurückkehrt. Fahrzeuge werden zu Beginn der Route in Depots beladen (für Lieferungen) oder entladen (für Abholungen). In einigen Fällen kann ein Depot auch als Lager fungieren, an dem das Fahrzeug Artikel entladen oder laden kann, um weitere Lieferungen oder Abholungen durchzuführen. Ein Depot weist Öffnungs- und Schließzeiten auf, die durch ein hartes Zeitfenster angegeben werden. Fahrzeuge dürfen nicht außerhalb dieses Zeitfensters bei einem Depot eintreffen. Das Depot-Feature-Set weist eine zugeordnete Attributtabelle auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. Name: Der Name des Depots. Die Felder "StartDepotName" und "EndDepotName" des Routen-Record-Set referenzieren die Namen, die Sie hier angeben. Es wird auch vom Lager (Be-/Entladen)-Record-Set referenziert, wenn dieses verwendet wird. Bei Depotnamen muss nicht zwischen Groß- und Kleinschreibung unterschieden werden, sie müssen angegeben werden und eindeutig sein. TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. ![]()
TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass kein zweites Zeitfenster vorhanden ist. Wenn das erste Zeitfenster gemäß den Feldern "TimeWindowStart1" und "TimeWindowEnd1" NULL ist, muss das zweite Zeitfenster ebenfalls NULL sein. Wenn es sich bei beiden Fenstern um Nicht-NULL-Fenster handelt, können sie nicht überlappen. Außerdem muss das zweite Zeitfenster auf das erste folgen. TimeWindowEnd2: Die Endzeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen Nullwert enthalten. Wenn "TimeWindowStart2" und "TimeWindowEnd2" beide NULL sind, gibt es kein zweites Zeitfenster. Wenn "TimeWindowStart2" nicht NULL ist, aber "TimeWindowEnd2" NULL ist, gibt es ein zweites Zeitfenster, das eine Startzeit, aber keine Endzeit hat. Dies ist zulässig. CurbApproach: Die Eigenschaft "CurbApproach" gibt die Richtung an, in der ein Fahrzeug am Netzwerkstandort ankommen bzw. von ihm wegfahren kann. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar:
Peilung: Die Richtung, in die sich ein Punkt bewegt. Die Einheit ist Grad und wird im Uhrzeigersinn von geographisch Nord gemessen. Dieses Feld wird in Verbindung mit dem Feld "BearingTol" verwendet. Peilungsdaten werden normalerweise automatisch von einem mobilen Gerät gesendet, das mit einem GPS-Empfänger ausgestattet ist. Versuchen Sie Peilungsdaten einzubeziehen, wenn Sie einen sich bewegenden Auftrag laden, beispielsweise einen Fußgänger oder ein Fahrzeug. Durch die Verwendung dieses Feldes kann verhindert werden, dass Positionen falschen Kanten zugewiesen werden, was auftreten kann, wenn er sich zufällig in der Nähe einer Kreuzung oder einer Überführung befindet. Mithilfe der Peilung kann Network Analyst einfacher ermitteln, auf welcher Straßenseite sich der Punkt befindet. Weitere Informationen finden Sie unter Peilung und BearingTol. BearingTol: Anhand des Peilungstoleranzwertes wird ein Bereich mit zulässigen Peilungswerten erstellt, wenn Punkte über das Feld "Peilung" auf einer Kante bewegt werden. Wenn sich der Wert des Feldes "Peilung" innerhalb des Bereichs der zulässigen Werte befindet, die über die Peilungstoleranz auf einer Kante generiert werden, kann der Punkt dort als Netzwerkstandort hinzugefügt werden. Andernfalls wird der nächstgelegene Punkt an der übernächsten Kante ausgewertet. Die Einheit ist Grad und der Standardwert ist 30. Die Werte müssen zwischen 0 und 180 liegen. Der Wert 30 bedeutet, dass bei dem Versuch von Network Analyst, einer Kante einen Netzwerkstandort hinzuzufügen, ein zulässiger Peilungswertebereich in einem Winkel von 15 Grad auf beiden Seiten der Kante (links und rechts) und in beiden digitalisierenden Richtungen der Kante generiert wird. Weitere Informationen finden Sie unter Peilung und BearingTol. NavLatency: Dieses Feld wird nur im Berechnungsprozess verwendet, wenn "Bearing" und "BearingTol" ebenfalls Werte aufweisen. Die Eingabe eines "NavLatency"-Wertes ist jedoch optional, selbst wenn bei "Bearing" und "BearingTol" Werte vorhanden sind. "NavLatency" gibt an, wie viel Zeit voraussichtlich zwischen dem Senden von GPS-Informationen von einem sich bewegenden Fahrzeug zu einem Server und dem Empfang der verarbeiteten Route durch das Navigationsgerät des Fahrzeugs vergeht. Die Zeiteinheiten von "NavLatency" entsprechen den Einheiten des Kostenattributs, das durch den Parameter "Time Attribute" angegeben wird. | Feature Set |
routes |
Die Routen, die für das Vehicle Routing Problem vorhanden sind. Eine Route gibt die Fahrzeug- und Fahrereigenschaften an. Nach der Berechnung stellt sie außerdem den Pfad zwischen Depots und Aufträgen dar. Eine Route kann Start- und Enddurchführungszeiten (Depot), eine feste oder flexible Anfangszeit, zeitbasierte Betriebskosten, entfernungsbasierte Betriebskosten, mehrere Kapazitäten, verschiedene Einschränkungen hinsichtlich des Arbeitstags eines Fahrers usw. aufweisen. Der Routen-Record-Set weist verschiedene Attribute auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. Name: Der Name der Route. Der Name muss eindeutig sein. Wenn der Feldwert NULL ist, erstellt Network Analyst zum Zeitpunkt der Berechnung einen eindeutigen Namen. Daher ist die Eingabe eines Wertes in den meisten Fällen optional. Sie müssen jedoch einen Namen eingeben, wenn Ihre Analyse Unterbrechungen, Lager (Be-/Entladen), Routenzonen oder Aufträge umfasst, die einer Route vorab zugewiesen sind, da der Routenname in diesen Fällen als Fremdschlüssel verwendet wird. Bei Routennamen wird die Groß-/Kleinschreibung nicht beachtet. StartDepotName: Der Name des Startdepots für die Route. Dieses Feld dient als Fremdschlüssel für das Feld "Name" in der Klasse "Depots". Wenn der Wert für "StartDepotName" NULL ist, beginnt die Route mit dem ersten zugewiesenen Auftrag. Wenn die Startposition des Fahrzeuges unbekannt oder für das Problem irrelevant ist, empfiehlt es sich, das Startdepot nicht anzugeben. Wenn StartDepotName jedoch NULL ist, darf EndDepotName nicht ebenfalls NULL sein. Wenn über die Route Lieferungen erfolgen und "StartDepotName" NULL ist, wird davon ausgegangen, dass das Fahrzeug vor Routenbeginn in einem virtuellen Depot beladen wird. Für eine Route ohne Stopps zum Be-/Entladen werden die zugehörigen Lieferaufträge (mit Werten für "DeliveryQuantities" ungleich 0 in der Klasse "Aufträge") am Startdepot oder virtuellen Depot geladen. Für eine Route mit Stopps zum Be-/Entladen werden nur die Lieferaufträge vor dem ersten Stopp zum Be-/Entladen am Startdepot oder virtuellen Depot geladen. EndDepotName: Der Name des Enddepots für die Route. Dieses Feld dient als Fremdschlüssel für das Feld "Name" in der Klasse "Depots". StartDepotServiceTime: Die Durchführungszeit am Startdepot. Mit dieser kann die Zeit zum Beladen des Fahrzeugs modelliert werden. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). ![]() Bei der Durchführungszeit am Start- und Enddepot handelt es sich um feste Werte (von den Werten der Felder "StartDepotServiceTime" und "EndDepotServiceTime" angegeben), bei der das tatsächliche Beladen für eine Route nicht berücksichtigt wird. Beispielsweise kann die Zeit zum Beladen eines Fahrzeugs am Startdepot von der Größe der Aufträge abhängen. Als Durchführungszeiten für Depots können Werte festgelegt werden, die einer vollständigen LKW-Ladung oder einer durchschnittlichen LKW-Ladung entsprechen, oder Sie können einen eigenen Schätzwert festlegen. EndDepotServiceTime: Die Durchführungszeit am Enddepot. Mit dieser kann die Zeit zum Entladen des Fahrzeugs modelliert werden. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). ![]() Bei der Durchführungszeit am Start- und Enddepot handelt es sich um feste Werte (von den Werten der Felder "StartDepotServiceTime" und "EndDepotServiceTime" angegeben), bei der das tatsächliche Beladen für eine Route nicht berücksichtigt wird. Beispielsweise kann die Zeit zum Beladen eines Fahrzeugs am Startdepot von der Größe der Aufträge abhängen. Als Durchführungszeiten für Depots können Werte festgelegt werden, die einer vollständigen LKW-Ladung oder einer durchschnittlichen LKW-Ladung entsprechen, oder Sie können einen eigenen Schätzwert festlegen. EarliestStartTime: Die früheste zulässige Startzeit für die Route. Diese wird vom Solver in Verbindung mit dem Zeitfenster des Startdepots verwendet, um realistische Routenstartzeiten zu bestimmen. Dieses Feld darf keine NULL-Werte enthalten, und sein Standardwert für die reine Uhrzeit ist 8:00 Uhr. Der Standardwert wird als 8:00 Uhr an dem vom Parameter "Default Date" angegebenen Datum interpretiert (default_date für Python). Das Standarddatum wird ignoriert, wenn ein Zeitfenster ein Datum mit der Zeit enthält. Formatieren Sie alle Zeitfenster in Depots, Routen, Aufträgen und Pausenzeiten so, dass außer der Uhrzeit auch das Datum enthalten ist, um Fehler in dieser Situation auszuschließen. Beim Verwenden von Netzwerk-Datasets mit Verkehrsdaten über mehrere Zeitzonen hinweg entspricht die Zeitzone für "EarliestStartTime" der Zeitzone der Kante oder des Knotens, auf der bzw. dem sich das Startdepot befindet. LatestStartTime: Die späteste zulässige Startzeit für die Route. Dieses Feld darf keine NULL-Werte enthalten, und sein Standardwert für die reine Uhrzeit ist 10:00 Uhr. Der Standardwert wird als 10:00 Uhr an dem von der Eigenschaft "Standarddatum" des Analyse-Layers angegebenen Datum interpretiert. Beim Verwenden von Netzwerk-Datasets mit Verkehrsdaten über mehrere Zeitzonen hinweg entspricht die Zeitzone für "LatestStartTime" der Zeitzone der Kante oder des Knotens, auf der bzw. dem sich das Startdepot befindet. ArriveDepartDelay: In diesem Feld wird die Fahrzeitdauer gespeichert, die erforderlich ist, um das Fahrzeug auf normale Reisegeschwindigkeiten zu beschleunigen, bis zu einem Stopp zu verlangsamen und in das bzw. aus dem Netzwerk zu bewegen (z. B. in die Parkposition und aus der Parkposition). Indem ein Wert für "ArriveDepartDelay" verwendet wird, wird der VRP-Solver davon abgehalten, viele Routen zum Abarbeiten von Aufträgen mit physischer Lagegleichheit zu senden. Die Kosten für diese Eigenschaft treten zwischen Besuchen bei nicht lagegleichen Aufträgen, Depots und Lagern zum Be-/Entladen auf. Wenn eine Route beispielsweise an einem Depot startet und zum Besuch des ersten Auftrags führt, wird die Gesamtverzögerung bei der Ankunft und Abfahrt der Fahrzeit hinzugefügt. Dasselbe gilt für die Fahrt vom ersten Auftrag zum zweiten Auftrag. Wenn der zweite und dritte Auftrag lagegleich sind, wird der Wert unter "ArriveDepartDelay" dazwischen nicht hinzugefügt, da sich das Fahrzeug nicht bewegen muss. Wenn die Route dann zu einem Lager zum Be-/Entladen führt, wird der Wert der Fahrzeit wieder hinzugefügt. Obwohl ein Fahrzeug bei einer Pause die Fahrt verlangsamen und unterbrechen und danach wieder beschleunigen muss, kann der VRP-Solver den Wert unter "ArriveDepartDelay" für Pausen nicht hinzufügen. Dies bedeutet, dass die Verzögerung bei der Ankunft und Abfahrt nur einmal hinzugefügt wird (und nicht zweimal), wenn ein Fahrzeug auf einer Route den Ort eines Auftrags verlässt, für eine Pause anhält und dann weiter zum nächsten Auftrag fährt. Zur Veranschaulichung nehmen Sie an, dass für ein Hochhaus fünf lagegleiche Aufträge vorliegen, die mit drei verschiedenen Routen abgearbeitet werden sollen. Dies bedeutet, dass drei Verzögerungen bei der Ankunft und Abfahrt anfallen. Drei Fahrer müssen separat einen Parkplatz finden und dasselbe Gebäude betreten. Wenn die Aufträge jedoch von nur einer Route abgearbeitet werden können, muss nur ein Fahrer einen Parkplatz finden und das Gebäude betreten. Somit fällt nur eine Verzögerung bei der Ankunft und Abfahrt an. Da das Ziel des VRP-Solvers die Kostenreduzierung ist, versucht er, die Verzögerungen bei der Ankunft und Abfahrt zu beschränken, wählt also die Option mit nur einer Route. (Beachten Sie, dass ggf. mehrere Routen verwendet werden müssen, wenn andere Einschränkungen – z. B. Besonderheiten, Zeitfenster oder Kapazitäten – dies erfordern.) Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). Capacities: Die maximale Kapazität des Fahrzeugs. Sie können die Kapazität in jeder beliebigen Bemaßung angeben, wie Gewicht, Volumen oder Menge. Sie können sogar mehrere Dimensionen, wie beispielsweise Gewicht und Volumen, angeben. Geben Sie Kapazitäten ohne die Angabe von Einheiten ein. Beispiel: Wenn Ihr Fahrzeug maximal 18 Tonnen transportieren kann, geben Sie 18 ein. Sie müssen daran denken, dass der Wert in Kilogramm angegeben ist. Wenn Sie mehrere Bemaßungen verfolgen, trennen Sie die numerischen Werte mit Leerzeichen. Wenn beispielsweise Gewicht und Volumen erfasst werden und Ihr Fahrzeug ein Gewicht von max. 18 Tonnen und ein Volumen von max. 56 Kubikmeter transportieren kann, sollten die Kapazitäten wie folgt eingegeben werden: 18 56. Sie müssen sich wieder die Einheiten merken. Sie müssen sich ferner merken, in welcher Sequenz die Werte und ihre entsprechenden Einheiten eingegeben werden (in diesem Fall Kilogramm gefolgt von Kubikmetern). Die Einheiten und die Einheitensequenz sind aus verschiedenen Gründen wichtig: Erstens können Sie die Informationen später neu deuten, und zweitens können Sie angemessene Werte für die Felder "DeliveryQuantities" und "PickupQuantities" bei "Orders" eingeben. Beachten Sie hinsichtlich des zweiten Punktes, dass der VRP-Solver gleichzeitig "Capacities", "DeliveryQuantities" und "PickupQuantities" referenziert, um sicherzustellen, dass eine Route nicht überlastet wird. Da im Feld keine Einheiten eingegeben werden können, kann Network Analyst Einheiten nicht konvertieren. Das heißt, Sie müssen die Werte für die drei Felder in denselben Einheiten und derselben Einheitensequenz eingeben, um sicherzustellen, dass die Werte korrekt interpretiert werden. Wenn Sie Einheiten mischen oder die Sequenz in einem der drei Felder ändern, erhalten Sie unerwünschte Ergebnisse ohne Warnmeldungen. Daher wird empfohlen, vorher einen Einheiten- und Einheitensequenzstandard einzurichten und diesen bei der Eingabe von Werten für diese drei Felder einzuhalten. Eine leere Zeichenfolge oder ein Nullwert gibt an, dass alle Werte Null sind. Kapazitätswerte dürfen nicht negativ sein. Wenn die Anzahl der Werte in der Zeichenfolge "Capacities" im Verhältnis zu den Feldern "DeliveryQuantities" oder "PickupQuantities" bei "Orders" nicht ausreichend ist, werden die restlichen Werte als 0 behandelt. ![]() Der VRP-Solver führt lediglich einen einfachen booleschen Test durch, um festzustellen, ob die Kapazitäten überschritten werden. Wenn der Kapazitätswert einer Route größer als oder gleich der gesamten transportierten Menge ist, geht der VRP-Solver davon aus, dass die Fracht in das Fahrzeug passt. Abhängig von der tatsächlichen Form der Fracht und des Fahrzeugs kann diese Annahme jedoch falsch sein. Der VRP-Solver lässt beispielsweise zu, dass eine Kugel mit 1.000 Kubikfuß in einen LKW mit 1.000 Kubikfuß und einer Breite von 8 Fuß verladen wird. Tatsächlich hat die Kugel jedoch einen Durchmesser von 12,6 Fuß und passt nicht in den LKW mit einer Breite von 8 Fuß. FixedCost: Ein fester Geldbetrag, der nur anfällt, wenn die Route in einer Lösung verwendet wird (d. h. der Route sind Aufträge zugewiesen). Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass keine festen Kosten vorhanden sind. Diese Kosten sind Bestandteil der Gesamtbetriebskosten für die Route. CostPerUnitTime: Der Geldbetrag – pro Zeiteinheit an Arbeit – der für die Gesamtroutendauer, einschließlich Fahrzeiten, Durchführungszeiten und Wartezeiten bei Aufträgen, Depots und Pausen, anfällt. Dieses Feld darf keinen Nullwert enthalten, und der Standardwert ist 1,0. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). CostPerUnitDistance: Der – pro Einheit gefahrener Strecke – für die Routenlänge (gesamte Reisestrecke) anfallende Geldbetrag. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass keine Kosten vorhanden sind. Die Einheit für diesen Feldwert wird durch den Parameter "Uhrzeitfeldeinheiten" (distance_units für Python) angegeben. OvertimeStartTime: Die Dauer der regulären Arbeitszeit, bevor die Berechnung der Überstunden beginnt. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass keine Überstunden angewendet werden. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). Wenn beispielsweise bei Überschreiten einer Gesamtroutendauer von 8 Stunden für den Fahrer Überstunden bezahlt werden müssen und der Parameter "Time Field Units" auf Minuten festgelegt ist, wird "OvertimeStartTime" als 480 (8 Stunden * 60 Minuten/Stunde) angegeben. CostPerUnitOvertime: Der pro Zeiteinheit von Überstunden anfallende Geldbetrag. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass der Wert von "CostPerUnitOvertime" mit dem Wert von "CostPerUnitTime" identisch ist. MaxOrderCount: Die maximal zulässige Anzahl von Aufträgen für die Route. Dieses Feld darf keine Nullwerte enthalten, und der Standardwert ist 30. MaxTotalTime: Die maximal zulässige Routendauer. Die Routendauer umfasst Fahrzeiten sowie Durchführungs- und Wartezeiten bei Aufträgen, Depots und Pausen. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass für die Routendauer keine Einschränkung gilt. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). MaxTotalTravelTime: Die maximal zulässige Fahrzeit für die Route. Die Fahrzeit umfasst nur die Zeit für Fahrten im Netzwerk, ohne Durchführungs- oder Wartezeit. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass für die maximal zulässige Fahrzeit keine Einschränkung gilt. Dieser Feldwert darf nicht größer als der Wert des Feldes "MaxTotalTime" sein. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). MaxTotalDistance: Die maximal zulässige Reisestrecke für die Route. Die Einheit für diesen Feldwert wird durch den Parameter "Uhrzeitfeldeinheiten" (distance_units für Python) angegeben. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass für die maximal zulässige Reisestrecke keine Einschränkung gilt. SpecialtyNames: Eine durch Leerzeichen getrennte Zeichenfolge mit den Namen der von der Route unterstützten Besonderheiten. Ein NULL-Wert gibt an, dass die Route keine Besonderheiten unterstützt. Dieses Feld dient als Fremdschlüssel für das Feld "SpecialtyNames" in der Klasse "Orders". Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Baum und Strauchschnittarbeiten durchführt, für einen Teil ihrer Aufträge ein Fahrzeug mit einer Hebebühne benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge BucketTruck in das Feld "SpecialtyNames" ein, um auf diese besondere Anforderung hinzuweisen. Für die anderen Aufträge bleibt der Wert des Feldes "SpecialtyNames " Null. Entsprechend gibt die Firma BucketTruck auch in das Feld "SpecialtyNames" von Routen ein, die von Fahrzeugen mit hydraulischen Auslegern befahren werden. Für die anderen Routen bleibt der Wert des Feldes Null. Zum Zeitpunkt der Berechnung weist der VRP-Solver jeder Route Aufträge ohne besondere Anforderungen zu, er weist jedoch Aufträge, die Fahrzeuge mit Hebebühnen erfordern, nur den Routen zu, die darüber verfügen. AssignmentRule: Gibt an, ob die Route beim Lösen des Problems verwendet werden kann. Dieses Feld ist durch eine Domäne von Werten eingeschränkt. Die möglichen Werte lauten wie folgt:
| Record Set |
breaks | Die Unterbrechungszeiten bzw. Pausenzeiten für Routen in einem Vehicle Routing Problem. Eine Pausenzeit ist mit genau einer Route verknüpft und kann nach Abschluss eines Auftrags, auf dem Weg zu einem Auftrag oder vor dem Abarbeiten eines Auftrags eingelegt werden. Sie verfügt über eine Startzeit und eine Dauer, für die der Fahrer entweder bezahlt oder nicht bezahlt wird. Sie können drei Optionen verwenden, um den Beginn einer Pausenzeit festzulegen. Sie können ein Zeitfenster, eine maximale Fahrzeit oder eine maximale Arbeitszeit eingeben. Der Unterbrechungs-Record-Set weist verknüpfte Attribute auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben.
ObjectID: Das vom System verwaltete ID-Feld. RouteName: Der Name der Route, auf die die Pausenzeit angewendet wird. Eine Pausenzeit wird nur einer Route zugewiesen, aber einer Route können mehrere Pausenzeiten zugewiesen werden. Dieses Feld ist ein Fremdschlüssel für das Feld "Name" in der Klasse "Routen" und darf keinen Nullwert enthalten. Precedence: Mithilfe von Vorrangswerten wird die Abfolge von Pausenzeiten einer Route festgelegt. Pausenzeiten mit einem Vorrangswert von 1 treten vor Pausenzeiten mit einem Vorrangswert von 2 ein usw. Alle Pausenzeiten müssen unabhängig davon, ob es sich um Zeitfenster-Pausenzeiten, Pausenzeiten wegen maximaler Fahrzeit oder Pausenzeiten wegen maximaler Arbeitszeit handelt, einen Vorrangswert aufweisen. ServiceTime: Die Dauer der Pause. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). TimeWindowStart: Die Anfangszeit für das Zeitfenster der Pausenzeit. Wenn dieses Feld NULL ist und "TimeWindowEnd" über einen gültigen Tageszeitwert verfügt, kann die Pausenzeit jederzeit vor dem TimeWindowEnd-Wert starten. Wenn dieses Feld über einen Wert verfügt, müssen "MaxTravelTimeBetweenBreaks" und "MaxCumulWorkTime" NULL sein. Außerdem müssen alle anderen Pausenzeiten im Analyse-Layer Nullwerte für "MaxTravelTimeBetweenBreaks" und "MaxCumulWorkTime" aufweisen. Zur Berechnungszeit tritt ein Fehler auf, falls eine Route über mehrere Pausenzeiten mit überlappenden Zeitfenstern verfügt. Die Zeitfensterfelder für Pausen können einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein Zeitfeld, z. B. "TimeWindowStart", einen reinen Uhrzeitwert enthält (z. B. 00:00 Uhr), wird vorausgesetzt, dass als Datum das vom Parameter Default Date angegebene Datum verwendet wird (default_date für Python). Wenn Sie Datums- und Uhrzeitwerte verwenden (z. B. 11.7.2012 00:00 Uhr), können Sie Zeitfenster über mehrere Tage angeben. Dies empfiehlt sich besonders, wenn eine Pause kurz vor oder nach Mitternacht eingelegt werden soll. Das Standarddatum wird ignoriert, wenn ein Zeitfenster ein Datum mit der Zeit enthält. Formatieren Sie alle Zeitfenster in Depots, Routen, Aufträgen und Pausenzeiten so, dass außer der Uhrzeit auch das Datum enthalten ist, um Fehler in dieser Situation auszuschließen. Beim Verwenden von Netzwerk-Datasets mit Verkehrsdaten über mehrere Zeitzonen hinweg entspricht die Zeitzone für "TimeWindowStart" und "TimeWindowEnd" der Zeitzone der Kante oder des Knotens, auf der bzw. dem sich das Startdepot befindet. TimeWindowEnd: Die Endzeit für das Zeitfenster der Pausenzeit. Wenn dieses Feld NULL ist und "TimeWindowStart" über einen gültigen Tageszeitwert verfügt, kann die Pausenzeit jederzeit nach dem TimeWindowStart-Wert starten. Wenn dieses Feld über einen Wert verfügt, müssen "MaxTravelTimeBetweenBreaks" und "MaxCumulWorkTime" NULL sein. Außerdem müssen alle anderen Pausenzeiten im Analyse-Layer Nullwerte für "MaxTravelTimeBetweenBreaks" und "MaxCumulWorkTime" aufweisen. MaxViolationTime: Dieses Feld gibt den maximal zulässigen Zeitverstoß für eine Zeitfenster-Pausenzeit an. Eine Zeitfensterverletzung liegt vor, wenn die Ankunftszeit außerhalb der Zeitspanne liegt. Der Wert 0 gibt an, dass keine Zeitfensterverletzung zulässig ist. Das heißt, es handelt sich um ein hartes Zeitfenster. Ein Wert ungleich 0 gibt die maximale Verspätung an. Beispielsweise kann die Pause 30 Minuten nach dem Ende des zugehörigen Zeitfensters beginnen, jedoch wird die Verspätung entsprechend dem Parameter Time Window Violation Importance sanktioniert (time_window_factor für Python). Diese Eigenschaft kann NULL sein. Ein Nullwert mit TimeWindowStart- und TimeWindowEnd-Werten gibt an, dass für den zulässigen Zeitverstoß kein Grenzwert gilt. Wenn "MaxTravelTimeBetweenBreaks" oder "MaxCumulWorkTime" über einen Wert verfügt, muss "MaxViolationTime" NULL sein. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). MaxTravelTimeBetweenBreaks: Die maximale Fahrzeit, die akkumuliert werden kann, bevor die Pausenzeit genommen wird. Die Fahrzeit wird entweder ab dem Ende der vorherigen Pause oder, falls noch keine Pause eingelegt wurde, ab dem Start der Route akkumuliert. Wenn es sich um die letzte Pausenzeit der Route handelt, gibt "MaxTravelTimeBetweenBreaks" auch die maximale Fahrzeit an, die von der letzten Pause bis zum Enddepot akkumuliert werden kann. Mithilfe dieses Feldes kann der Zeitraum beschränkt werden, wie lange eine Person fahren darf, bis eine Pausenzeit erforderlich ist. Wenn der Parameter Time Field Units der Analyse auf "Minuten" festgelegt ist (time_units für Python) und "MaxTravelTimeBetweenBreaks" den Wert 120 enthält, kann der Fahrer nach zwei Stunden Fahrt eine Pause einlegen. Um eine Pause nach zwei weiteren Stunden Fahrt zuzuweisen, muss die Eigenschaft "MaxTravelTimeBetweenBreaks" der zweiten Pause auf den Wert 120 festgelegt werden. Wenn dieses Feld über einen Wert verfügt, müssen "TimeWindowStart", "TimeWindowEnd", "MaxViolationTime" und "MaxCumulWorkTime" NULL sein, damit eine Analyse erfolgreich berechnet werden kann. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). MaxCumulWorkTime: Die maximale Arbeitszeit, die akkumuliert werden kann, bevor die Pausenzeit genommen wird. Arbeitszeit wird immer ab dem Anfang der Route akkumuliert. Die Arbeitszeit ist die Summe der Fahrzeit und Durchführungszeiten für Aufträge, Depots und Pausenzeiten. Beachten Sie jedoch, dass die Wartezeit darin nicht enthalten ist. Dies ist die Zeit, die eine Route (bzw. ein Fahrer) am Ort eines Auftrags oder an einem Depot mit dem Warten auf das Beginn des Zeitfensters verbringt. Mithilfe dieses Feldes kann der Zeitraum beschränkt werden, wie lange eine Person arbeiten darf, bis eine Pausenzeit erforderlich ist. Wenn die Eigenschaft Uhrzeitfeldeinheiten auf "Minuten" festgelegt ist (time_units für Python), "MaxCumulWorkTime" den Wert 120 enthält und "ServiceTime" den Wert 15 aufweist, kann der Fahrer nach zwei Stunden Arbeit eine Pause von 15 Minuten einlegen. Angenommen, für das letzte Beispiel ist nach weiteren drei Stunden Arbeit eine zweite Pause erforderlich. Um diese Pause anzugeben, geben Sie 315 (fünf Stunden und fünfzehn Minuten) als MaxCumulWorkTime-Wert der zweiten Pause ein. In dieser Zahl sind die MaxCumulWorkTime- und ServiceTime-Werte der vorherigen Pausenzeit sowie die drei zusätzlichen Stunden Arbeitszeit vor dem Gewähren der zweiten Pause enthalten. Bedenken Sie dabei Folgendes: Um zu vermeiden, dass Pausen wegen maximaler Arbeitszeit vorzeitig eingelegt werden, wird die Arbeitszeit ab dem Anfang der Route akkumuliert. Außerdem enthält die Arbeitszeit die Durchführungszeiten von vorher besuchten Depots, Aufträgen und Pausenzeiten. Wenn dieses Feld über einen Wert verfügt, müssen "TimeWindowStart", "TimeWindowEnd", "MaxViolationTime" und "MaxTravelTimeBetweenBreaks" NULL sein, damit eine Analyse erfolgreich berechnet werden kann. Die Einheit für diesen Feldwert wird durch den Parameter Uhrzeitfeldeinheiten angegeben (time_units für Python). IsPaid: Ein boolescher Wert, der angibt, ob die Pausenzeit bezahlt wird. Der Wert True gibt an, dass die Pausenzeit in die Berechnung der Routenkosten sowie die Bestimmung der Überstunden einbezogen wird. Der Wert False gibt das Gegenteil an. Der Standardwert ist "True". Sequence: Gibt als Eingabefeld die Sequenz der Pause auf der zugehörigen Route an. Dieses Feld kann Nullwerte enthalten. Die Eingabesequenzwerte sind positiv und für jede Route eindeutig (gültig für Depotstopps zum Be-/Entladen, Aufträge und Pausenzeiten), müssen jedoch nicht bei 1 beginnen und nicht zusammenhängend sein. Der Solver ändert das Sequenzfeld. Nach dem Berechnungsvorgang enthält dieses Feld den Sequenzwert der Pausenzeit auf der zugehörigen Route. Ausgabesequenzwerte für eine Route gelten für Depotstopps, Aufträge und Pausenzeiten, sie beginnen bei 1 (beim Startdepot) und sind aufeinander folgende Werte. | Record Set |
time_units |
Die Zeiteinheiten für alle zeitbasierten Feldwerte in der Analyse.
Viele Features und Datensätze in einer VRP-Analyse weisen Felder zum Speichern von Zeitwerten auf, wie "ServiceTime" für Aufträge und "CostPerUnitTime" für Routen. Um Dateneingabeanforderungen zu minimieren, umfassen diese Feldwerte keine Einheiten. Stattdessen müssen alle entfernungsbasierten Feldwerte in den gleichen Einheiten eingegeben werden. Mit diesem Parameter werden die Einheiten dieser Werte angegeben. Zeitbasierte Ausgabefelder verwenden dieselben durch diesen Parameter angegebenen Einheiten. Diese Zeiteinheit muss nicht der Zeiteinheit des Netzwerkparameters Time Attribute entsprechen (time_attribute). | String |
distance_units |
Die Entfernungseinheiten für alle entfernungsbasierten Feldwerte in der Analyse.
Viele Features und Datensätze in einer VRP-Analyse weisen Felder zum Speichern von Entfernungswerten auf, wie "MaxTotalDistance" und "CostPerUnitDistance" für Routen. Um Dateneingabeanforderungen zu minimieren, umfassen diese Feldwerte keine Einheiten. Stattdessen müssen alle entfernungsbasierten Feldwerte in den gleichen Einheiten eingegeben werden. Mit diesem Parameter werden die Einheiten dieser Werte angegeben. Entfernungsbasierte Ausgabefelder verwenden dieselben durch diesen Parameter angegebenen Einheiten. Diese Entfernungseinheit muss nicht der Entfernungseinheit des Netzwerkparameters Distance Attribute entsprechen (distance_attribute). | String |
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 |
output_workspace_location |
Die ArcSDE-/File-Geodatabase oder der In-Memory-Workspace, in der bzw. dem die Ausgabe-Feature-Classes erstellt werden. Dieser Workspace muss bereits vorhanden sein. Der Standard-Ausgabe-Workspace befindet sich im Speicher. | Workspace |
output_unassigned_stops_name |
Der Name der Ausgabe-Feature-Class, die alle nicht erreichbaren Depots oder nicht zugewiesenen Aufträge enthalten soll. | String |
output_stops_name |
Der Name der Feature-Class, die die Stopps auf den Routen enthalten soll. Diese Feature-Class umfasst Stopps bei Depots, Aufträge und Unterbrechungen. | String |
output_routes_name |
Der Name der Feature-Class, die die Routen der Analyse enthalten soll. | String |
output_directions_name |
Der Name der Feature-Class, die die Wegbeschreibungen für die Routen enthalten soll. | String |
default_date (optional) |
Das Standarddatum für Zeitfeldwerte, die eine Uhrzeit, jedoch kein Datum angeben. | Date |
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. Zu diesem Zweck wird der Wendenregel-Parameter implizit angegeben, indem die Anzahl der mit der Kreuzung verbundenen Kanten angegeben wird, was als Valenz der Knoten bezeichnet wird. 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 |
time_window_factor (optional) |
Bewertet die Bedeutung der Einhaltung von Zeitfenstern. Es gibt drei Optionen, die unten aufgelistet und beschrieben sind.
| String |
spatially_cluster_routes (optional) |
| Boolean |
route_zones (optional) |
Weist Arbeitsgebiete für bestimmte Routen aus. Eine Routenzone ist ein Polygon-Feature. Mit ihr werden Routen eingeschränkt, um nur die Aufträge durchzuführen, die im angegebenen Gebiet oder in dessen Nähe liegen. Einige Beispiele für Fälle, in denen Routenzonen sinnvoll sein können:
Das Routenzonen-Feature-Set weist eine zugeordnete Attributtabelle auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. RouteName: Der Name der Route, für die diese Zone gilt. Einer Routenzone kann maximal eine Route zugeordnet sein. Dieses Feld darf keine Nullwerte enthalten, und es fungiert als Fremdschlüssel für das Feld "Name" im Routen-Feature-Layer. IsHardZone: Ein boolescher Wert, der eine harte oder weiche Routenzone angibt. Der Wert "True" gibt an, dass es sich um eine harte Routenzone handelt. Dies bedeutet, dass ein Auftrag, der sich außerhalb des Routenzonenpolygons befindet, der Route nicht zugewiesen werden kann. Der Standardwert ist True (1). Der Wert "False"(0) gibt an, dass Aufträge außerhalb des Routenzonenpolygons dennoch zugewiesen werden können, die Kosten für die Durchführung des Auftrags jedoch mit einer Funktion gewichtet werden, die auf der euklidischen Entfernung von der Routenzone basiert. Im Grunde bedeutet dies, dass die Wahrscheinlichkeit einer Zuweisung des Auftrags zu der Route umso geringer ist, je größer die direkte Entfernung der weichen Zone vom Auftrag ist. | Feature Set |
route_renewals (optional) |
Gibt die Zwischendepots an, über die die Routen führen können, um die Fracht für Auslieferungs- oder Abholungsaufträge zu laden oder zu entladen. Über "Lager (Be-/Entladen)" wird eine Route mit einem Depot verknüpft. Die Beziehung gibt an, dass für die Route das Be- oder Entladen am zugeordneten Depot möglich ist. Lager zum Be-/Entladen können zum Modellieren von Szenarien verwendet werden, in denen ein Fahrzeug am Startdepot eine vollständige Ladung von Lieferungen abholt, die Aufträge durchführt, zum Depot zurückkehrt, um neue Lieferungen zu laden, und weitere Aufträge durchführt. Beispielsweise kann bei der Lieferung von Propangas das Fahrzeug mehrere Lieferungen durchführen, bis der Tank nahezu oder vollständig leer ist, einen Stützpunkt zum Nachfüllen aufsuchen und dann weitere Lieferungen durchführen. Beim Arbeiten mit Routenschwerpunkten sind folgende Regeln und Optionen zu beachten:
Der Lager (Be-/Entladen)-Record-Set weist verknüpfte Attribute auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. DepotName: Der Name des Depots, bei dem das Be-/Entladen erfolgt. Dieses Feld darf keinen Nullwert enthalten, und es fungiert als Fremdschlüssel für das Feld "Name" im Depots-Feature-Layer. RouteName: Der Name der Route, auf die dieses Lager zum Be-/Entladen angewendet wird. Dieses Feld darf keinen Nullwert enthalten, und es fungiert als Fremdschlüssel für das Feld "Name" im Routen-Feature-Layer. ServiceTime: Die Durchführungszeit für das Be-/Entladen. Dieses Feld kann einen Nullwert enthalten. Ein Nullwert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch die Eigenschaft "Uhrzeitfeldeinheiten" des Analyse-Layers angegeben. ![]() Die Zeit zum Beladen eines Fahrzeugs an einem Depot zum Be-/Entladen kann von der Größe des Fahrzeugs und seinem Beladungszustand abhängen. Die Durchführungszeit für das Be-/Entladen an einem Lager ist ein fester Wert, bei dem das tatsächliche Beladen nicht berücksichtigt wird. Für die Durchführungszeit zum Be-/Entladen sollte daher ein Wert festgelegt werden, der einer vollständigen LKW-Ladung oder einer durchschnittlichen LKW-Ladung entspricht, oder Sie können einen eigenen Schätzwert für die Zeit festlegen. | Record Set |
order_pairs (optional) |
Kombiniert Abholungs- und Lieferaufträge, sodass sie über dieselbe Route abgearbeitet werden. Zuweilen müssen Abholung und Lieferung für Aufträge paarweise zusammengefasst werden. Beispiel: Eine Kurierfirma benötigt eine Route, auf der ein wichtiges Paket abgeholt und ohne Rückkehr zum Depot oder zur Sortierstation geliefert wird, um die Lieferzeit zu minimieren. Diese zusammengehörigen Aufträge können durch die Verwendung von Auftragspaaren mit der entsprechenden Sequenz derselben Route zugewiesen werden. Es können ferner Einschränkungen für die Dauer zugewiesen werden, für die ein Paket im Fahrzeug bleiben darf. Beispiel: Eine Blutprobe muss innerhalb von zwei Stunden von der Arztpraxis in das Labor gebracht werden. Der Auftragspaare-Record-Set weist verknüpfte Attribute auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. FirstOrderName: Der Name des ersten Auftrags des Paares. Dieses Feld dient als Fremdschlüssel für das Feld "Name" im Aufträge-Feature-Layer. SecondOrderName: Der Name des zweiten Auftrags des Paares. Dieses Feld dient als Fremdschlüssel für das Feld "Name" im Aufträge-Feature-Layer. Der erste Auftrag des Paares muss ein Abholungsauftrag sein, d. h. der Wert für das zugehörige Feld "DeliveryQuantities" ist Null. Der zweite Auftrag des Paares muss ein Lieferauftrag sein, d. h. der Wert für das zugehörige Feld "PickupQuantities" ist Null. Die Menge, die mit dem ersten Auftrag abgeholt wird, muss mit der Menge übereinstimmen, die mit dem zweiten Auftrag geliefert wird. Als Sonderfall können in Szenarien, in denen keine Kapazitäten verwendet werden, beide Aufträge die Menge 0 aufweisen. ![]() Die Auftragsmengen werden nicht an Depots geladen oder entladen. MaxTransitTime: Die maximale Fahrzeit für das Auftragspaar. Die Fahrzeit ist die Dauer von der Abfahrtszeit des ersten Auftrags bis zur Ankunftszeit des zweiten Auftrags. Diese Einschränkung begrenzt die tatsächlich mit Fahren verbrachte Zeit zwischen den beiden Aufträgen. Wenn ein Fahrzeug Menschen oder verderbliche Waren transportiert, ist die Fahrzeit i. d. R. kürzer als bei einem Fahrzeug, das Pakete oder nicht verderbliche Waren transportiert. Dieses Feld kann Nullwerte enthalten. Ein Nullwert gibt an, dass für die Fahrzeit keine Einschränkung gilt. Die Einheit für diesen Feldwert wird durch die Eigenschaft "Uhrzeitfeldeinheiten" des Analyse-Layers angegeben. Vom Solver können Fahrzeitüberschreitungen (in Bezug auf die direkte Fahrzeit zwischen Auftragspaaren gemessen) verfolgt und gewichtet werden. Daher können Sie für den VRP-Solver eine von drei Strategien festlegen: (1) Minimieren der Gesamt-Fahrzeitüberschreitung, unabhängig von der Erhöhung der Reisekosten für die Fahrzeugflotte, (2) Suchen einer Lösung, die einen Kompromiss zwischen Gesamtzeitverstoß und Reisekosten ermöglicht, und (3) Ignorieren der Gesamt-Fahrzeitüberschreitung und stattdessen Minimieren der Reisekosten für die Fahrzeugflotte. Wenn Sie für den Parameter Excess Transit Time Importance (excess_transit_factor für Python) eine Gewichtung zuweisen, wählen Sie eine dieser drei Strategien aus. Unabhängig von der Gewichtung gibt der Solver jedoch in jedem Fall einen Fehler zurück, wenn der Wert für "MaxTransitTime" überschritten wird. | Record Set |
excess_transit_factor (optional) |
Bewertet, wie wichtig die Reduzierung von Fahrzeitüberschreitungen von Auftragspaaren ist. Die Fahrzeitüberschreitung entspricht der Zeit, um die die direkte Fahrzeit zwischen den Auftragspaaren überschritten wird. Eine Überschreitung kann durch Fahrerpausen oder Fahrten zu Zwischenaufträgen und Depots verursacht werden. Unten sind die drei Werte aufgelistet, die zur Wahl stehen.
| String |
point_barriers (optional) |
Gibt Punkt-Barrieren an, die in zwei Typen aufgeteilt sind: Einschränkungsbarrieren und Punkt-Barrieren für Zusatzkosten. Sie schränken vorübergehend das Passieren ein, oder fügen Impedanz zu Punkten im Netzwerk hinzu. Die Punkt-Barrieren werden durch ein Feature-Set definiert. Die Attributwerte, die Sie für die Punkt-Features angeben, bestimmen, ob es sich um Einschränkungsbarrieren oder Barrieren für Zusatzkosten handelt. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. Name: Der Name der Barriere. BarrierType: Gibt an, ob die Barriere die Fahrt völlig beschränkt oder Kosten für das Passieren der Barriere hinzufügt. Es gibt zwei Optionen:
Additional_Time: Wenn "BarrierType" auf "Zusatzkosten" eingestellt ist, gibt der Wert im Feld "Additional_Time" an, wie viel Zeit zu einer Route hinzugefügt wird, wenn die Route die Barriere passiert. Die Einheit für diesen Feldwert wird durch die Eigenschaft "Uhrzeitfeldeinheiten" des Analyse-Layers angegeben. Additional_Distance: Wenn "BarrierType" auf "Zusatzkosten" eingestellt ist, gibt der Wert im Feld "Additional_Distance" an, wie viel Impedanz zu einer Route hinzugefügt wird, wenn die Route die Barriere passiert. Die Einheit für diesen Feldwert wird durch den Parameter Entfernungsfeldeinheiten angegeben. | Feature Set |
line_barriers (optional) |
Gibt Linien-Barrieren an, die das Passieren vorübergehend einschränken. Die Linien-Barrieren werden durch ein Feature-Set definiert. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. Name: Der Name der Barriere. | Feature Set |
polygon_barriers (optional) | Gibt Polygon-Barrieren an, die in zwei Typen aufgeteilt sind: Einschränkungsbarrieren und Kostenfaktor-Polygon-Barrieren. Sie schränken vorübergehend das Passieren ein, oder skalieren die Impedanz der entsprechenden Teile des Netzwerks. Die Polygon-Barrieren werden durch ein Feature-Set definiert. Die Attributwerte, die Sie für die Polygon-Features angeben, bestimmen, ob es sich um Einschränkungsbarrieren oder Kostenfaktor-Barrieren handelt. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. Shape: Das Geometriefeld, das die geographische Position des Netzwerkanalyse-Objekts angibt. Name: Der Name der Barriere. BarrierType: Gibt an, ob die Barriere Reise völlig beschränkt oder die Kosten für das Passieren der Barriere skaliert. Es gibt zwei Optionen:
Scaled_Time: Die zeitbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem Wertesatz in diesem Feld multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine Kostenfaktorbarriere ist. Scaled_Distance: Die entfernungsbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem Wertesatz in diesem Feld multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine Kostenfaktorbarriere ist. | Feature Set |
time_attribute (optional) |
Definiert das Netzwerkkostenattribut, mit dem die Fahrzeit der Netzwerkelemente festgelegt wird. | String |
distance_attribute (optional) |
Definiert das Netzwerkkostenattribut, mit dem die Entfernung der Netzwerkelemente festgelegt wird. | String |
use_hierarchy_in_analysis (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. In solchen Fällen verwenden Sie "#" als Parameterwert. | Boolean |
restrictions (optional) |
Gibt an, welche Netzwerk-Restriktionsattribute bei der Berechnung beachtet werden. | String |
attribute_parameter_values (optional) |
Gibt die Parameterwerte für Netzwerkattribute mit Parametern an. Das Record Set weist zwei Spalten auf, die gemeinsam eindeutig Parameter identifizieren, und eine weitere Spalte, die den Parameterwert angibt. Das Attributparameterwerte-Record Set weist verknüpfte Attribute auf. Die Felder in der Attributtabelle sind unten aufgelistet und beschrieben. ObjectID: Das vom System verwaltete ID-Feld. AttributeName: Der Name des Netzwerkattributs, dessen Attributparameter von der Tabellenzeile festgelegt wird. ParameterName: Der Name des Attributparameters, dessen Wert von der Tabellenzeile festgelegt wird. (Objekttypparameter könne mit diesem Werkzeug nicht aktualisiert werden.) ParameterValue: Der Wert, der für den Attributparameter festgelegt werden soll. Wenn kein Wert angegeben ist, wird der Attributparameter auf Null festgelegt. | Record Set |
maximum_snap_tolerance (optional) |
Die maximale Fangtoleranz ist die weiteste Entfernung, in der Network Analyst bei der Positionierung oder Neupositionierung eines Punktes im Netzwerk sucht. Es wird nach geeigneten Kanten oder Knoten gesucht. Der Punkt wird an der nächsten Kante oder am nächsten Knoten gefangen. Wenn keine geeignete Position innerhalb der maximalen Fangtoleranz gefunden wird, wird das Objekt als verortet markiert. | Linear unit |
exclude_restricted_portions_of_the_network (optional) |
| Boolean |
feature_locator_where_clause [[dataset_name, SQL_Query],...] (optional) |
Ein SQL-Ausdruck zur Auswahl einer Teilmenge von Quell-Features, der eingrenzt, auf welchen Netzwerkelementen Aufträge und Depots positioniert werden können. Beispiel: Um sicherzustellen, dass Aufträge und Depots nicht auf eingeschränkt befahrbaren Straßen positioniert werden, erstellen Sie einen SQL-Ausdruck, der diese Quell-Features ausschließt. (Andere Netzwerkanalyse-Objekte, wie Barrieren, ignorieren die WHERE-Klausel des Feature Locator beim Laden.) Weitere Informationen zur SQL-Syntax und zu den Unterschieden zwischen Datenquellen finden Sie unter SQL-Referenz für in ArcGIS verwendete Abfrageausdrücke. | Value Table |
populate_route_lines (optional) |
| Boolean |
route_line_simplification_tolerance (optional) |
Geben Sie an, wie stark Sie die Routengeometrie vereinfachen möchten. Bei der Vereinfachung werden kritische Punkte auf einer Route beibehalten, wie Übergänge an Kreuzungen, um das wesentliche Shape der Route zu definieren, und andere Punkte entfernt. Die angegebene Vereinfachungsentfernung stellt den maximal zulässigen Versatz dar, den die vereinfachte Linie von der ursprünglichen Linie abweichen kann. Durch die Vereinfachung einer Linie wird die Anzahl von Stützpunkten reduziert. Häufig werden auch die Zeichenzeiten reduziert. | Linear unit |
populate_directions (optional) |
| Boolean |
directions_language (optional) |
Wählen Sie eine Sprache, in der Wegbeschreibungen erstellt werden. Die in der Dropdown-Liste verfügbaren Sprachen hängen davon ab, welche ArcGIS-Sprachpakete auf Ihrem Computer installiert sind. Beachten Sie, dass beim Veröffentlichen dieses Werkzeugs als Teil eines Service auf einem separaten Server das ArcGIS-Sprachpaket für die ausgewählte Sprache auf dem Server installiert sein muss, damit das Werkzeug ordnungsgemäß funktioniert. Wenn ein Sprachpaket nicht auf Ihrem Computer installiert ist, wird die Sprache nicht in der Dropdown-Liste angezeigt. Sie können jedoch stattdessen einen Sprachcode eingeben. | String |
directions_style_name (optional) |
Der Name des Formatierungs-Style von Beschreibungen. | String |
save_output_layer (optional) |
Es werden in jedem Fall eigenständige Tabellen und Feature-Classes zurückgegeben. Ein Serveradministrator möchte jedoch evtl. auch einen Netzwerkanalyse-Layer ausgeben, um einen Debugging-Vorgang für die Einrichtung und Ergebnisse des Werkzeugs mit den Network Analyst-Steuerelementen in der ArcGIS for Desktop-Umgebung durchzuführen. Dies kann den Debugging-Prozess deutlich vereinfachen. In ArcGIS for Desktop ist der Standardausgabeort für den Netzwerkanalyse-Layer der Scratch-Workspace, auf derselben Ebene wie die Scratch-Geodatabase. Das heißt, er wird als gleichgeordnetes Element der Scratch-Geodatabase gespeichert. Der Ausgabe-Netzwerkanalyse-Layer wird als LYR-Datei gespeichert, deren Name mit _ags_gpna beginnt, gefolgt von einer alphanumerischen GUID. | Boolean |
service_capabilities [[String, {Long}],...] (optional) |
Diese Eigenschaft bestimmt die maximale Datenverarbeitung bei der Ausführung dieses Werkzeugs als Geoverarbeitungs-Service. Sie legen dies aus einem der folgenden zwei Gründe fest: Erstens um zu verhindern, dass Ihr Server Probleme behebt, die mehr Ressourcen oder Verarbeitungszeit erfordern als Sie bereitstellen möchten, oder zweitens um zur Unterstützung eines Geschäftsmodells mehrere Services mit unterschiedlichen VRP-Funktionen zu erstellen. Beispiel: Wenn Sie ein mehrstufiges Service-Geschäftsmodell nutzen, möchten Sie evtl. einen kostenlosen VRP-Service bereitstellen, der maximal fünf Routen pro Berechnung unterstützt, und einen anderen gebührenpflichtigen Service, der mehr als fünf Routen pro Berechnung unterstützt. Bei der Eingrenzung der maximalen Anzahl der Routen können Sie eingrenzen, wie viele Aufträge oder Punkt-Barrieren zur Analyse hinzugefügt werden können. Eine andere Möglichkeit, Problemgrößen zu verwalten, ist die Festlegung einer maximalen Anzahl von Features (in der Regel Straßen-Features), die Linien- oder Polygon-Barrieren schneiden können. Die letzte Methode ist, eine hierarchische Berechnung zu erzwingen, selbst wenn der Benutzer keine Hierarchie verwenden möchte, wenn Aufträge geographisch über eine angegebene geradlinige Entfernung hinaus verteilt sind.
| Value Table |
ignore_invalid_order_locations (optional) |
| Boolean |
Codebeispiel
Ausführen des Werkzeugs, wenn nur die erforderlichen Parameter verwendet werden.
import arcpy
orders = arcpy.FeatureSet()
orders.load("Stores")
depots = arcpy.FeatureSet()
depots.load("DistributionCenter")
routes = arcpy.RecordSet()
routes.load("RoutesTable")
arcpy.na.SolveVehicleRoutingProblem(orders, depots, routes, "","Minutes",
"Miles", "Streets_ND")
Im folgenden eigenständigen Python-Skript wird veranschaulicht, wie das Werkzeug "SolveVehicleRoutingProblem" zum Bereitstellen mehrerer Aufträge für eine Fahrzeugflotte verwendet werden kann. Bei Verwendung des Werkzeugs "SolveVehicleRoutingProblem" müssen Sie nur ein einziges Werkzeug aufrufen, um das gesamte Analyseproblem zu berechnen. Für das Werkzeug "MakeVehicleRoutingProblemLayer" sind mehrere Werkzeuge aus der ArcGIS Network Analyst Tools-Toolbox erforderlich.
# Name: SolveVehicleRoutingProblem_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
import datetime
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"
impedanceAttribute = "TravelTime"
timeUnits = "Minutes"
distanceUnits = "Miles"
inOrders = "Analysis/Stores"
inDepots = "Analysis/DistributionCenter"
inRoutes = "RoutesTable"
outGeodatabase = "C:\data\output\VRPOutputs.gdb"
#Create two new feature sets and one record set with same schema as
#Orders, Deopts and Routes parameter in Solve Vehicle Routing Problem tool.
#Load the feature from the existing feature classes and table in the feature
#set. Note that Solve Vehicle Routing Problem tool does not provide a way to
#map field names between your input feature classes and table and the
#feature set or record set parameters. To ensure that the attributes are
#correctly transfered, the input feature classes and table must have same
#field names as the feature sets and record sets.
orders = arcpy.GetParameterValue("SolveVehicleRoutingProblem_na",0)
orders.load(inOrders)
depots = arcpy.GetParameterValue("SolveVehicleRoutingProblem_na",1)
depots.load(inDepots)
routes = arcpy.GetParameterValue("SolveVehicleRoutingProblem_na",2)
routes.load(inRoutes)
#Call the SolveVRP tool and store the results in the result object
result = arcpy.na.SolveVehicleRoutingProblem(orders,depots, routes,"",
timeUnits, distanceUnits,
inNetworkDataset, outGeodatabase,
populate_directions="DIRECTIONS")
#print the solve status and output any warning messages from tool execution
solveSucceeded = result.getOutput(0)
print "Solve Succeeded: {0}".format(solveSucceeded)
print "Messages from solver are printed below."
print result.getMessages(1)
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)