Package google.maps.routeoptimization.v1

इंडेक्स

RouteOptimization

वाहन की यात्राओं को ऑप्टिमाइज़ करने की सेवा.

कुछ खास तरह के फ़ील्ड के मान्य होने की अवधि:

  • google.protobuf.Timestamp
    • समय, यूनिक्स टाइम में दिया गया है: 1970-01-01T00:00:00+00:00 से सेकंड.
    • सेकंड की वैल्यू [0, 253402300799] के बीच होनी चाहिए. इसका मतलब है कि [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] के बीच होनी चाहिए.
    • nanos को अनसेट या 0 पर सेट किया जाना चाहिए.
  • google.protobuf.Duration
    • सेकंड की वैल्यू [0, 253402300799] के बीच होनी चाहिए. इसका मतलब है कि [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] के बीच होनी चाहिए.
    • nanos को अनसेट या 0 पर सेट किया जाना चाहिए.
  • google.type.LatLng
    • अक्षांश की वैल्यू, [-90.0, 90.0] के बीच होनी चाहिए.
    • देशांतर [-180.0, 180.0] के बीच होना चाहिए.
    • अक्षांश और देशांतर, दोनों में से कम से कम एक वैल्यू शून्य से ज़्यादा होनी चाहिए.
BatchOptimizeTours

rpc BatchOptimizeTours(BatchOptimizeToursRequest) returns (Operation)

एक या उससे ज़्यादा OptimizeToursRequest मैसेज के लिए, वाहन के सफ़र को एक साथ ऑप्टिमाइज़ करता है.

यह तरीका, ज़्यादा समय तक चलने वाला ऑपरेशन (एलआरओ) है. ऑप्टिमाइज़ेशन (OptimizeToursRequest मैसेज) और आउटपुट (OptimizeToursResponse मैसेज) के इनपुट, उपयोगकर्ता के तय किए गए फ़ॉर्मैट में Cloud Storage से पढ़े और उसमें लिखे जाते हैं. OptimizeTours तरीके की तरह, हर OptimizeToursRequest में एक ShipmentModel होता है और यह OptimizeToursResponse दिखाता है. इसमें ShipmentRoute फ़ील्ड होते हैं, जो वाहनों के लिए तय किए गए रास्तों का एक सेट होता है. इन रास्तों से, कुल लागत को कम किया जा सकता है.

उपयोगकर्ता, एलआरओ का स्टेटस देखने के लिए operations.get को पोल कर सकता है:

अगर LRO done फ़ील्ड की वैल्यू 'गलत' है, तो इसका मतलब है कि कम से कम एक अनुरोध अब भी प्रोसेस किया जा रहा है. हो सकता है कि अन्य अनुरोध पूरे हो गए हों और उनके नतीजे Cloud Storage में उपलब्ध हों.

अगर LRO का done फ़ील्ड 'सही' है, तो इसका मतलब है कि सभी अनुरोध प्रोसेस हो गए हैं. जिन अनुरोधों को प्रोसेस कर लिया गया है उनके नतीजे, Cloud Storage में उपलब्ध होंगे. जिन अनुरोधों को पूरा नहीं किया जा सका उनके नतीजे, Cloud Storage में उपलब्ध नहीं होंगे. अगर एलआरओ का error फ़ील्ड सेट है, तो उसमें उन अनुरोधों में से किसी एक की गड़बड़ी शामिल होती है जो पूरा नहीं हो पाया.

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

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

  • https://www.googleapis.com/auth/cloud-platform
IAM की अनुमतियां

parent रिसॉर्स पर, IAM की इस अनुमति की ज़रूरत है:

  • routeoptimization.operations.create

ज़्यादा जानकारी के लिए, IAM दस्तावेज़ देखें.
OptimizeTours

rpc OptimizeTours(OptimizeToursRequest) returns (OptimizeToursResponse)

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

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

इसका मकसद, ShipmentRoute को Vehicle को असाइन करना है, ताकि कुल लागत कम हो सके. लागत में ShipmentModel में बताए गए कई कॉम्पोनेंट होते हैं.

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

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

  • https://www.googleapis.com/auth/cloud-platform
IAM की अनुमतियां

parent रिसॉर्स पर, IAM की इस अनुमति की ज़रूरत है:

  • routeoptimization.locations.use

ज़्यादा जानकारी के लिए, IAM दस्तावेज़ देखें.
OptimizeToursLongRunning

rpc OptimizeToursLongRunning(OptimizeToursRequest) returns (Operation)

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

दिखाए गए long-running operation (LRO) का नाम <parent>/operations/<operation_id> फ़ॉर्मैट में होगा. इसका इस्तेमाल, कैलकुलेशन की प्रोग्रेस को ट्रैक करने के लिए किया जा सकता है. metadata फ़ील्ड का टाइप OptimizeToursLongRunningMetadata है. अगर response फ़ील्ड का टाइप OptimizeToursResponse है, तो इसका मतलब है कि फ़ील्ड को जोड़ दिया गया है.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request देखें.

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

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

  • https://www.googleapis.com/auth/cloud-platform
IAM की अनुमतियां

parent रिसॉर्स पर, IAM की इस अनुमति की ज़रूरत है:

  • routeoptimization.operations.create

ज़्यादा जानकारी के लिए, IAM दस्तावेज़ देखें.
OptimizeToursUri

rpc OptimizeToursUri(OptimizeToursUriRequest) returns (Operation)

यह OptimizeToursLongRunning तरीके का एक वैरिएंट है. इसे ज़्यादा टाइम आउट वैल्यू और बड़े इनपुट/आउटपुट साइज़ के साथ ऑप्टिमाइज़ेशन के लिए डिज़ाइन किया गया है.

क्लाइंट, Google Cloud Storage में सेव किए गए OptimizeToursRequest का यूआरआई तय करता है और सर्वर, OptimizeToursResponse को क्लाइंट के तय किए गए Google Cloud Storage यूआरआई में लिखता है.

कुछ मिनट से ज़्यादा समय लेने वाले और इनपुट/आउटपुट साइज़ 8 एमबी से ज़्यादा वाले ऑप्टिमाइज़ेशन के लिए, OptimizeTours तरीके के बजाय इस तरीके का इस्तेमाल करना चाहिए. हालांकि, इसका इस्तेमाल कम समय और छोटे ऑप्टिमाइज़ेशन के लिए भी किया जा सकता है.

दिखाए गए long-running operation (LRO) का नाम <parent>/operations/<operation_id> फ़ॉर्मैट में होगा. इसका इस्तेमाल, कैलकुलेशन की प्रोग्रेस को ट्रैक करने के लिए किया जा सकता है. metadata फ़ील्ड का टाइप OptimizeToursLongRunningMetadata है. अगर response फ़ील्ड का टाइप OptimizeToursUriResponse है, तो इसका मतलब है कि फ़ील्ड को जोड़ दिया गया है.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request देखें.

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

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

  • https://www.googleapis.com/auth/cloud-platform
IAM की अनुमतियां

parent रिसॉर्स पर, IAM की इस अनुमति की ज़रूरत है:

  • routeoptimization.operations.create

ज़्यादा जानकारी के लिए, IAM दस्तावेज़ देखें.

AggregatedMetrics

ShipmentRoute (सभी Transition और/या Visit (सभी ShipmentRoute) एलिमेंट के लिए OptimizeToursResponse) एलिमेंट के लिए एग्रीगेट की गई मेट्रिक.

फ़ील्ड
performed_shipment_count

int32

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

Duration

किसी रास्ते या समाधान के लिए यात्रा का कुल समय.
wait_duration

Duration

किसी रास्ते या समाधान के लिए इंतज़ार करने का कुल समय.
delay_duration

Duration

किसी रास्ते या समाधान के लिए, देरी की कुल अवधि.
break_duration

Duration

किसी रास्ते या समाधान के लिए, ब्रेक की कुल अवधि.
visit_duration

Duration

किसी रास्ते या समाधान के लिए, विज़िट की कुल अवधि.
total_duration

Duration

कुल अवधि, ऊपर दी गई सभी अवधियों के योग के बराबर होनी चाहिए. रूट के लिए, यह इनके बराबर भी होता है:

[ShipmentRoute.vehicle_end_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_end_time] - [ShipmentRoute.vehicle_start_time][google.maps.routeoptimization.v1.ShipmentRoute.vehicle_start_time]
travel_distance_meters

double

किसी रास्ते या समाधान के लिए, यात्रा की कुल दूरी.
max_loads

map<string, VehicleLoad>

इस रास्ते (सलूशन) पर मौजूद हर प्रॉडक्ट की संख्या के लिए, पूरे रास्ते (सलूशन) पर ज़्यादा से ज़्यादा लोड. इसे सभी Transition.vehicle_loads (सलूशन) के लिए ज़्यादा से ज़्यादा लोड के तौर पर कैलकुलेट किया जाता है. ShipmentRoute.metrics.max_loads.
performed_mandatory_shipment_count

int32

ज़रूरी शिपमेंट की संख्या.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
performed_shipment_penalty_cost_sum

double

पूरे हो चुके शिपमेंट के Shipment.penalty_cost का कुल योग.

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

BatchOptimizeToursMetadata

इस टाइप में कोई फ़ील्ड नहीं होता.

BatchOptimizeToursRequest कॉल के लिए ऑपरेशन का मेटाडेटा.

BatchOptimizeToursRequest

एक साथ कई टूर ऑप्टिमाइज़ करने का अनुरोध, एसिंक्रोनस ऑपरेशन के तौर पर करें. हर इनपुट फ़ाइल में एक OptimizeToursRequest और हर आउटपुट फ़ाइल में एक OptimizeToursResponse होना चाहिए. अनुरोध में, फ़ाइलों को पढ़ने/लिखने और पार्स करने की जानकारी होती है. सभी इनपुट और आउटपुट फ़ाइलें एक ही प्रोजेक्ट में होनी चाहिए.

फ़ील्ड
parent

string

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

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

अगर कोई जगह नहीं बताई जाती है, तो कोई क्षेत्र अपने-आप चुना जाएगा.
model_configs[]

AsyncModelConfig

ज़रूरी है. हर खरीदारी मॉडल के इनपुट/आउटपुट की जानकारी, जैसे कि फ़ाइल पाथ और डेटा फ़ॉर्मैट.

AsyncModelConfig

एक ऑप्टिमाइज़ेशन मॉडल को अलग-अलग समय पर हल करने के बारे में जानकारी.

फ़ील्ड
display_name

string

ज़रूरी नहीं. उपयोगकर्ता के तय किए गए मॉडल के नाम का इस्तेमाल, मॉडल का ट्रैक रखने के लिए, उपयोगकर्ताओं के उपनाम के तौर पर किया जा सकता है.
input_config

InputConfig

ज़रूरी है. इनपुट मॉडल के बारे में जानकारी.
output_config

OutputConfig

ज़रूरी है. आउटपुट के लिए जगह की जानकारी.

BatchOptimizeToursResponse

इस टाइप में कोई फ़ील्ड नहीं होता.

BatchOptimizeToursRequest का जवाब. यह वैल्यू, ऑपरेशन पूरा होने के बाद, लंबे समय तक चलने वाले ऑपरेशन में दिखती है.

BreakRule

वाहन के लिए ब्रेक का समय तय करने के नियम. जैसे, लंच ब्रेक. ब्रेक, एक ऐसी अवधि होती है जब वाहन अपनी मौजूदा जगह पर बिना किसी गतिविधि के खड़ा रहता है और कोई विज़िट नहीं कर पाता. ब्रेक इन स्थितियों में हो सकता है:

  • दो विज़िट के बीच की यात्रा के दौरान (इसमें विज़िट से ठीक पहले या ठीक बाद का समय शामिल होता है, लेकिन विज़िट के बीच का समय शामिल नहीं होता), ऐसे में यह विज़िट के बीच के ट्रांज़िट समय को बढ़ा देता है,
  • या गाड़ी के शुरू होने से पहले (हो सकता है कि गाड़ी ब्रेक के बीच में शुरू न हो), इस मामले में गाड़ी के शुरू होने के समय पर इसका असर नहीं पड़ता.
  • या वाहन के खत्म होने के बाद (वाहन के खत्म होने के समय के साथ).
फ़ील्ड
break_requests[]

BreakRequest

ब्रेक का क्रम. BreakRequest मैसेज देखें.
frequency_constraints[]

FrequencyConstraint

एक से ज़्यादा FrequencyConstraint लागू हो सकते हैं. यह ज़रूरी है कि वे सभी इस BreakRule के BreakRequest से संतुष्ट हों. FrequencyConstraint देखें.

BreakRequest

हर वाहन के लिए ब्रेक का क्रम (जैसे, उनकी संख्या और क्रम) पहले से पता होना चाहिए. दोहराए गए BreakRequest, उस क्रम को उसी क्रम में तय करते हैं जिसमें उन्हें होना चाहिए. उनकी समयसीमाएं (earliest_start_time / latest_start_time) ओवरलैप हो सकती हैं, लेकिन वे ऑर्डर के साथ काम करनी चाहिए (इसकी जांच की जाती है).

फ़ील्ड
earliest_start_time

Timestamp

ज़रूरी है. ब्रेक की शुरुआत का निचला थ्रेशोल्ड (इसमें शामिल है).
latest_start_time

Timestamp

ज़रूरी है. ब्रेक की शुरुआत का ऊपरी बाउंड (शामिल).
min_duration

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

Duration

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

Duration

ज़रूरी है. रास्ते में किसी भी समयावधि का ज़्यादा से ज़्यादा स्पैन, जिसमें कम से कम duration >= min_break_duration का ब्रेक शामिल न हो. यह संख्या पॉज़िटिव होनी चाहिए.

DataFormat

इनपुट और आउटपुट फ़ाइलों के लिए डेटा फ़ॉर्मैट.

Enums
DATA_FORMAT_UNSPECIFIED अमान्य वैल्यू, फ़ॉर्मैट UNSPECIFIED नहीं होना चाहिए.
JSON JavaScript ऑब्जेक्ट नोटेशन.
PROTO_TEXT प्रोटोकॉल बफ़र का टेक्स्ट फ़ॉर्मैट. https://protobuf.dev/reference/protobuf/textformat-spec/ देखें

DistanceLimit

यह एक सीमा है, जो तय करती है कि कितनी दूरी तक यात्रा की जा सकती है. यह सॉफ्ट या हार्ड हो सकता है.

अगर कोई सॉफ्ट लिमिट तय की गई है, तो soft_max_meters और cost_per_kilometer_above_soft_max, दोनों की वैल्यू तय होनी चाहिए. साथ ही, यह भी ज़रूरी है कि दोनों की वैल्यू 0 से ज़्यादा हो.

फ़ील्ड
max_meters

int64

यह एक तय सीमा है, जो दूरी को ज़्यादा से ज़्यादा max_meters तक सीमित करती है. सीमा, नेगेटिव नहीं होनी चाहिए.
soft_max_meters

int64

सॉफ्ट लिमिट, तय की गई दूरी की सीमा को लागू नहीं करती. हालांकि, इसकी सीमा का उल्लंघन करने पर, मॉडल में तय की गई अन्य लागतों के साथ एक ही यूनिट में लागत जुड़ जाती है.

अगर soft_max_meters तय किया गया है, तो यह max_meters से कम होना चाहिए और यह ऋणात्मक नहीं होना चाहिए.
cost_per_kilometer_below_soft_max

double

हर किलोमीटर की लागत, soft_max_meters तक बढ़ गई. इसका फ़ॉर्मूला यह है:

  min(distance_meters, soft_max_meters) / 1000.0 *
  cost_per_kilometer_below_soft_max.

route_distance_limit में यह कीमत काम नहीं करती.
cost_per_kilometer_above_soft_max

double

अगर दूरी soft_max_meters की सीमा से ज़्यादा है, तो हर किलोमीटर की लागत. अगर दूरी तय सीमा से कम है, तो अतिरिक्त शुल्क 0 होगा. अगर दूरी तय सीमा से ज़्यादा है, तो शुल्क का हिसाब लगाने के लिए इस फ़ॉर्मूला का इस्तेमाल किया जाता है:

  (distance_meters - soft_max_meters) / 1000.0 *
  cost_per_kilometer_above_soft_max.

कीमत नेगेटिव नहीं होनी चाहिए.

GcsDestination

Google Cloud Storage में वह जगह जहां आउटपुट फ़ाइलें सेव की जाएंगी.

फ़ील्ड
uri

string

ज़रूरी है. Google Cloud Storage का यूआरआई.

GcsSource

Google Cloud Storage में वह जगह जहां से इनपुट फ़ाइल को पढ़ा जाएगा.

फ़ील्ड
uri

string

ज़रूरी है. gs://bucket/path/to/object फ़ॉर्मैट वाला Google Cloud Storage ऑब्जेक्ट का यूआरआई.

InjectedSolutionConstraint

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

फ़ील्ड
routes[]

ShipmentRoute

इंजेक्शन के लिए सलूशन के रास्ते. हो सकता है कि ओरिजनल सलूशन से कुछ रास्ते हटा दिए जाएं. रास्तों और छोड़े गए शिपमेंट को, injected_first_solution_routes के लिए दी गई मान्यताओं की बुनियादी शर्तों को पूरा करना होगा.
skipped_shipments[]

SkippedShipment

इंजेक्ट करने के लिए, सलूशन के स्किप किए गए शिपमेंट. हो सकता है कि कुछ को ओरिजनल सलूशन से हटा दिया जाए. routes फ़ील्ड देखें.
constraint_relaxations[]

ConstraintRelaxation

वाहनों के शून्य या उससे ज़्यादा ग्रुप के लिए, यह तय करता है कि पाबंदियों को कब और कितना कम करना है. अगर यह फ़ील्ड खाली है, तो वाहन के सभी ऐसे रास्ते पूरी तरह से प्रतिबंधित कर दिए जाते हैं जिनमें कोई डेटा मौजूद है.

ConstraintRelaxation

वाहनों के ग्रुप के लिए, यह तय करता है कि विज़िट पर कौनसी पाबंदियां लगाई जाएंगी और किस लेवल तक. skipped_shipment फ़ील्ड में लिस्ट किए गए शिपमेंट को स्किप किया जा सकता है. इसका मतलब है कि उन्हें प्रोसेस नहीं किया जा सकता.

फ़ील्ड
relaxations[]

Relaxation

vehicle_indices में, वाहनों के साथ रास्तों पर की जाने वाली विज़िट पर लागू होने वाली, विज़िट से जुड़ी पाबंदियों में छूट.
vehicle_indices[]

int32

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

अगर interpret_injected_solutions_using_labels सही है, तो वाहन का इंडेक्स ShipmentRoute.vehicle_index की तरह ही मैप किया जाता है (fields टिप्पणी देखें).

सुकून देने वाले

अगर 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

Level

शर्तों में ढील देने का वह लेवल जो threshold_time और कम से कम threshold_visit_count के बाद की शर्तें पूरी होने पर लागू होता है.
threshold_time

Timestamp

वह समय जब छूट level लागू की जा सकती है.
threshold_visit_count

int32

विज़िट की वह संख्या जिसके बाद छूट level लागू की जा सकती है. अगर threshold_visit_count 0 है (या सेट नहीं है), तो level को सीधे वाहन के शुरू होने पर लागू किया जा सकता है.

अगर यह route.visits_size() + 1 है, तो level सिर्फ़ वाहन के आखिर में लागू किया जा सकता है. अगर यह संख्या route.visits_size() + 1 से ज़्यादा है, तो उस रास्ते के लिए level बिलकुल भी लागू नहीं होगा.

लेवल

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

यहां दी गई जानकारी, छूट के बढ़ते क्रम में दी गई है.

Enums
LEVEL_UNSPECIFIED

डिफ़ॉल्ट रूप से लागू होने वाली पाबंदियों का लेवल: कोई भी पाबंदी नहीं हटाई जाती. इसका मतलब है कि सभी विज़िट पर पूरी पाबंदी लगी रहती है.

इस वैल्यू का इस्तेमाल level में साफ़ तौर पर नहीं किया जाना चाहिए.
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.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] के लिए इनपुट दें.

फ़ील्ड
data_format

DataFormat

ज़रूरी है. इनपुट डेटा का फ़ॉर्मैट.
यूनियन फ़ील्ड source. ज़रूरी है. source इनमें से कोई एक हो सकता है:
gcs_source

GcsSource

Google Cloud Storage की कोई लोकेशन. यह एक ऑब्जेक्ट (फ़ाइल) होना चाहिए.

जगह

किसी जगह (भौगोलिक पॉइंट और वैकल्पिक हेडिंग) को एन्कैप्सुलेट करता है.

फ़ील्ड
lat_lng

LatLng

वेपॉइंट के भौगोलिक निर्देशांक.
heading

int32

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

OptimizeToursLongRunningMetadata

इस टाइप में कोई फ़ील्ड नहीं होता.

OptimizeToursLongRunning कॉल के लिए ऑपरेशन का मेटाडेटा.

OptimizeToursRequest

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

फ़ील्ड
parent

string

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

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

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

Duration

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

असाइनमेंट के लिए टाइम आउट खत्म होने से पहले, सर्वर कोई समाधान जनरेट करेगा. हालांकि, ऐसा सिर्फ़ तब होगा, जब ऐसा करना संभव हो.
model

ShipmentModel

शिपमेंट का मॉडल, जिसे हल करना है.
solving_mode

SolvingMode

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

SearchMode

अनुरोध को हल करने के लिए इस्तेमाल किया गया सर्च मोड.
injected_first_solution_routes[]

ShipmentRoute

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

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

समाधान, मान्य होने से जुड़ी कुछ बुनियादी शर्तों को पूरा करना चाहिए:

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

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

InjectedSolutionConstraint

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

अगर इंजेक्ट किया गया समाधान काम नहीं करता है, तो ज़रूरी नहीं कि पुष्टि करने से जुड़ी गड़बड़ी का मैसेज दिखे. इसके बजाय, गड़बड़ी का ऐसा मैसेज दिख सकता है जिससे पता चलता हो कि समाधान काम नहीं करता.
refresh_details_routes[]

ShipmentRoute

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

नवंबर 2020 से, यह सिर्फ़ उन रास्तों की पॉलीलाइन भरता है जिनमें कोई डेटा मौजूद होता है. साथ ही, इसके लिए populate_polylines के 'सही है' पर सेट होना ज़रूरी है.

सबमिट किए गए रास्तों के route_polyline फ़ील्ड, रास्ते transitions के साथ मेल नहीं खा सकते.

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

Shipment.ignore और Vehicle.ignore का व्यवहार पर कोई असर नहीं पड़ता. खाली नहीं होने वाले सभी रास्तों में, सभी विज़िट के बीच पॉलीलाइन अब भी पॉप्युलेट होती हैं. भले ही, उससे जुड़ी शिपमेंट या वाहनों को अनदेखा किया गया हो.
interpret_injected_solutions_using_labels

bool

अगर सही है, तो:

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

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

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

अगर इंजेक्ट किए गए समाधान में कोई vehicle_label, अनुरोध किए गए वाहन से मेल नहीं खाता है, तो उससे जुड़े रूट को उसके विज़िट के साथ समाधान से हटा दिया जाता है. अगर इंजेक्ट किए गए समाधान में कोई shipment_label, अनुरोध किए गए शिपमेंट से मेल नहीं खाता है, तो उससे जुड़ी विज़िट को समाधान से हटा दिया जाता है. अगर इंजेक्ट किए गए समाधान में कोई SkippedShipment.label, अनुरोध किए गए शिपमेंट से मेल नहीं खाता है, तो समाधान से SkippedShipment हटा दिया जाता है.

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

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

bool

ShipmentRoute फ़ील्ड Transition.travel_duration, Visit.start_time, और vehicle_end_time की गिनती करते समय, ट्रैफ़िक का अनुमान लगाएं. साथ ही, ShipmentRoute.has_traffic_infeasibilities फ़ील्ड सेट करते समय और OptimizeToursResponse.total_cost फ़ील्ड की गिनती करते समय भी ऐसा करें.
populate_polylines

bool

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

bool

अगर यह सही है, तो ShipmentRoute.transitions के जवाब में पॉलीलाइन और रास्ते के टोकन अपने-आप भर जाएंगे.
allow_large_deadline_despite_interruption_risk

bool

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

bool

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

string

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

double

जब use_geodesic_distances सही होता है, तो यह फ़ील्ड सेट होना चाहिए. साथ ही, इससे यात्रा में लगने वाले समय का हिसाब लगाने के लिए, लागू की गई स्पीड का पता चलता है. इसकी वैल्यू कम से कम 1.0 मीटर/सेकंड होनी चाहिए.
max_validation_errors

int32

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

SearchMode

यह मोड, खोज के व्यवहार को तय करता है. इसमें इंतज़ार का समय और समाधान की क्वालिटी के बीच का अंतर तय किया जाता है. सभी मोड में, अनुरोध की ग्लोबल समयसीमा लागू होती है.

Enums
SEARCH_MODE_UNSPECIFIED खोज मोड की जानकारी नहीं दी गई है. यह RETURN_FAST के बराबर है.
RETURN_FAST पहला अच्छा समाधान मिलने के बाद, खोज बंद कर दें.
CONSUME_ALL_AVAILABLE_TIME बेहतर समाधान खोजने के लिए, अपना सारा समय लगाएं.

SolvingMode

इससे यह तय होता है कि सॉल्वर को अनुरोध को कैसे हैंडल करना चाहिए. VALIDATE_ONLY के अलावा सभी मोड में, अगर अनुरोध अमान्य है, तो आपको INVALID_REQUEST गड़बड़ी का मैसेज मिलेगा. गड़बड़ियों की संख्या को सीमित करने के लिए, max_validation_errors देखें.

Enums
DEFAULT_SOLVE मॉडल को हल करें. [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] में चेतावनियां जारी की जा सकती हैं.
VALIDATE_ONLY मॉडल को हल किए बिना सिर्फ़ उसकी पुष्टि करता है: ज़्यादा से ज़्यादा OptimizeToursResponse.validation_errors पॉप्युलेट करता है.
DETECT_SOME_INFEASIBLE_SHIPMENTS

सिर्फ़ OptimizeToursResponse.validation_errors या OptimizeToursResponse.skipped_shipments को पॉप्युलेट करता है और बाकी अनुरोध को हल नहीं करता. जवाब में status और routes सेट नहीं होते. अगर injected_solution_constraint रास्तों में कोई समस्या का पता चलता है, तो उन्हें OptimizeToursResponse.validation_errors फ़ील्ड में भर दिया जाता है और OptimizeToursResponse.skipped_shipments को खाली छोड़ दिया जाता है.

अहम जानकारी: यहां उन सभी शिपमेंट की जानकारी नहीं दी जाती है जो प्रोसेस नहीं किए जा सकते. सिर्फ़ उन शिपमेंट की जानकारी दी जाती है जिन्हें प्रोसेस करने से पहले ही, शिप नहीं किए जा सकने के तौर पर मार्क कर दिया जाता है.
TRANSFORM_AND_RETURN_REQUEST

यह मोड सिर्फ़ तब काम करता है, जब ShipmentModel.objectives खाली न हो. अनुरोध हल नहीं किया गया है. इसमें सिर्फ़ उन लक्ष्यों के हिसाब से लागत की पुष्टि की जाती है और उन्हें भरा जाता है. ShipmentModel.objectives का दस्तावेज़ भी देखें. इसके बाद, अनुरोध को OptimizeToursResponse.processed_request के तौर पर दिखाया जाता है.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request देखें.

OptimizeToursResponse

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

फ़ील्ड
routes[]

ShipmentRoute

हर वाहन के लिए कैलकुलेट किए गए रूट; i-वां रूट, मॉडल में i-वें वाहन से मेल खाता है.
request_label

string

अगर अनुरोध में कोई लेबल बताया गया था, तो OptimizeToursRequest.label की कॉपी.
skipped_shipments[]

SkippedShipment

उन सभी शिपमेंट की सूची जिन्हें स्किप किया गया है.
validation_errors[]

OptimizeToursValidationError

पुष्टि करने से जुड़ी उन सभी गड़बड़ियों की सूची जिन्हें हमने खुद से पता लगाया है. OptimizeToursValidationError मैसेज के लिए, "कई गड़बड़ियां" की जानकारी देखें. अगर solving_mode DEFAULT_SOLVE है, तो गड़बड़ियों के बजाय चेतावनियां शामिल होंगी.
processed_request

OptimizeToursRequest

कुछ मामलों में, हम आने वाले अनुरोध को हल करने से पहले उसमें बदलाव करते हैं. जैसे, शुल्क जोड़ना. अगर solving_mode == TRANSFORM_AND_RETURN_REQUEST है, तो बदले गए अनुरोध को यहां दिखाया जाता है.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request देखें.
metrics

Metrics

इस समाधान के लिए, कुल समय, दूरी, और इस्तेमाल की मेट्रिक.

मेट्रिक

सभी रूट के लिए एग्रीगेट की गई कुल मेट्रिक.

फ़ील्ड
aggregated_route_metrics

AggregatedMetrics

यह डेटा, सभी रास्तों के लिए इकट्ठा किया जाता है. हर मेट्रिक, एक ही नाम के सभी ShipmentRoute.metrics फ़ील्ड का योग (या लोड के लिए, सबसे ज़्यादा वैल्यू) होती है.
skipped_mandatory_shipment_count

int32

ज़रूरी शिपमेंट की संख्या.
used_vehicle_count

int32

इस्तेमाल किए गए वाहनों की संख्या. ध्यान दें: अगर वाहन का रास्ता खाली है और Vehicle.used_if_route_is_empty की वैल्यू 'सही है' है, तो वाहन को इस्तेमाल किया गया माना जाता है.
earliest_vehicle_start_time

Timestamp

इस्तेमाल किए गए वाहन के लिए, सबसे पहले शुरू होने का समय. इसे ShipmentRoute.vehicle_start_time के सभी इस्तेमाल किए गए वाहनों के लिए, कम से कम समय के तौर पर कैलकुलेट किया जाता है.
latest_vehicle_end_time

Timestamp

इस्तेमाल किए गए वाहन के लिए, विज्ञापन दिखाने का आखिरी समय. इसे ShipmentRoute.vehicle_end_time के सभी इस्तेमाल किए गए वाहनों के लिए, ज़्यादा से ज़्यादा समय के तौर पर कैलकुलेट किया जाता है.
costs

map<string, double>

सॉल्यूशन की लागत, जिसे लागत से जुड़े अनुरोध फ़ील्ड के हिसाब से बांटा गया है. इनपुट OptimizeToursRequest के हिसाब से, कुंजियां प्रोटो पाथ होती हैं, जैसे कि "model.shipments.pickups.cost". साथ ही, वैल्यू, उससे जुड़े लागत फ़ील्ड से जनरेट की गई कुल लागत होती हैं, जो पूरे समाधान में एग्रीगेट की जाती हैं. दूसरे शब्दों में, costs["model.shipments.pickups.cost"] का मतलब है, पिकअप के लिए खरीदार से लिए जाने वाले सभी शुल्कों का कुल योग. मॉडल में तय की गई सभी लागतों की जानकारी यहां दी गई है. हालांकि, TransitionAttributes से जुड़ी लागतों की जानकारी 01/2022 से सिर्फ़ एग्रीगेट तरीके से दी गई है.
total_cost

double

समाधान की कुल लागत. लागत के मैप में मौजूद सभी वैल्यू का योग.

OptimizeToursUriMetadata

इस टाइप में कोई फ़ील्ड नहीं होता.

OptimizeToursUri कॉल के लिए ऑपरेशन का मेटाडेटा.

OptimizeToursUriRequest

OptimizeToursUri तरीके का इस्तेमाल करने वाला अनुरोध.

फ़ील्ड
parent

string

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

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

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

Uri

ज़रूरी है. उस Cloud Storage ऑब्जेक्ट का यूआरआई जिसमें OptimizeToursRequest मौजूद है.
output

Uri

ज़रूरी है. उस Cloud Storage ऑब्जेक्ट का यूआरआई जिसमें OptimizeToursResponse शामिल होगा.

OptimizeToursUriResponse

OptimizeToursUri तरीके से मिला जवाब.

फ़ील्ड
output

Uri

ज़रूरी नहीं. Cloud Storage ऑब्जेक्ट का यूआरआई, जिसमें OptimizeToursResponse को JSON या textproto के तौर पर एन्कोड किया गया हो. अगर ऑब्जेक्ट को JSON के तौर पर कोड में बदला गया था, तो ऑब्जेक्ट के नाम का एक्सटेंशन .json होगा. अगर ऑब्जेक्ट को textproto के तौर पर एन्कोड किया गया था, तो ऑब्जेक्ट के नाम का एक्सटेंशन .txtpb होगा.

रिसॉर्स के crc32_checksum का इस्तेमाल करके, यह पुष्टि की जा सकती है कि रिसॉर्स के कॉन्टेंट में बदलाव नहीं किया गया है.

OptimizeToursValidationError

OptimizeToursRequest की पुष्टि करते समय मिली गड़बड़ी या चेतावनी के बारे में बताता है.

फ़ील्ड
code

int32

पुष्टि करने से जुड़ी गड़बड़ी, (code, display_name) पेयर से तय होती है, जो हमेशा मौजूद होता है.

इस सेक्शन के बाद मौजूद फ़ील्ड में, गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है.

कई गड़बड़ियां: कई गड़बड़ियां होने पर, पुष्टि करने की प्रोसेस उनमें से कई को आउटपुट करने की कोशिश करती है. कंपाइलर की तरह ही, यह प्रोसेस भी पूरी तरह से सटीक नहीं होती. पुष्टि करने से जुड़ी कुछ गड़बड़ियां "गंभीर" होंगी. इसका मतलब है कि वे पुष्टि की पूरी प्रोसेस को रोक देंगी. ऐसा display_name="UNSPECIFIED" गड़बड़ियों के साथ-साथ अन्य गड़बड़ियों के लिए भी होता है. कुछ गड़बड़ियों की वजह से, पुष्टि करने की प्रोसेस में अन्य गड़बड़ियां स्किप हो सकती हैं.

स्थिरता: code और display_name बहुत स्थिर होने चाहिए. हालांकि, समय के साथ नए कोड और डिसप्ले नेम दिख सकते हैं. इस वजह से, किसी दिए गए (अमान्य) अनुरोध से, कोई दूसरा (code, display_name) पेयर मिल सकता है. ऐसा इसलिए होता है, क्योंकि नई गड़बड़ी की वजह से पुरानी गड़बड़ी छिप जाती है. उदाहरण के लिए, "कई गड़बड़ियां" देखें.
display_name

string

गड़बड़ी का डिसप्ले नेम.
fields[]

FieldReference

गड़बड़ी के संदर्भ में, ज़्यादातर मामलों में 0 या 1 फ़ील्ड शामिल होते हैं. हालांकि, इसमें एक से ज़्यादा फ़ील्ड भी शामिल हो सकते हैं. उदाहरण के लिए, वाहन #4 और शिपमेंट #2 के पहले पिकअप का रेफ़रंस इस तरह दिया जा सकता है:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} }

हालांकि, ध्यान दें कि किसी गड़बड़ी कोड के लिए, fields की एलिमेंट की संख्या में बदलाव नहीं होना चाहिए.
error_message

string

गड़बड़ी के बारे में ऐसी जानकारी वाली स्ट्रिंग जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. code और error_message के बीच 1:1 मैपिंग होती है (जब कोड != "UNSPECIFIED").

स्टेबिलिटी: स्टेबल नहीं है: किसी code से जुड़ा गड़बड़ी का मैसेज, समय के साथ बदल सकता है. उम्मीद है कि इससे गड़बड़ी के बारे में साफ़ तौर पर पता चलेगा. इसके बजाय, कृपया display_name और code का इस्तेमाल करें.
offending_values

string

इसमें फ़ील्ड की वैल्यू हो सकती हैं. यह सुविधा हमेशा उपलब्ध नहीं होती. आपको इस पर बिलकुल भरोसा नहीं करना चाहिए. इसका इस्तेमाल सिर्फ़ मैन्युअल मॉडल डीबगिंग के लिए करें.

FieldReference

पुष्टि करने से जुड़ी गड़बड़ी के लिए संदर्भ बताता है. FieldReference हमेशा इस फ़ाइल में मौजूद किसी फ़ील्ड को रेफ़र करता है और उसी हैरारकी वाले स्ट्रक्चर का पालन करता है. उदाहरण के लिए, हम वाहन #5 के start_time_windows के एलिमेंट #2 की जानकारी देने के लिए, इनका इस्तेमाल कर सकते हैं:

name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }

हालांकि, हम मैसेज में OptimizeToursRequest या ShipmentModel जैसी टॉप-लेवल इकाइयों को शामिल नहीं करते, ताकि मैसेज में बहुत ज़्यादा जानकारी न हो.

फ़ील्ड
name

string

फ़ील्ड का नाम, जैसे कि "वाहन".
sub_field

FieldReference

अगर ज़रूरी हो, तो बार-बार नेस्ट किया गया सब-फ़ील्ड.

यूनियन फ़ील्ड index_or_key.

index_or_key इनमें से कोई एक हो सकता है:
index

int32

अगर फ़ील्ड दोहराया गया है, तो उसका इंडेक्स.
key

string

अगर फ़ील्ड कोई मैप है, तो यह वैल्यू डालें.

OutputConfig

[BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] के नतीजों के लिए कोई डेस्टिनेशन तय करें.

फ़ील्ड
data_format

DataFormat

ज़रूरी है. आउटपुट डेटा का फ़ॉर्मैट.
यूनियन फ़ील्ड destination. ज़रूरी है. destination इनमें से कोई एक हो सकता है:
gcs_destination

GcsDestination

Google Cloud Storage में वह जगह जहां आउटपुट को सेव करना है.

RouteModifiers

वाहन के रास्तों का हिसाब लगाते समय, शर्तों के एक सेट को पूरा करने के लिए इस्तेमाल किया जाता है. हालांकि, इन शर्तों को पूरा करना ज़रूरी नहीं है. यह Google Maps Platform के Routes Preferred API में मौजूद RouteModifiers से मिलता-जुलता है. ज़्यादा जानकारी के लिए, https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers देखें.

फ़ील्ड
avoid_tolls

bool

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

bool

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

bool

इससे पता चलता है कि फ़ेरी का इस्तेमाल करने से बचना है या नहीं. उन रास्तों को प्राथमिकता दी जाएगी जिनमें फ़ेरी की यात्रा शामिल नहीं है. यह सिर्फ़ मोटर वाले यात्रा के मोड पर लागू होता है.
avoid_indoor

bool

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

शिपमेंट

किसी एक आइटम को पिकअप करने से लेकर डिलीवरी करने तक की प्रोसेस. शिपमेंट को पूरा होने के तौर पर तब ही माना जाएगा, जब कोई यूनीक वाहन पिकअप करने की किसी जगह पर जाए (और उसके हिसाब से स्पेयर कैपेसिटी कम हो जाए) और बाद में डिलीवरी करने की किसी जगह पर जाए (और उसके हिसाब से स्पेयर कैपेसिटी फिर से बढ़ जाए).

फ़ील्ड
display_name

string

शिपमेंट का वह नाम जो उपयोगकर्ता ने तय किया है. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं. साथ ही, UTF-8 वर्णों का इस्तेमाल किया जा सकता है.
pickups[]

VisitRequest

शिपमेंट से जुड़े पिकअप के विकल्पों का सेट. अगर यह जानकारी नहीं दी गई है, तो वाहन को सिर्फ़ डिलीवरी वाली जगह पर जाना होगा.
deliveries[]

VisitRequest

शिपमेंट से जुड़ी डिलीवरी के विकल्पों का सेट. अगर यह जानकारी नहीं दी गई है, तो वाहन को सिर्फ़ पिकअप की जगह पर जाना होगा.
load_demands

map<string, Load>

शिपमेंट की लोड डिमांड (उदाहरण के लिए, वज़न, वॉल्यूम, पैलेट की संख्या वगैरह). मैप में मौजूद कुंजियां, आइडेंटिफ़ायर होनी चाहिए. इनसे, उस लोड के टाइप के बारे में पता चलता हो. साथ ही, इनमें यूनिट भी शामिल होनी चाहिए. उदाहरण के लिए: "weight_kg", "volume_gallons", "pallet_count" वगैरह. अगर कोई दिया गया कुंजी मैप में नहीं दिखता है, तो उससे जुड़े लोड को शून्य माना जाता है.
allowed_vehicle_indices[]

int32

उन वाहनों का सेट जो इस शिपमेंट को पूरा कर सकते हैं. अगर यह फ़ील्ड खाली है, तो सभी वाहन यह कार्रवाई कर सकते हैं. ShipmentModel की vehicles सूची में, वाहनों को उनके इंडेक्स के हिसाब से दिखाया जाता है.
costs_per_vehicle[]

double

इससे पता चलता है कि हर वाहन से इस शिपमेंट की डिलीवरी करने पर, कितनी लागत आएगी. अगर इसकी वैल्यू दी गई है, तो इसमें इनमें से कोई एक होना चाहिए:

  • costs_per_vehicle_indices के जितने एलिमेंट होंगे उतने ही में भी होने चाहिए. costs_per_vehicle[i], मॉडल के वाहन costs_per_vehicle_indices[i] से जुड़ा है.
  • मॉडल में वाहनों की संख्या के बराबर एलिमेंट. i-वां एलिमेंट, मॉडल के वाहन #i से जुड़ा होता है.

ये लागत, penalty_cost की तरह ही इकाई में होनी चाहिए. साथ ही, ये लागत नकारात्मक नहीं होनी चाहिए. अगर कोई ऐसी लागत नहीं है, तो इस फ़ील्ड को खाली छोड़ दें.
costs_per_vehicle_indices[]

int32

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

Duration

यह पिकअप से डिलीवरी तक के सबसे छोटे रास्ते की तुलना में, सबसे लंबे रास्ते पर लगने वाले समय की जानकारी देता है. अगर यह जानकारी दी गई है, तो यह संख्या 0 से बड़ी होनी चाहिए. साथ ही, शिपमेंट में कम से कम एक पिकअप और एक डिलीवरी शामिल होनी चाहिए.

उदाहरण के लिए, मान लें कि t, पिकअप के चुने गए विकल्प से सीधे डिलीवरी के चुने गए विकल्प पर जाने में लगने वाला कम से कम समय है. इसके बाद, pickup_to_delivery_absolute_detour_limit सेटिंग लागू होती है:

start_time(delivery) - start_time(pickup) <=
t + pickup_to_delivery_absolute_detour_limit

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

Duration

इससे यह पता चलता है कि शिपमेंट के पिकअप से लेकर डिलीवरी शुरू होने तक, ज़्यादा से ज़्यादा कितनी देर लग सकती है. अगर यह जानकारी दी गई है, तो यह संख्या 0 से बड़ी होनी चाहिए. साथ ही, शिपमेंट में कम से कम एक पिकअप और एक डिलीवरी शामिल होनी चाहिए. यह इस बात पर निर्भर नहीं करता कि पिकअप और डिलीवरी के लिए कौनसे विकल्प चुने गए हैं. यह वाहन की स्पीड पर भी निर्भर नहीं करता. इसे, रास्ते में आने वाली ज़्यादा से ज़्यादा रुकावटों के साथ भी बताया जा सकता है: समाधान, दोनों खास बातों का ध्यान रखेगा.
shipment_type

string

इस शिपमेंट के लिए "टाइप" बताने वाली कोई स्ट्रिंग, जो खाली नहीं होनी चाहिए. इस सुविधा का इस्तेमाल, shipment_types (ShipmentModel में shipment_type_incompatibilities और shipment_type_requirements देखें) के बीच काम न करने या ज़रूरी शर्तों को तय करने के लिए किया जा सकता है.

यह visit_types से अलग है, जो किसी एक विज़िट के लिए तय किया जाता है: एक ही शिपमेंट से जुड़ी सभी पिकअप/डिलीवरी एक ही shipment_type शेयर करती हैं.
label

string

इस शिपमेंट के लिए लेबल तय करता है. इस लेबल की जानकारी, जवाब में मौजूद ShipmentRoute.Visit के shipment_label में दी जाती है.
ignore

bool

अगर यह सही है, तो इस शिपमेंट को छोड़ दें, लेकिन penalty_cost लागू न करें.

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

injected_first_solution_routes या injected_solution_constraint में किए गए शिपमेंट को अनदेखा करने की अनुमति है. समाधान करने वाला टूल, पिकअप/डिलीवरी से जुड़ी विज़िट को, शिपमेंट के रास्ते से हटा देता है. precedence_rules को भी अनदेखा कर दिया जाएगा.
penalty_cost

double

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

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

double

यह पिकअप से डिलीवरी तक के सबसे छोटे रास्ते की तुलना में, सबसे लंबे रास्ते में लगने वाले समय की जानकारी देता है. अगर यह जानकारी दी गई है, तो यह संख्या 0 से बड़ी होनी चाहिए. साथ ही, शिपमेंट में कम से कम एक पिकअप और एक डिलीवरी शामिल होनी चाहिए.

उदाहरण के लिए, मान लें कि t, पिकअप के चुने गए विकल्प से सीधे डिलीवरी के चुने गए विकल्प पर जाने में लगने वाला कम से कम समय है. इसके बाद, pickup_to_delivery_relative_detour_limit सेटिंग लागू होती है:

start_time(delivery) - start_time(pickup) <=
std::ceil(t * (1.0 + pickup_to_delivery_relative_detour_limit))

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

लोड करें

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

फ़ील्ड
amount

int64

उस विज़िट को पूरा करने वाले वाहन का लोड, कितनी मात्रा में बदलेगा. यह एक पूर्णांक है. इसलिए, उपयोगकर्ताओं को सटीक जानकारी पाने के लिए, सही इकाई चुनने का सुझाव दिया जाता है. यह वैल्यू 0 से ज़्यादा होनी चाहिए.

VisitRequest

वाहन से की जाने वाली विज़िट का अनुरोध: इसमें एक या दो जगह की जानकारी (नीचे देखें), खुलने और बंद होने का समय, और सेवा की अवधि (सामान पिकअप या डिलीवर करने के लिए वाहन के पहुंचने के बाद लगने वाला समय) की जानकारी होती है.

फ़ील्ड
arrival_location

LatLng

यह VisitRequest करते समय, गाड़ी की जगह की जानकारी. अगर शिपमेंट मॉडल में, दूरी और समय के मैट्रिक्स हैं, तो arrival_location की वैल्यू नहीं दी जानी चाहिए.
arrival_waypoint

Waypoint

वह वेपॉइंट जहां यह VisitRequest पूरा होने पर वाहन पहुंचता है. अगर शिपमेंट मॉडल में, दूरी और समय के मैट्रिक्स हैं, तो arrival_waypoint की वैल्यू नहीं दी जानी चाहिए.
departure_location

LatLng

वह जगह जहां VisitRequest पूरा होने के बाद, वाहन निकलता है. अगर यह arrival_location जैसा है, तो इसे हटाया जा सकता है. अगर शिपमेंट मॉडल में, दूरी और समय के मैट्रिक्स हैं, तो departure_location की वैल्यू नहीं दी जानी चाहिए.
departure_waypoint

Waypoint

वह वेपॉइंट जहां यह VisitRequest पूरा करने के बाद वाहन निकलता है. अगर यह arrival_waypoint जैसा है, तो इसे हटाया जा सकता है. अगर शिपमेंट मॉडल में, दूरी और समय के मैट्रिक्स हैं, तो departure_waypoint की वैल्यू नहीं दी जानी चाहिए.
tags[]

string

विज़िट के अनुरोध से जुड़े टैग की जानकारी देता है. खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है.
time_windows[]

TimeWindow

ऐसी टाइम विंडो जो किसी विज़िट के आने के समय को सीमित करती हैं. ध्यान दें कि कोई वाहन, पहुंचने के समय की विंडो के बाहर जा सकता है. इसका मतलब है कि पहुंचने का समय + कुल समय, समय की विंडो में होना ज़रूरी नहीं है. अगर वाहन TimeWindow.start_time से पहले पहुंचता है, तो आपको इंतज़ार करना पड़ सकता है.

TimeWindow के मौजूद न होने का मतलब है कि वाहन किसी भी समय इस विज़िट को पूरा कर सकता है.

टाइम विंडो अलग-अलग होनी चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं होनी चाहिए या एक-दूसरे के बगल में नहीं होनी चाहिए. साथ ही, वे बढ़ते क्रम में होनी चाहिए.

cost_per_hour_after_soft_end_time और soft_end_time सिर्फ़ तब सेट किए जा सकते हैं, जब एक ही समयावधि हो.
duration

Duration

विज़िट की अवधि, यानी वाहन के आने और जाने के बीच लगने वाला समय.इसे इंतज़ार के संभावित समय में जोड़ना होगा. time_windows देखें.
cost

double

वाहन के रास्ते पर, इस विज़िट के अनुरोध को पूरा करने की लागत. इसका इस्तेमाल, शिपमेंट के पिकअप या डिलीवरी के हर विकल्प के लिए अलग-अलग शुल्क चुकाने के लिए किया जा सकता है. यह कीमत, Shipment.penalty_cost की तरह ही होनी चाहिए. साथ ही, यह नकारात्मक नहीं होनी चाहिए.
load_demands

map<string, Load>

इस विज़िट के अनुरोध की मांगें लोड करें. यह Shipment.load_demands फ़ील्ड की तरह ही है. हालांकि, यह पूरे Shipment के बजाय सिर्फ़ इस VisitRequest पर लागू होता है. यहां दी गई मांगों को Shipment.load_demands में दी गई मांगों में जोड़ दिया गया है.
visit_types[]

string

विज़िट के टाइप बताता है. इसका इस्तेमाल, किसी वाहन को इस विज़िट को पूरा करने के लिए ज़रूरी अतिरिक्त समय देने के लिए किया जा सकता है (Vehicle.extra_visit_duration_for_visit_type देखें).

एक टाइप सिर्फ़ एक बार दिख सकता है.
label

string

इस VisitRequest के लिए लेबल तय करता है. इस लेबल को जवाब में, उससे जुड़े ShipmentRoute.Visit में visit_label के तौर पर रिपोर्ट किया जाता है.
avoid_u_turns

bool

इससे पता चलता है कि इस जगह पर ड्राइविंग के रास्तों में यू-टर्न लेने से बचना चाहिए या नहीं. यू-टर्न से बचने की कोशिश की जाएगी, लेकिन इसकी कोई गारंटी नहीं है कि ऐसा हमेशा हो पाएगा. यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है. इसलिए, इसमें बदलाव हो सकते हैं.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request देखें.

ShipmentModel

शिपमेंट मॉडल में शिपमेंट का एक सेट होता है. इसे वाहनों के एक सेट से पूरा किया जाना चाहिए. साथ ही, कुल लागत को कम करना चाहिए. कुल लागत में ये चीज़ें शामिल होती हैं:

  • वाहनों को रूट करने की लागत (कुल समय के हिसाब से लागत, यात्रा के समय के हिसाब से लागत, और सभी वाहनों के लिए तय लागत का योग).
  • शिपमेंट न करने पर लगने वाले जुर्माने.
  • शिपमेंट की पूरी अवधि के लिए खरीदार से लिया जाने वाला शुल्क
फ़ील्ड
shipments[]

Shipment

मॉडल में की जाने वाली शिपिंग का सेट.
vehicles[]

Vehicle

उन वाहनों का सेट जिनका इस्तेमाल विज़िट करने के लिए किया जा सकता है.
objectives[]

Objective

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

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request देखें.
global_start_time

Timestamp

मॉडल के शुरू और खत्म होने का ग्लोबल समय: इस सीमा से बाहर के किसी भी समय को मान्य नहीं माना जा सकता.

मॉडल का टाइम स्पैन एक साल से कम होना चाहिए. इसका मतलब है कि global_end_time और global_start_time के बीच का अंतर 31,536,000 सेकंड से ज़्यादा नहीं होना चाहिए.

cost_per_*hour फ़ील्ड का इस्तेमाल करते समय, परफ़ॉर्मेंस को बेहतर बनाने के लिए, हो सकता है कि आप इस विंडो को छोटे इंटरवल पर सेट करना चाहें. उदाहरण के लिए, अगर किसी एक दिन का मॉडल बनाया जाता है, तो आपको उस दिन के लिए ग्लोबल टाइम लिमिट सेट करनी चाहिए. अगर यह सेट नहीं है, तो डिफ़ॉल्ट रूप से 1 जनवरी, 1970 को 00:00:00 यूटीसी (यानी सेकंड: 0, नैनो: 0) का इस्तेमाल किया जाता है.
global_end_time

Timestamp

अगर इसकी वैल्यू सेट नहीं की जाती है, तो डिफ़ॉल्ट रूप से 1 जनवरी, 1971 को 00:00:00 यूटीसी (यानी सेकंड: 31,536,000, नैनो सेकंड: 0) का इस्तेमाल किया जाता है.
global_duration_cost_per_hour

double

पूरे प्लान की "ग्लोबल अवधि", सभी वाहनों के शुरू होने के सबसे पहले समय और खत्म होने के सबसे बाद के समय के बीच का अंतर होती है. उदाहरण के लिए, उपयोगकर्ता उस संख्या के लिए हर घंटे की लागत असाइन कर सकते हैं, ताकि जॉब को जल्द से जल्द पूरा करने के लिए उसे ऑप्टिमाइज़ किया जा सके. यह लागत, Shipment.penalty_cost की तरह ही यूनिट में होनी चाहिए.
duration_distance_matrices[]

DurationDistanceMatrix

मॉडल में इस्तेमाल की गई अवधि और दूरी की मैट्रिक के बारे में बताता है. अगर यह फ़ील्ड खाली है, तो use_geodesic_distances फ़ील्ड की वैल्यू के आधार पर, Google Maps या जियोडेसिक दूरी का इस्तेमाल किया जाएगा. अगर यह खाली नहीं है, तो use_geodesic_distances सही नहीं हो सकता. साथ ही, duration_distance_matrix_src_tags और duration_distance_matrix_dst_tags, दोनों खाली नहीं हो सकते.

इस्तेमाल के उदाहरण:

  • दो जगहें हैं: locA और locB.
  • एक वाहन, locA से अपना रास्ता शुरू करता है और locA पर खत्म करता है.
  • locB पर पिकअप के लिए एक अनुरोध.
model {
  vehicles { start_tags: "locA"  end_tags: "locA" }
  shipments { pickups { tags: "locB" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_dst_tags: "locA"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrices {
    rows {  # from: locA
      durations { seconds: 0 }   meters: 0    # to: locA
      durations { seconds: 100 } meters: 1000 # to: locB
    }
    rows {  # from: locB
      durations { seconds: 102 } meters: 990 # to: locA
      durations { seconds: 0 }   meters: 0   # to: locB
    }
  }
}
  • तीन जगहें हैं: locA, locB, और locC.
  • एक वाहन, locA से locB तक का रास्ता तय करता है. इसके लिए, मैट्रिक "fast" का इस्तेमाल किया जाता है.
  • एक वाहन, locB से अपना रास्ता शुरू करता है और locB पर खत्म करता है. इसके लिए, मैट्रिक "slow" का इस्तेमाल किया जाता है.
  • एक वाहन, locB से अपना रास्ता शुरू करता है और locB पर खत्म करता है. इसके लिए, मैट्रिक "fast" का इस्तेमाल किया जाता है.
  • locC पर, पिकअप के लिए एक बार आने का अनुरोध.
model {
  vehicles { start_tags: "locA" end_tags: "locB" start_tags: "fast" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "slow" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "fast" }
  shipments { pickups { tags: "locC" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_src_tags: "locC"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrix_dst_tags: "locC"
  duration_distance_matrices {
    vehicle_start_tag: "fast"
    rows {  # from: locA
      durations { seconds: 1000 } meters: 2000 # to: locB
      durations { seconds: 600 }  meters: 1000 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }   meters: 0    # to: locB
      durations { seconds: 700 } meters: 1200 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 702 } meters: 1190 # to: locB
      durations { seconds: 0 }   meters: 0    # to: locC
    }
  }
  duration_distance_matrices {
    vehicle_start_tag: "slow"
    rows {  # from: locA
      durations { seconds: 1800 } meters: 2001 # to: locB
      durations { seconds: 900 }  meters: 1002 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }    meters: 0    # to: locB
      durations { seconds: 1000 } meters: 1202 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 1001 } meters: 1195 # to: locB
      durations { seconds: 0 }    meters: 0    # to: locC
    }
  }
}
duration_distance_matrix_src_tags[]

string

ये टैग, कुल समय और दूरी की मैट्रिक के सोर्स की जानकारी देते हैं. duration_distance_matrices(i).rows(j), मैट्रिक i में टैग duration_distance_matrix_src_tags(j) वाली विज़िट से अन्य विज़िट तक के कुल समय और दूरी की जानकारी देता है.

टैग, VisitRequest.tags या Vehicle.start_tags से जुड़े हों. दिया गया VisitRequest या Vehicle, इस फ़ील्ड में मौजूद किसी एक टैग से पूरी तरह मैच करना चाहिए. ध्यान दें कि Vehicle के सोर्स, डेस्टिनेशन, और मैट्रिक टैग एक ही हो सकते हैं. इसी तरह, VisitRequest के सोर्स और डेस्टिनेशन टैग एक ही हो सकते हैं. सभी टैग अलग-अलग होने चाहिए और वे खाली स्ट्रिंग नहीं हो सकते. अगर यह फ़ील्ड खाली नहीं है, तो duration_distance_matrices भी खाली नहीं होना चाहिए.
duration_distance_matrix_dst_tags[]

string

कुल समय और दूरी के मैट्रिक के डेस्टिनेशन तय करने वाले टैग; duration_distance_matrices(i).rows(j).durations(k) (resp. duration_distance_matrices(i).rows(j).meters(k)), मैट्रिक i में टैग duration_distance_matrix_src_tags(j) से टैग duration_distance_matrix_dst_tags(k) तक की यात्रा की अवधि (या दूरी) तय करता है.

टैग, VisitRequest.tags या Vehicle.start_tags से जुड़े हों. दिया गया VisitRequest या Vehicle, इस फ़ील्ड में मौजूद किसी एक टैग से पूरी तरह मैच करना चाहिए. ध्यान दें कि Vehicle के सोर्स, डेस्टिनेशन, और मैट्रिक टैग एक ही हो सकते हैं. इसी तरह, VisitRequest के सोर्स और डेस्टिनेशन टैग एक ही हो सकते हैं. सभी टैग अलग-अलग होने चाहिए और वे खाली स्ट्रिंग नहीं हो सकते. अगर यह फ़ील्ड खाली नहीं है, तो duration_distance_matrices भी खाली नहीं होना चाहिए.
transition_attributes[]

TransitionAttributes

मॉडल में ट्रांज़िशन एट्रिब्यूट जोड़े गए.
shipment_type_incompatibilities[]

ShipmentTypeIncompatibility

shipment_types के ऐसे सेट जो साथ काम नहीं करते (ShipmentTypeIncompatibility देखें).
shipment_type_requirements[]

ShipmentTypeRequirement

shipment_type की ज़रूरी शर्तों के सेट (ShipmentTypeRequirement देखें).
precedence_rules[]

PrecedenceRule

प्राथमिकता वाले नियमों का सेट, जिसे मॉडल में लागू करना ज़रूरी है.

अहम जानकारी: प्राथमिकता के नियमों का इस्तेमाल करने से, समस्या का साइज़ सीमित हो जाता है. प्राथमिकता के नियमों का इस्तेमाल करके किए गए ऐसे अनुरोधों को अस्वीकार किया जा सकता है जिनमें कई शिपमेंट शामिल हैं.
max_active_vehicles

int32

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

DurationDistanceMatrix

यह विज़िट और वाहन की शुरुआती जगह से लेकर विज़िट और वाहन की आखिरी जगह तक की अवधि और दूरी का मैट्रिक बताता है.

फ़ील्ड
rows[]

Row

यह अवधि और दूरी के मैट्रिक की पंक्तियों के बारे में बताता है. इसमें ShipmentModel.duration_distance_matrix_src_tags के बराबर एलिमेंट होने चाहिए.
vehicle_start_tag

string

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

हर वाहन की शुरुआत, सिर्फ़ एक मेट्रिक से मेल खानी चाहिए. इसका मतलब है कि उसका एक start_tags फ़ील्ड, मेट्रिक के vehicle_start_tag फ़ील्ड से मेल खाना चाहिए.

सभी मैट्रिस में अलग-अलग vehicle_start_tag होना चाहिए.

पंक्ति

यह समय और दूरी की मैट्रिक की लाइन तय करता है.

फ़ील्ड
durations[]

Duration

किसी पंक्ति के लिए, अवधि की वैल्यू. इसमें ShipmentModel.duration_distance_matrix_dst_tags के बराबर एलिमेंट होने चाहिए.
meters[]

double

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

मकसद

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

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request देखें.

फ़ील्ड
type

Type

मकसद का टाइप.
weight

double

दूसरे लक्ष्यों की तुलना में, इस लक्ष्य को कितना महत्व देना चाहिए. यह कोई भी गैर-नेगेटिव संख्या हो सकती है. हालांकि, वज़न का योग 1 नहीं होना चाहिए. वेट की डिफ़ॉल्ट वैल्यू 1.0 होती है.

टाइप

मकसद का टाइप, जिसे लागत के सेट से मैप किया जाएगा.

Enums
DEFAULT सही समाधान पाने के लिए, शुल्कों के डिफ़ॉल्ट सेट का इस्तेमाल किया जाएगा. ध्यान दें: इस लक्ष्य का इस्तेमाल अपने-आप किया जा सकता है. हालांकि, अगर यह पहले से मौजूद नहीं है, तो उपयोगकर्ता के तय किए गए लक्ष्यों में, इसे हमेशा बेसलाइन के तौर पर, वेट 1.0 के साथ जोड़ा जाएगा.
MIN_DISTANCE "MIN" के लक्ष्य. तय की गई कुल दूरी कम करें.
MIN_WORKING_TIME सभी वाहनों के लिए, कुल काम करने का समय कम से कम करें.
MIN_TRAVEL_TIME यह ऊपर बताए गए तरीके जैसा ही है. हालांकि, इसमें सिर्फ़ यात्रा के समय पर फ़ोकस किया जाता है.
MIN_NUM_VEHICLES इस्तेमाल किए जाने वाले वाहनों की संख्या कम करें.

PrecedenceRule

दो इवेंट के बीच प्राथमिकता का नियम (हर इवेंट, शिपमेंट का पिकअप या डिलीवरी है): "पहले" इवेंट के शुरू होने के कम से कम offset_duration बाद, "दूसरे" इवेंट को शुरू करना होगा.

कई प्राथमिकताएं, एक ही (या मिलते-जुलते) इवेंट का रेफ़रंस दे सकती हैं. जैसे, "A की डिलीवरी के बाद B को पिकअप किया जाता है" और "B के पिकअप के बाद C को पिकअप किया जाता है".

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

फ़ील्ड
first_is_delivery

bool

इससे पता चलता है कि "पहला" इवेंट डिलीवरी है या नहीं.
second_is_delivery

bool

इससे पता चलता है कि "दूसरा" इवेंट डिलीवरी है या नहीं.
offset_duration

Duration

"पहले" और "दूसरे" इवेंट के बीच का ऑफ़सेट. यह नेगेटिव हो सकता है.
first_index

int32

"पहले" इवेंट का शिपमेंट इंडेक्स. यह फ़ील्ड भरना ज़रूरी है.
second_index

int32

"second" इवेंट का शिपमेंट इंडेक्स. यह फ़ील्ड भरना ज़रूरी है.

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 को कैसे व्यवस्थित किया जा सकता है.

  • वे ओवरलैप नहीं होते.
  • DELAY यूनीक होता है और अगली विज़िट (या वाहन के खत्म होने) से ठीक पहले, यह लगातार एक समयावधि होनी चाहिए. इसलिए, डिलीवरी में लगने वाले समय की शुरुआत और खत्म होने का समय जानने के लिए, डिलीवरी में लगने वाले समय की जानकारी ही काफ़ी है.
  • ब्रेक, एक-दूसरे से जुड़ी अवधियां होती हैं, जो ओवरलैप नहीं होतीं. जवाब में, हर ब्रेक के शुरू होने का समय और उसकी अवधि की जानकारी दी जाती है.
  • TRAVEL और WAIT "प्रीएमप्ट किए जा सकते हैं": इस ट्रांज़िशन के दौरान, इनमें कई बार रुकावट आ सकती है. क्लाइंट यह मान सकते हैं कि यात्रा "जितनी जल्दी हो सके" पूरी हो जाएगी और बाकी समय "इंतज़ार" में बीत जाएगा.

एक (जटिल) उदाहरण:

                               TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
  ||     |       |           |       |           |         |         ||
  ||  T  |   B   |     T     |       |     B     |         |    D    ||
  ||  r  |   r   |     r     |   W   |     r     |    W    |    e    ||
  ||  a  |   e   |     a     |   a   |     e     |    a    |    l    ||
  ||  v  |   a   |     v     |   i   |     a     |    i    |    a    ||
  ||  e  |   k   |     e     |   t   |     k     |    t    |    y    ||
  ||  l  |       |     l     |       |           |         |         ||
  ||     |       |           |       |           |         |         ||
--++-----------------------------------------------------------------++-->
फ़ील्ड
vehicle_index

int32

रूट पर चलने वाला वाहन, जिसकी पहचान सोर्स ShipmentModel में उसके इंडेक्स से की जाती है.
vehicle_label

string

इस रास्ते पर चलने वाले वाहन का लेबल. अगर यह जानकारी दी गई है, तो यह ShipmentModel.vehicles(vehicle_index).label के बराबर होना चाहिए.
vehicle_start_time

Timestamp

वाहन के रूट शुरू होने का समय.
vehicle_end_time

Timestamp

वह समय जब गाड़ी अपना रास्ता पूरा कर लेती है.
visits[]

Visit

किसी रास्ते को दिखाने वाली विज़िट का क्रम. visits[i] रास्ते में i-वी विज़िट है. अगर यह फ़ील्ड खाली है, तो वाहन को इस्तेमाल न किए जाने वाला माना जाता है.
transitions[]

Transition

रास्ते के लिए ट्रांज़िशन की क्रम से लगाई गई सूची.
has_traffic_infeasibilities

bool

जब OptimizeToursRequest.consider_road_traffic को 'सही' पर सेट किया जाता है, तो यह फ़ील्ड बताता है कि ट्रैफ़िक के आधार पर यात्रा की अनुमानित अवधि का इस्तेमाल करके, रास्ते के समय में होने वाली गड़बड़ियों का अनुमान लगाया जाता है. ट्रैफ़िक के हिसाब से यात्रा में लगने वाले समय, देरी, और विज़िट के बीच के ब्रेक को पूरा करने के लिए, विज़िट और वाहन की समयसीमा के हिसाब से ज़रूरत के मुताबिक समय नहीं हो सकता. ऐसा, पहली विज़िट से पहले या आखिरी विज़िट के बाद हो सकता है. उदाहरण के लिए,

  start_time(previous_visit) + duration(previous_visit) +
  travel_duration(previous_visit, next_visit) > start_time(next_visit)

ट्रैफ़िक की वजह से यात्रा के अनुमानित समय travel_duration(previous_visit, next_visit) में बढ़ोतरी होने की वजह से, next_visit पर पहुंचने में लगने वाला समय, उसकी मौजूदा समयसीमा से ज़्यादा हो सकता है. साथ ही, यात्रा के अनुमानित समय में बढ़ोतरी और विज़िट या ब्रेक के समय की विंडो से जुड़ी पाबंदियों की वजह से, ब्रेक को विज़िट के साथ ओवरलैप किया जा सकता है.
route_polyline

EncodedPolyline

रूट की कोड में बदली गई पॉलीलाइन. यह फ़ील्ड सिर्फ़ तब पॉप्युलेट होता है, जब OptimizeToursRequest.populate_polylines को 'सही है' पर सेट किया गया हो.
breaks[]

Break

इस रास्ते पर चलने वाले वाहन के लिए ब्रेक का शेड्यूल. breaks क्रम, समय के अंतराल दिखाता है. हर अंतराल, start_time से शुरू होता है और duration सेकंड तक चलता है.
metrics

AggregatedMetrics

इस रास्ते के लिए, कुल समय, दूरी, और लोड की मेट्रिक. कॉन्टेक्स्ट के हिसाब से, AggregatedMetrics के फ़ील्ड को सभी ShipmentRoute.transitions या ShipmentRoute.visits के लिए जोड़ा जाता है.
vehicle_fullness

VehicleFullness

VehicleFullness फ़ील्ड, यह कैलकुलेट करने के लिए कि कैप की गई मेट्रिक, वाहन की तय सीमाओं के कितने करीब हैं. इसके फ़ील्ड, कैप किए गए मेट्रिक फ़ील्ड (उदाहरण के लिए, AggregatedMetrics.travel_distance_meters) और वाहन की सीमा (उदाहरण के लिए, Vehicle.route_distance_limit) के बीच के अनुपात होते हैं.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
route_costs

map<string, double>

रास्ते की कीमत, जिसे कीमत से जुड़े अनुरोध फ़ील्ड के हिसाब से बांटा गया है. इनपुट OptimizeToursRequest के हिसाब से, कुंजियां प्रोटो पाथ होती हैं, जैसे कि "model.shipments.pickups.cost". साथ ही, वैल्यू, उससे जुड़े लागत फ़ील्ड से जनरेट की गई कुल लागत होती हैं, जो पूरे रूट पर एग्रीगेट की जाती हैं. दूसरे शब्दों में, costs["model.shipments.pickups.cost"] का मतलब है, रास्ते पर पिकअप करने की सभी लागतों का कुल योग. मॉडल में तय की गई सभी लागतों की जानकारी यहां दी गई है. हालांकि, TransitionAttributes से जुड़ी लागतों की जानकारी 01/2022 से सिर्फ़ एग्रीगेट तरीके से दी गई है.
route_total_cost

double

रास्ते की कुल कीमत. लागत के मैप में मौजूद सभी लागतों का कुल योग.

ब्रेक

ब्रेक के लागू होने की जानकारी देने वाला डेटा.

फ़ील्ड
start_time

Timestamp

ब्रेक शुरू होने का समय.
duration

Duration

ब्रेक की अवधि.

EncodedPolyline

पॉलीलाइन का कोड में बदला गया वर्शन. पॉलीलाइन को कोड में बदलने के बारे में ज़्यादा जानकारी यहां मिल सकती है: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding.

फ़ील्ड
points

string

पॉलीलाइन के कोड में बदले गए पॉइंट दिखाने वाली स्ट्रिंग.

ट्रांज़िशन

रास्ते पर दो इवेंट के बीच ट्रांज़िशन. ShipmentRoute की जानकारी देखें.

अगर वाहन में start_location और/या end_location नहीं है, तो यात्रा से जुड़ी मेट्रिक की वैल्यू 0 होगी.

फ़ील्ड
travel_duration

Duration

इस ट्रांज़िशन के दौरान यात्रा की अवधि.
travel_distance_meters

double

ट्रांज़िशन के दौरान तय की गई दूरी.
traffic_info_unavailable

bool

जब OptimizeToursRequest.consider_road_traffic के ज़रिए ट्रैफ़िक का अनुरोध किया जाता है और Transition के लिए ट्रैफ़िक की जानकारी नहीं मिल पाती, तो यह बूलियन 'सही है' पर सेट हो जाता है. ऐसा कुछ समय के लिए हो सकता है (रीयल टाइम ट्रैफ़िक सर्वर में कभी-कभी रुकावट आ सकती है) या हमेशा के लिए हो सकता है (इस जगह के लिए कोई डेटा नहीं है).
delay_duration

Duration

इस ट्रांज़िशन पर लागू होने वाली देरी की कुल अवधि. अगर कोई देरी है, तो यह अगले इवेंट (विज़िट या वाहन के खत्म होने) से ठीक delay_duration सेकंड पहले शुरू होती है. TransitionAttributes.delay देखें.
break_duration

Duration

अगर कोई ट्रांज़िशन हुआ है, तो उस दौरान हुए ब्रेक की कुल अवधि. हर ब्रेक के शुरू होने के समय और उसकी अवधि की जानकारी ShipmentRoute.breaks में सेव की जाती है.
wait_duration

Duration

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

Duration

ट्रांज़िशन की कुल अवधि, जो आपकी सुविधा के लिए दी गई है. यह बराबर है:

  • अगली विज़िट start_time (या अगर यह आखिरी ट्रांज़िशन है, तो vehicle_end_time) - इस ट्रांज़िशन का start_time;
  • अगर ShipmentRoute.has_traffic_infeasibilities गलत है, तो यह भी लागू होता है: `total_duration = travel_duration + delay_duration
  • break_duration + wait_duration`.
start_time

Timestamp

इस ट्रांज़िशन का शुरू होने का समय.
route_polyline

EncodedPolyline

ट्रांज़िशन के दौरान इस्तेमाल किए गए रास्ते की जानकारी देने वाली कोड की गई पॉलीलाइन. यह फ़ील्ड सिर्फ़ तब पॉप्युलेट होता है, जब populate_transition_polylines को 'सही है' पर सेट किया गया हो.
route_token

string

सिर्फ़ आउटपुट के लिए. यह एक ऐसा टोक़न है जिसे नेविगेशन के दौरान रास्ते को फिर से बनाने के लिए, Navigation SDK को पास किया जा सकता है. साथ ही, रास्ते को फिर से बनाने की स्थिति में, रास्ते को बनाने के मूल मकसद का सम्मान किया जाता है. इस टोकन को एक ओपेक ब्लॉब के तौर पर इस्तेमाल करें. अलग-अलग अनुरोधों में इसकी वैल्यू की तुलना न करें. ऐसा इसलिए, क्योंकि सेवा का वही रास्ता दिखाने पर भी इसकी वैल्यू बदल सकती है. यह फ़ील्ड सिर्फ़ तब पॉप्युलेट होता है, जब populate_transition_polylines को 'सही है' पर सेट किया गया हो.
vehicle_loads

map<string, VehicleLoad>

इस ट्रांज़िशन के दौरान, वाहन के हर उस टाइप के लिए लोड होता है जो इस वाहन के Vehicle.load_limits में दिखता है या इस रूट पर किए गए किसी शिपमेंट पर Shipment.load_demands शून्य से ज़्यादा होता है.

पहले ट्रांज़िशन के दौरान लोड, वाहन के रूट के शुरुआती लोड होते हैं. इसके बाद, हर विज़िट के बाद, विज़िट के load_demands को जोड़ा या घटाया जाता है, ताकि अगले ट्रांज़िशन के लोड का पता चल सके. यह इस बात पर निर्भर करता है कि विज़िट, पिकअप थी या डिलीवरी.

VehicleLoad

किसी दिए गए वाहन टाइप के लिए, रास्ते के किसी हिस्से पर वाहन के असल लोड की रिपोर्टिंग करता है (Transition.vehicle_loads देखें).

फ़ील्ड
amount

int64

वाहन के टाइप के हिसाब से, उस पर लोड की मात्रा. आम तौर पर, लोड की यूनिट उसके टाइप से पता चलती है. Transition.vehicle_loads देखें.

यहां जाएं

किसी रूट के दौरान की गई विज़िट. यह विज़िट, Shipment के पिकअप या डिलीवरी से जुड़ी है.

फ़ील्ड
shipment_index

int32

सोर्स ShipmentModel में shipments फ़ील्ड का इंडेक्स.
is_pickup

bool

अगर यह वैल्यू 'सही' है, तो इसका मतलब है कि विज़िट, Shipment के पिकअप से जुड़ी है. अगर ऐसा नहीं है, तो यह डिलीवरी से जुड़ा होता है.
visit_request_index

int32

Shipment के पिकअप या डिलीवरी फ़ील्ड में VisitRequest का इंडेक्स (is_pickup देखें).
start_time

Timestamp

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

map<string, Load>

शिपमेंट और विज़िट के अनुरोध load_demands के योग के तौर पर, विज़िट लोड की कुल मांग. अगर विज़िट डिलीवरी है, तो वैल्यू नेगेटिव होती हैं. मांगों की रिपोर्ट, Transition.loads (यह फ़ील्ड देखें) के टाइप के हिसाब से की जाती है.
detour

Duration

आपके डिलीवरी पते पर पहुंचने से पहले, रास्ते में जिन शिपमेंट को डिलीवर किया गया है उनकी वजह से, डिलीवरी में लगने वाला अतिरिक्त समय. साथ ही, समयसीमा की वजह से इंतज़ार करने में लगने वाला समय. अगर विज़िट डिलीवरी के लिए है, तो डेलिवरी के लिए किए गए सफ़र का हिसाब, पिकअप के लिए किए गए सफ़र से लगाया जाता है. यह हिसाब इस तरह लगाया जाता है:

start_time(delivery) - start_time(pickup)
- (duration(pickup) + travel duration from the pickup location
to the delivery location).

अगर ऐसा नहीं है, तो इसका हिसाब वाहन start_location से लगाया जाता है और यह इस हिसाब से होता है:

start_time - vehicle_start_time - travel duration from
the vehicle's `start_location` to the visit.
shipment_label

string

अगर Shipment में बताया गया है, तो उससे जुड़े Shipment.label की कॉपी.
visit_label

string

अगर VisitRequest में बताया गया है, तो उससे जुड़े VisitRequest.label की कॉपी.
injected_solution_location_token

int32

विज़िट की जगह की जानकारी दिखाने वाला अपारदर्शी टोकन.

यह फ़ील्ड, नतीजों के रास्तों की विज़िट में तब पॉप्युलेट हो सकता है, जब इस विज़िट के लिए VisitRequest.avoid_u_turns को 'सही' पर सेट किया गया हो या अनुरोध OptimizeToursRequest में ShipmentModel.avoid_u_turns को 'सही' पर सेट किया गया हो.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request देखें.

ShipmentTypeIncompatibility

इससे शिपमेंट के shipment_type के आधार पर, शिपमेंट के बीच की गड़बड़ियों के बारे में पता चलता है. एक ही रास्ते पर, एक-दूसरे के साथ काम न करने वाले शिपमेंट दिखने पर पाबंदी, शिपमेंट के साथ काम न करने वाले मोड के आधार पर लगाई जाती है.

फ़ील्ड
types[]

string

काम न करने वाले टाइप की सूची. सूची में शामिल दो शिपमेंट, जिनका shipment_types अलग-अलग है वे "काम नहीं करते".
incompatibility_mode

IncompatibilityMode

काम न करने की समस्या पर लागू मोड.

IncompatibilityMode

ये मोड बताते हैं कि एक ही रास्ते पर, एक-दूसरे के साथ काम न करने वाले शिपमेंट को कैसे दिखाने से रोका जाता है.

Enums
INCOMPATIBILITY_MODE_UNSPECIFIED काम न करने वाला कोई मोड. इस वैल्यू का कभी भी इस्तेमाल नहीं किया जाना चाहिए.
NOT_PERFORMED_BY_SAME_VEHICLE इस मोड में, एक-दूसरे के साथ काम न करने वाले दो शिपमेंट के लिए, एक ही वाहन का इस्तेमाल नहीं किया जा सकता.
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY

NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY के साथ काम न करने वाले मोड में, दो शिपमेंट के लिए:

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

ShipmentTypeRequirement

इससे शिपमेंट के टाइप के आधार पर, शिपमेंट के लिए ज़रूरी शर्तों के बारे में पता चलता है. ज़रूरी शर्तों के बारे में जानकारी, ज़रूरी शर्त के मोड से मिलती है.

फ़ील्ड
required_shipment_type_alternatives[]

string

dependent_shipment_types के लिए, शिपमेंट के अन्य टाइप की ज़रूरी सूची.
dependent_shipment_types[]

string

dependent_shipment_types फ़ील्ड में टाइप वाले सभी शिपमेंट के लिए, एक ही रास्ते पर required_shipment_type_alternatives टाइप का कम से कम एक शिपमेंट होना ज़रूरी है.

ध्यान दें: shipment_type की शर्तें ऐसी नहीं होनी चाहिए कि वे खुद पर निर्भर हों.
requirement_mode

RequirementMode

ज़रूरी शर्त पर लागू मोड.

RequirementMode

ऐसे मोड जो किसी रूट पर, एक-दूसरे पर निर्भर शिपमेंट के दिखने के तरीके के बारे में बताते हैं.

Enums
REQUIREMENT_MODE_UNSPECIFIED ज़रूरी शर्तों का मोड नहीं बताया गया है. इस वैल्यू का कभी भी इस्तेमाल नहीं किया जाना चाहिए.
PERFORMED_BY_SAME_VEHICLE इस मोड में, सभी "डिपेंडेंट" शिपमेंट को कम से कम एक "ज़रूरी" शिपमेंट के साथ एक ही वाहन से भेजा जाना चाहिए.
IN_SAME_VEHICLE_AT_PICKUP_TIME

IN_SAME_VEHICLE_AT_PICKUP_TIME मोड में, सभी "डिपेंडेंट" शिपमेंट के लिए, पिकअप के समय उनके वाहन में कम से कम एक "ज़रूरी" शिपमेंट होना चाहिए.

इसलिए, "डिपेंडेंट" शिपमेंट के पिकअप के लिए, इनमें से कोई एक होना चाहिए:

  • सिर्फ़ डिलीवरी के लिए "ज़रूरी" ऐसा शिपमेंट जिसे इस रूट पर डिलीवर किया गया हो
  • उससे पहले, उसी रास्ते पर "ज़रूरी" शिपमेंट को पिक अप किया गया हो. अगर "ज़रूरी" शिपमेंट की डिलीवरी होनी है, तो यह डिलीवरी "डिपेंडेंट" शिपमेंट के पिकअप के बाद की जानी चाहिए.
IN_SAME_VEHICLE_AT_DELIVERY_TIME पहले की तरह ही, "डिपेंडेंट" शिपमेंट के लिए, डिलीवरी के समय उनके वाहन में "ज़रूरी" शिपमेंट होना चाहिए.

SkippedShipment

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

फ़ील्ड
index

int32

इंडेक्स, सोर्स ShipmentModel में शिपमेंट के इंडेक्स से मेल खाता है.
label

string

अगर Shipment में बताया गया है, तो उससे जुड़े Shipment.label की कॉपी.
reasons[]

Reason

शिपमेंट को छोड़ने की वजहों की सूची. Reason के ऊपर मौजूद टिप्पणी देखें. अगर हमें यह समझ नहीं आता कि शिपमेंट को क्यों छोड़ा गया था, तो वजहें सेट नहीं की जाएंगी.
penalty_cost

double

यह Shipment.penalty_cost की एक कॉपी है. इसे यहां इसलिए शामिल किया गया है, ताकि किसी शिपमेंट को छोड़ने की गंभीरता को आसानी से देखा जा सके.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
estimated_incompatible_vehicle_ratio

double

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

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

कारण

अगर हम शिपमेंट को छोड़ने की वजह बता सकते हैं, तो इसकी वजहें यहां दी जाएंगी. अगर सभी वाहनों के लिए वजह एक जैसी नहीं है, तो 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 भी शामिल है. इसके अलावा, कम से कम एक वाहन की तय दूरी से ज़्यादा की गई होगी. इनमें वाहन 1 भी शामिल है.

फ़ील्ड
code

Code

कोड की टिप्पणियां देखें.
example_vehicle_indices[]

int32

यह example_vehicle_index जैसा ही है. हालांकि, हम पहचाने गए कई वाहनों की सूची देते हैं. यह ज़रूरी नहीं है कि इस सूची में सभी प्रॉडक्ट शामिल हों. यह सिर्फ़ तब भरा जाता है, जब [fill_example_vehicle_indices_in_skipped_reasons][] सही हो.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
example_exceeded_capacity_type

string

अगर वजह का कोड DEMAND_EXCEEDS_VEHICLE_CAPACITY है, तो इसका मतलब है कि आपने एक तरह की क्षमता से ज़्यादा की है.
example_vehicle_index

int32

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

कोड

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

Enums
CODE_UNSPECIFIED इसका कभी इस्तेमाल नहीं किया जाना चाहिए.
NO_VEHICLE मॉडल में कोई वाहन नहीं है, इसलिए सभी शिपमेंट की सुविधा उपलब्ध नहीं है.
DEMAND_EXCEEDS_VEHICLE_CAPACITY शिपमेंट की मांग, कुछ तरह की कपैसिटी के लिए वाहन की कपैसिटी से ज़्यादा है. इनमें से एक example_exceeded_capacity_type है.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT

इस शिपमेंट को पूरा करने के लिए, वाहन की start_location से शिपमेंट की पिकअप और/या डिलीवरी की जगहों और वाहन की आखिरी जगह तक की कम से कम दूरी, वाहन की route_distance_limit से ज़्यादा है.

ध्यान दें कि इस गिनती के लिए, हम जियोडेसिक दूरियों का इस्तेमाल करते हैं.
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT

इस शिपमेंट को पूरा करने में लगने वाला कम से कम समय, वाहन के route_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 फ़ील्ड खाली नहीं है और यह वाहन उससे जुड़ा नहीं है.
VEHICLE_IGNORED

वाहन के ignore फ़ील्ड की वैल्यू 'सही' है.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
SHIPMENT_IGNORED

शिपमेंट के ignore फ़ील्ड की वैल्यू 'सही' है.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT

injected_solution_constraint में शिपमेंट नहीं किया गया.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED

injected_solution_constraint में बताए गए वाहन के रास्ते से जुड़े नियमों में, किसी भी विज़िट को शामिल करने की अनुमति नहीं है.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
ZERO_PENALTY_COST

शिपमेंट के लिए, जुर्माने की कोई लागत नहीं है. यह मॉडलिंग के बेहतर विकल्प के तौर पर काम का हो सकता है. हालांकि, यह इस बात की जानकारी भी दे सकता है कि किसी शिपमेंट को क्यों छोड़ा गया.

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

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` <= `end_time` and
  0 <= `start_time` <= `soft_start_time` and
  0 <= `soft_end_time` <= `end_time`.
फ़ील्ड
start_time

Timestamp

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

Timestamp

हार्ड टाइम विंडो खत्म होने का समय. अगर कोई वैल्यू नहीं दी जाती है, तो यह ShipmentModel.global_end_time पर सेट हो जाएगी.
soft_start_time

Timestamp

समयावधि के शुरू होने का समय.
soft_end_time

Timestamp

समयसीमा खत्म होने का अनुमानित समय.
cost_per_hour_before_soft_start_time

double

अगर इवेंट, soft_start_time से पहले होता है, तो मॉडल में अन्य लागतों के साथ हर घंटे की लागत जोड़ी जाती है. इसे इस तरह से कैलकुलेट किया जाता है:

   max(0, soft_start_time - t.seconds)
                          * cost_per_hour_before_soft_start_time / 3600,
t being the time of the event.

यह शुल्क, शून्य से ज़्यादा होना चाहिए. साथ ही, यह फ़ील्ड सिर्फ़ तब सेट किया जा सकता है, जब soft_start_time सेट किया गया हो.
cost_per_hour_after_soft_end_time

double

अगर इवेंट soft_end_time के बाद होता है, तो मॉडल में अन्य खर्चों के साथ हर घंटे की लागत जोड़ी जाती है. इसे इस तरह से कैलकुलेट किया जाता है:

   max(0, t.seconds - soft_end_time.seconds)
                    * cost_per_hour_after_soft_end_time / 3600,
t being the time of the event.

यह लागत पॉज़िटिव होनी चाहिए. साथ ही, यह फ़ील्ड सिर्फ़ तब सेट किया जा सकता है, जब soft_end_time सेट किया गया हो.

TransitionAttributes

किसी रूट पर लगातार दो विज़िट के बीच ट्रांज़िशन के एट्रिब्यूट बताता है. एक ही ट्रांज़िशन पर कई TransitionAttributes लागू हो सकते हैं: ऐसे में, सभी अतिरिक्त लागतें जोड़ दी जाती हैं और सबसे सख्त शर्त या सीमा लागू होती है (सामान्य "AND" सेमेटिक्स के हिसाब से).

फ़ील्ड
src_tag

string

ऐसे टैग जो (src->dst) ट्रांज़िशन के सेट को तय करते हैं जिन पर ये एट्रिब्यूट लागू होते हैं.

सोर्स विज़िट या वाहन शुरू होने की जानकारी तब ही मैच होती है, जब उसके VisitRequest.tags या Vehicle.start_tags में src_tag हो या excluded_src_tag न हो. यह इस बात पर निर्भर करता है कि इन दोनों में से कौनसा फ़ील्ड खाली नहीं है.
excluded_src_tag

string

src_tag देखें. src_tag और excluded_src_tag में से किसी एक की वैल्यू खाली नहीं होनी चाहिए.
dst_tag

string

डेस्टिनेशन विज़िट या वाहन के खत्म होने की जानकारी तब ही मैच होती है, जब उसके VisitRequest.tags या Vehicle.end_tags में dst_tag हो या excluded_dst_tag न हो. यह इस बात पर निर्भर करता है कि इन दोनों में से कौनसा फ़ील्ड खाली नहीं है.
excluded_dst_tag

string

dst_tag देखें. dst_tag और excluded_dst_tag में से किसी एक की वैल्यू खाली नहीं होनी चाहिए.
cost

double

इस ट्रांज़िशन को लागू करने की लागत बताता है. यह मॉडल में मौजूद अन्य सभी लागतों की तरह ही एक ही इकाई में होती है. साथ ही, यह नकारात्मक नहीं होनी चाहिए. यह शुल्क, अन्य सभी मौजूदा शुल्कों के ऊपर लागू होता है.
cost_per_kilometer

double

इस ट्रांज़िशन के दौरान, यात्रा की गई दूरी पर लागू होने वाली हर किलोमीटर की कीमत बताता है. यह वैल्यू, वाहनों पर बताए गए किसी भी Vehicle.cost_per_kilometer में जोड़ दी जाती है.
distance_limit

DistanceLimit

इस ट्रांज़िशन को लागू करते समय, यात्रा की दूरी की सीमा तय करता है.

जून 2021 से, सिर्फ़ सॉफ्ट लिमिट का इस्तेमाल किया जा सकता है.
delay

Duration

इस ट्रांज़िशन को लागू करने में लगने वाले समय की जानकारी देता है.

यह देरी, सोर्स विज़िट खत्म होने के बाद और डेस्टिनेशन विज़िट शुरू होने से पहले होती है.

उरी

यूनिफ़ॉर्म रिसॉर्स आइडेंटिफ़ायर, जो किसी ऐसे रिसॉर्स को दिखाता है जिसे Route Optimization API पढ़ और लिख सकता है.

फ़ील्ड
uri

string

संसाधन का यूआरआई. ऐसा हो सकता है कि संसाधन अभी मौजूद न हो.

संसाधन का कॉन्टेंट, JSON या textproto के तौर पर कोड में बदला जाता है. सिर्फ़ Google Cloud Storage के संसाधनों का इस्तेमाल किया जा सकता है. अगर संसाधन को JSON के तौर पर कोड में बदला गया है, तो संसाधन के नाम के बाद .json होना चाहिए. अगर संसाधन को textproto के तौर पर कोड किया गया है, तो संसाधन के नाम के आखिर में .txtpb होना चाहिए. उदाहरण के लिए, JSON कोड में बदली गई फ़ाइल का Google Cloud Storage यूआरआई ऐसा दिख सकता है: gs://bucket/path/input/object.json.

वाहन

शिपमेंट से जुड़ी समस्या वाले वाहन का मॉडल. शिपमेंट से जुड़ी समस्या को हल करने पर, इस वाहन के लिए start_location से शुरू होकर end_location पर खत्म होने वाला रास्ता बन जाएगा. रूट, विज़िट का क्रम होता है (ShipmentRoute देखें).

फ़ील्ड
display_name

string

वाहन का वह नाम जो उपयोगकर्ता ने तय किया है. इसमें ज़्यादा से ज़्यादा 63 वर्ण हो सकते हैं. साथ ही, UTF-8 वर्णों का इस्तेमाल किया जा सकता है.
travel_mode

TravelMode

यात्रा का मोड, जिससे वाहन के लिए इस्तेमाल की जा सकने वाली सड़कों और उसकी स्पीड पर असर पड़ता है. travel_duration_multiple भी देखें.
route_modifiers

RouteModifiers

शर्तों का एक सेट, जो किसी वाहन के लिए रास्तों का हिसाब लगाने के तरीके पर असर डालता है.
start_location

LatLng

वह जगह जहां से वाहन किसी भी शिपमेंट को पिक अप करने से पहले शुरू होता है. अगर इसकी जानकारी नहीं दी जाती है, तो वाहन पहली बार पिकअप करने पर शुरू हो जाता है. अगर शिपमेंट मॉडल में कुल समय और दूरी के मैट्रिक हैं, तो start_location की वैल्यू नहीं दी जानी चाहिए.
start_waypoint

Waypoint

वह वेपॉइंट जो किसी भौगोलिक जगह को दिखाता है. वाहन, शिपमेंट लेने से पहले यहां से शुरू होता है. अगर start_waypoint या start_location में से कोई भी वैल्यू नहीं दी गई है, तो वाहन पहले पिकअप से शुरू होता है. अगर शिपमेंट मॉडल में कुल समय और दूरी के मैट्रिक हैं, तो start_waypoint की वैल्यू नहीं दी जानी चाहिए.
end_location

LatLng

वह भौगोलिक जगह जहां वाहन आखिरी VisitRequest पूरा करने के बाद पहुंचता है. अगर यह जानकारी नहीं दी जाती है, तो वाहन का ShipmentRoute, आखिरी VisitRequest पूरा होने के तुरंत बाद खत्म हो जाता है. अगर शिपमेंट मॉडल में कुल समय और दूरी के मैट्रिक हैं, तो end_location की वैल्यू नहीं दी जानी चाहिए.
end_waypoint

Waypoint

वह वेपॉइंट जो किसी भौगोलिक जगह को दिखाता है जहां वाहन आखिरी VisitRequest पूरा करने के बाद रुकता है. अगर end_waypoint और end_location, दोनों में से किसी की भी वैल्यू नहीं दी गई है, तो वाहन का ShipmentRoute, आखिरी VisitRequest पूरा होने के तुरंत बाद खत्म हो जाता है. अगर शिपमेंट मॉडल में कुल समय और दूरी के मैट्रिक हैं, तो end_waypoint की वैल्यू नहीं दी जानी चाहिए.
start_tags[]

string

वाहन के रास्ते की शुरुआत में जोड़े गए टैग की जानकारी देता है.

खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है.
end_tags[]

string

वाहन के रूट के आखिर में जोड़े गए टैग की जानकारी देता है.

खाली या डुप्लीकेट स्ट्रिंग की अनुमति नहीं है.
start_time_windows[]

TimeWindow

वह समय जब वाहन अपनी शुरुआती जगह से निकल सकता है. ये समयसीमाएं, ग्लोबल समयसीमाओं के अंदर होनी चाहिए (ShipmentModel.global_* फ़ील्ड देखें). अगर कोई समयसीमा तय नहीं की गई है, तो दुनिया भर में लागू होने वाली समयसीमाओं के अलावा कोई और सीमा नहीं होगी.

एक ही बार-बार इस्तेमाल होने वाले फ़ील्ड की टाइम विंडो अलग-अलग होनी चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं हो सकती या उसके बगल में नहीं हो सकती. साथ ही, वे टाइम विंडो, समय के हिसाब से क्रम में होनी चाहिए.

cost_per_hour_after_soft_end_time और soft_end_time सिर्फ़ तब सेट किए जा सकते हैं, जब एक ही समयावधि हो.
end_time_windows[]

TimeWindow

वह समयसीमा जिसके दौरान वाहन, अपनी मंज़िल पर पहुंच सकता है. ये समयसीमाएं, ग्लोबल समयसीमाओं के अंदर होनी चाहिए (ShipmentModel.global_* फ़ील्ड देखें). अगर कोई समयसीमा तय नहीं की गई है, तो दुनिया भर में लागू होने वाली समयसीमाओं के अलावा कोई और सीमा नहीं होगी.

एक ही बार-बार इस्तेमाल होने वाले फ़ील्ड की टाइम विंडो अलग-अलग होनी चाहिए.इसका मतलब है कि कोई भी टाइम विंडो, किसी दूसरी टाइम विंडो के साथ ओवरलैप नहीं हो सकती या उसके बगल में नहीं हो सकती. साथ ही, वे टाइम विंडो, समय के हिसाब से क्रम में होनी चाहिए.

cost_per_hour_after_soft_end_time और soft_end_time सिर्फ़ तब सेट किए जा सकते हैं, जब एक ही समयावधि हो.
unloading_policy

UnloadingPolicy

वाहन पर लागू की गई, सामान उतारने की नीति.
load_limits

map<string, LoadLimit>

वाहन की क्षमताएं (उदाहरण के लिए, वज़न, वॉल्यूम, पैलेट की संख्या). मैप में मौजूद कुंजियां, लोड के टाइप के आइडेंटिफ़ायर होती हैं. ये कुंजियां, Shipment.load_demands फ़ील्ड की कुंजियों से मेल खाती हैं. अगर इस मैप में कोई कुंजी मौजूद नहीं है, तो उससे जुड़ी क्षमता को अनलिमिटेड माना जाता है.
cost_per_hour

double

वाहन की लागत: सभी लागतें जोड़ दी जाती हैं और वे Shipment.penalty_cost की तरह ही एक ही इकाई में होनी चाहिए.

वाहन के रास्ते की हर घंटे की कीमत. यह शुल्क, रास्ते में लगने वाले कुल समय पर लागू होता है. इसमें यात्रा का समय, इंतज़ार का समय, और विज़िट का समय शामिल होता है. सिर्फ़ cost_per_traveled_hour के बजाय cost_per_hour का इस्तेमाल करने पर, थोड़ी देरी हो सकती है.
cost_per_traveled_hour

double

वाहन के रास्ते पर, हर घंटे की यात्रा की लागत. यह लागत, सिर्फ़ रास्ते में लगने वाले समय (यानी ShipmentRoute.transitions में बताए गए समय) पर लागू होती है. इसमें इंतज़ार करने और विज़िट करने का समय शामिल नहीं होता.
cost_per_kilometer

double

वाहन के रास्ते का हर किलोमीटर का किराया. यह शुल्क, ShipmentRoute.transitions में बताई गई दूरी पर लागू होता है. यह किसी एक VisitRequest के arrival_location से departure_location तक की दूरी पर लागू नहीं होता.
fixed_cost

double

अगर इस वाहन का इस्तेमाल शिपमेंट को मैनेज करने के लिए किया जाता है, तो तय की गई कीमत लागू होती है.
used_if_route_is_empty

bool

यह फ़ील्ड सिर्फ़ उन वाहनों पर लागू होता है जिनके रास्ते पर कोई शिपमेंट नहीं होता. इससे पता चलता है कि इस मामले में, वाहन को इस्तेमाल किया गया मानना चाहिए या नहीं.

अगर यह सही है, तो वाहन अपनी शुरुआती जगह से आखिरी जगह तक जाता है, भले ही वह कोई शिपमेंट न करता हो. साथ ही, शुरुआती जगह से आखिरी जगह तक की यात्रा में लगने वाले समय और दूरी की लागत को ध्यान में रखा जाता है.

ऐसा न करने पर, यह वाहन अपनी शुरुआती जगह से आखिरी जगह तक नहीं जाता और इस वाहन के लिए कोई break_rule या देरी (TransitionAttributes से) शेड्यूल नहीं की जाती. इस मामले में, वाहन के ShipmentRoute में वाहन के इंडेक्स और लेबल के अलावा कोई जानकारी नहीं होती.
route_duration_limit

DurationLimit

यह सीमा, वाहन के रास्ते की कुल अवधि पर लागू होती है. किसी OptimizeToursResponse में, किसी वाहन के रास्ते का कुल समय, उसके vehicle_end_time और vehicle_start_time के बीच का अंतर होता है.
travel_duration_limit

DurationLimit

यह सीमा, वाहन के रास्ते की यात्रा की अवधि पर लागू होती है. किसी दिए गए OptimizeToursResponse में, यात्रा में लगने वाला कुल समय, उसके सभी transitions.travel_duration का कुल योग होता है.
route_distance_limit

DistanceLimit

यह सीमा, वाहन के रास्ते की कुल दूरी पर लागू होती है. किसी दिए गए OptimizeToursResponse में, रास्ते की दूरी उसके सभी transitions.travel_distance_meters का योग होती है.
extra_visit_duration_for_visit_type

map<string, Duration>

visit_types स्ट्रिंग से लेकर अवधि तक के मैप की जानकारी देता है. यह समय, visit_types के साथ विज़िट के दौरान लिया जाने वाला समय है.VisitRequest.duration अगर cost_per_hour की वैल्यू दी गई है, तो विज़िट की इस अतिरिक्त अवधि के लिए शुल्क लिया जाता है. कुंजियां (जैसे, visit_types) खाली स्ट्रिंग नहीं हो सकतीं.

अगर विज़िट के अनुरोध के कई टाइप हैं, तो मैप में हर टाइप के लिए एक अवधि जोड़ी जाएगी.
break_rule

BreakRule

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

string

इस वाहन के लिए लेबल तय करता है. इस लेबल को जवाब में, उससे जुड़े ShipmentRoute के vehicle_label के तौर पर रिपोर्ट किया जाता है.
ignore

bool

अगर यह सही है, तो used_if_route_is_empty की वैल्यू गलत होनी चाहिए. साथ ही, इस वाहन का इस्तेमाल नहीं किया जाएगा.

अगर injected_first_solution_routes में, किसी ऐसे वाहन से शिपमेंट किया जाता है जिसे अनदेखा किया गया है, तो उसे पहले समाधान में छोड़ दिया जाता है. हालांकि, जवाब में उसे शामिल किया जा सकता है.

अगर injected_solution_constraint में, किसी ऐसे वाहन से शिपिंग की जाती है जिसे अनदेखा किया गया है और उससे जुड़ी पिकअप/डिलीवरी, वाहन पर ही होनी है (यानी कि RELAX_ALL_AFTER_THRESHOLD लेवल पर नहीं होनी है), तो उसे जवाब में शामिल नहीं किया जाता. अगर किसी शिपमेंट में allowed_vehicle_indices फ़ील्ड खाली नहीं है और अनुमति वाले सभी वाहनों को अनदेखा किया जाता है, तो उसे जवाब में शामिल नहीं किया जाता.
travel_duration_multiple

double

यह एक मल्टीप्लायर फ़ैक्टर होता है. इसका इस्तेमाल, इस वाहन के यात्रा के समय को बढ़ाने या घटाने के लिए किया जा सकता है. उदाहरण के लिए, इसे 2.0 पर सेट करने का मतलब है कि यह वाहन धीमा है और यात्रा में लगने वाला समय, स्टैंडर्ड वाहनों के मुकाबले दोगुना है. इस मल्टीपल का असर, विज़िट के कुल समय पर नहीं पड़ता. अगर cost_per_hour या cost_per_traveled_hour की वैल्यू दी गई है, तो इसकी लागत पर असर पड़ता है. यह वैल्यू, [0.001, 1000.0] की रेंज में होनी चाहिए. अगर यह एट्रिब्यूट सेट नहीं है, तो वाहन स्टैंडर्ड है और इस मल्टीपल को 1.0 माना जाता है.

चेतावनी: इस मल्टीप्लायर को लागू करने के बाद, यात्रा के समय को सबसे नज़दीकी सेकंड में राउंड किया जाएगा. हालांकि, कोई भी अंकों वाला ऑपरेशन करने से पहले ऐसा किया जाएगा. इसलिए, मल्टीप्लायर का छोटा होना, सटीक समय का पता लगाने में रुकावट डाल सकता है.

नीचे extra_visit_duration_for_visit_type भी देखें.

DurationLimit

वाहन के रास्ते की ज़्यादा से ज़्यादा अवधि तय करने वाली सीमा. यह सॉफ्ट या हार्ड हो सकता है.

जब सॉफ्ट लिमिट फ़ील्ड तय किया जाता है, तो सॉफ्ट मैक्स थ्रेशोल्ड और उससे जुड़ी लागत, दोनों को एक साथ तय करना ज़रूरी है.

फ़ील्ड
max_duration

Duration

यह एक तय सीमा है, जो अवधि को ज़्यादा से ज़्यादा max_duration तक सीमित करती है.
soft_max_duration

Duration

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

अगर soft_max_duration की वैल्यू दी गई है, तो यह ऋणात्मक नहीं होनी चाहिए. अगर max_duration एट्रिब्यूट की वैल्यू भी दी गई है, तो soft_max_duration की वैल्यू, max_duration की वैल्यू से कम होनी चाहिए.
quadratic_soft_max_duration

Duration

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

अगर quadratic_soft_max_duration की वैल्यू दी गई है, तो यह ऋणात्मक नहीं होनी चाहिए. अगर max_duration की वैल्यू भी दी गई है, तो quadratic_soft_max_duration की वैल्यू max_duration से कम होनी चाहिए. साथ ही, दोनों वैल्यू के बीच का अंतर एक दिन से ज़्यादा नहीं होना चाहिए:

max_duration - quadratic_soft_max_duration <= 86400 seconds
cost_per_hour_after_soft_max

double

soft_max_duration थ्रेशोल्ड का उल्लंघन होने पर, हर घंटे की लागत. अगर अवधि थ्रेशोल्ड से कम है, तो अतिरिक्त शुल्क 0 होगा. अगर अवधि थ्रेशोल्ड से ज़्यादा है, तो शुल्क इस हिसाब से लगेगा:

  cost_per_hour_after_soft_max * (duration - soft_max_duration)

कीमत नेगेटिव नहीं होनी चाहिए.
cost_per_square_hour_after_quadratic_soft_max

double

quadratic_soft_max_duration थ्रेशोल्ड का उल्लंघन होने पर, हर वर्ग घंटे की लागत.

अगर अवधि थ्रेशोल्ड से कम है, तो अतिरिक्त शुल्क 0 होगा. अगर अवधि थ्रेशोल्ड से ज़्यादा है, तो शुल्क इस हिसाब से लगेगा:

  cost_per_square_hour_after_quadratic_soft_max *
  (duration - quadratic_soft_max_duration)^2

कीमत नेगेटिव नहीं होनी चाहिए.

LoadLimit

इससे किसी वाहन पर लागू होने वाली लोड सीमा के बारे में पता चलता है. उदाहरण के लिए, "इस ट्रक में सिर्फ़ 3,500 किलो तक का सामान लाया जा सकता है". load_limits देखें.

फ़ील्ड
soft_max_load

int64

लोड की एक सॉफ्ट सीमा. cost_per_unit_above_soft_max देखें.
cost_per_unit_above_soft_max

double

अगर इस वाहन के रूट पर लोड कभी भी soft_max_load से ज़्यादा हो जाता है, तो शुल्क के लिए यह जुर्माना लागू होता है (हर वाहन पर सिर्फ़ एक बार): (लोड - soft_max_load) * cost_per_unit_above_soft_max. सभी लागतों को जोड़ दिया जाता है और उन्हें Shipment.penalty_cost की तरह ही इकाई में होना चाहिए.
start_load_interval

Interval

रास्ते की शुरुआत में, वाहन के लोड होने में लगने वाला समय.
end_load_interval

Interval

रास्ते के आखिर में, वाहन के लोड होने में लगने वाला समय.
max_load

int64

लोड की ज़्यादा से ज़्यादा अनुमति वाली रकम.
cost_per_kilometer

LoadCost

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

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request देखें.
cost_per_traveled_hour

LoadCost

इस वाहन के लिए, एक घंटे के दौरान एक यूनिट लोड के साथ यात्रा करने की लागत.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request देखें.

इंटरवल

लोड की जाने वाली रकम का इंटरवल.

फ़ील्ड
min

int64

कम से कम लोड. यह वैल्यू 0 से ज़्यादा होनी चाहिए. अगर दोनों की जानकारी दी गई है, तो min, max से कम होना चाहिए.
max

int64

ज़्यादा से ज़्यादा लोड. यह वैल्यू 0 से ज़्यादा होनी चाहिए. अगर इस एट्रिब्यूट की कोई वैल्यू सबमिट नहीं की जाती है, तो इस मैसेज से ज़्यादा से ज़्यादा लोड पर कोई पाबंदी नहीं होती. अगर दोनों की जानकारी दी गई है, तो min, max से कम होना चाहिए.

LoadCost

Transition के दौरान, एक यूनिट लोड को एक जगह से दूसरी जगह ले जाने की लागत. किसी लोड के लिए, लागत दो हिस्सों का योग होती है:

  • min(load, load_threshold) * cost_per_unit_below_threshold
  • max(0, load - load_threshold) * cost_per_unit_above_threshold

इस लागत के साथ, समाधान पहले ज़्यादा मांग वाले अनुरोधों को डिलीवर करना पसंद करते हैं या ज़्यादा मांग वाले अनुरोधों को आखिर में पिकअप करते हैं. उदाहरण के लिए, अगर किसी वाहन में

load_limit {
  key: "weight"
  value {
    cost_per_kilometer {
      load_threshold: 15
      cost_per_unit_below_threshold: 2.0
      cost_per_unit_above_threshold: 10.0
    }
  }
}

और इसका रूट, ट्रांज़िशन के साथ शुरू,पिकअप,पिकअप,डिलीवरी,डिलीवरी,खत्म है:

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 20 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

तो इस LoadCost की लागत (cost_below * load_below * kilometers + cost_above * load_above * kms) होगी

  • ट्रांज़िशन 0: 0.0
  • पहला ट्रांज़िशन: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • दूसरा ट्रांज़िशन: 2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
  • तीसरा ट्रांज़िशन: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • ट्रांज़िशन 4: 0.0

इसलिए, रास्ते पर LoadCost 120.0 है.

हालांकि, अगर रूट में ट्रांज़िशन के साथ शुरू,पिकअप,डिलीवरी,पिकअप,डिलीवरी,खत्म है, तो:

transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 10 }
             travel_distance_meters: 1000.0 }
transition { vehicle_load['weight'] { amount: 0 }
             travel_distance_meters: 1000.0 }

तो इस LoadCost की लागत

  • ट्रांज़िशन 0: 0.0
  • पहला ट्रांज़िशन: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • ट्रांज़िशन 2: 0.0
  • तीसरा ट्रांज़िशन: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • ट्रांज़िशन 4: 0.0

यहां रास्ते पर LoadCost 40.0 है.

LoadCost की वजह से, ज़्यादा लोड वाले ट्रांज़िशन वाले समाधानों की कीमत ज़्यादा होती है.

एक्सपेरिमेंट के तौर पर उपलब्ध: ज़्यादा जानकारी के लिए, https://developers.google.com/maps/tt/route-optimization/experimental/load-cost/make-request देखें.

फ़ील्ड
load_threshold

int64

लोड की वह रकम जिससे ज़्यादा होने पर, लोड की एक यूनिट को एक जगह से दूसरी जगह ले जाने की लागत, cost_per_unit_below_threshold से cost_per_unit_above_threshold में बदल जाती है. यह वैल्यू 0 से ज़्यादा होनी चाहिए.
cost_per_unit_below_threshold

double

0 से थ्रेशोल्ड के बीच की हर यूनिट के लिए, लोड की एक यूनिट को एक जगह से दूसरी जगह ले जाने की लागत. यह कोई तय वैल्यू होनी चाहिए और 0 से बड़ी होनी चाहिए.
cost_per_unit_above_threshold

double

थ्रेशोल्ड से ज़्यादा हर यूनिट के लिए, लोड की एक यूनिट को एक जगह से दूसरी जगह ले जाने की लागत. खास मामले में थ्रेशोल्ड = 0 होने पर, यह हर यूनिट की तय कीमत होती है. यह कोई तय वैल्यू होनी चाहिए और 0 से बड़ी होनी चाहिए.

TravelMode

यात्रा के ऐसे मोड जिनका इस्तेमाल वाहनों से किया जा सकता है.

ये, Google Maps Platform Routes API के यात्रा के मोड का सबसेट होने चाहिए. ज़्यादा जानकारी के लिए, यह देखें: https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode

ध्यान दें: WALKING रास्तों की जानकारी देने की सुविधा बीटा वर्शन में है. इसलिए, हो सकता है कि कभी-कभी इसमें साफ़-साफ़ दिखने वाले फ़ुटपाथ या पैदल चलने के रास्ते न दिखें. आपको अपने ऐप्लिकेशन में दिखाए जाने वाले, पैदल चलने के सभी रास्तों के लिए, उपयोगकर्ता को यह चेतावनी दिखानी होगी.

Enums
TRAVEL_MODE_UNSPECIFIED यात्रा के मोड की जानकारी नहीं दी गई है. यह DRIVING के बराबर है.
DRIVING ड्राइविंग निर्देशों से जुड़ा यात्रा मोड (कार, ...).
WALKING पैदल चलने के निर्देशों से जुड़ा यात्रा मोड.

UnloadingPolicy

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

unloading_policy के अलावा, अन्य शिपमेंट के लिए, रूट पर कहीं भी शिपिंग की जा सकती है.

Enums
UNLOADING_POLICY_UNSPECIFIED सामान उतारने की नीति के बारे में नहीं बताया गया है. डिलीवरी, पिकअप के बाद ही होनी चाहिए.
LAST_IN_FIRST_OUT डिलीवरी, पिकअप के उलटे क्रम में होनी चाहिए
FIRST_IN_FIRST_OUT डिलीवरी, पिकअप के क्रम में होनी चाहिए

VehicleFullness

VehicleFullness एक मेट्रिक है, जो यह कैलकुलेट करती है कि कोई वाहन कितना भरा हुआ है. हर VehicleFullness फ़ील्ड 0 से 1 के बीच होता है. इसे कैप की गई मेट्रिक फ़ील्ड (उदाहरण के लिए, AggregatedMetrics.travel_distance_meters) और वाहन की सीमा (उदाहरण के लिए, Vehicle.route_distance_limit) के बीच के अनुपात के तौर पर कैलकुलेट किया जाता है. हालांकि, यह ज़रूरी नहीं है कि वाहन की सीमा मौजूद हो. ऐसा न करने पर, फ़ुलनेस रेशियो सेट नहीं होगा. अगर सीमा 0 है, तो फ़ील्ड को 1 पर सेट किया जाता है. ध्यान दें: जब किसी रास्ते पर ट्रैफ़िक की वजह से यात्रा करना मुश्किल हो जाता है, तो हो सकता है कि कुछ वाहनों के लिए, भरी हुई स्थिति का अनुपात 1.0 से ज़्यादा हो. उदाहरण के लिए, हो सकता है कि वाहन तय की गई दूरी से ज़्यादा दूर चला जाए. ऐसे मामलों में, हम फ़ुलनेस वैल्यू को 1.0 पर कैप कर देते हैं.

फ़ील्ड
max_fullness

double

इस मैसेज में मौजूद सभी अन्य फ़ील्ड की ज़्यादा से ज़्यादा संख्या.
distance

double

AggregatedMetrics.travel_distance_meters और Vehicle.route_distance_limit के बीच का अनुपात. अगर Vehicle.route_distance_limit सेट नहीं है, तो यह फ़ील्ड सेट नहीं होगा.
travel_duration

double

[AggregatedMetrics.travel_duration_seconds][] और Vehicle.travel_duration_limit के बीच का अनुपात. अगर Vehicle.travel_duration_limit सेट नहीं है, तो यह फ़ील्ड सेट नहीं होगा.
active_duration

double

[AggregatedMetrics.total_duration_seconds][] और Vehicle.route_duration_limit के बीच का अनुपात. अगर Vehicle.route_duration_limit सेट नहीं है, तो यह फ़ील्ड सेट नहीं होगा.
max_load

double

[AggregatedMetrics.max_load][] के सभी टाइप और उनके Vehicle.load_limits के बीच का ज़्यादा से ज़्यादा अनुपात. अगर सभी Vehicle.load_limits फ़ील्ड सेट नहीं हैं, तो यह फ़ील्ड सेट नहीं होगा.
active_span

double

किसी वाहन के लिए, (vehicle_end_time - vehicle_start_time) / (latest_vehicle_end_time - earliest_vehicle_start_time) का अनुपात. अगर हर मौजूद नहीं है, तो इसके बजाय (ShipmentModel.global_end_time - ShipmentModel.global_start_time) का इस्तेमाल किया जाता है.

वेपॉइंट

वेपॉइंट को एनकैप्सुलेट करता है. वेपॉइंट, विज़िट रिक्वेस्ट के पहुंचने और जाने की जगहों के साथ-साथ, वाहनों के शुरू और खत्म होने की जगहों को मार्क करते हैं.

फ़ील्ड
side_of_road

bool

ज़रूरी नहीं. इससे पता चलता है कि इस वेपॉइंट की जगह पर, वाहन को सड़क की किसी खास तरफ़ रोकने की प्राथमिकता दी गई है. इस वैल्यू को सेट करने पर, रास्ता उस जगह से होकर गुज़रेगा, ताकि वाहन सड़क के उस हिस्से पर रुक सके जो सड़क के बीच से उस जगह की ओर झुका हुआ है. यह विकल्प, 'पैदल चलना' यात्रा मोड के लिए काम नहीं करता.
vehicle_stopover

bool

इससे पता चलता है कि यह वेपॉइंट, वाहनों को रोकने के लिए है, जहां से यात्रियों को बैठाया या छोड़ा जाता है. यह विकल्प सिर्फ़ 'ड्राइविंग' यात्रा मोड के लिए काम करता है. साथ ही, यह तब काम करता है, जब 'location_type' की वैल्यू 'location' हो.

एक्सपेरिमेंटल: आने वाले समय में, इस फ़ील्ड के काम करने के तरीके या इसकी मौजूदगी में बदलाव हो सकता है.
यूनियन फ़ील्ड location_type. किसी जगह की जानकारी दिखाने के अलग-अलग तरीके. location_type इनमें से कोई एक हो सकता है:
location

Location

भौगोलिक निर्देशांक का इस्तेमाल करके तय किया गया कोई पॉइंट. इसमें हेडिंग भी शामिल हो सकती है.
place_id

string

वेपॉइंट से जुड़ा पीओआई प्लेस आईडी.

किसी जगह पर पहुंचने या वहां से निकलने की जगह की जानकारी देने के लिए, प्लेस आईडी का इस्तेमाल करें. यह प्लेस आईडी इतना सटीक होना चाहिए कि उस जगह पर नेविगेट करने के लिए, LatLng की जगह की जानकारी तय की जा सके. उदाहरण के लिए, किसी इमारत का जगह आईडी सही है, लेकिन सड़क का जगह आईडी सही नहीं है.