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 wir unabhängig voneinander erkennen konnten. Weitere Informationen erhalten Sie unter MEHRERE FEHLER zur OptimizeToursValidationError-Meldung. Anstelle von Fehlern enthält diese Liste Warnungen, wenn solvingMode = DEFAULT_SOLVE ist.
metrics

object (Metrics)

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

OptimizeToursValidationError

Beschreibt einen Fehler oder eine Warnung, die beim Validieren eines 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, die auf diesen Abschnitt folgen, liefern weiteren Kontext zum Fehler.

MEHRERE FEHLER: Bei mehreren Fehlern wird während der Validierung versucht, mehrere davon auszugeben. Ähnlich wie ein Compiler ist dies ein nicht perfekter Prozess. Einige Validierungsfehler sind „fatal“, d. h., sie beenden den gesamten Validierungsprozess. Dies gilt unter anderem für displayName="UNSPECIFIED"-Fehler. 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 beispielsweise "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} }

Beachten Sie jedoch, dass sich die Kardinalität von fields für einen bestimmten Fehlercode nicht ändern sollte.
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 nicht darauf verlassen und sie nur für die manuelle Fehlerbehebung von Modellen verwenden.

FieldReference

Gibt einen Kontext für den Validierungsfehler an. Ein FieldReference bezieht sich immer auf ein bestimmtes Feld in dieser Datei und folgt derselben hierarchischen Struktur. So können wir beispielsweise Element 2 von startTimeWindows von Fahrzeug 5 mit folgendem Code angeben:

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

Entitäten der obersten Ebene wie OptimizeToursRequest oder ShipmentModel werden jedoch weggelassen, um die Nachricht nicht zu überladen.

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. „vehicles“
subField

object (FieldReference)

Rekursiv verschachteltes Unterfeld, falls erforderlich.

Union-Feld index_or_key.

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

integer

Index des Felds, falls es wiederholt wird.
key

string

Key, 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 obligatorischen Sendungen übersprungen.
usedVehicleCount

integer

Anzahl der verwendeten Fahrzeuge. Hinweis: Wenn eine Fahrzeugroute leer ist und Vehicle.used_if_route_is_empty wahr ist, gilt das Fahrzeug als gebraucht.
earliestVehicleStartTime

string (Timestamp format)

Der früheste Startzeitpunkt für ein Gebrauchtfahrzeug, berechnet als Minimum aller Gebrauchtfahrzeuge von 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 letzte Endzeit für ein Gebrauchtfahrzeug, berechnet als Maximum aller Gebrauchtwagen in der Kategorie „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 Eingabe OptimizeToursRequest, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die durch das entsprechende Kostenfeld generiert wurden, aggregiert über die gesamte Lösung. Mit anderen Worten: „costs["model.shipments.pickups.cost"]“ ist die Summe aller Abholkosten für die Lösung. Alle im Modell definierten Kosten werden hier detailliert aufgeführt, mit Ausnahme von Kosten im Zusammenhang mit Übergangsattributen, die seit dem 1. Januar 2022 nur zusammengefasst dargestellt werden.
totalCost

number

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