Method: projects.locations.optimizeTours

string (Duration format)

Se questo timeout è impostato, il server restituisce una risposta prima che sia trascorso il periodo di timeout o che venga raggiunta la scadenza del server per le richieste sincrone, a seconda del caso.

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

Una durata in secondi con un massimo di nove cifre frazionarie, che 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. Eventuali spedizioni non eseguite su un percorso vengono ignorate implicitamente nella prima soluzione, ma possono essere eseguite nelle soluzioni successive.

La soluzione deve soddisfare alcune ipotesi di validità di base:

• Per tutti i percorsi, vehicleIndex deve essere compreso nell'intervallo e non deve 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 eseguita 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)

Limita l'algoritmo di ottimizzazione per trovare una soluzione finale simile a una precedente. Ad esempio, può essere utilizzato per bloccare parti di percorsi già completati o da completare, ma che non devono essere modificati.

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 (ShipmentRoute)

Se non è vuoto, i percorsi 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 problema del modello.

A partire da novembre 2020, vengono compilati solo i polilinei dei percorsi non vuoti e populatePolylines deve essere impostato su true.

I campi routePolyline dei percorsi passati potrebbero non essere coerenti con il 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 true:

• utilizza ShipmentRoute.vehicle_label anziché vehicleIndex per abbinare i percorsi in una soluzione iniettata ai veicoli nella richiesta; riutilizza la mappatura dell'ShipmentRoute.vehicle_index originale al nuovo ShipmentRoute.vehicle_index per aggiornare ConstraintRelaxation.vehicle_indices se non vuoto, ma la mappatura deve essere non ambigua (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 iniettata alle spedizioni richieste.

Questa interpretazione si applica ai campi injectedFirstSolutionRoutes, injectedSolutionConstraint e refreshDetailsRoutes. Può essere utilizzato quando gli indici di spedizione o veicolo nella richiesta sono cambiati dalla creazione della soluzione, ad esempio perché le spedizioni o i veicoli sono stati rimossi dalla richiesta o aggiunti.

Se true, le etichette nelle seguenti categorie devono apparire al massimo una volta nella rispettiva 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 relative 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 richiesta, il SkippedShipment viene rimosso dalla soluzione.

La rimozione di visite ai percorsi o di interi percorsi da una soluzione iniettata può influire sui vincoli impliciti, il che può comportare la modifica della soluzione, errori di convalida o l'impossibilità di applicazione.

NOTA: l'utente che chiama 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 passata che ha prodotto il OptimizeToursResponse utilizzato nella soluzione iniettata e la richiesta corrente che include la soluzione iniettata. I controlli di unicità descritti sopra non sono sufficienti per garantire questo requisito.

boolean

Tieni conto della 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 true, i polilinee verranno compilati nelle ShipmentRoute di risposta.

boolean

Se true, i polilinee e i token di percorso verranno compilati nella risposta ShipmentRoute.transitions.

boolean

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

boolean

Se true, le distanze di viaggio verranno calcolate utilizzando le distanze geodetiche anziché quelle di Google Maps e i tempi di viaggio 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

Quando useGeodesicDistances è true, questo campo deve essere impostato e definisce la velocità applicata per calcolare i 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 sono in genere associati al payload dell'errore INVALID_ARGUMENT come dettaglio dell'errore BadRequest (https://cloud.google.com/apis/design/errors#error_details), a meno che solvingMode=VALIDATE_ONLY: consulta il campo OptimizeToursResponse.validation_errors. Il valore predefinito è 100 e il limite è 10.000.