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

rpc BatchOptimizeTours(BatchOptimizeToursRequest) returns (Operation)

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

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

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

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

अगर एलआरओ का 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)

यह फ़ंक्शन, OptimizeToursRequest भेजता है. इसमें ShipmentModel शामिल होता है. साथ ही, यह 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 (एलआरओ) का नाम <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 का यूआरआई तय करता है. इसके बाद, सर्वर, क्लाइंट के तय किए गए Google Cloud Storage यूआरआई में OptimizeToursResponse लिखता है.

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

लौटाए गए long-running operation (एलआरओ) का नाम <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

सभी Transition और/या Visit (क्रमशः, सभी ShipmentRoute) एलिमेंट के लिए, 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 का जवाब. यह कार्रवाई पूरी होने के बाद, Long Running Operation में दिखता है.

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 घंटे में एक घंटा" उदाहरण के मुताबिक है:

  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, दोनों की वैल्यू तय की जानी चाहिए. साथ ही, इनकी वैल्यू शून्य या इससे ज़्यादा होनी चाहिए.

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

  (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

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

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 शेयर नहीं करना चाहिए.
  • अनुरोध में मौजूद शिपमेंट के साथ, इंजेक्ट किए गए समाधान में मौजूद विज़िट को मैच करने के लिए, ShipmentRoute.Visit.shipment_label के बजाय shipment_index का इस्तेमाल करता है;
  • यह अनुरोध किए गए शिपमेंट से, इंजेक्ट किए गए समाधान में छोड़े गए शिपमेंट को मैच करने के लिए, SkippedShipment.index के बजाय SkippedShipment.label का इस्तेमाल करता है.

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

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

  • Vehicle.label अनुरोध में शामिल हो;
  • Shipment.label अनुरोध में शामिल हो;
  • ShipmentRoute.vehicle_label को इंजेक्ट किए गए सलूशन में;
  • SkippedShipment.label और ShipmentRoute.Visit.shipment_label को इंजेक्ट किए गए समाधान में शामिल करें. हालांकि, पिकअप/डिलिवरी के लिए विज़िट के जोड़े को छोड़कर, जिनके shipment_label को दो बार शामिल करना ज़रूरी है.

अगर इंजेक्ट किए गए समाधान में मौजूद 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

अगर यह विकल्प चुना जाता है, तो जवाब ShipmentRoutes में पॉलीलाइन अपने-आप भर जाएंगी.
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 से जुड़ी लागतों की जानकारी सिर्फ़ एग्रीगेट किए गए तरीके से दी जाती है. यह जानकारी 2022/01 से दी जा रही है.
total_cost

double

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

OptimizeToursUriMetadata

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

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

OptimizeToursUriRequest

यह OptimizeToursUri तरीके से इस्तेमाल किया गया अनुरोध है.

फ़ील्ड
parent

string

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

फ़ॉर्मैट:

  • projects/{project-id}
  • projects/{project-id}/locations/{location-id}

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

Uri

ज़रूरी है. OptimizeToursRequest वाले Cloud Storage ऑब्जेक्ट का यूआरआई.
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) पेयर मिल सकता है. ऐसा इसलिए, क्योंकि नई गड़बड़ी ने पुरानी गड़बड़ी को छिपा दिया है. उदाहरण के लिए, "MULTIPLE ERRORS" देखें.
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

फ़ील्ड का नाम, जैसे कि "vehicles".
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-th एलिमेंट, मॉडल के i-th वाहन से मेल खाता है.

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

int32

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

Duration

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

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

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

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

Duration

इससे शिपमेंट को पिकअप करने से लेकर डिलीवर करने तक का ज़्यादा से ज़्यादा समय पता चलता है. अगर इसे तय किया जाता है, तो यह शून्य या इससे ज़्यादा होना चाहिए. साथ ही, शिपमेंट में कम से कम पिकअप और डिलीवरी शामिल होनी चाहिए. यह इस बात पर निर्भर नहीं करता कि पिकअप और डिलीवरी के लिए कौनसे विकल्प चुने गए हैं. साथ ही, यह वाहन की स्पीड पर भी निर्भर नहीं करता. इसे ज़्यादा से ज़्यादा डाइवर्शन की पाबंदियों के साथ तय किया जा सकता है: समाधान, दोनों स्पेसिफ़िकेशन का पालन करेगा.
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

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

उदाहरण के लिए, मान लें कि चुने गए पिकअप के विकल्प से सीधे चुने गए डिलीवरी के विकल्प तक पहुंचने में कम से कम समय 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/10 से, सिर्फ़ तब तक रास्ते में बदलाव करने की सुविधा काम करती है, जब तक यात्रा की अवधि वाहनों पर निर्भर नहीं करती.

फ़ाइलों के लोड होने के बारे में जानकारी

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

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

Timestamp

अगर यह नीति सेट नहीं की गई है, तो डिफ़ॉल्ट वैल्यू के तौर पर 1 जनवरी, 1971 को 00:00:00 यूटीसी (यानी, सेकंड: 31536000, नैनोसेकंड: 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 पर पिकअप के लिए 1 अनुरोध.
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), टैग duration_distance_matrix_src_tags(j) वाली विज़िट से लेकर मैट्रिक्स i में मौजूद अन्य विज़िट तक की अवधि और दूरी तय करता है.

टैग, 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) वाली विज़िट तक की यात्रा की अवधि (resp. दूरी) तय करता है.

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

TransitionAttributes

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

ShipmentTypeIncompatibility

शिपमेंट के ऐसे टाइप के सेट जो एक-दूसरे के साथ काम नहीं करते (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 बाद शुरू होना चाहिए.

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

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

फ़ील्ड
first_is_delivery

bool

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

bool

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

Duration

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

int32

"first" इवेंट का शिपमेंट इंडेक्स. इस फ़ील्ड की वैल्यू देना ज़रूरी है.
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 यूनीक होता है और यह ज़रूरी है कि यह अगले स्टॉप (या वाहन के खत्म होने) से ठीक पहले का समय हो. इसलिए, इसके शुरू और खत्म होने का समय जानने के लिए, देरी की अवधि जानना काफ़ी है.
  • ब्रेक, समय की ऐसी अवधि होती है जो एक के बाद एक होती है और एक-दूसरे से ओवरलैप नहीं होती. जवाब में, हर ब्रेक के शुरू होने का समय और अवधि बताई जाती है.
  • यात्रा और इंतज़ार "प्रीएम्प्टेबल" होते हैं: इस ट्रांज़िशन के दौरान, इन्हें कई बार रोका जा सकता है. क्लाइंट यह मान सकते हैं कि यात्रा "जितनी जल्दी हो सके" शुरू हो जाती है और "इंतज़ार" में बाकी समय लगता है.

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

                               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-th विज़िट है. अगर यह फ़ील्ड खाली है, तो वाहन को इस्तेमाल नहीं किया गया माना जाता है.
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) बढ़ गया है. इसलिए, हो सकता है कि अगले स्टॉप पर पहुंचने का समय, मौजूदा समयसीमा से बाद का हो. इसके अलावा, यात्रा में लगने वाले समय के अनुमान और विज़िट या ब्रेक के समय की विंडो से जुड़ी पाबंदियों की वजह से, ब्रेक को विज़िट के साथ ओवरलैप करने के लिए मजबूर किया जा सकता है.
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 से जुड़ी लागतों की जानकारी सिर्फ़ एग्रीगेट किए गए तरीके से दी जाती है. यह जानकारी 2022/01 से दी जा रही है.
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

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

Duration

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

Duration

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

  • अगली विज़िट start_time (या अगर यह आखिरी ट्रांज़िशन है, तो vehicle_end_time) - इस ट्रांज़िशन का start_time;
  • अगर ShipmentRoute.has_traffic_infeasibilities की वैल्यू false है, तो यह भी लागू होगा: `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 की कॉपी.
visit_type

VisitType

ज़रूरी नहीं. इससे विज़िट का टाइप पता चलता है. Visit.is_pickup फ़ील्ड की वैल्यू को ओवरराइड करता है.
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 पर जाएं.

VisitType

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

Enums
VISIT_TYPE_UNSPECIFIED विज़िट के टाइप की जानकारी नहीं दी गई है.
PICKUP_SHIPMENT विज़िट, शिपमेंट पिकअप से जुड़ी होती है.
DELIVER_SHIPMENT यह विज़िट, शिपमेंट की डिलीवरी से जुड़ी होती है.

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

इस मोड में, एक साथ दो ऐसे शिपमेंट को एक ही वाहन में नहीं रखा जा सकता जो एक-दूसरे के साथ काम नहीं करते:

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

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][] की वैल्यू true हो.

एक्सपेरिमेंट के तौर पर उपलब्ध: इस फ़ील्ड के काम करने के तरीके या इसकी उपलब्धता में आने वाले समय में बदलाव हो सकता है.
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 से ज़्यादा है. यह दूरी, वाहन की 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_end_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>

यह विज़िट टाइप की स्ट्रिंग से अवधि तक का मैप तय करता है. समयावधि, VisitRequest.duration के अलावा वह समय है जो तय किए गए visit_types के साथ विज़िट के दौरान लिया जाता है. अगर 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 थ्रेशोल्ड का उल्लंघन होने पर, हर घंटे के हिसाब से लगने वाला शुल्क. अगर अवधि थ्रेशोल्ड से कम है, तो अतिरिक्त शुल्क नहीं लगता. अगर अवधि थ्रेशोल्ड से ज़्यादा है, तो शुल्क इस तरह से तय होता है:

  cost_per_hour_after_soft_max * (duration - soft_max_duration)

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

double

अगर quadratic_soft_max_duration थ्रेशोल्ड का उल्लंघन होता है, तो हर वर्ग घंटे के हिसाब से लगने वाला शुल्क.

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

  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
  • ट्रांज़िशन 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • ट्रांज़िशन 2: 2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
  • ट्रांज़िशन 3: 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
  • ट्रांज़िशन 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
  • ट्रांज़िशन 2: 0.0
  • ट्रांज़िशन 3: 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) का इस्तेमाल किया जाता है.

वेपॉइंट

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

फ़ील्ड
side_of_road

bool

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

bool

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

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

Location

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

string

रास्ते के किसी पॉइंट से जुड़ा POI प्लेस आईडी.

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