Package google.maps.routeoptimization.v1

সূচক

রুট অপ্টিমাইজেশান

যানবাহন ট্যুর অপ্টিমাইজ করার জন্য একটি পরিষেবা।

নির্দিষ্ট ধরণের ক্ষেত্রের বৈধতা:

  • google.protobuf.Timestamp
    • সময়গুলি ইউনিক্স সময়ে: 1970-01-01T00:00:00+00:00 থেকে সেকেন্ড।
    • সেকেন্ড অবশ্যই [0, 253402300799], অর্থাৎ [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00]-এ হতে হবে।
    • nanos আনসেট বা 0 এ সেট করা আবশ্যক।
  • google.protobuf.Duration
    • সেকেন্ড অবশ্যই [0, 253402300799], অর্থাৎ [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00]-এ হতে হবে।
    • nanos আনসেট বা 0 এ সেট করা আবশ্যক।
  • google.type.LatLng
    • অক্ষাংশ অবশ্যই [-90.0, 90.0]-এ হতে হবে।
    • দ্রাঘিমাংশ অবশ্যই [-180.0, 180.0]-এর মধ্যে হতে হবে।
    • অক্ষাংশ এবং দ্রাঘিমাংশের অন্তত একটি অ-শূন্য হতে হবে।
ব্যাচঅপ্টিমাইজ ট্যুরস

rpc BatchOptimizeTours( BatchOptimizeToursRequest ) returns ( Operation )

একটি ব্যাচ হিসাবে এক বা একাধিক OptimizeToursRequest বার্তাগুলির জন্য গাড়ির ট্যুর অপ্টিমাইজ করে৷

এই পদ্ধতিটি একটি লং রানিং অপারেশন (LRO)। অপ্টিমাইজেশনের জন্য ইনপুট ( OptimizeToursRequest বার্তা) এবং আউটপুট ( OptimizeToursResponse বার্তা) ক্লাউড স্টোরেজ থেকে ব্যবহারকারী-নির্দিষ্ট বিন্যাসে পড়া এবং লেখা হয়। OptimizeTours পদ্ধতির মতো, প্রতিটি OptimizeToursRequest একটি ShipmentModel থাকে এবং ShipmentRoute ক্ষেত্রগুলি সম্বলিত একটি OptimizeToursResponse প্রদান করে, যা সামগ্রিক খরচ কমিয়ে যানবাহনের দ্বারা সঞ্চালিত রুটের একটি সেট।

ব্যবহারকারী ভোট operations.get করতে পারেন।

যদি LRO done ক্ষেত্রটি মিথ্যা হয়, তাহলে অন্তত একটি অনুরোধ এখনও প্রক্রিয়া করা হচ্ছে। অন্যান্য অনুরোধগুলি সফলভাবে সম্পন্ন হতে পারে এবং তাদের ফলাফল ক্লাউড স্টোরেজে উপলব্ধ।

যদি LRO এর done ক্ষেত্রটি সত্য হয়, তাহলে সমস্ত অনুরোধ প্রক্রিয়া করা হয়েছে। যেকোনো সফলভাবে প্রক্রিয়াকৃত অনুরোধের ফলাফল ক্লাউড স্টোরেজে পাওয়া যাবে। ব্যর্থ হওয়া যেকোনো অনুরোধের ফলাফল ক্লাউড স্টোরেজে পাওয়া যাবে না। যদি LRO এর error ক্ষেত্রটি সেট করা থাকে, তাহলে এতে ব্যর্থ অনুরোধগুলির একটি থেকে ত্রুটি রয়েছে৷

অনুমোদনের সুযোগ

নিম্নলিখিত OAuth সুযোগ প্রয়োজন:

  • https://www.googleapis.com/auth/cloud-platform
আইএএম অনুমতি

parent রিসোর্সে নিম্নলিখিত IAM অনুমতির প্রয়োজন:

  • routeoptimization.operations.create

আরও তথ্যের জন্য, IAM ডকুমেন্টেশন দেখুন।

অপটিমাইজ ট্যুরস

rpc OptimizeTours( OptimizeToursRequest ) returns ( OptimizeToursResponse )

একটি ShipmentModel সম্বলিত একটি OptimizeToursRequest পাঠায় এবং ShipmentRoute s সম্বলিত একটি OptimizeToursResponse ফেরত দেয়, যা সামগ্রিক খরচ কমিয়ে যানবাহনের দ্বারা সম্পাদিত রুটের একটি সেট।

একটি ShipmentModel মডেল প্রধানত Shipment নিয়ে গঠিত যা চালাতে হবে এবং Vehicle যা Shipment পরিবহনের জন্য ব্যবহার করা যেতে পারে৷ ShipmentRoute রুটগুলি Vehicle Shipment বরাদ্দ করে৷ আরও নির্দিষ্টভাবে, তারা প্রতিটি গাড়ির জন্য একটি সিরিজ Visit নির্ধারণ করে, যেখানে একটি Visit একটি VisitRequest সাথে মিলে যায়, যা একটি Shipment জন্য একটি পিকআপ বা ডেলিভারি।

লক্ষ্য হল Vehicle ShipmentRoute একটি অ্যাসাইনমেন্ট প্রদান করা যা মোট খরচ কমিয়ে দেয় যেখানে খরচের অনেকগুলি উপাদান ShipmentModel সংজ্ঞায়িত করা হয়েছে৷

অনুমোদনের সুযোগ

নিম্নলিখিত OAuth সুযোগ প্রয়োজন:

  • https://www.googleapis.com/auth/cloud-platform
আইএএম অনুমতি

parent রিসোর্সে নিম্নলিখিত IAM অনুমতির প্রয়োজন:

  • routeoptimization.locations.use

আরও তথ্যের জন্য, IAM ডকুমেন্টেশন দেখুন।

OptimizeToursLongRunning

rpc OptimizeToursLongRunning( OptimizeToursRequest ) returns ( Operation )

এটি OptimizeTours পদ্ধতির একটি বৈকল্পিক যা বড় টাইমআউট মান সহ অপ্টিমাইজেশনের জন্য ডিজাইন করা হয়েছে৷ কয়েক মিনিটের বেশি সময় নেয় এমন অপ্টিমাইজেশনের জন্য OptimizeTours পদ্ধতির চেয়ে এটিকে অগ্রাধিকার দেওয়া উচিত।

ফিরে আসা long-running operation (LRO) ফর্ম্যাটের একটি নাম থাকবে <parent>/operations/<operation_id> এবং গণনার অগ্রগতি ট্র্যাক করতে ব্যবহার করা যেতে পারে। metadata ক্ষেত্রের ধরন হল OptimizeToursLongRunningMetadata । response ক্ষেত্রের ধরন হল OptimizeToursResponse , যদি সফল হয়।

পরীক্ষামূলক: আরও বিশদ বিবরণের জন্য https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request দেখুন।

অনুমোদনের সুযোগ

নিম্নলিখিত OAuth সুযোগ প্রয়োজন:

  • https://www.googleapis.com/auth/cloud-platform
আইএএম অনুমতি

parent রিসোর্সে নিম্নলিখিত IAM অনুমতির প্রয়োজন:

  • routeoptimization.operations.create

আরও তথ্যের জন্য, IAM ডকুমেন্টেশন দেখুন।

অপটিমাইজ ট্যুরসউরি

rpc OptimizeToursUri( OptimizeToursUriRequest ) returns ( Operation )

এটি OptimizeToursLongRunning পদ্ধতির একটি রূপ যা বড় টাইমআউট মান এবং বড় ইনপুট/আউটপুট আকার সহ অপ্টিমাইজেশনের জন্য ডিজাইন করা হয়েছে।

ক্লায়েন্ট Google ক্লাউড স্টোরেজে সংরক্ষিত OptimizeToursRequest এর URI নির্দিষ্ট করে এবং সার্ভারটি ক্লায়েন্ট-নির্দিষ্ট Google ক্লাউড স্টোরেজ URI-তে OptimizeToursResponse লিখে।

এই পদ্ধতিটি অপ্টিমাইজেশনের জন্য OptimizeTours পদ্ধতির চেয়ে পছন্দ করা উচিত যা কয়েক মিনিটের বেশি সময় নেয় এবং 8MB এর থেকে বড় ইনপুট/আউটপুট আকার, যদিও এটি ছোট এবং ছোট অপ্টিমাইজেশনের জন্যও ব্যবহার করা যেতে পারে।

ফিরে আসা long-running operation (LRO) ফর্ম্যাটের একটি নাম থাকবে <parent>/operations/<operation_id> এবং গণনার অগ্রগতি ট্র্যাক করতে ব্যবহার করা যেতে পারে। metadata ক্ষেত্রের ধরন হল OptimizeToursLongRunningMetadata । response ক্ষেত্রের ধরন হল OptimizeToursUriResponse , যদি সফল হয়।

পরীক্ষামূলক: আরও বিশদ বিবরণের জন্য https://developers.google.com/maps/tt/route-optimization/experimental/otlr/make-request দেখুন।

অনুমোদনের সুযোগ

নিম্নলিখিত OAuth সুযোগ প্রয়োজন:

  • https://www.googleapis.com/auth/cloud-platform
আইএএম অনুমতি

parent রিসোর্সে নিম্নলিখিত IAM অনুমতির প্রয়োজন:

  • routeoptimization.operations.create

আরও তথ্যের জন্য, IAM ডকুমেন্টেশন দেখুন।

সমষ্টিগত মেট্রিক্স

ShipmentRoute জন্য সমষ্টিগত মেট্রিক্স (অপ্টিমাইজ OptimizeToursResponse জন্য সমস্ত Transition এবং/অথবা Visit (সমস্ত ShipmentRoute উপর রেসপন্স) উপাদান।

ক্ষেত্র
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 >

এই রুটের প্রতিটি পরিমাণের জন্য (resp. সমাধান) সমগ্র রুটে অর্জিত সর্বাধিক লোড (resp. solution), সমস্ত Transition.vehicle_loads (resp. ShipmentRoute.metrics.max_loads ) এর উপর সর্বাধিক হিসাবে গণনা করা হয়েছে।

performed_mandatory_shipment_count

int32

সঞ্চালিত বাধ্যতামূলক চালানের সংখ্যা।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

performed_shipment_penalty_cost_sum

double

সম্পাদিত চালানের Shipment.penalty_cost যোগফল. পেনাল্টি_কস্ট।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

BatchOptimizeToursMetadata

এই ধরনের কোন ক্ষেত্র আছে.

BatchOptimizeToursRequest কলের জন্য অপারেশন মেটাডেটা।

BatchOptimizeToursRequest

একটি অ্যাসিঙ্ক্রোনাস অপারেশন হিসাবে ব্যাচ অপ্টিমাইজ ট্যুর করার অনুরোধ। প্রতিটি ইনপুট ফাইলে একটি OptimizeToursRequest থাকা উচিত এবং প্রতিটি আউটপুট ফাইলে একটি OptimizeToursResponse থাকবে। অনুরোধে ফাইলগুলি পড়া/লেখা এবং পার্স করার তথ্য রয়েছে। সমস্ত ইনপুট এবং আউটপুট ফাইল একই প্রকল্পের অধীনে হওয়া উচিত।

ক্ষেত্র
parent

string

প্রয়োজন। একটি কল করতে লক্ষ্য প্রকল্প এবং অবস্থান.

বিন্যাস: * projects/{project-id} * projects/{project-id}/locations/{location-id}

কোনো অবস্থান নির্দিষ্ট না থাকলে, একটি অঞ্চল স্বয়ংক্রিয়ভাবে বেছে নেওয়া হবে।

model_configs[]

AsyncModelConfig

প্রয়োজন। প্রতিটি ক্রয় মডেলের ইনপুট/আউটপুট তথ্য, যেমন ফাইল পাথ এবং ডেটা ফরম্যাট।

AsyncModelConfig

অসিঙ্ক্রোনাসভাবে একটি অপ্টিমাইজেশন মডেল সমাধানের জন্য তথ্য।

ক্ষেত্র
display_name

string

ঐচ্ছিক। ব্যবহারকারীর সংজ্ঞায়িত মডেল নাম, মডেলের ট্র্যাক রাখতে ব্যবহারকারীদের দ্বারা উপনাম হিসাবে ব্যবহার করা যেতে পারে।

input_config

InputConfig

প্রয়োজন। ইনপুট মডেল সম্পর্কে তথ্য।

output_config

OutputConfig

প্রয়োজন। পছন্দসই আউটপুট অবস্থান তথ্য.

BatchOptimizeToursResponse

এই ধরনের কোন ক্ষেত্র আছে.

একটি BatchOptimizeToursRequest এর প্রতিক্রিয়া। অপারেশন সম্পূর্ণ হওয়ার পর এটি লং রানিং অপারেশনে ফিরিয়ে দেওয়া হয়।

BreakRule

একটি যানবাহনের জন্য সময় বিরতি তৈরি করার নিয়ম (যেমন লাঞ্চ বিরতি)। একটি বিরতি হল একটি সংলগ্ন সময়কাল যেখানে যানবাহনটি তার বর্তমান অবস্থানে নিষ্ক্রিয় থাকে এবং কোনও পরিদর্শন করতে পারে না। একটি বিরতি ঘটতে পারে:

  • দুটি ভিজিটের মধ্যে ভ্রমণের সময় (যার মধ্যে একটি ভিজিটের আগে বা ঠিক পরে সময় থাকে, তবে ভিজিটের মাঝখানে নয়), এই ক্ষেত্রে এটি ভিজিটের মধ্যে সংশ্লিষ্ট ট্রানজিট সময়কে প্রসারিত করে,
  • বা যানবাহন শুরু হওয়ার আগে (একটি বিরতির মাঝখানে যানবাহন শুরু নাও হতে পারে), এই ক্ষেত্রে এটি গাড়ির শুরুর সময়কে প্রভাবিত করে না।
  • বা যানবাহন শেষ হওয়ার পরে (এভাবে, গাড়ির শেষ সময় সহ)।
ক্ষেত্র
break_requests[]

BreakRequest

বিরতির ক্রম। BreakRequest বার্তাটি দেখুন।

frequency_constraints[]

FrequencyConstraint

বেশ কিছু FrequencyConstraint প্রযোজ্য হতে পারে। এই BreakRule এর BreakRequest s দ্বারা তাদের সকলকে অবশ্যই সন্তুষ্ট হতে হবে। FrequencyConstraint দেখুন।

ব্রেক রিকোয়েস্ট

বিরতির ক্রম (অর্থাৎ তাদের সংখ্যা এবং ক্রম) যা প্রতিটি গাড়ির জন্য প্রযোজ্য তা অবশ্যই আগে থেকেই জানা উচিত। পুনরাবৃত্ত BreakRequest গুলি সেই ক্রমটিকে সংজ্ঞায়িত করে, যে ক্রমে সেগুলি ঘটতে হবে৷ তাদের সময় উইন্ডো ( earliest_start_time / latest_start_time ) ওভারল্যাপ হতে পারে, কিন্তু সেগুলি অবশ্যই অর্ডারের সাথে সামঞ্জস্যপূর্ণ হতে হবে (এটি চেক করা হয়েছে)।

ক্ষেত্র
earliest_start_time

Timestamp

প্রয়োজন। বিরতির শুরুতে লোয়ার বাউন্ড (অন্তর্ভুক্ত)।

latest_start_time

Timestamp

প্রয়োজন। বিরতির শুরুতে আপার বাউন্ড (ইনক্লুসিভ)।

min_duration

Duration

প্রয়োজন। বিরতির ন্যূনতম সময়কাল। ইতিবাচক হতে হবে।

ফ্রিকোয়েন্সি সীমাবদ্ধতা

একটি ন্যূনতম বিরতির ফ্রিকোয়েন্সি প্রয়োগ করে উপরে উল্লেখিত বিরতির ফ্রিকোয়েন্সি এবং সময়কালকে আরও সীমাবদ্ধ করতে পারে, যেমন "প্রতি 12 ঘন্টায় কমপক্ষে 1 ঘন্টা বিরতি থাকতে হবে"। ধরে নিলাম যে এটিকে "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 । ইতিবাচক হতে হবে।

ডেটা ফরম্যাট

ইনপুট এবং আউটপুট ফাইলের জন্য ডেটা বিন্যাস।

এনামস
DATA_FORMAT_UNSPECIFIED অবৈধ মান, বিন্যাস অবশ্যই অনির্দিষ্ট হওয়া উচিত নয়৷
JSON জাভাস্ক্রিপ্ট অবজেক্ট নোটেশন।
PROTO_TEXT প্রোটোকল বাফার টেক্সট ফরম্যাট। https://protobuf.dev/reference/protobuf/textformat-spec/ দেখুন

দূরত্বসীমা

ভ্রমণ করা যেতে পারে এমন একটি সর্বোচ্চ দূরত্ব সংজ্ঞায়িত করে। এটা শক্ত বা নরম হতে পারে।

যদি একটি নরম সীমা সংজ্ঞায়িত করা হয়, তাহলে soft_max_meters এবং cost_per_kilometer_above_soft_max উভয়কেই সংজ্ঞায়িত করতে হবে এবং অঋণাত্মক হতে হবে।

ক্ষেত্র
max_meters

int64

একটি কঠিন সীমা যা দূরত্বকে সর্বাধিক max_meters হতে বাধা দেয়৷ সীমাটি অবশ্যই নেতিবাচক হতে হবে।

soft_max_meters

int64

একটি নরম সীমা সর্বোচ্চ দূরত্বের সীমা বলবৎ করে না, কিন্তু লঙ্ঘন করলে একটি খরচ হয় যা একই ইউনিটের সাথে মডেলে সংজ্ঞায়িত অন্যান্য খরচের সাথে যোগ করে।

যদি সংজ্ঞায়িত করা হয় soft_max_meters অবশ্যই max_meters এর থেকে কম হতে হবে এবং অবশ্যই nonnegative হতে হবে।

cost_per_kilometer_below_soft_max

double

প্রতি কিলোমিটার খরচ, সূত্র সহ soft_max_meters পর্যন্ত বৃদ্ধি পাচ্ছে:

  min(distance_meters, soft_max_meters) / 1000.0 *
  cost_per_kilometer_below_soft_max.

এই খরচ route_distance_limit সমর্থিত নয়।

cost_per_kilometer_above_soft_max

double

দূরত্ব soft_max_meters সীমার উপরে হলে প্রতি কিলোমিটার খরচ। দূরত্ব সীমার নিচে থাকলে অতিরিক্ত খরচ 0 হয়, অন্যথায় খরচ গণনা করার জন্য ব্যবহৃত সূত্রটি নিম্নরূপ:

  (distance_meters - soft_max_meters) / 1000.0 *
  cost_per_kilometer_above_soft_max.

খরচ nonnegative হতে হবে.

Gcs গন্তব্য

Google ক্লাউড স্টোরেজের অবস্থান যেখানে আউটপুট ফাইল(গুলি) লেখা হবে৷

ক্ষেত্র
uri

string

প্রয়োজন। Google ক্লাউড স্টোরেজ ইউআরআই।

GcsSource

Google ক্লাউড স্টোরেজ অবস্থান যেখান থেকে ইনপুট ফাইল পড়া হবে।

ক্ষেত্র
uri

string

প্রয়োজন। gs://bucket/path/to/object ফর্ম্যাট সহ একটি Google ক্লাউড স্টোরেজ অবজেক্টের URI।

Injected Solution Constraint

কোন ভিজিটগুলিকে সীমাবদ্ধ করা উচিত এবং কীভাবে সেগুলিকে সীমাবদ্ধ করা উচিত সে সম্পর্কে তথ্য সহ অনুরোধে সমাধান ইনজেকশন করা হয়েছে৷

ক্ষেত্র
routes[]

ShipmentRoute

ইনজেকশন সমাধানের রুট। মূল সমাধান থেকে কিছু রুট বাদ দেওয়া যেতে পারে। রুট এবং এড়িয়ে যাওয়া শিপমেন্টগুলিকে অবশ্যই injected_first_solution_routes জন্য তালিকাভুক্ত মৌলিক বৈধতা অনুমানগুলি পূরণ করতে হবে৷

skipped_shipments[]

SkippedShipment

ইনজেকশনের সমাধানের চালান এড়িয়ে গেছে। মূল সমাধান থেকে কিছু বাদ দেওয়া যেতে পারে। routes ক্ষেত্র দেখুন.

constraint_relaxations[]

ConstraintRelaxation

যানবাহনের শূন্য বা তার বেশি গ্রুপের জন্য, কখন এবং কতটা সীমাবদ্ধতা শিথিল করতে হবে তা নির্দিষ্ট করে। যদি এই ক্ষেত্রটি খালি থাকে, সমস্ত অ-খালি যানবাহন রুট সম্পূর্ণরূপে সীমাবদ্ধ।

সীমাবদ্ধতা শিথিলকরণ

যানবাহনের একটি গ্রুপের জন্য, পরিদর্শনে কোন প্রান্তিক (গুলি) সীমাবদ্ধতা শিথিল করা হবে এবং কোন স্তরে তা নির্দিষ্ট করে৷ skipped_shipment ক্ষেত্রে তালিকাভুক্ত শিপমেন্টগুলি এড়ানোর জন্য সীমাবদ্ধ; অর্থাৎ, তারা সঞ্চালিত করা যাবে না.

ক্ষেত্র
relaxations[]

Relaxation

সমস্ত ভিজিট সীমাবদ্ধতা শিথিলতা যা vehicle_indices যানবাহন সহ রুটে পরিদর্শনের ক্ষেত্রে প্রযোজ্য হবে।

vehicle_indices[]

int32

যানবাহনের সূচকগুলি নির্দিষ্ট করে যেখানে পরিদর্শন সীমাবদ্ধতা relaxations প্রযোজ্য। খালি থাকলে, এটি ডিফল্ট হিসাবে বিবেচিত হয় এবং relaxations সমস্ত যানবাহনের ক্ষেত্রে প্রযোজ্য হয় যেগুলি অন্যান্য constraint_relaxations নির্দিষ্ট করা হয়নি। সেখানে সর্বাধিক একটি ডিফল্ট থাকতে পারে, অর্থাৎ, সর্বাধিক একটি সীমাবদ্ধতা শিথিলকরণ ক্ষেত্রে খালি vehicle_indices অনুমোদিত। একটি যানবাহন সূচক শুধুমাত্র একবার তালিকাভুক্ত করা যেতে পারে, এমনকি বেশ কয়েকটি constraint_relaxations মধ্যেও।

একটি গাড়ির সূচী ShipmentRoute.vehicle_index এর মতই ম্যাপ করা হয়, যদি interpret_injected_solutions_using_labels সত্য হয় ( fields মন্তব্য দেখুন)।

শিথিলতা

relaxations খালি থাকলে, routes সমস্ত দর্শনের শুরুর সময় এবং ক্রম সম্পূর্ণরূপে সীমাবদ্ধ থাকে এবং সেই রুটে কোনও নতুন ভিজিট সন্নিবেশ করা বা যোগ করা যাবে না। এছাড়াও, routes একটি গাড়ির শুরু এবং শেষের সময় সম্পূর্ণরূপে সীমাবদ্ধ, যতক্ষণ না গাড়িটি খালি থাকে (অর্থাৎ, কোনও ভিজিট নেই এবং মডেলটিতে মিথ্যা সেট করা_ used_if_route_is_empty হয়েছে)।

relaxations(i).level একটি পরিদর্শন #j-এ প্রয়োগ করা সীমাবদ্ধতা শিথিলকরণ স্তর নির্দিষ্ট করে যা সন্তুষ্ট করে:

  • route.visits(j).start_time >= relaxations(i).threshold_time AND
  • j + 1 >= relaxations(i).threshold_visit_count

একইভাবে, গাড়ির স্টার্ট relaxations(i).level শিথিল করা হয় যদি এটি সন্তুষ্ট করে:

  • vehicle_start_time >= relaxations(i).threshold_time AND
  • 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 মোটেও প্রয়োগ করা হয় না।

স্তর

বিভিন্ন সীমাবদ্ধতা শিথিলকরণ স্তরগুলি প্রকাশ করে, যা একটি পরিদর্শনের জন্য প্রয়োগ করা হয় এবং যেগুলি থ্রেশহোল্ড শর্তগুলিকে সন্তুষ্ট করার সময় অনুসরণ করে৷

নীচের গণনা ক্রমবর্ধমান শিথিলকরণের জন্য।

এনামস
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 এর মতোই, তবে গাড়িটিও শিথিল: থ্রেশহোল্ডের সময় বা তার পরে পরিদর্শন সম্পূর্ণ বিনামূল্যে এবং সম্ভাব্যভাবে অকার্যকর হয়ে যেতে পারে।

ইনপুট কনফিগারেশন

[BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours]-এর জন্য একটি ইনপুট নির্দিষ্ট করুন।

ক্ষেত্র
data_format

DataFormat

প্রয়োজন। ইনপুট তথ্য বিন্যাস.

ইউনিয়ন ক্ষেত্র source । প্রয়োজন। source নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
gcs_source

GcsSource

একটি Google ক্লাউড স্টোরেজ অবস্থান। এটি একটি একক বস্তু (ফাইল) হতে হবে।

অবস্থান

একটি অবস্থান (একটি ভৌগলিক বিন্দু, এবং একটি ঐচ্ছিক শিরোনাম) এনক্যাপসুলেট করে।

ক্ষেত্র
lat_lng

LatLng

ওয়েপয়েন্টের ভৌগলিক স্থানাঙ্ক।

heading

int32

কম্পাস শিরোনাম ট্র্যাফিক প্রবাহের দিকের সাথে যুক্ত। পিকআপ এবং ড্রপ-অফের জন্য ব্যবহার করার জন্য রাস্তার পাশে নির্দিষ্ট করতে এই মানটি ব্যবহার করা হয়। শিরোনামের মান 0 থেকে 360 পর্যন্ত হতে পারে, যেখানে 0 সঠিক উত্তরের একটি শিরোনাম নির্দিষ্ট করে, 90 পূর্বের পূর্বের শিরোনাম উল্লেখ করে ইত্যাদি।

OptimizeToursLongRunningMetadata

এই ধরনের কোন ক্ষেত্র আছে.

OptimizeToursLongRunning কলের জন্য অপারেশন মেটাডেটা।

অপটিমাইজ ট্যুর রিকোয়েস্ট

একটি ট্যুর অপ্টিমাইজেশান সমাধানকারীকে দেওয়ার অনুরোধ যা সমাধানের জন্য শিপমেন্ট মডেলের পাশাপাশি অপ্টিমাইজেশন প্যারামিটারগুলিকে সংজ্ঞায়িত করে৷

ক্ষেত্র
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/11 অনুসারে, এটি শুধুমাত্র খালি নয় এমন রুটের পলিলাইনগুলিকে পপুলেট করে এবং প্রয়োজন যে 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 s একই মূল vehicle_index শেয়ার করা উচিত নয়)।
  • অনুরোধে শিপমেন্টের সাথে একটি ইনজেকশন করা সমাধানে ভিজিট মেলাতে shipment_index এর পরিবর্তে ShipmentRoute.Visit.shipment_label ব্যবহার করে;
  • অনুরোধ শিপমেন্টের সাথে ইনজেকশন করা দ্রবণে এড়িয়ে যাওয়া শিপমেন্টের সাথে মেলাতে SkippedShipment.label এর পরিবর্তে SkippedShipment.index ব্যবহার করে।

এই ব্যাখ্যাটি injected_first_solution_routes , injected_solution_constraint , এবং refresh_details_routes ক্ষেত্রে প্রযোজ্য। এটি ব্যবহার করা যেতে পারে যখন অনুরোধে চালান বা যানবাহনের সূচকগুলি সমাধানটি তৈরি হওয়ার পর থেকে পরিবর্তিত হয়, সম্ভবত শিপমেন্ট বা যানবাহন অনুরোধ থেকে সরানো হয়েছে বা যোগ করা হয়েছে।

সত্য হলে, নিম্নলিখিত বিভাগের লেবেলগুলি অবশ্যই তাদের বিভাগে একবারে উপস্থিত হতে হবে:

যদি ইনজেকশনের দ্রবণে একটি vehicle_label একটি অনুরোধ গাড়ির সাথে মিল না থাকে, তাহলে সংশ্লিষ্ট রুটটি তার পরিদর্শন সহ সমাধান থেকে সরানো হয়। যদি ইনজেকশনের দ্রবণে একটি shipment_label একটি অনুরোধ চালানের সাথে সঙ্গতিপূর্ণ না হয়, তাহলে সংশ্লিষ্ট ভিজিটটি সমাধান থেকে সরানো হয়। যদি ইনজেকশন করা দ্রবণে একটি SkippedShipment.label অনুরোধ চালানের সাথে সামঞ্জস্যপূর্ণ না হয়, SkippedShipment সমাধান থেকে সরানো হয়।

একটি ইনজেকশনযুক্ত দ্রবণ থেকে রুট ভিজিট বা সম্পূর্ণ রুটগুলি সরানো অন্তর্নিহিত সীমাবদ্ধতার উপর প্রভাব ফেলতে পারে, যা সমাধানে পরিবর্তন, বৈধতা ত্রুটি বা অসম্ভাব্যতা হতে পারে।

দ্রষ্টব্য: কলকারীকে অবশ্যই নিশ্চিত করতে হবে যে প্রতিটি Vehicle.label (resp. Shipment.label ) দুটি প্রাসঙ্গিক অনুরোধ জুড়ে ব্যবহৃত একটি যানবাহন (resp. শিপমেন্ট) সত্তাকে স্বতন্ত্রভাবে সনাক্ত করে: অতীতের অনুরোধ যা ইনজেকশনের সমাধানে ব্যবহৃত OptimizeToursResponse তৈরি করেছিল এবং বর্তমান অনুরোধ যাতে ইনজেকশনের সমাধান অন্তর্ভুক্ত থাকে। উপরে বর্ণিত স্বতন্ত্রতা পরীক্ষাগুলি এই প্রয়োজনীয়তার গ্যারান্টি দেওয়ার জন্য যথেষ্ট নয়।

consider_road_traffic

bool

Transition.travel_duration , Visit.start_time , ShipmentRoute vehicle_end_time ; ShipmentRoute.has_traffic_infeasibilities ক্ষেত্র সেট করতে এবং OptimizeToursResponse.total_cost ফিল্ড গণনা করতে।

populate_polylines

bool

সত্য হলে, ShipmentRoute s এর প্রতিক্রিয়ায় পলিলাইনগুলি পপুলেট করা হবে।

populate_transition_polylines

bool

সত্য হলে, ShipmentRoute.transitions এ পলিলাইন এবং রুট টোকেনগুলি পূরণ করা হবে।

allow_large_deadline_despite_interruption_risk

bool

যদি এটি সেট করা থাকে, তাহলে অনুরোধের একটি সময়সীমা থাকতে পারে ( https://grpc.io/blog/deadlines দেখুন) 60 মিনিট পর্যন্ত। অন্যথায়, সর্বোচ্চ সময়সীমা মাত্র 30 মিনিট। মনে রাখবেন যে দীর্ঘস্থায়ী অনুরোধগুলির একটি উল্লেখযোগ্যভাবে বড় (কিন্তু এখনও ছোট) বাধার ঝুঁকি রয়েছে।

use_geodesic_distances

bool

যদি সত্য হয়, ভ্রমণের দূরত্বগুলি Google মানচিত্রের দূরত্বের পরিবর্তে জিওডেসিক দূরত্ব ব্যবহার করে গণনা করা হবে, এবং ভ্রমণের সময়গুলি জিওডেসিক দূরত্ব ব্যবহার করে গণনা করা হবে 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 field_validation দেখুন৷ এটি ডিফল্ট 100 এবং 10,000 এ সীমাবদ্ধ।

অনুসন্ধান মোড

মোড অনুসন্ধানের আচরণকে সংজ্ঞায়িত করে, ট্রেডিং অফ লেটেন্সি বনাম সমাধানের গুণমান। সমস্ত মোডে, বিশ্বব্যাপী অনুরোধের সময়সীমা কার্যকর করা হয়।

এনামস
SEARCH_MODE_UNSPECIFIED অনির্দিষ্ট অনুসন্ধান মোড, RETURN_FAST এর সমতুল্য।
RETURN_FAST প্রথম ভাল সমাধান খুঁজে পাওয়ার পরে অনুসন্ধান বন্ধ করুন।
CONSUME_ALL_AVAILABLE_TIME আরও ভাল সমাধান অনুসন্ধান করার জন্য সমস্ত উপলব্ধ সময় ব্যয় করুন।

সমাধান মোড

সমাধানকারীর অনুরোধটি কীভাবে পরিচালনা করা উচিত তা সংজ্ঞায়িত করে। সমস্ত মোডে VALIDATE_ONLY , যদি অনুরোধটি অবৈধ হয়, আপনি একটি INVALID_REQUEST ত্রুটি পাবেন৷ ফিরে আসা ত্রুটির সংখ্যা ক্যাপ করতে max_validation_errors দেখুন।

এনামস
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-th রুট মডেলের i-th যানের সাথে মিলে যায়।

request_label

string

OptimizeToursRequest.label এর অনুলিপি, যদি অনুরোধে একটি লেবেল নির্দিষ্ট করা থাকে।

skipped_shipments[]

SkippedShipment

সমস্ত চালানের তালিকা এড়িয়ে গেছে।

validation_errors[]

OptimizeToursValidationError

সমস্ত বৈধতা ত্রুটির তালিকা যা আমরা স্বাধীনভাবে সনাক্ত করতে সক্ষম হয়েছি। OptimizeToursValidationError বার্তাটির জন্য "একাধিক ত্রুটি" ব্যাখ্যাটি দেখুন৷ ত্রুটির পরিবর্তে, এটি DEFAULT_SOLVE হল solving_mode ক্ষেত্রে সতর্কতা অন্তর্ভুক্ত করবে।

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", এবং মানগুলি হল সংশ্লিষ্ট খরচ ক্ষেত্রের দ্বারা উত্পন্ন মোট খরচ, সমগ্র সমাধানের উপর একত্রিত৷ অন্য কথায়, খরচ ["model.shipments.pickups.cost"] হল সমাধানের সমস্ত পিকআপ খরচের সমষ্টি। মডেলে সংজ্ঞায়িত সমস্ত খরচ এখানে বিস্তারিতভাবে রিপোর্ট করা হয়েছে ট্রানজিশন অ্যাট্রিবিউটের সাথে সম্পর্কিত খরচগুলি বাদ দিয়ে যেগুলি শুধুমাত্র 2022/01 হিসাবে সমষ্টিগতভাবে রিপোর্ট করা হয়েছে।

total_cost

double

সমাধানের মোট খরচ। খরচ ম্যাপে সমস্ত মানের সমষ্টি।

OptimizeToursUriMetadata

এই ধরনের কোন ক্ষেত্র আছে.

OptimizeToursUri কলের জন্য অপারেশন মেটাডেটা।

OptimizeToursUriRequest

OptimizeToursUri পদ্ধতি দ্বারা ব্যবহৃত একটি অনুরোধ।

ক্ষেত্র
parent

string

প্রয়োজন। একটি কল করতে লক্ষ্য প্রকল্প বা অবস্থান.

বিন্যাস: * projects/{project-id} * projects/{project-id}/locations/{location-id}

কোনো অবস্থান নির্দিষ্ট না থাকলে, একটি অঞ্চল স্বয়ংক্রিয়ভাবে বেছে নেওয়া হবে।

input

Uri

প্রয়োজন। OptimizeToursRequest ধারণকারী ক্লাউড স্টোরেজ অবজেক্টের URI।

output

Uri

প্রয়োজন। ক্লাউড স্টোরেজ অবজেক্টের URI যাতে OptimizeToursResponse থাকবে।

OptimizeToursUriResponse

OptimizeToursUri পদ্ধতি দ্বারা প্রত্যাবর্তিত একটি প্রতিক্রিয়া।

ক্ষেত্র
output

Uri

ঐচ্ছিক। OptimizeToursResponse ধারণকারী ক্লাউড স্টোরেজ অবজেক্টের URI JSON বা textproto হিসেবে এনকোড করা হয়েছে। যদি অবজেক্টটি JSON হিসাবে এনকোড করা হয়, তাহলে অবজেক্টের নামের এক্সটেনশনটি হবে .json । যদি অবজেক্টটিকে টেক্সটপ্রোটো হিসাবে এনকোড করা হয়, তাহলে অবজেক্টের নামের এক্সটেনশনটি হবে .txtpb ।

সম্পদের crc32_checksum রিসোর্সের বিষয়বস্তু পরিবর্তন করা হয়নি তা যাচাই করতে ব্যবহার করা যেতে পারে।

OptimizeToursValidationError

একটি OptimizeToursRequest যাচাই করার সময় একটি ত্রুটি বা সতর্কতা দেখা দেয়।

ক্ষেত্র
code

int32

একটি বৈধতা ত্রুটি জোড়া ( code , display_name ) দ্বারা সংজ্ঞায়িত করা হয় যা সর্বদা উপস্থিত থাকে।

এই বিভাগটি অনুসরণ করা ক্ষেত্রগুলি ত্রুটি সম্পর্কে আরও প্রসঙ্গ সরবরাহ করে।

একাধিক ত্রুটি : যখন একাধিক ত্রুটি থাকে, তখন যাচাইকরণ প্রক্রিয়া তাদের মধ্যে কয়েকটি আউটপুট করার চেষ্টা করে। অনেকটা কম্পাইলারের মতো, এটি একটি অপূর্ণ প্রক্রিয়া। কিছু বৈধতা ত্রুটি "মারাত্মক" হবে, যার অর্থ তারা পুরো বৈধতা প্রক্রিয়া বন্ধ করে দেয়। অন্যদের মধ্যে display_name="UNSPECIFIED" ত্রুটির ক্ষেত্রে এটি হয়৷ কিছু ত্রুটির কারণে বৈধকরণ প্রক্রিয়া অন্যান্য ত্রুটিগুলি এড়িয়ে যেতে পারে৷

স্থিতিশীলতা : code এবং display_name খুব স্থিতিশীল হওয়া উচিত। কিন্তু সময়ের সাথে সাথে নতুন কোড এবং ডিসপ্লে নাম প্রদর্শিত হতে পারে, যা একটি ভিন্ন ( code , display_name ) জোড়া দেওয়ার জন্য একটি প্রদত্ত (অবৈধ) অনুরোধের কারণ হতে পারে কারণ নতুন ত্রুটিটি পুরানোটিকে লুকিয়ে রেখেছে৷ উদাহরণস্বরূপ, "একাধিক ত্রুটি" দেখুন।

display_name

string

ত্রুটি প্রদর্শন নাম.

fields[]

FieldReference

একটি ত্রুটি প্রসঙ্গে 0, 1 (বেশিরভাগ সময়) বা আরও ক্ষেত্র জড়িত হতে পারে। উদাহরণস্বরূপ, যানবাহন # 4 এবং চালান # 2 এর প্রথম পিকআপকে উল্লেখ করা নিম্নরূপ করা যেতে পারে:

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

উল্লেখ্য, যাইহোক, প্রদত্ত ত্রুটি কোডের জন্য fields মূলত্ব পরিবর্তন করা উচিত নয়।

error_message

string

মানব-পাঠযোগ্য স্ট্রিং ত্রুটি বর্ণনা করে। code এবং error_message এর মধ্যে একটি 1:1 ম্যাপিং আছে (when code!= "UNSPECIFIED")।

স্থিতিশীলতা : স্থিতিশীল নয়: একটি প্রদত্ত code সাথে সম্পর্কিত ত্রুটি বার্তাটি সময়ের সাথে পরিবর্তিত হতে পারে (আশা করি এটি স্পষ্ট করতে হবে)। পরিবর্তে display_name এবং code উপর নির্ভর করুন.

offending_values

string

ক্ষেত্র(গুলি) এর মান(গুলি) থাকতে পারে৷ এটি সবসময় পাওয়া যায় না। আপনার এটির উপর একেবারেই নির্ভর করা উচিত নয় এবং এটি শুধুমাত্র ম্যানুয়াল মডেল ডিবাগিংয়ের জন্য ব্যবহার করা উচিত।

ফিল্ড রেফারেন্স

বৈধতা ত্রুটির জন্য একটি প্রসঙ্গ নির্দিষ্ট করে। একটি FieldReference সর্বদা এই ফাইলের একটি প্রদত্ত ক্ষেত্রকে নির্দেশ করে এবং একই শ্রেণিবদ্ধ কাঠামো অনুসরণ করে। উদাহরণস্বরূপ, আমরা ব্যবহার করে যানবাহন #5 এর start_time_windows এর উপাদান #2 নির্দিষ্ট করতে পারি:

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

তবে আমরা বার্তার ভিড় এড়াতে OptimizeToursRequest বা ShipmentModel মতো শীর্ষ-স্তরের সত্তা বাদ দিই।

ক্ষেত্র
name

string

ক্ষেত্রের নাম, যেমন, "যান"।

sub_field

FieldReference

প্রয়োজনে বারবার নেস্টেড সাব-ফিল্ড।

ইউনিয়ন ক্ষেত্র index_or_key .

index_or_key নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:

index

int32

বারবার হলে ক্ষেত্রের সূচক।

key

string

ক্ষেত্রটি একটি মানচিত্র হলে কী।

আউটপুট কনফিগারেশন

[BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] ফলাফলের জন্য একটি গন্তব্য নির্দিষ্ট করুন।

ক্ষেত্র
data_format

DataFormat

প্রয়োজন। আউটপুট ডেটা বিন্যাস।

ইউনিয়ন ক্ষেত্রের destination । প্রয়োজন। destination নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
gcs_destination

GcsDestination

আউটপুট লিখতে Google ক্লাউড স্টোরেজ অবস্থান।

রুট মডিফায়ার

যানবাহনের রুট গণনা করার সময় সন্তুষ্ট করার জন্য ঐচ্ছিক অবস্থার একটি সেট এনক্যাপসুলেট করে। এটি 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 >

চালানের লোড চাহিদা (উদাহরণস্বরূপ ওজন, আয়তন, প্যালেটের সংখ্যা ইত্যাদি)। মানচিত্রের কীগুলি অনুরূপ লোডের ধরন বর্ণনাকারী শনাক্তকারী হওয়া উচিত, আদর্শভাবে ইউনিটগুলিও সহ। উদাহরণস্বরূপ: "ওজন_কেজি", "ভলিউম_গ্যালন", "প্যালেট_কাউন্ট", ইত্যাদি। যদি একটি প্রদত্ত কী মানচিত্রে উপস্থিত না হয়, তাহলে সংশ্লিষ্ট লোডটিকে শূন্য হিসাবে বিবেচনা করা হয়।

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-এর সাথে মিলে যায়।

এই খরচ অবশ্যই penalty_cost মতো একই ইউনিটে হতে হবে এবং নেতিবাচক হতে হবে না। এই ক্ষেত্রটি খালি রাখুন, যদি এমন কোন খরচ না থাকে।

costs_per_vehicle_indices[]

int32

যানবাহনের সূচকগুলি যেগুলির costs_per_vehicle প্রযোজ্য। যদি খালি না থাকে, তাহলে এটিতে অবশ্যই costs_per_vehicle এর সমান সংখ্যক উপাদান থাকতে হবে। একটি গাড়ির সূচক একাধিকবার নির্দিষ্ট করা যাবে না। একটি যানবাহনকে costs_per_vehicle_indices থেকে বাদ দেওয়া হলে, তার খরচ শূন্য।

pickup_to_delivery_absolute_detour_limit

Duration

পিকআপ থেকে ডেলিভারি পর্যন্ত সংক্ষিপ্ততম পথের তুলনায় সর্বাধিক নিখুঁত চক্কর সময় নির্দিষ্ট করে। যদি নির্দিষ্ট করা থাকে, এটি অবশ্যই নেতিবাচক হতে হবে এবং চালানে কমপক্ষে একটি পিকআপ এবং একটি ডেলিভারি থাকতে হবে।

উদাহরণস্বরূপ, নির্বাচিত পিকআপ বিকল্প থেকে সরাসরি নির্বাচিত ডেলিভারি বিকল্পে যেতে সবচেয়ে কম সময় নেওয়া যাক। তারপরে 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

পিকআপ থেকে ডেলিভারি পর্যন্ত সংক্ষিপ্ত পথের তুলনায় সর্বাধিক আপেক্ষিক চক্কর সময় নির্দিষ্ট করে। যদি নির্দিষ্ট করা থাকে, এটি অবশ্যই নেতিবাচক হতে হবে এবং চালানে কমপক্ষে একটি পিকআপ এবং একটি ডেলিভারি থাকতে হবে।

উদাহরণস্বরূপ, নির্বাচিত পিকআপ বিকল্প থেকে সরাসরি নির্বাচিত ডেলিভারি বিকল্পে যেতে সবচেয়ে কম সময় নেওয়া যাক। তারপরে 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 হতে হবে।

ভিজিট রিকোয়েস্ট

একটি ভিজিটের জন্য অনুরোধ যা একটি যানবাহন দ্বারা করা যেতে পারে: এটির একটি ভূ-অবস্থান (বা দুটি, নীচে দেখুন), খোলার এবং বন্ধের সময়গুলি টাইম উইন্ডো দ্বারা উপস্থাপিত, এবং একটি পরিষেবার সময়কাল (যান একবার পণ্য পিকআপ বা নামানোর জন্য গাড়ির দ্বারা ব্যয় করা সময়)।

ক্ষেত্র
arrival_location

LatLng

এই VisitRequest সম্পাদন করার সময় গাড়িটি যেখানে আসে সেই ভৌগলিক অবস্থান। শিপমেন্ট মডেলের সময়কাল দূরত্ব ম্যাট্রিক্স থাকলে, arrival_location অবশ্যই নির্দিষ্ট করা যাবে না।

arrival_waypoint

Waypoint

এই VisitRequest সম্পাদন করার সময় গাড়িটি যে ওয়েপয়েন্টে আসে। শিপমেন্ট মডেলের সময়কাল দূরত্ব ম্যাট্রিক্স থাকলে, arrival_waypoint অবশ্যই নির্দিষ্ট করা যাবে না।

departure_location

LatLng

ভৌগলিক অবস্থান যেখানে এই VisitRequest সম্পূর্ণ করার পরে গাড়িটি চলে যায়। বাদ দেওয়া যেতে পারে যদি এটি arrival_location এর মত হয়। শিপমেন্ট মডেলের সময়কাল দূরত্ব ম্যাট্রিক্স থাকলে, departure_location অবশ্যই নির্দিষ্ট করা যাবে না।

departure_waypoint

Waypoint

এই VisitRequest সম্পূর্ণ করার পর গাড়িটি যে ওয়েপয়েন্টে চলে যায়। বাদ দেওয়া যেতে পারে যদি এটি arrival_waypoint এর মতো হয়। শিপমেন্ট মডেলের সময়কাল দূরত্ব ম্যাট্রিক্স থাকলে, departure_waypoint অবশ্যই নির্দিষ্ট করা যাবে না।

tags[]

string

পরিদর্শন অনুরোধের সাথে সংযুক্ত ট্যাগগুলি নির্দিষ্ট করে৷ খালি বা ডুপ্লিকেট স্ট্রিং অনুমোদিত নয়।

time_windows[]

TimeWindow

টাইম উইন্ডো যা ভিজিটে আসার সময়কে সীমাবদ্ধ করে। মনে রাখবেন যে একটি যানবাহন আগমনের সময় উইন্ডোর বাইরে চলে যেতে পারে, অর্থাৎ আগমনের সময় + সময়কাল একটি টাইম উইন্ডোর ভিতরে থাকার প্রয়োজন নেই। গাড়ি TimeWindow.start_time এর আগে পৌঁছালে এর ফলে অপেক্ষার সময় হতে পারে।

TimeWindow এর অনুপস্থিতির মানে হল যে গাড়িটি যে কোনো সময় এই ভিজিট করতে পারে।

টাইম উইন্ডো অবশ্যই ডিসজয়েন্ট হতে হবে, অর্থাৎ কোন টাইম উইন্ডোকে অন্যের সাথে ওভারল্যাপ বা সংলগ্ন হতে হবে না এবং সেগুলি অবশ্যই ক্রমবর্ধমান ক্রমে হতে হবে।

cost_per_hour_after_soft_end_time এবং soft_end_time শুধুমাত্র একটি একক সময় উইন্ডো থাকলেই সেট করা যায়।

duration

Duration

পরিদর্শনের সময়কাল, অর্থাৎ আগমন এবং প্রস্থানের মধ্যে গাড়ির দ্বারা ব্যয় করা সময় (সম্ভাব্য অপেক্ষার সময় যোগ করতে হবে; time_windows দেখুন)।

cost

double

একটি যানবাহন রুটে এই পরিদর্শন অনুরোধ পরিষেবার খরচ. এটি প্রতিটি বিকল্প পিকআপ বা চালানের ডেলিভারির জন্য বিভিন্ন খরচ দিতে ব্যবহার করা যেতে পারে। এই খরচ Shipment.penalty_cost হিসাবে একই ইউনিটে হতে হবে এবং ঋণাত্মক হতে হবে না।

load_demands

map<string, Load >

এই ভিজিট অনুরোধ লোড চাহিদা. এটি Shipment.load_demands ফিল্ডের মতই, এটি সম্পূর্ণ Shipment পরিবর্তে শুধুমাত্র এই VisitRequest এ প্রযোজ্য। এখানে তালিকাভুক্ত চাহিদাগুলি Shipment.load_demands এ তালিকাভুক্ত চাহিদাগুলির সাথে যোগ করা হয়েছে।

visit_types[]

string

পরিদর্শনের প্রকারগুলি নির্দিষ্ট করে৷ এই পরিদর্শনটি সম্পূর্ণ করার জন্য একটি যানবাহনের জন্য প্রয়োজনীয় অতিরিক্ত সময় বরাদ্দ করতে এটি ব্যবহার করা যেতে পারে (দেখুন Vehicle.extra_visit_duration_for_visit_type )।

একটি প্রকার শুধুমাত্র একবার প্রদর্শিত হতে পারে।

label

string

এই VisitRequest জন্য একটি লেবেল নির্দিষ্ট করে। এই লেবেলটি সংশ্লিষ্ট ShipmentRoute.Visit visit_label হিসাবে প্রতিক্রিয়াতে রিপোর্ট করা হয়েছে।

avoid_u_turns

bool

এই অবস্থানে ড্রাইভিং রুটে ইউ-টার্ন এড়ানো উচিত কিনা তা নির্দিষ্ট করে। U-টার্ন এড়ানো সর্বোত্তম প্রচেষ্টা এবং সম্পূর্ণ পরিহারের নিশ্চয়তা নেই। এটি একটি পরীক্ষামূলক বৈশিষ্ট্য এবং আচরণ পরিবর্তন সাপেক্ষে।

পরীক্ষামূলক: আরও বিশদ বিবরণের জন্য https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request দেখুন।

শিপমেন্ট মডেল

একটি চালান মডেলে চালানের একটি সেট থাকে যা যানবাহনের একটি সেট দ্বারা সঞ্চালিত হতে হবে, সামগ্রিক খরচ কমিয়ে, যার সমষ্টি:

  • যানবাহন রুট করার খরচ (মোট সময় প্রতি খরচের যোগফল, ভ্রমণের সময় প্রতি খরচ, এবং সমস্ত যানবাহনের উপর নির্দিষ্ট খরচ)।
  • অকার্যকর চালান জরিমানা.
  • চালানের বিশ্বব্যাপী সময়কালের খরচ
ক্ষেত্র
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 ক্ষেত্রগুলি ব্যবহার করার সময়, আপনি কার্যক্ষমতা বাড়াতে এই উইন্ডোটিকে একটি ছোট ব্যবধানে সেট করতে চাইতে পারেন (যেমন, যদি আপনি একটি একক দিনের মডেল করেন, তাহলে আপনাকে সেই দিনে বিশ্বব্যাপী সময় সীমা নির্ধারণ করা উচিত)। সেট না থাকলে, 00:00:00 UTC, জানুয়ারী 1, 1970 (অর্থাৎ সেকেন্ড: 0, ন্যানো: 0) ডিফল্ট হিসাবে ব্যবহৃত হয়।

global_end_time

Timestamp

সেট না থাকলে, 00:00:00 UTC, জানুয়ারী 1, 1971 (অর্থাৎ সেকেন্ড: 31536000, nanos: 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।
  • 1টি গাড়ি 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।
  • ম্যাট্রিক্স "দ্রুত" ব্যবহার করে 1টি গাড়ি locA-তে তার রুট শুরু করে এবং locB-এ শেষ করে।
  • ম্যাট্রিক্স "স্লো" ব্যবহার করে 1টি গাড়ি locB-তে তার রুট শুরু করে এবং locB-এ শেষ করে।
  • ম্যাট্রিক্স "দ্রুত" ব্যবহার করে 1টি গাড়ি locB-তে তার রুট শুরু করে এবং locB-এ শেষ করে।
  • locC এ 1 পিকআপ ভিজিট করার অনুরোধ। 
model {
  vehicles { start_tags: "locA" end_tags: "locB" start_tags: "fast" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "slow" }
  vehicles { start_tags: "locB" end_tags: "locB" start_tags: "fast" }
  shipments { pickups { tags: "locC" } }
  duration_distance_matrix_src_tags: "locA"
  duration_distance_matrix_src_tags: "locB"
  duration_distance_matrix_src_tags: "locC"
  duration_distance_matrix_dst_tags: "locB"
  duration_distance_matrix_dst_tags: "locC"
  duration_distance_matrices {
    vehicle_start_tag: "fast"
    rows {  # from: locA
      durations { seconds: 1000 } meters: 2000 # to: locB
      durations { seconds: 600 }  meters: 1000 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }   meters: 0    # to: locB
      durations { seconds: 700 } meters: 1200 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 702 } meters: 1190 # to: locB
      durations { seconds: 0 }   meters: 0    # to: locC
    }
  }
  duration_distance_matrices {
    vehicle_start_tag: "slow"
    rows {  # from: locA
      durations { seconds: 1800 } meters: 2001 # to: locB
      durations { seconds: 900 }  meters: 1002 # to: locC
    }
    rows {  # from: locB
      durations { seconds: 0 }    meters: 0    # to: locB
      durations { seconds: 1000 } meters: 1202 # to: locC
    }
    rows {  # from: locC
      durations { seconds: 1001 } meters: 1195 # to: locB
      durations { seconds: 0 }    meters: 0    # to: locC
    }
  }
}
duration_distance_matrix_src_tags[]

string

সময়কাল এবং দূরত্ব ম্যাট্রিক্সের উত্স সংজ্ঞায়িত ট্যাগ; duration_distance_matrices(i).rows(j) ম্যাট্রিক্স i-তে অন্যান্য ভিজিট পর্যন্ত duration_distance_matrix_src_tags(j) ট্যাগ সহ ভিজিট থেকে সময়কাল এবং দূরত্ব নির্ধারণ করে।

ট্যাগ VisitRequest.tags বা Vehicle.start_tags এর সাথে মিলে যায়। একটি প্রদত্ত VisitRequest বা Vehicle অবশ্যই এই ক্ষেত্রের একটি ট্যাগের সাথে মিলবে। মনে রাখবেন যে একটি Vehicle উৎস, গন্তব্য এবং ম্যাট্রিক্স ট্যাগ একই হতে পারে; একইভাবে একটি VisitRequest এর উৎস এবং গন্তব্য ট্যাগ একই হতে পারে। সমস্ত ট্যাগ আলাদা হতে হবে এবং খালি স্ট্রিং হতে পারে না। যদি এই ক্ষেত্রটি খালি না থাকে, তাহলে duration_distance_matrices অবশ্যই খালি থাকবে না।

duration_distance_matrix_dst_tags[]

string

সময়কাল এবং দূরত্ব ম্যাট্রিক্সের গন্তব্য সংজ্ঞায়িত ট্যাগ; duration_distance_matrices(i).rows(j).durations(k) (resp. duration_distance_matrices(i).rows(j).meters(k)) পরিদর্শন থেকে ভ্রমণের সময়কাল (দূরত্ব) সংজ্ঞায়িত করে duration_distance_matrix_src_tags(j) ট্যাগ সহ matrix i-এ duration_distance_matrix_dst_tags(k)

ট্যাগ VisitRequest.tags বা Vehicle.start_tags এর সাথে মিলে যায়। একটি প্রদত্ত VisitRequest বা Vehicle অবশ্যই এই ক্ষেত্রের একটি ট্যাগের সাথে মিলবে। মনে রাখবেন যে একটি Vehicle উৎস, গন্তব্য এবং ম্যাট্রিক্স ট্যাগ একই হতে পারে; একইভাবে একটি VisitRequest এর উৎস এবং গন্তব্য ট্যাগ একই হতে পারে। সমস্ত ট্যাগ আলাদা হতে হবে এবং খালি স্ট্রিং হতে পারে না। যদি এই ক্ষেত্রটি খালি না থাকে, তাহলে duration_distance_matrices অবশ্যই খালি থাকবে না।

transition_attributes[]

TransitionAttributes

রূপান্তর বৈশিষ্ট্য মডেল যোগ করা হয়েছে.

shipment_type_incompatibilities[]

ShipmentTypeIncompatibility

বেমানান শিপমেন্ট_টাইপের সেট ( ShipmentTypeIncompatibility ইনকম্প্যাটিবিলিটি দেখুন)।

shipment_type_requirements[]

ShipmentTypeRequirement

shipment_type প্রয়োজনীয়তার সেট ( ShipmentTypeRequirement দেখুন)।

precedence_rules[]

PrecedenceRule

অগ্রাধিকার বিধিগুলির সেট যা মডেলে প্রয়োগ করা আবশ্যক৷

গুরুত্বপূর্ণ : অগ্রাধিকার নিয়মের ব্যবহার সমস্যার আকারকে সীমিত করে যা অপ্টিমাইজ করা যেতে পারে। অনেক চালান অন্তর্ভুক্ত অগ্রাধিকার নিয়ম ব্যবহার করে অনুরোধ প্রত্যাখ্যান করা হতে পারে.

max_active_vehicles

int32

সক্রিয় যানবাহনের সর্বাধিক সংখ্যা সীমাবদ্ধ করে। একটি যানবাহন সক্রিয় থাকে যদি এর রুটটি কমপক্ষে একটি চালান সম্পাদন করে। যেখানে যানবাহনের তুলনায় কম চালক আছে এবং যানবাহনের বহর ভিন্নধর্মী এমন ক্ষেত্রে রুটের সংখ্যা সীমিত করতে এটি ব্যবহার করা যেতে পারে। অপ্টিমাইজেশন তারপর ব্যবহার করার জন্য যানবাহনের সেরা উপসেট নির্বাচন করবে। কঠোরভাবে ইতিবাচক হতে হবে।

সময়কাল দূরত্ব ম্যাট্রিক্স

পরিদর্শন এবং যানবাহন শুরুর অবস্থানগুলি এবং যানবাহনের শেষ অবস্থানগুলি থেকে একটি সময়কাল এবং দূরত্বের ম্যাট্রিক্স নির্দিষ্ট করে৷

ক্ষেত্র
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।

টাইপ

উদ্দেশ্য টাইপ যা খরচের একটি সেটে ম্যাপ করা হবে।

এনামস
DEFAULT একটি যুক্তিসঙ্গত সমাধান নিশ্চিত করতে খরচের একটি ডিফল্ট সেট ব্যবহার করা হবে। দ্রষ্টব্য: এই উদ্দেশ্যটি নিজে থেকেই ব্যবহার করা যেতে পারে, তবে সর্বদা ওজন 1.0 এর সাথে একটি বেসলাইন হিসাবে, ব্যবহারকারীর দ্বারা নির্দিষ্ট করা উদ্দেশ্যগুলিতে যোগ করা হবে, যদি এটি ইতিমধ্যে উপস্থিত না থাকে।
MIN_DISTANCE "MIN" উদ্দেশ্য। ভ্রমণ করা মোট দূরত্ব কমিয়ে দিন।
MIN_WORKING_TIME মোট কাজের সময় কম করুন, সমস্ত যানবাহনের সমষ্টি।
MIN_TRAVEL_TIME উপরের মতই কিন্তু শুধুমাত্র ভ্রমণের সময় ফোকাস করা।
MIN_NUM_VEHICLES ব্যবহৃত গাড়ির সংখ্যা কমিয়ে দিন।

অগ্রাধিকার নিয়ম

দুটি ইভেন্টের মধ্যে একটি অগ্রাধিকার নিয়ম (প্রতিটি ইভেন্ট হল পিকআপ বা একটি চালানের ডেলিভারি): "দ্বিতীয়" ইভেন্টটি "প্রথম" শুরু হওয়ার পরে কমপক্ষে offset_duration শুরু করতে হবে।

একই (বা সম্পর্কিত) ঘটনাগুলিকে উল্লেখ করতে পারে বেশ কিছু পূর্বসূর্য, যেমন, "A-এর ডেলিভারির পরে B-এর পিকআপ হয়" এবং "B-এর পিক-আপের পরে C-এর পিকআপ ঘটে"।

তদ্ব্যতীত, অগ্রাধিকার শুধুমাত্র তখনই প্রযোজ্য যখন উভয় চালান সঞ্চালিত হয় এবং অন্যথায় উপেক্ষা করা হয়।

ক্ষেত্র
first_is_delivery

bool

"প্রথম" ইভেন্টটি একটি ডেলিভারি কিনা তা নির্দেশ করে৷

second_is_delivery

bool

"দ্বিতীয়" ইভেন্টটি একটি ডেলিভারি কিনা তা নির্দেশ করে৷

offset_duration

Duration

"প্রথম" এবং "দ্বিতীয়" ইভেন্টের মধ্যে অফসেট। এটা নেতিবাচক হতে পারে.

first_index

int32

"প্রথম" ইভেন্টের চালান সূচক। এই ক্ষেত্র নির্দিষ্ট করা আবশ্যক.

second_index

int32

"দ্বিতীয়" ইভেন্টের চালান সূচক। এই ক্ষেত্র নির্দিষ্ট করা আবশ্যক.

শিপমেন্ট রুট

একটি যানবাহনের রুট সময় অক্ষ বরাবর পচনশীল হতে পারে, এভাবে (আমরা অনুমান করি সেখানে 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

পরিশেষে, এখানে ট্রানজিশনের সময় ট্রাভেল, ব্রেক, বিলম্ব এবং অপেক্ষার ব্যবস্থা করা যেতে পারে।

  • তারা ওভারল্যাপ না.
  • বিলম্বটি অনন্য এবং পরের দর্শনের (বা গাড়ির সমাপ্তি) ঠিক আগে একটি সংলগ্ন সময় হতে হবে । সুতরাং, এটির শুরু এবং শেষ সময় জানার জন্য বিলম্বের সময়কাল জানা যথেষ্ট।
  • BREAKS হল সংলগ্ন, অ-ওভারল্যাপিং সময়কাল। প্রতিক্রিয়া প্রতিটি বিরতির শুরুর সময় এবং সময়কাল নির্দিষ্ট করে।
  • ট্রাভেল এবং ওয়েট হল "প্রিম্পটেবল": এই ট্রানজিশনের সময় এগুলি বেশ কয়েকবার ব্যাহত হতে পারে৷ ক্লায়েন্টরা ধরে নিতে পারেন যে ভ্রমণ "যত তাড়াতাড়ি সম্ভব" হয় এবং "অপেক্ষা" বাকি সময় পূরণ করে।

একটি (জটিল) উদাহরণ: 

                               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

একটি রুট প্রতিনিধিত্ব করে ভিজিট ক্রম আদেশ. ভিজিট[i] হল রুটের i-তম ভিজিট। এই ক্ষেত্রটি খালি থাকলে, গাড়িটিকে অব্যবহৃত হিসাবে বিবেচনা করা হয়।

transitions[]

Transition

রুটের জন্য ট্রানজিশনের অর্ডার করা তালিকা।

has_traffic_infeasibilities

bool

যখন OptimizeToursRequest.consider_road_traffic , সত্যে সেট করা হয়, তখন এই ক্ষেত্রটি নির্দেশ করে যে ট্র্যাফিক-ভিত্তিক ভ্রমণের সময়কালের অনুমান ব্যবহার করে রুটের সময়ের অসঙ্গতিগুলি পূর্বাভাস দেওয়া হয়৷ ট্রাফিক-সামঞ্জস্যপূর্ণ ভ্রমণ সম্পূর্ণ করার জন্য অপর্যাপ্ত সময় থাকতে পারে, বিলম্ব এবং ভিজিটের মধ্যে বিরতি, প্রথম দর্শনের আগে, বা শেষ দর্শনের পরে, যদিও এখনও পরিদর্শন এবং গাড়ির সময় জানালাকে সন্তুষ্ট করে। যেমন, 

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

ট্রাফিকের কারণে ট্রাভেল টাইম travel_duration(previous_visit, next_visit) এর অনুমান বৃদ্ধির কারণে নেক্সট_ভিসিটে আগমন সম্ভবত বর্তমান সময় উইন্ডোর চেয়ে পরে ঘটবে। এছাড়াও, ভ্রমণের সময় অনুমান বৃদ্ধি এবং পরিদর্শন বা বিরতির সময় উইন্ডো সীমাবদ্ধতার কারণে একটি বিরতি একটি দর্শনের সাথে ওভারল্যাপ করতে বাধ্য হতে পারে।

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", এবং মানগুলি হল সংশ্লিষ্ট খরচ ক্ষেত্রের দ্বারা উত্পন্ন মোট খরচ, সমগ্র রুট জুড়ে একত্রিত৷ অন্য কথায়, খরচ ["model.shipments.pickups.cost"] হল রুটের সমস্ত পিকআপ খরচের সমষ্টি৷ মডেলে সংজ্ঞায়িত সমস্ত খরচ এখানে বিস্তারিতভাবে রিপোর্ট করা হয়েছে ট্রানজিশন অ্যাট্রিবিউটের সাথে সম্পর্কিত খরচগুলি বাদ দিয়ে যেগুলি শুধুমাত্র 2022/01 হিসাবে সমষ্টিগতভাবে রিপোর্ট করা হয়েছে।

route_total_cost

double

রুটের মোট খরচ। খরচ ম্যাপে সমস্ত খরচের যোগফল।

বিরতি

একটি বিরতির সম্পাদন প্রতিনিধিত্বকারী ডেটা।

ক্ষেত্র
start_time

Timestamp

বিরতির শুরুর সময়।

duration

Duration

বিরতির সময়কাল।

এনকোডেড পলিলাইন

একটি পলিলাইনের এনকোড করা উপস্থাপনা। পলিলাইন এনকোডিং সম্পর্কে আরও তথ্য এখানে পাওয়া যাবে: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding ।

ক্ষেত্র
points

string

পলিলাইনের এনকোডেড পয়েন্ট প্রতিনিধিত্বকারী স্ট্রিং।

উত্তরণ

রুটে দুটি ইভেন্টের মধ্যে স্থানান্তর। ShipmentRoute বর্ণনা দেখুন।

যদি গাড়ির একটি start_location এবং/অথবা end_location না থাকে, তাহলে সংশ্লিষ্ট ভ্রমণের মেট্রিক্স 0 হয়।

ক্ষেত্র
travel_duration

Duration

এই পরিবর্তনের সময় ভ্রমণের সময়কাল।

travel_distance_meters

double

স্থানান্তরের সময় দূরত্ব ভ্রমণ।

traffic_info_unavailable

bool

যখন OptimizeToursRequest.consider_road_traffic এর মাধ্যমে ট্রাফিকের অনুরোধ করা হয়, এবং Transition জন্য ট্র্যাফিক তথ্য পুনরুদ্ধার করা যায় না, তখন এই বুলিয়ান সত্যে সেট করা হয়। এটি অস্থায়ী হতে পারে (রিয়েলটাইম ট্র্যাফিক সার্ভারে বিরল হিক্কা) বা স্থায়ী (এই অবস্থানের জন্য কোনও ডেটা নেই)।

delay_duration

Duration

এই ট্রানজিশনে প্রযোজ্য বিলম্বের সময়কালের যোগফল। যদি থাকে, বিলম্বটি পরবর্তী ইভেন্টের (ভিজিট বা গাড়ির সমাপ্তি) আগে ঠিক delay_duration সময় শুরু হয়। TransitionAttributes.delay দেখুন।

break_duration

Duration

এই পরিবর্তনের সময় বিরতির সময়কালের যোগফল, যদি থাকে। প্রতিটি বিরতির শুরুর সময় এবং সময়কাল সম্পর্কে বিশদ বিবরণ ShipmentRoute.breaks এ সংরক্ষণ করা হয়।

wait_duration

Duration

এই ট্রানজিশনের সময় অপেক্ষায় কেটেছে। অপেক্ষার সময়কাল অলস সময়ের সাথে মিলে যায় এবং বিরতির সময় অন্তর্ভুক্ত করে না। এছাড়াও মনে রাখবেন যে এই অপেক্ষার সময়টিকে কয়েকটি অ-সংলগ্ন বিরতিতে বিভক্ত করা যেতে পারে।

total_duration

Duration

ট্রানজিশনের মোট সময়কাল, সুবিধার জন্য প্রদত্ত। এটি সমান:

  • পরবর্তী ভিজিট start_time (বা vehicle_end_time যদি এটি শেষ ট্রানজিশন হয়) - এই ট্রানজিশনের start_time ;
  • ShipmentRoute.has_traffic_infeasibilities মিথ্যা হলে, নিম্নলিখিতগুলি অতিরিক্ত ধারণ করে: `total_duration = ভ্রমণ_সময়কাল + বিলম্ব_সময়কাল
  • বিরতি_কাল + অপেক্ষার_কাল'।
start_time

Timestamp

এই রূপান্তরের শুরুর সময়।

route_polyline

EncodedPolyline

রূপান্তরের সময় অনুসরণ করা রুটের এনকোডেড পলিলাইন উপস্থাপনা। populate_transition_polylines সত্যে সেট করা থাকলেই এই ক্ষেত্রটি পপুলেট করা হয়।

route_token

string

শুধুমাত্র আউটপুট। একটি অস্বচ্ছ টোকেন যা নেভিগেশনের সময় রুটটি পুনর্গঠন করতে নেভিগেশন SDK- তে পাস করা যেতে পারে এবং, পুনরায় রুট করার ক্ষেত্রে, রুটটি তৈরি করার সময় আসল উদ্দেশ্যকে সম্মান করে। এই টোকেনটিকে একটি অস্বচ্ছ ব্লব হিসাবে বিবেচনা করুন। অনুরোধ জুড়ে এর মান তুলনা করবেন না কারণ পরিষেবাটি ঠিক একই রুট ফিরিয়ে দিলেও এর মান পরিবর্তিত হতে পারে। populate_transition_polylines সত্যে সেট করা থাকলেই এই ক্ষেত্রটি পপুলেট করা হয়।

vehicle_loads

map<string, VehicleLoad >

এই ট্রানজিশনের সময় যানবাহন লোড হয়, প্রতিটি প্রকারের জন্য যা হয় এই গাড়ির Vehicle.load_limits তে প্রদর্শিত হয়, অথবা এই রুটে সম্পাদিত কিছু চালানে নন-জিরো Shipment.load_demands আছে৷

প্রথম স্থানান্তরের সময় লোডগুলি হল গাড়ির রুটের শুরুর লোড। তারপর, প্রতিটি ভিজিটের পরে, ভিজিটটি পিকআপ বা ডেলিভারি ছিল কিনা তার উপর নির্ভর করে, পরবর্তী ট্রানজিশনের লোড পেতে ভিজিটের load_demands হয় যোগ করা হয় বা বিয়োগ করা হয়।

যানবাহন লোড

একটি প্রদত্ত প্রকারের জন্য রুট বরাবর কিছু সময়ে গাড়ির প্রকৃত লোড রিপোর্ট করে ( 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.label অনুলিপি.লাবেল, Shipment নির্দিষ্ট করা থাকলে।

visit_label

string

সংশ্লিষ্ট VisitRequest.label অনুলিপি, যদি VisitRequest নির্দিষ্ট করা হয়।

injected_solution_location_token

int32

ভিজিটের অবস্থান সম্পর্কে তথ্য উপস্থাপন করে একটি অস্বচ্ছ টোকেন।

এই ক্ষেত্রটি ফলাফলের রুটগুলির পরিদর্শনগুলিতে পপুলেশন করা যেতে পারে যখন VisitRequest.avoid_u_turns এই ভিজিটের জন্য সত্যে সেট করা হয়েছিল বা যদি ShipmentModel.avoid_u_turns অনুরোধটি OptimizeToursRequest সত্যে সেট করা হয়েছিল।

পরীক্ষামূলক: আরও বিশদ বিবরণের জন্য https://developers.google.com/maps/tt/route-optimization/experimental/u-turn-avoidance/make-request দেখুন।

শিপমেন্ট টাইপ অসঙ্গতি

তাদের চালান_ টাইপের উপর নির্ভর করে চালানের মধ্যে অসঙ্গতিগুলি নির্দিষ্ট করে। অসঙ্গতি মোডের উপর ভিত্তি করে একই রুটে অসামঞ্জস্যপূর্ণ চালানের উপস্থিতি সীমাবদ্ধ।

ক্ষেত্র
types[]

string

বেমানান প্রকারের তালিকা। তালিকাভুক্তদের মধ্যে আলাদা shipment_types থাকা দুটি চালান হল "বেমানান"৷

incompatibility_mode

IncompatibilityMode

অসঙ্গতিতে মোড প্রয়োগ করা হয়েছে।

অসঙ্গতি মোড

একই রুটে অসামঞ্জস্যপূর্ণ চালানের উপস্থিতি কীভাবে সীমাবদ্ধ থাকে তা নির্ধারণ করে।

এনামস
INCOMPATIBILITY_MODE_UNSPECIFIED অনির্দিষ্ট অসঙ্গতি মোড। এই মান ব্যবহার করা উচিত নয়.
NOT_PERFORMED_BY_SAME_VEHICLE এই মোডে, অসামঞ্জস্যপূর্ণ ধরনের দুটি চালান একই যানবাহন ভাগ করতে পারে না।
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY

NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY অসঙ্গতি মোডের সাথে বেমানান প্রকারের দুটি চালানের জন্য:

  • যদি উভয়ই শুধুমাত্র পিকআপ হয় (কোনও ডেলিভারি নেই) বা শুধুমাত্র ডেলিভারি (কোন পিকআপ নেই), তবে তারা একই গাড়ি শেয়ার করতে পারবে না।
  • যদি একটি চালানের একটি ডেলিভারি এবং অন্যটি একটি পিকআপ থাকে, তবে দুটি চালান একই গাড়ি ভাগ করতে পারে যদি পূর্ববর্তী চালানটি পরবর্তীটি তোলার আগে বিতরণ করা হয়।

চালানের প্রকারের প্রয়োজনীয়তা

তাদের চালান_ টাইপের উপর ভিত্তি করে চালানের মধ্যে প্রয়োজনীয়তা নির্দিষ্ট করে। প্রয়োজনীয়তার সুনির্দিষ্ট বৈশিষ্ট্য প্রয়োজন মোড দ্বারা সংজ্ঞায়িত করা হয়।

ক্ষেত্র
required_shipment_type_alternatives[]

string

dependent_shipment_types টাইপস দ্বারা প্রয়োজনীয় বিকল্প চালানের ধরণের তালিকা।

dependent_shipment_types[]

string

dependent_shipment_types টাইপস ফিল্ডে কোনও ধরণের সহ সমস্ত শিপমেন্টের জন্য একই রুটে দেখার জন্য required_shipment_type_alternatives কমপক্ষে একটি চালানের প্রয়োজন।

দ্রষ্টব্য: প্রয়োজনীয়তার চেইনগুলি যেমন একটি shipment_type নিজের উপর নির্ভর করে তা অনুমোদিত নয়।

requirement_mode

RequirementMode

প্রয়োজনে মোড প্রয়োগ করা হয়েছে।

প্রয়োজন মোড

একটি রুটে নির্ভরশীল চালানের উপস্থিতি সংজ্ঞায়িত করে।

এনামস
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 আগের মতোই, "নির্ভরশীল" চালানগুলি ছাড়া তাদের ডেলিভারির সময় তাদের গাড়িতে একটি "প্রয়োজনীয়" চালান থাকতে হবে৷

স্কিপশিপমেন্ট

একটি সমাধানে অপরিবর্তিত শিপমেন্টের বিশদ নির্দিষ্ট করে। তুচ্ছ মামলার জন্য এবং/অথবা যদি আমরা এড়িয়ে যাওয়ার কারণটি সনাক্ত করতে সক্ষম হই তবে আমরা এখানে কারণটি প্রতিবেদন করি।

ক্ষেত্র
index

int32

সূচকটি সোর্স ShipmentModel চালানের সূচকের সাথে মিলে যায়।

label

string

সংশ্লিষ্ট Shipment.label অনুলিপি.লাবেল, Shipment নির্দিষ্ট করা থাকলে।

reasons[]

Reason

কেন চালানটি এড়িয়ে গেছে তা ব্যাখ্যা করে এমন একটি কারণগুলির একটি তালিকা। উপরোক্ত Reason দেখুন। কেন আমরা কেন চালান এড়িয়ে গেছেন তা যদি বুঝতে না পারি তবে কারণগুলি সেট করা হবে না।

penalty_cost

double

এটি Shipment.penalty_cost একটি অনুলিপি en

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

estimated_incompatible_vehicle_ratio

double

যানবাহনের আনুমানিক অনুপাত যা নীচের কমপক্ষে একটি কারণের জন্য এই চালানটি সম্পাদন করতে পারে না। দ্রষ্টব্য: কারণগুলি যখন কোনও যানবাহন জড়িত থাকে তখনই এটি পূরণ হয়।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

কারণ

চালানটি কেন এড়িয়ে গেছে তা যদি আমরা ব্যাখ্যা করতে পারি তবে কারণগুলি এখানে তালিকাভুক্ত করা হবে। যদি সমস্ত যানবাহনের জন্য কারণ একই না হয় তবে reason 1 টিরও বেশি উপাদান থাকবে। একটি এড়িয়ে যাওয়া চালানের নকল কারণ থাকতে পারে না, যেমন সমস্ত ক্ষেত্র একই থাকে 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 হিসাবে একই। এই তালিকাটি অগত্যা সম্পূর্ণ নয়। এটি কেবল তখনই পূরণ করা হয় যদি [PLEH_EXALL_VEHICLE_INDICES_IN_SKIPE_REAINS] [] সত্য।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

example_exceeded_capacity_type

string

যদি কারণ কোডটি DEMAND_EXCEEDS_VEHICLE_CAPACITY থাকে তবে একটি ক্ষমতার ধরণের নথি যা ছাড়িয়ে যায়।

example_vehicle_index

int32

যদি কারণটি চালান-যানবাহন অসঙ্গতির সাথে সম্পর্কিত হয় তবে এই ক্ষেত্রটি একটি প্রাসঙ্গিক গাড়ির সূচক সরবরাহ করে।

কোড

কোড কারণ টাইপ সনাক্তকরণ। এখানে অর্ডার অর্থহীন। বিশেষত, এটি উভয়ই প্রয়োগ করা হলে সমাধানের ক্ষেত্রে অন্য কোনও কারণ উপস্থিত হবে কিনা তার কোনও ইঙ্গিত দেয় না।

এনামস
CODE_UNSPECIFIED এটি কখনই ব্যবহার করা উচিত নয়।
NO_VEHICLE মডেলটিতে কোনও যানবাহন নেই যা সমস্ত চালানকে অপ্রয়োজনীয় করে তোলে।
DEMAND_EXCEEDS_VEHICLE_CAPACITY চালানের চাহিদা কিছু ক্ষমতার ধরণের জন্য একটি গাড়ির সক্ষমতা ছাড়িয়ে যায়, যার মধ্যে একটি example_exceeded_capacity_type টাইপ।
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT

এই চালানটি সম্পাদনের জন্য প্রয়োজনীয় সর্বনিম্ন দূরত্ব, অর্থাত্ গাড়ির start_location থেকে চালানের পিকআপ এবং/অথবা ডেলিভারির অবস্থানগুলিতে এবং গাড়ির শেষ স্থানে গাড়ির route_distance_limit ছাড়িয়ে যায়।

নোট করুন যে এই গণনার জন্য আমরা জিওডেসিক দূরত্ব ব্যবহার করি।

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT

ভ্রমণের সময়, অপেক্ষা করার সময় এবং পরিষেবার সময় সহ এই চালানটি সম্পাদনের জন্য প্রয়োজনীয় সর্বনিম্ন সময় গাড়ির route_duration_limit ছাড়িয়ে যায়।

দ্রষ্টব্য: ভ্রমণের সময়টি সেরা ক্ষেত্রে দৃশ্যে গণনা করা হয়, যথা জিওডেসিক দূরত্ব x 36 মি/এস (প্রায় 130 কিমি/ঘন্টা) হিসাবে।

CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT উপরের মতো একই তবে আমরা কেবল ন্যূনতম ভ্রমণের সময় এবং গাড়ির travel_duration_limit তুলনা করি।
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS যানবাহনটি এই চালানটি সেরা-ক্ষেত্রে দৃশ্যে সম্পাদন করতে পারে না (দেখুন CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT সময় গণনার জন্য) যদি এটি তার প্রথম দিকের সময়ে শুরু হয়: মোট সময়টি তার সর্বশেষ শেষ সময়ের পরে গাড়িটি শেষ করে দেবে।
VEHICLE_NOT_ALLOWED চালানের allowed_vehicle_indices ক্ষেত্রগুলি খালি নয় এবং এই যানটি এর সাথে সম্পর্কিত নয়।
VEHICLE_IGNORED

গাড়ির ignore ক্ষেত্রটি সত্য।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

SHIPMENT_IGNORED

চালানের ignore ক্ষেত্রটি সত্য।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

SKIPPED_IN_INJECTED_SOLUTION_CONSTRAINT

চালানটি injected_solution_constraint এড়িয়ে যায়।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

VEHICLE_ROUTE_IS_FULLY_SEQUENCE_CONSTRAINED

injected_solution_constraint নির্দিষ্ট গাড়ির রুট শিথিলকরণ কোনও ভিজিট সন্নিবেশ করার অনুমতি দেয় না।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

ZERO_PENALTY_COST

চালানের শূন্য জরিমানা ব্যয় রয়েছে। যদিও এটি একটি উন্নত মডেলিং পছন্দ হিসাবে কার্যকর হতে পারে তবে এটি কেন চালান এড়িয়ে গেছে তাও ব্যাখ্যা করতে পারে।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

টাইম উইন্ডো

টাইম উইন্ডো একটি ইভেন্টের সময়কে সীমাবদ্ধ করে, যেমন একটি পরিদর্শনে আগমনের সময়, বা একটি গাড়ির শুরু এবং শেষের সময়।

হার্ড টাইম উইন্ডো সীমানা, 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 ইভেন্টটি ঘটে তার কতক্ষণের পরে সমানুপাতিক ব্যয় করে। 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

মডেলটিতে অন্যান্য ব্যয়গুলিতে প্রতি ঘন্টা ব্যয় যুক্ত করা হয় যদি ইভেন্টটি সফট_স্টার্ট_টাইমের আগে ঘটে থাকে তবে গণনা করা হয়: 

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

এই ব্যয়টি অবশ্যই ইতিবাচক হতে হবে এবং সফট_স্টার্ট_টাইম সেট করা থাকলে ক্ষেত্রটি কেবল সেট করা যেতে পারে।

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 প্রযোজ্য হতে পারে: সেই ক্ষেত্রে, সমস্ত অতিরিক্ত খরচ যোগ হয় এবং কঠোরতম সীমাবদ্ধতা বা সীমা প্রযোজ্য হয় (প্রাকৃতিক "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/06 অনুযায়ী, শুধুমাত্র নরম সীমা সমর্থিত।

delay

Duration

এই রূপান্তরটি সম্পাদন করার সময় যে বিলম্ব হয়েছে তা উল্লেখ করে।

এই বিলম্ব সর্বদা উৎস পরিদর্শন শেষ করার পরে এবং গন্তব্য পরিদর্শন শুরু করার আগে ঘটে।

উরি

একটি ইউনিভার্সাল রিসোর্স আইডেন্টিফায়ার যা একটি রিসোর্সকে নির্দেশ করে যা রুট অপ্টিমাইজেশান এপিআই দ্বারা পড়া এবং লেখা যায়।

ক্ষেত্র
uri

string

সম্পদের URI. সম্পদ এখনও বিদ্যমান নাও হতে পারে.

সম্পদের বিষয়বস্তু JSON বা textproto হিসাবে এনকোড করা হয়। শুধুমাত্র Google ক্লাউড স্টোরেজ সংস্থান সমর্থিত। যদি রিসোর্সটি JSON হিসেবে এনকোড করা হয়, তাহলে রিসোর্সের নামের সাথে .json প্রত্যয়িত হতে হবে। যদি রিসোর্সটি টেক্সটপ্রোটো হিসাবে এনকোড করা হয়, তাহলে রিসোর্স নামের সাথে .txtpb প্রত্যয়িত হতে হবে। উদাহরণস্বরূপ, একটি JSON এনকোড করা ফাইলের একটি Google ক্লাউড স্টোরেজ URI এর মতো দেখতে হতে পারে: 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 departure_location arrival_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 সমষ্টি।travel_duration।

route_distance_limit

DistanceLimit

গাড়ির রুটের মোট দূরত্বে সীমা প্রযোজ্য। একটি প্রদত্ত OptimizeToursResponse এ, রুটের দূরত্ব হল এর সমস্ত transitions.travel_distance_meters সমষ্টি।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 টাইপও দেখুন।

সময়সীমা

একটি গাড়ির রুটের সর্বাধিক সময়কাল সংজ্ঞায়িত একটি সীমা৷ এটা শক্ত বা নরম হতে পারে।

যখন একটি নরম সীমা ক্ষেত্র সংজ্ঞায়িত করা হয়, তখন সফ্ট সর্বোচ্চ থ্রেশহোল্ড এবং এর সংশ্লিষ্ট খরচ উভয়ই একসাথে সংজ্ঞায়িত করা আবশ্যক।

ক্ষেত্র
max_duration

Duration

একটি হার্ড সীমা সর্বাধিক সর্বোচ্চ_করণের সময়কালকে সীমাবদ্ধ করে।

soft_max_duration

Duration

একটি নরম সীমা সর্বোচ্চ সময়সীমার সীমা বলবৎ করে না, কিন্তু লঙ্ঘন করলে রুটটিকে একটি খরচ বহন করতে হয়। এই খরচ একই ইউনিটের সাথে মডেলে সংজ্ঞায়িত অন্যান্য খরচ যোগ করে।

যদি সংজ্ঞায়িত করা হয় তবে soft_max_duration অবশ্যই অবিচ্ছিন্ন হতে হবে। যদি MAX_DURATION এছাড়াও সংজ্ঞায়িত করা হয় তবে soft_max_duration অবশ্যই সর্বোচ্চ_করণের চেয়ে কম হওয়া উচিত।

quadratic_soft_max_duration

Duration

একটি নরম সীমা সর্বোচ্চ সময়সীমার সীমা বলবৎ করে না, কিন্তু লঙ্ঘন করলে রুটটিকে খরচ করতে হয়, সময়কালের মধ্যে দ্বিঘাত। এই খরচ একই ইউনিটের সাথে মডেলে সংজ্ঞায়িত অন্যান্য খরচ যোগ করে।

যদি সংজ্ঞায়িত করা হয় তবে quadratic_soft_max_duration অবশ্যই অ -জ্ঞানমূলক হতে হবে। যদি max_duration এছাড়াও সংজ্ঞায়িত করা হয় তবে quadratic_soft_max_duration অবশ্যই max_duration চেয়ে কম হওয়া উচিত এবং পার্থক্যটি অবশ্যই এক দিনের চেয়ে বড় হতে হবে না:

max_duration - quadratic_soft_max_duration <= 86400 seconds

cost_per_hour_after_soft_max

double

soft_max_duration থ্রেশহোল্ড লঙ্ঘন করা হলে প্রতি ঘন্টা ব্যয় হয়। অতিরিক্ত খরচ হল 0 যদি সময়কাল থ্রেশহোল্ডের নিচে থাকে, অন্যথায় খরচ নিম্নরূপ সময়কালের উপর নির্ভর করে: 

  cost_per_hour_after_soft_max * (duration - soft_max_duration)

খরচ nonnegative হতে হবে.

cost_per_square_hour_after_quadratic_soft_max

double

quadratic_soft_max_duration থ্রেশহোল্ড লঙ্ঘন করা হলে প্রতি বর্গ ঘন্টা ব্যয় ব্যয় হয়।

অতিরিক্ত খরচ হল 0 যদি সময়কাল থ্রেশহোল্ডের নিচে থাকে, অন্যথায় খরচ নিম্নরূপ সময়কালের উপর নির্ভর করে: 

  cost_per_square_hour_after_quadratic_soft_max *
  (duration - quadratic_soft_max_duration)^2

খরচ nonnegative হতে হবে.

লোডসীমা

একটি গাড়িতে প্রযোজ্য একটি লোড সীমা সংজ্ঞায়িত করে, যেমন "এই ট্রাকটি শুধুমাত্র 3500 কেজি পর্যন্ত বহন করতে পারে"। 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 ।

লোডকস্ট

Transition সময় লোডের এক ইউনিট সরানোর খরচ। একটি প্রদত্ত লোডের জন্য, খরচ হল দুটি অংশের সমষ্টি:

  • cost_per_unit_below_threshold (লোড, load_threshold )
  • সর্বোচ্চ (0, লোড - 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 খরচ হল (কস্ট_নীচে * লোড_বেলো * কিলোমিটার + খরচ_উপরে * লোড_এর উপরে * কিলোমিটার)

  • রূপান্তর 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 হতে হবে।

ট্রাভেলমোড

যানবাহন দ্বারা ব্যবহার করা যেতে পারে যা ভ্রমণ মোড.

এগুলি Google মানচিত্র প্ল্যাটফর্ম রুট API ভ্রমণ মোডগুলির একটি উপসেট হওয়া উচিত, দেখুন: https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteTravelMode

দ্রষ্টব্য: WALKING রুটগুলি বিটাতে রয়েছে এবং কখনও কখনও পরিষ্কার ফুটপাথ বা পথচারী পথগুলি অনুপস্থিত থাকতে পারে৷ আপনি আপনার অ্যাপে প্রদর্শিত সমস্ত হাঁটার রুটের জন্য ব্যবহারকারীকে এই সতর্কতা প্রদর্শন করতে হবে।

এনামস
TRAVEL_MODE_UNSPECIFIED অনির্দিষ্ট ভ্রমণ মোড, DRIVING এর সমতুল্য।
DRIVING ড্রাইভিং দিকনির্দেশের সাথে সম্পর্কিত ভ্রমণ মোড (গাড়ি, ...)।
WALKING হাঁটার দিকনির্দেশের সাথে সম্পর্কিত ভ্রমণ মোড।

আনলোডিং নীতি

একটি যানবাহন কিভাবে আনলোড করা যেতে পারে তার নীতি। শুধুমাত্র একটি পিকআপ এবং একটি ডেলিভারি উভয়ই চালানের ক্ষেত্রে প্রযোজ্য৷

অন্যান্য শিপমেন্টগুলি unloading_policy থেকে পৃথক রুটে যে কোনও জায়গায় ঘটতে পারে।

এনামস
UNLOADING_POLICY_UNSPECIFIED অনির্দিষ্ট আনলোডিং নীতি; ডেলিভারি শুধুমাত্র তাদের সংশ্লিষ্ট পিক আপ পরে ঘটতে হবে.
LAST_IN_FIRST_OUT ডেলিভারি পিকআপের বিপরীত ক্রমে ঘটতে হবে
FIRST_IN_FIRST_OUT ডেলিভারি পিকআপের মতো একই ক্রমে ঘটতে হবে

যানবাহন

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

[সমষ্টিগতমেট্রিক্স.ট্রেভেল_ডারেশন_সেকেন্ডস] [] এবং Vehicle.travel_duration_limit মধ্যে অনুপাত। যদি Vehicle.travel_duration_limit আনসেট হয় তবে এই ক্ষেত্রটি আনসেট করা হবে।

active_duration

double

[সমষ্টিগতমেট্রিক্স.টোটাল_ডারেশন_সেকেন্ডস] [] এবং Vehicle.route_duration_limit মধ্যে অনুপাত। যদি Vehicle.route_duration_limit আনসেট হয় তবে এই ক্ষেত্রটি আনসেট করা হবে।

max_load

double

সমস্ত ধরণের [একত্রিতমেট্রিক্স.ম্যাক্স_লোড] [] এবং তাদের নিজ নিজ Vehicle.load_limits মধ্যে সর্বাধিক অনুপাত Load লোড_লিমিটস। যদি সমস্ত Vehicle.load_limits লোড_লিমিট ক্ষেত্রগুলি আনসেট হয় তবে এই ক্ষেত্রটি আনসেট করা হবে।

active_span

double

অনুপাত (যানবাহন_এন্ড_টাইম - যানবাহন_স্টার্ট_টাইম) / (সর্বশেষতম_ভিল_এএনডি_টাইম - প্রারম্ভিক_ভিকল_স্টার্ট_টাইম) প্রদত্ত যানবাহনের জন্য। যদি ডিনোমিনেটর উপস্থিত না থাকে তবে এটি পরিবর্তে ( ShipmentModel.global_end_time - ShipmentModel.global_start_time ) ব্যবহার করে।

ওয়েপয়েন্ট

একটি ওয়েপয়েন্ট এনক্যাপসুলেট করে। ওয়েপয়েন্টগুলি ভিজিট রিকোয়েস্টের আগমন এবং প্রস্থানের অবস্থানগুলি এবং যানবাহনের শুরু এবং শেষের অবস্থানগুলি চিহ্নিত করে৷

ক্ষেত্র
side_of_road

bool

ঐচ্ছিক। ইঙ্গিত করে যে এই ওয়েপয়েন্টের অবস্থানটি রাস্তার একটি নির্দিষ্ট পাশে গাড়ি থামানোর জন্য একটি পছন্দকে বোঝানো হয়েছে৷ আপনি যখন এই মানটি সেট করবেন, তখন রুটটি লোকেশনের মধ্য দিয়ে যাবে যাতে গাড়িটি রাস্তার পাশে থামতে পারে যে অবস্থানটি রাস্তার মাঝখানের দিকে পক্ষপাতদুষ্ট। এই বিকল্পটি 'ওয়াকিং' ভ্রমণ মোডের জন্য কাজ করে না।

vehicle_stopover

bool

ইঙ্গিত করে যে ওয়েপয়েন্টটি গাড়িগুলিকে থামানোর জন্য বোঝানো হয়েছে, যেখানে উদ্দেশ্য হয় পিক আপ বা ড্রপ করা। এই বিকল্পটি কেবল 'ড্রাইভিং' ট্র্যাভেল মোডের জন্য কাজ করে এবং যখন 'অবস্থান_প্রকার' 'অবস্থান' হয়।

পরীক্ষামূলক: এই ক্ষেত্রের আচরণ বা অস্তিত্ব ভবিষ্যতে পরিবর্তিত হতে পারে।

ইউনিয়ন ক্ষেত্রের location_type । একটি অবস্থানের প্রতিনিধিত্ব করার বিভিন্ন উপায়। location_type নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
location

Location

একটি ঐচ্ছিক শিরোনাম সহ ভৌগলিক স্থানাঙ্ক ব্যবহার করে নির্দিষ্ট করা একটি বিন্দু৷

place_id

string

POI প্লেস আইডি ওয়েপয়েন্টের সাথে যুক্ত।

একটি ভিজিটরিকোয়েস্টের আগমন বা প্রস্থানের অবস্থান নির্দিষ্ট করার জন্য একটি স্থান আইডি ব্যবহার করার সময়, একটি স্থান আইডি ব্যবহার করুন যা স্থানটিতে নেভিগেশনের জন্য একটি LatLng অবস্থান নির্ধারণ করার জন্য যথেষ্ট নির্দিষ্ট। উদাহরণস্বরূপ, একটি বিল্ডিং প্রতিনিধিত্বকারী একটি স্থান আইডি উপযুক্ত, কিন্তু একটি রাস্তা প্রতিনিধিত্বকারী একটি স্থান আইডি নিরুৎসাহিত করা হয়।