Method: projects.locations.optimizeTours

string (Duration format)

Se esse tempo limite for definido, o servidor vai retornar uma resposta antes que o período de tempo limite termine ou que o prazo do servidor para solicitações síncronas seja atingido, o que acontecer primeiro.

Para solicitações assíncronas, o servidor vai gerar uma solução (se possível) antes que o tempo limite expire.

Duração em segundos com até nove dígitos fracionários, terminando em "s". Exemplo: "3.5s".

object (ShipmentModel)

Modelo de envio a ser resolvido.

enum (SolvingMode)

Por padrão, o modo de solução é DEFAULT_SOLVE (0).

enum (SearchMode)

Modo de pesquisa usado para resolver a solicitação.

object (ShipmentRoute)

Orienta o algoritmo de otimização a encontrar uma primeira solução semelhante a uma anterior.

O modelo é restrito quando a primeira solução é criada. As entregas não realizadas em uma rota são implicitamente ignoradas na primeira solução, mas podem ser realizadas em soluções sucessivas.

A solução precisa atender a algumas proposições básicas de validade:

• Para todas as rotas, vehicleIndex precisa estar no intervalo e não pode ser duplicado.
• Para todas as visitas, shipmentIndex e visitRequestIndex precisam estar no intervalo.
• uma remessa só pode ser referenciada em um trajeto.
• A retirada de uma remessa de retirada e entrega precisa ser feita antes da entrega.
• não é possível realizar mais de uma alternativa de retirada ou entrega de um envio.
• para todas as rotas, os tempos estão aumentando (ou seja, vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• um envio só pode ser feito em um veículo permitido. Um veículo é permitido se Shipment.allowed_vehicle_indices estiver vazio ou se o vehicleIndex dele estiver incluído em Shipment.allowed_vehicle_indices.

Se a solução injetada não for viável, um erro de validação não será necessariamente retornado. Em vez disso, um erro indicando inviabilidade poderá ser retornado.

object (InjectedSolutionConstraint)

Restrinja o algoritmo de otimização para encontrar uma solução final semelhante a uma solução anterior. Por exemplo, isso pode ser usado para congelar partes de rotas que já foram concluídas ou que serão concluídas, mas não podem ser modificadas.

Se a solução injetada não for viável, um erro de validação não será necessariamente retornado. Em vez disso, um erro indicando inviabilidade poderá ser retornado.

object (ShipmentRoute)

Se não estiver vazio, as rotas fornecidas serão atualizadas sem modificar a sequência de visitas ou os tempos de viagem. Apenas outros detalhes serão atualizados. Isso não resolve o modelo.

Desde 11/2020, isso só preenche as polilinhas de rotas não vazias e exige que populatePolylines seja verdadeiro.

Os campos routePolyline das rotas transmitidas podem ser inconsistentes com a rota transitions.

Esse campo não pode ser usado com injectedFirstSolutionRoutes ou injectedSolutionConstraint.

Shipment.ignore e Vehicle.ignore não têm efeito no comportamento. As polilinhas ainda são preenchidas entre todas as visitas em todas as rotas não vazias, independentemente de os envios ou veículos relacionados serem ignorados.

boolean

Se for verdade:

• usa ShipmentRoute.vehicle_label em vez de vehicleIndex para corresponder rotas em uma solução injetada com veículos na solicitação; reutiliza o mapeamento do ShipmentRoute.vehicle_index original para o novo ShipmentRoute.vehicle_index para atualizar ConstraintRelaxation.vehicle_indices se não estiver vazio, mas o mapeamento precisa ser inequívoco (ou seja, vários ShipmentRoutes não podem compartilhar o mesmo vehicleIndex original).
• usa ShipmentRoute.Visit.shipment_label em vez de shipmentIndex para corresponder visitas em uma solução injetada com envios na solicitação;
• usa SkippedShipment.label em vez de SkippedShipment.index para corresponder aos envios ignorados na solução injetada com os envios da solicitação.

Essa interpretação se aplica aos campos injectedFirstSolutionRoutes, injectedSolutionConstraint e refreshDetailsRoutes. Ele pode ser usado quando os índices de envio ou de veículo na solicitação mudaram desde que a solução foi criada, talvez porque envios ou veículos foram removidos ou adicionados à solicitação.

Se for verdadeiro, os rótulos nas seguintes categorias vão aparecer no máximo uma vez em cada categoria:

• Vehicle.label na solicitação;
• Shipment.label na solicitação;
• ShipmentRoute.vehicle_label na solução injetada;
• SkippedShipment.label e ShipmentRoute.Visit.shipment_label na solução injetada, exceto pares de visitas de coleta/entrega, em que shipmentLabel precisa aparecer duas vezes.

Se um vehicleLabel na solução injetada não corresponder a um veículo de solicitação, a rota correspondente será removida da solução junto com as visitas. Se um shipmentLabel na solução injetada não corresponder a um envio de pedido, a visita correspondente será removida da solução. Se um SkippedShipment.label na solução injetada não corresponder a um envio de solicitação, o SkippedShipment será removido da solução.

Remover visitas ou rotas inteiras de uma solução injetada pode afetar as restrições implícitas, o que pode levar a mudanças na solução, erros de validação ou inviabilidade.

OBSERVAÇÃO: o caller precisa garantir que cada Vehicle.label (resp. Shipment.label) identifica de forma exclusiva um veículo (ou remessa) usado nas duas solicitações relevantes: a solicitação anterior que produziu o OptimizeToursResponse usado na solução injetada e a solicitação atual que inclui a solução injetada. As verificações de exclusividade descritas acima não são suficientes para garantir esse requisito.

boolean

Considere a estimativa de tráfego ao calcular os campos ShipmentRoute Transition.travel_duration, Visit.start_time e vehicleEndTime, ao definir o campo ShipmentRoute.has_traffic_infeasibilities e ao calcular o campo OptimizeToursResponse.total_cost.

boolean

Se for "true", as polilinhas serão preenchidas nas respostas ShipmentRoutes.

boolean

Se for "true", as polilinhas e os tokens de rota serão preenchidos na resposta ShipmentRoute.transitions.

boolean

Se esse campo for definido, a solicitação poderá ter um prazo (consulte https://grpc.io/blog/deadlines) de até 60 minutos. Caso contrário, o prazo máximo é de apenas 30 minutos. As solicitações de longa duração têm um risco significativamente maior (mas ainda pequeno) de interrupção.

boolean

Se for "true", as distâncias de viagem serão calculadas usando distâncias geodésicas em vez de distâncias do Google Maps, e os tempos de viagem serão calculados usando distâncias geodésicas com uma velocidade definida por geodesicMetersPerSecond.

string

Rótulo que pode ser usado para identificar esta solicitação, informado de volta no OptimizeToursResponse.request_label.

number

Quando useGeodesicDistances é verdadeiro, esse campo precisa ser definido e define a velocidade aplicada para calcular os tempos de viagem. O valor precisa ser de pelo menos 1,0 metro/segundo.

integer

Trunca o número de erros de validação retornados. Esses erros geralmente são anexados a uma carga útil de erro INVALID_ARGUMENT como um detalhe de erro BadRequest (https://cloud.google.com/apis/design/errors#error_details), a menos que solvingMode=VALIDATE_ONLY. Consulte o campo OptimizeToursResponse.validation_errors. O padrão é 100,e o limite é 10.000.