Method: projects.locations.optimizeTours

string (Duration format)

Se il timeout è impostato, il server restituisce una risposta prima che il periodo di timeout sia trascorso o che sia stata raggiunta la scadenza del server per le richieste sincrone, a seconda dell'evento che si verifica per primo.

Per le richieste asincrone, il server genererà una soluzione (se possibile) prima del timeout.

Durata in secondi con un massimo di nove cifre frazionarie e termina con "s". Esempio: "3.5s".

object (ShipmentModel)

Modello di spedizione da risolvere.

enum (SolvingMode)

Per impostazione predefinita, la modalità di risoluzione è DEFAULT_SOLVE (0).

enum (SearchMode)

Modalità di ricerca utilizzata per risolvere la richiesta.

object (ShipmentRoute)

Guida l'algoritmo di ottimizzazione a trovare una prima soluzione simile a una precedente.

Il modello è vincolato quando viene creata la prima soluzione. Tutte le spedizioni non effettuate su un itinerario vengono implicitamente saltate nella prima soluzione, ma possono essere effettuate in soluzioni successive.

La soluzione deve soddisfare alcuni presupposti di base della validità:

• per tutte le route, vehicleIndex deve essere nel raggio d'azione e non essere duplicato.
• Per tutte le visite, shipmentIndex e visitRequestIndex devono essere compresi nell'intervallo.
• È possibile fare riferimento a una spedizione in un solo percorso.
• il ritiro di una spedizione con ritiro e consegna deve essere eseguito prima della consegna.
• non può essere eseguita più di un'alternativa di ritiro o consegna di una spedizione.
• per tutti i percorsi, i tempi sono in aumento (ad es. vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
• una spedizione può essere effettuata solo su un veicolo consentito. Un veicolo è consentito se Shipment.allowed_vehicle_indices è vuoto o se il relativo vehicleIndex è incluso in Shipment.allowed_vehicle_indices.

Se la soluzione iniettata non è fattibile, non viene necessariamente restituito un errore di convalida, ma potrebbe essere restituito un errore che indica l'impossibilità di applicazione.

object (InjectedSolutionConstraint)

Limitare l'algoritmo di ottimizzazione a trovare una soluzione finale simile a una soluzione precedente. Questa opzione, ad esempio, può essere utilizzata per bloccare parti di percorsi che sono già stati completati o che devono essere completati ma non devono essere modificati.

Se la soluzione inserita non è fattibile, non viene necessariamente restituito un errore di convalida e potrebbe invece essere restituito un errore che indica l'inattuabilità.

object (ShipmentRoute)

Se il campo non è vuoto, gli itinerari specificati verranno aggiornati senza modificare la sequenza di visite o i tempi di percorrenza sottostanti: verranno aggiornati solo gli altri dettagli. Questo non risolve il modello.

A partire dal 2020/11, questo campo compila solo le polilinee delle route non vuote e richiede che populatePolylines sia true.

I campi routePolyline dei percorsi passati potrebbero non corrispondere al percorso transitions.

Questo campo non deve essere utilizzato insieme a injectedFirstSolutionRoutes o injectedSolutionConstraint.

Shipment.ignore e Vehicle.ignore non hanno alcun effetto sul comportamento. I polilinee vengono comunque compilati tra tutte le visite in tutti i percorsi non vuoti, indipendentemente dal fatto che le spedizioni o i veicoli correlati vengano ignorati.

boolean

Se il valore è vero:

• utilizza ShipmentRoute.vehicle_label anziché vehicleIndex per abbinare i percorsi di una soluzione iniettata con i veicoli nella richiesta; riutilizza la mappatura del ShipmentRoute.vehicle_index originale al nuovo ShipmentRoute.vehicle_index per aggiornare ConstraintRelaxation.vehicle_indices se il campo non è vuoto, ma il mapping deve essere non ambiguo (ovvero, più ShipmentRoute non devono condividere lo stesso vehicleIndex originale).
• utilizza ShipmentRoute.Visit.shipment_label anziché shipmentIndex per abbinare le visite in una soluzione iniettata alle spedizioni nella richiesta;
• utilizza SkippedShipment.label anziché SkippedShipment.index per abbinare le spedizioni saltate nella soluzione inserita con le spedizioni delle richieste.

Questa interpretazione si applica ai campi injectedFirstSolutionRoutes, injectedSolutionConstraint e refreshDetailsRoutes. Può essere usato quando gli indici delle spedizioni o dei veicoli nella richiesta sono cambiati dopo la creazione della soluzione, forse perché le spedizioni o i veicoli sono stati rimossi o aggiunti alla richiesta.

Se impostato su true, le etichette delle seguenti categorie devono apparire al massimo una sola volta nella categoria:

• Vehicle.label nella richiesta;
• Shipment.label nella richiesta;
• ShipmentRoute.vehicle_label nella soluzione iniettata;
• SkippedShipment.label e ShipmentRoute.Visit.shipment_label nella soluzione iniettata (tranne le coppie di visite di ritiro/consegna, il cui shipmentLabel deve apparire due volte).

Se un vehicleLabel nella soluzione iniettata non corrisponde a un veicolo richiesto, il percorso corrispondente viene rimosso dalla soluzione insieme alle visite. Se un shipmentLabel nella soluzione iniettata non corrisponde a un invio di richieste, la visita corrispondente viene rimossa dalla soluzione. Se un SkippedShipment.label nella soluzione iniettata non corrisponde a una spedizione di richiesta, il SkippedShipment viene rimosso dalla soluzione.

La rimozione delle visite ai percorsi o di interi percorsi da una soluzione inserita potrebbe influire sui vincoli impliciti, il che potrebbe portare a cambiamenti nella soluzione, errori di convalida o inattuabilità.

NOTA: il chiamante deve assicurarsi che ogni Vehicle.label (risp. Shipment.label) identifica in modo univoco un'entità veicolo (risp. spedizione) utilizzata nelle due richieste pertinenti: la richiesta precedente che ha prodotto il OptimizeToursResponse utilizzato nella soluzione iniettata e la richiesta attuale che include la soluzione iniettata. I controlli di univocità descritti sopra non sono sufficienti a garantire questo requisito.

boolean

Prendi in considerazione la stima del traffico per calcolare i campi ShipmentRoute Transition.travel_duration, Visit.start_time e vehicleEndTime, per impostare il campo ShipmentRoute.has_traffic_infeasibilities e per calcolare il campo OptimizeToursResponse.total_cost.

boolean

Se impostato su true, le polilinee verranno compilate nelle risposte ShipmentRoute.

boolean

Se true, i polilinee verranno compilati nella risposta ShipmentRoute.transitions.

boolean

Se questo criterio è impostato, la richiesta può avere una scadenza (vedi https://grpc.io/blog/deadlines) di massimo 60 minuti. In caso contrario, la scadenza massima è di soli 30 minuti. Tieni presente che le richieste di lunga durata presentano un rischio di interruzione significativamente maggiore (ma comunque ridotto).

boolean

Se true, le distanze di percorrere verranno calcolate utilizzando le distanze geodetiche anziché quelle di Google Maps e i tempi di percorrenza verranno calcolati utilizzando le distanze geodetiche con una velocità definita da geodesicMetersPerSecond.

string

L'etichetta che può essere utilizzata per identificare questa richiesta, riportata in OptimizeToursResponse.request_label.

number

Se useGeodesicDistances è impostato su true, è necessario impostare questo campo che definisce la velocità applicata al calcolo dei tempi di percorrenza. Il valore deve essere almeno pari a 1,0 metri/secondi.

integer

Tronca il numero di errori di convalida restituiti. Questi errori in genere sono associati a un payload di errore INVALID_ARGUMENT come dettaglio dell'errore BadRequest (https://cloud.google.com/apis/design/errors#error_details), a meno che non si veda il campo OptimizeToursResponse.validation_errors. Il valore predefinito è 100 ed è limitato a 10.000.