इंडेक्स
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
(मैसेज)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] में.
- नैनो को सेट नहीं किया जाना चाहिए या 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_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 |
मॉडल को हल करें. |
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" और ये वैल्यू, उस लागत के फ़ील्ड की वजह से जनरेट हुई कुल लागत होती हैं जिसे पूरे समाधान में जोड़ा जाता है. दूसरे शब्दों में कहें, तो कीमत["model.shipments.pickups.cost"], समाधान के तौर पर पिक अप की सभी कीमतों का कुल योग है. मॉडल में तय की गई सभी कीमतों के बारे में यहां पूरी जानकारी दी गई है. हालांकि, ट्रांज़िशन एट्रिब्यूट से जुड़ी लागत को छोड़कर, ये कीमतें सिर्फ़ 2022/01 तक के डेटा के आधार पर रिपोर्ट की गई हैं. |
total_cost |
समाधान की कुल लागत. लागत मैप में सभी मानों का योग. |
OptimizeToursValidationError
OptimizeToursRequest
की पुष्टि करते समय मिलने वाली गड़बड़ी के बारे में बताता है.
फ़ील्ड | |
---|---|
code |
पुष्टि करने से जुड़ी गड़बड़ी, जोड़े ( नीचे दिए गए फ़ील्ड में, गड़बड़ी के बारे में ज़्यादा जानकारी दी गई है. एक से ज़्यादा गड़बड़ियां: कई गड़बड़ियां होने पर, पुष्टि करने की प्रोसेस में कई गड़बड़ियां दिखाने की कोशिश की जाती है. किसी कंपाइलर की तरह ही, यह भी एक सटीक प्रोसेस नहीं है. पुष्टि करने से जुड़ी कुछ गड़बड़ियां "गंभीर" होंगी. इसका मतलब है कि पुष्टि करने की पूरी प्रक्रिया रुक जाती है. अन्य मामलों के साथ-साथ, स्थिरता: REFERENCE: सभी (कोड, नाम) जोड़े की सूची:
|
display_name |
गड़बड़ी का डिसप्ले नेम. |
fields[] |
गड़बड़ी के कॉन्टेक्स्ट में 0, 1 (ज़्यादातर समय) या उससे ज़्यादा फ़ील्ड शामिल हो सकते हैं. उदाहरण के लिए, वाहन #4 और शिपमेंट #2 का पहला पिकअप इस तरह से किया जा सकता है:
हालांकि, ध्यान दें कि किसी दिए गए गड़बड़ी कोड के लिए, |
error_message |
इस स्ट्रिंग में गड़बड़ी के बारे में ऐसी जानकारी होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. स्थिरता: स्थिर नहीं है: किसी |
offending_values |
इसमें फ़ील्ड की वैल्यू शामिल हो सकती हैं. यह सुविधा हमेशा उपलब्ध नहीं होती. आपको इस पर बिलकुल भरोसा नहीं करना चाहिए और इसका इस्तेमाल सिर्फ़ मैन्युअल मॉडल डीबग करने के लिए करना चाहिए. |
FieldReference
पुष्टि करने में हुई गड़बड़ी के लिए संदर्भ बताता है. 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 की वह जगह जहां आउटपुट में लिखना है. |
शिपमेंट
किसी एक आइटम को शिप करने से लेकर, उसकी डिलीवरी तक, किसी एक सामान को भेजने की सुविधा. किसी वाहन को 'परफ़ॉर्मेंस' तब ही माना जाएगा, जब वह पिकअप की किसी जगह पर जाए (और ज़रूरत के हिसाब से उसकी अतिरिक्त क्षमता कम कर दे). इसके बाद, डिलीवरी की किसी एक जगह पर ज़रूर जाए. इसलिए, वाहन की अतिरिक्त कपैसिटी को फिर से बढ़ाएं.
फ़ील्ड | |
---|---|
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/10 से, चक्कर लगाने की सुविधा सिर्फ़ तब काम करती है, जब यात्रा का समय वाहनों पर निर्भर न हो. |
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 |
अगर इसे सेट नहीं किया जाता है, तो 00:00:00 यूटीसी, 1 जनवरी, 1971 (जैसे कि सेकंड: 31536000, \nos: 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 "पहले से तैयार" हैं: इस बदलाव के दौरान उनमें कई बार रुकावट आ सकती है. क्लाइंट मान सकते हैं कि यात्रा "जल्द से जल्द" होगी और यह कि "इंतज़ार करो" बचे हुए समय को भर देता है.
A (मुश्किल) का उदाहरण:
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` <= `soft_start_time` <= `end_time` and
0 <= `start_time` <= `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/06 से, सिर्फ़ अस्थायी सीमाओं का इस्तेमाल किया जा सकता है. |
delay |
इस ट्रांज़िशन के दौरान हुई देरी के बारे में बताता है. यह देरी हमेशा स्रोत विज़िट खत्म होने के बाद और गंतव्य विज़िट शुरू होने से पहले होती है. |
वाहन
शिपमेंट से जुड़ी समस्या के दौरान वाहन का मॉडल बनाता है. शिपमेंट से जुड़ी समस्या हल करने पर, इस वाहन के लिए एक रास्ता, start_location
से शुरू होगा और end_location
पर खत्म होगा. रास्ता, विज़िट का क्रम होता है (ShipmentRoute
देखें).
फ़ील्ड | |
---|---|
display_name |
वाहन का डिसप्ले नेम, जिसे उपयोगकर्ता ने तय किया है. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं और इसमें UTF-8 वर्णों का इस्तेमाल किया जा सकता है. |
travel_mode |
यात्रा का वह मोड जो वाहन के लिए इस्तेमाल की जा सकने वाली सड़कों और उसकी स्पीड पर असर डालता है. |
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 |
अवधि को ज़्यादा से ज़्यादा 'ज़्यादा से ज़्यादा' अवधि तक सीमित करने वाली हार्ड लिमिट. |
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 |
वेपॉइंट से जुड़ा लोकप्रिय जगह का आईडी. |