OptimizeToursResponse

Antwort nach der Lösung eines Problems bei der Tourenoptimierung mit den Routen, die von den einzelnen Fahrzeugen befahren wurden, 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 finden Sie in der Erklärung zu OptimizeToursValidationError unter „MEHRERE FEHLER“. Anstelle von Fehlern werden in diesem Fall Warnungen angezeigt, wenn solvingMode = DEFAULT_SOLVE.
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 bei einem Compiler ist dies ein unvollkommener Prozess. Einige Validierungsfehler sind „fatal“, d. h., sie beenden 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 hinzukommen, was dazu führen kann, dass eine bestimmte (ungültige) Anfrage ein anderes Paar (code, displayName) zurückgibt, weil der neue Fehler den alten ausgeblendet hat. Siehe z. B. „MEHRERE FEHLER“.
displayName

string

Der Anzeigename des Fehlers.
fields[]

object (FieldReference)

Ein Fehlerkontext kann 0, 1 (in den meisten Fällen) oder mehrere Felder umfassen. Die erste Abholung für Fahrzeug 4 und Sendung 2 kann beispielsweise so angegeben werden:

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

Ein 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, die mit einer bestimmten code verknüpft ist, kann sich im Laufe der Zeit ändern (hoffentlich zu einer klareren Formulierung). Bitte verwende 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)

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 es wiederholt wird.
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 (oder bei Ladevorgängen der maximale Wert) aller 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 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 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 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 ausführlich aufgeführt, mit Ausnahme der Kosten im Zusammenhang mit TransitionAttributes, die seit Januar 2022 nur noch zusammengefasst erfasst werden.
totalCost

number

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