Method: projects.optimizeTours

string (Duration format)

Si se establece este tiempo de espera, el servidor devuelve una respuesta antes de que transcurra el período de tiempo de espera o se alcance el plazo del servidor para las solicitudes síncronas, lo que ocurra primero.

En el caso de las solicitudes asíncronas, el servidor generará una solución (si es posible) antes de que se agote el tiempo de espera.

Una duración en segundos con hasta nueve dígitos decimales, que terminan en “s”. Ejemplo: "3.5s".

object (ShipmentModel)

Es el modelo de envío que se debe resolver.

enum (SolvingMode)

De forma predeterminada, el modo de solución es DEFAULT_SOLVE (0).

enum (SearchMode)

Es el modo de búsqueda que se usa para resolver la solicitud.

object (ShipmentRoute)

Guía el algoritmo de optimización para encontrar una primera solución similar a una solución anterior.

El modelo se restringe cuando se crea la primera solución. Los envíos que no se realizan en una ruta se omiten de forma implícita en la primera solución, pero se pueden realizar en soluciones sucesivas.

La solución debe satisfacer algunas suposiciones básicas de validez:

• Para todas las rutas, vehicleIndex debe estar dentro del rango y no duplicarse.
• Para todas las visitas, shipmentIndex y visitRequestIndex deben estar dentro del rango.
• Solo se puede hacer referencia a un envío en una ruta.
• La partida de un envío de retiro y entrega debe realizarse antes de la entrega.
• No se puede realizar más de una alternativa de retiro o entrega de un envío.
• para todas las rutas, los tiempos aumentan (es decir, vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• El envío solo se puede realizar en un vehículo permitido. Se permite un vehículo si Shipment.allowed_vehicle_indices está vacío o si su vehicleIndex se incluye en Shipment.allowed_vehicle_indices.

Si la solución insertada no es factible, no necesariamente se muestra un error de validación, sino que se puede mostrar un error que indique que no es factible.

object (InjectedSolutionConstraint)

Restringe el algoritmo de optimización para encontrar una solución final que sea similar a una solución anterior. Por ejemplo, se puede usar para inmovilizar partes de rutas que ya se completaron o que se deben completar, pero no se deben modificar.

Si la solución insertada no es factible, no necesariamente se muestra un error de validación, sino que se puede mostrar un error que indique que no es factible.

object (ShipmentRoute)

Si no está vacío, se actualizarán las rutas proporcionadas sin modificar su secuencia subyacente de visitas ni los tiempos de viaje: solo se actualizarán otros detalles. Esto no resuelve el modelo.

Desde el 2020/11, esto solo completa las polilíneas de las rutas no vacías y requiere que populatePolylines sea verdadero.

Los campos routePolyline de las rutas que se pasan pueden no ser coherentes con la ruta transitions.

Este campo no se debe usar junto con injectedFirstSolutionRoutes o injectedSolutionConstraint.

Shipment.ignore y Vehicle.ignore no tienen efecto en el comportamiento. Las polilíneas se siguen propagando entre todas las visitas en todas las rutas no vacías, independientemente de si se ignoran los envíos o vehículos relacionados.

boolean

Si es verdadero, haz lo siguiente:

• Usa ShipmentRoute.vehicle_label en lugar de vehicleIndex para hacer coincidir las rutas en una solución insertada con los vehículos de la solicitud; reutiliza la asignación del ShipmentRoute.vehicle_index original al nuevo ShipmentRoute.vehicle_index para actualizar ConstraintRelaxation.vehicle_indices si no está vacío, pero la asignación debe ser inequívoca (es decir, varios ShipmentRoute no deben compartir el mismo vehicleIndex original).
• Usa ShipmentRoute.Visit.shipment_label en lugar de shipmentIndex para hacer coincidir las visitas en una solución insertada con los envíos en la solicitud.
• Usa SkippedShipment.label en lugar de SkippedShipment.index para hacer coincidir los envíos omitidos en la solución insertada con los envíos de la solicitud.

Esta interpretación se aplica a los campos injectedFirstSolutionRoutes, injectedSolutionConstraint y refreshDetailsRoutes. Se puede usar cuando los índices de envíos o vehículos de la solicitud cambiaron desde que se creó la solución, tal vez porque se quitaron o agregaron envíos o vehículos a la solicitud.

Si es verdadero, las etiquetas de las siguientes categorías deben aparecer como máximo una vez en su categoría:

• Vehicle.label en la solicitud
• Shipment.label en la solicitud
• ShipmentRoute.vehicle_label en la solución insertada
• SkippedShipment.label y ShipmentRoute.Visit.shipment_label en la solución insertada (excepto los pares de visitas de retiro y entrega, cuyo shipmentLabel debe aparecer dos veces).

Si un vehicleLabel en la solución insertada no corresponde a un vehículo de solicitud, se quita la ruta correspondiente de la solución junto con sus visitas. Si un shipmentLabel en la solución inyectada no corresponde a un envío de solicitud, se quita la visita correspondiente de la solución. Si un SkippedShipment.label en la solución insertada no corresponde a un envío de solicitud, se quita el SkippedShipment de la solución.

Quitar visitas a rutas o rutas completas de una solución insertada puede afectar las restricciones implícitas, lo que puede generar cambios en la solución, errores de validación o inviabilidad.

NOTA: El llamador debe asegurarse de que cada Vehicle.label (respectivamente, Shipment.label) identifica de forma única una entidad de vehículo (o envío) que se usa en las dos solicitudes pertinentes: la solicitud anterior que produjo el OptimizeToursResponse que se usó en la solución insertada y la solicitud actual que incluye la solución insertada. Las verificaciones de unicidad descritas anteriormente no son suficientes para garantizar este requisito.

boolean

Considera la estimación del tráfico para calcular los campos ShipmentRoute Transition.travel_duration, Visit.start_time y vehicleEndTime, para establecer el campo ShipmentRoute.has_traffic_infeasibilities y para calcular el campo OptimizeToursResponse.total_cost.

boolean

Si es verdadero, se completarán las polilíneas en las respuestas de ShipmentRoute.

boolean

Si es verdadero, las polilíneas y los tokens de ruta se propagarán en la respuesta ShipmentRoute.transitions.

boolean

Si se configura este parámetro, la solicitud puede tener un plazo (consulta https://grpc.io/blog/deadlines) de hasta 60 minutos. De lo contrario, el plazo máximo es de solo 30 minutos. Ten en cuenta que las solicitudes de larga duración tienen un riesgo de interrupción significativamente mayor (aunque sigue siendo pequeño).

boolean

Si es verdadero, las distancias de viaje se calcularán con distancias geodésicas en lugar de distancias de Google Maps, y los tiempos de viaje se calcularán con distancias geodésicas y una velocidad definida por geodesicMetersPerSecond.

string

Es la etiqueta que se puede usar para identificar esta solicitud y que se devuelve en OptimizeToursResponse.request_label.

number

Cuando useGeodesicDistances es verdadero, este campo debe configurarse y define la velocidad que se aplica para calcular los tiempos de viaje. Su valor debe ser de al menos 1.0 metros/segundo.

integer

Trunca la cantidad de errores de validación que se muestran. Por lo general, estos errores se adjuntan a una carga útil de error INVALID_ARGUMENT como un detalle de error BadRequest (https://cloud.google.com/apis/design/errors#error_details), a menos que solvingMode=VALIDATE_ONLY: consulta el campo OptimizeToursResponse.validation_errors. El valor predeterminado es 100 y el límite es 10,000.