OptimizeToursResponse

Antwort nach der Lösung eines Problems zur Optimierung der Tour mit den Routen, denen jedes Fahrzeug folgt, den übersprungenen Sendungen und den Gesamtkosten der Lösung.

JSON-Darstellung 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "metrics": {
    object (Metrics)
  }
}
Felder
routes[]

object (ShipmentRoute)

Für jedes Fahrzeug berechnete Routen; die i-te Route entspricht dem i-ten Fahrzeug im Modell.
requestLabel

string

Kopie der OptimizeToursRequest.label, falls in der Anfrage ein Label angegeben wurde.
skippedShipments[]

object (SkippedShipment)

Liste aller übersprungenen Sendungen.
validationErrors[]

object (OptimizeToursValidationError)

Liste aller Validierungsfehler, die unabhängig erkannt wurden. Weitere Informationen finden Sie in der Erklärung zu OptimizeToursValidationError unter „MEHRERE FEHLER“. Anstelle von Fehlern enthält diese Liste Warnungen, wenn solvingMode = DEFAULT_SOLVE ist.
metrics

object (Metrics)

Messwerte zu Dauer, Entfernung und Nutzung für diese Lösung.

OptimizeToursValidationError

Beschreibt einen Fehler oder eine Warnung, die bei der Validierung einer OptimizeToursRequest aufgetreten ist.

JSON-Darstellung 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
Felder
code

integer

Ein Validierungsfehler wird durch das Paar (code, displayName) definiert, das immer vorhanden ist.

Die Felder nach diesem Abschnitt liefern weitere Informationen zum Fehler.

MULTIPLE ERRORS: Wenn mehrere Fehler vorliegen, werden beim Validierungsprozess mehrere davon ausgegeben. Ähnlich wie ein Compiler ist dies ein nicht perfekter Prozess. Einige Validierungsfehler sind „schwerwiegend“, das heißt, sie stoppen den gesamten Validierungsprozess. Dies ist u. a. bei displayName="UNSPECIFIED"-Fehlern der Fall. Einige Fehler können dazu führen, dass andere Fehler bei der Validierung übersprungen werden.

Stabilität: code und displayName sollten sehr stabil sein. Im Laufe der Zeit können jedoch neue Codes und Anzeigenamen erscheinen. Dies kann dazu führen, dass eine bestimmte (ungültige) Anfrage zu einem anderen Paar (code, displayName) führt, da der neue Fehler das alte Paar ausgeblendet hat. Siehe z. B. „MEHRERE FEHLER“.
displayName

string

Der Fehleranzeigename.
fields[]

object (FieldReference)

Ein Fehlerkontext kann 0, 1 (in den meisten Fällen) oder mehrere Felder umfassen. Für Fahrzeug 4 und die erste Abholung der Sendung 2 könnte das beispielsweise so aussehen:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

Die Kardinalität von fields sollte sich jedoch für einen bestimmten Fehlercode nicht ändern.
errorMessage

string

Für Menschen lesbarer String, der den Fehler beschreibt. Es gibt eine 1:1-Zuordnung zwischen code und errorMessage (wenn „code“ != „UNSPECIFIED“).

Stabilität: Nicht stabil: Die Fehlermeldung für eine bestimmte code kann sich im Laufe der Zeit ändern (zur Klarstellung sei erwähnt) Verwenden Sie stattdessen displayName und code.
offendingValues

string

Kann die Werte der Felder enthalten. Diese Option ist nicht immer verfügbar. Sie sollten sich auf keinen Fall darauf verlassen und nur zum manuellen Debuggen von Modellen verwenden.

FieldReference

Gibt einen Kontext für den Validierungsfehler an. Ein FieldReference verweist immer auf ein bestimmtes Feld in dieser Datei und hat dieselbe hierarchische Struktur. Beispielsweise können wir Element 2 von startTimeWindows von Fahrzeug 5 wie folgt angeben:

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

Entitäten der obersten Ebene wie OptimizeToursRequest oder ShipmentModel werden jedoch weggelassen, um eine Überfüllung der Nachricht zu vermeiden.

JSON-Darstellung 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
Felder
name

string

Name des Felds, z.B. „Fahrzeuge“.
subField

object (FieldReference)

Bei Bedarf rekursiv verschachteltes untergeordnetes Feld.

Union-Feld index_or_key.

Für index_or_key ist nur einer der folgenden Werte zulässig:
index

integer

Index des Felds, falls wiederholt.
key

string

„Schlüssel“, wenn das Feld eine Zuordnung ist.

Messwerte

Gesamtmesswerte, aggregiert über alle Routen.

JSON-Darstellung 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
Felder
aggregatedRouteMetrics

object (AggregatedMetrics)

Aggregiert über die Routen. Jeder Messwert ist die Summe (bzw. bei Ladevorgängen als Maximalwert) für alle ShipmentRoute.metrics-Felder mit demselben Namen.
skippedMandatoryShipmentCount

integer

Anzahl der übersprungenen obligatorischen Sendungen.
usedVehicleCount

integer

Anzahl der verwendeten Fahrzeuge. Hinweis: Wenn eine Fahrzeugroute leer ist und Vehicle.used_if_route_is_empty „true“ ist, wird das Fahrzeug als genutzt betrachtet.
earliestVehicleStartTime

string (Timestamp format)

Die früheste Startzeit für ein gebrauchtes Fahrzeug, berechnet als Minimum aller gebrauchten Fahrzeuge in der Kategorie „ShipmentRoute.vehicle_start_time“.

Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: "2014-10-02T15:01:23Z" und "2014-10-02T15:01:23.045123456Z".
latestVehicleEndTime

string (Timestamp format)

Die späteste Endzeit für ein Gebrauchtfahrzeug, berechnet als Maximum aller Gebrauchtfahrzeuge von ShipmentRoute.vehicle_end_time.

Ein Zeitstempel im Format RFC3339 UTC "Zulu" mit einer Auflösung im Nanosekundenbereich und bis zu neun Nachkommastellen. Beispiele: "2014-10-02T15:01:23Z" und "2014-10-02T15:01:23.045123456Z".
costs

map (key: string, value: number)

Kosten der Lösung, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Proto-Pfade, bezogen auf die OptimizeToursRequest-Eingabe, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die vom entsprechenden Kostenfeld generiert und über die gesamte Lösung aggregiert werden. Mit anderen Worten: „cost“["model.shipments.pickups.cost"] ist die Summe aller Abholkosten der Lösung. Alle im Modell definierten Kosten werden hier ausführlich aufgeführt, mit Ausnahme der Kosten im Zusammenhang mit TransitionAttributes, die seit Januar 2022 nur noch in zusammengefasster Form erfasst werden.
totalCost

number

Gesamtkosten der Lösung. Die Summe aller Werte in der Kostenzuordnung.