شاخص
-
RouteOptimization
(رابط) -
AggregatedMetrics
(پیام) -
BatchOptimizeToursMetadata
(پیام) -
BatchOptimizeToursRequest
(پیام) -
BatchOptimizeToursRequest.AsyncModelConfig
(پیام) -
BatchOptimizeToursResponse
(پیام) -
BreakRule
(پیام) -
BreakRule.BreakRequest
(پیام) -
BreakRule.FrequencyConstraint
(پیام) -
DataFormat
(enum) -
DistanceLimit
(پیام) -
GcsDestination
(پیام) -
GcsSource
(پیام) -
InjectedSolutionConstraint
(پیام) -
InjectedSolutionConstraint.ConstraintRelaxation
(پیام) -
InjectedSolutionConstraint.ConstraintRelaxation.Relaxation
(پیام) -
InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level
(enum) -
InputConfig
(پیام) -
Location
(پیام) -
OptimizeToursRequest
(پیام) -
OptimizeToursRequest.SearchMode
(enum) -
OptimizeToursRequest.SolvingMode
(enum) -
OptimizeToursResponse
(پیام) -
OptimizeToursResponse.Metrics
(پیام) -
OptimizeToursValidationError
(پیام) -
OptimizeToursValidationError.FieldReference
(پیام) -
OutputConfig
(پیام) -
RouteModifiers
(پیام) -
Shipment
(پیام) -
Shipment.Load
(پیام) -
Shipment.VisitRequest
(پیام) -
ShipmentModel
(پیام) -
ShipmentModel.DurationDistanceMatrix
(پیام) -
ShipmentModel.DurationDistanceMatrix.Row
(پیام) -
ShipmentModel.PrecedenceRule
(پیام) -
ShipmentRoute
(پیام) -
ShipmentRoute.Break
(پیام) -
ShipmentRoute.EncodedPolyline
(پیام) -
ShipmentRoute.Transition
(پیام) -
ShipmentRoute.VehicleLoad
(پیام) -
ShipmentRoute.Visit
(پیام) -
ShipmentTypeIncompatibility
(پیام) -
ShipmentTypeIncompatibility.IncompatibilityMode
(enum) -
ShipmentTypeRequirement
(پیام) -
ShipmentTypeRequirement.RequirementMode
(enum) -
SkippedShipment
(پیام) -
SkippedShipment.Reason
(پیام) -
SkippedShipment.Reason.Code
(enum) -
TimeWindow
(پیام) -
TransitionAttributes
(پیام) -
Vehicle
(پیام) -
Vehicle.DurationLimit
(پیام) -
Vehicle.LoadLimit
(پیام) -
Vehicle.LoadLimit.Interval
(پیام) -
Vehicle.LoadLimit.LoadCost
(پیام) -
Vehicle.TravelMode
(عدد) -
Vehicle.UnloadingPolicy
(enum) -
Waypoint
(پیام)
بهینه سازی مسیر
خدماتی برای بهینه سازی تورهای خودرو.
اعتبار انواع خاصی از فیلدها:
-
google.protobuf.Timestamp
- زمان ها در زمان یونیکس هستند: ثانیه از 1970-01-01T00:00:00+00:00.
- ثانیه باید در [0, 253402300799]، یعنی در [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] باشد.
- نانو باید تنظیم نشده یا روی 0 تنظیم شود.
-
google.protobuf.Duration
- ثانیه باید در [0, 253402300799]، یعنی در [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00] باشد.
- نانو باید تنظیم نشده یا روی 0 تنظیم شود.
-
google.type.LatLng
- عرض جغرافیایی باید در [-90.0، 90.0] باشد.
- طول جغرافیایی باید در [-180.0، 180.0] باشد.
- حداقل یکی از طول و عرض جغرافیایی باید غیر صفر باشد.
BatchOptimizeTours |
---|
تورهای وسیله نقلیه را برای یک یا چند پیام این روش یک عملیات طولانی مدت (LRO) است. ورودیهای بهینهسازی (پیامهای کاربر می تواند برای بررسی وضعیت LRO از اگر قسمت LRO اگر قسمت
|
OptimizeTours |
---|
یک یک مدل هدف این است که تخصیصی از
|
متریک های جمع شده
معیارهای جمعآوریشده برای ShipmentRoute
(مثلاً برای OptimizeToursResponse
روی همه عناصر Transition
و/یا Visit
(در مقابل همه ShipmentRoute
).
فیلدها | |
---|---|
performed_shipment_count | تعداد محموله های انجام شده توجه داشته باشید که یک جفت تحویل و تحویل فقط یک بار حساب می شود. |
travel_duration | کل مدت سفر برای یک مسیر یا یک راه حل. |
wait_duration | کل مدت زمان انتظار برای یک مسیر یا یک راه حل. |
delay_duration | کل مدت تاخیر برای یک مسیر یا یک راه حل. |
break_duration | کل مدت زمان استراحت برای یک مسیر یا یک راه حل. |
visit_duration | کل مدت زمان بازدید برای یک مسیر یا یک راه حل. |
total_duration | کل مدت زمان باید برابر با مجموع تمام مدت زمان بالا باشد. برای مسیرها نیز با موارد زیر مطابقت دارد:
|
travel_distance_meters | کل مسافت سفر برای یک مسیر یا یک راه حل. |
max_loads | حداکثر بار بهدستآمده در کل مسیر (وظیفه راهحل)، برای هر یک از کمیتهای این مسیر (مشخصات راهحل)، که بهعنوان حداکثر روی همه |
BatchOptimizeToursMetadata
این نوع هیچ فیلدی ندارد.
فراداده عملیات برای تماس های BatchOptimizeToursRequest
.
BatchOptimizeToursRequest
درخواست بهینه سازی دسته ای تورها به عنوان یک عملیات ناهمزمان. هر فایل ورودی باید حاوی یک OptimizeToursRequest
باشد و هر فایل خروجی حاوی یک OptimizeToursResponse
باشد. درخواست حاوی اطلاعاتی برای خواندن/نوشتن و تجزیه فایلها است. تمام فایل های ورودی و خروجی باید تحت یک پروژه باشند.
فیلدها | |
---|---|
parent | مورد نیاز. پروژه و مکان مورد نظر برای برقراری تماس. قالب: * اگر مکانی مشخص نشده باشد، یک منطقه به طور خودکار انتخاب می شود. |
model_configs[] | مورد نیاز. اطلاعات ورودی/خروجی هر مدل خرید، مانند مسیرهای فایل و فرمت های داده. |
AsyncModelConfig
اطلاعاتی برای حل یک مدل بهینه سازی به صورت ناهمزمان.
فیلدها | |
---|---|
display_name | اختیاری. نام مدل تعریف شده توسط کاربر، می تواند به عنوان نام مستعار توسط کاربران برای پیگیری مدل ها استفاده شود. |
input_config | مورد نیاز. اطلاعات مربوط به مدل ورودی |
output_config | مورد نیاز. اطلاعات مکان خروجی مورد نظر |
BatchOptimizeToursResponse
این نوع هیچ فیلدی ندارد.
پاسخ به BatchOptimizeToursRequest
. این در عملیات طولانی مدت پس از اتمام عملیات برگردانده می شود.
BreakRule
قوانینی برای ایجاد وقفه زمانی برای یک وسیله نقلیه (مثلاً استراحت ناهار). استراحت یک دوره زمانی پیوسته است که طی آن وسیله نقلیه در موقعیت فعلی خود بیکار می ماند و نمی تواند هیچ بازدیدی را انجام دهد. وقفه ممکن است رخ دهد:
- در طول سفر بین دو بازدید (که شامل زمان درست قبل یا بعد از بازدید می شود، اما نه در وسط یک بازدید)، در این صورت زمان حمل و نقل مربوطه بین بازدیدها را افزایش می دهد.
- یا قبل از شروع خودرو (ممکن است وسیله نقلیه در وسط یک استراحت استارت نخورد)، در این صورت بر زمان استارت خودرو تأثیری نمی گذارد.
- یا پس از پایان خودرو (همچنین، با زمان پایان خودرو).
فیلدها | |
---|---|
break_requests[] | توالی استراحت. پیام |
frequency_constraints[] | ممکن است چندین |
Break Request
توالی وقفه ها (یعنی تعداد و ترتیب آنها) که برای هر وسیله نقلیه اعمال می شود باید از قبل مشخص باشد. BreakRequest
های مکرر آن توالی را به ترتیبی که باید رخ دهند، تعریف می کنند. پنجرههای زمانی آنها ( earliest_start_time
/ latest_start_time
) ممکن است با هم همپوشانی داشته باشند، اما باید با سفارش سازگار باشند (این مورد بررسی شده است).
فیلدها | |
---|---|
earliest_start_time | مورد نیاز. کران پایین (شامل) در شروع استراحت. |
latest_start_time | مورد نیاز. کران بالا (شامل) در شروع استراحت. |
min_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
ممکن است در عمل برای وقفه های غیر متوالی اعمال شود. به عنوان مثال، برنامه زیر به مثال "1 ساعت هر 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 | مورد نیاز. حداقل مدت زمان استراحت برای این محدودیت. غیر منفی. به توضیحات |
max_inter_break_duration | مورد نیاز. حداکثر بازه مجاز هر بازه زمانی در مسیر که حداقل تا حدی شامل وقفه |
DataFormat
فرمت های داده برای فایل های ورودی و خروجی.
Enums | |
---|---|
DATA_FORMAT_UNSPECIFIED | مقدار نامعتبر است، قالب نباید نامشخص باشد. |
JSON | نشانه گذاری شی جاوا اسکریپت. |
PROTO_TEXT | فرمت متنی بافرهای پروتکل. به https://protobuf.dev/reference/protobuf/textformat-spec/ مراجعه کنید |
محدودیت فاصله
حدی که حداکثر مسافت قابل پیمودن را تعیین می کند. می تواند سخت یا نرم باشد.
اگر یک حد نرم تعریف شده باشد، هم soft_max_meters
و هم cost_per_kilometer_above_soft_max
باید تعریف شده و غیرمنفی باشد.
فیلدها | |
---|---|
max_meters | حد سختی که فاصله را حداکثر حداکثر مکس_متر محدود می کند. حد باید غیرمنفی باشد. |
soft_max_meters | یک حد نرم محدودیت حداکثر فاصله را اعمال نمی کند، اما زمانی که نقض شود منجر به هزینه ای می شود که به هزینه های دیگر تعریف شده در مدل، با همان واحد اضافه می شود. اگر soft_max_meters تعریف شده باید کمتر از max_meters باشد و باید غیرمنفی باشد. |
cost_per_kilometer_below_soft_max | هزینه هر کیلومتر متحمل شده، افزایش تا
این هزینه در |
cost_per_kilometer_above_soft_max | اگر مسافت بالاتر از حد مجاز
هزینه باید غیرمنفی باشد. |
GcsDestination
مکان Google Cloud Storage که فایل(های) خروجی در آن نوشته می شود.
فیلدها | |
---|---|
uri | مورد نیاز. URI Google Cloud Storage. |
منبع Gcs
مکان Google Cloud Storage که فایل ورودی از آنجا خوانده می شود.
فیلدها | |
---|---|
uri | مورد نیاز. URI یک شی Google Cloud Storage با فرمت |
InjectedSolution Constraint
راه حل تزریق شده در درخواست شامل اطلاعاتی در مورد اینکه کدام بازدیدها باید محدود شوند و چگونه باید محدود شوند.
فیلدها | |
---|---|
routes[] | مسیرهای محلول برای تزریق برخی از مسیرها ممکن است از راه حل اصلی حذف شوند. مسیرها و محموله های نادیده گرفته شده باید مفروضات اعتبار اولیه فهرست شده برای |
skipped_shipments[] | محموله های محلول برای تزریق نادیده گرفته شده است. ممکن است برخی از راه حل اصلی حذف شوند. قسمت |
constraint_relaxations[] | برای گروه های صفر یا چند وسیله نقلیه، زمان و میزان کاهش محدودیت ها را مشخص می کند. اگر این فیلد خالی باشد، تمام مسیرهای غیرخالی وسایل نقلیه کاملاً محدود می شوند. |
محدودیت آرامش
برای گروهی از وسایل نقلیه، مشخص میکند که محدودیتهای بازدید در چه آستانهای کاهش مییابند و تا چه سطحی. محموله های فهرست شده در قسمت skipped_shipment
محدود به نادیده گرفتن هستند. یعنی نمی توان آنها را اجرا کرد.
فیلدها | |
---|---|
relaxations[] | تمام محدودیتهای بازدید که برای بازدید از مسیرهایی با وسایل نقلیه در |
vehicle_indices[] | شاخصهای وسیله نقلیه را مشخص میکند که اگر |
آرامش
اگر relaxations
خالی باشد، زمان شروع و ترتیب همه بازدیدها در routes
کاملاً محدود است و هیچ بازدید جدیدی نمی تواند در آن مسیرها درج یا اضافه شود. همچنین، زمان شروع و پایان یک وسیله نقلیه در routes
کاملاً محدود است، مگر اینکه وسیله نقلیه خالی باشد (یعنی هیچ بازدیدی نداشته باشد و در مدل used_if_route_is_empty
روی false تنظیم شده باشد).
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
AND -
route.visits_size() + 1 >= relaxations(i).threshold_visit_count
برای اعمال سطح آرامش، اگر بازدیدی با threshold_visit_count
یا threshold_time
مطابقت داشته باشد، دو relaxations
با همان level
اضافه کنید: یکی با مجموعه فقط threshold_visit_count
و دیگری با تنها threshold_time
تنظیم شده است. اگر یک بازدید شرایط relaxations
متعدد را برآورده کند، آرام ترین سطح اعمال می شود. در نتیجه، از شروع وسیله نقلیه تا بازدیدهای مسیر تا پایان وسیله نقلیه، سطح آرامش بیشتر می شود: یعنی با پیشرفت مسیر، سطح آرامش کاهش نمی یابد.
زمان و توالی بازدیدهای مسیری که شرایط آستانه هر relaxations
را برآورده نمی کند کاملاً محدود است و هیچ بازدیدی ممکن است در این توالی درج نشود. همچنین، اگر شروع یا پایان وسیله نقلیه شرایط آرامش را برآورده نکند، زمان ثابت است، مگر اینکه وسیله نقلیه خالی باشد.
فیلدها | |
---|---|
level | سطح آرامش محدودیت که زمانی اعمال می شود که شرایط در |
threshold_time | زمانی که |
threshold_visit_count | تعداد بازدیدهایی که ممکن است اگر |
سطح
سطوح مختلف آرامش محدودیت را بیان میکند که برای یک بازدید اعمال میشود و آنهایی که پس از آن زمانی که شرایط آستانه را برآورده میکنند، اعمال میشوند.
شمارش زیر به ترتیب افزایش آرامش است.
Enums | |
---|---|
LEVEL_UNSPECIFIED | سطح آرامش پیشفرض ضمنی: هیچ محدودیتی کاهش نمییابد، یعنی همه بازدیدها کاملاً محدود میشوند. این مقدار نباید به صراحت در |
RELAX_VISIT_TIMES_AFTER_THRESHOLD | زمان شروع بازدید و زمان شروع/پایان وسیله نقلیه آرام خواهد بود، اما هر بازدید به همان وسیله نقلیه محدود میشود و توالی بازدید باید رعایت شود: هیچ بازدیدی بین آنها یا قبل از آنها نمیتواند وارد شود. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD | مانند RELAX_VISIT_TIMES_AFTER_THRESHOLD ، اما توالی بازدید نیز آرام است: بازدیدها فقط توسط این وسیله نقلیه قابل انجام است، اما به طور بالقوه ممکن است انجام نشوند. |
RELAX_ALL_AFTER_THRESHOLD | مانند RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD ، اما وسیله نقلیه نیز آرام است: بازدیدها در زمان آستانه یا بعد از آن کاملا رایگان هستند و ممکن است به طور بالقوه انجام نشوند. |
InputConfig
یک ورودی برای [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] مشخص کنید.
فیلدها | |
---|---|
data_format | مورد نیاز. فرمت داده های ورودی |
source میدان اتحادیه مورد نیاز. source می تواند تنها یکی از موارد زیر باشد: | |
gcs_source | یک مکان Google Cloud Storage. این باید یک شی (فایل) واحد باشد. |
مکان
یک مکان (نقطه جغرافیایی و عنوان اختیاری) را در بر می گیرد.
فیلدها | |
---|---|
lat_lng | مختصات جغرافیایی نقطه راه. |
heading | عنوان قطب نما با جهت جریان ترافیک مرتبط است. این مقدار برای تعیین سمت جاده مورد استفاده برای حمل و نقل استفاده می شود. مقادیر سرفصل می تواند از 0 تا 360 باشد، جایی که 0 یک عنوان شمال را مشخص می کند، 90 عنوان یک عنوان شرق و غیره را مشخص می کند. |
OptimizeToursRequest
درخواست به یک حل کننده بهینه سازی تور داده شود که مدل حمل و نقل را برای حل و همچنین پارامترهای بهینه سازی تعریف می کند.
فیلدها | |
---|---|
parent | مورد نیاز. پروژه یا مکان را برای برقراری تماس هدف قرار دهید. قالب: * اگر مکانی مشخص نشده باشد، یک منطقه به طور خودکار انتخاب می شود. |
timeout | اگر این مهلت تنظیم شود، سرور قبل از سپری شدن مدت زمان یا رسیدن به مهلت سرور برای درخواستهای همزمان، هرکدام زودتر، پاسخی را برمیگرداند. برای درخواست های ناهمزمان، سرور یک راه حل (در صورت امکان) را قبل از سپری شدن مهلت ایجاد می کند. |
model | مدل حمل و نقل برای حل. |
solving_mode | به طور پیش فرض، حالت حل |
search_mode | حالت جستجو برای حل درخواست استفاده می شود. |
injected_first_solution_routes[] | الگوریتم بهینه سازی را در یافتن راه حل اول که مشابه راه حل قبلی است، راهنمایی کنید. وقتی اولین راه حل ساخته می شود، مدل محدود می شود. هر محموله ای که در یک مسیر انجام نشده باشد به طور ضمنی در راه حل اول نادیده گرفته می شود، اما ممکن است در راه حل های متوالی انجام شود. راه حل باید برخی از مفروضات اعتبار پایه را برآورده کند:
اگر راه حل تزریق شده امکان پذیر نباشد، یک خطای اعتبار سنجی لزوما برگردانده نمی شود و ممکن است به جای آن خطای نشان دهنده غیرممکن بودن برگردانده شود. |
injected_solution_constraint | الگوریتم بهینه سازی را برای یافتن راه حل نهایی که مشابه راه حل قبلی است محدود کنید. به عنوان مثال، این ممکن است برای مسدود کردن بخشهایی از مسیرهایی که قبلاً تکمیل شدهاند یا باید تکمیل شوند اما نباید اصلاح شوند استفاده شود. اگر راه حل تزریق شده امکان پذیر نباشد، یک خطای اعتبار سنجی لزوما برگردانده نمی شود و ممکن است به جای آن خطای نشان دهنده غیرممکن بودن برگردانده شود. |
refresh_details_routes[] | در صورت خالی نبودن، مسیرهای داده شده بدون تغییر توالی بازدیدها یا زمان سفر، به روز می شوند: فقط سایر جزئیات به روز می شوند. این مدل را حل نمی کند. از سال 2020/11، این فقط چند خطوط مسیرهای غیر خالی را پر می کند و مستلزم آن است که فیلدهای این فیلد نباید همراه با |
interpret_injected_solutions_using_labels | اگر درست باشد:
این تفسیر برای فیلدهای اگر درست باشد، برچسبهای دستههای زیر باید حداکثر یک بار در دسته خود ظاهر شوند:
اگر یک حذف بازدیدهای مسیر یا کل مسیرها از یک راه حل تزریقی ممکن است بر محدودیت های ضمنی تأثیر بگذارد، که ممکن است منجر به تغییر در راه حل، خطاهای اعتبارسنجی یا غیرممکن شود. توجه: تماس گیرنده باید اطمینان حاصل کند که هر |
consider_road_traffic | در محاسبه فیلدهای |
populate_polylines | اگر درست باشد، چند خطوط در پاسخ |
populate_transition_polylines | اگر درست باشد، چند خطوط و نشانههای مسیر در پاسخ |
allow_large_deadline_despite_interruption_risk | اگر این تنظیم شده باشد، درخواست می تواند حداکثر 60 دقیقه مهلت داشته باشد (به https://grpc.io/blog/deadlines مراجعه کنید). در غیر این صورت حداکثر مهلت فقط 30 دقیقه است. توجه داشته باشید که درخواست های طولانی مدت خطر وقفه به طور قابل توجهی بزرگتر (اما هنوز کوچک) دارند. |
use_geodesic_distances | اگر درست باشد، مسافتهای سفر با استفاده از فواصل ژئودزیکی به جای مسافتهای Google Maps و زمان سفر با استفاده از فواصل ژئودزیکی با سرعتی که توسط |
label | برچسبی که ممکن است برای شناسایی این درخواست استفاده شود، در |
geodesic_meters_per_second | وقتی |
max_validation_errors | تعداد خطاهای اعتبارسنجی برگشتی را کوتاه می کند. این خطاها معمولاً به یک بار خطای INVALID_ARGUMENT به عنوان جزئیات خطای BadRequest ( https://cloud.google.com/apis/design/errors#error_details) متصل می شوند، مگر اینکه solving_mode=VALIDATE_ONLY: به قسمت |
حالت جستجو
حالتی که رفتار جستجو را تعریف میکند، تاخیر در مقایسه با کیفیت راهحل را کاهش میدهد. در همه حالت ها، مهلت درخواست جهانی اجرا می شود.
Enums | |
---|---|
SEARCH_MODE_UNSPECIFIED | حالت جستجوی نامشخص، معادل RETURN_FAST . |
RETURN_FAST | پس از یافتن اولین راه حل خوب، جستجو را متوقف کنید. |
CONSUME_ALL_AVAILABLE_TIME | تمام زمان موجود را صرف جستجوی راه حل های بهتر کنید. |
حالت حل
نحوه رسیدگی به درخواست را مشخص می کند. در همه حالتها به جز VALIDATE_ONLY
، اگر درخواست نامعتبر باشد، یک خطای INVALID_REQUEST
دریافت خواهید کرد. به max_validation_errors
مراجعه کنید تا تعداد خطاهای برگشتی را محدود کنید.
Enums | |
---|---|
DEFAULT_SOLVE | مدل را حل کنید. هشدارها ممکن است در [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors] صادر شود. |
VALIDATE_ONLY | فقط مدل را بدون حل آن تأیید می کند: تا آنجا که ممکن است OptimizeToursResponse.validation_errors پر می کند. |
DETECT_SOME_INFEASIBLE_SHIPMENTS | فقط مهم : همه محمولههای غیرممکن به اینجا بازگردانده نمیشوند، بلکه فقط آنهایی که در طول پیش پردازش غیرممکن تشخیص داده میشوند. |
OptimizeToursResponse
پاسخ پس از حل یک مشکل بهینه سازی تور شامل مسیرهایی که هر وسیله نقلیه دنبال می کند، محموله هایی که نادیده گرفته شده اند و هزینه کلی راه حل.
فیلدها | |
---|---|
routes[] | مسیرهای محاسبه شده برای هر وسیله نقلیه؛ مسیر i-ام مربوط به i-امین وسیله نقلیه در مدل است. |
request_label | کپی |
skipped_shipments[] | لیست تمام محمولههای نادیده گرفته شده |
validation_errors[] | فهرستی از تمام خطاهای اعتبار سنجی که توانستیم به طور مستقل شناسایی کنیم. توضیحات "MULTIPLE ERRORS" را برای پیام |
metrics | مدت زمان، مسافت و معیارهای استفاده برای این راه حل. |
معیارها
معیارهای کلی، در همه مسیرها جمع آوری شده است.
فیلدها | |
---|---|
aggregated_route_metrics | در مسیرها جمع شده است. هر متریک مجموع (یا حداکثر، برای بارها) در تمام فیلدهای |
skipped_mandatory_shipment_count | تعداد محموله های اجباری حذف شده |
used_vehicle_count | تعداد وسایل نقلیه استفاده شده توجه: اگر مسیر وسیله نقلیه خالی باشد و |
earliest_vehicle_start_time | اولین زمان شروع برای یک وسیله نقلیه دست دوم، که به عنوان حداقل برای همه وسایل نقلیه استفاده شده در |
latest_vehicle_end_time | آخرین زمان پایان برای یک وسیله نقلیه کارکرده، که به عنوان حداکثر برای همه وسایل نقلیه استفاده شده |
costs | هزینه راه حل، به تفکیک فیلدهای درخواست مربوط به هزینه. کلیدها مسیرهای اولیه هستند، نسبت به ورودی OptimizeToursRequest، به عنوان مثال "model.shipments.pickups.cost"، و مقادیر کل هزینه تولید شده توسط فیلد هزینه مربوطه هستند که در کل راه حل جمع می شوند. به عبارت دیگر، هزینهها ["model.shipments.picups.cost"] مجموع تمام هزینههای برداشت بیش از راهحل است. تمام هزینههای تعریفشده در مدل در اینجا بهجز هزینههای مربوط به TransitionAttributes که فقط به صورت تجمیع شده از سال 2022/01 گزارش شدهاند، در اینجا گزارش میشوند. |
total_cost | هزینه کل راه حل مجموع تمام مقادیر در نقشه هزینه ها. |
OptimizeToursValidationError
خطا یا اخطاری را که هنگام تأیید اعتبار OptimizeToursRequest
با آن مواجه می شود، توصیف می کند.
فیلدها | |
---|---|
code | یک خطای اعتبارسنجی توسط جفت ( فیلدهای زیر این بخش زمینه بیشتری در مورد خطا ارائه می دهند. خطاهای چندگانه : هنگامی که چندین خطا وجود دارد، فرآیند اعتبارسنجی سعی می کند چندین مورد از آنها را خروجی دهد. بسیار شبیه یک کامپایلر، این یک فرآیند ناقص است. برخی از خطاهای اعتبارسنجی "کشنده" خواهند بود، به این معنی که کل فرآیند اعتبار سنجی را متوقف می کنند. این مورد برای خطاهای STABILITY : |
display_name | نام نمایش خطا |
fields[] | زمینه خطا ممکن است شامل 0، 1 (بیشتر اوقات) یا بیشتر فیلد باشد. به عنوان مثال، مراجعه به وسیله نقلیه شماره 4 و اولین پیکاپ محموله شماره 2 را می توان به صورت زیر انجام داد:
البته توجه داشته باشید که کاردینالیته |
error_message | رشته قابل خواندن توسط انسان که خطا را توصیف می کند. یک نگاشت 1:1 بین پایداری : پایدار نیست: پیام خطای مرتبط با |
offending_values | ممکن است حاوی مقدار(های) فیلد(ها) باشد. این همیشه در دسترس نیست. شما مطلقاً نباید به آن تکیه کنید و فقط برای اشکال زدایی مدل دستی از آن استفاده کنید. |
مرجع فیلد
زمینه ای را برای خطای اعتبارسنجی مشخص می کند. یک FieldReference
همیشه به یک فیلد معین در این فایل اشاره دارد و از ساختار سلسله مراتبی یکسانی پیروی می کند. به عنوان مثال، ممکن است عنصر #2 start_time_windows
شماره 5 را با استفاده از:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
با این حال، ما نهادهای سطح بالا مانند OptimizeToursRequest
یا ShipmentModel
را حذف می کنیم تا از شلوغ شدن پیام جلوگیری کنیم.
فیلدها | |
---|---|
name | نام رشته، به عنوان مثال، "وسایل نقلیه". |
sub_field | در صورت نیاز، زیر فیلد تودرتوی بازگشتی. |
فیلد اتحادیه | |
index | فهرست فیلد در صورت تکرار. |
key | اگر فیلد نقشه است، کلید بزنید. |
OutputConfig
مقصدی را برای نتایج [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] مشخص کنید.
فیلدها | |
---|---|
data_format | مورد نیاز. فرمت داده های خروجی |
destination میدان اتحادیه مورد نیاز. destination فقط می تواند یکی از موارد زیر باشد: | |
gcs_destination | مکان Google Cloud Storage برای نوشتن خروجی. |
RouteModifiers
مجموعه ای از شرایط اختیاری را در بر می گیرد تا هنگام محاسبه مسیرهای وسیله نقلیه برآورده شود. این شبیه به RouteModifiers
در Google Maps Platform Routes Preferred API است. ببینید: https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers .
فیلدها | |
---|---|
avoid_tolls | مشخص می کند که آیا در صورت معقول بودن از جاده های عوارضی اجتناب شود یا خیر. اولویت با مسیرهایی است که دارای عوارضی نیستند. فقط برای حالت های سفر موتوری اعمال می شود. |
avoid_highways | مشخص می کند که آیا در صورت لزوم از بزرگراه ها اجتناب شود یا خیر. اولویت با مسیرهای فاقد بزرگراه خواهد بود. فقط برای حالت های سفر موتوری اعمال می شود. |
avoid_ferries | مشخص میکند که آیا در صورت لزوم از کشتیها اجتناب شود یا خیر. اولویت با مسیرهایی است که شامل سفر با کشتی نباشد. فقط برای حالت های سفر موتوری اعمال می شود. |
avoid_indoor | اختیاری. مشخص می کند که آیا از پیمایش در داخل خانه در صورت لزوم اجتناب شود. اولویت به مسیرهایی داده می شود که دارای ناوبری داخلی نیستند. فقط برای حالت سفر |
حمل و نقل
حمل و نقل یک کالا، از یکی از وانت های آن تا یکی از تحویل های آن. برای اینکه حمل و نقل انجام شده در نظر گرفته شود، یک وسیله نقلیه منحصربهفرد باید از یکی از مکانهای وانت خود بازدید کند (و ظرفیت یدکی خود را بر این اساس کاهش دهد)، سپس بعداً از یکی از مکانهای تحویل آن بازدید کند (و بنابراین ظرفیتهای یدکی خود را مجدداً افزایش دهد).
فیلدها | |
---|---|
display_name | نام نمایشی تعریف شده توسط کاربر برای محموله. می تواند حداکثر 63 کاراکتر باشد و ممکن است از نویسه های UTF-8 استفاده کند. |
pickups[] | مجموعه ای از جایگزین های پیکاپ مرتبط با محموله. اگر مشخص نشده باشد، وسیله نقلیه فقط باید از مکان مربوط به تحویل بازدید کند. |
deliveries[] | مجموعه ای از جایگزین های تحویل مرتبط با حمل و نقل. اگر مشخص نشده باشد، وسیله نقلیه فقط باید از مکان مربوط به پیکاپ بازدید کند. |
load_demands | نیازهای بار حمل و نقل (به عنوان مثال وزن، حجم، تعداد پالت ها و غیره). کلیدهای نقشه باید شناسههایی باشند که نوع بار مربوطه را توصیف میکنند و در حالت ایدهآل، واحدها را نیز شامل میشوند. به عنوان مثال: "weight_kg"، "volume_gallons"، "pallet_count"، و غیره. اگر کلید داده شده در نقشه ظاهر نشود، بار مربوطه به عنوان null در نظر گرفته می شود. |
allowed_vehicle_indices[] | مجموعه وسایل نقلیه ای که ممکن است این حمل و نقل را انجام دهند. اگر خالی باشد، همه وسایل نقلیه می توانند آن را انجام دهند. وسایل نقلیه با شاخص آنها در لیست |
costs_per_vehicle[] | هزینه ای را که هنگام تحویل این محموله توسط هر وسیله نقلیه متحمل می شود را مشخص می کند. اگر مشخص شده باشد، باید یکی از این موارد را داشته باشد:
این هزینه ها باید با |
costs_per_vehicle_indices[] | شاخص های وسایل نقلیه ای که |
pickup_to_delivery_absolute_detour_limit | حداکثر زمان انحراف مطلق را در مقایسه با کوتاه ترین مسیر از تحویل گرفتن تا تحویل مشخص می کند. اگر مشخص شده باشد، باید غیرمنفی باشد و محموله باید حداقل شامل یک تحویل و یک تحویل باشد. برای مثال، اجازه دهید t کوتاهترین زمان برای رفتن مستقیم از جایگزین انتخابشده به جایگزین تحویل انتخابشده باشد. سپس تنظیم
اگر هر دو محدودیت نسبی و مطلق در یک محموله مشخص شده باشند، از حد محدودتر برای هر جفت تحویل/تحویل ممکن استفاده می شود. از سال ۲۰۱۷/۲۰۱۰، انحرافها فقط زمانی پشتیبانی میشوند که مدت زمان سفر به وسایل نقلیه بستگی نداشته باشد. |
pickup_to_delivery_time_limit | حداکثر مدت زمان از شروع تحویل تا شروع تحویل یک محموله را مشخص می کند. اگر مشخص شده باشد، باید غیرمنفی باشد و محموله باید حداقل شامل یک تحویل و یک تحویل باشد. این بستگی به این ندارد که کدام گزینه برای تحویل و تحویل انتخاب شده است و نه به سرعت خودرو. این را می توان در کنار حداکثر محدودیت های انحرافی مشخص کرد: راه حل به هر دو مشخصات احترام می گذارد. |
shipment_type | رشته غیر خالی که یک "نوع" را برای این محموله مشخص می کند. از این ویژگی می توان برای تعریف ناسازگاری ها یا الزامات بین با |
label | یک برچسب برای این محموله مشخص می کند. این برچسب در پاسخ در |
ignore | اگر درست است، از این ارسال صرفنظر کنید، اما نادیده گرفتن یک محموله منجر به خطای اعتبار سنجی زمانی می شود که هر نوع نادیده گرفتن محمولهای که در |
penalty_cost | در صورت عدم تکمیل ارسال، این جریمه به هزینه کلی مسیرها اضافه می شود. در صورت بازدید از یکی از گزینه های تحویل و تحویل، یک محموله تکمیل شده تلقی می شود. هزینه ممکن است در همان واحد مورد استفاده برای سایر زمینه های مربوط به هزینه در مدل بیان شود و باید مثبت باشد. مهم : اگر این جریمه مشخص نشده باشد، بی نهایت در نظر گرفته می شود، یعنی حمل و نقل باید تکمیل شود. |
pickup_to_delivery_relative_detour_limit | حداکثر زمان انحراف نسبی را در مقایسه با کوتاه ترین مسیر از تحویل گرفتن تا تحویل مشخص می کند. اگر مشخص شده باشد، باید غیرمنفی باشد و محموله باید حداقل شامل یک تحویل و یک تحویل باشد. برای مثال، اجازه دهید t کوتاهترین زمان برای رفتن مستقیم از جایگزین انتخابشده به جایگزین تحویل انتخابشده باشد. سپس تنظیم
اگر هر دو محدودیت نسبی و مطلق در یک محموله مشخص شده باشند، از حد محدودتر برای هر جفت تحویل/تحویل ممکن استفاده می شود. از سال ۲۰۱۷/۲۰۱۰، انحرافها فقط زمانی پشتیبانی میشوند که مدت زمان سفر به وسایل نقلیه بستگی نداشته باشد. |
بارگذاری کنید
هنگام انجام یک بازدید، ممکن است مقداری از پیش تعریف شده به بار خودرو اضافه شود، اگر حمل و نقل باشد، یا در صورت تحویل از آن کم شود. این پیام چنین مقداری را تعریف می کند. load_demands
ببینید.
فیلدها | |
---|---|
amount | مقدار بار وسیله نقلیه ای که بازدید مربوطه را انجام می دهد متفاوت است. از آنجایی که یک عدد صحیح است، به کاربران توصیه می شود یک واحد مناسب را برای جلوگیری از افت دقت انتخاب کنند. باید ≥ 0 باشد. |
VisitRequest
درخواست بازدید که می تواند توسط یک وسیله نقلیه انجام شود: دارای یک موقعیت جغرافیایی (یا دو مورد، در زیر)، زمان باز و بسته شدن که توسط پنجره های زمانی نشان داده شده است، و مدت زمان سرویس (زمان صرف شده توسط وسیله نقلیه پس از رسیدن آن) برای تحویل گرفتن یا تحویل کالا).
فیلدها | |
---|---|
arrival_location | مکان جغرافیایی که وسیله نقلیه هنگام انجام این |
arrival_waypoint | نقطه ای که وسیله نقلیه هنگام انجام این |
departure_location | موقعیت جغرافیایی که وسیله نقلیه پس از تکمیل این |
departure_waypoint | نقطه ای که وسیله نقلیه پس از تکمیل این |
tags[] | برچسب های پیوست شده به درخواست بازدید را مشخص می کند. رشته های خالی یا تکراری مجاز نیستند. |
time_windows[] | پنجره های زمانی که زمان ورود را در یک بازدید محدود می کند. توجه داشته باشید که یک وسیله نقلیه ممکن است خارج از پنجره زمان رسیدن حرکت کند، یعنی زمان ورود + مدت زمان لازم نیست در یک پنجره زمانی باشد. اگر وسیله نقلیه قبل از عدم وجود پنجره های زمانی باید از هم گسسته باشند، یعنی هیچ پنجره زمانی نباید با دیگری همپوشانی داشته باشد یا در مجاورت آن قرار گیرد و باید به ترتیب افزایشی باشند. |
duration | مدت زمان بازدید، یعنی مدت زمان صرف شده توسط وسیله نقلیه بین ورود و خروج (برای افزودن به زمان انتظار احتمالی؛ به |
cost | هزینه سرویس این درخواست بازدید در مسیر وسیله نقلیه. این می تواند برای پرداخت هزینه های مختلف برای هر بار تحویل یا تحویل یک محموله استفاده شود. این هزینه باید همان واحد |
load_demands | بارگیری تقاضاهای این درخواست بازدید. این درست مانند فیلد |
visit_types[] | انواع بازدید را مشخص می کند. این ممکن است برای اختصاص زمان اضافی مورد نیاز برای یک وسیله نقلیه برای تکمیل این بازدید استفاده شود (به یک نوع فقط یک بار می تواند ظاهر شود. |
label | یک برچسب برای این |
مدل حمل و نقل
یک مدل حمل و نقل شامل مجموعهای از محمولهها است که باید توسط مجموعهای از وسایل نقلیه انجام شود، در حالی که هزینه کلی را به حداقل میرساند که مجموع موارد زیر است:
- هزینه مسیریابی وسایل نقلیه (مبلغ هزینه در کل زمان ، هزینه در هر زمان سفر و هزینه ثابت در تمام وسایل نقلیه).
- مجازات های حمل و نقل بدون عملکرد.
- هزینه مدت جهانی محموله ها
فیلدها | |
---|---|
shipments[] | مجموعه محموله هایی که باید در مدل انجام شود. |
vehicles[] | مجموعه ای از وسایل نقلیه که می توانند برای انجام بازدیدها استفاده شوند. |
global_start_time | زمان شروع و پایان جهانی مدل: هیچ بار خارج از این محدوده نمی تواند معتبر تلقی شود. مدت زمان مدل باید کمتر از یک سال باشد ، یعنی هنگام استفاده از زمینه های |
global_end_time | اگر UNET ، 00:00:00 UTC ، 1 ژانویه 1971 (یعنی ثانیه: 31536000 ، نانو: 0) به عنوان پیش فرض استفاده می شود. |
global_duration_cost_per_hour | "مدت زمان جهانی" برنامه کلی ، تفاوت بین اولین زمان شروع موثر و آخرین زمان پایان مؤثر همه وسایل نقلیه است. به عنوان مثال کاربران می توانند در هر ساعت هزینه ای را به آن مقدار اختصاص دهند تا به عنوان مثال برای اتمام کار زودرس و بهینه سازی کنند. این هزینه باید در همان واحد |
duration_distance_matrices[] | مدت زمان و ماتریس فاصله مورد استفاده در مدل را مشخص می کند. اگر این قسمت خالی باشد ، بسته به مقدار قسمت نمونه های استفاده:
|
duration_distance_matrix_src_tags[] | برچسب های تعریف منابع ماتریس مدت زمان و فاصله. برچسب ها با |
duration_distance_matrix_dst_tags[] | برچسب های تعیین کننده مقصد ماتریس مدت زمان و فاصله. برچسب ها با |
transition_attributes[] | ویژگی های انتقال به مدل اضافه شده است. |
shipment_type_incompatibilities[] | مجموعه ای از حمل و نقل ناسازگار_تایپ (به |
shipment_type_requirements[] | مجموعه ای از الزامات |
precedence_rules[] | مجموعه ای از قوانین تقدم که باید در مدل اجرا شود. |
max_active_vehicles | حداکثر تعداد وسایل نقلیه فعال را محدود می کند. اگر مسیر آن حداقل یک محموله انجام شود ، وسیله نقلیه فعال است. این می تواند برای محدود کردن تعداد مسیرها در مواردی که رانندگان کمتری نسبت به وسایل نقلیه وجود دارد استفاده شود و ناوگان وسایل نقلیه ناهمگن باشد. بهینه سازی سپس بهترین زیر مجموعه وسایل نقلیه را برای استفاده انتخاب می کند. باید کاملاً مثبت باشد. |
مدت زمان بندی
ماتریس مدت زمان و مسافت را از مکان های بازدید و شروع وسایل نقلیه برای بازدید و مکان های انتهای وسیله نقلیه مشخص می کند.
فیلدها | |
---|---|
rows[] | ردیف های ماتریس مدت زمان و فاصله را مشخص می کند. این باید به عنوان عناصر زیادی به عنوان |
vehicle_start_tag | تگ تعریف می کند که در این ماتریس مدت زمان و مسافت از وسایل نقلیه استفاده می شود. اگر خالی باشد ، این در مورد همه وسایل نقلیه صدق می کند ، و فقط یک ماتریس واحد وجود دارد. هر شروع وسیله نقلیه باید دقیقاً با یک ماتریس مطابقت داشته باشد ، یعنی دقیقاً یکی از قسمت همه ماتریس ها باید یک |
ردیف
یک ردیف از ماتریس مدت زمان و فاصله را مشخص می کند.
فیلدها | |
---|---|
durations[] | مقادیر مدت زمان برای یک ردیف معین. این باید به عنوان عناصر زیادی به عنوان |
meters[] | مقادیر فاصله برای یک ردیف معین. اگر هیچ هزینه یا محدودیتی به مسافت های مدل اشاره داشته باشد ، این می تواند خالی بماند. در غیر این صورت باید به اندازه |
پیشگام
یک قانون تقدم بین دو رویداد (هر رویداد وانت یا تحویل حمل و نقل است): رویداد "دوم" باید offset_duration
پس از شروع "اول" حداقل شروع به کار کند.
چندین سابقه می تواند به همان وقایع (یا مرتبط) مربوط باشد ، به عنوان مثال ، "وانت B پس از تحویل" و "وانت C اتفاق می افتد که پس از وانت B" اتفاق می افتد.
علاوه بر این ، مقدمات فقط در صورت انجام هر دو محموله اعمال می شود و در غیر این صورت نادیده گرفته می شوند.
فیلدها | |
---|---|
first_is_delivery | نشان می دهد که آیا رویداد "اول" تحویل است. |
second_is_delivery | نشان می دهد که آیا رویداد "دوم" تحویل است. |
offset_duration | جبران بین رویداد "اول" و "دوم". می تواند منفی باشد. |
first_index | شاخص حمل و نقل رویداد "اولین". این فیلد باید مشخص شود. |
second_index | شاخص حمل و نقل رویداد "دوم". این فیلد باید مشخص شود. |
حمل و نقل
مسیر وسیله نقلیه را می توان تجزیه کرد ، در طول محور زمان ، مانند این (فرض می کنیم تعداد بازدیدی وجود دارد):
| | | | | 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+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
سرانجام ، در اینجا نحوه سفر ، استراحت ، تأخیر و انتظار می تواند در طول انتقال ترتیب داده شود.
- آنها با هم تداخل ندارند.
- تأخیر منحصر به فرد است و باید یک دوره متناوب درست قبل از بازدید بعدی (یا پایان وسیله نقلیه) باشد. بنابراین ، دانستن مدت زمان تأخیر برای دانستن زمان شروع و پایان آن کافی است.
- استراحت ها دوره های متناقض و غیر همپوشانی هستند. پاسخ زمان و مدت زمان شروع هر استراحت را مشخص می کند.
- مسافرت و انتظار "قابل حمل" است: در طی این انتقال می توان چندین بار قطع شد. مشتریان می توانند فرض کنند که سفر "در اسرع وقت" اتفاق می افتد و "صبر کنید" زمان باقی مانده را پر می کند.
مثال (پیچیده):
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 | وسیله نقلیه ای که مسیر را انجام می دهد ، که توسط شاخص آن در Source |
vehicle_label | در صورت مشخص شدن ، برچسب وسیله نقلیه ای که این مسیر را انجام می دهد ، برابر با |
vehicle_start_time | زمانی که وسیله نقلیه مسیر خود را شروع می کند. |
vehicle_end_time | زمانی که وسیله نقلیه مسیر خود را تمام می کند. |
visits[] | دنباله سفارش داده شده از بازدیدهای یک مسیر. بازدیدها [i] بازدید I-Th در مسیر است. اگر این میدان خالی باشد ، وسیله نقلیه به عنوان استفاده نشده در نظر گرفته می شود. |
transitions[] | لیست سفارش داده شده برای مسیر. |
has_traffic_infeasibilities | هنگامی که
ورود به Next_visit احتمالاً دیرتر از پنجره زمانی فعلی خود به دلیل افزایش برآورد زمان سفر |
route_polyline | بازنمایی پلی خطی رمزگذاری شده از مسیر. این قسمت فقط در صورتی جمع می شود که |
breaks[] | استراحت برنامه ریزی شده برای وسیله نقلیه در حال انجام این مسیر. دنباله |
metrics | مدت زمان ، فاصله و معیارهای بار برای این مسیر. زمینه های جمع آوری شده در کلیه |
route_costs | هزینه مسیر ، توسط زمینه های درخواست مربوط به هزینه تقسیم می شود. کلیدها مسیرهای پروتئین هستند ، نسبت به ورودی OptimizetoursRequest ، به عنوان مثال "model.shipments.pickups.cost" ، و مقادیر کل هزینه تولید شده توسط میدان هزینه مربوطه است که در کل مسیر جمع می شوند. به عبارت دیگر ، هزینه ها ["model.shipments.pickups.cost"] مجموع هزینه های وانت در مسیر است. تمام هزینه های تعریف شده در مدل در اینجا به استثنای هزینه های مربوط به انتقال attributes که فقط از سال 2022/01 گزارش می شوند ، به تفصیل گزارش شده است. |
route_total_cost | هزینه کل مسیر. مجموع هزینه های موجود در نقشه هزینه. |
شکستن
داده های نمایانگر اجرای یک استراحت.
فیلدها | |
---|---|
start_time | زمان شروع استراحت. |
duration | مدت زمان استراحت. |
رمز رمز
بازنمایی رمزگذاری شده یک پلی خط. اطلاعات بیشتر در مورد رمزگذاری پلیلین را می توان در اینجا یافت: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://develops.google.com/maps/documentation/javascript/reference/geometry.encoding .
فیلدها | |
---|---|
points | رشته نمایانگر نقاط رمزگذاری شده پلی خط. |
انتقال
انتقال بین دو رویداد در مسیر. توضیحات مربوط به ShipmentRoute
را ببینید.
اگر وسیله نقلیه دارای start_location
و/یا end_location
نباشد ، معیارهای سفر مربوطه 0 است.
فیلدها | |
---|---|
travel_duration | مدت زمان سفر در طول این انتقال. |
travel_distance_meters | مسافت طی شده در طول انتقال. |
traffic_info_unavailable | هنگامی که ترافیک از طریق |
delay_duration | مجموع مدت زمان تأخیر در این انتقال اعمال می شود. در صورت وجود ، تأخیر دقیقاً |
break_duration | در صورت وجود ، مجموع مدت زمان وقفه هایی که در طول این انتقال رخ می دهد. جزئیات مربوط به زمان و مدت زمان شروع هر شکست |
wait_duration | زمان صرف انتظار در طول این انتقال. مدت زمان انتظار با زمان بیکار مطابقت دارد و شامل زمان شکستن نیست. همچنین توجه داشته باشید که این زمان انتظار ممکن است به چندین فواصل غیر مبهم تقسیم شود. |
total_duration | مدت زمان انتقال ، برای راحتی فراهم شده است. برابر است با:
|
start_time | زمان شروع این انتقال. |
route_polyline | بازنمایی پلی خطی رمزگذاری شده از مسیر که در طول انتقال دنبال می شود. این قسمت فقط در صورتی جمع می شود که |
route_token | فقط خروجی یک نشانه مات که می تواند برای بازسازی مسیر در حین ناوبری به SDK ناوبری منتقل شود ، و در صورت تجدید نظر ، هنگام ایجاد مسیر ، به قصد اصلی احترام می گذارد. این نشانه را به عنوان حباب مات درمان کنید. ارزش آن را در بین درخواست ها مقایسه نکنید زیرا ممکن است ارزش آن تغییر کند حتی اگر سرویس دقیقاً همان مسیر را برگرداند. این قسمت فقط در صورتی جمع می شود که |
vehicle_loads | در طی این انتقال ، برای هر نوع که در این وسیله نقلیه ظاهر می شود ، بار خودرو را بارهای خودرو می کند بارها در اولین انتقال بارهای شروع مسیر وسیله نقلیه است. سپس ، پس از هر بازدید ، بسته به اینکه این بازدید وانت یا |
بارگیری وسایل نقلیه
گزارش بار واقعی وسیله نقلیه در مقطعی در طول مسیر ، برای یک نوع معین (به Transition.vehicle_loads
مراجعه کنید).
فیلدها | |
---|---|
amount | مقدار بار در وسیله نقلیه ، برای نوع داده شده. واحد بار معمولاً توسط نوع نشان داده می شود. به |
بازدید کنید
بازدیدی که در طی یک مسیر انجام شد. این بازدید مربوط به وانت یا تحویل Shipment
است.
فیلدها | |
---|---|
shipment_index | فهرست زمینه |
is_pickup | در صورت صحت این دیدار با وانت |
visit_request_index | فهرست |
start_time | زمانی که بازدید از آن شروع می شود. توجه داشته باشید که وسیله نقلیه ممکن است زودتر از این در محل بازدید وارد شود. بارها با |
load_demands | کل تقاضای بار بازدید به عنوان مبلغ حمل و نقل و درخواست بازدید |
detour | زمان دفع اضافی به دلیل محموله های بازدید شده در مسیر قبل از بازدید و زمان احتمالی انتظار ناشی از ویندوزهای زمان. اگر این بازدید تحویل باشد ، دفع از وانت مربوطه محاسبه می شود و برابر است با:
در غیر این صورت ، آن را از
|
shipment_label | کپی از |
visit_label | در صورت مشخص شدن در |
قابلیت سازگاری حمل و نقل
بسته به نوع حمل و نقل آنها ، ناسازگاری بین محموله ها را مشخص می کند. ظاهر محموله های ناسازگار در همان مسیر بر اساس حالت ناسازگاری محدود می شود.
فیلدها | |
---|---|
types[] | لیست انواع ناسازگار. دو محموله دارای |
incompatibility_mode | حالت برای ناسازگاری اعمال می شود. |
نامطلوب
حالت هایی که چگونگی محدود شدن ظاهر محموله های ناسازگار در همان مسیر را تعریف می کنند.
Enums | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED | حالت ناسازگاری نامشخص. این مقدار هرگز نباید استفاده شود. |
NOT_PERFORMED_BY_SAME_VEHICLE | در این حالت ، دو محموله با انواع ناسازگار هرگز نمی توانند همان وسیله نقلیه را به اشتراک بگذارند. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY | برای دو محموله با انواع ناسازگار با
|
حمل و نقل
الزامات بین محموله ها را بر اساس حمل و نقل_تایپ آنها مشخص می کند. مشخصات مورد نیاز توسط حالت مورد نیاز تعریف شده است.
فیلدها | |
---|---|
required_shipment_type_alternatives[] | لیست انواع حمل و نقل جایگزین مورد نیاز توسط |
dependent_shipment_types[] | کلیه محموله ها با یک نوع در قسمت توجه: زنجیره های مورد نیاز به گونه ای که یک |
requirement_mode | حالت اعمال شده برای نیاز. |
روش
حالت هایی که ظاهر محموله های وابسته را در یک مسیر تعریف می کنند.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED | حالت مورد نیاز نامشخص. این مقدار هرگز نباید استفاده شود. |
PERFORMED_BY_SAME_VEHICLE | در این حالت ، کلیه محموله های "وابسته" باید حداقل وسیله نقلیه حداقل یکی از محموله های "مورد نیاز" خود را به اشتراک بگذارند. |
IN_SAME_VEHICLE_AT_PICKUP_TIME | با استفاده از حالت وانت حمل و نقل "وابسته" بنابراین باید داشته باشد:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME | مانند گذشته ، به جز محموله های "وابسته" باید در زمان تحویل خود حمل و نقل "مورد نیاز" را بر روی وسیله نقلیه خود داشته باشند. |
تحصیل
جزئیات محموله های بدون عملکرد را در یک راه حل مشخص می کند. برای موارد بی اهمیت و/یا اگر قادر به شناسایی علت پرش هستیم ، دلیل را در اینجا گزارش می دهیم.
فیلدها | |
---|---|
index | این شاخص مطابق با شاخص حمل و نقل در منبع |
label | کپی از |
reasons[] | لیستی از دلایلی که توضیح می دهد چرا این محموله رد شد. |
دلیل
اگر بتوانیم توضیح دهیم که چرا حمل و نقل از بین رفته است ، دلایل در اینجا ذکر می شود. اگر دلیل برای همه وسایل نقلیه یکسان نباشد ، 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 | به نظرات کد مراجعه کنید. |
example_exceeded_capacity_type | اگر دلیل کد |
example_vehicle_index | اگر دلیل آن مربوط به ناسازگاری یک وسیله نقلیه حمل و نقل باشد ، این زمینه شاخص یک وسیله نقلیه مربوطه را فراهم می کند. |
کد
کد شناسایی نوع دلیل. سفارش در اینجا بی معنی است. به طور خاص ، در صورت اعمال هر دو ، هیچ نشانه ای از اینكه آیا دلیل مشخصی در راه حل ظاهر خواهد شد.
Enums | |
---|---|
CODE_UNSPECIFIED | این هرگز نباید استفاده شود. |
NO_VEHICLE | هیچ وسیله نقلیه در مدل وجود ندارد که همه محموله ها را غیرقابل نفوذ کند. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY | تقاضای حمل و نقل از ظرفیت وسیله نقلیه برای برخی از انواع ظرفیت فراتر می رود که یکی از آنها example_exceeded_capacity_type است. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT | حداقل مسافت لازم برای انجام این محموله ، یعنی از توجه داشته باشید که برای این محاسبه از مسافت های ژئودزیکی استفاده می کنیم. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT | حداقل زمان لازم برای انجام این محموله ، از جمله زمان سفر ، زمان انتظار و زمان خدمات بیش از توجه: زمان سفر در بهترین سناریو محاسبه می شود ، یعنی فاصله ژئودزیک x 36 متر بر ثانیه (تقریباً 130 کیلومتر در ساعت). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT | همانند بالا ، اما ما فقط حداقل زمان سفر و travel_duration_limit وسیله نقلیه_دوراسیون_یمیت را مقایسه می کنیم. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS | وسیله نقلیه نمی تواند این محموله را در سناریوی بهترین حالت انجام دهد (به CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT برای محاسبه زمان مراجعه کنید) اگر در اولین زمان شروع خود شروع شود: زمان کل باعث می شود که وسیله نقلیه پس از آخرین زمان پایان خود پایان یابد. |
VEHICLE_NOT_ALLOWED | میدان allowed_vehicle_indices حمل و نقل خالی نیست و این وسیله نقلیه متعلق به آن نیست. |
پنجره زمانی
Windows Time زمان یک رویداد را محدود می کند ، مانند زمان ورود در یک بازدید یا زمان شروع و پایان یک وسیله نقلیه.
محدودیت های پنجره زمان سخت ، start_time
و end_time
، اولین و آخرین زمان رویداد را اجرا کنید ، به گونه ای که start_time <= event_time <= end_time
. پنجره زمان نرم محدود ، soft_start_time
، ترجیح می دهد این رویداد در یا بعد از soft_start_time
اتفاق بیفتد و با تحمل هزینه متناسب با چه مدت قبل از SOFT_START_TIME اتفاق بیفتد. پنجره زمانی نرم که دارای قسمت بالایی ، soft_end_time
است ، ترجیح می دهد این رویداد در یا قبل از soft_end_time
اتفاق بیفتد و با تحمل هزینه متناسب با چه مدت بعد از soft_end_time
اتفاق بیفتد. start_time
، end_time
، soft_start_time
و soft_end_time
باید در محدوده زمان جهانی باشد (به ShipmentModel.global_start_time
و ShipmentModel.global_end_time
مراجعه کنید) و باید احترام بگذارید:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
فیلدها | |
---|---|
start_time | زمان شروع پنجره زمان سخت. اگر نامشخص باشد ، آن را به |
end_time | زمان پایان پنجره زمان سخت. اگر نامشخص باشد ، آن را به |
soft_start_time | زمان شروع نرم پنجره زمان. |
soft_end_time | زمان پایان نرم پنجره زمان. |
cost_per_hour_before_soft_start_time | در صورت وقوع این رویداد قبل از soft_start_time ، هزینه ای در هر ساعت به سایر هزینه ها اضافه می شود ، محاسبه می شود:
این هزینه باید مثبت باشد و در صورت تنظیم SOFT_START_TIME ، می توان آن را تنظیم کرد. |
cost_per_hour_after_soft_end_time | در صورت وقوع این رویداد پس از
این هزینه باید مثبت باشد و در صورت تنظیم |
انتقال
ویژگی های انتقال بین دو بازدید متوالی در یک مسیر را مشخص می کند. چندین TransitionAttributes
ممکن است برای همان انتقال اعمال شود: در این حالت ، تمام هزینه های اضافی اضافه می شوند و سخت ترین محدودیت یا حد اعمال می شود (به دنبال معناشناسی طبیعی "و" معناشناسی).
فیلدها | |
---|---|
src_tag | برچسب هایی که مجموعه ای از انتقال (SRC-> DST) را تعیین می کند ، این ویژگی ها به آن اعمال می شود. بازدید از منبع یا شروع وسیله نقلیه در صورت بازدید از |
excluded_src_tag | |
dst_tag | بازدید از مقصد یا پایان خودرو مطابقت دارد اگر |
excluded_dst_tag | به |
cost | هزینه ای را برای انجام این انتقال مشخص می کند. این در همان واحد مانند سایر هزینه های مدل است و نباید منفی باشد. در بالای تمام هزینه های موجود دیگر اعمال می شود. |
cost_per_kilometer | هزینه ای را برای هر کیلومتر اعمال شده برای مسافت طی شده هنگام انجام این انتقال مشخص می کند. این به هر |
distance_limit | محدودیت در مسافت طی شده هنگام انجام این انتقال را مشخص می کند. از سال 2021/06 ، فقط از محدودیت های نرم پشتیبانی می شود. |
delay | تأخیر ناشی از انجام این انتقال را مشخص می کند. این تأخیر همیشه پس از اتمام بازدید منبع و قبل از شروع بازدید از مقصد اتفاق می افتد. |
وسیله نقلیه
یک وسیله نقلیه را در مشکل حمل و نقل مدل می کند. حل یک مشکل حمل و نقل مسیری را که از start_location
شروع می شود و به پایان می رسد در end_location
برای این وسیله نقلیه ساخته می شود. یک مسیر دنباله ای از بازدیدها است (به ShipmentRoute
مراجعه کنید).
فیلدها | |
---|---|
display_name | نام نمایشگر تعریف شده توسط کاربر. این می تواند تا 63 کاراکتر طول داشته باشد و ممکن است از شخصیت های UTF-8 استفاده کند. |
travel_mode | حالت سفر که بر جاده های قابل استفاده توسط وسیله نقلیه و سرعت آن تأثیر می گذارد. همچنین به |
route_modifiers | مجموعه ای از شرایط برای برآورده کردن تأثیرگذاری بر نحوه محاسبه مسیرها برای وسیله نقلیه داده شده. |
start_location | موقعیت جغرافیایی که در آن وسیله نقلیه قبل از انتخاب هرگونه محموله شروع می شود. اگر مشخص نشده باشد ، وسیله نقلیه در اولین وانت خود شروع می شود. اگر مدل حمل و نقل دارای ماتریس مدت و فاصله باشد ، |
start_waypoint | Waypoint نمایانگر یک مکان جغرافیایی است که در آن وسیله نقلیه قبل از انتخاب هرگونه محموله شروع می شود. اگر نه |
end_location | موقعیت جغرافیایی که پس از اتمام آخرین |
end_waypoint | Waypoint نمایانگر یک مکان جغرافیایی است که وسیله نقلیه پس از اتمام آخرین |
start_tags[] | برچسب های متصل به شروع مسیر وسیله نقلیه را مشخص می کند. رشته های خالی یا کپی مجاز نیستند. |
end_tags[] | برچسب های متصل به انتهای مسیر وسیله نقلیه را مشخص می کند. رشته های خالی یا کپی مجاز نیستند. |
start_time_windows[] | ویندوزهای زمانی که در طی آن وسیله نقلیه ممکن است محل شروع خود را ترک کند. آنها باید در محدوده زمان جهانی باشند (به زمینه های ویندوزهای زمانی متعلق به همان زمینه مکرر باید از هم جدا شوند ، یعنی هیچ پنجره زمانی نمی تواند با دیگری همپوشانی داشته باشد یا در مجاورت دیگری باشد و باید به ترتیب زمانی باشد. |
end_time_windows[] | ویندوزهای زمانی که در طی آن وسیله نقلیه ممکن است به محل انتها برسد. آنها باید در محدوده زمان جهانی باشند (به زمینه های ویندوزهای زمانی متعلق به همان زمینه مکرر باید از هم جدا شوند ، یعنی هیچ پنجره زمانی نمی تواند با دیگری همپوشانی داشته باشد یا در مجاورت دیگری باشد و باید به ترتیب زمانی باشد. |
unloading_policy | خط مشی تخلیه شده روی وسیله نقلیه. |
load_limits | ظرفیت وسیله نقلیه (وزن ، حجم ، # پالت به عنوان مثال). کلیدهای موجود در نقشه شناسه های نوع بار هستند ، مطابق با کلیدهای قسمت |
cost_per_hour | هزینه های وسیله نقلیه: تمام هزینه ها اضافه می شوند و باید در واحد هزینه در هر ساعت مسیر وسیله نقلیه. این هزینه برای کل زمان که در طول مسیر گرفته شده اعمال می شود و شامل زمان سفر ، زمان انتظار و زمان بازدید است. استفاده از |
cost_per_traveled_hour | هزینه هر ساعت سفر از مسیر وسیله نقلیه. این هزینه فقط برای زمان سفر گرفته شده توسط مسیر (یعنی گزارش شده در |
cost_per_kilometer | هزینه هر کیلومتر مسیر وسیله نقلیه. این هزینه برای مسافت گزارش |
fixed_cost | در صورت استفاده از این وسیله نقلیه برای رسیدگی به محموله ، هزینه ثابت اعمال می شود. |
used_if_route_is_empty | این زمینه فقط در مورد وسایل نقلیه اعمال می شود که مسیر آنها در خدمت هیچ محموله ای نباشد. این نشان می دهد که آیا وسیله نقلیه باید در این مورد استفاده شود یا خیر. اگر درست باشد ، وسیله نقلیه از شروع خود به محل پایان خود می رود حتی اگر در خدمت هیچ محموله ای نباشد ، و هزینه های زمان و مسافت ناشی از شروع آن -> سفر پایان در نظر گرفته می شود. در غیر این صورت ، از شروع آن به محل پایان خود سفر نمی کند ، و هیچ |
route_duration_limit | حد اعمال شده در کل مدت زمان مسیر وسیله نقلیه. در |
travel_duration_limit | محدودیت اعمال شده در طول سفر مسیر وسیله نقلیه. در یک |
route_distance_limit | حد اعمال شده در فاصله کل مسیر وسیله نقلیه. در یک |
extra_visit_duration_for_visit_type | نقشه ای را از رشته های بازدید_ types گرفته تا مدت زمان مشخص می کند. مدت زمان علاوه بر اگر درخواست بازدید از انواع مختلفی داشته باشد ، مدت زمان دیگری برای هر نوع نقشه اضافه می شود. |
break_rule | برنامه شکست را که باید در این وسیله نقلیه اجرا شود ، توصیف می کند. در صورت خالی بودن ، هیچ گونه استراحت برای این وسیله نقلیه برنامه ریزی نشده است. |
label | برچسب این وسیله نقلیه را مشخص می کند. این برچسب در پاسخ به عنوان |
ignore | در صورت صحت ، اگر یک حمل و نقل توسط یک وسیله نقلیه نادیده گرفته شده در اگر یک حمل و نقل توسط یک وسیله نقلیه نادیده گرفته شده در |
travel_duration_multiple | یک عامل چند برابر را مشخص می کند که می تواند برای افزایش یا کاهش زمان سفر این وسیله نقلیه استفاده شود. به عنوان مثال ، تنظیم این در 2.0 به این معنی است که این وسیله نقلیه کندتر است و زمان سفر دارد که دو برابر آن برای وسایل نقلیه استاندارد است. این چند بر مدت بازدید تأثیر نمی گذارد. اگر هشدار: زمان سفر به نزدیکترین دوم پس از استفاده از این چند برابر ، اما قبل از انجام هرگونه عملیات عددی ، به نزدیکترین ثانیه گرد می شود ، بنابراین ، یک ضرب کوچک ممکن است منجر به از بین رفتن دقت شود. همچنین در زیر |
مدت زمان طولانی
محدودیتی که حداکثر مدت زمان مسیر یک وسیله نقلیه را تعیین می کند. این می تواند سخت یا نرم باشد.
هنگامی که یک میدان حد نرم تعریف شده است ، هم آستانه حداکثر حداکثر و هزینه مرتبط با آن باید با هم تعریف شود.
فیلدها | |
---|---|
max_duration | محدودیت سخت محدود کردن مدت زمان حداکثر max_duration. |
soft_max_duration | حد نرم که حداکثر حد مجاز را اجرا نمی کند ، اما در صورت نقض ، مسیر را متحمل می شود. این هزینه به سایر هزینه های تعریف شده در مدل ، با همان واحد اضافه می کند. در صورت تعریف ، |
quadratic_soft_max_duration | یک حد نرم که حداکثر حد طول را اجرا نمی کند ، اما در صورت نقض ، مسیر را متحمل می شود ، در مدت زمان ، درجه دوم است. این هزینه به سایر هزینه های تعریف شده در مدل ، با همان واحد اضافه می کند. در صورت تعریف ، |
cost_per_hour_after_soft_max | در صورت نقض آستانه
هزینه باید غیر منفی باشد. |
cost_per_square_hour_after_quadratic_soft_max | در صورت نقض آستانه اگر مدت زمان زیر آستانه باشد ، هزینه اضافی 0 است ، در غیر این صورت هزینه به مدت زیر بستگی دارد:
هزینه باید غیر منفی باشد. |
بارداری
محدودیت بار اعمال شده به وسیله نقلیه را تعریف می کند ، به عنوان مثال "این کامیون فقط 3500 کیلوگرم حمل می کند". load_limits
ببینید.
فیلدها | |
---|---|
soft_max_load | A soft limit of the load. See |
cost_per_unit_above_soft_max | If the load ever exceeds |
start_load_interval | The acceptable load interval of the vehicle at the start of the route. |
end_load_interval | The acceptable load interval of the vehicle at the end of the route. |
max_load | The maximum acceptable amount of load. |
cost_per_kilometer | Cost of moving one unit of load over one kilometer for this vehicle. This can be used as a proxy for fuel consumption: if the load is a weight (in Newtons), then load*kilometer has the dimension of an energy. |
cost_per_traveled_hour | Cost of traveling with a unit of load during one hour for this vehicle. |
فاصله
Interval of acceptable load amounts.
فیلدها | |
---|---|
min | A minimum acceptable load. Must be ≥ 0. If they're both specified, |
max | A maximum acceptable load. Must be ≥ 0. If unspecified, the maximum load is unrestricted by this message. If they're both specified, |
LoadCost
Cost of moving one unit of load during a Transition
. For a given load, the cost is the sum of two parts:
- min(load,
load_threshold
) *cost_per_unit_below_threshold
- max(0, load -
load_threshold
) *cost_per_unit_above_threshold
With this cost, solutions prefer to deliver high demands first, or equivalently pickup high demands last. For example, if a vehicle has
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
}
}
}
and its route is start,pickup,pickup,delivery,delivery,end with transitions:
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 }
then the cost incurred by this LoadCost
is (cost_below * load_below * kilometers + cost_above * load_above * kms)
- transition 0: 0.0
- transition 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 2: 2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
- transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 4: 0.0
So the LoadCost
over the route is 120.0.
However, if the route is start,pickup,delivery,pickup,delivery,end with transitions:
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 }
then the cost incurred by this LoadCost
is
- transition 0: 0.0
- transition 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 2: 0.0
- transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 4: 0.0
Here the LoadCost
over the route is 40.0.
LoadCost
makes solutions with heavy-loaded transitions more expensive.
فیلدها | |
---|---|
load_threshold | Amount of load above which the cost of moving a unit of load changes from cost_per_unit_below_threshold to cost_per_unit_above_threshold. Must be >= 0. |
cost_per_unit_below_threshold | Cost of moving a unit of load, for each unit between 0 and threshold. Must be a finite value, and >= 0. |
cost_per_unit_above_threshold | Cost of moving a unit of load, for each unit above threshold. In the special case threshold = 0, this is a fixed cost per unit. Must be a finite value, and >= 0. |
حالت سفر
Travel modes which can be used by vehicles.
These should be a subset of the Google Maps Platform Routes Preferred API travel modes, see: https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode .
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED | Unspecified travel mode, equivalent to DRIVING . |
DRIVING | Travel mode corresponding to driving directions (car, ...). |
WALKING | Travel mode corresponding to walking directions. |
UnloadingPolicy
Policy on how a vehicle can be unloaded. Applies only to shipments having both a pickup and a delivery.
Other shipments are free to occur anywhere on the route independent of unloading_policy
.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED | Unspecified unloading policy; deliveries must just occur after their corresponding pickups. |
LAST_IN_FIRST_OUT | Deliveries must occur in reverse order of pickups |
FIRST_IN_FIRST_OUT | Deliveries must occur in the same order as pickups |
نقطه راه
Encapsulates a waypoint. Waypoints mark arrival and departure locations of VisitRequests, and start and end locations of Vehicles.
فیلدها | |
---|---|
side_of_road | اختیاری. Indicates that the location of this waypoint is meant to have a preference for the vehicle to stop at a particular side of road. When you set this value, the route will pass through the location so that the vehicle can stop at the side of road that the location is biased towards from the center of the road. This option doesn't work for the 'WALKING' travel mode. |
Union field location_type . Different ways to represent a location. location_type can be only one of the following: | |
location | A point specified using geographic coordinates, including an optional heading. |
place_id | The POI Place ID associated with the waypoint. |
شاخص
-
RouteOptimization
(interface) -
AggregatedMetrics
(message) -
BatchOptimizeToursMetadata
(message) -
BatchOptimizeToursRequest
(message) -
BatchOptimizeToursRequest.AsyncModelConfig
(message) -
BatchOptimizeToursResponse
(message) -
BreakRule
(message) -
BreakRule.BreakRequest
(message) -
BreakRule.FrequencyConstraint
(message) -
DataFormat
(enum) -
DistanceLimit
(message) -
GcsDestination
(message) -
GcsSource
(message) -
InjectedSolutionConstraint
(message) -
InjectedSolutionConstraint.ConstraintRelaxation
(message) -
InjectedSolutionConstraint.ConstraintRelaxation.Relaxation
(message) -
InjectedSolutionConstraint.ConstraintRelaxation.Relaxation.Level
(enum) -
InputConfig
(message) -
Location
(message) -
OptimizeToursRequest
(message) -
OptimizeToursRequest.SearchMode
(enum) -
OptimizeToursRequest.SolvingMode
(enum) -
OptimizeToursResponse
(message) -
OptimizeToursResponse.Metrics
(message) -
OptimizeToursValidationError
(message) -
OptimizeToursValidationError.FieldReference
(message) -
OutputConfig
(message) -
RouteModifiers
(message) -
Shipment
(message) -
Shipment.Load
(message) -
Shipment.VisitRequest
(message) -
ShipmentModel
(message) -
ShipmentModel.DurationDistanceMatrix
(message) -
ShipmentModel.DurationDistanceMatrix.Row
(message) -
ShipmentModel.PrecedenceRule
(message) -
ShipmentRoute
(message) -
ShipmentRoute.Break
(message) -
ShipmentRoute.EncodedPolyline
(message) -
ShipmentRoute.Transition
(message) -
ShipmentRoute.VehicleLoad
(message) -
ShipmentRoute.Visit
(message) -
ShipmentTypeIncompatibility
(message) -
ShipmentTypeIncompatibility.IncompatibilityMode
(enum) -
ShipmentTypeRequirement
(message) -
ShipmentTypeRequirement.RequirementMode
(enum) -
SkippedShipment
(message) -
SkippedShipment.Reason
(message) -
SkippedShipment.Reason.Code
(enum) -
TimeWindow
(message) -
TransitionAttributes
(message) -
Vehicle
(message) -
Vehicle.DurationLimit
(message) -
Vehicle.LoadLimit
(message) -
Vehicle.LoadLimit.Interval
(message) -
Vehicle.LoadLimit.LoadCost
(message) -
Vehicle.TravelMode
(enum) -
Vehicle.UnloadingPolicy
(enum) -
Waypoint
(message)
RouteOptimization
A service for optimizing vehicle tours.
Validity of certain types of fields:
-
google.protobuf.Timestamp
- Times are in Unix time: seconds since 1970-01-01T00:00:00+00:00.
- seconds must be in [0, 253402300799], ie in [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
- nanos must be unset or set to 0.
-
google.protobuf.Duration
- seconds must be in [0, 253402300799], ie in [1970-01-01T00:00:00+00:00, 9999-12-31T23:59:59+00:00].
- nanos must be unset or set to 0.
-
google.type.LatLng
- latitude must be in [-90.0, 90.0].
- longitude must be in [-180.0, 180.0].
- at least one of latitude and longitude must be non-zero.
BatchOptimizeTours |
---|
تورهای وسیله نقلیه را برای یک یا چند پیام این روش یک عملیات طولانی مدت (LRO) است. ورودیهای بهینهسازی (پیامهای کاربر می تواند برای بررسی وضعیت LRO از اگر قسمت LRO اگر قسمت
|
OptimizeTours |
---|
یک یک مدل هدف این است که تخصیصی از
|
AggregatedMetrics
Aggregated metrics for ShipmentRoute
(resp. for OptimizeToursResponse
over all Transition
and/or Visit
(resp. over all ShipmentRoute
) elements.
فیلدها | |
---|---|
performed_shipment_count | Number of shipments performed. Note that a pickup and delivery pair only counts once. |
travel_duration | Total travel duration for a route or a solution. |
wait_duration | Total wait duration for a route or a solution. |
delay_duration | Total delay duration for a route or a solution. |
break_duration | Total break duration for a route or a solution. |
visit_duration | Total visit duration for a route or a solution. |
total_duration | The total duration should be equal to the sum of all durations above. For routes, it also corresponds to:
|
travel_distance_meters | Total travel distance for a route or a solution. |
max_loads | Maximum load achieved over the entire route (resp. solution), for each of the quantities on this route (resp. solution), computed as the maximum over all |
BatchOptimizeToursMetadata
This type has no fields.
Operation metadata for BatchOptimizeToursRequest
calls.
BatchOptimizeToursRequest
Request to batch optimize tours as an asynchronous operation. Each input file should contain one OptimizeToursRequest
, and each output file will contain one OptimizeToursResponse
. The request contains information to read/write and parse the files. All the input and output files should be under the same project.
فیلدها | |
---|---|
parent | مورد نیاز. پروژه و مکان مورد نظر برای برقراری تماس. قالب: * اگر مکانی مشخص نشده باشد، یک منطقه به طور خودکار انتخاب می شود. |
model_configs[] | مورد نیاز. اطلاعات ورودی/خروجی هر مدل خرید، مانند مسیرهای فایل و فرمت های داده. |
AsyncModelConfig
Information for solving one optimization model asynchronously.
فیلدها | |
---|---|
display_name | اختیاری. User defined model name, can be used as alias by users to keep track of models. |
input_config | مورد نیاز. Information about the input model. |
output_config | مورد نیاز. The desired output location information. |
BatchOptimizeToursResponse
This type has no fields.
Response to a BatchOptimizeToursRequest
. This is returned in the Long Running Operation after the operation is complete.
BreakRule
Rules to generate time breaks for a vehicle (eg lunch breaks). A break is a contiguous period of time during which the vehicle remains idle at its current position and cannot perform any visit. A break may occur:
- during the travel between two visits (which includes the time right before or right after a visit, but not in the middle of a visit), in which case it extends the corresponding transit time between the visits,
- or before the vehicle start (the vehicle may not start in the middle of a break), in which case it does not affect the vehicle start time.
- or after the vehicle end (ditto, with the vehicle end time).
فیلدها | |
---|---|
break_requests[] | Sequence of breaks. See the |
frequency_constraints[] | Several |
BreakRequest
The sequence of breaks (ie their number and order) that apply to each vehicle must be known beforehand. The repeated BreakRequest
s define that sequence, in the order in which they must occur. Their time windows ( earliest_start_time
/ latest_start_time
) may overlap, but they must be compatible with the order (this is checked).
فیلدها | |
---|---|
earliest_start_time | مورد نیاز. Lower bound (inclusive) on the start of the break. |
latest_start_time | مورد نیاز. Upper bound (inclusive) on the start of the break. |
min_duration | مورد نیاز. Minimum duration of the break. Must be positive. |
FrequencyConstraint
One may further constrain the frequency and duration of the breaks specified above, by enforcing a minimum break frequency, such as "There must be a break of at least 1 hour every 12 hours". Assuming that this can be interpreted as "Within any sliding time window of 12h, there must be at least one break of at least one hour", that example would translate to the following FrequencyConstraint
:
{
min_break_duration { seconds: 3600 } # 1 hour.
max_inter_break_duration { seconds: 39600 } # 11 hours (12 - 1 = 11).
}
The timing and duration of the breaks in the solution will respect all such constraints, in addition to the time windows and minimum durations already specified in the BreakRequest
.
A FrequencyConstraint
may in practice apply to non-consecutive breaks. For example, the following schedule honors the "1h every 12h" example:
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 | مورد نیاز. Minimum break duration for this constraint. Nonnegative. See description of |
max_inter_break_duration | مورد نیاز. Maximum allowed span of any interval of time in the route that does not include at least partially a break of |
DataFormat
Data formats for input and output files.
Enums | |
---|---|
DATA_FORMAT_UNSPECIFIED | Invalid value, format must not be UNSPECIFIED. |
JSON | نشانه گذاری شی جاوا اسکریپت. |
PROTO_TEXT | Protocol Buffers text format. See https://protobuf.dev/reference/protobuf/textformat-spec/ |
DistanceLimit
A limit defining a maximum distance which can be traveled. It can be either hard or soft.
If a soft limit is defined, both soft_max_meters
and cost_per_kilometer_above_soft_max
must be defined and be nonnegative.
فیلدها | |
---|---|
max_meters | A hard limit constraining the distance to be at most max_meters. The limit must be nonnegative. |
soft_max_meters | A soft limit not enforcing a maximum distance limit, but when violated results in a cost which adds up to other costs defined in the model, with the same unit. If defined soft_max_meters must be less than max_meters and must be nonnegative. |
cost_per_kilometer_below_soft_max | Cost per kilometer incurred, increasing up to
This cost is not supported in |
cost_per_kilometer_above_soft_max | Cost per kilometer incurred if distance is above
The cost must be nonnegative. |
GcsDestination
The Google Cloud Storage location where the output file(s) will be written to.
فیلدها | |
---|---|
uri | مورد نیاز. Google Cloud Storage URI. |
GcsSource
The Google Cloud Storage location where the input file will be read from.
فیلدها | |
---|---|
uri | مورد نیاز. URI of a Google Cloud Storage object with the format |
InjectedSolutionConstraint
Solution injected in the request including information about which visits must be constrained and how they must be constrained.
فیلدها | |
---|---|
routes[] | Routes of the solution to inject. Some routes may be omitted from the original solution. The routes and skipped shipments must satisfy the basic validity assumptions listed for |
skipped_shipments[] | Skipped shipments of the solution to inject. Some may be omitted from the original solution. See the |
constraint_relaxations[] | For zero or more groups of vehicles, specifies when and how much to relax constraints. If this field is empty, all non-empty vehicle routes are fully constrained. |
ConstraintRelaxation
For a group of vehicles, specifies at what threshold(s) constraints on visits will be relaxed and to which level. Shipments listed in the skipped_shipment
field are constrained to be skipped; ie, they cannot be performed.
فیلدها | |
---|---|
relaxations[] | All the visit constraint relaxations that will apply to visits on routes with vehicles in |
vehicle_indices[] | Specifies the vehicle indices to which the visit constraint A vehicle index is mapped the same as |
آرامش
If relaxations
is empty, the start time and sequence of all visits on routes
are fully constrained and no new visits may be inserted or added to those routes. Also, a vehicle's start and end time in routes
is fully constrained, unless the vehicle is empty (ie, has no visits and has used_if_route_is_empty
set to false in the model).
relaxations(i).level
specifies the constraint relaxation level applied to a visit #j that satisfies:
-
route.visits(j).start_time >= relaxations(i).threshold_time
AND -
j + 1 >= relaxations(i).threshold_visit_count
Similarly, the vehicle start is relaxed to relaxations(i).level
if it satisfies:
-
vehicle_start_time >= relaxations(i).threshold_time
AND -
relaxations(i).threshold_visit_count == 0
and the vehicle end is relaxed torelaxations(i).level
if it satisfies: -
vehicle_end_time >= relaxations(i).threshold_time
AND -
route.visits_size() + 1 >= relaxations(i).threshold_visit_count
To apply a relaxation level if a visit meets the threshold_visit_count
OR the threshold_time
add two relaxations
with the same level
: one with only threshold_visit_count
set and the other with only threshold_time
set. If a visit satisfies the conditions of multiple relaxations
, the most relaxed level applies. As a result, from the vehicle start through the route visits in order to the vehicle end, the relaxation level becomes more relaxed: ie, the relaxation level is non-decreasing as the route progresses.
The timing and sequence of route visits that do not satisfy the threshold conditions of any relaxations
are fully constrained and no visits may be inserted into these sequences. Also, if a vehicle start or end does not satisfy the conditions of any relaxation the time is fixed, unless the vehicle is empty.
فیلدها | |
---|---|
level | The constraint relaxation level that applies when the conditions at or after |
threshold_time | The time at or after which the relaxation |
threshold_visit_count | The number of visits at or after which the relaxation If it is |
سطح
Expresses the different constraint relaxation levels, which are applied for a visit and those that follow when it satisfies the threshold conditions.
The enumeration below is in order of increasing relaxation.
Enums | |
---|---|
LEVEL_UNSPECIFIED | Implicit default relaxation level: no constraints are relaxed, ie, all visits are fully constrained. This value must not be explicitly used in |
RELAX_VISIT_TIMES_AFTER_THRESHOLD | Visit start times and vehicle start/end times will be relaxed, but each visit remains bound to the same vehicle and the visit sequence must be observed: no visit can be inserted between them or before them. |
RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD | Same as RELAX_VISIT_TIMES_AFTER_THRESHOLD , but the visit sequence is also relaxed: visits can only be performed by this vehicle, but can potentially become unperformed. |
RELAX_ALL_AFTER_THRESHOLD | Same as RELAX_VISIT_TIMES_AND_SEQUENCE_AFTER_THRESHOLD , but the vehicle is also relaxed: visits are completely free at or after the threshold time and can potentially become unperformed. |
InputConfig
Specify an input for [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours].
فیلدها | |
---|---|
data_format | مورد نیاز. The input data format. |
Union field source . مورد نیاز. source can be only one of the following: | |
gcs_source | A Google Cloud Storage location. This must be a single object (file). |
مکان
Encapsulates a location (a geographic point, and an optional heading).
فیلدها | |
---|---|
lat_lng | The waypoint's geographic coordinates. |
heading | The compass heading associated with the direction of the flow of traffic. This value is used to specify the side of the road to use for pickup and drop-off. Heading values can be from 0 to 360, where 0 specifies a heading of due North, 90 specifies a heading of due East, etc. |
OptimizeToursRequest
Request to be given to a tour optimization solver which defines the shipment model to solve as well as optimization parameters.
فیلدها | |
---|---|
parent | مورد نیاز. پروژه یا مکان را برای برقراری تماس هدف قرار دهید. قالب: * اگر مکانی مشخص نشده باشد، یک منطقه به طور خودکار انتخاب می شود. |
timeout | اگر این مهلت تنظیم شود، سرور قبل از سپری شدن مدت زمان یا رسیدن به مهلت سرور برای درخواستهای همزمان، هرکدام زودتر، پاسخی را برمیگرداند. برای درخواست های ناهمزمان، سرور یک راه حل (در صورت امکان) را قبل از سپری شدن مهلت ایجاد می کند. |
model | مدل حمل و نقل برای حل. |
solving_mode | به طور پیش فرض، حالت حل |
search_mode | حالت جستجو برای حل درخواست استفاده می شود. |
injected_first_solution_routes[] | الگوریتم بهینه سازی را در یافتن راه حل اول که مشابه راه حل قبلی است، راهنمایی کنید. وقتی اولین راه حل ساخته می شود، مدل محدود می شود. هر محموله ای که در یک مسیر انجام نشده باشد به طور ضمنی در راه حل اول نادیده گرفته می شود، اما ممکن است در راه حل های متوالی انجام شود. راه حل باید برخی از مفروضات اعتبار پایه را برآورده کند:
اگر راه حل تزریق شده امکان پذیر نباشد، یک خطای اعتبار سنجی لزوما برگردانده نمی شود و ممکن است به جای آن خطای نشان دهنده غیرممکن بودن برگردانده شود. |
injected_solution_constraint | الگوریتم بهینه سازی را برای یافتن راه حل نهایی که مشابه راه حل قبلی است محدود کنید. به عنوان مثال، این ممکن است برای مسدود کردن بخشهایی از مسیرهایی که قبلاً تکمیل شدهاند یا باید تکمیل شوند اما نباید اصلاح شوند استفاده شود. اگر راه حل تزریق شده امکان پذیر نباشد، یک خطای اعتبار سنجی لزوما برگردانده نمی شود و ممکن است به جای آن خطای نشان دهنده غیرممکن بودن برگردانده شود. |
refresh_details_routes[] | در صورت خالی نبودن، مسیرهای داده شده بدون تغییر توالی بازدیدها یا زمان سفر، به روز می شوند: فقط سایر جزئیات به روز می شوند. این مدل را حل نمی کند. As of 2020/11, this only populates the polylines of non-empty routes and requires that The This field must not be used together with |
interpret_injected_solutions_using_labels | اگر درست باشد:
This interpretation applies to the اگر درست باشد، برچسبهای دستههای زیر باید حداکثر یک بار در دسته خود ظاهر شوند:
If a حذف بازدیدهای مسیر یا کل مسیرها از یک راه حل تزریقی ممکن است بر محدودیت های ضمنی تأثیر بگذارد، که ممکن است منجر به تغییر در راه حل، خطاهای اعتبارسنجی یا غیرممکن شود. توجه: تماس گیرنده باید اطمینان حاصل کند که هر |
consider_road_traffic | Consider traffic estimation in calculating |
populate_polylines | اگر درست باشد، چند خطوط در پاسخ |
populate_transition_polylines | اگر درست باشد، چند خطوط و نشانههای مسیر در پاسخ |
allow_large_deadline_despite_interruption_risk | اگر این تنظیم شده باشد، درخواست می تواند حداکثر 60 دقیقه مهلت داشته باشد (به https://grpc.io/blog/deadlines مراجعه کنید). در غیر این صورت حداکثر مهلت فقط 30 دقیقه است. توجه داشته باشید که درخواست های طولانی مدت خطر وقفه به طور قابل توجهی بزرگتر (اما هنوز کوچک) دارند. |
use_geodesic_distances | If true, travel distances will be computed using geodesic distances instead of Google Maps distances, and travel times will be computed using geodesic distances with a speed defined by |
label | برچسبی که ممکن است برای شناسایی این درخواست استفاده شود، در |
geodesic_meters_per_second | When |
max_validation_errors | تعداد خطاهای اعتبارسنجی برگشتی را کوتاه می کند. These errors are typically attached to an INVALID_ARGUMENT error payload as a BadRequest error detail ( https://cloud.google.com/apis/design/errors#error_details) , unless solving_mode=VALIDATE_ONLY: see the |
حالت جستجو
Mode defining the behavior of the search, trading off latency versus solution quality. In all modes, the global request deadline is enforced.
Enums | |
---|---|
SEARCH_MODE_UNSPECIFIED | Unspecified search mode, equivalent to RETURN_FAST . |
RETURN_FAST | Stop the search after finding the first good solution. |
CONSUME_ALL_AVAILABLE_TIME | Spend all the available time to search for better solutions. |
SolvingMode
Defines how the solver should handle the request. In all modes but VALIDATE_ONLY
, if the request is invalid, you will receive an INVALID_REQUEST
error. See max_validation_errors
to cap the number of errors returned.
Enums | |
---|---|
DEFAULT_SOLVE | Solve the model. Warnings may be issued in [OptimizeToursResponse.validation_errors][google.cloud.optimization.v1.OptimizeToursResponse.validation_errors]. |
VALIDATE_ONLY | Only validates the model without solving it: populates as many OptimizeToursResponse.validation_errors as possible. |
DETECT_SOME_INFEASIBLE_SHIPMENTS | Only populates IMPORTANT : not all infeasible shipments are returned here, but only the ones that are detected as infeasible during preprocessing. |
OptimizeToursResponse
Response after solving a tour optimization problem containing the routes followed by each vehicle, the shipments which have been skipped and the overall cost of the solution.
فیلدها | |
---|---|
routes[] | Routes computed for each vehicle; the i-th route corresponds to the i-th vehicle in the model. |
request_label | Copy of the |
skipped_shipments[] | The list of all shipments skipped. |
validation_errors[] | List of all the validation errors that we were able to detect independently. See the "MULTIPLE ERRORS" explanation for the |
metrics | Duration, distance and usage metrics for this solution. |
معیارها
Overall metrics, aggregated over all routes.
فیلدها | |
---|---|
aggregated_route_metrics | Aggregated over the routes. Each metric is the sum (or max, for loads) over all |
skipped_mandatory_shipment_count | Number of mandatory shipments skipped. |
used_vehicle_count | Number of vehicles used. Note: if a vehicle route is empty and |
earliest_vehicle_start_time | The earliest start time for a used vehicle, computed as the minimum over all used vehicles of |
latest_vehicle_end_time | The latest end time for a used vehicle, computed as the maximum over all used vehicles of |
costs | Cost of the solution, broken down by cost-related request fields. The keys are proto paths, relative to the input OptimizeToursRequest, eg "model.shipments.pickups.cost", and the values are the total cost generated by the corresponding cost field, aggregated over the whole solution. In other words, costs["model.shipments.pickups.cost"] is the sum of all pickup costs over the solution. All costs defined in the model are reported in detail here with the exception of costs related to TransitionAttributes that are only reported in an aggregated way as of 2022/01. |
total_cost | Total cost of the solution. The sum of all values in the costs map. |
OptimizeToursValidationError
Describes an error or warning encountered when validating an OptimizeToursRequest
.
فیلدها | |
---|---|
code | A validation error is defined by the pair ( The fields following this section provide more context about the error. MULTIPLE ERRORS : When there are multiple errors, the validation process tries to output several of them. Much like a compiler, this is an imperfect process. Some validation errors will be "fatal", meaning that they stop the entire validation process. This is the case for STABILITY : |
display_name | The error display name. |
fields[] | An error context may involve 0, 1 (most of the time) or more fields. For example, referring to vehicle #4 and shipment #2's first pickup can be done as follows:
Note, however, that the cardinality of |
error_message | Human-readable string describing the error. There is a 1:1 mapping between STABILITY : Not stable: the error message associated to a given |
offending_values | May contain the value(s) of the field(s). این همیشه در دسترس نیست. You should absolutely not rely on it and use it only for manual model debugging. |
FieldReference
Specifies a context for the validation error. A FieldReference
always refers to a given field in this file and follows the same hierarchical structure. For example, we may specify element #2 of start_time_windows
of vehicle #5 using:
name: "vehicles" index: 5 sub_field { name: "end_time_windows" index: 2 }
We however omit top-level entities such as OptimizeToursRequest
or ShipmentModel
to avoid crowding the message.
فیلدها | |
---|---|
name | Name of the field, eg, "vehicles". |
sub_field | Recursively nested sub-field, if needed. |
Union field | |
index | Index of the field if repeated. |
key | Key if the field is a map. |
OutputConfig
Specify a destination for [BatchOptimizeTours][google.maps.routeoptimization.v1.RouteOptimizationService.BatchOptimizeTours] results.
فیلدها | |
---|---|
data_format | مورد نیاز. The output data format. |
Union field destination . مورد نیاز. destination can be only one of the following: | |
gcs_destination | The Google Cloud Storage location to write the output to. |
رویه سازان
Encapsulates a set of optional conditions to satisfy when calculating vehicle routes. This is similar to RouteModifiers
in the Google Maps Platform Routes Preferred API; see: https://developers.google.com/maps/documentation/routes/reference/rest/v2/RouteModifiers .
فیلدها | |
---|---|
avoid_tolls | Specifies whether to avoid toll roads where reasonable. Preference will be given to routes not containing toll roads. Applies only to motorized travel modes. |
avoid_highways | Specifies whether to avoid highways where reasonable. Preference will be given to routes not containing highways. Applies only to motorized travel modes. |
avoid_ferries | Specifies whether to avoid ferries where reasonable. Preference will be given to routes not containing travel by ferries. Applies only to motorized travel modes. |
avoid_indoor | اختیاری. Specifies whether to avoid navigating indoors where reasonable. Preference will be given to routes not containing indoor navigation. Applies only to the |
حمل و نقل
The shipment of a single item, from one of its pickups to one of its deliveries. For the shipment to be considered as performed, a unique vehicle must visit one of its pickup locations (and decrease its spare capacities accordingly), then visit one of its delivery locations later on (and therefore re-increase its spare capacities accordingly).
فیلدها | |
---|---|
display_name | The user-defined display name of the shipment. It can be up to 63 characters long and may use UTF-8 characters. |
pickups[] | Set of pickup alternatives associated to the shipment. If not specified, the vehicle only needs to visit a location corresponding to the deliveries. |
deliveries[] | Set of delivery alternatives associated to the shipment. If not specified, the vehicle only needs to visit a location corresponding to the pickups. |
load_demands | Load demands of the shipment (for example weight, volume, number of pallets etc). The keys in the map should be identifiers describing the type of the corresponding load, ideally also including the units. For example: "weight_kg", "volume_gallons", "pallet_count", etc. If a given key does not appear in the map, the corresponding load is considered as null. |
allowed_vehicle_indices[] | The set of vehicles that may perform this shipment. If empty, all vehicles may perform it. Vehicles are given by their index in the |
costs_per_vehicle[] | Specifies the cost that is incurred when this shipment is delivered by each vehicle. If specified, it must have EITHER:
These costs must be in the same unit as |
costs_per_vehicle_indices[] | Indices of the vehicles to which |
pickup_to_delivery_absolute_detour_limit | Specifies the maximum absolute detour time compared to the shortest path from pickup to delivery. If specified, it must be nonnegative, and the shipment must contain at least a pickup and a delivery. For example, let t be the shortest time taken to go from the selected pickup alternative directly to the selected delivery alternative. Then setting
If both relative and absolute limits are specified on the same shipment, the more constraining limit is used for each possible pickup/delivery pair. As of 2017/10, detours are only supported when travel durations do not depend on vehicles. |
pickup_to_delivery_time_limit | Specifies the maximum duration from start of pickup to start of delivery of a shipment. If specified, it must be nonnegative, and the shipment must contain at least a pickup and a delivery. This does not depend on which alternatives are selected for pickup and delivery, nor on vehicle speed. This can be specified alongside maximum detour constraints: the solution will respect both specifications. |
shipment_type | Non-empty string specifying a "type" for this shipment. This feature can be used to define incompatibilities or requirements between Differs from |
label | Specifies a label for this shipment. This label is reported in the response in the |
ignore | If true, skip this shipment, but don't apply a Ignoring a shipment results in a validation error when there are any Ignoring a shipment that is performed in |
penalty_cost | If the shipment is not completed, this penalty is added to the overall cost of the routes. A shipment is considered completed if one of its pickup and delivery alternatives is visited. The cost may be expressed in the same unit used for all other cost-related fields in the model and must be positive. IMPORTANT : If this penalty is not specified, it is considered infinite, ie the shipment must be completed. |
pickup_to_delivery_relative_detour_limit | Specifies the maximum relative detour time compared to the shortest path from pickup to delivery. If specified, it must be nonnegative, and the shipment must contain at least a pickup and a delivery. For example, let t be the shortest time taken to go from the selected pickup alternative directly to the selected delivery alternative. Then setting
If both relative and absolute limits are specified on the same shipment, the more constraining limit is used for each possible pickup/delivery pair. As of 2017/10, detours are only supported when travel durations do not depend on vehicles. |
بارگذاری کنید
هنگام انجام یک بازدید، ممکن است مقداری از پیش تعریف شده به بار خودرو اضافه شود، اگر حمل و نقل باشد، یا در صورت تحویل از آن کم شود. این پیام چنین مقداری را تعریف می کند. See load_demands
.
فیلدها | |
---|---|
amount | مقدار بار وسیله نقلیه ای که بازدید مربوطه را انجام می دهد متفاوت است. از آنجایی که یک عدد صحیح است، به کاربران توصیه می شود یک واحد مناسب را برای جلوگیری از افت دقت انتخاب کنند. باید ≥ 0 باشد. |
VisitRequest
Request for a visit which can be done by a vehicle: it has a geo-location (or two, see below), opening and closing times represented by time windows, and a service duration time (time spent by the vehicle once it has arrived to pickup or drop off goods).
فیلدها | |
---|---|
arrival_location | The geo-location where the vehicle arrives when performing this |
arrival_waypoint | The waypoint where the vehicle arrives when performing this |
departure_location | The geo-location where the vehicle departs after completing this |
departure_waypoint | The waypoint where the vehicle departs after completing this |
tags[] | Specifies tags attached to the visit request. Empty or duplicate strings are not allowed. |
time_windows[] | Time windows which constrain the arrival time at a visit. Note that a vehicle may depart outside of the arrival time window, ie arrival time + duration do not need to be inside a time window. This can result in waiting time if the vehicle arrives before The absence of Time windows must be disjoint, ie no time window must overlap with or be adjacent to another, and they must be in increasing order. |
duration | Duration of the visit, ie time spent by the vehicle between arrival and departure (to be added to the possible waiting time; see |
cost | Cost to service this visit request on a vehicle route. This can be used to pay different costs for each alternative pickup or delivery of a shipment. This cost must be in the same unit as |
load_demands | Load demands of this visit request. This is just like |
visit_types[] | Specifies the types of the visit. This may be used to allocate additional time required for a vehicle to complete this visit (see A type can only appear once. |
label | Specifies a label for this |
ShipmentModel
A shipment model contains a set of shipments which must be performed by a set of vehicles, while minimizing the overall cost, which is the sum of:
- the cost of routing the vehicles (sum of cost per total time, cost per travel time, and fixed cost over all vehicles).
- the unperformed shipment penalties.
- the cost of the global duration of the shipments
فیلدها | |
---|---|
shipments[] | Set of shipments which must be performed in the model. |
vehicles[] | Set of vehicles which can be used to perform visits. |
global_start_time | Global start and end time of the model: no times outside of this range can be considered valid. The model's time span must be less than a year, ie the When using |
global_end_time | If unset, 00:00:00 UTC, January 1, 1971 (ie seconds: 31536000, nanos: 0) is used as default. |
global_duration_cost_per_hour | The "global duration" of the overall plan is the difference between the earliest effective start time and the latest effective end time of all vehicles. Users can assign a cost per hour to that quantity to try and optimize for earliest job completion, for example. This cost must be in the same unit as |
duration_distance_matrices[] | Specifies duration and distance matrices used in the model. If this field is empty, Google Maps or geodesic distances will be used instead, depending on the value of the نمونه های استفاده:
|
duration_distance_matrix_src_tags[] | Tags defining the sources of the duration and distance matrices; Tags correspond to |
duration_distance_matrix_dst_tags[] | Tags defining the destinations of the duration and distance matrices; Tags correspond to |
transition_attributes[] | Transition attributes added to the model. |
shipment_type_incompatibilities[] | Sets of incompatible shipment_types (see |
shipment_type_requirements[] | Sets of |
precedence_rules[] | Set of precedence rules which must be enforced in the model. |
max_active_vehicles | Constrains the maximum number of active vehicles. A vehicle is active if its route performs at least one shipment. This can be used to limit the number of routes in the case where there are fewer drivers than vehicles and that the fleet of vehicles is heterogeneous. The optimization will then select the best subset of vehicles to use. Must be strictly positive. |
DurationDistanceMatrix
Specifies a duration and distance matrix from visit and vehicle start locations to visit and vehicle end locations.
فیلدها | |
---|---|
rows[] | Specifies the rows of the duration and distance matrix. It must have as many elements as |
vehicle_start_tag | Tag defining to which vehicles this duration and distance matrix applies. If empty, this applies to all vehicles, and there can only be a single matrix. Each vehicle start must match exactly one matrix, ie exactly one of their All matrices must have a different |
ردیف
Specifies a row of the duration and distance matrix.
فیلدها | |
---|---|
durations[] | Duration values for a given row. It must have as many elements as |
meters[] | Distance values for a given row. If no costs or constraints refer to distances in the model, this can be left empty; otherwise it must have as many elements as |
PrecedenceRule
A precedence rule between two events (each event is the pickup or the delivery of a shipment): the "second" event has to start at least offset_duration
after "first" has started.
Several precedences can refer to the same (or related) events, eg, "pickup of B happens after delivery of A" and "pickup of C happens after pickup of B".
Furthermore, precedences only apply when both shipments are performed and are otherwise ignored.
فیلدها | |
---|---|
first_is_delivery | Indicates if the "first" event is a delivery. |
second_is_delivery | Indicates if the "second" event is a delivery. |
offset_duration | The offset between the "first" and "second" event. می تواند منفی باشد. |
first_index | Shipment index of the "first" event. این فیلد باید مشخص شود. |
second_index | Shipment index of the "second" event. این فیلد باید مشخص شود. |
ShipmentRoute
A vehicle's route can be decomposed, along the time axis, like this (we assume there are n visits):
| | | | | 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
Note that we make a difference between:
- "punctual events", such as the vehicle start and end and each visit's start and end (aka arrival and departure). They happen at a given second.
- "time intervals", such as the visits themselves, and the transition between visits. Though time intervals can sometimes have zero duration, ie start and end at the same second, they often have a positive duration.
Invariants:
- If there are n visits, there are n+1 transitions.
- A visit is always surrounded by a transition before it (same index) and a transition after it (index + 1).
- The vehicle start is always followed by transition #0.
- The vehicle end is always preceded by transition #n.
Zooming in, here is what happens during a Transition
and a 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
Lastly, here is how the TRAVEL, BREAKS, DELAY and WAIT can be arranged during a transition.
- آنها با هم تداخل ندارند.
- The DELAY is unique and must be a contiguous period of time right before the next visit (or vehicle end). Thus, it suffice to know the delay duration to know its start and end time.
- The BREAKS are contiguous, non-overlapping periods of time. The response specifies the start time and duration of each break.
- TRAVEL and WAIT are "preemptable": they can be interrupted several times during this transition. Clients can assume that travel happens "as soon as possible" and that "wait" fills the remaining time.
A (complex) example:
TRANSITION[i]
--++-----+-----------------------------------------------------------++-->
|| | | | | | | ||
|| T | B | T | | B | | D ||
|| r | r | r | W | r | W | e ||
|| a | e | a | a | e | a | l ||
|| v | a | v | i | a | i | a ||
|| e | k | e | t | k | t | y ||
|| l | | l | | | | ||
|| | | | | | | ||
--++-----------------------------------------------------------------++-->
فیلدها | |
---|---|
vehicle_index | Vehicle performing the route, identified by its index in the source |
vehicle_label | Label of the vehicle performing this route, equal to |
vehicle_start_time | Time at which the vehicle starts its route. |
vehicle_end_time | Time at which the vehicle finishes its route. |
visits[] | Ordered sequence of visits representing a route. visits[i] is the i-th visit in the route. If this field is empty, the vehicle is considered as unused. |
transitions[] | Ordered list of transitions for the route. |
has_traffic_infeasibilities | When
Arrival at next_visit will likely happen later than its current time window due the increased estimate of travel time |
route_polyline | The encoded polyline representation of the route. This field is only populated if |
breaks[] | Breaks scheduled for the vehicle performing this route. The |
metrics | Duration, distance and load metrics for this route. The fields of |
route_costs | Cost of the route, broken down by cost-related request fields. The keys are proto paths, relative to the input OptimizeToursRequest, eg "model.shipments.pickups.cost", and the values are the total cost generated by the corresponding cost field, aggregated over the whole route. In other words, costs["model.shipments.pickups.cost"] is the sum of all pickup costs over the route. All costs defined in the model are reported in detail here with the exception of costs related to TransitionAttributes that are only reported in an aggregated way as of 2022/01. |
route_total_cost | Total cost of the route. The sum of all costs in the cost map. |
شکستن
Data representing the execution of a break.
فیلدها | |
---|---|
start_time | Start time of a break. |
duration | Duration of a break. |
EncodedPolyline
The encoded representation of a polyline. More information on polyline encoding can be found here: https://developers.google.com/maps/documentation/utilities/polylinealgorithm https://developers.google.com/maps/documentation/javascript/reference/geometry#encoding .
فیلدها | |
---|---|
points | String representing encoded points of the polyline. |
انتقال
Transition between two events on the route. See the description of ShipmentRoute
.
If the vehicle does not have a start_location
and/or end_location
, the corresponding travel metrics are 0.
فیلدها | |
---|---|
travel_duration | Travel duration during this transition. |
travel_distance_meters | Distance traveled during the transition. |
traffic_info_unavailable | When traffic is requested via |
delay_duration | Sum of the delay durations applied to this transition. If any, the delay starts exactly |
break_duration | Sum of the duration of the breaks occurring during this transition, if any. Details about each break's start time and duration are stored in |
wait_duration | Time spent waiting during this transition. Wait duration corresponds to idle time and does not include break time. Also note that this wait time may be split into several non-contiguous intervals. |
total_duration | Total duration of the transition, provided for convenience. برابر است با:
|
start_time | Start time of this transition. |
route_polyline | The encoded polyline representation of the route followed during the transition. This field is only populated if |
route_token | فقط خروجی An opaque token that can be passed to Navigation SDK to reconstruct the route during navigation, and, in the event of rerouting, honor the original intention when the route was created. Treat this token as an opaque blob. Don't compare its value across requests as its value may change even if the service returns the exact same route. This field is only populated if |
vehicle_loads | Vehicle loads during this transition, for each type that either appears in this vehicle's The loads during the first transition are the starting loads of the vehicle route. Then, after each visit, the visit's |
VehicleLoad
Reports the actual load of the vehicle at some point along the route, for a given type (see Transition.vehicle_loads
).
فیلدها | |
---|---|
amount | The amount of load on the vehicle, for the given type. The unit of load is usually indicated by the type. See |
بازدید کنید
A visit performed during a route. This visit corresponds to a pickup or a delivery of a Shipment
.
فیلدها | |
---|---|
shipment_index | Index of the |
is_pickup | If true the visit corresponds to a pickup of a |
visit_request_index | Index of |
start_time | Time at which the visit starts. Note that the vehicle may arrive earlier than this at the visit location. Times are consistent with the |
load_demands | Total visit load demand as the sum of the shipment and the visit request |
detour | Extra detour time due to the shipments visited on the route before the visit and to the potential waiting time induced by time windows. If the visit is a delivery, the detour is computed from the corresponding pickup visit and is equal to:
Otherwise, it is computed from the vehicle
|
shipment_label | Copy of the corresponding |
visit_label | Copy of the corresponding |
ShipmentTypeIncompatibility
Specifies incompatibilties between shipments depending on their shipment_type. The appearance of incompatible shipments on the same route is restricted based on the incompatibility mode.
فیلدها | |
---|---|
types[] | List of incompatible types. Two shipments having different |
incompatibility_mode | Mode applied to the incompatibility. |
IncompatibilityMode
Modes defining how the appearance of incompatible shipments are restricted on the same route.
Enums | |
---|---|
INCOMPATIBILITY_MODE_UNSPECIFIED | Unspecified incompatibility mode. This value should never be used. |
NOT_PERFORMED_BY_SAME_VEHICLE | In this mode, two shipments with incompatible types can never share the same vehicle. |
NOT_IN_SAME_VEHICLE_SIMULTANEOUSLY | For two shipments with incompatible types with the
|
ShipmentTypeRequirement
Specifies requirements between shipments based on their shipment_type. The specifics of the requirement are defined by the requirement mode.
فیلدها | |
---|---|
required_shipment_type_alternatives[] | List of alternative shipment types required by the |
dependent_shipment_types[] | All shipments with a type in the NOTE: Chains of requirements such that a |
requirement_mode | Mode applied to the requirement. |
RequirementMode
Modes defining the appearance of dependent shipments on a route.
Enums | |
---|---|
REQUIREMENT_MODE_UNSPECIFIED | Unspecified requirement mode. This value should never be used. |
PERFORMED_BY_SAME_VEHICLE | In this mode, all "dependent" shipments must share the same vehicle as at least one of their "required" shipments. |
IN_SAME_VEHICLE_AT_PICKUP_TIME | With the A "dependent" shipment pickup must therefore have either:
|
IN_SAME_VEHICLE_AT_DELIVERY_TIME | Same as before, except the "dependent" shipments need to have a "required" shipment on their vehicle at the time of their delivery . |
SkippedShipment
Specifies details of unperformed shipments in a solution. For trivial cases and/or if we are able to identify the cause for skipping, we report the reason here.
فیلدها | |
---|---|
index | The index corresponds to the index of the shipment in the source |
label | Copy of the corresponding |
reasons[] | A list of reasons that explain why the shipment was skipped. See comment above |
دلیل
If we can explain why the shipment was skipped, reasons will be listed here. If the reason is not the same for all vehicles, reason
will have more than 1 element. A skipped shipment cannot have duplicate reasons, ie where all fields are the same except for 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
}
The skipped shipment is incompatible with all vehicles. The reasons may be different for all vehicles but at least one vehicle's "Apples" capacity would be exceeded (including vehicle 1), at least one vehicle's "Pears" capacity would be exceeded (including vehicle 3) and at least one vehicle's distance limit would be exceeded (including vehicle 1).
فیلدها | |
---|---|
code | Refer to the comments of Code. |
example_exceeded_capacity_type | If the reason code is |
example_vehicle_index | If the reason is related to a shipment-vehicle incompatibility, this field provides the index of one relevant vehicle. |
کد
Code identifying the reason type. The order here is meaningless. In particular, it gives no indication of whether a given reason will appear before another in the solution, if both apply.
Enums | |
---|---|
CODE_UNSPECIFIED | This should never be used. |
NO_VEHICLE | There is no vehicle in the model making all shipments infeasible. |
DEMAND_EXCEEDS_VEHICLE_CAPACITY | The demand of the shipment exceeds a vehicle's capacity for some capacity types, one of which is example_exceeded_capacity_type . |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DISTANCE_LIMIT | The minimum distance necessary to perform this shipment, ie from the vehicle's Note that for this computation we use the geodesic distances. |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT | The minimum time necessary to perform this shipment, including travel time, wait time and service time exceeds the vehicle's Note: travel time is computed in the best-case scenario, namely as geodesic distance x 36 m/s (roughly 130 km/hour). |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TRAVEL_DURATION_LIMIT | Same as above but we only compare minimum travel time and the vehicle's travel_duration_limit . |
CANNOT_BE_PERFORMED_WITHIN_VEHICLE_TIME_WINDOWS | The vehicle cannot perform this shipment in the best-case scenario (see CANNOT_BE_PERFORMED_WITHIN_VEHICLE_DURATION_LIMIT for time computation) if it starts at its earliest start time: the total time would make the vehicle end after its latest end time. |
VEHICLE_NOT_ALLOWED | The allowed_vehicle_indices field of the shipment is not empty and this vehicle does not belong to it. |
پنجره زمانی
Time windows constrain the time of an event, such as the arrival time at a visit, or the start and end time of a vehicle.
Hard time window bounds, start_time
and end_time
, enforce the earliest and latest time of the event, such that start_time <= event_time <= end_time
. The soft time window lower bound, soft_start_time
, expresses a preference for the event to happen at or after soft_start_time
by incurring a cost proportional to how long before soft_start_time the event occurs. The soft time window upper bound, soft_end_time
, expresses a preference for the event to happen at or before soft_end_time
by incurring a cost proportional to how long after soft_end_time
the event occurs. start_time
, end_time
, soft_start_time
and soft_end_time
should be within the global time limits (see ShipmentModel.global_start_time
and ShipmentModel.global_end_time
) and should respect:
0 <= `start_time` <= `end_time` and
0 <= `start_time` <= `soft_start_time` and
0 <= `soft_end_time` <= `end_time`.
فیلدها | |
---|---|
start_time | The hard time window start time. If unspecified it will be set to |
end_time | The hard time window end time. If unspecified it will be set to |
soft_start_time | The soft start time of the time window. |
soft_end_time | The soft end time of the time window. |
cost_per_hour_before_soft_start_time | A cost per hour added to other costs in the model if the event occurs before soft_start_time, computed as:
This cost must be positive, and the field can only be set if soft_start_time has been set. |
cost_per_hour_after_soft_end_time | A cost per hour added to other costs in the model if the event occurs after
This cost must be positive, and the field can only be set if |
TransitionAttributes
Specifies attributes of transitions between two consecutive visits on a route. Several TransitionAttributes
may apply to the same transition: in that case, all extra costs add up and the strictest constraint or limit applies (following natural "AND" semantics).
فیلدها | |
---|---|
src_tag | Tags defining the set of (src->dst) transitions these attributes apply to. A source visit or vehicle start matches iff its |
excluded_src_tag | See |
dst_tag | A destination visit or vehicle end matches iff its |
excluded_dst_tag | See |
cost | Specifies a cost for performing this transition. This is in the same unit as all other costs in the model and must not be negative. It is applied on top of all other existing costs. |
cost_per_kilometer | Specifies a cost per kilometer applied to the distance traveled while performing this transition. It adds up to any |
distance_limit | Specifies a limit on the distance traveled while performing this transition. As of 2021/06, only soft limits are supported. |
delay | Specifies a delay incurred when performing this transition. This delay always occurs after finishing the source visit and before starting the destination visit. |
وسیله نقلیه
Models a vehicle in a shipment problem. Solving a shipment problem will build a route starting from start_location
and ending at end_location
for this vehicle. A route is a sequence of visits (see ShipmentRoute
).
فیلدها | |
---|---|
display_name | The user-defined display name of the vehicle. It can be up to 63 characters long and may use UTF-8 characters. |
travel_mode | The travel mode which affects the roads usable by the vehicle and its speed. See also |
route_modifiers | A set of conditions to satisfy that affect the way routes are calculated for the given vehicle. |
start_location | Geographic location where the vehicle starts before picking up any shipments. If not specified, the vehicle starts at its first pickup. If the shipment model has duration and distance matrices, |
start_waypoint | Waypoint representing a geographic location where the vehicle starts before picking up any shipments. If neither |
end_location | Geographic location where the vehicle ends after it has completed its last |
end_waypoint | Waypoint representing a geographic location where the vehicle ends after it has completed its last |
start_tags[] | Specifies tags attached to the start of the vehicle's route. Empty or duplicate strings are not allowed. |
end_tags[] | Specifies tags attached to the end of the vehicle's route. Empty or duplicate strings are not allowed. |
start_time_windows[] | Time windows during which the vehicle may depart its start location. They must be within the global time limits (see Time windows belonging to the same repeated field must be disjoint, ie no time window can overlap with or be adjacent to another, and they must be in chronological order. |
end_time_windows[] | Time windows during which the vehicle may arrive at its end location. They must be within the global time limits (see Time windows belonging to the same repeated field must be disjoint, ie no time window can overlap with or be adjacent to another, and they must be in chronological order. |
unloading_policy | Unloading policy enforced on the vehicle. |
load_limits | Capacities of the vehicle (weight, volume, # of pallets for example). The keys in the map are the identifiers of the type of load, consistent with the keys of the |
cost_per_hour | Vehicle costs: all costs add up and must be in the same unit as Cost per hour of the vehicle route. This cost is applied to the total time taken by the route, and includes travel time, waiting time, and visit time. Using |
cost_per_traveled_hour | Cost per traveled hour of the vehicle route. This cost is applied only to travel time taken by the route (ie, that reported in |
cost_per_kilometer | Cost per kilometer of the vehicle route. This cost is applied to the distance reported in the |
fixed_cost | Fixed cost applied if this vehicle is used to handle a shipment. |
used_if_route_is_empty | This field only applies to vehicles when their route does not serve any shipments. It indicates if the vehicle should be considered as used or not in this case. If true, the vehicle goes from its start to its end location even if it doesn't serve any shipments, and time and distance costs resulting from its start --> end travel are taken into account. Otherwise, it doesn't travel from its start to its end location, and no |
route_duration_limit | Limit applied to the total duration of the vehicle's route. In a given |
travel_duration_limit | Limit applied to the travel duration of the vehicle's route. In a given |
route_distance_limit | Limit applied to the total distance of the vehicle's route. In a given |
extra_visit_duration_for_visit_type | Specifies a map from visit_types strings to durations. The duration is time in addition to If a visit request has multiple types, a duration will be added for each type in the map. |
break_rule | Describes the break schedule to be enforced on this vehicle. If empty, no breaks will be scheduled for this vehicle. |
label | Specifies a label for this vehicle. This label is reported in the response as the |
ignore | If true, If a shipment is performed by an ignored vehicle in If a shipment is performed by an ignored vehicle in |
travel_duration_multiple | Specifies a multiplicative factor that can be used to increase or decrease travel times of this vehicle. For example, setting this to 2.0 means that this vehicle is slower and has travel times that are twice what they are for standard vehicles. This multiple does not affect visit durations. It does affect cost if WARNING: Travel times will be rounded to the nearest second after this multiple is applied but before performing any numerical operations, thus, a small multiple may result in a loss of precision. See also |
DurationLimit
A limit defining a maximum duration of the route of a vehicle. It can be either hard or soft.
When a soft limit field is defined, both the soft max threshold and its associated cost must be defined together.
فیلدها | |
---|---|
max_duration | A hard limit constraining the duration to be at most max_duration. |
soft_max_duration | A soft limit not enforcing a maximum duration limit, but when violated makes the route incur a cost. This cost adds up to other costs defined in the model, with the same unit. If defined, |
quadratic_soft_max_duration | A soft limit not enforcing a maximum duration limit, but when violated makes the route incur a cost, quadratic in the duration. This cost adds up to other costs defined in the model, with the same unit. If defined, |
cost_per_hour_after_soft_max | Cost per hour incurred if the
The cost must be nonnegative. |
cost_per_square_hour_after_quadratic_soft_max | Cost per square hour incurred if the The additional cost is 0 if the duration is under the threshold, otherwise the cost depends on the duration as follows:
The cost must be nonnegative. |
LoadLimit
Defines a load limit applying to a vehicle, eg "this truck may only carry up to 3500 kg". See load_limits
.
فیلدها | |
---|---|
soft_max_load | A soft limit of the load. See |
cost_per_unit_above_soft_max | If the load ever exceeds |
start_load_interval | The acceptable load interval of the vehicle at the start of the route. |
end_load_interval | The acceptable load interval of the vehicle at the end of the route. |
max_load | The maximum acceptable amount of load. |
cost_per_kilometer | Cost of moving one unit of load over one kilometer for this vehicle. This can be used as a proxy for fuel consumption: if the load is a weight (in Newtons), then load*kilometer has the dimension of an energy. |
cost_per_traveled_hour | Cost of traveling with a unit of load during one hour for this vehicle. |
فاصله
Interval of acceptable load amounts.
فیلدها | |
---|---|
min | A minimum acceptable load. Must be ≥ 0. If they're both specified, |
max | A maximum acceptable load. Must be ≥ 0. If unspecified, the maximum load is unrestricted by this message. If they're both specified, |
LoadCost
Cost of moving one unit of load during a Transition
. For a given load, the cost is the sum of two parts:
- min(load,
load_threshold
) *cost_per_unit_below_threshold
- max(0, load -
load_threshold
) *cost_per_unit_above_threshold
With this cost, solutions prefer to deliver high demands first, or equivalently pickup high demands last. For example, if a vehicle has
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
}
}
}
and its route is start,pickup,pickup,delivery,delivery,end with transitions:
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 }
then the cost incurred by this LoadCost
is (cost_below * load_below * kilometers + cost_above * load_above * kms)
- transition 0: 0.0
- transition 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 2: 2.0 * 15 * 1.0 + 10.0 * (20 - 15) * 1.0 = 80.0
- transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 4: 0.0
So the LoadCost
over the route is 120.0.
However, if the route is start,pickup,delivery,pickup,delivery,end with transitions:
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 }
then the cost incurred by this LoadCost
is
- transition 0: 0.0
- transition 1: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 2: 0.0
- transition 3: 2.0 * 10 * 1.0 + 10.0 * 0 * 1.0 = 20.0
- transition 4: 0.0
Here the LoadCost
over the route is 40.0.
LoadCost
makes solutions with heavy-loaded transitions more expensive.
فیلدها | |
---|---|
load_threshold | Amount of load above which the cost of moving a unit of load changes from cost_per_unit_below_threshold to cost_per_unit_above_threshold. Must be >= 0. |
cost_per_unit_below_threshold | Cost of moving a unit of load, for each unit between 0 and threshold. Must be a finite value, and >= 0. |
cost_per_unit_above_threshold | Cost of moving a unit of load, for each unit above threshold. In the special case threshold = 0, this is a fixed cost per unit. Must be a finite value, and >= 0. |
حالت سفر
Travel modes which can be used by vehicles.
These should be a subset of the Google Maps Platform Routes Preferred API travel modes, see: https://developers.google.com/maps/documentation/routes_preferred/reference/rest/Shared.Types/RouteTravelMode .
Enums | |
---|---|
TRAVEL_MODE_UNSPECIFIED | Unspecified travel mode, equivalent to DRIVING . |
DRIVING | Travel mode corresponding to driving directions (car, ...). |
WALKING | Travel mode corresponding to walking directions. |
UnloadingPolicy
Policy on how a vehicle can be unloaded. Applies only to shipments having both a pickup and a delivery.
Other shipments are free to occur anywhere on the route independent of unloading_policy
.
Enums | |
---|---|
UNLOADING_POLICY_UNSPECIFIED | Unspecified unloading policy; deliveries must just occur after their corresponding pickups. |
LAST_IN_FIRST_OUT | Deliveries must occur in reverse order of pickups |
FIRST_IN_FIRST_OUT | Deliveries must occur in the same order as pickups |
نقطه راه
Encapsulates a waypoint. Waypoints mark arrival and departure locations of VisitRequests, and start and end locations of Vehicles.
فیلدها | |
---|---|
side_of_road | اختیاری. Indicates that the location of this waypoint is meant to have a preference for the vehicle to stop at a particular side of road. When you set this value, the route will pass through the location so that the vehicle can stop at the side of road that the location is biased towards from the center of the road. This option doesn't work for the 'WALKING' travel mode. |
Union field location_type . Different ways to represent a location. location_type can be only one of the following: | |
location | A point specified using geographic coordinates, including an optional heading. |
place_id | The POI Place ID associated with the waypoint. |