Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Definiert, wie der Solver die Anfrage verarbeiten soll. In allen Modi außer VALIDATE_ONLY erhalten Sie bei einer ungültigen Anfrage den Fehler INVALID_REQUEST. Mit maxValidationErrors können Sie die Anzahl der zurückgegebenen Fehler begrenzen.
Enums
DEFAULT_SOLVE
Lösen Sie das Modell. Warnungen können unter [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] ausgegeben werden.
WICHTIG: Nicht alle nicht umsetzbaren Sendungen werden hier zurückgegeben, sondern nur die, die während der Vorverarbeitung als nicht umsetzbar erkannt werden.
TRANSFORM_AND_RETURN_REQUEST
Dieser Modus funktioniert nur, wenn ShipmentModel.objectives nicht leer ist. Die Anfrage ist nicht gelöst. Er wird nur validiert und mit Kosten gefüllt, die den angegebenen Zielvorhaben entsprechen. Weitere Informationen finden Sie in der Dokumentation zu ShipmentModel.objectives. Die Anfrage wird als OptimizeToursResponse.processed_request zurückgegeben.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-31 (UTC)."],[[["\u003cp\u003eDefines how the solver processes the request, dictating whether it solves the model, validates it, or detects infeasible shipments.\u003c/p\u003e\n"],["\u003cp\u003eOffers three modes: \u003ccode\u003eDEFAULT_SOLVE\u003c/code\u003e for solving, \u003ccode\u003eVALIDATE_ONLY\u003c/code\u003e for validation, and \u003ccode\u003eDETECT_SOME_INFEASIBLE_SHIPMENTS\u003c/code\u003e for identifying problematic shipments.\u003c/p\u003e\n"],["\u003cp\u003eIn all modes except \u003ccode\u003eVALIDATE_ONLY\u003c/code\u003e, invalid requests will return an \u003ccode\u003eINVALID_REQUEST\u003c/code\u003e error, with potential for controlling the number of error messages.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eDETECT_SOME_INFEASIBLE_SHIPMENTS\u003c/code\u003e mode focuses on pre-processing infeasibility detection without fully solving the problem.\u003c/p\u003e\n"]]],[],null,["# SolvingMode\n\nDefines 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 [maxValidationErrors](/maps/documentation/route-optimization/reference/rest/v1/projects.locations/optimizeTours#body.request_body.FIELDS.max_validation_errors) to cap the number of errors returned.\n\n| Enums ||\n|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `DEFAULT_SOLVE` | Solve the model. Warnings may be issued in \\[OptimizeToursResponse.validation_errors\\]\\[google.cloud.optimization.v1.OptimizeToursResponse.validation_errors\\]. |\n| `VALIDATE_ONLY` | Only validates the model without solving it: populates as many [OptimizeToursResponse.validation_errors](/maps/documentation/route-optimization/reference/rest/v1/OptimizeToursResponse#FIELDS.validation_errors) as possible. |\n| `DETECT_SOME_INFEASIBLE_SHIPMENTS` | Only populates [OptimizeToursResponse.validation_errors](/maps/documentation/route-optimization/reference/rest/v1/OptimizeToursResponse#FIELDS.validation_errors) or [OptimizeToursResponse.skipped_shipments](/maps/documentation/route-optimization/reference/rest/v1/OptimizeToursResponse#FIELDS.skipped_shipments), and doesn't actually solve the rest of the request (`status` and `routes` are unset in the response). If infeasibilities in `injectedSolutionConstraint` routes are detected they are populated in the [OptimizeToursResponse.validation_errors](/maps/documentation/route-optimization/reference/rest/v1/OptimizeToursResponse#FIELDS.validation_errors) field and [OptimizeToursResponse.skipped_shipments](/maps/documentation/route-optimization/reference/rest/v1/OptimizeToursResponse#FIELDS.skipped_shipments) is left empty. *IMPORTANT*: not all infeasible shipments are returned here, but only the ones that are detected as infeasible during preprocessing. |\n| `TRANSFORM_AND_RETURN_REQUEST` | This mode only works if `ShipmentModel.objectives` is not empty. The request is not solved. It is only validated and filled with costs corresponding to the given objectives. Also see the documentation of `ShipmentModel.objectives`. The resulting request is returned as `OptimizeToursResponse.processed_request`. Experimental: See \u003chttps://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request\u003e for more details. |"]]
