# Package Classes (1.15.0) 1.15.0 (latest) 1.14.0 1.13.0 1.12.0 1.11.2 1.10.0 1.9.1 1.8.5 1.7.0 1.6.0 1.5.0 1.4.3 1.3.2 1.2.0 1.1.3 1.0.1 0.1.1 Summary of entries of Classes for optimization. ## Classes ### [FleetRoutingAsyncClient](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.services.fleet_routing.FleetRoutingAsyncClient) A service for optimizing vehicle tours. Validity of certain types of fields: - `google.protobuf.Timestamp` - Times are in Unix time: seconds since 1970-01-01T00:00:00+00:00. - seconds must be in \[0, 253402300799\], i.e. in \[1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00\]. - nanos must be unset or set to 0. - `google.protobuf.Duration` - seconds must be in \[0, 253402300799\], i.e. in \[1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00\]. - nanos must be unset or set to 0. - `google.type.LatLng` - latitude must be in \[-90.0, 90.0\]. - longitude must be in \[-180.0, 180.0\]. - at least one of latitude and longitude must be non-zero. ### [FleetRoutingClient](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.services.fleet_routing.FleetRoutingClient) A service for optimizing vehicle tours. Validity of certain types of fields: - `google.protobuf.Timestamp` - Times are in Unix time: seconds since 1970-01-01T00:00:00+00:00. - seconds must be in \[0, 253402300799\], i.e. in \[1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00\]. - nanos must be unset or set to 0. - `google.protobuf.Duration` - seconds must be in \[0, 253402300799\], i.e. in \[1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00\]. - nanos must be unset or set to 0. - `google.type.LatLng` - latitude must be in \[-90.0, 90.0\]. - longitude must be in \[-180.0, 180.0\]. - at least one of latitude and longitude must be non-zero. ### [AggregatedMetrics](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.AggregatedMetrics) Aggregated metrics for ShipmentRoute (resp. for OptimizeToursResponse over all Transition and/or Visit (resp. over all ShipmentRoute) elements. ### [CostsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.AggregatedMetrics.CostsEntry) The abstract base class for a message. ### [MaxLoadsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.AggregatedMetrics.MaxLoadsEntry) The abstract base class for a message. ### [AsyncModelMetadata](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.AsyncModelMetadata) The long running operation metadata for async model related methods. ### [State](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.AsyncModelMetadata.State) Possible states of the operation. ### [BatchOptimizeToursRequest](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BatchOptimizeToursRequest) Request to batch optimize tours as an asynchronous operation. Each input file should contain one `OptimizeToursRequest`, and each output file will contain one `OptimizeToursResponse`. The request contains information to read/write and parse the files. All the input and output files should be under the same project. ### [AsyncModelConfig](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BatchOptimizeToursRequest.AsyncModelConfig) Information for solving one optimization model asynchronously. ### [BatchOptimizeToursResponse](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BatchOptimizeToursResponse) Response to a `BatchOptimizeToursRequest`. This is returned in the LRO Operation after the operation is complete. ### [BreakRule](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BreakRule) Rules to generate time breaks for a vehicle (e.g. lunch breaks). A break is a contiguous period of time during which the vehicle remains idle at its current position and cannot perform any visit. A break may occur: - during the travel between two visits (which includes the time right before or right after a visit, but not in the middle of a visit), in which case it extends the corresponding transit time between the visits, - or before the vehicle start (the vehicle may not start in the middle of a break), in which case it does not affect the vehicle start time. - or after the vehicle end (ditto, with the vehicle end time). ### [BreakRequest](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BreakRule.BreakRequest) The sequence of breaks (i.e. their number and order) that apply to each vehicle must be known beforehand. The repeated `BreakRequest`\\ s define that sequence, in the order in which they must occur. Their time windows (`earliest_start_time` / `latest_start_time`) may overlap, but they must be compatible with the order (this is checked). ### [FrequencyConstraint](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.BreakRule.FrequencyConstraint) One may further constrain the frequency and duration of the breaks specified above, by enforcing a minimum break frequency, such as "There must be a break of at least 1 hour every 12 hours". Assuming that this can be interpreted as "Within any sliding time window of 12h, there must be at least one break of at least one hour", that example would translate to the following `FrequencyConstraint`: :: { min_break_duration { seconds: 3600 } # 1 hour. max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11). } The timing and duration of the breaks in the solution will respect all such constraints, in addition to the time windows and minimum durations already specified in the `BreakRequest`. A `FrequencyConstraint` may in practice apply to non-consecutive breaks. For example, the following schedule honors the "1h every 12h" example: :: 04:00 vehicle start .. performing travel and visits .. 09:00 1 hour break 10:00 end of the break .. performing travel and visits .. 12:00 20-min lunch break 12:20 end of the break .. performing travel and visits .. 21:00 1 hour break 22:00 end of the break .. performing travel and visits .. 23:59 vehicle end ### [CapacityQuantity](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.CapacityQuantity) Deprecated: Use Vehicle.LoadLimit.Interval instead. ### [CapacityQuantityInterval](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.CapacityQuantityInterval) Deprecated: Use Vehicle.LoadLimit.Interval instead. .. _oneof: ### [DataFormat](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.DataFormat) Data formats for input and output files. ### [DistanceLimit](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.DistanceLimit) A limit defining a maximum distance which can be traveled. It can be either hard or soft. If a soft limit is defined, both `soft_max_meters` and `cost_per_kilometer_above_soft_max` must be defined and be nonnegative. .. _oneof: ### [GcsDestination](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.GcsDestination) The Google Cloud Storage location where the output file will be written to. ### [GcsSource](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.GcsSource) The Google Cloud Storage location where the input file will be read from. ### [InjectedSolutionConstraint](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.InjectedSolutionConstraint) Solution injected in the request including information about which visits must be constrained and how they must be constrained. ### [ConstraintRelaxation](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.InjectedSolutionConstraint.ConstraintRelaxation) For a group of vehicles, specifies at what threshold(s) constraints on visits will be relaxed and to which level. Shipments listed in the `skipped_shipment` field are constrained to be skipped; i.e., they cannot be performed. ### [Relaxation](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.InjectedSolutionConstraint.ConstraintRelaxation.Relaxation) If `relaxations` is empty, the start time and sequence of all visits on `routes` are fully constrained and no new visits may be inserted or added to those routes. Also, a vehicle's start and end time in `routes` is fully constrained, unless the vehicle is empty (i.e., has no visits and has `used_if_route_is_empty` set to false in the model). `relaxations(i).level` specifies the constraint relaxation level applied to a visit #j that satisfies: - `route.visits(j).start_time >= relaxations(i).threshold_time` AND - `j + 1 >= relaxations(i).threshold_visit_count` Similarly, the vehicle start is relaxed to `relaxations(i).level` if it satisfies: - `vehicle_start_time >= relaxations(i).threshold_time` AND - `relaxations(i).threshold_visit_count == 0` and the vehicle end is relaxed to `relaxations(i).level` if it satisfies: - `vehicle_end_time >= relaxations(i).threshold_time` AND - `route.visits_size() + 1 >= relaxations(i).threshold_visit_count` To apply a relaxation level if a visit meets the `threshold_visit_count` OR the `threshold_time` add two `relaxations` with the same `level`: one with only `threshold_visit_count` set and the other with only `threshold_time` set. If a visit satisfies the conditions of multiple `relaxations`, the most relaxed level applies. As a result, from the vehicle start through the route visits in order to the vehicle end, the relaxation level becomes more relaxed: i.e., the relaxation level is non-decreasing as the route progresses. The timing and sequence of route visits that do not satisfy the threshold conditions of any `relaxations` are fully constrained and no visits may be inserted into these sequences. Also, if a vehicle start or end does not satisfy the conditions of any relaxation the time is fixed, unless the vehicle is empty. ### [Level](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level) Expresses the different constraint relaxation levels, which are applied for a visit and those that follow when it satisfies the threshold conditions. The enumeration below is in order of increasing relaxation. This value must not be explicitly used in `level`. RELAX_VISIT_TIMES_AFTER_THRESHOLD (1): Visit start times and vehicle start/end times will be relaxed, but each visit remains bound to the same vehicle and the visit sequence must be observed: no visit can be inserted between them or before them. RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD (2): Same as `RELAX_VISIT_TIMES_AFTER_THRESHOLD`, but the visit sequence is also relaxed: visits can only be performed by this vehicle, but can potentially become unperformed. RELAX_ALL_AFTER_THRESHOLD (3): Same as `RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD`, but the vehicle is also relaxed: visits are completely free at or after the threshold time and can potentially become unperformed. ### [InputConfig](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.InputConfig) The desired input location information. .. _oneof: ### [Location](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Location) Encapsulates a location (a geographic point, and an optional heading). .. _oneof: ### [OptimizeToursRequest](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursRequest) Request to be given to a tour optimization solver which defines the shipment model to solve as well as optimization parameters. .. _oneof: ### [SearchMode](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursRequest.SearchMode) Mode defining the behavior of the search, trading off latency versus solution quality. In all modes, the global request deadline is enforced. ### [SolvingMode](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursRequest.SolvingMode) Defines how the solver should handle the request. In all modes but `VALIDATE_ONLY`, if the request is invalid, you will receive an `INVALID_REQUEST` error. See max_validation_errors to cap the number of errors returned. *IMPORTANT*: not all infeasible shipments are returned here, but only the ones that are detected as infeasible during preprocessing. ### [OptimizeToursResponse](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursResponse) Response after solving a tour optimization problem containing the routes followed by each vehicle, the shipments which have been skipped and the overall cost of the solution. ### [Metrics](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursResponse.Metrics) Overall metrics, aggregated over all routes. ### [CostsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursResponse.Metrics.CostsEntry) The abstract base class for a message. ### [OptimizeToursValidationError](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursValidationError) Describes an error encountered when validating an `OptimizeToursRequest`. ### [FieldReference](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OptimizeToursValidationError.FieldReference) Specifies a context for the validation error. A `FieldReference` always refers to a given field in this file and follows the same hierarchical structure. For example, we may specify element #2 of `start_time_windows` of vehicle #5 using: :: name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 } We however omit top-level entities such as `OptimizeToursRequest` or `ShipmentModel` to avoid crowding the message. This message has `oneof`_ fields (mutually exclusive fields). For each oneof, at most one member field can be set at the same time. Setting any member of the oneof automatically clears all other members. .. _oneof: ### [OutputConfig](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.OutputConfig) The desired output location. .. _oneof: ### [RouteModifiers](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.RouteModifiers) Encapsulates a set of optional conditions to satisfy when calculating vehicle routes. This is similar to `RouteModifiers` in the Google Maps Platform API; see: . ### [Shipment](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Shipment) The shipment of a single item, from one of its pickups to one of its deliveries. For the shipment to be considered as performed, a unique vehicle must visit one of its pickup locations (and decrease its spare capacities accordingly), then visit one of its delivery locations later on (and therefore re-increase its spare capacities accordingly). .. _oneof: ### [Load](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Shipment.Load) When performing a visit, a predefined amount may be added to the vehicle load if it's a pickup, or subtracted if it's a delivery. This message defines such amount. See load_demands. ### [LoadDemandsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Shipment.LoadDemandsEntry) The abstract base class for a message. ### [VisitRequest](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Shipment.VisitRequest) Request for a visit which can be done by a vehicle: it has a geo-location (or two, see below), opening and closing times represented by time windows, and a service duration time (time spent by the vehicle once it has arrived to pickup or drop off goods). ### [LoadDemandsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Shipment.VisitRequest.LoadDemandsEntry) The abstract base class for a message. ### [ShipmentModel](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel) A shipment model contains a set of shipments which must be performed by a set of vehicles, while minimizing the overall cost, which is the sum of: - the cost of routing the vehicles (sum of cost per total time, cost per travel time, and fixed cost over all vehicles). - the unperformed shipment penalties. - the cost of the global duration of the shipments .. _oneof: ### [BreakRule](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.BreakRule) Deprecated: Use top level BreakRule instead. Rules to generate time breaks for a vehicle (e.g. lunch breaks). A break is a contiguous period of time during which the vehicle remains idle at its current position and cannot perform any visit. A break may occur: - during the travel between two visits (which includes the time right before or right after a visit, but not in the middle of a visit), in which case it extends the corresponding transit time between the visits - before the vehicle start (the vehicle may not start in the middle of a break), in which case it does not affect the vehicle start time. - after the vehicle end (ditto, with the vehicle end time). ### [BreakRequest](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.BreakRule.BreakRequest) The sequence of breaks (i.e. their number and order) that apply to each vehicle must be known beforehand. The repeated `BreakRequest`\\ s define that sequence, in the order in which they must occur. Their time windows (`earliest_start_time` / `latest_start_time`) may overlap, but they must be compatible with the order (this is checked). ### [FrequencyConstraint](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.BreakRule.FrequencyConstraint) One may further constrain the frequency and duration of the breaks specified above, by enforcing a minimum break frequency, such as "There must be a break of at least 1 hour every 12 hours". Assuming that this can be interpreted as "Within any sliding time window of 12h, there must be at least one break of at least one hour", that example would translate to the following `FrequencyConstraint`: :: { min_break_duration { seconds: 3600 } # 1 hour. max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11). } The timing and duration of the breaks in the solution will respect all such constraints, in addition to the time windows and minimum durations already specified in the `BreakRequest`. A `FrequencyConstraint` may in practice apply to non-consecutive breaks. For example, the following schedule honors the "1h every 12h" example: :: 04:00 vehicle start .. performing travel and visits .. 09:00 1 hour break 10:00 end of the break .. performing travel and visits .. 12:00 20-min lunch break 12:20 end of the break .. performing travel and visits .. 21:00 1 hour break 22:00 end of the break .. performing travel and visits .. 23:59 vehicle end ### [DurationDistanceMatrix](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.DurationDistanceMatrix) Specifies a duration and distance matrix from visit and vehicle start locations to visit and vehicle end locations. ### [Row](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.DurationDistanceMatrix.Row) Specifies a row of the duration and distance matrix. ### [PrecedenceRule](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentModel.PrecedenceRule) A precedence rule between two events (each event is the pickup or the delivery of a shipment): the "second" event has to start at least `offset_duration` after "first" has started. Several precedences can refer to the same (or related) events, e.g., "pickup of B happens after delivery of A" and "pickup of C happens after pickup of B". Furthermore, precedences only apply when both shipments are performed and are otherwise ignored. .. _oneof: ### [ShipmentRoute](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.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 \| \| \| \| \|\| \|\| \| \| \| \| \| \| \|\| --++---++--\> ### [Break](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Break) Data representing the execution of a break. ### [Delay](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Delay) Deprecated: Use ShipmentRoute.Transition.delay_duration instead. Time interval spent on the route resulting from a TransitionAttributes.delay. ### [EncodedPolyline](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.EncodedPolyline) The encoded representation of a polyline. More information on polyline encoding can be found here: . ### [RouteCostsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.RouteCostsEntry) The abstract base class for a message. ### [Transition](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Transition) Transition between two events on the route. See the description of ShipmentRoute. If the vehicle does not have a `start_location` and/or `end_location`, the corresponding travel metrics are 0. ### [VehicleLoadsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Transition.VehicleLoadsEntry) The abstract base class for a message. ### [TravelStep](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.TravelStep) Deprecated: Use ShipmentRoute.Transition instead. Travel between each visit along the route: from the vehicle's `start_location` to the first visit's `arrival_location`, then from the first visit's `departure_location` to the second visit's `arrival_location`, and so on until the vehicle's `end_location`. This accounts only for the actual travel between visits, not counting the waiting time, the time spent performing a visit, nor the distance covered during a visit. Invariant: `travel_steps_size() == visits_size() + 1`. If the vehicle does not have a start_ and/or end_location, the corresponding travel metrics are 0 and/or empty. ### [VehicleLoad](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.VehicleLoad) Reports the actual load of the vehicle at some point along the route, for a given type (see Transition.vehicle_loads). ### [Visit](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Visit) A visit performed during a route. This visit corresponds to a pickup or a delivery of a `Shipment`. ### [LoadDemandsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentRoute.Visit.LoadDemandsEntry) The abstract base class for a message. ### [ShipmentTypeIncompatibility](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentTypeIncompatibility) Specifies incompatibilties between shipments depending on their shipment_type. The appearance of incompatible shipments on the same route is restricted based on the incompatibility mode. ### [IncompatibilityMode](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentTypeIncompatibility.IncompatibilityMode) Modes defining how the appearance of incompatible shipments are restricted on the same route. - If both are pickups only (no deliveries) or deliveries only (no pickups), they cannot share the same vehicle at all. - If one of the shipments has a delivery and the other a pickup, the two shipments can share the same vehicle iff the former shipment is delivered before the latter is picked up. ### [ShipmentTypeRequirement](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentTypeRequirement) Specifies requirements between shipments based on their shipment_type. The specifics of the requirement are defined by the requirement mode. ### [RequirementMode](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.ShipmentTypeRequirement.RequirementMode) Modes defining the appearance of dependent shipments on a route. A "dependent" shipment pickup must therefore have either: - A delivery-only "required" shipment delivered on the route after, or - A "required" shipment picked up on the route before it, and if the "required" shipment has a delivery, this delivery must be performed after the "dependent" shipment's pickup. IN_SAME_VEHICLE_AT_DELIVERY_TIME (3): Same as before, except the "dependent" shipments need to have a "required" shipment on their vehicle at the time of their *delivery*. ### [SkippedShipment](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.SkippedShipment) Specifies details of unperformed shipments in a solution. For trivial cases and/or if we are able to identify the cause for skipping, we report the reason here. ### [Reason](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.SkippedShipment.Reason) If we can explain why the shipment was skipped, reasons will be listed here. If the reason is not the same for all vehicles, `reason` will have more than 1 element. A skipped shipment cannot have duplicate reasons, i.e. where all fields are the same except for `example_vehicle_index`. Example: :: reasons { code: DEMAND_EXCEEDS_VEHICLE_CAPACITY example_vehicle_index: 1 example_exceeded_capacity_type: "Apples" } reasons { code: DEMAND_EXCEEDS_VEHICLE_CAPACITY example_vehicle_index: 3 example_exceeded_capacity_type: "Pears" } reasons { code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT example_vehicle_index: 1 } The skipped shipment is incompatible with all vehicles. The reasons may be different for all vehicles but at least one vehicle's "Apples" capacity would be exceeded (including vehicle 1), at least one vehicle's "Pears" capacity would be exceeded (including vehicle 3) and at least one vehicle's distance limit would be exceeded (including vehicle 1). .. _oneof: ### [Code](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.SkippedShipment.Reason.Code) Code identifying the reason type. The order here is meaningless. In particular, it gives no indication of whether a given reason will appear before another in the solution, if both apply. Note that for this computation we use the geodesic distances. CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT (4): The minimum time necessary to perform this shipment, including travel time, wait time and service time exceeds the vehicle's `route_duration_limit`. Note: travel time is computed in the best-case scenario, namely as geodesic distance x 36 m/s (roughly 130 km/hour). CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT (5): Same as above but we only compare minimum travel time and the vehicle's `travel_duration_limit`. CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS (6): The vehicle cannot perform this shipment in the best-case scenario (see `CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT` for time computation) if it starts at its earliest start time: the total time would make the vehicle end after its latest end time. VEHICLE_NOT_ALLOWED (7): The `allowed_vehicle_indices` field of the shipment is not empty and this vehicle does not belong to it. ### [TimeWindow](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.TimeWindow) Time windows constrain the time of an event, such as the arrival time at a visit, or the start and end time of a vehicle. Hard time window bounds, `start_time` and `end_time`, enforce the earliest and latest time of the event, such that `start_time <= event_time <= end_time`. The soft time window lower bound, `soft_start_time`, expresses a preference for the event to happen at or after `soft_start_time` by incurring a cost proportional to how long before soft_start_time the event occurs. The soft time window upper bound, `soft_end_time`, expresses a preference for the event to happen at or before `soft_end_time` by incurring a cost proportional to how long after `soft_end_time` the event occurs. `start_time`, `end_time`, `soft_start_time` and `soft_end_time` should be within the global time limits (see ShipmentModel.global_start_time and ShipmentModel.global_end_time) and should respect: :: 0 <= `start_time` <= `soft_start_time` <= `end_time` and 0 <= `start_time` <= `soft_end_time` <= `end_time`. .. _oneof: ### [TransitionAttributes](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.TransitionAttributes) Specifies attributes of transitions between two consecutive visits on a route. Several `TransitionAttributes` may apply to the same transition: in that case, all extra costs add up and the strictest constraint or limit applies (following natural "AND" semantics). ### [Vehicle](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle) Models a vehicle in a shipment problem. Solving a shipment problem will build a route starting from `start_location` and ending at `end_location` for this vehicle. A route is a sequence of visits (see `ShipmentRoute`). .. _oneof: ### [DurationLimit](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.DurationLimit) A limit defining a maximum duration of the route of a vehicle. It can be either hard or soft. When a soft limit field is defined, both the soft max threshold and its associated cost must be defined together. .. _oneof: ### [ExtraVisitDurationForVisitTypeEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.ExtraVisitDurationForVisitTypeEntry) The abstract base class for a message. ### [LoadLimit](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.LoadLimit) Defines a load limit applying to a vehicle, e.g. "this truck may only carry up to 3500 kg". See load_limits. .. _oneof: ### [Interval](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.LoadLimit.Interval) Interval of acceptable load amounts. .. _oneof: ### [LoadLimitsEntry](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.LoadLimitsEntry) The abstract base class for a message. ### [TravelMode](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.TravelMode) Travel modes which can be used by vehicles. These should be a subset of the Google Maps Platform Routes Preferred API travel modes, see: . ### [UnloadingPolicy](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Vehicle.UnloadingPolicy) Policy on how a vehicle can be unloaded. Applies only to shipments having both a pickup and a delivery. Other shipments are free to occur anywhere on the route independent of `unloading_policy`. ### [Waypoint](https://docs.cloud.google.com/python/docs/reference/optimization/latest/google.cloud.optimization_v1.types.Waypoint) Encapsulates a waypoint. Waypoints mark arrival and departure locations of VisitRequests, and start and end locations of Vehicles. This message has `oneof`_ fields (mutually exclusive fields). For each oneof, at most one member field can be set at the same time. Setting any member of the oneof automatically clears all other members. .. _oneof: