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 in der Erklärung zu „MULTIPLE ERRORS“ für die Meldung OptimizeToursValidationError. Anstelle von Fehlern werden 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.

MEHRERE FEHLER: 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. Das ist unter anderem 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). Verwenden Sie stattdessen displayName und code.
offendingValues

string

Kann den Wert oder die Werte des Felds enthalten. Das ist nicht immer möglich. Sie sollten sich auf keinen Fall darauf verlassen und es nur für das manuelle 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 folgt derselben hierarchischen Struktur. Beispiel: Wir geben Element 2 von startTimeWindows des Fahrzeugs 5 mit folgendem Code 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)
  },

  // The following is a list of mutually exclusive fields. At most one of the
  // fields will be set in a response:
  "index": integer,
  "key": string
  // End of mutually exclusive fields.
}
Felder
name

string

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

object (FieldReference)

Bei Bedarf rekursiv verschachteltes Unterfeld.
Im Folgenden finden Sie eine Liste von sich gegenseitig ausschließenden Feldern. In einer Antwort wird höchstens eines der Felder festgelegt:
index

integer

Index des Felds, wenn es wiederholt wird.
key

string

Schlüssel, wenn das Feld eine Karte ist.
Ende der sich gegenseitig ausschließenden Felder.

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)

Ü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 genutzt.
earliestVehicleStartTime

string (Timestamp format)

Die früheste Startzeit für ein gebrauchtes Fahrzeug, berechnet als das Minimum aller gebrauchten Fahrzeuge 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 späteste 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 zur Eingabe „OptimizeToursRequest“, 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, mit Ausnahme der Kosten für TransitionAttributes, die ab Januar 2022 nur noch aggregiert ausgewiesen werden.
totalCost

number

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