OptimizeToursResponse

Es la respuesta después de resolver un problema de optimización de recorridos que contiene las rutas que sigue 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)

Son las rutas calculadas para cada vehículo. La ruta i corresponde al vehículo i en el 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ó cuando se validaba un 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.

Los campos que siguen a esta sección proporcionan 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 serán "irreparables", 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.

ESTABILIDAD: 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 “MULTIPLE ERRORS”.
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, para hacer referencia al vehículo n° 4 y a la primera recolección del envío n° 2, puedes hacerlo 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

Es una cadena legible que describe el error. Hay una asignación de uno a uno 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, usa 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 solo debes usarlo para la depuración manual de modelos.

FieldReference

Especifica un contexto para el error de validación. Un FieldReference siempre se refiere a un campo determinado en este archivo y sigue la misma estructura jerárquica. Por ejemplo, podemos especificar el elemento 2 de startTimeWindows del vehículo 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 recursiva, 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 Vehicle.used_if_route_is_empty es verdadero, se considera que el vehículo está en uso.
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)

Es el costo de la solución, desglosado por campos de solicitud 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 registran en detalle aquí, a excepción de los costos relacionados con TransitionAttributes, que solo se registran de forma agregada a partir de 1/2022.
totalCost

number

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