OptimizeToursResponse

Antwort nach der Lösung eines Problems zur Tourenoptimierung mit den Routen der einzelnen Fahrzeuge, den übersprungenen Sendungen und den Gesamtkosten der Lösung.

JSON-Darstellung 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "processedRequest": {
    object (OptimizeToursRequest)
  },
  "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 von OptimizeToursRequest.label, wenn in der Anfrage ein Label angegeben wurde.
skippedShipments[]

object (SkippedShipment)

Die Liste aller übersprungenen Sendungen.
validationErrors[]

object (OptimizeToursValidationError)

Liste aller Validierungsfehler, die wir unabhängig voneinander erkennen konnten. Weitere Informationen finden Sie unter „MEHRERE FEHLER“ in der Erklärung zur Meldung OptimizeToursValidationError. Statt Fehler werden in diesem Fall Warnungen angezeigt, wenn solvingMode gleich DEFAULT_SOLVE ist.
processedRequest

object (OptimizeToursRequest)

In einigen Fällen ändern wir die eingehende Anfrage, bevor wir sie bearbeiten, z.B. indem wir Kosten hinzufügen. Wenn „solvingMode“ == TRANSFORM_AND_RETURN_REQUEST, wird die geänderte Anfrage hier zurückgegeben.

Experimentell: Weitere Informationen finden Sie unter https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.
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 nach diesem Abschnitt enthalten weitere Informationen zum Fehler.

MULTIPLE ERRORS: Wenn mehrere Fehler vorliegen, werden bei der Validierung mehrere davon ausgegeben. Ähnlich wie bei einem Compiler ist dies ein unvollkommener Prozess. Einige Validierungsfehler sind schwerwiegend und führen dazu, dass der gesamte Validierungsprozess beendet wird. Dies ist u. a. bei displayName="UNSPECIFIED"-Fehlern der Fall. Bei einigen Fehlern werden möglicherweise andere Fehler im Validierungsprozess übersprungen.

STABILITÄT: code und displayName sollten sehr stabil sein. Im Laufe der Zeit können jedoch neue Codes und Anzeigenamen hinzukommen. Dadurch kann es passieren, dass eine bestimmte (ungültige) Anfrage ein anderes (code, displayName)-Paar zurückgibt, weil der neue Fehler den alten verdeckt hat. Ein Beispiel finden Sie unter „MEHRERE FEHLER“.
displayName

string

Der Anzeigename des Fehlers.
fields[]

object (FieldReference)

Ein Fehlerkontext kann 0, 1 (meistens) oder mehrere Felder umfassen. Beispiel: Die erste Abholung von Fahrzeug 4 und Sendung 2 kann 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 für einen bestimmten Fehlercode jedoch 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 einem bestimmten code verknüpft ist, kann sich im Laufe der Zeit ändern (hoffentlich, um sie zu verdeutlichen). Verlassen Sie sich stattdessen auf displayName und code.
offendingValues

string

Kann den Wert oder die Werte des Felds enthalten. Diese Option ist nicht immer verfügbar. Sie sollten sich auf keinen Fall darauf verlassen und es nur für das manuelle Debugging 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. Beispiel: Wir geben Element 2 von startTimeWindows von Fahrzeug 5 an:

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

Wir lassen jedoch Top-Level-Entitäten wie OptimizeToursRequest oder ShipmentModel weg, 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 Unterfeld.

Union-Feld index_or_key.

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

integer

Index des Felds, wenn es wiederholt wird.
key

string

Schlüssel, wenn das Feld eine Zuordnung ist.

Messwerte

Gesamtmesswerte, aggregiert über alle Routen hinweg.

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

object (AggregatedMetrics)

Über die Routen aggregiert. Jeder Messwert ist die Summe (oder der Maximalwert für Lasten) aller ShipmentRoute.metrics-Felder mit demselben Namen.
skippedMandatoryShipmentCount

integer

Anzahl der übersprungenen Pflichtlieferungen.
usedVehicleCount

integer

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

string (Timestamp format)

Die früheste Startzeit für ein Gebrauchtfahrzeug, berechnet als das Minimum aller Gebrauchtfahrzeuge von ShipmentRoute.vehicle_start_time.

Verwendet RFC 3339, wobei die generierte Ausgabe immer Z-normalisiert ist und 0, 3, 6 oder 9 Nachkommastellen verwendet. Andere Offsets als „Z“ werden ebenfalls akzeptiert. Beispiele: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" oder "2014-10-02T15:01:23+05:30".
latestVehicleEndTime

string (Timestamp format)

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

Verwendet RFC 3339, wobei die generierte Ausgabe immer Z-normalisiert ist und 0, 3, 6 oder 9 Nachkommastellen verwendet. Andere Offsets als „Z“ werden ebenfalls akzeptiert. Beispiele: "2014-10-02T15:01:23Z", "2014-10-02T15:01:23.045123456Z" oder "2014-10-02T15:01:23+05:30".
costs

map (key: string, value: number)

Kosten der Lösung, aufgeschlüsselt nach kostenbezogenen Anfragefeldern. Die Schlüssel sind Protopfade relativ zum OptimizeToursRequest-Eingabe, z. B. „model.shipments.pickups.cost“. Die Werte sind die Gesamtkosten, die durch das entsprechende Kostenfeld generiert werden, 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. Ausgenommen sind Kosten im Zusammenhang mit TransitionAttributes, die seit Januar 2022 nur noch zusammengefasst angegeben werden.
totalCost

number

Gesamtkosten der Lösung. Die Summe aller Werte in der Kostenübersicht.