OptimizeToursRequest(mapping=None, *, ignore_unknown_fields=False, **kwargs)Request to be given to a tour optimization solver which defines the shipment model to solve as well as optimization parameters.
.. _oneof: https://proto-plus-python.readthedocs.io/en/stable/fields.html#oneofs-mutually-exclusive-fields
Attributes | |
|---|---|
| Name | Description |
parent |
str
Required. Target project and location to make a call. Format: projects/{project-id}/locations/{location-id}.
If no location is specified, a region will be chosen
automatically.
|
timeout |
google.protobuf.duration_pb2.Duration
If this timeout is set, the server returns a response before the timeout period has elapsed or the server deadline for synchronous requests is reached, whichever is sooner. For asynchronous requests, the server will generate a solution (if possible) before the timeout has elapsed. |
model |
google.cloud.optimization_v1.types.ShipmentModel
Shipment model to solve. |
solving_mode |
google.cloud.optimization_v1.types.OptimizeToursRequest.SolvingMode
By default, the solving mode is DEFAULT_SOLVE (0).
|
search_mode |
google.cloud.optimization_v1.types.OptimizeToursRequest.SearchMode
Search mode used to solve the request. |
injected_first_solution_routes |
MutableSequence[google.cloud.optimization_v1.types.ShipmentRoute]
Guide the optimization algorithm in finding a first solution that is similar to a previous solution. The model is constrained when the first solution is built. Any shipments not performed on a route are implicitly skipped in the first solution, but they may be performed in successive solutions. The solution must satisfy some basic validity assumptions: - for all routes, vehicle_index must be in range and
not be duplicated.
- for all visits, shipment_index and
visit_request_index must be in range.
- a shipment may only be referenced on one route.
- the pickup of a pickup-delivery shipment must be
performed before the delivery.
- no more than one pickup alternative or delivery
alternative of a shipment may be performed.
- for all routes, times are increasing (i.e.,
vehicle_start_time <= visits[0].start_time=""><= visits[1].start_time="" ...=""><=>).
- a shipment may only be performed on a vehicle that is
allowed. A vehicle is allowed if
Shipment.allowed_vehicle_indices
is empty or its vehicle_index is included in
Shipment.allowed_vehicle_indices.
If the injected solution is not feasible, a validation error
is not necessarily returned and an error indicating
infeasibility may be returned instead.
|
injected_solution_constraint |
google.cloud.optimization_v1.types.InjectedSolutionConstraint
Constrain the optimization algorithm to find a final solution that is similar to a previous solution. For example, this may be used to freeze portions of routes which have already been completed or which are to be completed but must not be modified. If the injected solution is not feasible, a validation error is not necessarily returned and an error indicating infeasibility may be returned instead. |
refresh_details_routes |
MutableSequence[google.cloud.optimization_v1.types.ShipmentRoute]
If non-empty, the given routes will be refreshed, without modifying their underlying sequence of visits or travel times: only other details will be updated. This does not solve the model. As of 2020/11, this only populates the polylines of non-empty routes and requires that populate_polylines is
true.
The route_polyline fields of the passed-in routes may be
inconsistent with route transitions.
This field must not be used together with
injected_first_solution_routes or
injected_solution_constraint.
Shipment.ignore and Vehicle.ignore have no effect on
the behavior. Polylines are still populated between all
visits in all non-empty routes regardless of whether the
related shipments or vehicles are ignored.
|
interpret_injected_solutions_using_labels |
bool
If true: - uses ShipmentRoute.vehicle_label instead of vehicle_index to match routes in an
injected solution with vehicles in the request; reuses
the mapping of original
ShipmentRoute.vehicle_index
to new
ShipmentRoute.vehicle_index
to update
ConstraintRelaxation.vehicle_indices
if non-empty, but the mapping must be unambiguous (i.e.,
multiple ShipmentRoute\ s must not share the same
original vehicle_index).
- uses
ShipmentRoute.Visit.shipment_label
instead of shipment_index to match visits in an
injected solution with shipments in the request;
- uses
SkippedShipment.label
instead of
SkippedShipment.index
to match skipped shipments in the injected solution with
request shipments.
This interpretation applies to the
injected_first_solution_routes,
injected_solution_constraint, and
refresh_details_routes fields. It can be used when
shipment or vehicle indices in the request have changed
since the solution was created, perhaps because shipments or
vehicles have been removed from or added to the request.
If true, labels in the following categories must appear at
most once in their category:
- Vehicle.label
in the request;
- Shipment.label
in the request;
- ShipmentRoute.vehicle_label
in the injected solution;
- SkippedShipment.label
and
ShipmentRoute.Visit.shipment_label
in the injected solution (except pickup/delivery visit
pairs, whose shipment_label must appear twice).
If a vehicle_label in the injected solution does not
correspond to a request vehicle, the corresponding route is
removed from the solution along with its visits. If a
shipment_label in the injected solution does not
correspond to a request shipment, the corresponding visit is
removed from the solution. If a
SkippedShipment.label
in the injected solution does not correspond to a request
shipment, the SkippedShipment is removed from the
solution.
Removing route visits or entire routes from an injected
solution may have an effect on the implied constraints,
which may lead to change in solution, validation errors, or
infeasibility.
NOTE: The caller must ensure that each
Vehicle.label
(resp.
Shipment.label)
uniquely identifies a vehicle (resp. shipment) entity used
across the two relevant requests: the past request that
produced the OptimizeToursResponse used in the injected
solution and the current request that includes the injected
solution. The uniqueness checks described above are not
enough to guarantee this requirement.
|
consider_road_traffic |
bool
Consider traffic estimation in calculating ShipmentRoute
fields
Transition.travel_duration,
Visit.start_time,
and vehicle_end_time; in setting the
ShipmentRoute.has_traffic_infeasibilities
field, and in calculating the
OptimizeToursResponse.total_cost
field.
|
populate_polylines |
bool
If true, polylines will be populated in response ShipmentRoute\ s.
|
populate_transition_polylines |
bool
If true, polylines will be populated in response ShipmentRoute.transitions. Note that in this case, the polylines will also be populated in the deprecated travel_steps.
|
allow_large_deadline_despite_interruption_risk |
bool
If this is set, then the request can have a deadline (see https://grpc.io/blog/deadlines) of up to 60 minutes. Otherwise, the maximum deadline is only 30 minutes. Note that long-lived requests have a significantly larger (but still small) risk of interruption. |
use_geodesic_distances |
bool
If true, travel distances will be computed using geodesic distances instead of Google Maps distances, and travel times will be computed using geodesic distances with a speed defined by geodesic_meters_per_second.
|
geodesic_meters_per_second |
float
When use_geodesic_distances is true, this field must be
set and defines the speed applied to compute travel times.
Its value must be at least 1.0 meters/seconds.
This field is a member of oneof_ _geodesic_meters_per_second.
|
max_validation_errors |
int
Truncates the number of validation errors returned. These errors are typically attached to an INVALID_ARGUMENT error payload as a BadRequest error detail (https://cloud.google.com/apis/design/errors#error_details), unless solving_mode=VALIDATE_ONLY: see the OptimizeToursResponse.validation_errors field. This defaults to 100 and is capped at 10,000. This field is a member of oneof_ _max_validation_errors.
|
label |
str
Label that may be used to identify this request, reported back in the OptimizeToursResponse.request_label. |
populate_travel_step_polylines |
bool
Deprecated: Use OptimizeToursRequest.populate_transition_polylines instead. If true, polylines will be populated in response ShipmentRoute.transitions. Note that in this case, the polylines will also be populated in the deprecated travel_steps.
|
Classes
SearchMode
SearchMode(value)Mode defining the behavior of the search, trading off latency versus solution quality. In all modes, the global request deadline is enforced.
Values:
SEARCH_MODE_UNSPECIFIED (0):
Unspecified search mode, equivalent to RETURN_FAST.
RETURN_FAST (1):
Stop the search after finding the first good
solution.
CONSUME_ALL_AVAILABLE_TIME (2):
Spend all the available time to search for
better solutions.
SolvingMode
SolvingMode(value)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.
Values:
DEFAULT_SOLVE (0):
Solve the model.
VALIDATE_ONLY (1):
Only validates the model without solving it: populates as
many
OptimizeToursResponse.validation_errors
as possible.
DETECT_SOME_INFEASIBLE_SHIPMENTS (2):
Only populates
OptimizeToursResponse.validation_errors
or
OptimizeToursResponse.skipped_shipments,
and doesn't actually solve the rest of the request
(status and routes are unset in the response). If
infeasibilities in injected_solution_constraint routes
are detected they are populated in the
OptimizeToursResponse.validation_errors
field and
OptimizeToursResponse.skipped_shipments
is left empty.
*IMPORTANT*: not all infeasible shipments are returned here,
but only the ones that are detected as infeasible during
preprocessing.