OptimizeToursResponse

תגובה אחרי פתרון בעיה של אופטימיזציית סיור, שמכילה את המסלולים שאחריהם של כל רכב, את המשלוחים שדילגת עליהם והעלות הכוללת של הפתרון.

ייצוג ב-JSON 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "metrics": {
    object (Metrics)
  }
}
שדות
routes[]

object (ShipmentRoute)

מסלולים שחושבו לכל רכב. המסלול ה-i תואם לרכב ה-i במודל.
requestLabel

string

עותק של OptimizeToursRequest.label, אם צוינה תווית בבקשה.
skippedShipments[]

object (SkippedShipment)

רשימה של כל המשלוחים שנדחו.
validationErrors[]

object (OptimizeToursValidationError)

רשימה של כל שגיאות האימות שזיהינו באופן עצמאי. חשוב לעיין בהסבר 'מספר שגיאות' בהודעה OptimizeToursValidationError. במקום שגיאות, יופיעו אזהרות אם הערך של solvingMode הוא DEFAULT_SOLVE.
metrics

object (Metrics)

מדדי משך זמן, מרחק ושימוש של הפתרון הזה.

OptimizeToursValidationError

מיועד לתיאור שגיאה או אזהרה שהתרחשה במהלך האימות של OptimizeToursRequest.

ייצוג ב-JSON 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
שדות
code

integer

שגיאת אימות מוגדרת על ידי הצמד (code, displayName) שתמיד נמצא.

בשדות שמופיעים אחרי הקטע הזה, מוצג הקשר נוסף לגבי השגיאה.

מספר שגיאות: כשיש כמה שגיאות, תהליך האימות מנסה לייצר פלט של כמה מהן. בדומה למהדר, זהו תהליך מושלם. חלק משגיאות האימות יהיו "קטלניות", כלומר הן יעצור את תהליך האימות כולו. זה המצב, בין היתר, בשגיאות displayName="UNSPECIFIED". שגיאות מסוימות עלולות לגרום לתהליך האימות לדלג על שגיאות אחרות.

יציבות: code ו-displayName צריכים להיות יציבים מאוד. עם זאת, קודים ושמות תצוגה חדשים עשויים להופיע לאורך זמן, וכתוצאה מכך בקשה (לא חוקית) מסוימת עשויה להניב צמד (code, displayName) שונה כי השגיאה החדשה הסתירה את השגיאה הישנה. לדוגמה, ראו 'שגיאות מרובות'.
displayName

string

השם המוצג של השגיאה.
fields[]

object (FieldReference)

הקשר של שגיאה יכול לכלול 0, 1 (בדרך כלל) או יותר שדות. לדוגמה, אפשר להתייחס לרכב מס' 4 ולאיסוף הראשון של משלוח מס' 2 באופן הבא:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

עם זאת, חשוב לזכור שהעוצמה של fields לא אמורה להשתנות עבור קוד שגיאה נתון.
errorMessage

string

מחרוזת לתיאור השגיאה, שאנשים יכולים לקרוא. יש מיפוי של 1:1 בין code לבין errorMessage (כשהקוד != "UNSPECIFIED").

יציבות: לא יציבה: הודעת השגיאה שמשויכת ל-code נתון עשויה להשתנות (אנחנו מקווים להבהיר זאת) עם הזמן. במקום זאת, יש להשתמש ב-displayName וב-code.
offendingValues

string

יכול להכיל את הערכים של השדות. האפשרות הזו לא תמיד זמינה. בשום אופן אין להסתמך על התכונה הזו ולהשתמש בה רק לצורך ניפוי באגים באופן ידני.

FieldReference

מציין את ההקשר לשגיאת האימות. השדה FieldReference תמיד מתייחס לשדה נתון בקובץ הזה, והמבנה ההיררכי שלו זהה. לדוגמה, אפשר לציין את רכיב מס' 2 של startTimeWindows ברכב מס' 5 באמצעות:

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

עם זאת, אנחנו משמיטים ישויות ברמה העליונה כמו OptimizeToursRequest או ShipmentModel כדי למנוע עומס בהודעה.

ייצוג ב-JSON 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
שדות
name

string

שם השדה, למשל "vehicles".
subField

object (FieldReference)

שדה משנה מקונן באופן רקורסיבי, אם יש צורך.

שדה איחוד index_or_key.

הערך של index_or_key יכול להיות רק אחת מהאפשרויות הבאות:
index

integer

אינדקס השדה אם חוזר על עצמו.
key

string

מפתח אם השדה הוא מפה.

מדדים

מדדים כלליים, שמצטברים מכל המסלולים.

ייצוג ב-JSON 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
שדות
aggregatedRouteMetrics

object (AggregatedMetrics)

נתון נצבר מכל הנתיבים. כל מדד הוא הסכום (או המקסימלי, לטעינות) של כל ShipmentRoute.metrics השדות בעלי אותו השם.
skippedMandatoryShipmentCount

integer

מספר המשלוחים החובה שקודם להם עברה 'דילוג'.
usedVehicleCount

integer

מספר כלי הרכב שבהם נעשה שימוש. הערה: אם מסלול הרכב ריק והערך של Vehicle.used_if_route_is_empty הוא True, הרכב נחשב כמשומש.
earliestVehicleStartTime

string (Timestamp format)

שעת ההתחלה המוקדמת ביותר של רכב משומש, המחושב כמינימום על כל כלי הרכב משומשים (ShipmentRoute.vehicle_start_time).

חותמת זמן בפורמט UTC 'Zulu' של RFC3339, עם רזולוציה של ננו-שנייה ועד תשע ספרות עשרוניות. דוגמאות: "2014-10-02T15:01:23Z" ו-"2014-10-02T15:01:23.045123456Z".
latestVehicleEndTime

string (Timestamp format)

שעת הסיום האחרונה של רכב משומש, מחושבת כערך המקסימלי של ShipmentRoute.vehicle_end_time בכל הרכבים המשומשים.

חותמת זמן בפורמט 'Zulu' בפורמט RFC3339 UTC, עם רזולוציה של ננו-שנייה ועד תשע ספרות אחרי הנקודה. דוגמאות: "2014-10-02T15:01:23Z" ו-"2014-10-02T15:01:23.045123456Z".
costs

map (key: string, value: number)

עלות הפתרון, בחלוקה לפי שדות של בקשות שקשורים לעלויות. המפתחות הם נתיבים ב-Proto, ביחס ל-OptimizeToursRequest, למשל model.shipments.pickups.cost", והערכים הם העלות הכוללת שנוצרה על ידי שדה העלות התואם, שמצטברת בכל הפתרון. במילים אחרות, costs["model.shipments.pickups.cost"] הוא הסכום של כל עלויות האיסוף בפתרון. כל העלויות שמוגדרות במודל מדווחות כאן בפירוט, למעט עלויות שקשורות ל-TransitionAttributes שמדווחות רק באופן מצטבר החל מינואר 2022.
totalCost

number

העלות הכוללת של הפתרון. הסכום של כל הערכים במפת העלויות.