Vehicle Routing Problem berechnen (Network Analyst)—ArcGIS Pro

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 VRP-Analyse-Layer findet die besten Routen für eine Fahrzeugflotte.

Weitere Informationen zur Ausgabe von "Vehicle Routing Problem berechnen"

Vorversion:

Dies ist ein veraltetes Werkzeug. Diese Funktion wurde durch das Werkzeug Analyse-Layer für Vehicle Routing Problem erstellen und die Schaltfläche Vehicle Routing Problem im Dropdown-Menü Netzwerkanalyse auf dem Menüband Analyse ersetzt.

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
- Benutzerdefinierter Reisemodus
- Netzwerkstandorte
- Ausgabe
- Service-Eigenschaften

Parameter

Beschriftung	Erläuterung	Datentyp
Aufträge	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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. Hinweis: Ein Zeitfenster gibt nur an, wann ein Fahrzeug bei einer Lieferung ankommen kann. Es gibt nicht an, wann die Durchführungszeit abgeschlossen sein muss. Wenn die Durchführungszeit und die Abfahrt des Fahrzeugs vor dem Ende des Zeitfensters berücksichtigt werden sollen, subtrahieren Sie den Feldwert für ServiceTime vom Feldwert für TimeWindowEnd1. Die Zeitfensterfelder dürfen einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Dabei darf es sich nicht um ganze Zahlen handeln, die Millisekunden seit Unixzeit darstellen. Die Zeitzone für Zeitfensterfelder wird mit dem Parameter time_zone_usage_for_time_fields angegeben. Wenn ein Zeitfeld, z. B. TimeWindowStart1, einen reinen Uhrzeitwert enthält (z. B. 8:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft "Standarddatum" des Analyse-Layers angegebene Datum verwendet wird. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2010 8:00 Uhr), können Sie Zeitfenster über mehrere Tage festlegen. 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. Wenn Sie Verkehrsdaten verwenden, beziehen sich die Felder für Uhrzeit und Datum des Netzwerkstandorts immer auf die gleiche Zeitzone wie die Kante, auf der sich der Netzwerkstandort befindet. TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert 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 NULL-Wert 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 nach dem Ende des Zeitfensters liegt. 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 NULL-Wert bedeutet jedoch auch, 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Zeitfensterverletzungen können vom Solver verfolgt und gewichtet werden. Daher können Sie für den VRP-Solver eine von drei Strategien festlegen: Minimieren des Gesamtzeitverstoßes, unabhängig von der Erhöhung der Reisekosten für die Fahrzeugflotte Suchen einer Lösung, die einen Kompromiss zwischen Gesamtzeitverstoß und Reisekosten ermöglicht Ignorieren des Gesamtzeitverstoßes und stattdessen Minimieren der Reisekosten für die Fahrzeugflotte Wenn Sie dem Parameter Gewichtung der Zeitfensterverletzung (time_window_factor in Python) eine Gewichtung zuweisen, entscheiden Sie sich letztendlich für eine dieser drei Strategien. Der Solver gibt 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. InboundArriveTime: Legt fest, wann der am Ort des Auftrags abzuliefernde Gegenstand am Startdepot bereit ist. Der Auftrag kann einer Route nur dann zugewiesen werden, wenn die eingehende Ankunftszeit dem letzten Startzeitwert der Route vorausgeht. Auf diese Weise kann die Route das Depot nicht verlassen, bevor der Liefergegenstand bereit ist, in das Depot geladen zu werden. Mit diesem Feld können Szenarien mit Umladungen eingehender Lieferungen modelliert werden. Beispiel: Für einen Auftrag sind spezielle Materialien erforderlich, die derzeit nicht im Depot verfügbar sind. Die Materialien werden von einem anderen Standort versendet und erreichen das Depot um 11:00 Uhr. Um sicherzustellen, dass ein Fahrzeug, das auf einer Route den Ort vor dem Eintreffen der Lieferung verlässt, dem Auftrag nicht zugewiesen wird, wird die eingehende Ankunftszeit des Auftrags auf 11:00 Uhr festgelegt. Die speziellen Materialien treffen um 11:00 Uhr ein, werden auf das Fahrzeug geladen und das Fahrzeug verlässt das Depot, um die ihm zugewiesenen Orte des Auftrags anzufahren. Hinweis: Die Startzeit der Route, die Durchführungszeiten umfasst, muss auf die eingehende Ankunftszeit folgen. Wenn eine Route vor der eingehenden Ankunftszeit eines Auftrags beginnt, kann der Auftrag der Route nicht zugewiesen werden. Die Zuweisung ist auch dann ungültig, wenn die Route eine Start-Depot-Durchführungszeit aufweist, die bis über die eingehende Ankunftszeit hinaus andauert. Dieses Zeitfeld kann einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein reiner Uhrzeitwert festgelegt wurde (z. B. 11:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Das Standarddatum wird jedoch ignoriert, wenn ein Zeitfeld in Depots, Routen, Aufträgen oder Unterbrechungen ein Datum mit Uhrzeit enthält. Geben Sie in diesem Fall all diese Felder mit Datum und Uhrzeit ein (z. B. 11.07.2015 11:00 Uhr). Der VRP-Solver berücksichtigt InboundArriveTime unabhängig vom DeliveryQuantities-Wert. Wenn außerdem eine ausgehende Abfahrtzeit angegeben ist, muss deren Zeitwert nach der eingehenden Ankunftszeit liegen. Der VRP Solver ist nicht für die Lösung von Problemen ausgelegt, die länger als ein Jahr andauern. Daher müssen alle Durchführungszeiten und Zeitfenster weniger als ein Jahr betragen. OutboundDepartTime: Legt fest, wann der am Ort des Auftrags abzuholende Liefergegenstand das End-Depot erreichen muss. Der Auftrag kann einer Route nur dann zugewiesen werden, wenn die Route den Ort des Auftrags anfahren kann und dessen End-Depot vor der angegebenen ausgehenden Abfahrtzeit erreicht. Mit diesem Feld können Szenarien mit Umladungen ausgehender Lieferungen modelliert werden. Beispiel: Eine Transportfirma schickt Lieferwagen los, um Pakete von Aufträgen abzuholen und sie zu einem Depot zu bringen. Von dort aus werden sie auf dem Weg zu ihrem Endziel zu anderen Einrichtungen weitertransportiert. Täglich um 15:00 Uhr stoppt ein Sattelschlepper am Depot, um die Pakete mit hoher Priorität abzuholen und sie direkt zu einer zentralen Verarbeitungsstation zu bringen. Um eine Verzögerung der Pakete mit hoher Priorität bis zur 15:00 Uhr-Fahrt des folgenden Tages zu vermeiden, lässt die Transportfirma die Pakete mit hoher Priorität an den Auftragsorten von Lieferwagen abholen und vor Ablauf der 15:00 Uhr-Frist zum Depot bringen. Dazu wird die Abfahrtszeit auf 15:00 Uhr festgelegt. Hinweis: Die Endzeit der Route, einschließlich der Durchführungszeiten, muss vor der ausgehenden Abfahrtzeit liegen Wenn eine Route ein Depot erreicht, die Durchführungszeit des End-Depots jedoch nicht vor der ausgehenden Abfahrtzeit des Auftrags abgeschlossen ist, kann der Auftrag der Route nicht zugewiesen werden. Dieses Zeitfeld kann einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein reiner Uhrzeitwert festgelegt wurde (z. B. 11:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Das Standarddatum wird jedoch ignoriert, wenn ein Zeitfeld in Depots, Routen, Aufträgen oder Unterbrechungen ein Datum mit Uhrzeit enthält. Geben Sie in diesem Fall all diese Felder mit Datum und Uhrzeit ein (z. B. 11.07.2015 11:00 Uhr). Der VRP-Solver berücksichtigt OutboundDepartTime unabhängig vom PickupQuantities-Wert. Wenn außerdem eine Ankunftszeit angegeben ist, muss deren Zeitwert vor der Abfahrtszeit liegen. 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 Maße angeben, 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 Abfolge die Werte und ihre entsprechenden Einheiten eingegeben werden. Stellen Sie sicher, dass Capacities für Routen und DeliveryQuantities und 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 unterschiedliche Einheiten verwendet werden oder die Reihenfolge geändert wird, erhalten Sie unerwünschte Ergebnisse, ohne dass eine Warnmeldung ausgegeben wird. Eine leere Zeichenfolge oder ein NULL-Wert 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. Hinweis: 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 NULL-Wert (ein NULL-Wert 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" in seiner Ausgabe nie die Einnahmen enthält. Jedoch werden für die Einnahmen 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 NULL-Wert gibt an, dass der Auftrag keine Besonderheiten erfordert. Die Schreibweisen der in den Anforderungs- und Routenklassen aufgeführten gesonderten Elemente müssen genau übereinstimmen, sodass sie vom VRP Solver zusammengeführt werden können. Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Grünanlagen pflegt und Baumschnittarbeiten durchführt, für einige Aufträge ein Fahrzeug mit einem Hubsteiger benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge Hubsteiger in das Feld SpecialtyNames ein, um auf diese besondere Anforderung hinzuweisen. SpecialtyNames bleibt NULL für die anderen Aufträge. Entsprechend gibt die Firma Hubsteiger 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 Hubsteiger 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). Ausschließen (0): Der Auftrag wird aus dem nachfolgenden Berechnungsvorgang ausgeschlossen. Route und relative Sequenz beibehalten (1): Der Solver muss den Auftrag während des Berechnungsvorgangs immer der vorab zugewiesenen Route mit der vorab zugewiesenen relativen Sequenz zuweisen. Wenn diese Zuweisungsregel nicht befolgt werden kann, führt dies zu einem Verstoß gegen den Auftrag. Mit dieser Einstellung wird nur die relative Sequenz, nicht die absolute Sequenz, verwaltet. Um dies näher zu veranschaulichen, stellen Sie sich vor, es gibt zwei Aufträge: A und B. Sie weisen die Sequenzwerte 2 bzw. 3 auf. Wenn Sie die Werte des Feldes AssignmentRule auf "Route und relative Sequenz beibehalten" festlegen, können sich die tatsächlichen Sequenzwerte von A und B nach der Berechnung ändern, da andere Aufträge, Pausenzeiten und Depotstopps immer vor, zwischen oder nach A und B angeordnet werden können. B kann jedoch nicht vor A angeordnet werden. Route beibehalten (2): Der Solver muss den Auftrag während des Berechnungsvorgangs immer der vorab zugewiesenen Route zuweisen. Außerdem muss eine gültige Sequenz festgelegt sein, auch wenn diese nicht unbedingt beibehalten werden muss. Wenn der Auftrag nicht der angegebenen Route zugewiesen werden kann, führt dies zu einem Verstoß gegen den Auftrag. Überschreiben (3): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist eine Route und Sequenz für den Auftrag zu, um den Gesamtwert der Zielfunktion zu verringern. Dies ist der Standardwert. Erstes Element verankern (4): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist dem Auftrag eine Route zu und legt ihn als ersten Auftrag auf dieser Route fest, um den Gesamtwert der Zielfunktion zu verringern. Letztes Element verankern (5): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist dem Auftrag eine Route zu und legt ihn als letzten Auftrag auf dieser Route fest, um den Gesamtwert der Zielfunktion zu verringern. Dieses Feld darf keinen NULL-Wert enthalten. CurbApproach: Die Eigenschaft CurbApproach gibt die Richtung an, in der ein Fahrzeug bei der Einrichtung ankommt bzw. von ihr wegfährt. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar: Beide Seiten des Fahrzeugs (0): Das Fahrzeug kann sich von beiden Richtungen dem Netzwerkstandort nähern und von ihm abfahren. Wenden ist erlaubt. Sie sollten diese Einstellung auswählen, wenn das Fahrzeug an dem Stopp wenden kann bzw. wenn es in eine Auffahrt oder einen Parkplatz einfahren und dort wenden kann. Rechte Seite des Fahrzeugs (1): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der rechten Seite des Fahrzeugs befinden. Wenden ist verboten. Linke Seite des Fahrzeugs (2): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der linken Seite des Fahrzeugs befinden. Wenden ist verboten. Wendeverbot (3): Wenn sich das Fahrzeug dem Netzwerkstandort nähert, kann sich die Bordkante auf jeder Seite des Fahrzeuges befinden; das Fahrzeug muss jedoch abfahren, ohne zu wenden. 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 NULL-Wert 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 NULL-Wert enthalten, um anzugeben, dass der Auftrag an einer beliebigen Position auf der Route eingefügt werden kann. Ein NULL-Wert ist nur gemeinsam mit einem NULL-Wert für RouteName zulässig. Die Eingabesequenzwerte sind nicht negativ und für jede Route eindeutig (gültig für Depotstopps, Aufträge und Pausenzeiten), müssen jedoch nicht bei 0 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 Artikel entladen oder eingeladen werden, 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 den Namen, den Sie hier angeben. Er wird ebenfalls vom Record-Set "Lager (Be-/Entladen)" referenziert, wenn dieses verwendet wird. Bei Depotnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Das Feld darf nicht leer sein und muss einen eindeutigen Namen enthalten. TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. Hinweis: Die Zeitfensterfelder können einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein Zeitfeld einen reinen Uhrzeitwert enthält (z. B. 8:00 Uhr), wird vorausgesetzt, dass als Datum das vom Parameter Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2010 8:00 Uhr), können Sie Zeitfenster über mehrere Tage festlegen. 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. Wenn Sie Verkehrsdaten verwenden, beziehen sich die Felder für Uhrzeit und Datum des Netzwerkstandorts immer auf die gleiche Zeitzone wie die Kante, auf der sich der Netzwerkstandort befindet. TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert 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 NULL-Wert 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 bei der Einrichtung ankommt bzw. von ihr wegfährt. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar: Beide Seiten des Fahrzeugs (0): Das Fahrzeug kann sich von beiden Richtungen dem Netzwerkstandort nähern und von ihm abfahren. Wenden ist erlaubt. Sie sollten diese Einstellung auswählen, wenn das Fahrzeug an dem Stopp wenden kann bzw. wenn es in eine Auffahrt oder einen Parkplatz einfahren und dort wenden kann. Rechte Seite des Fahrzeugs (1): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der rechten Seite des Fahrzeugs befinden. Wenden ist verboten. Linke Seite des Fahrzeugs (2): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der linken Seite des Fahrzeugs befinden. Wenden ist verboten. Wendeverbot (3): Wenn sich das Fahrzeug dem Netzwerkstandort nähert, kann sich die Bordkante auf jeder Seite des Fahrzeuges befinden; das Fahrzeug muss jedoch abfahren, ohne zu wenden. Bearing: 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 Bearing auf einer Kante bewegt werden. Wenn sich der Wert des Feldes Bearing 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 Einheiten in Grad, und der Standardwert ist 30. Der Wert muss größer als 0 und kleiner als 180 sein. 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 enthalten. Die Eingabe eines NavLatency-Wertes ist jedoch optional, selbst wenn in Bearing und BearingTol Werte enthalten 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 Zeitattribut angegeben wird.	Feature Set
Routen	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 zum 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 nicht zwischen Groß-/Kleinschreibung unterschieden. StartDepotName: Der Name des Startdepots für die Route. Dieses Feld dient als Fremdschlüssel für das Feld Name in 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, kann EndDepotName nicht ebenfalls NULL sein. Virtuelle Startdepots sind nicht zulässig, wenn Aufträge oder Depots in mehreren Zeitzonen vorliegen. 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 ist ein Fremdschlüssel für das Feld Name im Parameter Depots. StartDepotServiceTime: Die Durchführungszeit am Startdepot. Mit dieser kann die Zeit zum Beladen des Fahrzeugs modelliert werden. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Hinweis: 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 NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Hinweis: 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 der standardmäßige Uhrzeitwert ist 8:00 Uhr. Der Standardwert wird als 8:00 Uhr an dem vom Parameter Standarddatum (default_date in Python) angegebenen Datum interpretiert. 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 der standardmäßige Uhrzeitwert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Capacities: Die maximale Kapazität des Fahrzeugs. Sie können die Kapazität in einer beliebigen Dimension 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 Maße angeben, 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, sollte Capacities wie folgt angegeben werden: 18 56. Sie müssen sich wieder die Einheiten merken. Sie müssen sich ferner merken, in welcher Reihenfolge die Werte und ihre entsprechenden Einheiten eingegeben werden (in diesem Fall Tonnen gefolgt von Kubikmetern). Die Einheiten und deren Reihenfolge sind aus mehreren Gründen wichtig: Erstens können Sie so die Informationen auch später richtig deuten, und zweitens können Sie angemessene Werte für die Felder DeliveryQuantities und PickupQuantities unter Aufträge 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 unterschiedliche Einheiten verwendet werden oder die Reihenfolge in einem der drei Felder geändert wird, erhalten Sie unerwünschte Ergebnisse, ohne dass eine Warnmeldung ausgegeben wird. 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 NULL-Wert 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 zum Feld DeliveryQuantities oder PickupQuantities unter "Aufträge" nicht ausreichend ist, werden die restlichen Werte als 0 behandelt. Vorsicht: 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 NULL-Werte enthalten. Ein NULL-Wert 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 NULL-Wert enthalten und der Standardwert ist 1,0. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. CostPerUnitDistance: Der – pro Einheit gefahrener Strecke – für die Routenlänge (gesamte Reisestrecke) anfallende Geldbetrag. Dieses Feld kann NULL-Werte enthalten. Ein NULL-Wert 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 NULL-Werte enthalten. Ein NULL-Wert gibt an, dass keine Überstunden angewendet werden. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Wenn beispielsweise dem Fahrer bei Überschreitung einer Gesamtroutendauer von 8 Stunden Überstunden bezahlt werden müssen, wird OvertimeStartTime als 480 (8 Stunden * 60 Minuten/Stunde) angegeben, vorausgesetzt, für den Parameter Uhrzeitfeldeinheiten wurde Minutes festgelegt. CostPerUnitOvertime: Der pro Zeiteinheit von Überstunden anfallende Geldbetrag. Dieser kann nur dann einen NULL-Wert enthalten, wenn OvertimeStartTime auch Null ist. Andernfalls muss es ein positiver Wert sein, der größer ist als der Wert für CostPerUnitTime. MaxOrderCount: Die maximal zulässige Anzahl von Aufträgen für die Route. Dieses Feld darf keine NULL-Werte enthalten und der Standardwert beträgt 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 NULL-Werte enthalten. Ein NULL-Wert gibt an, dass für die Routendauer keine Einschränkung gilt. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte enthalten. Ein NULL-Wert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte enthalten. Ein NULL-Wert 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 ist ein Fremdschlüssel für das Feld SpecialtyNames im Parameter Aufträge. Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Grünanlagen pflegt und Baumschnittarbeiten durchführt, für einige Aufträge ein Fahrzeug mit einem Hubsteiger benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge Hubsteiger in das Feld SpecialtyNames ein, um auf diese besondere Anforderung hinzuweisen. SpecialtyNames bleibt NULL für die anderen Aufträge. Entsprechend gibt die Firma Hubsteiger 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 Hubsteiger 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: Einschließen: Die Route wird in den Berechnungsvorgang einbezogen. Dies ist der Standardwert. Ausschließen: Die Route wird aus dem Berechnungsvorgang ausgeschlossen.	Record Set
Unterbrechungen	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 darf keine NULL-Werte enthalten, und der Standardwert beträgt 60. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. TimeWindowStart: Die Anfangszeit für das Zeitfenster der Pausenzeit. Halboffene Zeitfenster sind als Pausenzeiten ungültig. Wenn dieses Feld über einen Wert verfügt, müssen die Feldwerte für MaxTravelTimeBetweenBreaks und MaxCumulWorkTime NULL sein. Alle anderen Pausenzeiten in der Analyse müssen NULL-Werte 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 in Pausen dürfen einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Dabei darf es sich nicht um ganze Zahlen handeln, die Millisekunden seit Unixzeit darstellen. Die Zeitzone für Zeitfensterfelder wird mit dem Parameter time_zone_usage_for_time_fields angegeben. Wenn ein Zeitfeld, z. B. TimeWindowStart, einen reinen Uhrzeitwert enthält (z. B. 12:00 Uhr), wird angenommen, dass das Datum dem vom Parameter Standarddatum (default_date in Python) angegebenen Datum entspricht. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2012 12:00 Uhr), können Sie Zeitfenster über mehrere Tage angeben. Dies empfiehlt sich, 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. TimeWindowEnd: Die Endzeit für das Zeitfenster der Pausenzeit. Halboffene Zeitfenster sind als Pausenzeiten ungültig. Wenn dieses Feld über einen Wert verfügt, müssen die Feldwerte für MaxTravelTimeBetweenBreaks und MaxCumulWorkTime NULL sein. Alle anderen Pausenzeiten in der Analyse müssen NULL-Werte 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 Gewichtung der Zeitfensterverletzung (time_window_factor in Python) sanktioniert. Diese Eigenschaft kann NULL sein. Ein NULL-Wert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 für den Analyseparameter Uhrzeitfeldeinheiten (time_units in Python) Minutes festgelegt wurde und MaxTravelTimeBetweenBreaks den Wert 120 aufweist, kann der Fahrer nach zwei Stunden Fahrt eine Pause einlegen. Um eine Pause nach zwei weiteren Stunden Fahrt zuzuweisen, muss als Feldwert für MaxTravelTimeBetweenBreaks der zweiten Pause 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 den 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 (time_units für Python) auf Minuten festgelegt ist, MaxCumulWorkTime den Wert 120 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte 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
Uhrzeitfeld-Einheiten	Gibt die Zeiteinheiten für alle zeitbasierten Feldwerte in der Analyse an. 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 (time_attribute in Python) entsprechen. Sekunden—Sekunden Minuten—Minuten Stunden—Stunden Tage—Tage	String
Entfernungsfeld-Einheiten	Gibt die Entfernungseinheiten für alle entfernungsbasierten Feldwerte in der Analyse an. 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 (distance attribute in Python) entsprechen. Meilen—Meilen Kilometer—Kilometer Fuß—Fuß Yard—Yard Meter—Meter Seemeilen—Seemeilen	String
Netzwerk-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
Ausgabe-Geodatabase-Workspace	Die 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
Name von nicht zugewiesenen Ausgabe-Stopps	Der Name der Ausgabe-Feature-Class, die alle nicht erreichbaren Depots oder nicht zugewiesenen Aufträge enthalten soll.	String
Ausgabename für Stopps	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
Ausgabenname für Routen	Der Name der Feature-Class, die die Routen der Analyse enthalten soll.	String
Ausgabename für Wegbeschreibung	Der Name der Feature-Class, die die Wegbeschreibungen für die Routen enthalten soll.	String
Standarddatum (optional)	Das Standarddatum für Zeitfeldwerte, die einen Zeitpunkt, jedoch kein Datum angeben.	Date
Wendenregel (optional)	Definiert die Wendenregel an, die an Knoten verwendet werden soll. 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. Sie können auch die Einstellung der CurbApproach-Eigenschaft Ihrer Netzwerkstandorte festlegen. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird. Zulässig—Wenden sind an Knoten mit einer beliebigen Anzahl verbundener Kanten erlaubt. Dies ist der Standardwert. Nicht zulässig—Wenden sind an allen Knoten verboten, unabhängig von der Valenz der Knoten. Jedoch sind selbst bei Auswahl dieser Einstellung Wenden an Netzwerkstandorten weiterhin erlaubt, allerdings können Sie für die Eigenschaft CurbApproach des jeweiligen Netzwerkstandorts auch ein Verbot von Wenden festlegen. Nur bei Sackgassen zulässig—Wenden sind an allen Knoten verboten, außer es ist nur eine angrenzende Kante vorhanden (Sackgasse). Nur bei Sackgassen und Kreuzungen zulässig—Wenden sind an Knoten verboten, an denen genau zwei angrenzende Kanten aufeinander treffen, jedoch an Kreuzungen (Knoten mit drei oder mehr angrenzenden Kanten) und in Sackgassen (Knoten mit genau einer angrenzenden Kante) erlaubt. Oftmals verfügen Netzwerke über unwesentliche Knoten in der Mitte von Straßensegmenten. Durch diese Option wird verhindert, dass Fahrzeuge an diesen Punkten wenden.	String
Gewichtung der Zeitfensterverletzung (optional)	Gibt an, wie wichtig die Einhaltung von Zeitfenstern ist. Es gibt drei Optionen, die unten aufgelistet und beschrieben sind. Niedrig—Legt den Schwerpunkt auf die Minimierung der Fahrzeiten, statt auf die rechtzeitige Ankunft. Sie können ggf. diese Einstellung wählen, wenn Sie einen wachsenden Rückstand an Service-Anforderungen bewältigen müssen. Um an einem Tag mehr Aufträge durchführen zu können und den Rückstand abzuarbeiten, können Sie diese Einstellung auswählen, obwohl den Kunden durch die Verspätungen Unannehmlichkeiten entstehen können. Mittel—Legt den Schwerpunkt gleichzeitig auf die Minimierung der Fahrzeiten und die Ankunft in den Zeitfenstern. Dies ist der Standardwert. Hoch—Legt den Schwerpunkt auf eine rechtzeitige Ankunft und weniger auf die Minimierung der Fahrzeiten. Unternehmen mit zeitkritischen Lieferungen oder einem Schwerpunkt auf Kundenservice würden diese Einstellung auswählen.	String
Raumcluster-Routen (optional)	Gibt an, ob räumliches Clustering verwendet werden soll. Aktiviert: Die einer einzelnen Route zugewiesenen Aufträge werden räumlich gruppiert. Durch das Bilden von Auftrags-Clustern befinden sich Routen häufig in kleineren Gebieten. Dadurch schneiden sich die Routenlinien weniger oft, jedoch können sich die Gesamtfahrzeiten erhöhen. Dies ist die Standardeinstellung. Deaktiviert: Der Solver priorisiert das Bilden von räumlichen Auftrags-Clustern nicht, und die Routenlinien können sich schneiden. Verwenden Sie diese Option, wenn Routenzonen angegeben sind.	Boolean
Routenzonen (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. Nachfolgend finden Sie Beispiele für Fälle, in denen sich Routenzonen als sinnvoll erweisen: Einige Ihrer Mitarbeiter verfügen nicht über die erforderlichen Genehmigungen für die Durchführung von Arbeit in bestimmten Bundesländern oder Gemeinden. Sie können eine harte Routenzone erstellen, damit diese Mitarbeiter nur Aufträge in Gebieten erreichen, in denen die Anforderungen erfüllt werden. Bei einem Ihrer Fahrzeuge treten häufig Pannen auf. Daher soll es nur Aufträge an Standorten durchführen, die sich in der Nähe Ihrer Reparaturwerkstatt befinden, um die Reaktionszeit zu minimieren. Sie können eine weiche oder harte Routenzone erstellen, um das Fahrzeug in der Nähe zu behalten. 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
Lager (Be-/Entladen) (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 auf der Route das Be- oder Entladen am verknüpften 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. Wird gleichzeitig mit Routenschwerpunkten gearbeitet, sind folgende Regeln und Optionen zu beachten: Die Stelle zum Nachladen/Entladen bzw. der Standort zum Be-/Entladen muss nicht mit dem Start- oder Enddepot übereinstimmen. Jede Route kann eine oder mehrere vorab festgelegte Standorte zum Be-/Entladen aufweisen. Ein Standort zum Be-/Entladen kann mehrmals auf einer einzelnen Route verwendet werden. In einigen Fällen sind möglicherweise für eine Route mehrere potenzielle Standorte zum Be-/Entladen vorhanden, und vom Solver wird der nächste verfügbare Standort zum Be-/Entladen ausgewählt. 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, 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, 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 NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch die Eigenschaft "Uhrzeitfeldeinheiten" des Analyse-Layers angegeben. Hinweis: 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
Auftragspaare (optional)	Kombiniert Abhol- 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. Durch die Verwendung von Auftragspaaren können diese zusammengehörigen Aufträge in der entsprechenden Reihenfolge 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. Hinweis: 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 NULL-Werte enthalten. Ein NULL-Wert 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: Minimieren der Gesamt-Fahrzeitüberschreitung unabhängig von höheren Reisekosten für die Fahrzeugflotte, Suchen einer Lösung mit ausgewogenem Verhältnis zwischen Gesamtzeitverstoß und Reisekosten sowie Ignorieren der Gesamt-Fahrzeitüberschreitung und stattdessen Minimieren der Reisekosten für die Fahrzeugflotte. Wenn Sie dem Parameter Gewichtung der Fahrzeitüberschreitung (excess_transit_factor in Python) eine Gewichtung zuweisen, entscheiden Sie sich für eine dieser drei Strategien. 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
Gewichtung der Fahrzeitüberschreitung (optional)	Gibt an, wie wichtig die Reduzierung von Fahrzeitüberschreitungen bei 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. Niedrig—Legt den Schwerpunkt auf die Minimierung der Gesamtlösungskosten und weniger auf die Fahrzeitüberschreitung. Diese Einstellung wird normalerweise von Kurierdiensten verwendet. Da Kurierdienste Pakete und keine Personen befördern, muss die Fahrzeit nicht berücksichtigt werden. Mit dieser Einstellung können Kuriere Auftragspaare in der ordnungsgemäßen Reihenfolge abwickeln und die Gesamtlösungskosten minimieren. Mittel—Legt den Schwerpunkt auf ein ausgewogenes Verhältnis zwischen Reduzierung der Fahrzeitüberschreitung und Reduzierung der Gesamtreisekosten. Dies ist der Standardwert. Hoch—Legt den Schwerpunkt auf die kürzeste Fahrzeit zwischen Auftragspaaren und weniger auf die Gesamtreisekosten. Diese Einstellung empfiehlt sich, wenn bei Aufträgen Personen befördert werden und Sie die Fahrzeiten der Personen verkürzen möchten. Ein typisches Beispiel sind Taxiunternehmen.	String
Punkt-Barrieren (optional)	Legt Punkt-Barrieren fest, die in zwei Typen unterteil sind: Punkt-Barrieren für Einschränkungen und Punkt-Barrieren für Zusatzkosten. Sie schränken das Passieren von Punkten oder Hinzufügen von Impedanz zu Punkten im Netzwerk vorübergehend ein. Die Punkt-Barrieren werden durch ein Feature-Set definiert und anhand der Attributwerte, die Sie für die Punkt-Features angeben, wird festgelegt, ob es sich um Punkt-Barrieren für Einschränkungen oder Punkt-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 Reise völlig beschränkt oder Kosten beim Passieren der Barriere hinzufügt. Es gibt zwei Optionen: Einschränkung (0): Untersagt, dass die Barriere passiert wird. Dies ist der Standardwert. Zusatzkosten (2): Durch Passieren der Barriere erhöhen sich die Netzwerkkosten um den Betrag, der in den Feldern Additional_Time und Additional_Distance angegeben ist. Additional_Time: Wenn BarrierType auf Zusatzkosten festgelegt ist, gibt der Wert des Feldes Additional_Time an, wie viel Zeit 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 festgelegt ist, gibt der Wert des Feldes Additional_Distance an, wie viel Impedanz einer Route hinzugefügt wird, wenn die Route die Barriere passiert. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten angegeben.	Feature Set
Linien-Barrieren (optional)	Gibt Linien-Barrieren an, für die das Passieren vorübergehend eingeschränkt ist. 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-Barrieren (optional)	Legt Polygon-Barrieren fest, die in zwei Typen unterteil sind: Punkt-Barrieren für Einschränkungen und Punkt-Barrieren für skalierte Kosten. Sie schränken das Passieren oder Skalieren der Impedanz für die Teile des Netzwerks ein, die sie abdecken. Die Polygon-Barrieren werden durch ein Feature-Set definiert und anhand der Attributwerte, die Sie für die Polygon-Features angeben, wird festgelegt, ob es sich um Punkt-Barrieren für Einschränkungen oder Punkt-Barrieren für skalierte Kosten 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 Reise völlig beschränkt oder die Kosten für das Passieren der Barriere skaliert. Es gibt zwei Optionen: Einschränkung (0): Untersagt, dass die Barriere an irgend einer Stelle passiert werden kann. Dies ist der Standardwert. Kostenfaktor (1): Skaliert die Impedanz der zugrunde liegenden Kanten, indem diese mit dem Wert der Eigenschaft "Attr_[Impedance]" multipliziert werden. Wenn Kanten teilweise von der Barriere abgedeckt werden, wird die Impedanz aufgeteilt und multipliziert. Scaled_Time: Die zeitbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem in diesem Feld festgelegten Wert multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine skalierte Kostenbarriere ist. Scaled_Distance: Die entfernungsbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem in diesem Feld festgelegten Wert multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine skalierte Kostenbarriere ist.	Feature Set
Zeitattribut (optional)	Das Netzwerkkostenattribut, mit dem die Fahrzeit der Netzwerkelemente festgelegt wird. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
Entfernungsattribut (optional)	Das Netzwerkkostenattribut, mit dem die Entfernung der Netzwerkelemente festgelegt wird. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
Hierarchie bei Analyse verwenden (optional)	Aktiviert: Für die Analyse wird das Hierarchie-Attribut verwendet. Wenn eine Hierarchie verwendet wird, werden vom Solver Kanten einer höheren Rangstufe gegenüber Kanten niedrigerer Rangstufen bevorzugt. Hierarchische Berechnungen sind schneller und können verwendet werden, um zu simulieren, dass ein Fahrer es nach Möglichkeit vorzieht, auf Autobahnen statt auf Landstraßen zu fahren, selbst wenn die Fahrstrecke dann länger ist. Diese Option ist nur dann aktiv, wenn das Eingabe-Netzwerk-Dataset ein Hierarchie-Attribut aufweist. Deaktiviert: Für die Analyse wird kein Hierarchie-Attribut verwendet. Wird keine Hierarchie verwendet, ist das Ergebnis eine genaue Route für das Netzwerk-Dataset. Der Parameter ist inaktiv, wenn ein Hierarchie-Attribut nicht für das Netzwerk-Dataset definiert ist, das zum Durchführen der Analyse verwendet wird. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	Boolean
Einschränkungen (optional)	Gibt an, welche Netzwerkrestriktionsattribute bei der Berechnung beachtet werden. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
Netzwerkparameterwerte (optional)	Gibt die Parameterwerte für die Netzwerkattribute an, die über Parameter verfügen. Über zwei der Spalten im Datensatz werden Parameter eindeutig identifiziert und über eine weitere Spalte wird der Parameterwert angegeben. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird. Der Datensatz für Attributparameterwerte 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 durch die Tabellenzeile festgelegt wird. ParameterName: Der Name des Attributparameters, dessen Wert durch die Tabellenzeile festgelegt wird. (Parameter des Typs "Objekt" können mit diesem Werkzeug nicht aktualisiert werden.) ParameterValue: Der Wert, den Sie für den Attributparameter festlegen möchten. Wenn kein Wert angegeben ist, wird der Attributparameterwert auf NULL festgelegt.	Record Set
Maximale Fangtoleranz (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 und der Punkt wird an der nächstgelegenen Kante bzw. am nächstgelegenen Knoten gefangen. Wenn keine geeignete Position innerhalb der maximale Fangtoleranz gefunden wird, wird das Objekt als nicht verortet gekennzeichnet.	Linear Unit
Nicht passierbare Teile des Netzwerks ausschließen (optional)	Gibt an, wo Netzwerkstandorte platziert werden. Aktiviert: Die Netzwerkstandorte werden nur auf passierbaren Teilen des Netzwerks platziert. Dies verhindert, dass Netzwerkstandorte auf Elementen platziert werden, die Sie aufgrund von Beschränkungen oder Barrieren nicht erreichen können. Stellen Sie vor dem Hinzufügen der Netzwerkstandorte mithilfe dieser Option sicher, dass Sie bereits alle Einschränkungsbarrieren zum Eingabe-Netzwerkanalyse-Layer hinzugefügt haben, um die gewünschten Ergebnisse zu erhalten. Beim Hinzufügen von Barrierenobjekten ist diese Option nicht anwendbar. Deaktiviert: Die Netzwerkstandorte werden auf allen Elementen des Netzwerks platziert. Die Netzwerkstandorte, die mit dieser Option hinzugefügt werden, sind – wenn sie auf eingeschränkten Elementen platziert werden – möglicherweise während des Berechnungsprozesses nicht erreichbar.	Boolean
WHERE-Klausel für Feature-Locator (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-Locators beim Laden.	Value Table
Routenlinien füllen (optional)	Gibt an, ob Linien erstellt werden, die das echte Shape der Routen darstellen. Aktiviert: Die Shape-Felder von Routen-Features werden mit Linien gefüllt. Deaktiviert: Für die Ausgaberouten wird kein Shape erstellt.	Boolean
Vereinfachungstoleranz für Routenlinien (optional)	Die Vereinfachungsentfernung der Routengeometrie. 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. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	Linear Unit
Wegbeschreibungen erstellen (optional)	Gibt an, ob Wegbeschreibungen erstellt werden. Aktiviert: Es werden Wegbeschreibungen erstellt. Die im Parameter Ausgabename für Wegbeschreibung angegebene Feature-Class wird mit Wegbeschreibungen für die einzelnen Routen gefüllt. Das Netzwerk-Dataset muss Wegbeschreibungen unterstützen, da sonst bei der Berechnung der Wegbeschreibungen ein Fehler auftritt. Deaktiviert: Es werden keine Wegbeschreibungen erstellt.	Boolean
Sprache für Wegbeschreibung (optional)	Die Sprache, in der Wegbeschreibungen erstellt werden. Die in der Dropdown-Liste verfügbaren Sprachen hängen von den auf dem Computer installierten ArcGIS-Sprachpaketen ab. Wenn Sie dieses Werkzeug als Teil eines Service auf einem separaten Server veröffentlichen möchten, muss das ArcGIS-Sprachpaket für die ausgewählte Sprache auf dem Server installiert sein, 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
Style-Name für Wegbeschreibung (optional)	Gibt den Formatierungs-Style von Wegbeschreibungen an. NA Desktop—Druckbare Wegbeschreibung NA Navigation—Wegbeschreibung für ein Navigationsgerät im Fahrzeug NA Campus—Wegbeschreibung für Fußgänger	String
Ausgabe-Netzwerkanalyse-Layer speichern (optional)	Gibt an, ob die Ausgabe einen Netzwerkanalyse-Layer der Ergebnisse umfasst. Aktiviert: Die Ausgabe umfasst einen Netzwerkanalyse-Layer der Ergebnisse. Deaktiviert: Die Ausgabe umfasst keinen Netzwerkanalyse-Layer der Ergebnisse. Es werden in jedem Fall Standalone-Tabellen und Feature-Classes zurückgegeben. Möglicherweise möchte ein Serveradministrator ebenfalls einen Netzwerkanalyse-Layer ausgeben, um einen Debugging-Vorgang für das Setup und die Ergebnisse des Werkzeugs mit den Network Analyst-Steuerelementen in der ArcGIS Desktop-Umgebung durchzuführen. Dies kann das Debuggen vereinfachen. In ArcGIS 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-Eigenschaften (optional)	Bestimmt die maximale Verarbeitungszeit bei der Ausführung dieses Werkzeugs als Geoverarbeitungsservice. Sie legen dies aus einem der folgenden zwei Gründe fest: um zu verhindern, dass Ihr Server Probleme berechnet, die mehr Ressourcen oder Verarbeitungszeit erfordern, als Sie bereitstellen möchten, oder um im Rahmen Ihres Geschäftsmodells mehrere Services mit unterschiedlichen VRP-Funktionen zu erstellen. Beispiel: Sie folgen einem Geschäftsmodell mit mehrstufigem Serviceangebot und möchten einen kostenlosen VRP-Service bereitstellen, der maximal fünf Routen pro Berechnung unterstützt, sowie einen weiteren gebührenpflichtigen Service, der mehr als fünf Routen pro Berechnung unterstützt. Zusätzlich zur maximalen Anzahl an Routen können Sie die Anzahl an Aufträgen oder Punkt-Barrieren beschränken, die der Analyse hinzugefügt werden können. Eine andere Möglichkeit zur Steuerung von problematischen Größen besteht in der 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. MAXIMUM POINT BARRIERS—Die maximal zulässige Anzahl an Punkt-Barrieren. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM FEATURES INTERSECTING LINE BARRIERS—Die maximale Anzahl von Quell-Features, die von allen Linien-Barrieren in der Analyse geschnitten werden kann. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM FEATURES INTERSECTING POLYGON BARRIERS—Die maximale Anzahl von Quell-Features, die von allen Polygon-Barrieren in der Analyse geschnitten werden kann. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM ORDERS—Die maximal zulässige Anzahl von Aufträgen in der Analyse. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM ROUTES—Die maximal zulässige Anzahl von Routen in der Analyse. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. FORCE HIERARCHY BEYOND DISTANCE—Die maximale geradlinige Entfernung zwischen Aufträgen, bevor das Vehicle Routing Problem mit der Netzwerkhierarchie berechnet wird. Die Einheiten für diesen Wert entsprechen denen im Parameter Distance Field Units.Wenn das Netzwerk kein Hierarchie-Attribut aufweist, wird diese Einschränkung ignoriert. Wenn Hierarchie bei Analyse verwenden aktiviert ist, wird die Hierarchie immer verwendet. Wenn der Parameter Hierarchie bei Analyse verwenden deaktiviert ist und diese Einschränkung einen NULL-Wert aufweist, wird die Hierarchie nicht erzwungen. MAXIMUM ORDERS PER ROUTE—Die maximale Anzahl von Aufträgen, die jeder Route zugewiesen werden können. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist.	Value Table
Ungültige Auftragsstandorte ignorieren (optional)	Gibt an, ob ungültige Aufträge beim Berechnen des Vehicle Routing Problem ignoriert werden. Aktiviert: Beim Berechnungsvorgang werden ungültige Aufträge ignoriert, und es wird eine Lösung zurückgegeben, sofern keine anderen Fehler aufgetreten sind. Wenn Sie Routen erstellen und sofort an die Fahrer weitergeben müssen, können Sie bei Bedarf ungültige Aufträge ignorieren, die Berechnung durchführen und die Routen an die Fahrer übermitteln. Lösen Sie als Nächstes alle ungültigen Aufträge aus dem letzten Berechnungsvorgang, und fügen Sie sie zur VRP-Analyse für den nächsten Arbeitstag oder die nächste Arbeitsschicht hinzu. Deaktiviert: Der Berechnungsvorgang ist nicht erfolgreich, wenn ungültige Aufträge erkannt werden. Ein ungültiger Auftrag ist ein Auftrag, den der VRP-Solver nicht erreichen kann. Ein Auftrag kann aus verschiedenen Gründen nicht erreichbar sein, etwa weil er sich in einem unzulässigen Netzwerkelement, überhaupt nicht im Netzwerk oder an einem nicht verbundenen Teil des Netzwerks befindet.	Boolean
Reisemodus (optional)	Wählen Sie den Transportmodus für die Analyse aus. Benutzerdefiniert kann immer ausgewählt werden. Um andere Namen für Reisemodi anzuzeigen, müssen sie in dem Netzwerk-Dataset vorhanden sein, das im Parameter Netzwerk-Dataset angegeben wurde. Ein Reisemodus wird in einem Netzwerk-Dataset definiert und stellt Override-Werte für Parameter bereit, die zusammen Reisemodi wie Auto, Lkw, Fußgänger usw. modellieren. Wenn Sie hier einen Reisemodus auswählen, müssen Sie keine Werte für die folgenden Parameter angeben, die von Werten überschrieben werden, die im Netzwerk-Dataset angegeben wurden: Wendenregel Zeitattribut Entfernungsattribut Hierarchie bei Analyse verwenden Beschränkungen Netzwerkparameterwerte Vereinfachungstoleranz für Routenlinien Benutzerdefiniert—Definieren Sie einen Reisemodus, der Ihre spezifischen Anforderungen erfüllt. Bei Auswahl von Benutzerdefiniert überschreibt das Werkzeug die oben aufgelisteten Reisemodusparameter nicht. Dies ist der Standardwert.	String
Netzwerkstandortfelder ignorieren (optional)	Gibt an, ob die Netzwerkstandortfelder (SourceID, SourceOID, PosAlong und SideOfEdge) bei der Suche nach Aufträgen, Depots oder Barrieren im Netzwerk berücksichtigt werden. Aktiviert: Netzwerkstandortfelder werden bei der Suche der Eingaben im Netzwerk nicht berücksichtigt. Stattdessen werden die Eingaben stets mithilfe einer räumlichen Suche lokalisiert. Deaktiviert: Netzwerkstandortfelder werden bei der Suche der Eingaben im Netzwerk berücksichtigt. Dies ist der Standardwert.	Boolean
Zeitzonenverwendung für Zeitfelder (optional)	Gibt die Zeitzone der folgenden Datums-/Uhrzeit-Eingabefelder an, die vom Werkzeug unterstützt werden: TimeWindowStart1, TimeWindowEnd1, TimeWindowStart2, TimeWindowEnd2, InboundArriveTime und OutboundDepartTime für Aufträge; TimeWindowStart1, TimeWindowEnd1, TimeWindowStart2 und TimeWindowEnd2 für Depots; EarliestStartTime und LatestStartTime für Routen sowie TimeWindowStart und TimeWindowEnd für Pausen. Es ist hilfreich, die Werte für Datum/Uhrzeit in UTC anzugeben, wenn Sie die Zeitzone nicht kennen, in der sich die Aufträge oder Depots befinden, oder wenn Sie über Aufträge und Depots in mehreren Zeitzonen verfügen und alle Werte für Datum/Uhrzeit gleichzeitig gestartet werden sollen. Die UTC-Option kann nur angewendet werden, wenn Ihr Netzwerk-Dataset ein Zeitzonenattribut definiert. Anderenfalls werden alle Werte für Datum/Uhrzeit stets als Geo local (GEO_LOCAL in Python) verarbeitet. GEO LOCAL—Die mit den Aufträgen oder Depots verknüpften Werte für Datum/Uhrzeit befinden sich in der Zeitzone, in der sich die Aufträge und Depots befinden. Bei Routen basieren die Werte für Datum/Uhrzeit auf der Zeitzone, in der sich das Startdepot für die Route befindet. Hat eine Route kein Startdepot, müssen sich alle Aufträge und Depots über alle Routen hinweg in einer einzelnen Zeitzone befinden. Bei Pausen basieren die Werte für Datum/Uhrzeit auf der Zeitzone der Routen. Wenn sich Ihr Depot beispielsweise in einem Gebiet befindet, in dem die Eastern Standard Time gilt, und die Werte des ersten Zeitfensters (angegeben in TimeWindowStart1 und TimeWindowEnd1) 8:00 Uhr und 17:00 Uhr lauten, werden die Zeitfensterwerte als 8:00 Uhr und 17:00 Uhr Eastern Standard Time behandelt. UTC—Die mit den Aufträgen oder Depots verknüpften Datums-/Uhrzeitwerte sind in der koordinierten Weltzeit (UTC) angegeben und basieren nicht auf der Zeitzone, in der sich die Aufträge oder Depots befinden. Wenn sich Ihr Depot beispielsweise in einem Gebiet befindet, in dem die Eastern Standard Time gilt und die Werte des ersten Zeitfensters (angegeben als TimeWindowStart1 und TimeWindowEnd1) 8.00 Uhr und 17.00 Uhr lauten, werden die Zeitfensterwerte als 12.00 Uhr und 21.00 Uhr Eastern Standard Time behandelt, wobei davon ausgegangen wird, dass die Sommerzeit berücksichtigt wird.	String
Overrides (optional)	Hinweis: Dieser Parameter ist nur für die interne Verwendung vorgesehen.	String
Routendaten speichern (optional)	Gibt an, ob eine .zip-Datei mit einer File-Geodatabase gespeichert werden soll, in der die Eingaben und Ausgaben der Analyse in einem Format vorliegen, das zum Freigeben von Routen-Layern mit ArcGIS Online oder ArcGIS Enterprise verwendet werden kann. In ArcGIS Desktop befindet sich der Standardausgabespeicherort für diese Ausgabedatei im Scratch-Ordner. Sie können den Speicherort des Scratch-Ordners festlegen, indem Sie arcpy.env.scratchFolder verwenden oder die Geoverarbeitungsumgebung überprüfen. Aktiviert: Das Werkzeug erstellt ein .zip-Archiv, das einen File-Geodatabase-Workspace mit den Eingaben und Ausgaben der Analyse enthält. Deaktiviert: Es werden keine Routendaten gespeichert. Dies ist die Standardeinstellung.	Boolean

Abgeleitete Ausgabe

Beschriftung	Erläuterung	Datentyp
Ausgabeberechnung erfolgreich	Ein boolescher Wert, der angibt, ob die Berechnung der Vehicle Routing Problem-Analyse erfolgreich war.	Boolean
Nicht zugeordnete Ausgabe-Stopps	Tabelle mit einer Liste der Aufträge, die auf keiner Route besucht werden konnten.	Table
Ausgabe-Stopps	Tabelle mit Informationen über Stopps bei Depots, Aufträgen und Unterbrechungen.	Table
Ausgabe-Routen	Eine Feature-Class, die die Fahrer, Fahrzeuge und Fahrzeugroutenpfade in einem Vehicle Routing Problem repräsentiert.	Feature Class
Ausgabe-Wegbeschreibungen	Schrittweise Anleitungen, um den Fahrern die Verfolgung ihrer zugewiesenen Routen zu erleichtern.	Feature Class
Ausgabe-Netzwerkanalyse-Layer	Netzwerkanalyse-Layer mit in den Werkzeugparametern konfigurierten Eigenschaften, der für weitere Analysen oder zum Debuggen in der Karte verwendet werden kann.	File
Ausgabe-Routendaten	Eine .zip-Datei mit allen Informationen für eine bestimmte Route.	File

arcpy.na.SolveVehicleRoutingProblem(orders, depots, routes, breaks, time_units, distance_units, network_dataset, output_workspace_location, output_unassigned_stops_name, output_stops_name, output_routes_name, output_directions_name, {default_date}, {uturn_policy}, {time_window_factor}, {spatially_cluster_routes}, {route_zones}, {route_renewals}, {order_pairs}, {excess_transit_factor}, {point_barriers}, {line_barriers}, {polygon_barriers}, {time_attribute}, {distance_attribute}, {use_hierarchy_in_analysis}, {restrictions}, {attribute_parameter_values}, {maximum_snap_tolerance}, {exclude_restricted_portions_of_the_network}, {feature_locator_where_clause}, {populate_route_lines}, {route_line_simplification_tolerance}, {populate_directions}, {directions_language}, {directions_style_name}, {save_output_layer}, {service_capabilities}, {ignore_invalid_order_locations}, {travel_mode}, {ignore_network_location_fields}, {time_zone_usage_for_time_fields}, {overrides}, {save_route_data})

Name	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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. Hinweis: Ein Zeitfenster gibt nur an, wann ein Fahrzeug bei einer Lieferung ankommen kann. Es gibt nicht an, wann die Durchführungszeit abgeschlossen sein muss. Wenn die Durchführungszeit und die Abfahrt des Fahrzeugs vor dem Ende des Zeitfensters berücksichtigt werden sollen, subtrahieren Sie den Feldwert für ServiceTime vom Feldwert für TimeWindowEnd1. Die Zeitfensterfelder dürfen einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Dabei darf es sich nicht um ganze Zahlen handeln, die Millisekunden seit Unixzeit darstellen. Die Zeitzone für Zeitfensterfelder wird mit dem Parameter time_zone_usage_for_time_fields angegeben. Wenn ein Zeitfeld, z. B. TimeWindowStart1, einen reinen Uhrzeitwert enthält (z. B. 8:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft "Standarddatum" des Analyse-Layers angegebene Datum verwendet wird. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2010 8:00 Uhr), können Sie Zeitfenster über mehrere Tage festlegen. 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. Wenn Sie Verkehrsdaten verwenden, beziehen sich die Felder für Uhrzeit und Datum des Netzwerkstandorts immer auf die gleiche Zeitzone wie die Kante, auf der sich der Netzwerkstandort befindet. TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert 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 NULL-Wert 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 nach dem Ende des Zeitfensters liegt. 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 NULL-Wert bedeutet jedoch auch, 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Zeitfensterverletzungen können vom Solver verfolgt und gewichtet werden. Daher können Sie für den VRP-Solver eine von drei Strategien festlegen: Minimieren des Gesamtzeitverstoßes, unabhängig von der Erhöhung der Reisekosten für die Fahrzeugflotte Suchen einer Lösung, die einen Kompromiss zwischen Gesamtzeitverstoß und Reisekosten ermöglicht Ignorieren des Gesamtzeitverstoßes und stattdessen Minimieren der Reisekosten für die Fahrzeugflotte Wenn Sie dem Parameter Gewichtung der Zeitfensterverletzung (time_window_factor in Python) eine Gewichtung zuweisen, entscheiden Sie sich letztendlich für eine dieser drei Strategien. Der Solver gibt 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. InboundArriveTime: Legt fest, wann der am Ort des Auftrags abzuliefernde Gegenstand am Startdepot bereit ist. Der Auftrag kann einer Route nur dann zugewiesen werden, wenn die eingehende Ankunftszeit dem letzten Startzeitwert der Route vorausgeht. Auf diese Weise kann die Route das Depot nicht verlassen, bevor der Liefergegenstand bereit ist, in das Depot geladen zu werden. Mit diesem Feld können Szenarien mit Umladungen eingehender Lieferungen modelliert werden. Beispiel: Für einen Auftrag sind spezielle Materialien erforderlich, die derzeit nicht im Depot verfügbar sind. Die Materialien werden von einem anderen Standort versendet und erreichen das Depot um 11:00 Uhr. Um sicherzustellen, dass ein Fahrzeug, das auf einer Route den Ort vor dem Eintreffen der Lieferung verlässt, dem Auftrag nicht zugewiesen wird, wird die eingehende Ankunftszeit des Auftrags auf 11:00 Uhr festgelegt. Die speziellen Materialien treffen um 11:00 Uhr ein, werden auf das Fahrzeug geladen und das Fahrzeug verlässt das Depot, um die ihm zugewiesenen Orte des Auftrags anzufahren. Hinweis: Die Startzeit der Route, die Durchführungszeiten umfasst, muss auf die eingehende Ankunftszeit folgen. Wenn eine Route vor der eingehenden Ankunftszeit eines Auftrags beginnt, kann der Auftrag der Route nicht zugewiesen werden. Die Zuweisung ist auch dann ungültig, wenn die Route eine Start-Depot-Durchführungszeit aufweist, die bis über die eingehende Ankunftszeit hinaus andauert. Dieses Zeitfeld kann einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein reiner Uhrzeitwert festgelegt wurde (z. B. 11:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Das Standarddatum wird jedoch ignoriert, wenn ein Zeitfeld in Depots, Routen, Aufträgen oder Unterbrechungen ein Datum mit Uhrzeit enthält. Geben Sie in diesem Fall all diese Felder mit Datum und Uhrzeit ein (z. B. 11.07.2015 11:00 Uhr). Der VRP-Solver berücksichtigt InboundArriveTime unabhängig vom DeliveryQuantities-Wert. Wenn außerdem eine ausgehende Abfahrtzeit angegeben ist, muss deren Zeitwert nach der eingehenden Ankunftszeit liegen. Der VRP Solver ist nicht für die Lösung von Problemen ausgelegt, die länger als ein Jahr andauern. Daher müssen alle Durchführungszeiten und Zeitfenster weniger als ein Jahr betragen. OutboundDepartTime: Legt fest, wann der am Ort des Auftrags abzuholende Liefergegenstand das End-Depot erreichen muss. Der Auftrag kann einer Route nur dann zugewiesen werden, wenn die Route den Ort des Auftrags anfahren kann und dessen End-Depot vor der angegebenen ausgehenden Abfahrtzeit erreicht. Mit diesem Feld können Szenarien mit Umladungen ausgehender Lieferungen modelliert werden. Beispiel: Eine Transportfirma schickt Lieferwagen los, um Pakete von Aufträgen abzuholen und sie zu einem Depot zu bringen. Von dort aus werden sie auf dem Weg zu ihrem Endziel zu anderen Einrichtungen weitertransportiert. Täglich um 15:00 Uhr stoppt ein Sattelschlepper am Depot, um die Pakete mit hoher Priorität abzuholen und sie direkt zu einer zentralen Verarbeitungsstation zu bringen. Um eine Verzögerung der Pakete mit hoher Priorität bis zur 15:00 Uhr-Fahrt des folgenden Tages zu vermeiden, lässt die Transportfirma die Pakete mit hoher Priorität an den Auftragsorten von Lieferwagen abholen und vor Ablauf der 15:00 Uhr-Frist zum Depot bringen. Dazu wird die Abfahrtszeit auf 15:00 Uhr festgelegt. Hinweis: Die Endzeit der Route, einschließlich der Durchführungszeiten, muss vor der ausgehenden Abfahrtzeit liegen Wenn eine Route ein Depot erreicht, die Durchführungszeit des End-Depots jedoch nicht vor der ausgehenden Abfahrtzeit des Auftrags abgeschlossen ist, kann der Auftrag der Route nicht zugewiesen werden. Dieses Zeitfeld kann einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein reiner Uhrzeitwert festgelegt wurde (z. B. 11:00 Uhr), wird vorausgesetzt, dass als Datum das von der Eigenschaft Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Das Standarddatum wird jedoch ignoriert, wenn ein Zeitfeld in Depots, Routen, Aufträgen oder Unterbrechungen ein Datum mit Uhrzeit enthält. Geben Sie in diesem Fall all diese Felder mit Datum und Uhrzeit ein (z. B. 11.07.2015 11:00 Uhr). Der VRP-Solver berücksichtigt OutboundDepartTime unabhängig vom PickupQuantities-Wert. Wenn außerdem eine Ankunftszeit angegeben ist, muss deren Zeitwert vor der Abfahrtszeit liegen. 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 Maße angeben, 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 Abfolge die Werte und ihre entsprechenden Einheiten eingegeben werden. Stellen Sie sicher, dass Capacities für Routen und DeliveryQuantities und 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 unterschiedliche Einheiten verwendet werden oder die Reihenfolge geändert wird, erhalten Sie unerwünschte Ergebnisse, ohne dass eine Warnmeldung ausgegeben wird. Eine leere Zeichenfolge oder ein NULL-Wert 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. Hinweis: 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 NULL-Wert (ein NULL-Wert 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" in seiner Ausgabe nie die Einnahmen enthält. Jedoch werden für die Einnahmen 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 NULL-Wert gibt an, dass der Auftrag keine Besonderheiten erfordert. Die Schreibweisen der in den Anforderungs- und Routenklassen aufgeführten gesonderten Elemente müssen genau übereinstimmen, sodass sie vom VRP Solver zusammengeführt werden können. Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Grünanlagen pflegt und Baumschnittarbeiten durchführt, für einige Aufträge ein Fahrzeug mit einem Hubsteiger benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge Hubsteiger in das Feld SpecialtyNames ein, um auf diese besondere Anforderung hinzuweisen. SpecialtyNames bleibt NULL für die anderen Aufträge. Entsprechend gibt die Firma Hubsteiger 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 Hubsteiger 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). Ausschließen (0): Der Auftrag wird aus dem nachfolgenden Berechnungsvorgang ausgeschlossen. Route und relative Sequenz beibehalten (1): Der Solver muss den Auftrag während des Berechnungsvorgangs immer der vorab zugewiesenen Route mit der vorab zugewiesenen relativen Sequenz zuweisen. Wenn diese Zuweisungsregel nicht befolgt werden kann, führt dies zu einem Verstoß gegen den Auftrag. Mit dieser Einstellung wird nur die relative Sequenz, nicht die absolute Sequenz, verwaltet. Um dies näher zu veranschaulichen, stellen Sie sich vor, es gibt zwei Aufträge: A und B. Sie weisen die Sequenzwerte 2 bzw. 3 auf. Wenn Sie die Werte des Feldes AssignmentRule auf "Route und relative Sequenz beibehalten" festlegen, können sich die tatsächlichen Sequenzwerte von A und B nach der Berechnung ändern, da andere Aufträge, Pausenzeiten und Depotstopps immer vor, zwischen oder nach A und B angeordnet werden können. B kann jedoch nicht vor A angeordnet werden. Route beibehalten (2): Der Solver muss den Auftrag während des Berechnungsvorgangs immer der vorab zugewiesenen Route zuweisen. Außerdem muss eine gültige Sequenz festgelegt sein, auch wenn diese nicht unbedingt beibehalten werden muss. Wenn der Auftrag nicht der angegebenen Route zugewiesen werden kann, führt dies zu einem Verstoß gegen den Auftrag. Überschreiben (3): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist eine Route und Sequenz für den Auftrag zu, um den Gesamtwert der Zielfunktion zu verringern. Dies ist der Standardwert. Erstes Element verankern (4): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist dem Auftrag eine Route zu und legt ihn als ersten Auftrag auf dieser Route fest, um den Gesamtwert der Zielfunktion zu verringern. Letztes Element verankern (5): Der Solver ignoriert während des Berechnungsvorgangs die Vorabzuweisung (falls vorhanden) von Route und Sequenz für den Auftrag. Er weist dem Auftrag eine Route zu und legt ihn als letzten Auftrag auf dieser Route fest, um den Gesamtwert der Zielfunktion zu verringern. Dieses Feld darf keinen NULL-Wert enthalten. CurbApproach: Die Eigenschaft CurbApproach gibt die Richtung an, in der ein Fahrzeug bei der Einrichtung ankommt bzw. von ihr wegfährt. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar: Beide Seiten des Fahrzeugs (0): Das Fahrzeug kann sich von beiden Richtungen dem Netzwerkstandort nähern und von ihm abfahren. Wenden ist erlaubt. Sie sollten diese Einstellung auswählen, wenn das Fahrzeug an dem Stopp wenden kann bzw. wenn es in eine Auffahrt oder einen Parkplatz einfahren und dort wenden kann. Rechte Seite des Fahrzeugs (1): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der rechten Seite des Fahrzeugs befinden. Wenden ist verboten. Linke Seite des Fahrzeugs (2): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der linken Seite des Fahrzeugs befinden. Wenden ist verboten. Wendeverbot (3): Wenn sich das Fahrzeug dem Netzwerkstandort nähert, kann sich die Bordkante auf jeder Seite des Fahrzeuges befinden; das Fahrzeug muss jedoch abfahren, ohne zu wenden. 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 NULL-Wert 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 NULL-Wert enthalten, um anzugeben, dass der Auftrag an einer beliebigen Position auf der Route eingefügt werden kann. Ein NULL-Wert ist nur gemeinsam mit einem NULL-Wert für RouteName zulässig. Die Eingabesequenzwerte sind nicht negativ und für jede Route eindeutig (gültig für Depotstopps, Aufträge und Pausenzeiten), müssen jedoch nicht bei 0 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 Artikel entladen oder eingeladen werden, 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 den Namen, den Sie hier angeben. Er wird ebenfalls vom Record-Set "Lager (Be-/Entladen)" referenziert, wenn dieses verwendet wird. Bei Depotnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Das Feld darf nicht leer sein und muss einen eindeutigen Namen enthalten. TimeWindowStart1: Die Anfangszeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein Nullwert gibt an, dass keine Anfangszeit vorhanden ist. Hinweis: Die Zeitfensterfelder können einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Wenn ein Zeitfeld einen reinen Uhrzeitwert enthält (z. B. 8:00 Uhr), wird vorausgesetzt, dass als Datum das vom Parameter Standarddatum des Analyse-Layers angegebene Datum verwendet wird. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2010 8:00 Uhr), können Sie Zeitfenster über mehrere Tage festlegen. 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. Wenn Sie Verkehrsdaten verwenden, beziehen sich die Felder für Uhrzeit und Datum des Netzwerkstandorts immer auf die gleiche Zeitzone wie die Kante, auf der sich der Netzwerkstandort befindet. TimeWindowEnd1: Die Endzeit des ersten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Endzeit vorhanden ist. TimeWindowStart2: Die Anfangszeit des zweiten Zeitfensters für den Netzwerkstandort. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert 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 NULL-Wert 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 bei der Einrichtung ankommt bzw. von ihr wegfährt. Es sind vier Optionen (ihre codierten Werte werden in Klammern angegeben) verfügbar: Beide Seiten des Fahrzeugs (0): Das Fahrzeug kann sich von beiden Richtungen dem Netzwerkstandort nähern und von ihm abfahren. Wenden ist erlaubt. Sie sollten diese Einstellung auswählen, wenn das Fahrzeug an dem Stopp wenden kann bzw. wenn es in eine Auffahrt oder einen Parkplatz einfahren und dort wenden kann. Rechte Seite des Fahrzeugs (1): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der rechten Seite des Fahrzeugs befinden. Wenden ist verboten. Linke Seite des Fahrzeugs (2): Wenn sich das Fahrzeug dem Netzwerkstandort nähert oder von diesem wegfährt, muss sich die Bordsteinkante auf der linken Seite des Fahrzeugs befinden. Wenden ist verboten. Wendeverbot (3): Wenn sich das Fahrzeug dem Netzwerkstandort nähert, kann sich die Bordkante auf jeder Seite des Fahrzeuges befinden; das Fahrzeug muss jedoch abfahren, ohne zu wenden. Bearing: 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 Bearing auf einer Kante bewegt werden. Wenn sich der Wert des Feldes Bearing 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 Einheiten in Grad, und der Standardwert ist 30. Der Wert muss größer als 0 und kleiner als 180 sein. 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 enthalten. Die Eingabe eines NavLatency-Wertes ist jedoch optional, selbst wenn in Bearing und BearingTol Werte enthalten 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 Zeitattribut 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 zum 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 nicht zwischen Groß-/Kleinschreibung unterschieden. StartDepotName: Der Name des Startdepots für die Route. Dieses Feld dient als Fremdschlüssel für das Feld Name in 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, kann EndDepotName nicht ebenfalls NULL sein. Virtuelle Startdepots sind nicht zulässig, wenn Aufträge oder Depots in mehreren Zeitzonen vorliegen. 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 ist ein Fremdschlüssel für das Feld Name im Parameter Depots. StartDepotServiceTime: Die Durchführungszeit am Startdepot. Mit dieser kann die Zeit zum Beladen des Fahrzeugs modelliert werden. Dieses Feld kann einen NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Hinweis: 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 NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Hinweis: 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 der standardmäßige Uhrzeitwert ist 8:00 Uhr. Der Standardwert wird als 8:00 Uhr an dem vom Parameter Standarddatum (default_date in Python) angegebenen Datum interpretiert. 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 der standardmäßige Uhrzeitwert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Capacities: Die maximale Kapazität des Fahrzeugs. Sie können die Kapazität in einer beliebigen Dimension 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 Maße angeben, 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, sollte Capacities wie folgt angegeben werden: 18 56. Sie müssen sich wieder die Einheiten merken. Sie müssen sich ferner merken, in welcher Reihenfolge die Werte und ihre entsprechenden Einheiten eingegeben werden (in diesem Fall Tonnen gefolgt von Kubikmetern). Die Einheiten und deren Reihenfolge sind aus mehreren Gründen wichtig: Erstens können Sie so die Informationen auch später richtig deuten, und zweitens können Sie angemessene Werte für die Felder DeliveryQuantities und PickupQuantities unter Aufträge 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 unterschiedliche Einheiten verwendet werden oder die Reihenfolge in einem der drei Felder geändert wird, erhalten Sie unerwünschte Ergebnisse, ohne dass eine Warnmeldung ausgegeben wird. 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 NULL-Wert 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 zum Feld DeliveryQuantities oder PickupQuantities unter "Aufträge" nicht ausreichend ist, werden die restlichen Werte als 0 behandelt. Vorsicht: 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 NULL-Werte enthalten. Ein NULL-Wert 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 NULL-Wert enthalten und der Standardwert ist 1,0. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. CostPerUnitDistance: Der – pro Einheit gefahrener Strecke – für die Routenlänge (gesamte Reisestrecke) anfallende Geldbetrag. Dieses Feld kann NULL-Werte enthalten. Ein NULL-Wert 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 NULL-Werte enthalten. Ein NULL-Wert gibt an, dass keine Überstunden angewendet werden. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. Wenn beispielsweise dem Fahrer bei Überschreitung einer Gesamtroutendauer von 8 Stunden Überstunden bezahlt werden müssen, wird OvertimeStartTime als 480 (8 Stunden * 60 Minuten/Stunde) angegeben, vorausgesetzt, für den Parameter Uhrzeitfeldeinheiten wurde Minutes festgelegt. CostPerUnitOvertime: Der pro Zeiteinheit von Überstunden anfallende Geldbetrag. Dieser kann nur dann einen NULL-Wert enthalten, wenn OvertimeStartTime auch Null ist. Andernfalls muss es ein positiver Wert sein, der größer ist als der Wert für CostPerUnitTime. MaxOrderCount: Die maximal zulässige Anzahl von Aufträgen für die Route. Dieses Feld darf keine NULL-Werte enthalten und der Standardwert beträgt 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 NULL-Werte enthalten. Ein NULL-Wert gibt an, dass für die Routendauer keine Einschränkung gilt. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte enthalten. Ein NULL-Wert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte enthalten. Ein NULL-Wert 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 ist ein Fremdschlüssel für das Feld SpecialtyNames im Parameter Aufträge. Um die Bedeutung und Funktionsweise von Besonderheiten zu veranschaulichen, nehmen Sie an, dass eine Firma, die Grünanlagen pflegt und Baumschnittarbeiten durchführt, für einige Aufträge ein Fahrzeug mit einem Hubsteiger benötigt, um große Bäume zu beschneiden. Das Unternehmen gibt für diese Aufträge Hubsteiger in das Feld SpecialtyNames ein, um auf diese besondere Anforderung hinzuweisen. SpecialtyNames bleibt NULL für die anderen Aufträge. Entsprechend gibt die Firma Hubsteiger 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 Hubsteiger 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: Einschließen: Die Route wird in den Berechnungsvorgang einbezogen. Dies ist der Standardwert. Ausschließen: Die Route wird aus dem Berechnungsvorgang ausgeschlossen.	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 darf keine NULL-Werte enthalten, und der Standardwert beträgt 60. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. TimeWindowStart: Die Anfangszeit für das Zeitfenster der Pausenzeit. Halboffene Zeitfenster sind als Pausenzeiten ungültig. Wenn dieses Feld über einen Wert verfügt, müssen die Feldwerte für MaxTravelTimeBetweenBreaks und MaxCumulWorkTime NULL sein. Alle anderen Pausenzeiten in der Analyse müssen NULL-Werte 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 in Pausen dürfen einen reinen Uhrzeitwert oder einen Wert für Datum und Uhrzeit enthalten. Dabei darf es sich nicht um ganze Zahlen handeln, die Millisekunden seit Unixzeit darstellen. Die Zeitzone für Zeitfensterfelder wird mit dem Parameter time_zone_usage_for_time_fields angegeben. Wenn ein Zeitfeld, z. B. TimeWindowStart, einen reinen Uhrzeitwert enthält (z. B. 12:00 Uhr), wird angenommen, dass das Datum dem vom Parameter Standarddatum (default_date in Python) angegebenen Datum entspricht. Wenn Sie Datums- und Zeitwerte verwenden (z. B. 7/11/2012 12:00 Uhr), können Sie Zeitfenster über mehrere Tage angeben. Dies empfiehlt sich, 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. TimeWindowEnd: Die Endzeit für das Zeitfenster der Pausenzeit. Halboffene Zeitfenster sind als Pausenzeiten ungültig. Wenn dieses Feld über einen Wert verfügt, müssen die Feldwerte für MaxTravelTimeBetweenBreaks und MaxCumulWorkTime NULL sein. Alle anderen Pausenzeiten in der Analyse müssen NULL-Werte 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 Gewichtung der Zeitfensterverletzung (time_window_factor in Python) sanktioniert. Diese Eigenschaft kann NULL sein. Ein NULL-Wert 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 für den Analyseparameter Uhrzeitfeldeinheiten (time_units in Python) Minutes festgelegt wurde und MaxTravelTimeBetweenBreaks den Wert 120 aufweist, kann der Fahrer nach zwei Stunden Fahrt eine Pause einlegen. Um eine Pause nach zwei weiteren Stunden Fahrt zuzuweisen, muss als Feldwert für MaxTravelTimeBetweenBreaks der zweiten Pause 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 den 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 (time_units für Python) auf Minuten festgelegt ist, MaxCumulWorkTime den Wert 120 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 mithilfe des Parameters Uhrzeitfeldeinheiten (time_units in Python) angegeben. 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 NULL-Werte 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	Gibt die Zeiteinheiten für alle zeitbasierten Feldwerte in der Analyse an. Seconds—Sekunden Minutes—Minuten Hours—Stunden Days—Tage 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 (time_attribute in Python) entsprechen.	String
distance_units	Gibt die Entfernungseinheiten für alle entfernungsbasierten Feldwerte in der Analyse an. Miles—Meilen Kilometers—Kilometer Feet—Fuß Yards—Yard Meters—Meter NauticalMiles—Seemeilen 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 (distance attribute in Python) entsprechen.	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 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 einen Zeitpunkt, jedoch kein Datum angeben.	Date
uturn_policy (optional)	Definiert die Wendenregel an, die an Knoten verwendet werden soll. 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. ALLOW_UTURNS—Wenden sind an Knoten mit einer beliebigen Anzahl verbundener Kanten erlaubt. Dies ist der Standardwert. NO_UTURNS—Wenden sind an allen Knoten verboten, unabhängig von der Valenz der Knoten. Jedoch sind selbst bei Auswahl dieser Einstellung Wenden an Netzwerkstandorten weiterhin erlaubt, allerdings können Sie für die Eigenschaft CurbApproach des jeweiligen Netzwerkstandorts auch ein Verbot von Wenden festlegen. ALLOW_DEAD_ENDS_ONLY—Wenden sind an allen Knoten verboten, außer es ist nur eine angrenzende Kante vorhanden (Sackgasse). ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—Wenden sind an Knoten verboten, an denen genau zwei angrenzende Kanten aufeinander treffen, jedoch an Kreuzungen (Knoten mit drei oder mehr angrenzenden Kanten) und in Sackgassen (Knoten mit genau einer angrenzenden Kante) erlaubt. Oftmals verfügen Netzwerke über unwesentliche Knoten in der Mitte von Straßensegmenten. Durch diese Option wird verhindert, dass Fahrzeuge an diesen Punkten wenden. 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. Sie können auch die Einstellung der CurbApproach-Eigenschaft Ihrer Netzwerkstandorte festlegen. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
time_window_factor (optional)	Gibt an, wie wichtig die Einhaltung von Zeitfenstern ist. Es gibt drei Optionen, die unten aufgelistet und beschrieben sind. Low—Legt den Schwerpunkt auf die Minimierung der Fahrzeiten, statt auf die rechtzeitige Ankunft. Sie können ggf. diese Einstellung wählen, wenn Sie einen wachsenden Rückstand an Service-Anforderungen bewältigen müssen. Um an einem Tag mehr Aufträge durchführen zu können und den Rückstand abzuarbeiten, können Sie diese Einstellung auswählen, obwohl den Kunden durch die Verspätungen Unannehmlichkeiten entstehen können. Medium—Legt den Schwerpunkt gleichzeitig auf die Minimierung der Fahrzeiten und die Ankunft in den Zeitfenstern. Dies ist der Standardwert. High—Legt den Schwerpunkt auf eine rechtzeitige Ankunft und weniger auf die Minimierung der Fahrzeiten. Unternehmen mit zeitkritischen Lieferungen oder einem Schwerpunkt auf Kundenservice würden diese Einstellung auswählen.	String
spatially_cluster_routes (optional)	Gibt an, ob räumliches Clustering verwendet werden soll. CLUSTER—Die einer einzelnen Route zugewiesenen Aufträge werden räumlich gruppiert. Durch das Bilden von Auftrags-Clustern befinden sich Routen häufig in kleineren Gebieten. Dadurch schneiden sich die Routenlinien weniger oft, jedoch können sich die Gesamtfahrzeiten erhöhen. Dies ist die Standardeinstellung. NO_CLUSTER—Der Solver priorisiert das Bilden von räumlichen Auftrags-Clustern nicht, und die Routenlinien können sich schneiden. Verwenden Sie diese Option, wenn Routenzonen angegeben sind.	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. Nachfolgend finden Sie Beispiele für Fälle, in denen sich Routenzonen als sinnvoll erweisen: Einige Ihrer Mitarbeiter verfügen nicht über die erforderlichen Genehmigungen für die Durchführung von Arbeit in bestimmten Bundesländern oder Gemeinden. Sie können eine harte Routenzone erstellen, damit diese Mitarbeiter nur Aufträge in Gebieten erreichen, in denen die Anforderungen erfüllt werden. Bei einem Ihrer Fahrzeuge treten häufig Pannen auf. Daher soll es nur Aufträge an Standorten durchführen, die sich in der Nähe Ihrer Reparaturwerkstatt befinden, um die Reaktionszeit zu minimieren. Sie können eine weiche oder harte Routenzone erstellen, um das Fahrzeug in der Nähe zu behalten. 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 auf der Route das Be- oder Entladen am verknüpften 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. Wird gleichzeitig mit Routenschwerpunkten gearbeitet, sind folgende Regeln und Optionen zu beachten: Die Stelle zum Nachladen/Entladen bzw. der Standort zum Be-/Entladen muss nicht mit dem Start- oder Enddepot übereinstimmen. Jede Route kann eine oder mehrere vorab festgelegte Standorte zum Be-/Entladen aufweisen. Ein Standort zum Be-/Entladen kann mehrmals auf einer einzelnen Route verwendet werden. In einigen Fällen sind möglicherweise für eine Route mehrere potenzielle Standorte zum Be-/Entladen vorhanden, und vom Solver wird der nächste verfügbare Standort zum Be-/Entladen ausgewählt. 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, 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, 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 NULL-Wert enthalten. Ein NULL-Wert gibt an, dass keine Durchführungszeit vorhanden ist. Die Einheit für diesen Feldwert wird durch die Eigenschaft "Uhrzeitfeldeinheiten" des Analyse-Layers angegeben. Hinweis: 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 Abhol- 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. Durch die Verwendung von Auftragspaaren können diese zusammengehörigen Aufträge in der entsprechenden Reihenfolge 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. Hinweis: 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 NULL-Werte enthalten. Ein NULL-Wert 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: Minimieren der Gesamt-Fahrzeitüberschreitung unabhängig von höheren Reisekosten für die Fahrzeugflotte, Suchen einer Lösung mit ausgewogenem Verhältnis zwischen Gesamtzeitverstoß und Reisekosten sowie Ignorieren der Gesamt-Fahrzeitüberschreitung und stattdessen Minimieren der Reisekosten für die Fahrzeugflotte. Wenn Sie dem Parameter Gewichtung der Fahrzeitüberschreitung (excess_transit_factor in Python) eine Gewichtung zuweisen, entscheiden Sie sich für eine dieser drei Strategien. 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)	Gibt an, wie wichtig die Reduzierung von Fahrzeitüberschreitungen bei 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. Low—Legt den Schwerpunkt auf die Minimierung der Gesamtlösungskosten und weniger auf die Fahrzeitüberschreitung. Diese Einstellung wird normalerweise von Kurierdiensten verwendet. Da Kurierdienste Pakete und keine Personen befördern, muss die Fahrzeit nicht berücksichtigt werden. Mit dieser Einstellung können Kuriere Auftragspaare in der ordnungsgemäßen Reihenfolge abwickeln und die Gesamtlösungskosten minimieren. Medium—Legt den Schwerpunkt auf ein ausgewogenes Verhältnis zwischen Reduzierung der Fahrzeitüberschreitung und Reduzierung der Gesamtreisekosten. Dies ist der Standardwert. High—Legt den Schwerpunkt auf die kürzeste Fahrzeit zwischen Auftragspaaren und weniger auf die Gesamtreisekosten. Diese Einstellung empfiehlt sich, wenn bei Aufträgen Personen befördert werden und Sie die Fahrzeiten der Personen verkürzen möchten. Ein typisches Beispiel sind Taxiunternehmen.	String
point_barriers (optional)	Legt Punkt-Barrieren fest, die in zwei Typen unterteil sind: Punkt-Barrieren für Einschränkungen und Punkt-Barrieren für Zusatzkosten. Sie schränken das Passieren von Punkten oder Hinzufügen von Impedanz zu Punkten im Netzwerk vorübergehend ein. Die Punkt-Barrieren werden durch ein Feature-Set definiert und anhand der Attributwerte, die Sie für die Punkt-Features angeben, wird festgelegt, ob es sich um Punkt-Barrieren für Einschränkungen oder Punkt-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 Reise völlig beschränkt oder Kosten beim Passieren der Barriere hinzufügt. Es gibt zwei Optionen: Einschränkung (0): Untersagt, dass die Barriere passiert wird. Dies ist der Standardwert. Zusatzkosten (2): Durch Passieren der Barriere erhöhen sich die Netzwerkkosten um den Betrag, der in den Feldern Additional_Time und Additional_Distance angegeben ist. Additional_Time: Wenn BarrierType auf Zusatzkosten festgelegt ist, gibt der Wert des Feldes Additional_Time an, wie viel Zeit 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 festgelegt ist, gibt der Wert des Feldes Additional_Distance an, wie viel Impedanz einer Route hinzugefügt wird, wenn die Route die Barriere passiert. Die Einheit für diesen Feldwert wird mithilfe des Parameters Uhrzeitfeldeinheiten angegeben.	Feature Set
line_barriers (optional)	Gibt Linien-Barrieren an, für die das Passieren vorübergehend eingeschränkt ist. 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)	Legt Polygon-Barrieren fest, die in zwei Typen unterteil sind: Punkt-Barrieren für Einschränkungen und Punkt-Barrieren für skalierte Kosten. Sie schränken das Passieren oder Skalieren der Impedanz für die Teile des Netzwerks ein, die sie abdecken. Die Polygon-Barrieren werden durch ein Feature-Set definiert und anhand der Attributwerte, die Sie für die Polygon-Features angeben, wird festgelegt, ob es sich um Punkt-Barrieren für Einschränkungen oder Punkt-Barrieren für skalierte Kosten 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 Reise völlig beschränkt oder die Kosten für das Passieren der Barriere skaliert. Es gibt zwei Optionen: Einschränkung (0): Untersagt, dass die Barriere an irgend einer Stelle passiert werden kann. Dies ist der Standardwert. Kostenfaktor (1): Skaliert die Impedanz der zugrunde liegenden Kanten, indem diese mit dem Wert der Eigenschaft "Attr_[Impedance]" multipliziert werden. Wenn Kanten teilweise von der Barriere abgedeckt werden, wird die Impedanz aufgeteilt und multipliziert. Scaled_Time: Die zeitbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem in diesem Feld festgelegten Wert multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine skalierte Kostenbarriere ist. Scaled_Distance: Die entfernungsbasierten Impedanzwerte der Kanten, die der Barriere zugrunde liegen, werden mit dem in diesem Feld festgelegten Wert multipliziert. Dieses Feld ist nur relevant, wenn die Barriere eine skalierte Kostenbarriere ist.	Feature Set
time_attribute (optional)	Das Netzwerkkostenattribut, mit dem die Fahrzeit der Netzwerkelemente festgelegt wird. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
distance_attribute (optional)	Das Netzwerkkostenattribut, mit dem die Entfernung der Netzwerkelemente festgelegt wird. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
use_hierarchy_in_analysis (optional)	USE_HIERARCHY—Für die Analyse wird das Hierarchie-Attribut verwendet. Wenn eine Hierarchie verwendet wird, werden vom Solver Kanten einer höheren Rangstufe gegenüber Kanten niedrigerer Rangstufen bevorzugt. Hierarchische Berechnungen sind schneller und können verwendet werden, um zu simulieren, dass ein Fahrer es nach Möglichkeit vorzieht, auf Autobahnen statt auf Landstraßen zu fahren, selbst wenn die Fahrstrecke dann länger ist. Diese Option ist nur dann gültig, wenn das Eingabe-Netzwerk-Dataset ein Hierarchie-Attribut aufweist. NO_HIERARCHY—Für die Analyse wird kein Hierarchie-Attribut verwendet. Wird keine Hierarchie verwendet, ist das Ergebnis eine genaue Route für das Netzwerk-Dataset. 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. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	Boolean
restrictions [restriction,...] (optional)	Gibt an, welche Netzwerkrestriktionsattribute bei der Berechnung beachtet werden. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	String
attribute_parameter_values (optional)	Gibt die Parameterwerte für die Netzwerkattribute an, die über Parameter verfügen. Über zwei der Spalten im Datensatz werden Parameter eindeutig identifiziert und über eine weitere Spalte wird der Parameterwert angegeben. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird. Der Datensatz für Attributparameterwerte 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 durch die Tabellenzeile festgelegt wird. ParameterName: Der Name des Attributparameters, dessen Wert durch die Tabellenzeile festgelegt wird. (Parameter des Typs "Objekt" können mit diesem Werkzeug nicht aktualisiert werden.) ParameterValue: Der Wert, den Sie für den Attributparameter festlegen möchten. Wenn kein Wert angegeben ist, wird der Attributparameterwert 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 und der Punkt wird an der nächstgelegenen Kante bzw. am nächstgelegenen Knoten gefangen. Wenn keine geeignete Position innerhalb der maximale Fangtoleranz gefunden wird, wird das Objekt als nicht verortet gekennzeichnet.	Linear Unit
exclude_restricted_portions_of_the_network (optional)	Gibt an, wo Netzwerkstandorte platziert werden. EXCLUDE—Die Netzwerkstandorte werden nur auf passierbaren Teilen des Netzwerks platziert. Dies verhindert, dass Netzwerkstandorte auf Elementen platziert werden, die Sie aufgrund von Beschränkungen oder Barrieren nicht erreichen können. Stellen Sie vor dem Hinzufügen der Netzwerkstandorte mithilfe dieser Option sicher, dass Sie bereits alle Einschränkungsbarrieren zum Eingabe-Netzwerkanalyse-Layer hinzugefügt haben, um die gewünschten Ergebnisse zu erhalten. Beim Hinzufügen von Barrierenobjekten ist diese Option nicht anwendbar. In solchen Fällen verwenden Sie "#" als Parameterwert. INCLUDE—Die Netzwerkstandorte werden auf allen Elementen des Netzwerks platziert. Die Netzwerkstandorte, die mit dieser Option hinzugefügt werden, sind – wenn sie auf eingeschränkten Elementen platziert werden – möglicherweise während des Berechnungsprozesses nicht erreichbar.	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-Locators beim Laden.	Value Table
populate_route_lines (optional)	Gibt an, ob Linien erstellt werden, die das echte Shape der Routen darstellen. NO_ROUTE_LINES—Für die Ausgaberouten wird kein Shape erstellt. Wenn keine Routenlinien erstellt werden, können keine Wegbeschreibungen berechnet werden. ROUTE_LINES—Die Ausgabe-Routen haben die exakte Form der zugrunde liegenden Netzwerkquellen.	Boolean
route_line_simplification_tolerance (optional)	Die Vereinfachungsentfernung der Routengeometrie. 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. Der Wert dieses Parameters wird überschrieben, wenn Reisemodus (travel_mode in Python) auf einen anderen Wert als "Benutzerdefiniert" festgelegt wird.	Linear Unit
populate_directions (optional)	Gibt an, ob Wegbeschreibungen erstellt werden. DIRECTIONS—Es werden keine Wegbeschreibungen erstellt. Die im Parameter output_directions_name angegebene Feature-Class wird mit abschnittsweisen Anweisungen für jede Route gefüllt. Das Netzwerk-Dataset muss Wegbeschreibungen unterstützen, da sonst bei der Berechnung der Wegbeschreibungen ein Fehler auftritt. NO_DIRECTIONS—Es werden keine Wegbeschreibungen erstellt.	Boolean
directions_language (optional)	Die Sprache, in der Wegbeschreibungen erstellt werden. Die in der Dropdown-Liste verfügbaren Sprachen hängen von den auf dem Computer installierten ArcGIS-Sprachpaketen ab. Wenn Sie dieses Werkzeug als Teil eines Service auf einem separaten Server veröffentlichen möchten, muss das ArcGIS-Sprachpaket für die ausgewählte Sprache auf dem Server installiert sein, 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)	Gibt den Formatierungs-Style von Wegbeschreibungen an. NA Desktop—Druckbare Wegbeschreibung NA Navigation—Wegbeschreibung für ein Navigationsgerät im Fahrzeug NA Campus—Wegbeschreibung für Fußgänger	String
save_output_layer (optional)	Gibt an, ob die Ausgabe einen Netzwerkanalyse-Layer der Ergebnisse umfasst. NO_SAVE_OUTPUT_LAYER—Die Ausgabe umfasst keinen Netzwerkanalyse-Layer der Ergebnisse. SAVE_OUTPUT_LAYER—Die Ausgabe umfasst einen Netzwerkanalyse-Layer der Ergebnisse. Es werden in jedem Fall Standalone-Tabellen und Feature-Classes zurückgegeben. Möglicherweise möchte ein Serveradministrator ebenfalls einen Netzwerkanalyse-Layer ausgeben, um einen Debugging-Vorgang für das Setup und die Ergebnisse des Werkzeugs mit den Network Analyst-Steuerelementen in der ArcGIS Desktop-Umgebung durchzuführen. Dies kann das Debuggen vereinfachen. In ArcGIS 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)	Bestimmt die maximale Verarbeitungszeit bei der Ausführung dieses Werkzeugs als Geoverarbeitungsservice. Sie legen dies aus einem der folgenden zwei Gründe fest: um zu verhindern, dass Ihr Server Probleme berechnet, die mehr Ressourcen oder Verarbeitungszeit erfordern, als Sie bereitstellen möchten, oder um im Rahmen Ihres Geschäftsmodells mehrere Services mit unterschiedlichen VRP-Funktionen zu erstellen. Beispiel: Sie folgen einem Geschäftsmodell mit mehrstufigem Serviceangebot und möchten einen kostenlosen VRP-Service bereitstellen, der maximal fünf Routen pro Berechnung unterstützt, sowie einen weiteren gebührenpflichtigen Service, der mehr als fünf Routen pro Berechnung unterstützt. Zusätzlich zur maximalen Anzahl an Routen können Sie die Anzahl an Aufträgen oder Punkt-Barrieren beschränken, die der Analyse hinzugefügt werden können. Eine andere Möglichkeit zur Steuerung von problematischen Größen besteht in der 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. MAXIMUM POINT BARRIERS—Die maximal zulässige Anzahl an Punkt-Barrieren. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM FEATURES INTERSECTING LINE BARRIERS—Die maximale Anzahl von Quell-Features, die von allen Linien-Barrieren in der Analyse geschnitten werden kann. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM FEATURES INTERSECTING POLYGON BARRIERS—Die maximale Anzahl von Quell-Features, die von allen Polygon-Barrieren in der Analyse geschnitten werden kann. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM ORDERS—Die maximal zulässige Anzahl von Aufträgen in der Analyse. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. MAXIMUM ROUTES—Die maximal zulässige Anzahl von Routen in der Analyse. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist. FORCE HIERARCHY BEYOND DISTANCE—Die maximale geradlinige Entfernung zwischen Aufträgen, bevor das Vehicle Routing Problem mit der Netzwerkhierarchie berechnet wird. Die Einheiten für diesen Wert entsprechen denen im Parameter Distance Field Units.Wenn das Netzwerk kein Hierarchie-Attribut aufweist, wird diese Einschränkung ignoriert. Wenn Hierarchie bei Analyse verwenden aktiviert ist, wird die Hierarchie immer verwendet. Wenn der Parameter Hierarchie bei Analyse verwenden deaktiviert ist und diese Einschränkung einen NULL-Wert aufweist, wird die Hierarchie nicht erzwungen. MAXIMUM ORDERS PER ROUTE—Die maximale Anzahl von Aufträgen, die jeder Route zugewiesen werden können. Bei Überschreitung dieses Grenzwertes wird ein Fehler zurückgegeben. Ein NULL-Wert gibt an, dass kein Grenzwert vorhanden ist.	Value Table
ignore_invalid_order_locations (optional)	Gibt an, ob ungültige Aufträge beim Berechnen des Vehicle Routing Problem ignoriert werden. HALT—Der Berechnungsvorgang ist nicht erfolgreich, wenn ungültige Aufträge erkannt werden. Ein ungültiger Auftrag ist ein Auftrag, den der VRP-Solver nicht erreichen kann. Ein Auftrag kann aus verschiedenen Gründen nicht erreichbar sein, etwa weil er sich in einem unzulässigen Netzwerkelement, überhaupt nicht im Netzwerk oder an einem nicht verbundenen Teil des Netzwerks befindet. Dies ist der Standardwert, der einem Booleschen "False"-Wert entspricht. SKIP—Beim Berechnungsvorgang werden ungültige Aufträge ignoriert, und es wird eine Lösung zurückgegeben, sofern keine anderen Fehler aufgetreten sind.Wenn Sie Routen erstellen und sofort an die Fahrer weitergeben müssen, können Sie bei Bedarf ungültige Aufträge ignorieren, die Berechnung durchführen und die Routen an die Fahrer übermitteln. Lösen Sie als Nächstes alle ungültigen Aufträge aus dem letzten Berechnungsvorgang, und fügen Sie sie zur VRP-Analyse für den nächsten Arbeitstag oder die nächste Arbeitsschicht hinzu. Dieser Wert entspricht einem Booleschen "True"-Wert.	Boolean
travel_mode (optional)	Wählen Sie den Transportmodus für die Analyse aus. CUSTOM kann immer ausgewählt werden. Um andere Namen für Reisemodi anzuzeigen, müssen sie in dem Netzwerk-Dataset vorhanden sein, das im Parameter Network_Dataset angegeben wurde. (Die Funktion arcpy.na.GetTravelModes stellt ein Wörterbuch der Reisemodusobjekte bereit, die in einem Netzwerk-Dataset konfiguriert wurden, und die Eigenschaft name gibt den Namen eines Reisemodusobjekts zurück.) Ein Reisemodus wird in einem Netzwerk-Dataset definiert und stellt Override-Werte für Parameter bereit, die zusammen Reisemodi wie Auto, Lkw, Fußgänger und usw. modellieren. Wenn Sie hier einen Reisemodus auswählen, müssen Sie keine Werte für die folgenden Parameter angeben, die von Werten überschrieben werden, die im Netzwerk-Dataset angegeben wurden: uturn_policy time_attribute distance_attribute use_hierarchy_in_analysis restrictions attribute_parameter_values route_line_simplification_tolerance CUSTOM—Definieren Sie einen Reisemodus, der Ihre spezifischen Anforderungen erfüllt. Bei Auswahl von CUSTOM überschreibt das Werkzeug die oben aufgelisteten Reisemodusparameter nicht. Dies ist der Standardwert.	String
ignore_network_location_fields (optional)	Gibt an, ob die Netzwerkstandortfelder bei der Suche nach Aufträgen, Depots oder Barrieren im Netzwerk berücksichtigt werden. IGNORE—Netzwerkstandortfelder werden bei der Suche der Eingaben im Netzwerk nicht berücksichtigt. Stattdessen werden die Eingaben stets mithilfe einer räumlichen Suche lokalisiert. HONOR—Netzwerkstandortfelder werden bei der Suche der Eingaben im Netzwerk berücksichtigt. Dies ist der Standardwert.	Boolean
time_zone_usage_for_time_fields (optional)	Gibt die Zeitzone der folgenden Datums-/Uhrzeit-Eingabefelder an, die vom Werkzeug unterstützt werden: TimeWindowStart1, TimeWindowEnd1, TimeWindowStart2, TimeWindowEnd2, InboundArriveTime und OutboundDepartTime für Aufträge; TimeWindowStart1, TimeWindowEnd1, TimeWindowStart2 und TimeWindowEnd2 für Depots; EarliestStartTime und LatestStartTime für Routen sowie TimeWindowStart und TimeWindowEnd für Pausen. GEO_LOCAL—Die mit den Aufträgen oder Depots verknüpften Werte für Datum/Uhrzeit befinden sich in der Zeitzone, in der sich die Aufträge und Depots befinden. Bei Routen basieren die Werte für Datum/Uhrzeit auf der Zeitzone, in der sich das Startdepot für die Route befindet. Hat eine Route kein Startdepot, müssen sich alle Aufträge und Depots über alle Routen hinweg in einer einzelnen Zeitzone befinden. Bei Pausen basieren die Werte für Datum/Uhrzeit auf der Zeitzone der Routen. Wenn sich Ihr Depot beispielsweise in einem Gebiet befindet, in dem die Eastern Standard Time gilt, und die Werte des ersten Zeitfensters (angegeben in TimeWindowStart1 und TimeWindowEnd1) 8:00 Uhr und 17:00 Uhr lauten, werden die Zeitfensterwerte als 8:00 Uhr und 17:00 Uhr Eastern Standard Time behandelt. UTC—Die mit den Aufträgen oder Depots verknüpften Datums-/Uhrzeitwerte sind in der koordinierten Weltzeit (UTC) angegeben und basieren nicht auf der Zeitzone, in der sich die Aufträge oder Depots befinden. Wenn sich Ihr Depot beispielsweise in einem Gebiet befindet, in dem die Eastern Standard Time gilt und die Werte des ersten Zeitfensters (angegeben als TimeWindowStart1 und TimeWindowEnd1) 8.00 Uhr und 17.00 Uhr lauten, werden die Zeitfensterwerte als 12.00 Uhr und 21.00 Uhr Eastern Standard Time behandelt, wobei davon ausgegangen wird, dass die Sommerzeit berücksichtigt wird. Es ist hilfreich, die Werte für Datum/Uhrzeit in UTC anzugeben, wenn Sie die Zeitzone nicht kennen, in der sich die Aufträge oder Depots befinden, oder wenn Sie über Aufträge und Depots in mehreren Zeitzonen verfügen und alle Werte für Datum/Uhrzeit gleichzeitig gestartet werden sollen. Die UTC-Option kann nur angewendet werden, wenn Ihr Netzwerk-Dataset ein Zeitzonenattribut definiert. Anderenfalls werden alle Werte für Datum/Uhrzeit stets als Geo local (GEO_LOCAL in Python) verarbeitet.	String
overrides (optional)	Hinweis: Dieser Parameter ist nur für die interne Verwendung vorgesehen.	String
save_route_data (optional)	Gibt an, ob eine .zip-Datei mit einer File-Geodatabase gespeichert werden soll, in der die Eingaben und Ausgaben der Analyse in einem Format vorliegen, das zum Freigeben von Routen-Layern mit ArcGIS Online oder ArcGIS Enterprise verwendet werden kann. In ArcGIS Desktop befindet sich der Standardausgabespeicherort für diese Ausgabedatei im Scratch-Ordner. Sie können den Speicherort des Scratch-Ordners mit arcpy.env.scratchFolder festlegen. SAVE_ROUTE_DATA—Das Werkzeug erstellt ein .zip-Archiv, das einen File-Geodatabase-Workspace mit den Eingaben und Ausgaben der Analyse enthält. NO_SAVE_ROUTE_DATA—Es werden keine Routendaten gespeichert. Dies ist die Standardeinstellung.	Boolean

Abgeleitete Ausgabe

Name	Erläuterung	Datentyp
solve_succeeded	Ein boolescher Wert, der angibt, ob die Berechnung der Vehicle Routing Problem-Analyse erfolgreich war.	Boolean
out_unassigned_stops	Tabelle mit einer Liste der Aufträge, die auf keiner Route besucht werden konnten.	Table
out_stops	Tabelle mit Informationen über Stopps bei Depots, Aufträgen und Unterbrechungen.	Table
out_routes	Eine Feature-Class, die die Fahrer, Fahrzeuge und Fahrzeugroutenpfade in einem Vehicle Routing Problem repräsentiert.	Feature Class
out_directions	Schrittweise Anleitungen, um den Fahrern die Verfolgung ihrer zugewiesenen Routen zu erleichtern.	Feature Class
out_network_analysis_layer	Netzwerkanalyse-Layer mit in den Werkzeugparametern konfigurierten Eigenschaften, der für weitere Analysen oder zum Debuggen in der Karte verwendet werden kann.	File
out_route_data	Eine .zip-Datei mit allen Informationen für eine bestimmte Route.	File

Codebeispiel

SolveVehicleRoutingProblem – Beispiel 1 (Python-Fenster)

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")

SolveVehicleRoutingProblem – Beispiel 2 (eigenständiges Skript)

Im folgenden eigenständigen Python-Skript wird veranschaulicht, wie das Werkzeug SolveVehicleRoutingProblem zum Bereitstellen mehrerer Aufträge für eine Fahrzeugflotte verwendet werden kann.

# 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 Network Analyst license if available. Fail if the Network Analyst license is not available.
    if arcpy.CheckExtension("network") == "Available":
        arcpy.CheckOutExtension("network")
    else:
        raise arcpy.ExecuteError("Network Analyst Extension license is not available.")
    
    #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 occurred on line %i" % tb.tb_lineno)
    print(str(e))

Umgebungen

Aktueller Workspace, Ausgabe-Koordinatensystem

Lizenzinformationen

Basic: Erfordert Network Analyst
Standard: Erfordert Network Analyst
Advanced: Erfordert Network Analyst

Feedback zu diesem Thema?

Zusammenfassung

Vorversion:

Verwendung

Parameter

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Vorsicht:

Hinweis:

Hinweis:

Hinweis:

Abgeleitete Ausgabe

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Hinweis:

Vorsicht:

Hinweis:

Hinweis:

Hinweis:

Abgeleitete Ausgabe

Codebeispiel

Umgebungen

Lizenzinformationen

In diesem Thema