OptimizeToursResponse

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

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

object (ShipmentRoute)

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

string

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

object (SkippedShipment)

רשימת כל המשלוחים שדילגתם עליהם.
validationErrors[]

object (OptimizeToursValidationError)

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

object (OptimizeToursRequest)

במקרים מסוימים אנחנו משנים את הבקשה הנכנסת לפני שאנחנו פותרים אותה, למשל מוסיפים עלויות. אם solvingMode == TRANSFORM_AND_RETURN_REQUEST, הבקשה ששונתה מוחזרת כאן.

ניסיוני: פרטים נוספים זמינים בכתובת https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request.
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 (ברוב המקרים) או יותר שדות. לדוגמה, כדי להתייחס לאיסוף הראשון של משלוח מספר 2 באמצעות כלי רכב מספר 4, אפשר להשתמש בפורמט הבא:

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.

הפלט שנוצר תמיד יהיה בפורמט RFC 3339, עם נורמליזציה של Z ושימוש ב-0, 3, 6 או 9 ספרות אחרי הנקודה. אפשר להשתמש גם בהיסטים אחרים חוץ מ-Z. דוגמאות: "2014-10-02T15:01:23Z", ‏ "2014-10-02T15:01:23.045123456Z" או "2014-10-02T15:01:23+05:30".
latestVehicleEndTime

string (Timestamp format)

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

הפלט שנוצר תמיד יהיה בפורמט RFC 3339, עם נורמליזציה של Z ושימוש ב-0, 3, 6 או 9 ספרות אחרי הנקודה. אפשר להשתמש גם בהיסטים אחרים חוץ מ-Z. דוגמאות: "2014-10-02T15:01:23Z", ‏ "2014-10-02T15:01:23.045123456Z" או "2014-10-02T15:01:23+05:30".
costs

map (key: string, value: number)

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

number

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