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.
JSON representation |
---|
{ "routes": [ { object ( |
Fields | |
---|---|
routes[] |
Routes computed for each vehicle; the i-th route corresponds to the i-th vehicle in the model. |
request |
Copy of the |
skipped |
The list of all shipments skipped. |
validation |
List of all the validation errors that we were able to detect independently. See the "MULTIPLE ERRORS" explanation for the |
metrics |
Duration, distance and usage metrics for this solution. |
OptimizeToursValidationError
Describes an error or warning encountered when validating an OptimizeToursRequest
.
JSON representation |
---|
{
"code": integer,
"displayName": string,
"fields": [
{
object ( |
Fields | |
---|---|
code |
A validation error is defined by the pair ( The fields following this section provide more context about the error. MULTIPLE ERRORS: When there are multiple errors, the validation process tries to output several of them. Much like a compiler, this is an imperfect process. Some validation errors will be "fatal", meaning that they stop the entire validation process. This is the case for STABILITY: |
display |
The error display name. |
fields[] |
An error context may involve 0, 1 (most of the time) or more fields. For example, referring to vehicle #4 and shipment #2's first pickup can be done as follows:
Note, however, that the cardinality of |
error |
Human-readable string describing the error. There is a 1:1 mapping between STABILITY: Not stable: the error message associated to a given |
offending |
May contain the value(s) of the field(s). This is not always available. You should absolutely not rely on it and use it only for manual model debugging. |
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 startTimeWindows
of vehicle #5 using:
name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }
We however omit top-level entities such as OptimizeToursRequest
or ShipmentModel
to avoid crowding the message.
JSON representation |
---|
{ "name": string, "subField": { object ( |
Fields | |
---|---|
name |
Name of the field, e.g., "vehicles". |
sub |
Recursively nested sub-field, if needed. |
Union field
|
|
index |
Index of the field if repeated. |
key |
Key if the field is a map. |
Metrics
Overall metrics, aggregated over all routes.
JSON representation |
---|
{
"aggregatedRouteMetrics": {
object ( |
Fields | |
---|---|
aggregated |
Aggregated over the routes. Each metric is the sum (or max, for loads) over all |
skipped |
Number of mandatory shipments skipped. |
used |
Number of vehicles used. Note: if a vehicle route is empty and |
earliest |
The earliest start time for a used vehicle, computed as the minimum over all used vehicles of A timestamp in RFC3339 UTC "Zulu" format, with nanosecond resolution and up to nine fractional digits. Examples: |
latest |
The latest end time for a used vehicle, computed as the maximum over all used vehicles of A timestamp in RFC3339 UTC "Zulu" format, with nanosecond resolution and up to nine fractional digits. Examples: |
costs |
Cost of the solution, broken down by cost-related request fields. The keys are proto paths, relative to the input OptimizeToursRequest, e.g. "model.shipments.pickups.cost", and the values are the total cost generated by the corresponding cost field, aggregated over the whole solution. In other words, costs["model.shipments.pickups.cost"] is the sum of all pickup costs over the solution. All costs defined in the model are reported in detail here with the exception of costs related to TransitionAttributes that are only reported in an aggregated way as of 2022/01. |
total |
Total cost of the solution. The sum of all values in the costs map. |