OptimizeToursResponse

Es la respuesta después de resolver un problema de optimización de recorridos que contiene las rutas que siguió cada vehículo, los envíos que se omitieron y el costo general de la solución.

Representación JSON 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "metrics": {
    object (Metrics)
  }
}
Campos
routes[]

object (ShipmentRoute)

Rutas calculadas para cada vehículo; la i-ésima ruta corresponde al vehículo i-ésimo del modelo.
requestLabel

string

Es una copia de OptimizeToursRequest.label si se especificó una etiqueta en la solicitud.
skippedShipments[]

object (SkippedShipment)

La lista de todos los envíos omitidos
validationErrors[]

object (OptimizeToursValidationError)

Es la lista de todos los errores de validación que pudimos detectar de forma independiente. Consulta la explicación de "MULTIPLE ERRORS" para el mensaje OptimizeToursValidationError. En lugar de errores, se incluirán advertencias en el caso de que solvingMode sea DEFAULT_SOLVE.
metrics

object (Metrics)

Métricas de duración, distancia y uso de esta solución.

OptimizeToursValidationError

Describe un error o una advertencia que se encontró durante la validación de una OptimizeToursRequest.

Representación JSON 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
Campos
code

integer

Un error de validación se define por el par (code, displayName) que siempre está presente.

En los campos que siguen a esta sección, se proporciona más contexto sobre el error.

MULTIPLE ERRORS: Cuando hay varios errores, el proceso de validación intenta mostrar varios de ellos. Al igual que un compilador, este es un proceso imperfecto. Algunos errores de validación son “fatales”, lo que significa que detienen todo el proceso de validación. Este es el caso de los errores de displayName="UNSPECIFIED", entre otros. Algunos errores pueden hacer que el proceso de validación omita otros errores.

ESTIBILIDAD: code y displayName deben ser muy estables. Sin embargo, es posible que aparezcan códigos y nombres visibles nuevos con el tiempo, lo que puede hacer que una solicitud determinada (no válida) genere un par diferente (code, displayName) porque el error nuevo ocultó el anterior. Por ejemplo, consulta “VARIOS ERRORES”.
displayName

string

El nombre visible del error.
fields[]

object (FieldReference)

Un contexto de error puede incluir 0, 1 (la mayoría de las veces) o más campos. Por ejemplo, hacer referencia al vehículo núm. 4 y al primer retiro del envío núm. 2 se puede hacer de la siguiente manera:

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

Sin embargo, ten en cuenta que la cardinalidad de fields no debe cambiar para un código de error determinado.
errorMessage

string

Cadena legible que describe el error Hay una asignación de 1:1 entre code y errorMessage (cuando code != "UNSPECIFIED").

ESTABILIDAD: No es estable: el mensaje de error asociado a un code determinado puede cambiar (con suerte, para aclararlo) con el tiempo. En su lugar, confía en displayName y code.
offendingValues

string

Puede contener los valores de los campos. Esta opción no siempre está disponible. No debes confiar en él y usarlo solo para la depuración manual del modelo.

FieldReference

Especifica un contexto para el error de validación. Un FieldReference siempre hace referencia a un campo determinado en este archivo y sigue la misma estructura jerárquica. Por ejemplo, podríamos especificar el elemento no 2 de startTimeWindows del vehículo no 5 de la siguiente manera:

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

Sin embargo, omitimos las entidades de nivel superior, como OptimizeToursRequest o ShipmentModel, para evitar que el mensaje esté sobrecargado.

Representación JSON 
{
  "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.
}
Campos
name

string

Es el nombre del campo, p.ej., "vehicles".
subField

object (FieldReference)

Subcampo anidado de forma recurrente, si es necesario.

Campo de unión index_or_key.

index_or_key puede ser una de las siguientes opciones:
index

integer

Es el índice del campo si se repite.
key

string

Es clave si el campo es un mapa.

Métricas

Métricas generales, agregadas en todas las rutas

Representación JSON 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
Campos
aggregatedRouteMetrics

object (AggregatedMetrics)

Se agregan en las rutas. Cada métrica es la suma (o el máximo, para las cargas) de todos los campos ShipmentRoute.metrics con el mismo nombre.
skippedMandatoryShipmentCount

integer

Cantidad de envíos obligatorios omitidos.
usedVehicleCount

integer

Es la cantidad de vehículos utilizados. Nota: Si la ruta de un vehículo está vacía y el valor de Vehicle.used_if_route_is_empty es verdadero, el vehículo se considera usado.
earliestVehicleStartTime

string (Timestamp format)

Es la hora de inicio más antigua de un vehículo usado, calculada como el mínimo de todos los vehículos usados de ShipmentRoute.vehicle_start_time.

Una marca de tiempo en formato RFC3339 UTC “Zulú”, con una resolución de nanosegundos y hasta nueve dígitos fraccionarios. Ejemplos: "2014-10-02T15:01:23Z" y "2014-10-02T15:01:23.045123456Z".
latestVehicleEndTime

string (Timestamp format)

Es la hora de finalización más reciente de un vehículo usado, calculada como el máximo de todos los vehículos usados de ShipmentRoute.vehicle_end_time.

Una marca de tiempo en formato RFC3339 UTC “Zulú”, con una resolución de nanosegundos y hasta nueve dígitos fraccionarios. Ejemplos: "2014-10-02T15:01:23Z" y "2014-10-02T15:01:23.045123456Z".
costs

map (key: string, value: number)

Costo de la solución, desglosado por campos de solicitudes relacionados con el costo. Las claves son rutas de proto, en relación con la entrada OptimizeToursRequest, p. ej., "model.shipments.pickups.cost", y los valores son el costo total generado por el campo de costo correspondiente, agregado en toda la solución. En otras palabras, costs["model.shipments.pickups.cost"] es la suma de todos los costos de retiro de la solución. Todos los costos definidos en el modelo se informan aquí en detalle, excepto los costos relacionados con TransitionAttributes que solo se informan de forma agregada a partir de 2022/01.
totalCost

number

El costo total de la solución Es la suma de todos los valores en el mapa de costos.