- JSON-Darstellung
- Sendung
- VisitRequest
- LatLng
- Wegpunkt
- Ort
- TimeWindow
- Fahrzeug
- TravelMode
- RouteModifiers
- UnloadingPolicy
- LoadLimit
- Intervall
- LoadCost
- DurationLimit
- DistanceLimit
- BreakRule
- BreakRequest
- FrequencyConstraint
- DurationDistanceMatrix
- Zeile
- TransitionAttributes
- ShipmentTypeIncompatibility
- IncompatibilityMode
- ShipmentTypeRequirement (Anforderungen an den Versandtyp)
- RequirementMode
- PrecedenceRule
Ein Versandmodell enthält eine Reihe von Sendungen, die von einer Gruppe von Fahrzeugen durchgeführt werden müssen und dabei die Gesamtkosten, die sich aus der folgenden Summe ergeben, zu minimieren:
- die Kosten für die Routenplanung der Fahrzeuge (Summe der Kosten pro Gesamtzeit, Kosten pro Fahrtzeit und Fixkosten für alle Fahrzeuge).
- die Strafen für nicht ausgeführte Sendungen.
- die Kosten für die gesamte Dauer der Sendungen
JSON-Darstellung |
---|
{ "shipments": [ { object ( |
Felder | |
---|---|
shipments[] |
Satz von Sendungen, die im Modell ausgeführt werden müssen. |
vehicles[] |
Gruppe von Fahrzeugen, die für Besuche verwendet werden können. |
globalStartTime |
Globaler Beginn und Ende des Modells: Zeiten außerhalb dieses Bereichs können nicht als gültig betrachtet werden. Die Zeitspanne des Modells muss kürzer als ein Jahr sein, d. h., Wenn Sie Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
globalEndTime |
Wenn kein Wert festgelegt ist, wird als Standardwert 00:00:00 UTC, 1. Januar 1971 (d. h. Sekunden: 31536000, Nanosekunden: 0) verwendet. Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
globalDurationCostPerHour |
Die „globale Dauer“ des Gesamtplans ist die Differenz zwischen der frühesten effektiven Startzeit und der letzten effektiven Endzeit aller Fahrzeuge. Nutzende können dieser Menge Kosten pro Stunde zuweisen, um beispielsweise den frühesten Abschluss eines Auftrags zu optimieren. Diese Kosten müssen in derselben Einheit wie |
durationDistanceMatrices[] |
Gibt die im Modell verwendeten Zeit- und Entfernungsmatrizen an. Wenn dieses Feld leer ist, werden je nach Wert des Felds Typische Syntax:
|
durationDistanceMatrixSrcTags[] |
Tags, die die Quellen der Zeit- und Entfernungsmatrizen definieren; Tags entsprechen |
durationDistanceMatrixDstTags[] |
Tags, mit denen die Ziele der Matrizen für Dauer und Entfernung definiert werden; Tags entsprechen |
transitionAttributes[] |
Dem Modell hinzugefügte Übergangsattribute |
shipmentTypeIncompatibilities[] |
Kombinationen von nicht kompatiblen Versandtypen (siehe |
shipmentTypeRequirements[] |
Gruppe von |
precedenceRules[] |
Eine Reihe von Vorrangregeln, die im Modell erzwungen werden müssen. |
maxActiveVehicles |
Beschränkt die maximale Anzahl aktiver Fahrzeuge. Ein Fahrzeug ist aktiv, wenn auf seiner Route mindestens ein Versand durchgeführt wird. Dies kann verwendet werden, um die Anzahl der Routen für den Fall zu begrenzen, dass es weniger Fahrer als Fahrzeuge gibt und der Fuhrpark heterogen ist. Bei der Optimierung wird dann die beste Teilmenge von Fahrzeugen ausgewählt. Muss strikt positiv sein. |
Versand
Der Versand eines einzelnen Artikels von einer Abholstelle zu einer Lieferstelle. Damit die Lieferung als ausgeführt gilt, muss ein einzelnes Fahrzeug einen der Abholorte aufsuchen (und seine Reservekapazitäten entsprechend verringern) und später einen der Lieferorte aufsuchen (und seine Reservekapazitäten entsprechend wieder erhöhen).
JSON-Darstellung |
---|
{ "displayName": string, "pickups": [ { object ( |
Felder | |
---|---|
displayName |
Der benutzerdefinierte Anzeigename der Sendung. Er kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten. |
pickups[] |
Abholoptionen, die mit der Sendung verknüpft sind. Wenn nichts angegeben ist, muss das Fahrzeug nur einen Standort anfahren, der den Lieferungen entspricht. |
deliveries[] |
Gruppe von Lieferalternativen für die Lieferung. Wenn nichts angegeben ist, muss das Fahrzeug nur einen Standort aufsuchen, der den Abholorten entspricht. |
loadDemands |
Anforderungen an die Ladung der Sendung (z. B. Gewicht, Volumen, Anzahl der Paletten usw.) Die Schlüssel in der Zuordnung sollten IDs sein, die den Typ der entsprechenden Ladung beschreiben, idealerweise auch mit den Einheiten. Beispiel: „weight_kg“, „volumen_gallons“, „pallet_count“ usw. Wenn ein bestimmter Schlüssel nicht auf der Karte erscheint, wird die entsprechende Last als null betrachtet. |
allowedVehicleIndices[] |
Die Fahrzeuge, die diese Sendung ausführen können. Wenn das Feld leer ist, kann die Aktion von allen Fahrzeugen ausgeführt werden. Fahrzeuge sind gemäß ihrem Index in der |
costsPerVehicle[] |
Gibt die Kosten an, die anfallen, wenn diese Sendung von jedem Fahrzeug zugestellt wird. Wenn angegeben, muss es ENTWEDER:
Diese Kosten müssen sich in derselben Einheit wie |
costsPerVehicleIndices[] |
Indizes der Fahrzeuge, für die |
pickupToDeliveryAbsoluteDetourLimit |
Gibt die maximale absolute Umwegzeit im Vergleich zum kürzesten Weg von der Abholung zur Zustellung an. Wenn angegeben, muss er ein positiver Wert sein und die Sendung muss mindestens eine Abholung und eine Lieferung enthalten. Es sollte beispielsweise die kürzeste Zeit sein, die von der ausgewählten Abholoption direkt zur ausgewählten Lieferalternative benötigt wird. Dann wird durch das Festlegen von
Wenn für dieselbe Lieferung sowohl relative als auch absolute Grenzwerte angegeben sind, wird für jedes mögliche Paar aus Abholung und Lieferung das restriktivere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisedauer nicht vom Fahrzeug abhängt. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
pickupToDeliveryTimeLimit |
Gibt die maximale Dauer vom Beginn der Abholung bis zum Beginn der Zustellung einer Sendung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten. Das hängt nicht davon ab, welche Alternativen für die Abholung und Lieferung ausgewählt werden, und auch nicht von der Fahrzeuggeschwindigkeit. Dies kann neben maximalen Umwegbeschränkungen angegeben werden: Die Lösung berücksichtigt beide Spezifikationen. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
shipmentType |
Der String zur Angabe eines Typs für diese Sendung ist nicht leer. Mit dieser Funktion können Sie Inkompatibilitäten oder Anforderungen zwischen Unterscheidet sich von |
label |
Gibt ein Label für diese Sendung an. Dieses Label wird in der Antwort im |
ignore |
Wenn wahr, überspringe diese Sendung, wende aber keine Wenn eine Sendung ignoriert wird, tritt ein Validierungsfehler auf, wenn Das Ignorieren einer Sendung, die in |
penaltyCost |
Wenn die Lieferung nicht abgeschlossen wird, wird diese Strafe auf die Gesamtkosten der Routen angerechnet. Ein Versand gilt als abgeschlossen, wenn eine der Abhol- und Lieferoptionen in Anspruch genommen wird. Die Kosten können in derselben Einheit angegeben werden, die für alle anderen kostenbezogenen Felder im Modell verwendet wird. Sie müssen positiv sein. WICHTIG: Wenn diese Strafe nicht angegeben ist, gilt sie als unendlich, d.h., der Versand muss abgeschlossen sein. |
pickupToDeliveryRelativeDetourLimit |
Gibt die maximale relative Umwegzeit im Vergleich zum kürzesten Weg von der Abholung zur Lieferung an. Wenn angegeben, muss der Wert nicht negativ sein und die Sendung muss mindestens eine Abholung und eine Zustellung enthalten. Es sollte beispielsweise die kürzeste Zeit sein, die von der ausgewählten Abholoption direkt zur ausgewählten Lieferalternative benötigt wird. Dann wird durch das Festlegen von
Wenn für dieselbe Sendung sowohl relative als auch absolute Limits angegeben sind, wird für jedes mögliche Abhol-/Lieferpaar das strengere Limit verwendet. Seit Oktober 2017 werden Umwege nur unterstützt, wenn die Reisedauer nicht vom Fahrzeug abhängt. |
VisitRequest
Anfrage für einen Besuch, der von einem Fahrzeug ausgeführt werden kann: Es hat einen geografischen Standort (oder zwei, siehe unten), Öffnungs- und Schließzeiten in Form von Zeitfenstern sowie eine Servicedauer (Zeit, die das Fahrzeug nach Ankunft zum Abholen oder Abgeben der Waren verbracht hat).
JSON-Darstellung |
---|
{ "arrivalLocation": { object ( |
Felder | |
---|---|
arrivalLocation |
Der geografisch Standort, an dem das Fahrzeug bei dieser |
arrivalWaypoint |
Der Wegpunkt, an dem das Fahrzeug ankommt, wenn es diese |
departureLocation |
Der geografische Standort, an dem das Fahrzeug nach Abschluss dieser |
departureWaypoint |
Der Wegpunkt, an dem das Fahrzeug nach Abschluss dieser |
tags[] |
Gibt Tags an, die an die Besuchsanfrage angehängt sind. Leere oder doppelte Strings sind nicht zulässig. |
timeWindows[] |
Zeitfenster, die die Ankunftszeit bei einem Besuch einschränken. Beachten Sie, dass ein Fahrzeug möglicherweise außerhalb der Ankunftszeit abfahren kann, d.h. Ankunftszeit und Dauer müssen nicht innerhalb eines Zeitfensters liegen. Dies kann zu Wartezeiten führen, wenn das Fahrzeug vor Wenn Die Zeitfenster dürfen sich nicht überschneiden, d. h., sie dürfen nicht aneinander angrenzen. Außerdem müssen sie in aufsteigender Reihenfolge angegeben werden.
|
duration |
Dauer des Besuchs, d. h. die Zeit, die das Fahrzeug zwischen Ankunft und Abfahrt verbringt (wird zur möglichen Wartezeit addiert, siehe Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
cost |
Kosten für die Bearbeitung dieser Besuchsanfrage auf einer Fahrzeugroute. So können Sie für jede alternative Abholung oder Lieferung einer Sendung unterschiedliche Kosten bezahlen. Diese Kosten müssen in derselben Einheit wie |
loadDemands |
Ladeanforderungen dieser Besuchsanfrage. Dies entspricht dem Feld |
visitTypes[] |
Gibt die Arten der Besuche an. So kann zusätzliche Zeit für ein Fahrzeug für diesen Besuch eingeplant werden (siehe Ein Typ kann nur einmal vorkommen. |
label |
Gibt ein Label für dieses |
LatLng
Ein Objekt, das ein Paar aus Breiten- und Längengrad darstellt. Es wird als Paar von Double-Werten ausgedrückt, die für den Breitengrad und den Längengrad stehen. Sofern nicht anders angegeben, muss dieses Objekt dem WGS84-Standard entsprechen. Die Werte müssen innerhalb normalisierter Bereiche liegen.
JSON-Darstellung |
---|
{ "latitude": number, "longitude": number } |
Felder | |
---|---|
latitude |
Der Breitengrad in Grad. Er muss im Bereich [-90,0, +90,0] liegen. |
longitude |
Der Längengrad in Grad. Er muss im Bereich [-180,0, +180,0] liegen. |
Zwischenstopp
Schließt einen Wegpunkt ein. Wegpunkte kennzeichnen die Ankunfts- und Abfahrtsorte von VisitRequests sowie Start- und Endpositionen von Fahrzeugen.
JSON-Darstellung |
---|
{ "sideOfRoad": boolean, // Union field |
Felder | |
---|---|
sideOfRoad |
Optional. Gibt an, dass der Standort dieses Wegpunkts das Fahrzeug bevorzugt an einer bestimmten Straßenseite halten soll. Wenn Sie diesen Wert festlegen, verläuft die Route durch den Standort, sodass das Fahrzeug an der Straßenseite anhalten kann, zu der der Standort gewichtet ist. Diese Option ist für die Mobilitätsform „WALKING“ nicht verfügbar. |
Union-Feld location_type . Verschiedene Möglichkeiten, einen Standort darzustellen. Für location_type ist nur einer der folgenden Werte zulässig: |
|
location |
Ein Punkt, der mithilfe geografischer Koordinaten angegeben wird, einschließlich einer optionalen Richtung. |
placeId |
Die POI-Orts-ID, die mit dem Wegpunkt verknüpft ist. |
Standort
Umfasst einen Standort (einen geografischen Punkt und eine optionale Überschrift).
JSON-Darstellung |
---|
{
"latLng": {
object ( |
Felder | |
---|---|
latLng |
Die geografischen Koordinaten des Wegpunkts. |
heading |
Die Kompassausrichtung, die der Richtung des Verkehrsflusses zugeordnet ist. Mit diesem Wert wird die Straßenseite angegeben, auf der ein- und aussteigen soll. Die Richtung kann zwischen 0 und 360 liegen, wobei 0 eine Richtung nach Norden, 90 eine Richtung nach Osten usw. angibt. |
TimeWindow
Zeitfenster beschränken die Uhrzeit eines Ereignisses, z. B. die Ankunftszeit bei einem Besuch oder die Start- und Endzeit eines Fahrzeugs.
Die festen Zeitfenstergrenzen startTime
und endTime
erzwingen den frühesten und spätesten Zeitpunkt des Ereignisses, sodass startTime <= event_time <=
endTime
. Die Untergrenze des weichen Zeitfensters (softStartTime
) drückt eine Präferenz für das Ereignis aus, das am oder nach dem softStartTime
eintritt, indem Kosten proportional zur Dauer vor dem Ereignis „softStartTime“ anfallen. Die obere Grenze des weichen Zeitfensters, softEndTime
, gibt an, dass das Ereignis am oder vor softEndTime
stattfinden soll. Die Kosten sind dann proportional dazu, wie lange nach softEndTime
das Ereignis eintritt. startTime
, endTime
, softStartTime
und softEndTime
müssen innerhalb der globalen Zeitbeschränkungen liegen (siehe ShipmentModel.global_start_time
und ShipmentModel.global_end_time
) und Folgendes berücksichtigen:
0 <= `startTime` <= `endTime` and
0 <= `startTime` <= `softStartTime` and
0 <= `softEndTime` <= `endTime`.
JSON-Darstellung |
---|
{ "startTime": string, "endTime": string, "softStartTime": string, "softEndTime": string, "costPerHourBeforeSoftStartTime": number, "costPerHourAfterSoftEndTime": number } |
Felder | |
---|---|
startTime |
Die Startzeit des schweren Zeitfensters. Wenn kein Wert angegeben ist, wird er auf Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
endTime |
Das Ende des Zeitfensters. Wenn kein Wert angegeben ist, wird er auf Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
softStartTime |
Die Startzeit des Zeitfensters. Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
softEndTime |
Die weiche Endzeit des Zeitfensters. Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
costPerHourBeforeSoftStartTime |
Dieser Betrag wird den anderen Kosten im Modell hinzugefügt, wenn das Ereignis vor dem „softStartTime“ eintritt. Die Berechnung erfolgt so:
Dieser Wert muss positiv sein und das Feld kann nur festgelegt werden, wenn softStartTime festgelegt wurde. |
costPerHourAfterSoftEndTime |
Diese Kosten pro Stunde werden den anderen Kosten im Modell hinzugefügt, wenn das Ereignis nach
Diese Kosten müssen positiv sein. Das Feld kann nur festgelegt werden, wenn |
Fahrzeug
Modelliert ein Fahrzeug bei einem Versandproblem. Wenn ein Versandproblem gelöst wird, wird für dieses Fahrzeug eine Route erstellt, die bei startLocation
beginnt und um endLocation
endet. Eine Route besteht aus einer Folge von Besuchen (siehe ShipmentRoute
).
JSON-Darstellung |
---|
{ "displayName": string, "travelMode": enum ( |
Felder | |
---|---|
displayName |
Der benutzerdefinierte Anzeigename des Fahrzeugs. Sie kann bis zu 63 Zeichen lang sein und UTF-8-Zeichen enthalten. |
travelMode |
Die Mobilitätsform, die sich auf die für das Fahrzeug nutzbaren Straßen und die Geschwindigkeit auswirkt. Siehe auch |
routeModifiers |
Eine Reihe von Bedingungen, die erfüllt werden müssen und sich darauf auswirken, wie Routen für das jeweilige Fahrzeug berechnet werden. |
startLocation |
Geografische Position, an der das Fahrzeug startet, bevor es Sendungen abholt. Wenn keine Angabe erfolgt, beginnt das Fahrzeug bei der ersten Abholung. Wenn das Versandmodell Matrizen für Dauer und Entfernung enthält, darf |
startWaypoint |
Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug startet, bevor eine Sendung abgeholt wird. Wenn weder |
endLocation |
Geografische Position, an der das Fahrzeug endet, nachdem es seine letzte |
endWaypoint |
Wegpunkt, der einen geografischen Standort darstellt, an dem das Fahrzeug endet, nachdem es seine letzte |
startTags[] |
Gibt Tags an, die am Anfang der Route des Fahrzeugs angebracht sind. Leere oder doppelte Strings sind nicht zulässig. |
endTags[] |
Gibt Tags an, die am Ende der Route des Fahrzeugs angehängt sind. Leere oder doppelte Strings sind nicht zulässig. |
startTimeWindows[] |
Zeitfenster, in denen das Fahrzeug vom Startort losfahren kann. Sie müssen innerhalb der globalen Zeitlimits liegen (siehe Zeitfenster, die zum selben wiederholten Feld gehören, dürfen sich nicht überschneiden. Sie müssen also nicht aneinandergrenzen und in chronologischer Reihenfolge angeordnet sein.
|
endTimeWindows[] |
Zeitfenster, in denen das Fahrzeug am Zielort ankommen kann. Sie müssen innerhalb der globalen Zeitbeschränkungen liegen (siehe Felder „ Zeitfenster, die zum selben wiederholten Feld gehören, dürfen sich nicht überschneiden. Sie müssen also nicht aneinandergrenzen und in chronologischer Reihenfolge angeordnet sein.
|
unloadingPolicy |
Die Richtlinie zum Entladen wird für das Fahrzeug erzwungen. |
loadLimits |
Kapazitäten des Fahrzeugs (z. B. Gewicht, Volumen, Anzahl der Paletten) Die Schlüssel in der Zuordnung sind die IDs des Ladetyps, die mit den Schlüsseln im Feld |
costPerHour |
Fahrzeugkosten: Alle Kosten müssen in derselben Einheit wie Kosten pro Stunde der Fahrzeugroute. Diese Kosten werden auf die Gesamtzeit der Route angewendet und umfassen Fahrtzeit, Wartezeit und Besuchszeit. Die Verwendung von |
costPerTraveledHour |
Kosten pro zurückgelegte Stunde der Fahrzeugroute. Diese Kosten werden nur auf die Fahrzeit der Route angewendet (d. h. die in |
costPerKilometer |
Kosten pro Kilometer der Fahrzeugroute. Diese Kosten werden auf die in der |
fixedCost |
Pauschalkosten, die anfallen, wenn dieses Fahrzeug für die Bearbeitung einer Sendung verwendet wird. |
usedIfRouteIsEmpty |
Dieses Feld gilt nur für Fahrzeuge, deren Route keine Sendungen bedient. Gibt an, ob das Fahrzeug in diesem Fall als gebraucht gilt oder nicht. Wenn „wahr“ festgelegt ist, fährt das Fahrzeug von seinem Start- zum Endort, auch wenn es keine Sendungen abwickelt. Die Zeit- und Entfernungskosten für die Fahrt vom Start- zum Endort werden berücksichtigt. Andernfalls wird das Fahrzeug nicht vom Start bis zum Zielort bewegt und für dieses Fahrzeug sind keine |
routeDurationLimit |
Das Limit wird auf die Gesamtdauer der Route des Fahrzeugs angewendet. In einer bestimmten |
travelDurationLimit |
Die Beschränkung gilt für die Reisedauer der Route des Fahrzeugs. In einem bestimmten |
routeDistanceLimit |
Beschränkung, die auf die Gesamtstrecke der Route des Fahrzeugs angewendet wird. In einer bestimmten |
extraVisitDurationForVisitType |
Hier wird eine Zuordnung von Strings vom Typ „visitTypes“ zu Zeiträumen angegeben. Die Dauer ist zusätzlich zu Wenn eine Besuchsanfrage mehrere Typen aufweist, wird für jeden Typ in der Karte eine Dauer hinzugefügt. |
breakRule |
Beschreibt den Pausenzeitplan, der für dieses Fahrzeug erzwungen werden soll. Wenn das Feld leer ist, werden für dieses Fahrzeug keine Pausen geplant. |
label |
Gibt ein Label für dieses Fahrzeug an. Dieses Label wird in der Antwort als |
ignore |
Falls wahr, muss Wenn eine Sendung von einem ignorierten Fahrzeug in Wenn ein Versand von einem ignorierten Fahrzeug in |
travelDurationMultiple |
Gibt einen multiplikativen Faktor an, mit dem die Fahrtzeit dieses Fahrzeugs erhöht oder verringert werden kann. Wenn Sie diesen Wert beispielsweise auf 2,0 festlegen, ist dieses Fahrzeug langsamer und die Fahrtzeiten sind doppelt so lang wie bei Standardfahrzeugen. Dieser Multiplikator wirkt sich nicht auf die Besuchsdauer aus. Es wirkt sich auf die Kosten aus, wenn WARNUNG: Die Fahrtzeiten werden nach Anwendung dieses Multiplikators, aber vor der Ausführung numerischer Vorgänge auf die nächste Sekunde gerundet. Ein kleiner Multiplikator kann daher zu einem Genauigkeitsverlust führen. Weitere Informationen finden Sie unter |
TravelMode
Mobilitätsformen, die von Fahrzeugen genutzt werden können.
Diese sollten eine Teilmenge der bevorzugten Mobilitätsarten der Google Maps Platform Routes API sein. Weitere Informationen finden Sie unter https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode.
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
Nicht angegebene Mobilitätsform, entspricht DRIVING . |
DRIVING |
Mobilitätsform, die der Route entspricht (Auto, ...). |
WALKING |
Mobilitätsform, die der Wegbeschreibung für Fußgänger entspricht. |
RouteModifiers
Umfasst eine Reihe optionaler Bedingungen, die bei der Berechnung von Fahrzeugrouten erfüllt werden müssen. Dies entspricht RouteModifiers
in der Google Maps Platform Routes Preferred API. Weitere Informationen finden Sie unter https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.
JSON-Darstellung |
---|
{ "avoidTolls": boolean, "avoidHighways": boolean, "avoidFerries": boolean, "avoidIndoor": boolean } |
Felder | |
---|---|
avoidTolls |
Gibt an, ob Mautstraßen gegebenenfalls vermieden werden. Es werden Routen bevorzugt, die keine Mautstraßen enthalten. Gilt nur für motorisierte Fortbewegungsarten. |
avoidHighways |
Gibt an, ob Autobahnen vermieden werden sollen, sofern dies sinnvoll ist. Vorzug wird Routen gegeben, die keine Autobahnen enthalten. Gilt nur für motorisierte Fortbewegungsarten. |
avoidFerries |
Gibt an, ob Fähren nach Möglichkeit vermieden werden sollen. Vorzug wird Routen eingeräumt, die keine Fahrten mit Fähren enthalten. Gilt nur für motorisierte Fortbewegungsarten. |
avoidIndoor |
Optional. Gibt an, ob das Fahren in Innenräumen angemessen ist. Routen, die keine Indoor-Navigationssysteme enthalten, haben Vorrang. Gilt nur für die Mobilitätsform |
UnloadingPolicy
Richtlinie zum Entladen eines Fahrzeugs. Gilt nur für Sendungen mit Abholung und Lieferung.
Andere Sendungen können unabhängig von unloadingPolicy
an beliebiger Stelle auf der Route erfolgen.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
Unbekannte Entladerichtlinie; Lieferungen müssen unmittelbar nach der entsprechenden Abholung erfolgen. |
LAST_IN_FIRST_OUT |
Die Lieferungen müssen in umgekehrter Reihenfolge der Abholungen erfolgen. |
FIRST_IN_FIRST_OUT |
Lieferungen müssen in derselben Reihenfolge wie die Abholung erfolgen |
LoadLimit
Definiert eine Traglast, die für ein Fahrzeug gilt, z. B. „Dieser Lkw darf nur bis zu 3.500 kg tragen“. loadLimits
ansehen.
JSON-Darstellung |
---|
{ "softMaxLoad": string, "costPerUnitAboveSoftMax": number, "startLoadInterval": { object ( |
Felder | |
---|---|
softMaxLoad |
Ein weiches Limit für die Auslastung. |
costPerUnitAboveSoftMax |
Wenn die Auslastung auf der Route dieses Fahrzeugs jemals |
startLoadInterval |
Das zulässige Ladeintervall des Fahrzeugs zu Beginn der Route. |
endLoadInterval |
Das zulässige Ladeintervall des Fahrzeugs am Ende der Route. |
maxLoad |
Die maximal zulässige Auslastung. |
costPerKilometer |
Kosten für das Verschieben einer Ladungseinheit über einen Kilometer für dieses Fahrzeug. Dies kann als Proxy für den Kraftstoffverbrauch verwendet werden: Wenn die Last ein Gewicht (in Newton) ist, hat die Last × Kilometer die Dimension einer Energie. |
costPerTraveledHour |
Kosten für die Fahrt mit einer Ladung während einer Stunde für dieses Fahrzeug. |
Intervall
Intervall der zulässigen Lademengen.
JSON-Darstellung |
---|
{ "min": string, "max": string } |
Felder | |
---|---|
min |
Eine akzeptable Mindestlast. Muss ≥ 0 sein. Wenn beide angegeben sind, muss |
max |
Maximale akzeptable Last. Muss ≥ 0 sein. Wenn keine Angabe gemacht wird, ist die maximale Auslastung durch diese Nachricht nicht eingeschränkt. Wenn beide angegeben sind, muss |
LoadCost
Die Kosten für die Übertragung einer Ladungseinheit während einer Transition
. Für eine bestimmte Last berechnen sich die Kosten aus zwei Teilen:
- min(load,
loadThreshold
) ×costPerUnitBelowThreshold
- max(0, load -
loadThreshold
) *costPerUnitAboveThreshold
Bei diesen Kosten wird es bevorzugt, hohe Anforderungen zuerst zu liefern oder gleichzeitig hohe Anforderungen zuletzt abzudecken. Wenn ein Fahrzeug beispielsweise
load_limit {
key: "weight"
value {
costPerKilometer {
loadThreshold: 15
costPerUnitBelowThreshold: 2.0
costPerUnitAboveThreshold: 10.0
}
}
}
und die Route lautet „Start“, „Abholung“, „Abholung“, „Lieferung“, „Lieferung“ und „Ende“ mit Übergängen:
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
Dann betragen die durch LoadCost
anfallenden Kosten (cost_below * load_below * Kilometer + cost_above * load_above * kms)
- Übergang 0: 0,0
- Übergang 1: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
- Übergang 2: 2,0 × 15 × 1,0 + 10,0 × (20 − 15) × 1,0 = 80,0
- Übergang 3: 2,0 * 10 * 1,0 + 10,0 * 0 * 1,0 = 20,0
- transition 4: 0.0
Der LoadCost
für die gesamte Route beträgt also 120,0.
Wenn die Route jedoch so aussieht: Start, Abholung, Zustellung, Abholung, Zustellung, Ende, mit Übergängen:
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
travelDistanceMeters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
travelDistanceMeters: 1000.0 }
dann betragen die durch LoadCost
entstehenden Kosten
- Übergang 0: 0,0
- Übergang 1: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
- transition 2: 0.0
- Übergang 3: 2,0 × 10 × 1,0 + 10,0 × 0 × 1,0 = 20,0
- transition 4: 0.0
Hier beträgt der LoadCost
über die Route 40,0.
LoadCost
macht Lösungen mit stark ausgelasteten Übergängen teurer.
JSON-Darstellung |
---|
{ "loadThreshold": string, "costPerUnitBelowThreshold": number, "costPerUnitAboveThreshold": number } |
Felder | |
---|---|
loadThreshold |
Lastbetrag, ab dem sich die Kosten für das Verschieben einer Lasteinheit von „costPerUnitBelowThreshold“ in „costPerUnitAboveThreshold“ ändern“. Muss >= 0 sein. |
costPerUnitBelowThreshold |
Kosten für das Verschieben einer Lasteinheit für jede Einheit zwischen 0 und Schwellenwert. Muss ein endlicher Wert und größer als 0 sein. |
costPerUnitAboveThreshold |
Kosten für das Verschieben einer Lasteinheit für jede Einheit über dem Schwellenwert. Im Sonderfall „Schwellenwert = 0“ handelt es sich um eine fixe Kostenpauschale pro Einheit. Muss ein endlicher Wert sein und >= 0. |
DurationLimit
Ein Limit, das die maximale Dauer der Route eines Fahrzeugs definiert. Sie kann hart oder weich sein.
Wenn ein Feld für den flexiblen Grenzwert definiert ist, müssen sowohl der Grenzwert für den flexiblen Maximalwert als auch die zugehörigen Kosten gemeinsam definiert werden.
JSON-Darstellung |
---|
{ "maxDuration": string, "softMaxDuration": string, "quadraticSoftMaxDuration": string, "costPerHourAfterSoftMax": number, "costPerSquareHourAfterQuadraticSoftMax": number } |
Felder | |
---|---|
maxDuration |
Ein starres Limit, das die Dauer auf maximal maxDuration beschränkt. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
softMaxDuration |
Bei einem weichen Limit, das keine maximale Dauer erzwingt, fallen bei einem Verstoß für die Route Kosten an. Diese Kosten summieren sich zu den anderen im Modell definierten Kosten mit derselben Einheit. Falls angegeben, darf Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
quadraticSoftMaxDuration |
Bei einem weichen Limit, das keine maximale Dauer erzwingt, fallen bei einem Verstoß für die Route Kosten mit quadratischer Dauer an. Diese Kosten werden mit anderen im Modell definierten Kosten mit derselben Einheit addiert. Falls angegeben, darf
Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
costPerHourAfterSoftMax |
Kosten pro Stunde, die anfallen, wenn der Grenzwert von
Die Kosten dürfen nicht negativ sein. |
costPerSquareHourAfterQuadraticSoftMax |
Die Kosten pro Quadratstunde, die beim Verstoß gegen den Grenzwert von Die zusätzlichen Kosten sind 0, wenn die Dauer unter dem Grenzwert liegt. Andernfalls hängen die Kosten wie folgt von der Dauer ab:
Die Kosten dürfen nicht negativ sein. |
DistanceLimit
Ein Limit, das eine maximale Strecke definiert, die zurückgelegt werden kann. Sie kann entweder hart oder weich sein.
Wenn ein weiches Limit definiert ist, müssen sowohl softMaxMeters
als auch costPerKilometerAboveSoftMax
definiert werden und nicht negativ sein.
JSON-Darstellung |
---|
{ "maxMeters": string, "softMaxMeters": string, "costPerKilometerBelowSoftMax": number, "costPerKilometerAboveSoftMax": number } |
Felder | |
---|---|
maxMeters |
Ein fester Grenzwert, der den Abstand auf maximal maxMeters beschränkt. Der Grenzwert darf nicht negativ sein. |
softMaxMeters |
Ein weiches Limit, das keine maximale Entfernung erzwingt, aber bei einem Verstoß zu Kosten führt, die sich mit anderen im Modell definierten Kosten mit derselben Einheit addieren. Falls definiert, muss „softMaxMeters“ kleiner als „maxMeters“ sein und darf nicht negativ sein. |
costPerKilometerBelowSoftMax |
Die Kosten pro angefallenem Kilometer werden mit folgender Formel um bis zu
Diese Kosten werden in |
costPerKilometerAboveSoftMax |
Kosten pro Kilometer, wenn die Entfernung das Limit von
Die Kosten dürfen nicht negativ sein. |
BreakRule
Regeln zum Generieren von Zeitpausen für ein Fahrzeug (z.B. Mittagspausen). Eine Pause ist ein zusammenhängender Zeitraum, in dem das Fahrzeug an seiner aktuellen Position inaktiv bleibt und keine Besuche durchführen kann. Es kann zu einer Unterbrechung kommen:
- während der Reise zwischen zwei Besuchen (einschließlich der Zeit unmittelbar vor oder unmittelbar nach einem Besuch, aber nicht während eines Besuchs). In diesem Fall wird die entsprechende Laufzeit zwischen den Besuchen verlängert.
- oder vor dem Start des Fahrzeugs (das Fahrzeug wird möglicherweise nicht mitten in einer Pause gestartet), in diesem Fall hat es keinen Einfluss auf die Startzeit des Fahrzeugs.
- oder nach dem Fahrzeugende (ditto mit der Endzeit des Fahrzeugs).
JSON-Darstellung |
---|
{ "breakRequests": [ { object ( |
Felder | |
---|---|
breakRequests[] |
Reihenfolge der Pausen Weitere Informationen finden Sie in der Nachricht |
frequencyConstraints[] |
Es können mehrere |
BreakRequest
Die Reihenfolge der Pausen für jedes Fahrzeug (d.h. ihre Anzahl und Reihenfolge) muss im Voraus bekannt sein. Die wiederholten BreakRequest
definieren diese Sequenz in der Reihenfolge, in der sie auftreten müssen. Die Zeitfenster (earliestStartTime
/ latestStartTime
) dürfen sich überschneiden, müssen aber mit der Bestellung kompatibel sein (dies wird geprüft).
JSON-Darstellung |
---|
{ "earliestStartTime": string, "latestStartTime": string, "minDuration": string } |
Felder | |
---|---|
earliestStartTime |
Erforderlich. Untere Grenze (einschließlich) des Beginns der Pause. Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
latestStartTime |
Erforderlich. Obergrenze (einschließlich) für den Beginn der Pause. Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: |
minDuration |
Erforderlich. Minimale Dauer der Pause Muss positiv sein. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
FrequencyConstraint
Die Häufigkeit und Dauer der oben angegebenen Pausen kann weiter eingeschränkt werden, indem eine Mindestpausenhäufigkeit festgelegt wird, z. B. „Mindestens eine Stunde alle 12 Stunden eine Pause machen“. Angenommen, dies kann als „Innerhalb eines gleitenden Zeitfensters von 12 Stunden muss es mindestens eine Pause von mindestens einer Stunde geben“ interpretiert werden, würde dieses Beispiel in die folgende FrequencyConstraint
übersetzt:
{
minBreakDuration { seconds: 3600 } # 1 hour.
maxInterBreakDuration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
Bei der Zeit und Dauer der Werbeunterbrechungen in der Lösung werden alle diese Einschränkungen berücksichtigt, zusätzlich zu den Zeitfenstern und Mindestdauern, die bereits in der BreakRequest
angegeben sind.
Ein FrequencyConstraint
kann in der Praxis auch für nicht aufeinanderfolgende Unterbrechungen gelten. Im folgenden Zeitplan wird beispielsweise das Beispiel „1h alle 12h“ berücksichtigt:
04:00 vehicle start
.. performing travel and visits ..
09:00 1 hour break
10:00 end of the break
.. performing travel and visits ..
12:00 20-min lunch break
12:20 end of the break
.. performing travel and visits ..
21:00 1 hour break
22:00 end of the break
.. performing travel and visits ..
23:59 vehicle end
JSON-Darstellung |
---|
{ "minBreakDuration": string, "maxInterBreakDuration": string } |
Felder | |
---|---|
minBreakDuration |
Erforderlich. Mindestdauer der Werbeunterbrechung für diese Einschränkung. Nicht negativ. Siehe Beschreibung von Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
maxInterBreakDuration |
Erforderlich. Maximale zulässige Spanne eines Zeitintervalls auf der Route, das nicht mindestens teilweise eine Pause von Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
DurationDistanceMatrix
Gibt eine Matrix für die Dauer und die Entfernung zwischen Besuchs- und Fahrzeugstartstandorten und Zielstandorten an.
JSON-Darstellung |
---|
{
"rows": [
{
object ( |
Felder | |
---|---|
rows[] |
Gibt die Zeilen der Matrix für Dauer und Entfernung an. Es muss so viele Elemente wie |
vehicleStartTag |
Tag, das angibt, für welche Fahrzeuge diese Matrix mit Dauer und Entfernung gilt. Wenn das Feld leer ist, gilt dies für alle Fahrzeuge und es kann nur eine einzige Matrix geben. Jeder Fahrzeugstart muss genau einer Matrix entsprechen, d.h. genau eines der Alle Matrizen müssen eine unterschiedliche |
Zeile
Gibt eine Zeile mit der Matrix für Dauer und Distanz an.
JSON-Darstellung |
---|
{ "durations": [ string ], "meters": [ number ] } |
Felder | |
---|---|
durations[] |
Dauerwerte für eine bestimmte Zeile. Es muss dieselbe Anzahl an Elementen wie Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
meters[] |
Entfernungswerte für eine bestimmte Zeile. Wenn sich keine Kosten oder Einschränkungen auf Entfernungen im Modell beziehen, kann dieses Feld leer bleiben. Andernfalls muss es so viele Elemente wie |
TransitionAttributes
Gibt Attribute von Übergängen zwischen zwei aufeinanderfolgenden Besuchen auf einer Route an. Für dieselbe Umstellung können mehrere TransitionAttributes
gelten. In diesem Fall werden alle zusätzlichen Kosten addiert und die strengste Einschränkung oder das strengste Limit angewendet (entsprechend der natürlichen „AND“-Semantik).
JSON-Darstellung |
---|
{
"srcTag": string,
"excludedSrcTag": string,
"dstTag": string,
"excludedDstTag": string,
"cost": number,
"costPerKilometer": number,
"distanceLimit": {
object ( |
Felder | |
---|---|
srcTag |
Tags, die die (src->dst)-Übergänge definieren, auf die diese Attribute angewendet werden. Ein Quellbesuch oder Fahrzeugstart wird nur dann als übereinstimmend eingestuft, wenn |
excludedSrcTag |
|
dstTag |
Ein Zielbesuch oder ein Fahrzeugende stimmt überein, wenn |
excludedDstTag |
|
cost |
Gibt die Kosten für diese Umstellung an. Diese Einheit entspricht allen anderen Kosten im Modell und darf nicht negativ sein. Sie wird auf alle anderen bestehenden Kosten aufgeschlagen. |
costPerKilometer |
Gibt die Kosten pro Kilometer an, die auf die zurückgelegte Strecke bei dieser Umstellung angewendet werden. Die Summe ergibt alle |
distanceLimit |
Gibt eine Grenze für die zurückgelegte Strecke an, die während dieses Übergangs zurückgelegt wird. Seit Juni 2021 werden nur noch Softlimits unterstützt. |
delay |
Gibt die Verzögerung an, die bei der Durchführung dieser Umstellung auftritt. Diese Verzögerung tritt immer nach dem Ende des Quellbesuchs und vor Beginn des Zielbesuchs auf. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
ShipmentTypeIncompatibility
Gibt Inkompatibilitäten zwischen Sendungen in Abhängigkeit von ihrem Versandtyp an. Die Anzeige inkompatibler Sendungen auf derselben Route ist je nach Inkompatibilitätsmodus eingeschränkt.
JSON-Darstellung |
---|
{
"types": [
string
],
"incompatibilityMode": enum ( |
Felder | |
---|---|
types[] |
Liste der inkompatiblen Typen. Zwei Sendungen mit unterschiedlichen |
incompatibilityMode |
Modus, der auf die Inkompatibilität angewendet wird. |
IncompatibilityMode
Mobilitätsformen, mit denen das Auftreten inkompatibler Sendungen auf derselben Route eingeschränkt werden.
Enums | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
Nicht angegebener Inkompatibilitätsmodus. Dieser Wert sollte niemals verwendet werden. |
NOT_PERFORMED_BY_SAME_VEHICLE |
In diesem Modus können zwei Sendungen mit inkompatiblen Typen nicht dasselbe Fahrzeug teilen. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
Für zwei Sendungen mit inkompatiblen Typen mit dem Inkompatibilitätsmodus
|
ShipmentTypeRequirement
Hier werden die Anforderungen an Sendungen basierend auf ihrem shipmentType angegeben. Die Details der Anforderung werden durch den Anforderungsmodus definiert.
JSON-Darstellung |
---|
{
"requiredShipmentTypeAlternatives": [
string
],
"dependentShipmentTypes": [
string
],
"requirementMode": enum ( |
Felder | |
---|---|
requiredShipmentTypeAlternatives[] |
Liste alternativer Versandtypen, die von der |
dependentShipmentTypes[] |
Für alle Sendungen mit einem Typ im Feld HINWEIS: Anforderungsketten, die davon abhängen, ein |
requirementMode |
Modus wurde auf die Anforderung angewendet. |
RequirementMode
Modi, die das Aussehen abhängiger Sendungen auf einer Route definieren.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
Nicht angegebener Anforderungsmodus. Dieser Wert sollte niemals verwendet werden. |
PERFORMED_BY_SAME_VEHICLE |
In diesem Modus müssen alle „abhängigen“ Sendungen dasselbe Fahrzeug wie mindestens eine ihrer „erforderlichen“ Sendungen nutzen. |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
Im Modus Für die Abholung einer „abhängigen“ Sendung muss daher Folgendes angegeben sein:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
Wie zuvor, mit der Ausnahme, dass bei den „abhängigen“ Sendungen zum Zeitpunkt der Lieferung eine „erforderliche“ Sendung im Fahrzeug vorhanden sein muss. |
PrecedenceRule
Eine Vorrangregel zwischen zwei Ereignissen (jedes Ereignis ist die Abholung oder Zustellung einer Sendung): Das „zweite“ Ereignis muss mindestens offsetDuration
nach Beginn des ersten Ereignisses beginnen.
Mehrere Rangfolgen können sich auf dieselben (oder verwandten) Ereignisse beziehen, z.B. „Abholung von B erfolgt nach Lieferung von A“ und „Abholung von C erfolgt nach Abholung von B“.
Außerdem gelten Vorrangregeln nur, wenn beide Sendungen ausgeführt werden. Andernfalls werden sie ignoriert.
JSON-Darstellung |
---|
{ "firstIsDelivery": boolean, "secondIsDelivery": boolean, "offsetDuration": string, "firstIndex": integer, "secondIndex": integer } |
Felder | |
---|---|
firstIsDelivery |
Gibt an, ob das erste Ereignis eine Übermittlung ist. |
secondIsDelivery |
Gibt an, ob das „zweite“ Ereignis eine Zustellung ist. |
offsetDuration |
Die Zeitverschiebung zwischen dem ersten und dem zweiten Ereignis. Sie kann negativ sein. Die Dauer in Sekunden mit bis zu neun Nachkommastellen und am Ende mit " |
firstIndex |
Versandindex des „ersten“ Ereignisses. Dieses Feld muss angegeben werden. |
secondIndex |
Versandindex des Ereignisses „second“. Dieses Feld muss angegeben werden. |