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)
  },

  // The following is a list of mutually exclusive fields. At most one of the
  // fields will be set in a response:
  "index": integer,
  "key": string
  // End of mutually exclusive fields.
}
फ़ील्ड
name

string

फ़ील्ड का नाम, जैसे कि "vehicles".
subField

object (FieldReference)

ज़रूरत पड़ने पर, बार-बार नेस्ट किया गया सब-फ़ील्ड.
यहां ऐसे फ़ील्ड की सूची दी गई है जिनमें से सिर्फ़ एक को चुना जा सकता है. जवाब में ज़्यादा से ज़्यादा एक फ़ील्ड सेट किया जाएगा:
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

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