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) पेयर मिल सकता है, क्योंकि नई गड़बड़ी ने पुरानी गड़बड़ी को छिपा दिया है. उदाहरण के लिए, "MULTIPLE ERRORS" देखें.
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

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

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

string

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

FieldReference

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

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 का इस्तेमाल करता है. इसमें जनरेट किया गया आउटपुट हमेशा 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 में मौजूद, इस्तेमाल की गई सभी गाड़ियों के लिए नीलामी खत्म होने के सबसे नए समय के हिसाब से तय किया जाता है.

यह आरएफ़सी 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

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