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)

गड़बड़ी के संदर्भ में, ज़्यादातर मामलों में एक या उससे ज़्यादा फ़ील्ड शामिल हो सकते हैं. हालांकि, ऐसा भी हो सकता है कि कोई फ़ील्ड शामिल न हो. उदाहरण के लिए, वाहन #4 और शिपमेंट #2 के पहले पिकअप का रेफ़रंस इस तरह दिया जा सकता है:

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

हालांकि, ध्यान दें कि किसी गड़बड़ी कोड के लिए, fields की एलिमेंट की संख्या में बदलाव नहीं होना चाहिए.
errorMessage

string

गड़बड़ी के बारे में ऐसी जानकारी वाली स्ट्रिंग जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. code और errorMessage के बीच 1:1 मैपिंग होती है (जब कोड != "UNSPECIFIED").

स्टेबलिटी: स्टेबल नहीं है: किसी code से जुड़ा गड़बड़ी का मैसेज, समय के साथ बदल सकता है. उम्मीद है कि इससे गड़बड़ी के बारे में साफ़ तौर पर पता चलेगा. इसके बजाय, कृपया displayName और code का इस्तेमाल करें.
offendingValues

string

इसमें फ़ील्ड की वैल्यू हो सकती हैं. यह सुविधा हमेशा उपलब्ध नहीं होती. आपको इस पर बिलकुल भरोसा नहीं करना चाहिए. इसका इस्तेमाल सिर्फ़ मैन्युअल मॉडल डीबगिंग के लिए करें.

FieldReference

पुष्टि करने से जुड़ी गड़बड़ी के लिए संदर्भ बताता है. FieldReference हमेशा इस फ़ाइल में मौजूद किसी फ़ील्ड को रेफ़र करता है और एक ही हैरारकी वाले स्ट्रक्चर का पालन करता है. उदाहरण के लिए, हम वाहन #5 के startTimeWindows एलिमेंट #2 की जानकारी देने के लिए, इनका इस्तेमाल कर सकते हैं:

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

फ़ील्ड का नाम, जैसे कि "वाहन".
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 की वैल्यू 'सही है' है, तो वाहन को इस्तेमाल किया गया माना जाता है.
earliestVehicleStartTime

string (Timestamp format)

इस्तेमाल किए गए वाहन के लिए, सबसे पहले शुरू होने का समय. इसे ShipmentRoute.vehicle_start_time के सभी इस्तेमाल किए गए वाहनों के लिए, कम से कम समय के तौर पर कैलकुलेट किया जाता है.

आरएफ़सी3339 यूटीसी के "Zulu" फ़ॉर्मैट में एक टाइमस्टैंप, नैनोसेकंड रिज़ॉल्यूशन और नौ दशमलव अंकों के साथ. उदाहरण के लिए: "2014-10-02T15:01:23Z" और "2014-10-02T15:01:23.045123456Z".
latestVehicleEndTime

string (Timestamp format)

इस्तेमाल किए गए वाहन के लिए, विज्ञापन दिखाने का आखिरी समय. इसे ShipmentRoute.vehicle_end_time के सभी इस्तेमाल किए गए वाहनों के लिए, ज़्यादा से ज़्यादा समय के तौर पर कैलकुलेट किया जाता है.

आरएफ़सी3339 यूटीसी के "Zulu" फ़ॉर्मैट में एक टाइमस्टैंप, नैनोसेकंड रिज़ॉल्यूशन और नौ दशमलव अंकों के साथ. उदाहरण के लिए: "2014-10-02T15:01:23Z" और "2014-10-02T15:01:23.045123456Z".
costs

map (key: string, value: number)

सॉल्यूशन की लागत, जिसे लागत से जुड़े अनुरोध फ़ील्ड के हिसाब से बांटा गया है. इनपुट OptimizeToursRequest के हिसाब से, कुंजियां प्रोटो पाथ होती हैं, जैसे कि "model.shipments.pickups.cost". साथ ही, वैल्यू, उससे जुड़े लागत फ़ील्ड से जनरेट की गई कुल लागत होती है, जो पूरे समाधान में एग्रीगेट की जाती है. दूसरे शब्दों में, costs["model.shipments.pickups.cost"] का मतलब है, पिकअप के लिए खरीदार से लिए जाने वाले सभी शुल्कों का कुल योग. मॉडल में तय की गई सभी लागतों की जानकारी यहां दी गई है. हालांकि, TransitionAttributes से जुड़ी लागतों की जानकारी 01/2022 से सिर्फ़ एग्रीगेट तरीके से दी गई है.
totalCost

number

समाधान की कुल लागत. लागत के मैप में मौजूद सभी वैल्यू का योग.