इंडेक्स
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
- समय, Unix समय में है: 01-01-1970 से अब तक T00: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 |
नर्म सीमा, दूरी की सीमा को लागू नहीं करती. हालांकि, उल्लंघन होने पर लागत लगती है जो मॉडल में तय की गई अन्य सभी कीमतों को जोड़ देती है. अगर सॉफ़्ट_max_meter का मान तय किया गया है, तो यह max_meter से कम होना चाहिए. साथ ही, यह शून्य से कम होना चाहिए. |
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
[BACKUPOptimizeTours][google.maps.route Optimization.v1.Route OptimizationService.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 |
अगर यह नीति सेट की जाती है, तो अनुरोध की समयसीमा 60 मिनट तक की हो सकती है. इस बारे में ज़्यादा जानने के लिए, https://grpc.io/blog/deadlines पर जाएं. अगर ऐसा नहीं है, तो समयसीमा सिर्फ़ 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_ बतौर गड़बड़ी पेलोड के साथ अटैच की जाती है. इस प्रक्रिया के दौरान, Solution_mode=पढ़ना, VerifiedATE_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 |
पुष्टि करने से जुड़ी गड़बड़ी, जोड़े ( नीचे दिए गए अन्य फ़ील्ड में, गड़बड़ी के बारे में ज़्यादा जानकारी दी गई है. कई गड़बड़ियां: जब कई गड़बड़ियां होती हैं, तो पुष्टि करने की प्रोसेस उनमें से कई गड़बड़ियां होने की कोशिश करती है. किसी कंपाइलर की तरह, यह एक अपूर्ण प्रक्रिया है. पुष्टि करने से जुड़ी कुछ गड़बड़ियां "घातक" होंगी. इसका मतलब है कि वे पुष्टि की पूरी प्रक्रिया को रोक देती हैं. यह अन्य गड़बड़ियों के साथ-साथ, स्थिरता: पहचान फ़ाइल: सभी (कोड, नाम) पेयर की सूची:
|
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
[batOptimizeTours][google.maps.route Optimization.v1.Route OptimizationService.BatchOptimizeTours] नतीजों के लिए कोई डेस्टिनेशन तय करें.
फ़ील्ड | |
---|---|
data_format |
ज़रूरी है. आउटपुट डेटा फ़ॉर्मैट. |
यूनियन फ़ील्ड destination . ज़रूरी है. destination इनमें से सिर्फ़ एक हो सकती है: |
|
gcs_destination |
वह Google Cloud Storage जगह जिसमें आउटपुट लिखना है. |
शिपमेंट
किसी एक सामान का शिपमेंट, उसके किसी एक पिकअप से लेकर किसी एक डिलीवरी तक. किसी शिपमेंट को लागू करने के लिए, यह ज़रूरी है कि कोई यूनीक वाहन, पिक अप करने की किसी एक जगह पर जाए. साथ ही, उसकी बची हुई जगह पर जाए. फिर, बाद में डिलीवरी करने की किसी एक जगह पर जाएं. इसलिए, उसकी जगह पर अपनी अतिरिक्त क्षमता को फिर से बढ़ाएं.
फ़ील्ड | |
---|---|
display_name |
शिपमेंट का उपयोगकर्ता की ओर से तय किया गया डिसप्ले नेम. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं और इसमें UTF-8 वर्णों का इस्तेमाल किया जा सकता है. |
pickups[] |
शिपमेंट से जुड़े पिकअप के विकल्पों का सेट. अगर इसके बारे में नहीं बताया गया है, तो वाहन को सिर्फ़ डिलीवरी वाली जगह पर जाना होगा. |
deliveries[] |
शिपमेंट से जुड़े डिलीवरी के विकल्पों का सेट. अगर इसके बारे में नहीं बताया गया है, तो वाहन को सिर्फ़ पिकअप वाली जगह पर जाना होगा. |
load_demands |
शिपमेंट के लिए ज़रूरी चीज़ों की जानकारी लोड करना. जैसे, वज़न, वॉल्यूम, पैलेट की संख्या वगैरह. मैप में दी गई कुंजियों में ऐसे आइडेंटिफ़ायर होने चाहिए जो लोड के टाइप की जानकारी देते हों. खास तौर पर, इसमें यूनिट भी शामिल होनी चाहिए. उदाहरण के लिए: "weight_kg", "वॉल्यूम_गैलन", "पैलेट_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 |
अगर यह नीति सेट नहीं है, तो 1 जनवरी, 1971 को 00:00:00 यूटीसी, यानी सेकंड: 31536000, नैनोस: 0 का इस्तेमाल डिफ़ॉल्ट रूप से किया जाएगा. |
global_duration_cost_per_hour |
कुल प्लान की "ग्लोबल पीरियड", सभी वाहनों के खत्म होने का सबसे पहला समय और खत्म होने के सबसे नए समय के बीच का अंतर होती है. उदाहरण के लिए, उपयोगकर्ता उस मात्रा को हर घंटे की लागत के तौर पर असाइन कर सकते हैं, ताकि काम जल्दी पूरा करने के लिए उसे ऑप्टिमाइज़ किया जा सके. यह लागत |
duration_distance_matrices[] |
इस मॉडल में इस्तेमाल किए गए अवधि और दूरी के मैट्रिक्स को तय करता है. अगर यह फ़ील्ड खाली है, तो इस्तेमाल करने के उदाहरण:
|
duration_distance_matrix_src_tags[] |
अवधि और दूरी के आव्यूहों के स्रोत बताने वाले टैग; टैग |
duration_distance_matrix_dst_tags[] |
अवधि और दूरी के मैट्रिक्स के डेस्टिनेशन तय करने वाले टैग; टैग |
transition_attributes[] |
मॉडल में ट्रांज़िशन एट्रिब्यूट जोड़े गए. |
shipment_type_incompatibilities[] |
ऐसे शिपमेंट_टाइप के सेट जिनका इस्तेमाल नहीं किया जा सकता ( |
shipment_type_requirements[] |
|
precedence_rules[] |
प्राथमिकता के नियमों का सेट, जिसे इस मॉडल में लागू किया जाना चाहिए. |
max_active_vehicles |
चालू वाहनों की ज़्यादा से ज़्यादा संख्या को सीमित करता है. कोई वाहन तब चालू रहता है, जब उसके रास्ते में कम से कम एक शिपमेंट भेजा जाता हो. इसका इस्तेमाल उन रास्तों की संख्या को सीमित करने के लिए किया जा सकता है जहां वाहनों की तुलना में ड्राइवर की संख्या कम हो और वाहन एक साथ कई न हों. इसके बाद, ऑप्टिमाइज़ेशन के तहत, इस्तेमाल करने के लिए वाहनों का सबसे अच्छा सबसेट चुना जाएगा. पूरी तरह सकारात्मक होना चाहिए. |
DurationDistanceMatrix
विज़िट की गई जगहों, वाहन के शुरू होने की जगहों, और वाहन के खत्म होने की जगहों से जुड़ी दूरी और दूरी के मैट्रिक्स की जानकारी देता है.
फ़ील्ड | |
---|---|
rows[] |
अवधि और दूरी के मैट्रिक्स की पंक्तियों को तय करता है. इसमें |
vehicle_start_tag |
इस टैग से पता चलता है कि यह कुल समय और दूरी का मैट्रिक्स किन वाहनों पर लागू होता है. अगर खाली है, तो यह सभी गाड़ियों पर लागू होता है और सिर्फ़ एक आव्यूह हो सकता है. हर वाहन के शुरू होने की वैल्यू, एक मैट्रिक्स से ही मैच होनी चाहिए. इसका मतलब है कि उसके सभी मैट्रिक्स में एक अलग |
पंक्ति
अवधि और दूरी के मैट्रिक्स की पंक्ति दिखाता है.
फ़ील्ड | |
---|---|
durations[] |
किसी पंक्ति के लिए अवधि की वैल्यू. इसमें |
meters[] |
किसी पंक्ति के लिए दूरी की वैल्यू. अगर कोई लागत या सीमा इस मॉडल में दूरी को नहीं बताती है, तो इसे खाली छोड़ा जा सकता है. ऐसा न करने पर, इसमें |
PrecedenceRule
दो इवेंट के बीच प्राथमिकता का नियम (हर इवेंट, किसी शिपमेंट के लिए पिक अप या डिलीवरी है): "पहला" इवेंट शुरू होने के बाद, "दूसरा" इवेंट कम से कम offset_duration
से शुरू होना चाहिए.
कई प्राथमिकताएं एक ही (या मिलते-जुलते) इवेंट के बारे में बता सकती हैं, उदाहरण के लिए, "B का पिक अप, A की डिलीवरी के बाद होता है" और "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) से पहले और उसके बाद ट्रांज़िशन (इंडेक्स + 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 और AGE की व्यवस्था कैसे की जा सकती है.
- वे ओवरलैप नहीं होते.
- देरी यूनीक है और अगली विज़िट (या वाहन खत्म होने से पहले) से ठीक पहले की समयावधि होनी चाहिए. इसलिए, शुरू और खत्म होने का समय जानने के लिए, देरी की अवधि की जानकारी होना काफ़ी है.
- 'BREAKS' समय की ऐसी अवधि होती है जो एक-दूसरे से जुड़ी हुई होती हैं और ओवरलैप नहीं होती हैं. इस रिस्पॉन्स से, हर ब्रेक के शुरू होने का समय और उसकी अवधि की जानकारी मिलती है.
- TRAVEL और AGE "प्रीम्प्टेबल" होते हैं: इस ट्रांज़िशन के दौरान उन्हें कई बार रोका जा सकता है. क्लाइंट यह मान सकते हैं कि यात्रा "जल्द से जल्द" हो जाती है और "इंतज़ार" करने का समय बचा है.
एक (जटिल) उदाहरण:
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], इस रास्ते की i-वीं यात्रा है. अगर यह फ़ील्ड खाली है, तो वाहन को 'इस्तेमाल नहीं किया गया' माना जाएगा. |
transitions[] |
रास्ते के लिए ट्रांज़िशन की क्रम वाली सूची. |
has_traffic_infeasibilities |
जब
Next_visit पर पहुंचने पर, हो सकता है कि वह मौजूदा समय के बाद पहुंच जाए. ऐसा इसलिए है, क्योंकि ट्रैफ़िक की वजह से, यात्रा में लगने वाले समय का अनुमान |
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
नहीं है, तो यात्रा की उससे जुड़ी मेट्रिक 0 होगी.
फ़ील्ड | |
---|---|
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
शिपमेंट के लिए ज़रूरी शर्तों के बारे में बताता है. यह शर्त, उनके शिपमेंट_type के आधार पर तय होती है. ज़रूरी शर्तें, ज़रूरत मोड से तय होती हैं.
फ़ील्ड | |
---|---|
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
}
स्किप किया गया शिपमेंट, सभी वाहनों के साथ काम नहीं करता. सभी वाहनों के लिए, ये वजहें अलग-अलग हो सकती हैं. हालांकि, कम से कम एक वाहन में "सेब" की क्षमता ज़्यादा हो जाएगी (इसमें वाहन 1 भी शामिल है), कम से कम एक वाहन "नाशपाती" की क्षमता से ज़्यादा हो सकता है (इसमें वाहन 3 भी शामिल है) और कम से कम एक वाहन की दूरी सीमा पार हो जाएगी (इसमें पहला वाहन भी शामिल है).
फ़ील्ड | |
---|---|
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
पर या उसके बाद होगा. इसके लिए, soft_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/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 |
traffic_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 |
वेपॉइंट से जुड़ा लोकप्रिय जगह का आईडी. |