Method: projects.optimizeTours

यह नीति, ShipmentModel वाला OptimizeToursRequest भेजता है. साथ ही, ShipmentRoute वाला OptimizeToursResponse दिखाता है. ये उन रास्तों के सेट होते हैं जिन पर वाहन इस्तेमाल करते हैं, जिससे कुल लागत कम होती है.

एक ShipmentModel मॉडल में मुख्य रूप से Shipments शामिल होते हैं, जिन्हें लागू करने की ज़रूरत होती है और Vehicle वे जिनका इस्तेमाल Shipment के ट्रांसपोर्ट के लिए किया जा सकता है. ShipmentRoute, Vehicle को Shipment असाइन करते हैं. खास तौर पर, वे हर वाहन के लिए Visit की एक सीरीज़ असाइन करते हैं, जिसमें Visit VisitRequest से जुड़ा होता है, जो Shipment के लिए पिक अप या डिलीवरी है.

इसका लक्ष्य Vehicle के लिए ShipmentRoute का एक असाइनमेंट उपलब्ध कराना है, जो ShipmentModel में तय की गई कुल लागत को कम करता है.

एचटीटीपी अनुरोध

POST https://routeoptimization.googleapis.com/v1/{parent=projects/*}:optimizeTours

यह यूआरएल gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल करता है.

पाथ के पैरामीटर

पैरामीटर
parent

string

ज़रूरी है. कॉल करने के लिए, प्रोजेक्ट या जगह को टारगेट करें.

फ़ॉर्मैट: * projects/{project-id} * projects/{project-id}/locations/{location-id}

अगर कोई जगह तय नहीं की गई है, तो क्षेत्र अपने-आप चुन लिया जाएगा.

अनुरोध का मुख्य भाग

अनुरोध के मुख्य हिस्से में, इस तरह का डेटा शामिल होता है:

जेएसओएन के काेड में दिखाना 
{
  "timeout": string,
  "model": {
    object (ShipmentModel)
  },
  "solvingMode": enum (SolvingMode),
  "searchMode": enum (SearchMode),
  "injectedFirstSolutionRoutes": [
    {
      object (ShipmentRoute)
    }
  ],
  "injectedSolutionConstraint": {
    object (InjectedSolutionConstraint)
  },
  "refreshDetailsRoutes": [
    {
      object (ShipmentRoute)
    }
  ],
  "interpretInjectedSolutionsUsingLabels": boolean,
  "considerRoadTraffic": boolean,
  "populatePolylines": boolean,
  "populateTransitionPolylines": boolean,
  "allowLargeDeadlineDespiteInterruptionRisk": boolean,
  "useGeodesicDistances": boolean,
  "label": string,
  "geodesicMetersPerSecond": number,
  "maxValidationErrors": integer
}
फ़ील्ड
timeout

string (Duration format)

अगर यह टाइम आउट सेट किया जाता है, तो सर्वर टाइम आउट की अवधि खत्म होने से पहले या सिंक करने के अनुरोधों की समयसीमा खत्म होने से पहले जवाब देता है. इन दोनों में से जो भी पहले हो.

एसिंक्रोनस अनुरोधों के लिए, अगर संभव हो, तो सर्वर टाइम आउट की अवधि खत्म होने से पहले समाधान जनरेट करेगा.

सेकंड में दी गई अवधि, जिसमें नौ भिन्नांक हो सकते हैं. साथ ही, यह 's' पर खत्म होता है. उदाहरण: "3.5s".
model

object (ShipmentModel)

हल करने के लिए शिपमेंट मॉडल.
solvingMode

enum (SolvingMode)

डिफ़ॉल्ट रूप से, समाधान मोड DEFAULT_SOLVE (0) होता है.
searchMode

enum (SearchMode)

अनुरोध का जवाब देने के लिए, खोज मोड का इस्तेमाल किया जाता है.
injectedFirstSolutionRoutes[]

object (ShipmentRoute)

पिछले सलूशन से मिलता-जुलता पहला सलूशन ढूंढने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम की मदद लें.

पहला सलूशन बनाते समय, मॉडल सीमित होता है. अगर किसी रास्ते पर शिपिंग नहीं की जाती है, तो पहले सलूशन में शिपिंग को छोड़ दिया जाता है. हालांकि, बाद के समाधान के तौर पर उन शिपमेंट को भी बार-बार इस्तेमाल किया जा सकता है.

समाधान को कुछ बुनियादी मान्यताओं के हिसाब से बनाया जाना चाहिए:

  • सभी रास्तों के लिए, vehicleIndex रेंज में होना चाहिए और उसका डुप्लीकेट नहीं होना चाहिए.
  • सभी विज़िट के लिए, shipmentIndex और visitRequestIndex रेंज में होनी चाहिए.
  • शिपमेंट का संदर्भ सिर्फ़ एक रूट पर दिया जा सकता है.
  • पिकअप-डिलीवरी वाले शिपमेंट को, डिलीवरी से पहले ही पिकअप कर लिया जाना चाहिए.
  • किसी शिपमेंट को पिकअप करने के एक से ज़्यादा विकल्प या डिलीवरी नहीं की जा सकती.
  • सभी रास्तों के लिए, समय बढ़ रहा है (जैसे, vehicleStartTime <= visits[0].start_time <= visits[1].start_time ... <= vehicleEndTime).
  • शिपमेंट सिर्फ़ ऐसे वाहन पर ही परफ़ॉर्म किया जा सकता है जिसे अनुमति मिली हो. अगर Shipment.allowed_vehicle_indices खाली है या उसका vehicleIndex Shipment.allowed_vehicle_indices में शामिल है, तो वाहन की अनुमति है.

अगर इंजेक्ट किया गया सलूशन काम नहीं करता है, तो ज़रूरी नहीं है कि पुष्टि करने के दौरान कोई गड़बड़ी दिखे. इसके बजाय, गड़बड़ी दिखाने वाली गड़बड़ी दिख सकती है.
injectedSolutionConstraint

object (InjectedSolutionConstraint)

पिछले समाधान से मिलता-जुलता आखिरी हल खोजने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम पर पाबंदी लगाएं. उदाहरण के लिए, इसका इस्तेमाल उन रास्तों को फ़्रीज़ करने के लिए किया जा सकता है जो पहले ही पूरे हो चुके हैं या जिन्हें पूरा किया जाना है, लेकिन उनमें बदलाव नहीं किया गया है.

अगर इंजेक्ट किया गया सलूशन काम नहीं करता है, तो ज़रूरी नहीं है कि पुष्टि करने के दौरान कोई गड़बड़ी दिखे. इसके बजाय, गड़बड़ी दिखाने वाली गड़बड़ी दिख सकती है.
refreshDetailsRoutes[]

object (ShipmentRoute)

अगर रास्ते खाली नहीं हैं, तो दिए गए रूट को रीफ़्रेश कर दिया जाएगा. विज़िट के क्रम या यात्रा में लगने वाले समय के क्रम में बदलाव किए बिना, सिर्फ़ अन्य जानकारी अपडेट की जाएगी. इससे इस मॉडल का समाधान नहीं होता.

साल 2020/11 से, यह सिर्फ़ उन रास्तों की पॉलीलाइन भरता है जो खाली नहीं हैं और इसके लिए ज़रूरी है कि populatePolylines सही हो.

पास-इन रास्तों के routePolyline फ़ील्ड, रास्ते transitions से अलग हो सकते हैं.

इस फ़ील्ड का इस्तेमाल injectedFirstSolutionRoutes या injectedSolutionConstraint के साथ नहीं किया जाना चाहिए.

Shipment.ignore और Vehicle.ignore का व्यवहार पर कोई असर नहीं होता. सभी गैर-खाली रास्तों पर होने वाली सभी विज़िट के दौरान, पॉलीलाइन अपने-आप भर जाती है. इससे कोई फ़र्क़ नहीं पड़ता कि संबंधित शिपमेंट या वाहनों को अनदेखा किया गया है या नहीं.
interpretInjectedSolutionsUsingLabels

boolean

अगर सही है:

  • अनुरोध में वाहन के इंजेक्ट किए गए सॉल्यूशन में रूट का मिलान करने के लिए, vehicleIndex के बजाय ShipmentRoute.vehicle_label का इस्तेमाल किया जाता है. अगर यह खाली नहीं है, तो ConstraintRelaxation.vehicle_indices को अपडेट करने के लिए मूल ShipmentRoute.vehicle_index की मैपिंग का फिर से इस्तेमाल किया जाता है. हालांकि, मैपिंग की जानकारी साफ़ तौर पर नहीं दी जानी चाहिए. इसका मतलब है कि एक से ज़्यादा ShipmentRoute के लिए मूल vehicleIndex का इस्तेमाल नहीं किया जाना चाहिए.ShipmentRoute.vehicle_index
  • इंजेक्ट किए गए सॉल्यूशन में, अनुरोध वाले शिपमेंट के साथ विज़िट को मैच करने के लिए, shipmentIndex के बजाय ShipmentRoute.Visit.shipment_label का इस्तेमाल करता है;
  • इंजेक्ट किए गए सलूशन में, अनुरोध वाले शिपमेंट के साथ, स्किप किए गए शिपमेंट को मैच करने के लिए, SkippedShipment.index के बजाय SkippedShipment.label का इस्तेमाल किया जाता है.

यह जानकारी injectedFirstSolutionRoutes, injectedSolutionConstraint, और refreshDetailsRoutes फ़ील्ड पर लागू होती है. इसका इस्तेमाल तब किया जा सकता है, जब समाधान बनाए जाने के बाद, अनुरोध में शिपमेंट या वाहन इंडेक्स में बदलाव किए गए हों. इसकी वजह यह हो सकती है कि शिपमेंट या वाहनों को अनुरोध से हटा दिया गया हो या जोड़ दिया गया हो.

सही होने पर, नीचे दी गई कैटगरी में मौजूद लेबल अपनी कैटगरी में ज़्यादा से ज़्यादा एक बार दिखने चाहिए:

अगर इंजेक्ट किए गए घोल में मौजूद vehicleLabel, किसी वाहन के अनुरोध से मेल नहीं खाता, तो उस रूट को विज़िट के साथ सलूशन से हटा दिया जाता है. अगर इंजेक्ट किए गए सॉल्यूशन में मौजूद shipmentLabel, शिपमेंट के अनुरोध के हिसाब से नहीं है, तो उस सॉल्यूशन को उस सॉल्यूशन से हटा दिया जाता है. अगर इंजेक्ट किए गए घोल में मौजूद SkippedShipment.label, शिपमेंट के अनुरोध के मुताबिक नहीं है, तो SkippedShipment को सलूशन से हटा दिया जाता है.

इंजेक्ट किए गए सलूशन से, रूट विज़िट या पूरे रूट को हटाने से, अनुमानित पाबंदियों पर असर पड़ सकता है. इसकी वजह से समाधान में बदलाव हो सकता है, पुष्टि करने से जुड़ी गड़बड़ियां हो सकती हैं या काम न कर पाने की समस्या हो सकती है.

ध्यान दें: कॉल करने वाले (कॉलर) को यह पक्का करना होगा कि हर Vehicle.label (resp. Shipment.label) खास तौर पर ऐसे वाहन (रिस्पेक्ट शिपमेंट) इकाई की पहचान करता है जिसका इस्तेमाल इन दो काम के अनुरोधों में किया गया था: पिछला अनुरोध जिसमें इंजेक्ट किए गए सॉल्यूशन में इस्तेमाल किया गया OptimizeToursResponse बनाया गया था और मौजूदा अनुरोध जिसमें इंजेक्ट किया गया सॉल्यूशन शामिल है. इस ज़रूरी शर्त को पूरा करने के लिए, ऊपर बताई गई यूनीक वैल्यू की जांच काफ़ी नहीं है.
considerRoadTraffic

boolean

ShipmentRoute फ़ील्ड Transition.travel_duration, Visit.start_time, और vehicleEndTime का हिसाब लगाने के दौरान, ShipmentRoute.has_traffic_infeasibilities फ़ील्ड की सेटिंग और OptimizeToursResponse.total_cost फ़ील्ड का हिसाब लगाने के दौरान, ट्रैफ़िक के अनुमान का इस्तेमाल करें.
populatePolylines

boolean

सही होने पर, जवाब के तौर पर ShipmentRoute सेकंड में पॉलीलाइन अपने-आप भर जाएंगी.
populateTransitionPolylines

boolean

सही होने पर, जवाब ShipmentRoute.transitions में पॉलीलाइन अपने-आप भर जाएंगी.
allowLargeDeadlineDespiteInterruptionRisk

boolean

अगर यह नीति सेट की जाती है, तो अनुरोध की समयसीमा 60 मिनट तक की हो सकती है. इस बारे में ज़्यादा जानने के लिए, https://grpc.io/blog/deadlines पर जाएं. अगर ऐसा नहीं है, तो समयसीमा सिर्फ़ 30 मिनट की है. ध्यान दें कि लंबे समय से चल रहे अनुरोधों में रुकावट आने का जोखिम काफ़ी ज़्यादा (लेकिन अब भी कम) होता है.
useGeodesicDistances

boolean

सही होने पर, यात्रा की दूरी का हिसाब Google Maps की दूरी के बजाय, भौगोलिक दूरी का इस्तेमाल करके लगाया जाएगा. साथ ही, यात्रा में लगने वाले समय का हिसाब, geodesicMetersPerSecond में तय की गई गति के साथ जियोडेसिक दूरी का इस्तेमाल करके लगाया जाएगा.
label

string

इस अनुरोध की पहचान करने के लिए इस्तेमाल किया जाने वाला लेबल. इसकी शिकायत OptimizeToursResponse.request_label में की गई है.
geodesicMetersPerSecond

number

useGeodesicDistances के सही होने पर, इस फ़ील्ड को सेट करना ज़रूरी है. यह फ़ील्ड, यात्रा में लगने वाले समय की गणना करने के लिए लागू होने वाली गति की जानकारी देता है. इसकी वैल्यू कम से कम 1.0 मीटर/सेकंड होनी चाहिए.
maxValidationErrors

integer

पुष्टि करने में हुई गड़बड़ियों की संख्या को छोटा करता है. आम तौर पर ये गड़बड़ियां BadRequest गड़बड़ी की जानकारी (https://cloud.google.com/apis/design/errors#error_details) के रूप में, INVALID_ बतौर गड़बड़ी पेलोड के साथ अटैच की जाती हैं. इस काम के लिए, SolveMode=ValidationATE_ONLY: OptimizeToursResponse.validation_errors फ़ील्ड देखें. यह डिफ़ॉल्ट रूप से 100 पर सेट होता है और 10,000 पर सीमित होता है.

जवाब का मुख्य भाग

कामयाब रहने पर, जवाब के मुख्य हिस्से में OptimizeToursResponse का एक इंस्टेंस शामिल किया जाता है.

अनुमति के दायरे

नीचे दिए गए OAuth के लिंक की ज़रूरत हाेती है:

  • https://www.googleapis.com/auth/cloud-platform