इंडेक्स
RouteOptimization
(इंटरफ़ेस)AggregatedMetrics
(मैसेज)BatchOptimizeToursMetadata
(मैसेज)BatchOptimizeToursRequest
(मैसेज)BatchOptimizeToursRequest.AsyncModelConfig
(मैसेज)BatchOptimizeToursResponse
(मैसेज)BreakRule
(मैसेज)BreakRule.BreakRequest
(मैसेज)BreakRule.FrequencyConstraint
(मैसेज)DataFormat
(enum)DistanceLimit
(मैसेज)GcsDestination
(मैसेज)GcsSource
(मैसेज)InjectedSolutionConstraint
(मैसेज)InjectedSolutionConstraint.ConstraintRelaxation
(मैसेज)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation
(मैसेज)InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level
(enum)InputConfig
(मैसेज)Location
(मैसेज)OptimizeToursRequest
(मैसेज)OptimizeToursRequest.SearchMode
(enum)OptimizeToursRequest.SolvingMode
(enum)OptimizeToursResponse
(मैसेज)OptimizeToursResponse.Metrics
(मैसेज)OptimizeToursValidationError
(मैसेज)OptimizeToursValidationError.FieldReference
(मैसेज)OutputConfig
(मैसेज)RouteModifiers
(मैसेज)Shipment
(मैसेज)Shipment.Load
(मैसेज)Shipment.VisitRequest
(मैसेज)ShipmentModel
(मैसेज)ShipmentModel.DurationDistanceMatrix
(मैसेज)ShipmentModel.DurationDistanceMatrix.Row
(मैसेज)ShipmentModel.PrecedenceRule
(मैसेज)ShipmentRoute
(मैसेज)ShipmentRoute.Break
(मैसेज)ShipmentRoute.EncodedPolyline
(मैसेज)ShipmentRoute.Transition
(मैसेज)ShipmentRoute.VehicleLoad
(मैसेज)ShipmentRoute.Visit
(मैसेज)ShipmentTypeIncompatibility
(मैसेज)ShipmentTypeIncompatibility.IncompatibilityMode
(enum)ShipmentTypeRequirement
(मैसेज)ShipmentTypeRequirement.RequirementMode
(enum)SkippedShipment
(मैसेज)SkippedShipment.Reason
(मैसेज)SkippedShipment.Reason.Code
(enum)TimeWindow
(मैसेज)TransitionAttributes
(मैसेज)Vehicle
(मैसेज)Vehicle.DurationLimit
(मैसेज)Vehicle.LoadLimit
(मैसेज)Vehicle.LoadLimit.Interval
(मैसेज)Vehicle.TravelMode
(enum)Vehicle.UnloadingPolicy
(enum)Waypoint
(मैसेज)
RouteOptimization
वाहन यात्राओं को ऑप्टिमाइज़ करने की सेवा.
कुछ खास तरह के फ़ील्ड के मान्य होने की अवधि:
google.protobuf.Timestamp
- समय, यूनिक्स समय के हिसाब से हैं: सेकंड 1970-01-01T00:00:00+00:00.
- सेकंड [0, 253402300799] में होने चाहिए, जैसे कि [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] में.
- nanos को अनसेट या 0 पर सेट किया जाना चाहिए.
google.protobuf.Duration
- सेकंड [0, 253402300799] में होने चाहिए, जैसे कि [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] में.
- नैनो को सेट नहीं किया जाना चाहिए या 0 पर सेट किया जाना चाहिए.
google.type.LatLng
- अक्षांश [-90.0, 90.0] में होना चाहिए.
- देशांतर [-180.0, 180.0] में होना चाहिए.
- कम से कम एक अक्षांश और देशांतर शून्य नहीं होना चाहिए.
BatchOptimizeTours |
---|
बैच के तौर पर एक या उससे ज़्यादा यह तरीका, लंबे समय तक चलने वाला ऑपरेशन (एलआरओ) है. ऑप्टिमाइज़ेशन ( उपयोगकर्ता, एलआरओ का स्टेटस देखने के लिए अगर एलआरओ का अगर एलआरओ का
|
OptimizeTours |
---|
यह फ़ंक्शन,
इसका लक्ष्य
|
AggregatedMetrics
ShipmentRoute
के लिए एग्रीगेट की गई मेट्रिक (सभी Transition
और/या Visit
(सभी ShipmentRoute
एलिमेंट पर रिस्पॉन्स) से OptimizeToursResponse
के लिए रिस्पॉन्स)
फ़ील्ड | |
---|---|
performed_shipment_count |
शिपमेंट की संख्या. ध्यान दें कि पिकअप और डिलीवरी की जोड़ी को सिर्फ़ एक बार गिना जाता है. |
travel_duration |
किसी रास्ते या समाधान के लिए, यात्रा में लगने वाला कुल समय. |
wait_duration |
किसी रूट या समाधान के लिए इंतज़ार का कुल समय. |
delay_duration |
किसी रूट या समाधान के लिए कुल देरी. |
break_duration |
किसी रूट या समाधान के लिए ब्रेक की कुल अवधि. |
visit_duration |
किसी रूट या समाधान के लिए, विज़िट की कुल अवधि. |
total_duration |
कुल अवधि, ऊपर दी गई सभी अवधियों के योग के बराबर होनी चाहिए. रास्तों के लिए, यह इन चीज़ों से भी मेल खाता है:
|
travel_distance_meters |
किसी रास्ते या समाधान के लिए, यात्रा की कुल दूरी. |
max_loads |
इस रूट पर मौजूद हर मात्रा (रिज़ॉल्यूशन समाधान) के लिए हासिल किया गया ज़्यादा से ज़्यादा लोड, सभी |
BatchOptimizeToursMetadata
इस टाइप में कोई फ़ील्ड नहीं है.
BatchOptimizeToursRequest
कॉल के लिए ऑपरेशन मेटाडेटा.
BatchOptimizeToursRequest
एसिंक्रोनस ऑपरेशन के रूप में कई बार यात्रा ऑप्टिमाइज़ करने का अनुरोध करें. हर इनपुट फ़ाइल में एक OptimizeToursRequest
और हर आउटपुट फ़ाइल में एक OptimizeToursResponse
होना चाहिए. अनुरोध में फ़ाइलों को पढ़ने/लिखने और पार्स करने की जानकारी शामिल है. सभी इनपुट और आउटपुट फ़ाइलें एक ही प्रोजेक्ट में होनी चाहिए.
फ़ील्ड | |
---|---|
parent |
ज़रूरी है. कॉल करने के लिए, प्रोजेक्ट और जगह को टारगेट करें. फ़ॉर्मैट: * अगर किसी जगह की जानकारी नहीं दी गई है, तो कोई इलाका अपने-आप चुन लिया जाएगा. |
model_configs[] |
ज़रूरी है. हर खरीदारी मॉडल की जानकारी इनपुट/आउटपुट जानकारी, जैसे कि फ़ाइल पाथ और डेटा फ़ॉर्मैट. |
AsyncModelConfig
किसी ऑप्टिमाइज़ेशन मॉडल को एसिंक्रोनस तरीके से हल करने की जानकारी.
फ़ील्ड | |
---|---|
display_name |
ज़रूरी नहीं. मॉडल को ट्रैक करने के लिए, उपयोगकर्ता किसी मॉडल के नाम का इस्तेमाल कर सकते हैं. |
input_config |
ज़रूरी है. इनपुट मॉडल के बारे में जानकारी. |
output_config |
ज़रूरी है. आउटपुट के लिए जगह की जानकारी. |
BatchOptimizeToursResponse
इस टाइप में कोई फ़ील्ड नहीं है.
BatchOptimizeToursRequest
का जवाब दिया जा रहा है. कार्रवाई पूरी होने के बाद, इसे 'लंबे समय तक चलने वाली कार्रवाई' में दिखाया जाता है.
BreakRule
वाहन के लिए ब्रेक का समय तय करने के नियम. जैसे, लंच ब्रेक. ब्रेक, लगातार चलने वाली वह अवधि होती है जिसमें वाहन अपनी मौजूदा पोज़िशन पर कोई गतिविधि नहीं करता. साथ ही, वह किसी भी जगह विज़िट नहीं कर सकता. ब्रेक मिल सकता है:
- दो विज़िट के बीच की यात्रा के दौरान (जिसमें विज़िट से ठीक पहले या ठीक बाद का समय शामिल होता है, लेकिन विज़िट के बीच का समय शामिल नहीं होता), और इस मामले में यह विज़िट के बीच का ट्रांज़िट समय बढ़ाता है,
- वाहन को चालू करने से पहले या ब्रेक के बीच में ऐसा हो सकता है कि वाहन चालू न हो. इस स्थिति में, वाहन के शुरू होने के समय पर कोई असर नहीं पड़ता.
- या वाहन खत्म होने के बाद (ठीक इसी तरह, वाहन खत्म होने के समय के साथ).
फ़ील्ड | |
---|---|
break_requests[] |
ब्रेक का क्रम. |
frequency_constraints[] |
कई |
BreakRequest
हर वाहन पर लागू होने वाले ब्रेक के क्रम (जैसे, उनका नंबर और क्रम) के बारे में पहले से पता होना चाहिए. दोहराए गए BreakRequest
उसी क्रम को तय करते हैं जिसमें वे होने चाहिए. उनकी टाइम विंडो (earliest_start_time
/ latest_start_time
) ओवरलैप हो सकती हैं, लेकिन वे ऑर्डर के हिसाब से होनी चाहिए (इसे चुना गया है).
फ़ील्ड | |
---|---|
earliest_start_time |
ज़रूरी है. ब्रेक की शुरुआत पर लोअर बाउंड (शामिल) |
latest_start_time |
ज़रूरी है. ब्रेक की शुरुआत पर ऊपरी सीमा (शामिल). |
min_duration |
ज़रूरी है. ब्रेक लेने की कम से कम अवधि. पॉज़िटिव होना चाहिए. |
FrequencyConstraint
ऊपर बताए गए ब्रेक की फ़्रीक्वेंसी और अवधि को और भी सीमित किया जा सकता है. इसके लिए, ब्रेक की कम से कम फ़्रीक्वेंसी लागू करें. जैसे, "हर 12 घंटे में कम से कम एक घंटे का ब्रेक होना चाहिए". मान लें कि इसका मतलब "12 घंटे की किसी भी स्लाइडिंग टाइम विंडो में, कम से कम एक घंटे का ब्रेक होना चाहिए" है. इस उदाहरण का अनुवाद इस FrequencyConstraint
में किया जाएगा:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
सलूशन में ब्रेक का समय और अवधि, BreakRequest
में पहले से तय की गई टाइम विंडो और कम से कम समयावधि के साथ-साथ इन सभी पाबंदियों को ध्यान में रखकर तय की जाएगी.
FrequencyConstraint
, लगातार न होने वाले ब्रेक पर लागू हो सकता है. उदाहरण के लिए, नीचे दिया गया शेड्यूल, "हर 12 घंटे में 1 घंटा" के उदाहरण के मुताबिक है:
04:00 vehicle start
.. performing travel and visits ..
09:00 1 hour break
10:00 end of the break
.. performing travel and visits ..
12:00 20-min lunch break
12:20 end of the break
.. performing travel and visits ..
21:00 1 hour break
22:00 end of the break
.. performing travel and visits ..
23:59 vehicle end
फ़ील्ड | |
---|---|
min_break_duration |
ज़रूरी है. इस शर्त के लिए, ब्रेक की कम से कम अवधि. नेगेटिव नहीं. |
max_inter_break_duration |
ज़रूरी है. रास्ते में किसी भी समयावधि का ज़्यादा से ज़्यादा स्पैन, जिसमें कम से कम |
DataFormat
इनपुट और आउटपुट फ़ाइलों के लिए डेटा फ़ॉर्मैट.
Enums | |
---|---|
DATA_FORMAT_UNSPECIFIED |
अमान्य मान, प्रारूप अनिर्दिष्ट नहीं होना चाहिए. |
JSON |
JavaScript ऑब्जेक्ट नोटेशन. |
PROTO_TEXT |
प्रोटोकॉल बफ़र का टेक्स्ट फ़ॉर्मैट. https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
तय की गई ज़्यादा से ज़्यादा दूरी तय करने वाली सीमा. यह कठोर या मुलायम हो सकता है.
अगर सॉफ़्ट लिमिट तय की गई है, तो soft_max_meters
और cost_per_kilometer_above_soft_max
, दोनों एट्रिब्यूट की वैल्यू दी जानी चाहिए. साथ ही, वैल्यू शून्य से कम होनी चाहिए.
फ़ील्ड | |
---|---|
max_meters |
हार्ड लिमिट, जो दूरी को ज़्यादा से ज़्यादा max_meters में सीमित करती है. वैल्यू की सीमा, शून्य से कम होनी चाहिए. |
soft_max_meters |
ऐसी सॉफ़्ट लिमिट, जिससे दूरी की ज़्यादा से ज़्यादा सीमा लागू नहीं होती. हालांकि, इसका उल्लंघन होने पर कीमत बढ़ जाती है. इस वजह से, मॉडल में बताई गई कीमत की वैल्यू, डिवाइस की यूनिट के हिसाब से बढ़ जाती है. अगर तय किया गया soft_max_meters max_meters से कम होना चाहिए, तो यह शून्य से कम होना चाहिए. |
cost_per_kilometer_below_soft_max |
खर्च की गई प्रति किलोमीटर, लागत
|
cost_per_kilometer_above_soft_max |
दूरी
लागत गैर-ऋणात्मक होनी चाहिए. |
GcsDestination
Google Cloud Storage की वह जगह जहां आउटपुट फ़ाइल(फ़ाइलें) लिखी जाएंगी.
फ़ील्ड | |
---|---|
uri |
ज़रूरी है. Google Cloud Storage यूआरआई. |
GcsSource
Google Cloud Storage में वह जगह जहां से इनपुट फ़ाइल को पढ़ा जाएगा.
फ़ील्ड | |
---|---|
uri |
ज़रूरी है. |
InjectedSolutionConstraint
अनुरोध में इंजेक्ट किया गया समाधान. इसमें यह जानकारी शामिल होती है कि किन विज़िट पर पाबंदी लगानी है और उन्हें कैसे लगाना है.
फ़ील्ड | |
---|---|
routes[] |
सलूशन इंजेक्ट करने के लिए रूट तय करना. हो सकता है कि ओरिजनल सलूशन से कुछ रास्ते हटा दिए जाएं. रूट और स्किप किए गए शिपमेंट, |
skipped_shipments[] |
समाधान को इंजेक्ट करने के लिए शिपमेंट को स्किप किया गया. कुछ समस्याओं को मूल समाधान से हटाया जा सकता है. |
constraint_relaxations[] |
वाहनों के शून्य या उससे ज़्यादा ग्रुप के लिए, यह बताता है कि कब और कितनी आराम करना है. अगर यह फ़ील्ड खाली है, तो वाहन के ऐसे सभी रास्ते पूरी तरह से सीमित हो जाते हैं जो खाली नहीं हैं. |
ConstraintRelaxation
वाहनों के ग्रुप के लिए, यह तय करता है कि विज़िट पर कौनसी पाबंदियां किस थ्रेशोल्ड पर और किस लेवल तक हटाई जाएंगी. skipped_shipment
फ़ील्ड में लिस्ट किए गए शिपमेंट को स्किप किया जा सकता है. इसका मतलब है कि उन्हें प्रोसेस नहीं किया जा सकता.
फ़ील्ड | |
---|---|
relaxations[] |
|
vehicle_indices[] |
वाहन के उन इंडेक्स की जानकारी देता है जिन पर विज़िट की सीमा अगर |
सुकून देने वाले
अगर relaxations
खाली है, तो routes
पर सभी विज़िट का शुरू होने का समय और क्रम पूरी तरह से सीमित होता है. साथ ही, उन रास्तों में कोई नई विज़िट नहीं डाली या जोड़ी जा सकती. साथ ही, routes
में वाहन के शुरू और खत्म होने का समय पूरी तरह सीमित होता है.ऐसा तब तक होता है, जब तक वाहन खाली न हो. इसका मतलब है कि इस पर कोई विज़िट नहीं किया गया है और मॉडल में used_if_route_is_empty
को 'गलत' पर सेट किया गया है.
relaxations(i).level
, विज़िट #j पर लागू की गई पाबंदी के लेवल के बारे में बताता है. यह लेवल इन शर्तों को पूरा करने पर लागू होता है:
route.visits(j).start_time >= relaxations(i).threshold_time
औरj + 1 >= relaxations(i).threshold_visit_count
इसी तरह, अगर वाहन इन शर्तों को पूरा करता है, तो उसे relaxations(i).level
तक चलाने की अनुमति दी जाती है:
vehicle_start_time >= relaxations(i).threshold_time
औरrelaxations(i).threshold_visit_count == 0
और वाहन का छोरrelaxations(i).level
है, अगर यह इन शर्तों के मुताबिक हो:vehicle_end_time >= relaxations(i).threshold_time
औरroute.visits_size() + 1 >= relaxations(i).threshold_visit_count
अगर कोई विज़िट, threshold_visit_count
से मिलती है या threshold_time
में एक ही level
के साथ दो relaxations
जोड़ें, तो आराम का लेवल लागू करने के लिए: एक में सिर्फ़ threshold_visit_count
सेट और दूसरे में सिर्फ़ threshold_time
सेट हो. अगर कोई विज़िट, एक से ज़्यादा relaxations
की शर्तें पूरी करती है, तो सबसे आरामदेह लेवल लागू होता है. इस वजह से, वाहन शुरू होने से लेकर रास्ते की विज़िट तक, वाहन के खत्म होने तक, आराम का लेवल ज़्यादा आसान हो जाता है. इसका मतलब है कि रास्ते के आगे बढ़ने के साथ-साथ, आराम का लेवल कम नहीं होता.
किसी भी relaxations
की थ्रेशोल्ड शर्तों को पूरा नहीं करने वाली रूट विज़िट का समय और क्रम पूरी तरह से सीमित हैं और इन क्रमों में कोई विज़िट नहीं डाली जा सकती है. इसके अलावा, अगर वाहन के शुरू या खत्म होने का समय, छूट की किसी भी शर्त को पूरा नहीं करता है, तो वाहन खाली होने तक उसका समय तय रहता है.
फ़ील्ड | |
---|---|
level |
शर्तों में ढील का वह लेवल जो |
threshold_time |
वह समय जब छूट |
threshold_visit_count |
उन विज़िट की संख्या जिनके लिए या उनके बाद, अगर यह |
लेवल
विज़िट के लिए लागू होने वाले कंस्ट्रेंट के अलग-अलग लेवल के बारे में बताता है और वे लेवल दिखाता है जो थ्रेशोल्ड की शर्तों को पूरा करने के बाद लागू होते हैं.
नीचे दी गई सूची, राहत देने के मकसद से दी गई है.
Enums | |
---|---|
LEVEL_UNSPECIFIED |
इंप्लिसिट डिफ़ॉल्ट रिलैक्सेशन लेवल: कोई भी शर्त आसानी से नहीं हटाई जाती है. इसका मतलब है कि सभी विज़िट पर पूरी तरह से पाबंदी लगी होती है.
|
RELAX_VISIT_TIMES_AFTER_THRESHOLD |
विज़िट शुरू होने का समय और वाहन के शुरू/खत्म होने का समय तय करने में ज़्यादा ज़रूरत नहीं होगी. हालांकि, हर विज़िट एक ही वाहन से जुड़ी होनी चाहिए और विज़िट के क्रम का ध्यान रखा जाना चाहिए: इनके बीच या इनसे पहले कोई विज़िट नहीं डाली जा सकती. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD |
RELAX_VISIT_TIMES_AFTER_THRESHOLD की तरह ही, लेकिन विज़िट का क्रम भी आसान है: विज़िट सिर्फ़ इस वाहन से की जा सकती हैं, लेकिन हो सकता है कि विज़िट की कोई कार्रवाई न हो. |
RELAX_ALL_AFTER_THRESHOLD |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD की तरह ही, लेकिन वाहन में भी आराम मिलता है: तय समय पर या उसके बाद, यात्रा पूरी तरह से मुफ़्त है. ऐसा भी हो सकता है कि इस दौरान, यात्रा के लिए कोई शुल्क न लिया जाए. |
InputConfig
[BatchOptimizeTours][google.maps.route बिज़नेस.v1.RouteOptimizeService.BatchOptimizeTours] के लिए कोई इनपुट मिला हो.
फ़ील्ड | |
---|---|
data_format |
ज़रूरी है. इनपुट डेटा का फ़ॉर्मैट. |
यूनियन फ़ील्ड source . ज़रूरी है. source इनमें से सिर्फ़ एक हो सकता है: |
|
gcs_source |
Google Cloud Storage की जगह. यह एक ही ऑब्जेक्ट (फ़ाइल) होना चाहिए. |
जगह
जगह को इनकैप्सुलेट करता है (भौगोलिक पॉइंट और वैकल्पिक हेडिंग).
फ़ील्ड | |
---|---|
lat_lng |
वेपॉइंट के भौगोलिक निर्देशांक. |
heading |
ट्रैफ़िक के फ़्लो की दिशा से जुड़ा कंपास हेडिंग. इस वैल्यू का इस्तेमाल सड़क के उस हिस्से के बारे में बताने के लिए किया जाता है जिसका इस्तेमाल पिकअप और ड्रॉप-ऑफ़ के लिए किया जाना है. शीर्षक का मान 0 से 360 तक हो सकता है, जहां 0 से उत्तरी दिशा की ओर जाने की आखिरी तारीख के बारे में पता चलता है, 90 शीर्षक की शुरुआत की तारीख वगैरह के बारे में बताता है. |
OptimizeToursRequest
किसी टूर ऑप्टिमाइज़ेशन सॉल्वर को दिए जाने का अनुरोध. इस सॉल्वर में, शिपमेंट मॉडल और ऑप्टिमाइज़ेशन पैरामीटर की जानकारी होती है.
फ़ील्ड | |
---|---|
parent |
ज़रूरी है. कॉल करने के लिए, प्रोजेक्ट या जगह को टारगेट करें. फ़ॉर्मैट: * अगर किसी जगह की जानकारी नहीं दी गई है, तो कोई इलाका अपने-आप चुन लिया जाएगा. |
timeout |
अगर यह टाइम आउट सेट है, तो सर्वर, टाइम आउट होने की अवधि खत्म होने या सिंक्रोनस अनुरोधों के लिए सर्वर की समयसीमा खत्म होने से पहले जवाब देता है, जो भी पहले हो. एसिंक्रोनस अनुरोधों के लिए, सर्वर टाइम आउट खत्म होने से पहले समाधान जनरेट करेगा (अगर मुमकिन हो). |
model |
शिपमेंट मॉडल को हल करना है. |
solving_mode |
डिफ़ॉल्ट रूप से, समस्या हल करने वाला मोड |
search_mode |
अनुरोध का समाधान करने के लिए, सर्च मोड का इस्तेमाल किया जाता है. |
injected_first_solution_routes[] |
पिछले समाधान से मिलता-जुलता पहला समाधान ढूंढने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम को गाइड करें. पहला समाधान बनाए जाने पर, मॉडल सीमित होता है. किसी रूट पर नहीं की गई शिपिंग की जानकारी को पहले विकल्प में साफ़ तौर पर स्किप कर दिया जाता है. हालांकि, उसे बाद में इस्तेमाल किया जा सकता है. समाधान को, मान्य मान्यता के कुछ बुनियादी अनुमानों को पूरा करना होगा:
अगर इंजेक्ट किया गया समाधान संभव नहीं है, तो ज़रूरी नहीं कि एक पुष्टि गड़बड़ी दिखाई गई हो और इसके बजाय, गड़बड़ी दिखाने वाली गड़बड़ी दिखाई जाए. |
injected_solution_constraint |
पिछले समाधान से मिलता-जुलता आखिरी समाधान ढूंढने के लिए, ऑप्टिमाइज़ेशन एल्गोरिदम को कंट्रोल करें. उदाहरण के लिए, इसका इस्तेमाल रूट के उन हिस्सों को फ़्रीज़ करने के लिए किया जा सकता है जो पूरे हो चुके हैं या जिन्हें पूरा किया जाना है, लेकिन उनमें कोई बदलाव नहीं किया जाना चाहिए. अगर इंजेक्ट किया गया समाधान संभव नहीं है, तो ज़रूरी नहीं कि एक पुष्टि गड़बड़ी दिखाई गई हो और इसके बजाय, गड़बड़ी दिखाने वाली गड़बड़ी दिखाई जाए. |
refresh_details_routes[] |
अगर सूची में कोई जगह है, तो दिए गए रास्ते रीफ़्रेश हो जाएंगे. हालांकि, विज़िट के क्रम या यात्रा में लगने वाले समय में कोई बदलाव नहीं होगा. सिर्फ़ अन्य जानकारी अपडेट की जाएगी. इससे मॉडल का समाधान नहीं होता. 2020/11 से, यह सिर्फ़ उन रास्तों की पॉलीलाइन भरता है जो खाली नहीं हैं और यह ज़रूरी है कि पास किए गए रास्तों के इस फ़ील्ड का इस्तेमाल इस व्यवहार पर |
interpret_injected_solutions_using_labels |
अगर सही है:
यह परिभाषा अगर सही है, तो इन कैटगरी के लेबल अपनी कैटगरी में ज़्यादा से ज़्यादा एक बार दिखने चाहिए:
अगर इंजेक्ट किए गए सलूशन में इंजेक्ट किए गए किसी सलूशन से रूट विज़िट या पूरे रूट को हटाने पर, पहले से तय की गई पाबंदियों पर असर पड़ सकता है. इसकी वजह से, समाधान में बदलाव हो सकता है, पुष्टि करने से जुड़ी गड़बड़ियां हो सकती हैं या उसे पूरा न किया जा सकता हो. ध्यान दें: कॉलर को यह पक्का करना होगा कि हर |
consider_road_traffic |
|
populate_polylines |
अगर सही है, तो जवाब |
populate_transition_polylines |
अगर सही है, तो जवाब |
allow_large_deadline_despite_interruption_risk |
अगर इसे सेट किया जाता है, तो अनुरोध करने की समयसीमा (https://grpc.io/blog/deadlines देखें) में 60 मिनट तक हो सकती है. अगर ऐसा नहीं है, तो समयसीमा खत्म होने में सिर्फ़ 30 मिनट लगेंगे. ध्यान दें कि लंबे समय तक सक्रिय रहने वाले अनुरोधों में रुकावट का काफ़ी ज़्यादा (लेकिन कम) जोखिम होता है. |
use_geodesic_distances |
अगर सही है, तो यात्रा की दूरी का हिसाब लगाने के लिए, Google Maps की दूरी के बजाय जियोडेसिक दूरी का इस्तेमाल किया जाएगा. साथ ही, यात्रा में लगने वाले समय का हिसाब, |
label |
इस अनुरोध की पहचान करने के लिए इस्तेमाल किया जा सकने वाला लेबल, |
geodesic_meters_per_second |
जब |
max_validation_errors |
पुष्टि करने में हुई गड़बड़ियों की संख्या को छोटा करता है. आम तौर पर, इन गड़बड़ियों को BadRequest गड़बड़ी की जानकारी (https://cloud.google.com/apis/design/errors#error_details) के तौर पर, INVALID_LANGUAGE गड़बड़ी के पेलोड के साथ जोड़ा जाता है, जब तक कि resolve_mode=VALIDATE_ONLY: |
SearchMode
यह मोड, खोज के व्यवहार को तय करता है. इसमें इंतज़ार के समय और समाधान की क्वालिटी के बीच का अंतर तय किया जाता है. सभी मोड में, अनुरोध की ग्लोबल समयसीमा लागू होती है.
Enums | |
---|---|
SEARCH_MODE_UNSPECIFIED |
RETURN_FAST के जैसा, सर्च मोड की जानकारी नहीं है. |
RETURN_FAST |
पहला अच्छा समाधान मिलने के बाद, खोज बंद करें. |
CONSUME_ALL_AVAILABLE_TIME |
बेहतर समाधान खोजने के लिए अपना पूरा समय निकालें. |
SolvingMode
इससे यह तय होता है कि सॉल्वर को अनुरोध को कैसे हैंडल करना चाहिए. VALIDATE_ONLY
के अलावा सभी मोड में, अगर अनुरोध अमान्य है, तो आपको INVALID_REQUEST
गड़बड़ी का मैसेज मिलेगा. दिखाई जाने वाली गड़बड़ियों की संख्या सीमित करने के लिए, max_validation_errors
पर जाएं.
Enums | |
---|---|
DEFAULT_SOLVE |
मॉडल को हल करें. [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] में चेतावनियां जारी की जा सकती हैं. |
VALIDATE_ONLY |
मॉडल को हल किए बिना सिर्फ़ उसकी पुष्टि करता है: ज़्यादा से ज़्यादा OptimizeToursResponse.validation_errors का डेटा जनरेट करता है. |
DETECT_SOME_INFEASIBLE_SHIPMENTS |
यह सिर्फ़ अहम जानकारी: यहां सभी मुश्किलों को शिप नहीं किया जाता है. सिर्फ़ उन्हें ही लौटाया जाता है जो प्री-प्रोसेसिंग के दौरान मुश्किल दिखते हैं. |
OptimizeToursResponse
यात्रा को ऑप्टिमाइज़ करने से जुड़ी समस्या को हल करने के बाद जवाब दिया जाता है. इसमें हर वाहन के लिए आने वाले रास्तों, स्किप किए गए शिपमेंट, और समाधान की कुल लागत शामिल होती है.
फ़ील्ड | |
---|---|
routes[] |
हर वाहन के लिए तय किए गए रास्ते; i-th रूट, मॉडल में i-th वाहन से मेल खाता है. |
request_label |
|
skipped_shipments[] |
स्किप किए गए सभी शिपमेंट की सूची. |
validation_errors[] |
पुष्टि करने से जुड़ी उन सभी गड़बड़ियों की सूची जिनका हमने अलग से पता लगाया था. "कई गड़बड़ियां" देखें |
metrics |
इस समाधान के लिए, कुल समय, दूरी, और इस्तेमाल की मेट्रिक. |
मेट्रिक
सभी रूट की एग्रीगेट की गई कुल मेट्रिक.
फ़ील्ड | |
---|---|
aggregated_route_metrics |
यह डेटा, सभी रास्तों के लिए इकट्ठा किया जाता है. हर मेट्रिक, एक ही नाम के सभी |
skipped_mandatory_shipment_count |
ज़रूरी शिपमेंट की संख्या. |
used_vehicle_count |
इस्तेमाल किए गए वाहनों की संख्या. ध्यान दें: अगर वाहन का रास्ता खाली है और |
earliest_vehicle_start_time |
इस्तेमाल किए गए वाहन के लिए, सबसे पहले शुरू होने का समय. इसे |
latest_vehicle_end_time |
इस्तेमाल किए गए वाहन के लिए, विज्ञापन दिखाने का आखिरी समय. इसे |
costs |
सॉल्यूशन की लागत, जिसे लागत से जुड़े अनुरोध फ़ील्ड के हिसाब से बांटा गया है. कुंजियां प्रोटो पाथ होती हैं, जो इनपुट OptimizeToursRequest से जुड़ी होती हैं, जैसे कि "model.shipments.pickups.cost" और वैल्यू की वैल्यू, उस लागत के फ़ील्ड से जनरेट हुई कुल लागत होती है जिसे पूरे समाधान में जोड़ा जाता है. दूसरे शब्दों में, costs["model.shipments.pickups.cost"] का मतलब है, पिकअप के लिए खरीदार से लिए जाने वाले सभी शुल्कों का कुल योग. मॉडल में तय की गई सभी कीमतों के बारे में यहां ज़्यादा जानकारी दी गई है. हालांकि, ट्रांज़िशन एट्रिब्यूट से जुड़ी लागत को छोड़कर, ये कीमतें सिर्फ़ 2022/01 तक के डेटा के आधार पर रिपोर्ट की गई हैं. |
total_cost |
समाधान की कुल लागत. लागत के मैप में मौजूद सभी वैल्यू का योग. |
OptimizeToursValidationError
OptimizeToursRequest
की पुष्टि करते समय मिलने वाली किसी गड़बड़ी या चेतावनी के बारे में बताता है.
फ़ील्ड | |
---|---|
code |
पुष्टि करने से जुड़ी गड़बड़ी, जोड़े ( नीचे दिए गए फ़ील्ड में, गड़बड़ी के बारे में ज़्यादा जानकारी दी गई है. एक से ज़्यादा गड़बड़ियां: कई गड़बड़ियां होने पर, पुष्टि करने की प्रोसेस में, उनमें से कई गड़बड़ियां दिखाने की कोशिश की जाती है. किसी कंपाइलर की तरह ही, यह भी एक सटीक प्रोसेस नहीं है. पुष्टि करने से जुड़ी कुछ गड़बड़ियां "गंभीर" होंगी. इसका मतलब है कि पुष्टि करने की पूरी प्रक्रिया रुक जाती है. ऐसा स्टेबलिटी: REFERENCE: सभी (कोड, नाम) जोड़े की सूची:
|
display_name |
गड़बड़ी का डिसप्ले नेम. |
fields[] |
गड़बड़ी के कॉन्टेक्स्ट में 0, 1 (ज़्यादातर समय) या उससे ज़्यादा फ़ील्ड शामिल हो सकते हैं. उदाहरण के लिए, वाहन #4 और शिपमेंट #2 का पहला पिकअप इस तरह से किया जा सकता है:
हालांकि, ध्यान दें कि किसी दिए गए गड़बड़ी कोड के लिए, |
error_message |
इस स्ट्रिंग में गड़बड़ी के बारे में ऐसी जानकारी होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. स्थिरता: स्थिर नहीं है: किसी |
offending_values |
इसमें फ़ील्ड की वैल्यू शामिल हो सकती हैं. यह सुविधा हमेशा उपलब्ध नहीं होती. आपको इस पर बिलकुल भरोसा नहीं करना चाहिए और इसका इस्तेमाल सिर्फ़ मैन्युअल मॉडल डीबग करने के लिए करना चाहिए. |
फ़ील्ड रेफ़रंस
पुष्टि करने में हुई गड़बड़ी के लिए संदर्भ बताता है. FieldReference
हमेशा इस फ़ाइल में दिए गए फ़ील्ड का हवाला देता है और उसी हैरारकी के स्ट्रक्चर का पालन करता है. उदाहरण के लिए, हम वाहन #5 के start_time_windows
का एलिमेंट #2 तय करने के लिए इनका इस्तेमाल कर सकते हैं:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
हालांकि, हम मैसेज में OptimizeToursRequest
या ShipmentModel
जैसी टॉप-लेवल इकाइयों को शामिल नहीं करते, ताकि मैसेज में बहुत ज़्यादा जानकारी न हो.
फ़ील्ड | |
---|---|
name |
फ़ील्ड का नाम, जैसे कि "वाहन". |
sub_field |
अगर ज़रूरी हो, तो बार-बार नेस्ट किया गया सब-फ़ील्ड. |
यूनियन फ़ील्ड
|
|
index |
अगर फ़ील्ड दोहराया गया है, तो उसका इंडेक्स. |
key |
अगर फ़ील्ड कोई मैप है, तो कुंजी. |
OutputConfig
[BatchOptimizeTours][google.maps.route अब सर्टिफ़िकेशन.v1.Route OptimizationService.BatchOptimizeTours] नतीजों के लिए कोई डेस्टिनेशन तय करें.
फ़ील्ड | |
---|---|
data_format |
ज़रूरी है. आउटपुट डेटा फ़ॉर्मैट. |
यूनियन फ़ील्ड destination . ज़रूरी है. destination इनमें से कोई एक हो सकता है: |
|
gcs_destination |
Google Cloud Storage में वह जगह जहां आउटपुट को सेव करना है. |
RouteModifiers
यह नीति, वाहन के रास्तों का हिसाब लगाते समय, वैकल्पिक शर्तों के सेट को एनकैप्सुलेट करती है. यह जानकारी, Google Maps Platform Routes Preferred API में मौजूद RouteModifiers
से मिलती-जुलती है; यहां देखें: https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers.
फ़ील्ड | |
---|---|
avoid_tolls |
इससे यह तय होता है कि ज़रूरत पड़ने पर, टोल वाली सड़कों से बचना है या नहीं. उन रास्तों को प्राथमिकता दी जाएगी जिनमें टोल रोड शामिल नहीं हैं. यह सिर्फ़ मोटर वाले यात्रा के मोड पर लागू होता है. |
avoid_highways |
इससे यह तय होता है कि ज़रूरत पड़ने पर, हाइवे से बचना है या नहीं. उन रास्तों को प्राथमिकता दी जाएगी जिनमें हाइवे नहीं हैं. यह सिर्फ़ मोटर वाले यात्रा के मोड पर लागू होता है. |
avoid_ferries |
इससे पता चलता है कि फ़ेरी का इस्तेमाल करने से बचना है या नहीं. उन रास्तों को प्राथमिकता दी जाएगी जिनमें फ़ेरी से यात्रा करने की सुविधा नहीं है. यह सुविधा सिर्फ़ मोटर वाले यात्रा मोड पर लागू होती है. |
avoid_indoor |
ज़रूरी नहीं. इस नीति से यह पता चलता है कि जहां भी ज़रूरी हो वहां घर के अंदर नेविगेट करना है या नहीं. ऐसे रास्तों को प्राथमिकता दी जाएगी जिनमें इनडोर नेविगेशन की सुविधा शामिल नहीं है. यह सिर्फ़ |
शिपमेंट
किसी एक आइटम को शिप करने से लेकर, किसी एक पिक अप से लेकर उसकी डिलीवरी तक का सफ़र. किसी वाहन को 'परफ़ॉर्मेंस' तब ही माना जाएगा, जब वह पिकअप की किसी जगह पर जाए (और ज़रूरत के हिसाब से उसकी अतिरिक्त क्षमता कम करे). इसके बाद, डिलीवरी की किसी एक जगह पर जाए. इसलिए, वाहन की अतिरिक्त कपैसिटी को फिर से बढ़ाएं.
फ़ील्ड | |
---|---|
display_name |
शिपमेंट का डिसप्ले नेम, जिसे उपयोगकर्ता ने तय किया है. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं और इसमें UTF-8 वर्णों का इस्तेमाल किया जा सकता है. |
pickups[] |
शिपमेंट से जुड़े पिकअप के विकल्पों का सेट. अगर इस बारे में नहीं बताया गया है, तो वाहन को सिर्फ़ उस जगह पर जाना होगा जहां डिलीवरी की जा रही है. |
deliveries[] |
शिपमेंट से जुड़े डिलीवरी के विकल्पों का सेट. अगर यह जानकारी नहीं दी गई है, तो वाहन को सिर्फ़ पिकअप की जगह पर जाना होगा. |
load_demands |
शिपमेंट से जुड़ी जानकारी लोड करना. उदाहरण के लिए, वज़न, वॉल्यूम, पैलेट की संख्या वगैरह. मैप में दी गई कुंजियों को ऐसे आइडेंटिफ़ायर होने चाहिए जो इससे जुड़े लोड के टाइप की जानकारी देते हों. खास तौर पर, इसमें इकाइयां भी शामिल होनी चाहिए. उदाहरण के लिए: "weight_kg", "quantity_gallons", "pallet_count", वगैरह. अगर कोई कुंजी मैप पर नहीं दिखती है, तो उससे जुड़ा लोड शून्य के तौर पर माना जाता है. |
allowed_vehicle_indices[] |
वाहनों का वह सेट जो इस शिपमेंट की डिलीवरी कर सकता है. अगर खाली है, तो सभी वाहन इस पर काम कर सकते हैं. वाहनों को उनके इंडेक्स के हिसाब से, |
costs_per_vehicle[] |
इससे पता चलता है कि हर वाहन से यह शिपमेंट भेजने पर कितना शुल्क लगेगा. अगर बताया गया है, तो इसमें कोई भी ऐसा होना चाहिए:
ये लागतें |
costs_per_vehicle_indices[] |
उन वाहनों के इंडेक्स जिन पर |
pickup_to_delivery_absolute_detour_limit |
इससे पता चलता है कि पिक अप से डिलीवरी तक के सबसे छोटे पाथ की तुलना में, ज़्यादा से ज़्यादा कितना समय घूमा है. अगर बताया गया है, तो यह ज़रूरी नहीं है कि यह नेगेटिव में हो. साथ ही, शिपमेंट में पिक अप और डिलीवरी की जानकारी होनी चाहिए. उदाहरण के लिए, मान लें कि पिक अप के चुने गए विकल्प से, डिलीवरी के चुने गए विकल्प तक, सीधे पहुंचने में कम से कम समय लगता है. जब
अगर एक ही शिपमेंट के लिए, रिलेटिव और एब्सोलूट, दोनों तरह की सीमाएं तय की गई हैं, तो पिकअप/डिलीवरी के हर संभावित जोड़े के लिए, ज़्यादा पाबंदी वाली सीमा का इस्तेमाल किया जाता है. अक्टूबर 2017 से, यात्रा में लगने वाला समय वाहनों पर निर्भर न होने पर ही, रास्ते में आने वाली रुकावटों की जानकारी दी जा सकती है. |
pickup_to_delivery_time_limit |
इससे यह पता चलता है कि शिपमेंट के पिकअप से लेकर डिलीवरी शुरू होने तक, ज़्यादा से ज़्यादा कितना समय लग सकता है. अगर बताया गया है, तो यह ज़रूरी नहीं है कि यह नेगेटिव में हो. साथ ही, शिपमेंट में पिक अप और डिलीवरी की जानकारी होनी चाहिए. यह इस बात पर निर्भर नहीं करता कि पिकअप और डिलीवरी के लिए कौनसे विकल्प चुने गए हैं और न ही यह वाहन की रफ़्तार पर निर्भर करता है. इसे ज़्यादा से ज़्यादा डेटूर कंस्ट्रेंट के साथ तय किया जा सकता है: समाधान दोनों स्पेसिफ़िकेशन के हिसाब से काम करेगा. |
shipment_type |
"टाइप" बताने वाली स्ट्रिंग खाली नहीं है इस शिपमेंट के लिए शुल्क लिया जाएगा. इस सुविधा का इस्तेमाल, एक विज़िट के लिए तय की गई |
label |
इस शिपमेंट के लिए लेबल तय करता है. यह लेबल, इससे जुड़े |
ignore |
अगर सही है, तो इस शिपमेंट को छोड़ें, लेकिन मॉडल में कोई
|
penalty_cost |
अगर शिपमेंट पूरा नहीं होता है, तो यह जुर्माना रूट्स की कुल लागत में जोड़ा जाता है. किसी शिपमेंट को तब ही पूरा माना जाता है, जब उसके पिकअप और डिलीवरी के किसी विकल्प का इस्तेमाल किया जाता है. लागत को उसी इकाई में दिखाया जा सकता है जिसका इस्तेमाल मॉडल में अन्य सभी लागत-संबंधी फ़ील्ड के लिए किया जाता है और यह धनात्मक होनी चाहिए. अहम जानकारी: अगर जुर्माने की जानकारी नहीं दी गई है, तो इसे अनगिनत माना जाता है. इसका मतलब है कि शिपमेंट पूरा होना ज़रूरी है. |
pickup_to_delivery_relative_detour_limit |
इससे यह जानकारी मिलती है कि पिकअप से डिलीवरी तक के सबसे छोटे पाथ की तुलना में, ज़्यादा से ज़्यादा कितना समय घूमता है. अगर बताया गया है, तो यह ज़रूरी नहीं है कि यह नेगेटिव में हो. साथ ही, शिपमेंट में पिक अप और डिलीवरी की जानकारी होनी चाहिए. उदाहरण के लिए, मान लें कि पिक अप के चुने गए विकल्प से, डिलीवरी के चुने गए विकल्प तक, सीधे पहुंचने में कम से कम समय लगता है. जब
अगर एक ही शिपमेंट पर संबंधित और कुल सीमाएं, दोनों की जानकारी दी गई है, तो हर संभावित पिकअप/डिलीवरी पेयर के लिए ज़्यादा सीमा का इस्तेमाल किया जाता है. 2017/10 से, चक्कर लगाने की सुविधा सिर्फ़ तब काम करती है, जब यात्रा का समय वाहनों पर निर्भर न हो. |
लोड
विज़िट करते समय, अगर सामान को पिकअप किया जाता है, तो पहले से तय की गई रकम को वाहन के लोड में जोड़ा जा सकता है. अगर सामान डिलीवरी का समय है, तो उसे घटाया जा सकता है. इस मैसेज में ऐसी रकम के बारे में बताया गया है. load_demands
देखें.
फ़ील्ड | |
---|---|
amount |
अलग-अलग विज़िट के दौरान, वाहन का लोड होने में लगने वाला समय अलग-अलग होगा. यह एक पूर्णांक है, इसलिए उपयोगकर्ताओं को सटीक जानकारी देने के लिए सही यूनिट चुनने की सलाह दी जाती है. यह वैल्यू 0 से ज़्यादा होनी चाहिए. |
VisitRequest
ऐसी विज़िट के लिए अनुरोध जो वाहन कर सकता है: इसमें एक भौगोलिक-जगह (या दो, नीचे देखें), खुलने और बंद होने का समय, टाइम विंडो से दिखाया जाता है, और सेवा में लगने वाला समय (सामान को पिक अप या ड्रॉप करने के लिए पहुंचने पर लगने वाला समय) शामिल है.
फ़ील्ड | |
---|---|
arrival_location |
वह जगह जहां से |
arrival_waypoint |
इस |
departure_location |
वह भौगोलिक जगह जहां से |
departure_waypoint |
वह पॉइंट जहां से |
tags[] |
विज़िट के अनुरोध से जुड़े टैग के बारे में जानकारी देता है. खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है. |
time_windows[] |
टाइम विंडो, जो किसी विज़िट पर पहुंचने के समय को रोकती हैं. ध्यान दें कि वाहन, पहुंचने के समय की विंडो के बाहर भी जा सकता है. इसका मतलब है कि यात्रा के समय और पहुंचने का समय, समय विंडो के अंदर होना ज़रूरी नहीं है. अगर वाहन
टाइम विंडो एक-दूसरे से अलग होनी चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं करनी चाहिए या एक-दूसरे के बगल में होनी चाहिए. साथ ही, टाइम विंडो बढ़ते क्रम में होनी चाहिए.
|
duration |
विज़िट का कुल समय, यानी वाहन के पहुंचने और रवाना होने के बीच बिताया गया समय (इंतज़ार करने के संभावित समय में जोड़ा गया है; |
cost |
वाहन के रास्ते के लिए, यात्रा के इस अनुरोध को पूरा करने में लगने वाला शुल्क. इसका इस्तेमाल करके, किसी भी प्रॉडक्ट के पिकअप या डिलीवरी के अलग-अलग शुल्क चुकाए जा सकते हैं. यह लागत |
load_demands |
इस विज़िट के अनुरोध की मांगें लोड करें. यह ठीक |
visit_types[] |
विज़िट के टाइप की जानकारी देता है. इसका इस्तेमाल, किसी वाहन को इस विज़िट को पूरा करने के लिए ज़रूरी अतिरिक्त समय देने के लिए किया जा सकता है ( एक टाइप सिर्फ़ एक बार दिख सकता है. |
label |
इस |
ShipmentModel
किसी शिपमेंट मॉडल में, शिपमेंट का एक सेट होता है. इसे वाहनों के एक सेट को पूरा करना होता है. हालांकि, कुल लागत को कम से कम किया जाता है, जो कि कुल कीमत होती है:
- वाहनों को रूट करने का खर्च (कुल समय का कुल योग, हर यात्रा में लगने वाला समय, और सभी वाहनों के लिए तय शुल्क).
- शिपिंग पर लगी पाबंदियां लागू नहीं होंगी.
- शिपिंग की ग्लोबल अवधि की लागत
फ़ील्ड | |
---|---|
shipments[] |
शिपमेंट का वह सेट जिसे मॉडल में किया जाना चाहिए. |
vehicles[] |
वाहनों का सेट, जिसका इस्तेमाल विज़िट के लिए किया जा सकता है. |
global_start_time |
मॉडल के शुरू और खत्म होने का ग्लोबल समय: इस सीमा से बाहर के किसी भी समय को मान्य नहीं माना जा सकता. मॉडल का टाइम स्पैन एक साल से कम होना चाहिए. इसका मतलब है कि
|
global_end_time |
अगर इसकी वैल्यू सेट नहीं की जाती है, तो डिफ़ॉल्ट रूप से 1 जनवरी, 1971 को 00:00:00 यूटीसी (यानी, सेकंड: 31,536,000, नैनो सेकंड: 0) का इस्तेमाल किया जाता है. |
global_duration_cost_per_hour |
"वैश्विक अवधि" कुल प्लान में, सभी वाहनों के शुरू होने के समय और खत्म होने के नए समय के बीच का अंतर होता है. उदाहरण के लिए, उपयोगकर्ता उस संख्या के लिए हर घंटे का शुल्क तय कर सकते हैं. इससे, वह काम जल्दी पूरा करने के लिए, उसे ऑप्टिमाइज़ कर सकेगा. यह लागत |
duration_distance_matrices[] |
मॉडल में इस्तेमाल की गई अवधि और दूरी की मैट्रिक के बारे में बताता है. अगर यह फ़ील्ड खाली है, तो इस्तेमाल के उदाहरण:
|
duration_distance_matrix_src_tags[] |
अवधि और दूरी के मैट्रिक्स के सोर्स को तय करने वाले टैग; टैग |
duration_distance_matrix_dst_tags[] |
अवधि और दूरी के मैट्रिक्स के गंतव्य तय करने वाले टैग; टैग |
transition_attributes[] |
मॉडल में ट्रांज़िशन एट्रिब्यूट जोड़े गए. |
shipment_type_incompatibilities[] |
ऐसे शिपमेंट_types के सेट जो काम नहीं करते हैं ( |
shipment_type_requirements[] |
|
precedence_rules[] |
प्राथमिकता के नियमों का सेट, जिसे मॉडल में लागू किया जाना चाहिए. |
max_active_vehicles |
यह सक्रिय वाहनों की ज़्यादा से ज़्यादा संख्या को सीमित करता है. किसी वाहन को तब चालू माना जाता है, जब उसके रास्ते पर कम से कम एक शिपमेंट किया गया हो. इसका इस्तेमाल, ऐसे मामलों में रास्तों की संख्या को सीमित करने के लिए किया जा सकता है जहां वाहनों के मुकाबले कम ड्राइवर हैं और वाहनों का बेड़ा अलग है. इसके बाद, ऑप्टिमाइज़ेशन की मदद से वाहनों का वह सबसेट चुना जा सकेगा जिसे इस्तेमाल करना है. पूरी तरह सकारात्मक होना चाहिए. |
DurationDistanceMatrix
इस नीति से, यात्रा और वाहन के शुरू होने की जगहों से लेकर यात्रा और वाहन के खत्म होने की जगहों तक, कुल समय और दूरी की मैट्रिक्स की जानकारी मिलती है.
फ़ील्ड | |
---|---|
rows[] |
कुल समय और दूरी के आव्यूह की लाइनों के बारे में बताता है. इसमें |
vehicle_start_tag |
यह तय करने वाला टैग कि किन वाहनों पर यह अवधि और दूरी की मैट्रिक्स लागू होती है. अगर इस फ़ील्ड को खाली छोड़ा जाता है, तो यह सभी गाड़ियों पर लागू होता है. साथ ही, इसमें सिर्फ़ एक मैट्रिक्स हो सकता है. हर वाहन के स्टार्ट होने का समय, एक ही मैट्रिक्स से मेल खाना चाहिए. इसका मतलब है कि सभी मैट्रिक्स का |
पंक्ति
कुल समय और दूरी के आव्यूह की जानकारी देता है.
फ़ील्ड | |
---|---|
durations[] |
किसी लाइन के लिए, कुल समय की वैल्यू. इसमें |
meters[] |
किसी पंक्ति के लिए दूरी की वैल्यू. अगर कोई लागत या कंस्ट्रेंट मॉडल में दूरी का संदर्भ नहीं देता है, तो इसे खाली छोड़ा जा सकता है; ऐसा नहीं होने पर, उसमें |
PrecedenceRule
दो इवेंट के बीच प्राथमिकता का एक नियम (हर इवेंट पिकअप या शिपमेंट की डिलीवरी है): "दूसरा" इवेंट, "पहले" के बाद कम से कम offset_duration
पर शुरू होना चाहिए शुरू हो गया है.
कई प्राथमिकताएं एक ही (या मिलते-जुलते) इवेंट का रेफ़रंस दे सकती हैं. उदाहरण के लिए, "A की डिलीवरी के बाद, B का पिक अप किया जाएगा" और "C का पिक अप B के पिकअप के बाद होता है".
इसके अलावा, प्राथमिकता सिर्फ़ तब लागू होती है, जब दोनों शिपमेंट हो जाते हैं और उन्हें अनदेखा कर दिया जाता है.
फ़ील्ड | |
---|---|
first_is_delivery |
बताता है कि क्या "पहला" इवेंट एक डिलीवरी है. |
second_is_delivery |
इससे पता चलता है कि "दूसरा" इवेंट डिलीवरी है या नहीं. |
offset_duration |
"पहले" के बीच का ऑफ़सेट और "दूसरा" इवेंट. यह नकारात्मक हो सकता है. |
first_index |
"फ़र्स्ट" का शिपमेंट इंडेक्स इवेंट. इस फ़ील्ड के बारे में बताना ज़रूरी है. |
second_index |
"सेकंड" का शिपमेंट इंडेक्स इवेंट. इस फ़ील्ड के बारे में बताना ज़रूरी है. |
ShipmentRoute
टाइम ऐक्सिस पर वाहन के रास्ते को इस तरह से डिकोड किया जा सकता है (हम मान लेते हैं कि विज़िट n हैं):
| | | | | T[2], | | |
| Transition | Visit #0 | | | V[2], | | |
| #0 | aka | T[1] | V[1] | ... | V[n-1] | T[n] |
| aka T[0] | V[0] | | | V[n-2],| | |
| | | | | T[n-1] | | |
^ ^ ^ ^ ^ ^ ^ ^
vehicle V[0].start V[0].end V[1]. V[1]. V[n]. V[n]. vehicle
start (arrival) (departure) start end start end end
ध्यान दें कि हम इन बीच अंतर करते हैं:
- "समय के साथ होने वाले इवेंट", जैसे कि वाहन के शुरू और खत्म होने के साथ-साथ, हर विज़िट के शुरू और खत्म होने (जैसे कि आने और जाने का समय). यह घटना, एक सेकंड में पूरी हो जाती है.
- "समय अंतराल", जैसे कि विज़िट और विज़िट के बीच का ट्रांज़िशन. हालांकि, टाइम इंटरवल की अवधि कभी-कभी शून्य हो सकती है.जैसे, एक ही सेकंड पर शुरू और खत्म होना. हालांकि, अक्सर उनकी अवधि पॉज़िटिव होती है.
इन्वैरिएंट:
- अगर n विज़िट हैं, तो n+1 ट्रांज़िशन हैं.
- कोई विज़िट, हमेशा उसके पहले के ट्रांज़िशन (एक ही इंडेक्स) और उसके बाद के ट्रांज़िशन (इंडेक्स + 1) से होती है.
- वाहन के चालू होने के बाद, हमेशा ट्रांज़िशन #0 होता है.
- वाहन की समाप्ति से पहले हमेशा #n होता है.
ज़ूम इन करने पर, Transition
और Visit
के दौरान क्या होता है, यहां बताया गया है:
---+-------------------------------------+-----------------------------+-->
| TRANSITION[i] | VISIT[i] |
| | |
| * TRAVEL: the vehicle moves from | PERFORM the visit: |
| VISIT[i-1].departure_location to | |
| VISIT[i].arrival_location, which | * Spend some time: |
| takes a given travel duration | the "visit duration". |
| and distance | |
| | * Load or unload |
| * BREAKS: the driver may have | some quantities from the |
| breaks (e.g. lunch break). | vehicle: the "demand". |
| | |
| * WAIT: the driver/vehicle does | |
| nothing. This can happen for | |
| many reasons, for example when | |
| the vehicle reaches the next | |
| event's destination before the | |
| start of its time window | |
| | |
| * DELAY: *right before* the next | |
| arrival. E.g. the vehicle and/or | |
| driver spends time unloading. | |
| | |
---+-------------------------------------+-----------------------------+-->
^ ^ ^
V[i-1].end V[i].start V[i].end
आखिर में, यहां बताया गया है कि ट्रांज़िशन के दौरान TRAVEL, BREAKS, DELAY और WAIT को किस तरह व्यवस्थित किया जा सकता है.
- वे ओवरलैप नहीं होते हैं.
- देरी यूनीक है और अगली विज़िट (या वाहन के खत्म होने) से ठीक पहले की अवधि ज़रूरी है. इसलिए, देरी के शुरू और खत्म होने के समय की जानकारी देना काफ़ी होगा.
- BREAKS एक साथ चलने वाले और अलग-अलग समय अवधि के होते हैं. जवाब में, हर ब्रेक के शुरू होने का समय और उसकी अवधि की जानकारी दी जाती है.
- TRAVEL और WAIT "प्रीएमप्ट किए जा सकते हैं": इस ट्रांज़िशन के दौरान, इनमें कई बार रुकावट आ सकती है. क्लाइंट मान सकते हैं कि यात्रा "जल्द से जल्द" होगी और यह कि "इंतज़ार करो" बचे हुए समय को भर देता है.
एक (जटिल) उदाहरण:
TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
|| | | | | | | ||
|| T | B | T | | B | | D ||
|| r | r | r | W | r | W | e ||
|| a | e | a | a | e | a | l ||
|| v | a | v | i | a | i | a ||
|| e | k | e | t | k | t | y ||
|| l | | l | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
फ़ील्ड | |
---|---|
vehicle_index |
रास्ते के बारे में बताने वाला वाहन, जिसकी पहचान सोर्स |
vehicle_label |
इस रास्ते पर चलने वाले वाहन का लेबल. अगर यह जानकारी दी गई है, तो यह |
vehicle_start_time |
वाहन के रूट शुरू होने का समय. |
vehicle_end_time |
वह समय जब वाहन अपना रास्ता पूरा करता है. |
visits[] |
रास्तों को दिखाने वाली विज़िट का क्रम. विज़िट[i] रूट की पहली विज़िट है. अगर यह फ़ील्ड खाली है, तो वाहन को इस्तेमाल न किए जाने वाला माना जाता है. |
transitions[] |
रूट के लिए ट्रांज़िशन की क्रम वाली सूची. |
has_traffic_infeasibilities |
अगर
ट्रैफ़िक की वजह से, यात्रा में लगने वाले समय |
route_polyline |
रूट की कोड में बदली गई पॉलीलाइन. यह फ़ील्ड सिर्फ़ तब पॉप्युलेट होता है, जब |
breaks[] |
इस रास्ते पर चलने वाले वाहन के लिए ब्रेक का शेड्यूल. |
metrics |
इस रूट की अवधि, दूरी, और लोड की मेट्रिक. कॉन्टेक्स्ट के आधार पर, |
route_costs |
रास्ते की कीमत, जिसे कीमत से जुड़े अनुरोध फ़ील्ड के हिसाब से बांटा गया है. कुंजियां प्रोटो पाथ होती हैं, जो इनपुट OptimizeToursRequest से जुड़ी होती हैं, जैसे कि "model.shipments.pickups.cost" और ये वैल्यू, उस लागत के फ़ील्ड से जनरेट हुई कुल लागत होती हैं जिसे पूरे रास्ते के लिए एग्रीगेट किया जाता है. दूसरे शब्दों में कहें, तो ["model.shipments.pickups.cost"], किसी रूट पर पिक अप करने के सभी शुल्कों का कुल योग होता है. मॉडल में तय की गई सभी कीमतों के बारे में यहां ज़्यादा जानकारी दी गई है. हालांकि, ट्रांज़िशन एट्रिब्यूट से जुड़ी लागत को छोड़कर, ये कीमतें सिर्फ़ 2022/01 तक के डेटा के आधार पर रिपोर्ट की गई हैं. |
route_total_cost |
रास्ते की कुल कीमत. लागत के मैप में मौजूद सभी लागतों का कुल योग. |
ब्रेक
ब्रेक के लागू होने की जानकारी देने वाला डेटा.
फ़ील्ड | |
---|---|
start_time |
ब्रेक लेने का समय. |
duration |
ब्रेक का कुल समय. |
EncodedPolyline
पॉलीलाइन का एन्कोडेड निरूपण. पॉलीलाइन को कोड में बदलने के बारे में ज़्यादा जानकारी यहां मिल सकती है: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.
फ़ील्ड | |
---|---|
points |
पॉलीलाइन के कोड में बदले गए पॉइंट दिखाने वाली स्ट्रिंग. |
ट्रांज़िशन
रास्ते पर दो इवेंट के बीच ट्रांज़िशन. ShipmentRoute
का ब्यौरा देखें.
अगर वाहन में start_location
और/या end_location
नहीं है, तो यात्रा से जुड़ी मेट्रिक शून्य होगी.
फ़ील्ड | |
---|---|
travel_duration |
इस ट्रांज़िशन के दौरान यात्रा की अवधि. |
travel_distance_meters |
बदलाव के दौरान तय की गई दूरी. |
traffic_info_unavailable |
जब |
delay_duration |
इस ट्रांज़िशन पर लागू होने वाली देरी की कुल अवधि. अगर कोई देरी है, तो यह अगले इवेंट (विज़िट या वाहन के खत्म होने) से ठीक |
break_duration |
इस बदलाव के दौरान होने वाले ब्रेक की कुल अवधि, अगर कोई हो. हर ब्रेक के शुरू होने का समय और अवधि की जानकारी, |
wait_duration |
इस ट्रांज़िशन के दौरान इंतज़ार करने में लगने वाला समय. इंतज़ार की अवधि, डिवाइस के इस्तेमाल न होने के समय से मेल खाती है. इसमें ब्रेक का समय शामिल नहीं होता. यह भी ध्यान रखें कि इंतज़ार के इस समय को कई गैर-लगातार इंटरवल में बांटा जा सकता है. |
total_duration |
ट्रांज़िशन की कुल अवधि, जो आपकी सुविधा के लिए दी गई है. यह इसके बराबर है:
|
start_time |
इस बदलाव के शुरू होने का समय. |
route_polyline |
ट्रांज़िशन के दौरान, कोड में बदली गई पॉलीलाइन दिखाने वाला रूट इस्तेमाल करना. इस फ़ील्ड में जानकारी सिर्फ़ तब अपने-आप भर जाती है, जब |
vehicle_loads |
इस बदलाव के दौरान, हर उस तरह के वाहन के लिए लोड होगा जो इस वाहन के पहले ट्रांज़िशन के दौरान लोड, वाहन के रास्ते के शुरुआती लोड होते हैं. इसके बाद, हर विज़िट के बाद, अगले ट्रांज़िशन के लोड पाने के लिए विज़िट के |
VehicleLoad
किसी दिए गए टाइप के लिए, रास्ते में आने वाले किसी समय वाहन का वास्तविक लोड रिपोर्ट करता है (Transition.vehicle_loads
देखें).
फ़ील्ड | |
---|---|
amount |
बताए गए टाइप के हिसाब से, वाहन पर लोड की संख्या. लोड की यूनिट को आम तौर पर, टाइप के हिसाब से दिखाया जाता है. |
यहां जाएं
किसी रास्ते के दौरान की गई यात्रा. यह विज़िट, Shipment
के पिकअप या डिलीवरी से जुड़ी है.
फ़ील्ड | |
---|---|
shipment_index |
सोर्स |
is_pickup |
अगर विज़िट सही है, तो |
visit_request_index |
|
start_time |
विज़िट शुरू होने का समय. ध्यान दें कि वाहन, विज़िट की जगह पर इससे पहले पहुंच सकता है. समय, |
load_demands |
शिपमेंट और विज़िट के अनुरोध |
detour |
डिलीवरी के लिए चुने गए रास्ते पर, डिलीवरी से पहले जिन शिपमेंट की डिलीवरी की जा चुकी है उनकी वजह से, डिलीवरी में लगने वाला अतिरिक्त समय. साथ ही, डिलीवरी के लिए तय की गई समयसीमा की वजह से, डिलीवरी में लगने वाला संभावित समय. अगर विज़िट एक डिलीवरी है, तो चक्करदार पथ की गणना संबंधित पिकअप विज़िट से की जाती है और यह इसके बराबर होता है:
अगर ऐसा नहीं है, तो इसकी गिनती,
|
shipment_label |
अगर |
visit_label |
अगर |
ShipmentTypeIncompatibility
यह बताने के लिए कि शिपमेंट के बीच किस तरह का असर होता है, यह जानकारी शिपमेंट के टाइप के आधार पर दी जाती है. एक ही रास्ते पर, एक-दूसरे के साथ काम न करने वाले शिपमेंट दिखने पर पाबंदी, शिपमेंट के साथ काम न करने वाले मोड के आधार पर लगाई जाती है.
फ़ील्ड | |
---|---|
types[] |
असंगत प्रकारों की सूची. दो शिपमेंट, जिनके |
incompatibility_mode |
मोड, साथ काम नहीं करता था. |
IncompatibilityMode
ऐसे मोड जिनसे यह तय होता है कि एक ही रास्ते पर, साथ काम न करने वाले शिपमेंट के दिखने पर पाबंदी कैसे लगाई जाए.
Enums | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED |
साथ काम नहीं करने वाला मोड सेट नहीं किया गया है. इस वैल्यू का इस्तेमाल कभी नहीं किया जाना चाहिए. |
NOT_PERFORMED_BY_SAME_VEHICLE |
इस मोड में, अलग-अलग तरह के दो शिपमेंट एक ही वाहन का इस्तेमाल नहीं कर सकते. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY |
|
ShipmentTypeRequirement
यह शिपमेंट के लिए उसकी शिपिंग की शर्तों के बारे में अलग-अलग जानकारी देता है. यह जानकारी, शिपमेंट के लिए उनकी शिपिंग की जानकारी देने के तरीके के हिसाब से दी जाती है. ज़रूरी शर्तों की जानकारी, 'ज़रूरी शर्तें' मोड से तय होती है.
फ़ील्ड | |
---|---|
required_shipment_type_alternatives[] |
ऐसे वैकल्पिक शिपमेंट टाइप की सूची जो |
dependent_shipment_types[] |
ध्यान दें: ज़रूरतों की चेन की अनुमति नहीं है, जैसे कि |
requirement_mode |
मोड को ज़रूरत के हिसाब से लागू किया गया. |
RequirementMode
किसी रास्ते पर डिपेंडेंट शिपमेंट के दिखने के तरीके तय करने वाले मोड.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED |
ज़रूरी शर्तों वाला मोड तय नहीं है. इस वैल्यू का इस्तेमाल कभी नहीं किया जाना चाहिए. |
PERFORMED_BY_SAME_VEHICLE |
इस मोड में, सभी "निर्भर" सभी शिपमेंट में एक ही वाहन मौजूद होना चाहिए जो कम से कम एक "ज़रूरी" प्रॉडक्ट के तौर पर शेयर किया गया हो शिपमेंट. |
IN_SAME_VEHICLE_AT_PICKUP_TIME |
"डिपेंडेंट" इसलिए, शिपमेंट से जुड़े सुझाव देने के लिए, इनमें से कोई एक शर्त पूरी होनी चाहिए:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME |
पहले की तरह ही, सिवाय इसके कि "डिपेंडेंट" शिपमेंट के लिए, डिलीवरी के समय उनके वाहन में "ज़रूरी" शिपमेंट होना चाहिए. |
SkippedShipment
किसी समाधान में, पूरे नहीं किए गए शिपमेंट की जानकारी देता है. मामूली मामलों में और/या अगर हम स्किप करने की वजह का पता लगा पाते हैं, तो हम यहां उसकी वजह बताते हैं.
फ़ील्ड | |
---|---|
index |
यह इंडेक्स, सोर्स |
label |
अगर |
reasons[] |
प्रॉडक्ट शिप न किए जाने की वजहों की सूची. |
कारण
अगर हम इस बात की जानकारी देंगे कि शिपमेंट को स्किप क्यों किया गया, तो इसकी वजहें यहां बताई जाएंगी. अगर सभी वाहनों के लिए वजह एक जैसी नहीं है, तो reason
में एक से ज़्यादा एलिमेंट होंगे. छोड़े गए शिपमेंट में डुप्लीकेट वजहें नहीं हो सकतीं, जैसे कि example_vehicle_index
को छोड़कर सभी फ़ील्ड एक जैसे हों. उदाहरण:
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 1
example_exceeded_capacity_type: "Apples"
}
reasons {
code: DEMAND_EXCEEDS_VEHICLE_CAPACITY
example_vehicle_index: 3
example_exceeded_capacity_type: "Pears"
}
reasons {
code: CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT
example_vehicle_index: 1
}
स्किप किया गया शिपमेंट, सभी वाहनों के साथ काम नहीं करता. सभी वाहनों के लिए वजहें अलग-अलग हो सकती हैं, लेकिन कम से कम एक वाहन के "सेब" होने चाहिए क्षमता से ज़्यादा होने का अनुमान लगाया जा सकता है (इसमें एक वाहन भी शामिल है). कम से कम एक वाहन की "नाशपाती" क्षमता (कार 3 सहित) से ज़्यादा हो जाएगी. साथ ही, कम से कम एक वाहन के लिए दूरी की सीमा (वाहन 1 भी शामिल है) पार हो जाएगी.
फ़ील्ड | |
---|---|
code |
कोड की टिप्पणियां देखें. |
example_exceeded_capacity_type |
अगर वजह का कोड |
example_vehicle_index |
अगर वजह किसी शिपिंग वाहन के साथ काम न करने की वजह से है, तो इस फ़ील्ड में किसी एक वाहन का इंडेक्स दिया जाता है. |
कोड
वजह बताने वाला कोड. यहां दिया गया आदेश बेकार है. खास तौर पर, इससे यह पता नहीं चलता कि अगर दोनों वजहें लागू होती हैं, तो समाधान में कोई वजह किसी दूसरी वजह से पहले दिखेगी या नहीं.
Enums | |
---|---|
CODE_UNSPECIFIED |
इसका इस्तेमाल कभी नहीं किया जाना चाहिए. |
NO_VEHICLE |
मॉडल में कोई वाहन नहीं है, इसलिए सभी शिपमेंट की सुविधा उपलब्ध नहीं है. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY |
शिपमेंट की मांग, कुछ तरह की कपैसिटी के लिए वाहन की कपैसिटी से ज़्यादा है. इनमें से एक example_exceeded_capacity_type है. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT |
इस शिपमेंट के लिए ज़रूरी कम से कम दूरी, जैसे कि वाहन का ध्यान दें कि इस हिसाब लगाने के लिए, हम जियोडेसिक दूरियों का इस्तेमाल करते हैं. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT |
इस शिपमेंट को पूरा करने में लगने वाला कम से कम समय, वाहन के ध्यान दें: यात्रा में लगने वाले समय का हिसाब, सबसे बेहतर स्थिति के लिए लगाया जाता है. उदाहरण के लिए, जियोडेसिक दूरी x 36 मी॰/घं॰ (करीब 130 कि॰मी॰/घंटा). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT |
यह ऊपर बताए गए तरीके जैसा ही है. हालांकि, हम सिर्फ़ यात्रा के कम से कम समय और वाहन के travel_duration_limit की तुलना करते हैं. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS |
वाहन, सबसे पहले के शुरू होने के समय से शुरू होने पर, सबसे अच्छी स्थिति वाली स्थिति में इस शिपमेंट को पूरा नहीं कर सकता (समय का हिसाब लगाने के लिए CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT देखें). यह शिपिंग समय, वाहन के सबसे हाल के खत्म होने के समय के बाद खत्म होगा. |
VEHICLE_NOT_ALLOWED |
शिपमेंट का allowed_vehicle_indices फ़ील्ड खाली नहीं है और यह वाहन उससे जुड़ा नहीं है. |
TimeWindow
टाइम विंडो, किसी इवेंट के समय को सीमित कर देती हैं, जैसे कि विज़िट के समय पहुंचने का समय या वाहन के शुरू और खत्म होने का समय.
हार्ड टाइम विंडो की सीमाएं, start_time
और end_time
, इवेंट का सबसे पुराना और सबसे नया समय लागू करती हैं, जैसे कि start_time <= event_time <=
end_time
. सॉफ़्ट टाइम विंडो की निचली सीमा, soft_start_time
, इवेंट को soft_start_time
को या उसके बाद होने वाले इवेंट के तौर पर प्राथमिकता देती है. इसके लिए, इस अनुपात में उस इवेंट के सॉफ़्ट_start_time के आधार पर प्रॉडक्ट को शामिल किया जाता है. सॉफ़्ट टाइम विंडो की ऊपरी सीमा, soft_end_time
, इवेंट को soft_end_time
को या उससे पहले होने देने को प्राथमिकता देती है. इसके लिए, इस बात पर ध्यान दिया जाता है कि इवेंट soft_end_time
के बाद कितने समय बाद होगा. start_time
, end_time
, soft_start_time
, और soft_end_time
, ग्लोबल टाइम सीमाओं के अंदर होने चाहिए (ShipmentModel.global_start_time
और ShipmentModel.global_end_time
देखें) और इनके मुताबिक होना चाहिए:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
फ़ील्ड | |
---|---|
start_time |
मुश्किल समय की विंडो शुरू होने का समय. अगर इसे सेट नहीं किया गया है, तो इसे |
end_time |
मुश्किल समय की अवधि खत्म होने का समय. अगर इसे सेट नहीं किया गया है, तो इसे |
soft_start_time |
टाइम विंडो का सॉफ़्ट स्टार्ट समय. |
soft_end_time |
समय विंडो का सॉफ़्ट खत्म होने का समय. |
cost_per_hour_before_soft_start_time |
अगर इवेंट, soft_start_time से पहले होता है, तो मॉडल में अन्य लागतों के साथ हर घंटे की लागत जोड़ी जाती है. इसे इस तरह से कैलकुलेट किया जाता है:
यह शुल्क, शून्य से ज़्यादा होना चाहिए. साथ ही, यह फ़ील्ड सिर्फ़ तब सेट किया जा सकता है, जब soft_start_time सेट किया गया हो. |
cost_per_hour_after_soft_end_time |
अगर इवेंट
यह लागत पॉज़िटिव होनी चाहिए. साथ ही, फ़ील्ड को सिर्फ़ तब सेट किया जा सकता है, जब |
TransitionAttributes
किसी रूट पर लगातार दो विज़िट के बीच ट्रांज़िशन एट्रिब्यूट बताता है. एक ही ट्रांज़िशन पर कई TransitionAttributes
लागू हो सकते हैं: इस स्थिति में, सभी अतिरिक्त शुल्क जुड़ जाते हैं और सबसे सख्त पाबंदी या सीमा लागू होती है (सामान्य "AND" सिमैंटिक का इस्तेमाल करके).
फ़ील्ड | |
---|---|
src_tag |
(src->dst) ट्रांज़िशन के सेट को तय करने वाले टैग, इन एट्रिब्यूट पर लागू होते हैं. किसी सोर्स विज़िट या वाहन के शुरू होने का समय, अगर उसके |
excluded_src_tag |
|
dst_tag |
किसी डेस्टिनेशन विज़िट या वाहन के एंड का मिलान अगर उसके |
excluded_dst_tag |
|
cost |
इस ट्रांज़िशन की लागत तय करता है. यह मॉडल में मौजूद सभी अन्य लागतों की तरह ही एक ही इकाई में होती है. साथ ही, यह नेगेटिव नहीं होनी चाहिए. इसे अन्य सभी मौजूदा लागतों पर लागू किया जाता है. |
cost_per_kilometer |
इस ट्रांज़िशन के दौरान, यात्रा की गई दूरी पर लागू होने वाली हर किलोमीटर की कीमत बताता है. यह वाहनों पर मौजूद किसी भी |
distance_limit |
यह बदलाव करते समय तय की गई दूरी की जानकारी देता है. जून 2021 से, सिर्फ़ सॉफ्ट लिमिट का इस्तेमाल किया जा सकता है. |
delay |
इस ट्रांज़िशन के दौरान हुई देरी के बारे में बताता है. यह देरी हमेशा स्रोत विज़िट खत्म होने के बाद और गंतव्य विज़िट शुरू होने से पहले होती है. |
वाहन
शिपमेंट से जुड़ी समस्या के दौरान वाहन का मॉडल बनाता है. शिपमेंट से जुड़ी समस्या हल करने पर, इस वाहन के लिए एक ऐसा रास्ता बनेगा जो start_location
से शुरू होगा और end_location
पर खत्म होगा. रास्ता, विज़िट का क्रम होता है (ShipmentRoute
देखें).
फ़ील्ड | |
---|---|
display_name |
वाहन का डिसप्ले नेम, जिसे उपयोगकर्ता ने तय किया है. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं और इसमें UTF-8 वर्णों का इस्तेमाल किया जा सकता है. |
travel_mode |
यात्रा का वह मोड जो वाहन के लिए इस्तेमाल की जा सकने वाली सड़कों और उसकी स्पीड पर असर डालता है. |
route_modifiers |
शर्तों का एक सेट, जो दिए गए वाहन के लिए रास्तों की गणना के तरीके को प्रभावित करती है. |
start_location |
वह भौगोलिक जगह जहां से सामान पिक अप करने से पहले वाहन शुरू होता है. अगर जानकारी नहीं दी जाती है, तो वाहन पहले पिकअप पर शुरू किया जाएगा. अगर शिपमेंट मॉडल में अवधि और दूरी के मैट्रिक्स हैं, तो |
start_waypoint |
ऐसी भौगोलिक जगह दिखाने वाला वेपॉइंट जहां किसी शिपमेंट को पिक अप करने से पहले, गाड़ी शुरू होती है. अगर |
end_location |
वह भौगोलिक जगह जहां वाहन आखिरी |
end_waypoint |
उस भौगोलिक जगह को दिखाने वाला वेपॉइंट जहां आखिरी |
start_tags[] |
वाहन के रूट की शुरुआत से जुड़े टैग के बारे में बताता है. खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है. |
end_tags[] |
वाहन के रूट के आखिर में जोड़े गए टैग की जानकारी देता है. खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है. |
start_time_windows[] |
टाइम विंडो, जिस दौरान वाहन अपनी शुरुआती जगह से निकल सकता है. इन्हें ग्लोबल टाइम लिमिट के अंदर होना चाहिए ( दोहराए जाने वाले एक ही फ़ील्ड की टाइम विंडो को अलग-अलग रखना चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं कर सकती या एक टाइम विंडो के बगल में नहीं होनी चाहिए. साथ ही, ये समय के हिसाब से क्रम में होनी चाहिए.
|
end_time_windows[] |
वह समयसीमा जिसके दौरान वाहन, अपनी मंज़िल पर पहुंच सकता है. ये समयसीमाएं, ग्लोबल समयसीमाओं के अंदर होनी चाहिए ( दोहराए जाने वाले एक ही फ़ील्ड की टाइम विंडो को अलग-अलग रखना चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं कर सकती या एक टाइम विंडो के बगल में नहीं होनी चाहिए. साथ ही, ये समय के हिसाब से क्रम में होनी चाहिए.
|
unloading_policy |
वाहन पर सामान को अनलोड करने की नीति लागू है. |
load_limits |
वाहन की क्षमता (वज़न, वॉल्यूम, # पैलेट). मैप में मौजूद कुंजियां, लोड के टाइप के आइडेंटिफ़ायर हैं और ये |
cost_per_hour |
वाहन की लागत: सभी लागतें जोड़ दी जाती हैं और वे वाहन के रास्ते में हर घंटे का शुल्क. यह शुल्क, रास्ते में लगने वाले कुल समय पर लागू होता है. इसमें यात्रा का समय, इंतज़ार का समय, और विज़िट का समय शामिल होता है. सिर्फ़ |
cost_per_traveled_hour |
वाहन के रास्ते में हर घंटे की गई यात्रा का शुल्क. यह शुल्क, यात्रा में लगने वाले समय के लिए ही है (यानी कि |
cost_per_kilometer |
वाहन के रास्ते में प्रति किलोमीटर का शुल्क. यह कीमत, |
fixed_cost |
अगर इस वाहन का इस्तेमाल शिपमेंट को हैंडल करने के लिए किया जाता है, तो तय शुल्क लागू होता है. |
used_if_route_is_empty |
यह फ़ील्ड वाहनों पर सिर्फ़ तब लागू होता है, जब उनके रास्ते पर कोई शिपमेंट नहीं भेजा जाता. इसमें यह जानकारी मिलती है कि इस मामले में वाहन को इस्तेमाल किया गया माना जाना चाहिए या नहीं. अगर सही है, तो वाहन अपने शुरू से आखिरी जगह तक चला जाता है, भले ही वह किसी भी शिपमेंट को सेवा न देता हो. साथ ही, इसके शुरू होने से लगने वाले समय और दूरी की लागत > साथ ही, यात्रा के आखिरी चरण को भी ध्यान में रखा जाता है. ऐसा नहीं करने पर, यह अपनी शुरुआत से अपनी जगह तक नहीं पहुंचेगा. साथ ही, इस वाहन के लिए, |
route_duration_limit |
यह सीमा, वाहन के रास्ते की कुल अवधि पर लागू होती है. दिए गए |
travel_duration_limit |
यह सीमा, वाहन के रास्ते की यात्रा में लगने वाले समय पर लागू होती है. किसी |
route_distance_limit |
यह सीमा, वाहन के रास्ते की कुल दूरी पर लागू होती है. दिए गए |
extra_visit_duration_for_visit_type |
visit_types स्ट्रिंग से लेकर अवधि तक के मैप की जानकारी देता है. यह समय, अगर विज़िट का अनुरोध कई तरह के हैं, तो मैप में हर तरह के लिए एक अवधि जोड़ दी जाएगी. |
break_rule |
इस वाहन के लिए ब्रेक का शेड्यूल बताता है. अगर यह खाली है, तो इस वाहन के लिए कोई ब्रेक शेड्यूल नहीं किया जाएगा. |
label |
इस वाहन के लिए एक लेबल तय करता है. इस लेबल को जवाब में, उससे जुड़े |
ignore |
अगर सही है, तो अगर अगर |
travel_duration_multiple |
यह एक मल्टीप्लायर फ़ैक्टर होता है. इसका इस्तेमाल, इस वाहन के यात्रा के समय को बढ़ाने या घटाने के लिए किया जा सकता है. उदाहरण के लिए, इसे 2.0 पर सेट करने का मतलब है कि यह वाहन धीमा है और सामान्य वाहनों के मुकाबले, इसमें यात्रा में लगने वाला समय दोगुना है. इस मल्टीपल का असर, विज़िट के कुल समय पर नहीं पड़ता. अगर चेतावनी: इस मल्टीपल को लागू करने के बाद, यात्रा के समय को उसके नज़दीक के सेकंड में बदल दिया जाएगा. हालांकि, अंकों वाली कोई कार्रवाई करने से पहले, यात्रा के समय की वैल्यू को घटाने पर, संख्या में हुए बदलाव का असर सटीक होगा. यहां |
DurationLimit
वाहन के रूट की ज़्यादा से ज़्यादा अवधि तय करने वाली सीमा. यह कठोर या मुलायम हो सकता है.
सॉफ़्ट लिमिट फ़ील्ड को तय करने पर, सॉफ़्ट मैक्स थ्रेशोल्ड और उससे जुड़ी लागत, दोनों को एक साथ तय किया जाना चाहिए.
फ़ील्ड | |
---|---|
max_duration |
यह एक तय सीमा है, जो अवधि को ज़्यादा से ज़्यादा max_duration तक सीमित करती है. |
soft_max_duration |
सॉफ्ट लिमिट, वीडियो की अवधि की ज़्यादा से ज़्यादा सीमा लागू नहीं करती. हालांकि, इसकी सीमा का उल्लंघन करने पर, रास्ते पर शुल्क लगता है. यह लागत, उसी इकाई के साथ मॉडल में तय की गई अन्य लागतों को जोड़ देती है. अगर तय किया गया हो, तो |
quadratic_soft_max_duration |
यह एक सॉफ़्ट सीमा है, जो गतिविधि की ज़्यादा से ज़्यादा अवधि पर पाबंदी नहीं लगाती. हालांकि, इस सीमा का उल्लंघन करने पर, रास्ते की लागत बढ़ जाती है. यह लागत, गतिविधि की अवधि के हिसाब से बढ़ती है. यह लागत, उसी इकाई के साथ मॉडल में तय की गई अन्य लागतों को जोड़ देती है. अगर तय किया गया हो, तो
|
cost_per_hour_after_soft_max |
लागत गैर-ऋणात्मक होनी चाहिए. |
cost_per_square_hour_after_quadratic_soft_max |
अगर अवधि, थ्रेशोल्ड से कम है, तो अतिरिक्त लागत 0 होगी. ऐसा न होने पर, लागत इस तरह की अवधि पर निर्भर करेगी:
लागत गैर-ऋणात्मक होनी चाहिए. |
LoadLimit
वाहन पर लागू होने वाली लोड सीमा के बारे में बताता है, उदाहरण के लिए "यह ट्रक सिर्फ़ 3,500 कि॰ग्रा॰ तक का वज़न ले सकता है". load_limits
देखें.
फ़ील्ड | |
---|---|
soft_max_load |
लोड की सॉफ्ट सीमा. |
cost_per_unit_above_soft_max |
अगर इस वाहन के रास्ते में कभी भी |
start_load_interval |
रूट की शुरुआत में वाहन का लोड होने में लगने वाला समय. |
end_load_interval |
रास्ते के आखिर में, वाहन में लोड करने के लिए स्वीकार की जाने वाली समयावधि. |
max_load |
लोड की वह ज़्यादा से ज़्यादा सीमा जिसे स्वीकार किया जा सकता है. |
इंटरवल
स्वीकार की जाने वाली लोड रकम का इंटरवल.
फ़ील्ड | |
---|---|
min |
कम से कम स्वीकार्य लोड. यह 0 या इससे ज़्यादा होना चाहिए. अगर दोनों के बारे में बताया गया है, तो |
max |
तय सीमा के मुताबिक लोड होने वाली फ़ाइलें. यह 0 या इससे ज़्यादा होना चाहिए. अगर यह नहीं बताया गया है, तो ज़्यादा से ज़्यादा लोड पर इस मैसेज का असर नहीं होगा. अगर दोनों के बारे में बताया गया है, तो |
TravelMode
यात्रा के ऐसे मोड जिनका इस्तेमाल वाहन कर सकते हैं.
ये, Google Maps Platform Routes Preferred API के यात्रा के मोड के सबसेट होने चाहिए. ज़्यादा जानकारी के लिए, https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode पर जाएं.
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED |
अनिर्दिष्ट यात्रा मोड, DRIVING के बराबर. |
DRIVING |
ड्राइविंग दिशा निर्देशों के मुताबिक यात्रा का मोड (कार, ...). |
WALKING |
पैदल चलने के निर्देशों से जुड़ा यात्रा मोड. |
UnloadingPolicy
वाहन को अनलोड करने से जुड़ी नीति. यह सिर्फ़ उन शिपमेंट पर लागू होता है जिनके लिए पिक अप और डिलीवरी, दोनों मौजूद हैं.
unloading_policy
से अलग, रास्ते पर कहीं भी दूसरे शिपमेंट मुफ़्त में भेजे जा सकते हैं.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED |
अनलोडिंग नीति के बारे में जानकारी नहीं दी गई है; पिक अप किए जाने के तुरंत बाद ही डिलीवरी की जानी चाहिए. |
LAST_IN_FIRST_OUT |
डिलीवरी, पिक अप के क्रम में नहीं होनी चाहिए |
FIRST_IN_FIRST_OUT |
डिलीवरी उसी क्रम में होनी चाहिए जिस क्रम में पिकअप की सुविधा है |
वेपॉइंट
वेपॉइंट को एनकैप्सुलेट करता है. वेपॉइंट, visitRequests के आने और जाने की जगहों को मार्क करते हैं. साथ ही, वाहनों के शुरू और खत्म होने की जगह की जानकारी भी देते हैं.
फ़ील्ड | |
---|---|
side_of_road |
ज़रूरी नहीं. यह बताता है कि इस वेपॉइंट की जगह को प्राथमिकता दी गई है, ताकि वाहन को सड़क के किसी खास तरफ़ रोका जा सके. जब आप यह मान सेट करते हैं, तो मार्ग उस स्थान से गुजरेगा ताकि वाहन सड़क के उस किनारे पर रुक सके जिस स्थान का स्थान सड़क के बीच से पूर्वाग्रह है. यह विकल्प 'पैदल चलना' के लिए काम नहीं करता यात्रा मोड. |
यूनियन फ़ील्ड location_type . किसी जगह को दिखाने के अलग-अलग तरीके. location_type इनमें से सिर्फ़ एक हो सकता है: |
|
location |
भौगोलिक निर्देशांक का इस्तेमाल करके तय किया गया पॉइंट, जिसमें एक वैकल्पिक शीर्षक भी शामिल होता है. |
place_id |
वेपॉइंट से जुड़ा लोकप्रिय जगह का आईडी. |