- एचटीटीपी अनुरोध
- पाथ पैरामीटर
- अनुरोध का मुख्य हिस्सा
- जवाब का मुख्य हिस्सा
- अनुमति पाने के लिंक
- आईएएम की अनुमतियां
यह ShipmentModel वाला OptimizeToursRequest भेजता है और ShipmentRoute वाला OptimizeToursResponse दिखाता है. इन रास्तों का सेट ऐसे रास्तों का होता है जिन पर वाहनों की मदद से कुल खर्च को कम किया जाता है.
ShipmentModel मॉडल में मुख्य रूप से ऐसे Shipment होते हैं जिन्हें पूरा करना ज़रूरी होता है. साथ ही, इसमें ऐसे Vehicle भी होते हैं जिनका इस्तेमाल Shipment को ट्रांसपोर्ट करने के लिए किया जा सकता है. ShipmentRoute, Shipment को Vehicle को असाइन करते हैं. ज़्यादा जानकारी के लिए, हर वाहन को Visit की एक सीरीज़ असाइन की जाती है. इसमें Visit, VisitRequest से जुड़ा होता है, जो Shipment के लिए पिकअप या डिलीवरी है.
इसका मकसद, ShipmentRoute को Vehicle को असाइन करना है, ताकि कुल लागत कम हो सके. लागत में ShipmentModel में बताए गए कई कॉम्पोनेंट होते हैं.
एचटीटीपी अनुरोध
POST https://routeoptimization.googleapis.com/v1/{parent=projects/*/locations/*}:optimizeTours
यूआरएल में gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल किया गया है.
पाथ पैरामीटर
| पैरामीटर | |
|---|---|
| parent | 
 ज़रूरी है. कॉल करने के लिए, प्रोजेक्ट या जगह को टारगेट करें. फ़ॉर्मैट: *  अगर कोई जगह नहीं बताई जाती है, तो कोई क्षेत्र अपने-आप चुना जाएगा. | 
अनुरोध का मुख्य भाग
अनुरोध के मुख्य भाग में, नीचे दिए गए स्ट्रक्चर वाला डेटा होता है:
| JSON के काेड में दिखाना | 
|---|
| { "timeout": string, "model": { object ( | 
| फ़ील्ड | |
|---|---|
| timeout | 
 अगर यह टाइम आउट सेट हो, तो सर्वर, टाइम आउट होने की अवधि खत्म होने या सिंक्रोनस अनुरोधों के लिए सर्वर की समयसीमा खत्म होने से पहले जवाब देता है, जो भी पहले हो. असाइनमेंट के लिए, सर्वर टाइम आउट खत्म होने से पहले ही समाधान जनरेट कर देगा. हालांकि, ऐसा सिर्फ़ तब होगा, जब यह संभव हो. सेकंड में कुल अवधि, जिसमें दशमलव के बाद नौ अंक हो सकते हैं. यह अवधि ' | 
| model | 
 शिपमेंट मॉडल को हल करना है. | 
| solvingMode | 
 डिफ़ॉल्ट रूप से, समस्या हल करने का मोड  | 
| searchMode | 
 अनुरोध का समाधान करने के लिए, सर्च मोड का इस्तेमाल किया जाता है. | 
| injectedFirstSolutionRoutes[] | 
 पहले से मौजूद समाधान से मिलता-जुलता समाधान ढूंढने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम को निर्देश दें. पहला समाधान बनाने पर, मॉडल पर पाबंदी लग जाती है. किसी रूट पर न किए गए शिपमेंट, पहले समाधान में छूट जाते हैं. हालांकि, उन्हें बाद के समाधानों में शामिल किया जा सकता है. समाधान को, मान्य मान्यता के कुछ बुनियादी अनुमानों को पूरा करना होगा: 
 अगर इंजेक्ट किया गया समाधान संभव नहीं है, तो ज़रूरी नहीं कि एक पुष्टि गड़बड़ी दिखाई गई हो और इसके बजाय, गड़बड़ी दिखाने वाली गड़बड़ी दिखाई जाए. | 
| injectedSolutionConstraint | 
 पिछले समाधान से मिलता-जुलता फ़ाइनल समाधान ढूंढने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम को सीमित करें. उदाहरण के लिए, इसका इस्तेमाल उन रास्तों के हिस्सों को फ़्रीज़ करने के लिए किया जा सकता है जो पहले ही पूरे हो चुके हैं या जिन्हें पूरा करना बाकी है, लेकिन जिनमें बदलाव नहीं करना है. अगर इंजेक्ट किया गया समाधान काम नहीं करता है, तो ज़रूरी नहीं कि पुष्टि करने से जुड़ी गड़बड़ी का मैसेज दिखे. इसके बजाय, गड़बड़ी का ऐसा मैसेज दिख सकता है जिससे पता चलता हो कि समाधान काम नहीं करता. | 
| refreshDetailsRoutes[] | 
 अगर सूची में कोई जगह है, तो दिए गए रास्ते रीफ़्रेश हो जाएंगे. हालांकि, विज़िट के क्रम या यात्रा में लगने वाले समय में कोई बदलाव नहीं होगा. सिर्फ़ अन्य जानकारी अपडेट की जाएगी. इससे मॉडल का समाधान नहीं होता. नवंबर 2020 से, यह सिर्फ़ उन रास्तों की पॉलीलाइन भरता है जिनमें कोई डेटा मौजूद होता है. साथ ही, इसके लिए  सबमिट किए गए रास्तों के  इस फ़ील्ड का इस्तेमाल  इस व्यवहार पर  | 
| interpretInjectedSolutionsUsingLabels | 
 अगर सही है: 
 यह परिभाषा  अगर सही है, तो इन कैटगरी के लेबल अपनी कैटगरी में ज़्यादा से ज़्यादा एक बार दिखने चाहिए: 
 अगर इंजेक्ट किए गए सलूशन में  इंजेक्ट किए गए सलूशन से रूट विज़िट या पूरे रूट को हटाने पर, पहले से तय की गई पाबंदियों पर असर पड़ सकता है. इसकी वजह से समाधान में बदलाव हो सकता है, पुष्टि करने से जुड़ी गड़बड़ियां हो सकती हैं या उसे पूरा न किया जा सकता हो. ध्यान दें: कॉलर को यह पक्का करना होगा कि हर  | 
| considerRoadTraffic | 
 
 | 
| populatePolylines | 
 अगर सही है, तो जवाब  | 
| populateTransitionPolylines | 
 अगर सही है, तो रिस्पॉन्स  | 
| allowLargeDeadlineDespiteInterruptionRisk | 
 अगर इसे सेट किया जाता है, तो अनुरोध करने की समयसीमा (https://grpc.io/blog/deadlines देखें) में 60 मिनट तक हो सकती है. अगर ऐसा नहीं है, तो समयसीमा खत्म होने में सिर्फ़ 30 मिनट लगेंगे. ध्यान दें कि लंबे समय तक चलने वाले अनुरोधों में रुकावट आने का जोखिम ज़्यादा होता है. हालांकि, यह जोखिम बहुत कम होता है. | 
| useGeodesicDistances | 
 अगर सही है, तो यात्रा की दूरी का हिसाब लगाने के लिए, Google Maps की दूरी के बजाय जियोडेसिक दूरी का इस्तेमाल किया जाएगा. साथ ही, यात्रा में लगने वाले समय का हिसाब,  | 
| label | 
 इस अनुरोध की पहचान करने के लिए इस्तेमाल किया जा सकने वाला लेबल, जिसकी शिकायत  | 
| geodesicMetersPerSecond | 
 जब  | 
| maxValidationErrors | 
 पुष्टि करने से जुड़ी गड़बड़ियों की संख्या को छोटा कर देता है. आम तौर पर, ये गड़बड़ियां INVALID_ARGUMENT गड़बड़ी वाले पेलोड में, BadRequest गड़बड़ी की जानकारी (https://cloud.google.com/apis/design/errors#error_details) के तौर पर अटैच होती हैं. हालांकि, ऐसा तब तक नहीं होता, जब तक solvingMode=VALIDATE_ONLY नहीं है:  | 
जवाब का मुख्य भाग
कामयाब रहने पर, जवाब के मुख्य हिस्से में OptimizeToursResponse का एक इंस्टेंस शामिल किया जाता है.
अनुमति के दायरे
नीचे दिए गए OAuth के लिंक की ज़रूरत हाेती है:
- https://www.googleapis.com/auth/cloud-platform
IAM की अनुमतियां
parent संसाधन पर, इस IAM अनुमति की ज़रूरत होती है:
- routeoptimization.locations.use
ज़्यादा जानकारी के लिए, IAM दस्तावेज़ देखें.