Cloud Optimization V1 API - Class Google::Cloud::Optimization::V1::ShipmentRoute (v0.9.1)

Reference documentation and code samples for the Cloud Optimization V1 API class Google::Cloud::Optimization::V1::ShipmentRoute.

A vehicle's route can be decomposed, along the time axis, like this (we assume there are n visits): | | | | | T[2], | | | | Transition | Visit #0 | | | V[2], | | | | #0 | aka | T[1] | V[1] | ... | V[n-1] | T[n] | | aka T[0] | V[0] | | | V[n-2],| | | | | | | | T[n-1] | | | ^ ^ ^ ^ ^ ^ ^ ^ vehicle V[0].start V[0].end V[1]. V[1]. V[n]. V[n]. vehicle start (arrival) (departure) start end start end end Note that we make a difference between:

• "punctual events", such as the vehicle start and end and each visit's start and end (aka arrival and departure). They happen at a given second.
• "time intervals", such as the visits themselves, and the transition between visits. Though time intervals can sometimes have zero duration, i.e. start and end at the same second, they often have a positive duration.

Invariants:

• If there are n visits, there are n+1 transitions.
• A visit is always surrounded by a transition before it (same index) and a transition after it (index + 1).
• The vehicle start is always followed by transition #0.
• The vehicle end is always preceded by transition #n.

Zooming in, here is what happens during a Transition and a Visit: ---+-------------------------------------+-----------------------------+--> | TRANSITION[i] | VISIT[i] | | | | | * TRAVEL: the vehicle moves from | PERFORM the visit: | | VISIT[i-1].departure_location to | | | VISIT[i].arrival_location, which | * Spend some time: | | takes a given travel duration | the "visit duration". | | and distance | | | | * Load or unload | | * BREAKS: the driver may have | some quantities from the | | breaks (e.g. lunch break). | vehicle: the "demand". | | | | | * WAIT: the driver/vehicle does | | | nothing. This can happen for | | | many reasons, for example when | | | the vehicle reaches the next | | | event's destination before the | | | start of its time window | | | | | | * DELAY: right before the next | | | arrival. E.g. the vehicle and/or | | | driver spends time unloading. | | | | | ---+-------------------------------------+-----------------------------+--> ^ ^ ^ V[i-1].end V[i].start V[i].end Lastly, here is how the TRAVEL, BREAKS, DELAY and WAIT can be arranged during a transition.

• They don't overlap.
• The DELAY is unique and must be a contiguous period of time right before the next visit (or vehicle end). Thus, it suffice to know the delay duration to know its start and end time.
• The BREAKS are contiguous, non-overlapping periods of time. The response specifies the start time and duration of each break.
• TRAVEL and WAIT are "preemptable": they can be interrupted several times during this transition. Clients can assume that travel happens "as soon as possible" and that "wait" fills the remaining time.

A (complex) example: TRANSITION[i] --++-----+-----------------------------------------------------------++--> || | | | | | | || || T | B | T | | B | | D || || r | r | r | W | r | W | e || || a | e | a | a | e | a | l || || v | a | v | i | a | i | a || || e | k | e | t | k | t | y || || l | | l | | | | || || | | | | | | || --++-----------------------------------------------------------------++-->