Make Vehicle Routing Problem Layer Tool
أداة إنشاء طبقة مشكلة توجيه المركبة
ArcMap ArcGIS
How to use Make Vehicle Routing Problem Layer Tool in Arc Toolbox ArcMap ArcGIS??
كيفية استخدام أداة إنشاء طبقة مشكلة توجيه المركبة ؟؟
Path
to access the toolمسار الوصول الى الأداة
:
Make
Vehicle Routing Problem Layer Tool, Analysis Toolset,
Network Analyst Tools Toolbox
Make Vehicle Routing Problem Layer
Makes a vehicle routing
problem (VRP) network analysis layer and sets its analysis properties. A vehicle
routing problem analysis layer is useful for optimizing a set of routes using a
fleet of vehicles.
إنشاء طبقة تحليل شبكة مشكلة في توجيه السيارة (VRP)
وتعيين خصائص التحليل الخاصة بها. تعد طبقة تحليل مشكلة توجيه السيارة مفيدة
لتحسين مجموعة من المسارات باستخدام أسطول من المركبات.
The Make Vehicle Routing
Problem Layer and Solve Vehicle Routing Problem tools are similar, but they are
designed for different purposes. Use the Solve Vehicle Routing Problem tool if
you are setting up a geoprocessing service; it will simplify the setup process;
otherwise, use the Make Vehicle Routing Problem Layer tool.
تتشابه أداتا إنشاء طبقة مشكلة توجيه السيارة وحل
مشكلات توجيه السيارة ، لكنهما مصممتان لأغراض مختلفة. استخدم أداة حل مشكلة توجيه
السيارة إذا كنت تقوم بإعداد خدمة معالجة جغرافية ؛ سوف يبسط عملية الإعداد ؛ خلاف
ذلك ، استخدم أداة إنشاء طبقة مشكلة توجيه السيارة.
To create a VRP geoprocessing service using Solve Vehicle Routing Problem Layer, you only need to set up one tool and publish it as a service. In contrast, you need to create a model with the Make Vehicle Routing Problem Layer, properly connect it to various other tools,
and publish the model to create a service. One other
option to consider is the ArcGIS Online Vehicle Routing Problem services. The
services run like geoprocessing tools in ArcMap, can be accessed from other
applications, and include high-quality road data for much of the world.
لإنشاء خدمة معالجة جغرافية VRP باستخدام حل طبقة مشكلة توجيه السيارة ، ما عليك سوى إعداد أداة واحدة ونشرها كخدمة. في المقابل ، تحتاج إلى إنشاء نموذج باستخدام طبقة مشكلة توجيه السيارة ، وتوصيلها بشكل صحيح بالعديد من الأدوات الأخرى ،
ونشر النموذج لإنشاء خدمة. أحد
الخيارات الأخرى التي يجب مراعاتها هو خدمات مشاكل توجيه المركبات في ArcGIS Online. تعمل الخدمات مثل أدوات المعالجة الجغرافية في ArcMap ،
ويمكن الوصول إليها من تطبيقات أخرى ، وتتضمن بيانات طريق عالية الجودة لمعظم
أنحاء العالم.
Input
Analysis Network
The network dataset on which the vehicle routing problem analysis will be
performed. The network dataset must have a time based cost attribute since the
VRP solver minimizes time.
Output
Layer Name
Name of the vehicle routing problem network analysis layer to create.
Time Impedance
The time cost attribute used to define the traversal time along the
elements of the network. The time cost attribute is required, since the vehicle
routing problem solver minimizes time.
Distance
Impedance (optional)
The distance cost attribute used to define the length along the elements
of the network. The distance cost attribute is optional.
Time Field
Units (optional)
The time units used by the temporal fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the time cost attribute.
· Seconds
· Minutes
· Hours
· Days
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is March
6, 2013, then the entire time value for the field is 9:00 A.M., March 6, 2013.
The default date has no effect on time field values that already have a date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time windows
is less important than reducing your overall solution cost. You may want to use
this setting if you have a growing backlog of service requests. For the purpose
of servicing more orders in a day and reducing the backlog, you can choose this
setting even though customers will be inconvenienced with your fleet's late
arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn Policy
(optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
1.
Input Analysis Network أدخل تحليل
الشبكة
The network dataset on
which the vehicle routing problem analysis will be performed. The network
dataset must have a time based cost attribute since the VRP solver minimizes
time.
مجموعة بيانات الشبكة التي سيتم إجراء تحليل مشكلة
توجيه السيارة عليها. يجب أن تحتوي مجموعة بيانات الشبكة على سمة تكلفة تستند إلى
الوقت نظرًا لأن أداة حل VRP تقلل
الوقت.
Output
Layer Name
Name of the vehicle routing problem network analysis layer to create.
Time
Impedance
The time cost attribute used to define the traversal time along the
elements of the network. The time cost attribute is required, since the vehicle
routing problem solver minimizes time.
Distance
Impedance (optional)
The distance cost attribute used to define the length along the elements
of the network. The distance cost attribute is optional.
Time Field
Units (optional)
The time units used by the temporal fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the time cost attribute.
· Seconds
· Minutes
· Hours
· Days
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
2.
Output Layer Name اسم طبقة الإخراج
Name of the vehicle
routing problem network analysis layer to create.
اسم طبقة تحليل شبكة مشكلة توجيه السيارة المراد
إنشاؤها.
Time Impedance
The time cost attribute used to define the traversal time along the
elements of the network. The time cost attribute is required, since the vehicle
routing problem solver minimizes time.
Distance
Impedance (optional)
The distance cost attribute used to define the length along the elements
of the network. The distance cost attribute is optional.
Time Field
Units (optional)
The time units used by the temporal fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the time cost attribute.
· Seconds
· Minutes
· Hours
· Days
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers at
your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn Policy
(optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
3.
Time Impedance وقت الإعاقة
The time cost attribute
used to define the traversal time along the elements of the network. The time
cost attribute is required, since the vehicle routing problem solver minimizes
time.
جدول تكلفة الوقت المستخدمة لتحديد وقت الاجتياز
على طول عناصر الشبكة. مطلوب جدول تكلفة الوقت ، نظرًا لأن أداة حل مشكلات توجيه
السيارة تقلل الوقت.
Distance
Impedance (optional)
The distance cost attribute used to define the length along the elements
of the network. The distance cost attribute is optional.
Time Field
Units (optional)
The time units used by the temporal fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the time cost attribute.
· Seconds
· Minutes
· Hours
· Days
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers at
your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
4.
Distance Impedance (optional) معاوقة
المسافة (اختياري)
The distance cost
attribute used to define the length along the elements of the network. The
distance cost attribute is optional.
جدول تكلفة المسافة المستخدمة لتحديد الطول على
طول عناصر الشبكة. جدول تكلفة المسافة اختيارية.
Time Field
Units (optional)
The time units used by the temporal fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the time cost attribute.
· Seconds
· Minutes
· Hours
· Days
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers at
your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
5.
Time Field Units (optional) وحدات
حقل الوقت (اختياري)
The time units used by
the temporal fields of the analysis layer's sublayers and tables (network
analysis classes). This does not have to be the same as the units of the time
cost attribute.
·
Seconds
·
Minutes
·
Hours
·
Days
الوحدات الزمنية المستخدمة بواسطة الحقول الزمنية
للطبقات الفرعية والجداول لطبقة التحليل (فئات تحليل الشبكة). لا يجب أن يكون هذا
هو نفسه وحدات سمة تكلفة الوقت.
• ثواني
•الدقائق
•ساعات
•أيام
6.
Distance Field Units (optional) وحدات
حقل المسافة (اختياري)
The distance units used
by distance fields of the analysis layer's sublayers and tables (network
analysis classes). This does not have to be the same as the units of the
optional distance cost attribute.
·
Miles
·
Kilometers
·
Feet
·
Yards
·
Meters
·
Inches
·
Centimeters
·
Millimeters
·
Decimeters
·
NauticalMiles
وحدات المسافة التي تستخدمها حقول المسافة للطبقات
الفرعية والجداول لطبقة التحليل (فئات تحليل الشبكة). لا يجب أن يكون هذا هو نفسه
وحدات سمة تكلفة المسافة الاختيارية.
•اميال
• كيلومترات
•قدم
• ساحات
• أمتار
• بوصة
• سم
• مليمترات
• ديسيمتر
• أميال بحرية
7.
Default Date (optional) التاريخ
الافتراضي (اختياري)
التاريخ الضمني لقيم حقل الوقت التي ليس لها تاريخ
محدد مع الوقت. إذا كان حقل الوقت لكائن ترتيب ، مثل TimeWindowStart1 ، يحتوي على قيمة للوقت فقط ، فمن المفترض أن يكون التاريخ هو
التاريخ الافتراضي. على سبيل المثال ، إذا كان لأحد الطلبات قيمة TimeWindowStart1 9:00 صباحًا والتاريخ الافتراضي هو 6 مارس 2013 ، فإن القيمة الزمنية
الكاملة للحقل هي 9:00 صباحًا ، 6 مارس 2013. ليس للتاريخ الافتراضي أي تأثير في
الوقت المحدد لقيم الحقول التي لها تاريخ بالفعل.
يمكن أيضًا تحديد يوم الأسبوع باعتباره التاريخ
الافتراضي باستخدام التواريخ التالية.
• اليوم - 12/30/1899
• الأحد - 12/31/1899
• الاثنين - 1/1/1900
• الثلاثاء - 1/2/1900
• الأربعاء - 1/3/1900
• الخميس - 1/4/1900
• الجمعة - 1/5/1900
• السبت - 1/6/1900
على سبيل المثال ، لتحديد أن التاريخ الضمني لقيم
حقل الوقت يجب أن يكون يوم الثلاثاء ، حدد قيمة المعلمة كـ 1/2/1900.
إذا كانت مجموعة بيانات الشبكة الخاصة بك تتضمن
بيانات حركة المرور ، فقد تتغير نتائج التحليل بناءً على التاريخ الذي تحدده هنا.
على سبيل المثال ، إذا بدأت مساراتك في الساعة 8:00 صباحًا يوم الأحد ، عندما لا
يكون هناك الكثير من حركة المرور ، مقابل 8:00 صباحًا يوم الاثنين خلال ساعة
الذروة ، فسيستغرق طريق الاثنين وقتًا أطول. علاوة على ذلك ، يمكن أن يتغير المسار
الأفضل اعتمادًا على ظروف حركة المرور.
8.
Capacity Count (optional) عدد السعة
(اختياري)
عدد أبعاد قيود السعة المطلوبة لوصف الحدود ذات
الصلة للمركبات. في حالة تسليم الطلبات ، قد يكون لكل مركبة قدر محدود من الوزن
والحجم الذي يمكن أن تحمله في وقت واحد بناءً على القيود المادية والقانونية. في
هذه الحالة ، إذا قمت بتتبع الوزن والحجم على الطلبات ، يمكنك استخدام هاتين
السعتين لمنع المركبات من التحميل الزائد.
عدد السعة لهذا السيناريو هو اثنان (الوزن
والحجم). اعتمادًا على المشكلة ، قد تحتاج إلى تتبع أنواع مختلفة أو كميات من
السعات. القدرات التي تم إدخالها في حقول السعة (DeliveryQuantities و PickupQuantities لفئة الطلبات والقدرات
لفئة المسارات) عبارة عن سلاسل أرقام محددة بمسافات ، والتي يمكن أن تحمل عدد
القيم المحددة في عدد السعة. يجب أن يظهر كل بُعد من أبعاد السعة في نفس الترتيب
الموضعي لجميع قيم حقل السعة في نفس طبقة تحليل VRP.
السعات نفسها غير مسماة ، لذلك لتجنب نقل أبعاد
السعة عن طريق الخطأ ، تأكد من إدخال قوائم السعة المحددة بمسافة دائمًا بنفس
الترتيب لجميع قيم حقل السعة.
9.
Time Window Violation Importance (optional) أهمية انتهاك نافذة الوقت (اختياري)
تتيح لك هذه المعلمة تقييم أهمية احترام النوافذ
الزمنية دون التسبب في انتهاكات. يحدث انتهاك النافذة الزمنية عند وصول طريق إلى
أمر أو مستودع أو فاصل بعد إغلاق نافذة زمنية. الانتهاك هو الفترة الفاصلة بين
نهاية النافذة الزمنية ووقت وصول المسار.
يمكن أن يتغير حل VRP وفقًا
للقيمة التي تختارها لمعلمة أهمية انتهاك النافذة الزمنية. تصف القائمة التالية ما
تعنيه القيم وكيف يمكن أن يختلف حل VRP
الناتج:
• مرتفع - يحاول المحلل
إيجاد حل يقلل من انتهاكات النافذة الزمنية على حساب زيادة وقت السفر الإجمالي.
اختر هذا الإعداد إذا كان الوصول في الوقت المحدد للطلبات أكثر أهمية بالنسبة لك
من تقليل التكلفة الإجمالية للحل. قد يكون هذا هو الحال إذا كنت تقابل العملاء
بناءً على طلباتك ولا تريد إزعاجهم بسبب تأخر وصولهم (هناك خيار آخر وهو استخدام
نوافذ الوقت الصعب التي لا يمكن انتهاكها على الإطلاق). مشكلة في التوجيه ، قد
يكون من المستحيل زيارة جميع الطلبات ضمن الإطارات الزمنية الخاصة بهم. في هذه
الحالة ، حتى الإعداد العالي قد ينتج عنه انتهاكات.
• متوسط - هذا هو
الإعداد الافتراضي. يبحث المحلل عن توازن بين الإطارات الزمنية للاجتماع وتقليل
التكلفة الإجمالية للحل.
• منخفض - يحاول القائم
بالحل إيجاد حل يقلل وقت السفر الإجمالي ، بغض النظر عن الإطارات الزمنية. اختر
هذا الإعداد إذا كان احترام النوافذ الزمنية أقل أهمية من تقليل التكلفة الإجمالية
للحل. قد ترغب في استخدام هذا الإعداد إذا كان لديك تراكم متزايد لطلبات الخدمة.
لغرض خدمة المزيد من الطلبات في يوم واحد وتقليل الأعمال المتراكمة ، يمكنك اختيار
هذا الإعداد على الرغم من أن العملاء سيتضايقون من وصول أسطولك المتأخر.
10.
Excess Transit Time Importance (optional) أهمية وقت العبور الزائد (اختياري)
تتيح لك هذه المعلمة تقييم أهمية تقليل وقت العبور
الزائد. وقت العبور الزائد هو مقدار الوقت الذي يتجاوز الوقت المطلوب للسفر مباشرة
بين الطلبات المزدوجة. ينتج الوقت الزائد عن فترات الراحة أو السفر إلى أوامر أو
مستودعات أخرى بين الزيارات إلى الطلبات المزدوجة.
يمكن أن يتغير حل VRP وفقًا
للقيمة التي تختارها لأهمية وقت العبور الزائد. تصف القائمة التالية ما تعنيه
القيم وكيف يمكن أن يختلف حل VRP
الناتج:
• مرتفع - يحاول القائم
بالحل إيجاد حل بوقت عبور أقل بين الطلبات المزدوجة على حساب زيادة تكاليف السفر
الإجمالية. من المنطقي استخدام هذا الإعداد إذا كنت تنقل الأشخاص بين الطلبات
المزدوجة وتريد تقصير وقت الركوب. هذه سمة من سمات خدمات سيارات الأجرة.
• متوسط - هذا هو
الإعداد الافتراضي. يبحث المحلل عن توازن بين تقليل وقت العبور الزائد وتقليل
التكلفة الإجمالية للحل.
• منخفض - يحاول القائم
بالحل إيجاد حل يقلل التكلفة الإجمالية للحل ، بغض النظر عن وقت العبور الزائد.
يشيع استخدام هذا الإعداد مع خدمات البريد السريع. نظرًا لأن السعاة ينقلون الطرود
بدلاً من الأشخاص ، فلا داعي للقلق بشأن وقت الركوب. يتيح استخدام هذا الإعداد
لشركات التوصيل خدمة الطلبات المزدوجة بالتسلسل المناسب وتقليل التكلفة الإجمالية
للحل.
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn Policy
(optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn Policy
(optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on whether
the junction represents an intersection or dead end. To accommodate this, the
U-turn policy parameter is implicitly specified by how many edges connect to
the junction, which is known as junction valency. The acceptable values for
this parameter are listed below; each is followed by a description of its
meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the relevant
limits of the vehicles. In an order delivery case, each vehicle may have a
limited amount of weight and volume it can carry at one time based on physical
and legal limitations. In this case, if you track the weight and volume on the
orders, you can use these two capacities to prevent the vehicles from getting
overloaded. The capacity count for this scenario is two (weight and volume).
Depending on the problem, you may need to track different types or amounts of
capacities. The capacities entered into the capacity fields (DeliveryQuantities
and PickupQuantities for the Orders class and Capacities for the Routes class)
are space-delimited strings of numbers, which can hold up to the number of
values specified in Capacity Count. Each capacity dimension should appear in
the same positional order for all capacity field values in the same VRP
analysis layer. The capacities themselves are unnamed, so to avoid accidentally
transposing capacity dimensions, ensure that the space-delimited capacity lists
are always entered in the same order for all capacity field values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn Policy
(optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight and
volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
Distance
Field Units (optional)
The distance units used by distance fields of the analysis layer's
sublayers and tables (network analysis classes). This does not have to be the
same as the units of the optional distance cost attribute.
· Miles
· Kilometers
· Feet
· Yards
· Meters
· Inches
· Centimeters
· Millimeters
· Decimeters
· NauticalMiles
Default
Date (optional)
The implied date for time field values that don't have a date specified
with the time. If a time field for an order object, such as TimeWindowStart1,
has a time-only value, the date is assumed to be the default date. For example,
if an order has a TimeWindowStart1 value of 9:00 AM and the default date is
March 6, 2013, then the entire time value for the field is 9:00 A.M., March 6,
2013. The default date has no effect on time field values that already have a
date.
The day of the week can also be specified as the default date using the
following dates.
· Today—12/30/1899
· Sunday—12/31/1899
· Monday—1/1/1900
· Tuesday—1/2/1900
· Wednesday—1/3/1900
· Thursday—1/4/1900
· Friday—1/5/1900
· Saturday—1/6/1900
For
example, to specify that the implied date for time field values should be
Tuesday, specify the parameter value as 1/2/1900.
If your network dataset includes traffic data, the results of the analysis
could change depending on the date that you specify here. For example, if your
routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus
8:00 a.m. on Monday during rush hour, the Monday route would take longer.
Furthermore, the best path could change depending on traffic conditions.
Capacity
Count (optional)
The number of capacity constraint dimensions required to describe the
relevant limits of the vehicles. In an order delivery case, each vehicle may
have a limited amount of weight and volume it can carry at one time based on
physical and legal limitations. In this case, if you track the weight and
volume on the orders, you can use these two capacities to prevent the vehicles
from getting overloaded. The capacity count for this scenario is two (weight
and volume). Depending on the problem, you may need to track different types or
amounts of capacities. The capacities entered into the capacity fields
(DeliveryQuantities and PickupQuantities for the Orders class and Capacities
for the Routes class) are space-delimited strings of numbers, which can hold up
to the number of values specified in Capacity Count. Each capacity dimension
should appear in the same positional order for all capacity field values in the
same VRP analysis layer. The capacities themselves are unnamed, so to avoid
accidentally transposing capacity dimensions, ensure that the space-delimited
capacity lists are always entered in the same order for all capacity field
values.
Time
Window Violation Importance (optional)
This parameter allows you to rate the importance of honoring time windows
without causing violations. A time window violation occurs when a route arrives
at an order, depot, or break after a time window has closed. The violation is
the interval between the end of the time window and the arrival time of a
route.
The VRP solution can change according to the value you choose for the Time
Window Violation Importance parameter. The following list describes what the
values mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution that minimizes time window
violations at the expense of increasing the overall travel time. Choose this
setting if arriving on time at orders is more important to you than minimizing
your overall solution cost. This may be the case if you are meeting customers
at your orders and you don't want to inconvenience them with tardy arrivals
(another option is to use hard time windows that can't be violated at
all).Given other constraints of a vehicle routing problem, it may be impossible
to visit all the orders within their time windows. In this case, even a High
setting might produce violations.
· Medium—This is the default setting. The solver looks for a balance between
meeting time windows and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall travel
time, regardless of time windows. Choose this setting if respecting time
windows is less important than reducing your overall solution cost. You may
want to use this setting if you have a growing backlog of service requests. For
the purpose of servicing more orders in a day and reducing the backlog, you can
choose this setting even though customers will be inconvenienced with your
fleet's late arrivals.
Excess
Transit Time Importance (optional)
This parameter allows you to rate the importance of reducing excess
transit time. Excess transit time is the amount of time exceeding the time
required to travel directly between the paired orders. The excess time results
from breaks or travel to other orders or depots between visits to the paired
orders.
The VRP solution can change according to the value you choose for the
Excess Transit Time Importance. The following list describes what the values
mean and how the resulting VRP solution can vary:
· High—The solver tries to find a solution with less excess transit time
between paired orders at the expense of increasing the overall travel costs. It
makes sense to use this setting if you are transporting people between paired
orders and you want to shorten their ride time. This is characteristic of taxi
services.
· Medium—This is the default setting. The solver looks for a balance between
reducing excess transit time and reducing the overall solution cost.
· Low—The solver tries to find a solution that minimizes overall solution
cost, regardless of excess transit time. This setting is commonly used with
courier services. Since couriers transport packages as opposed to people, they
don't need to worry about ride time. Using this setting allows the couriers to
service paired orders in the proper sequence and minimize the overall solution
cost.
Use
Hierarchy in Analysis (optional)
· Checked—Use the hierarchy attribute for the analysis. Using a hierarchy
results in the solver preferring higher-order edges to lower-order edges.
Hierarchical solves are faster, and they can be used to simulate the preference
of a driver who chooses to travel on freeways over local roads when
possible—even if that means a longer trip. This option is enabled only if the
input network dataset has a hierarchy attribute.
· Unchecked—Do not use the hierarchy attribute for the analysis. Not using a
hierarchy yields an exact route for the network dataset.
The parameter is disabled if a hierarchy attribute is not defined on the
network dataset used to perform the analysis.
Hierarchy
Rank Settings (optional)
Prior to version 10, this parameter allowed you to change the hierarchy
ranges for your analysis from the default hierarchy ranges established in the
network dataset. At version 10, this parameter is no longer supported. If you
want to change the hierarchy ranges for your analysis, update the default
hierarchy ranges in the network dataset.
Output
Path Shape (optional)
· TRUE_LINES_WITH_MEASURES—The output routes will have the exact shape of
the underlying network sources. Furthermore, the output includes route
measurements for linear referencing. The measurements increase from the first
stop and record the cumulative impedance to reach a given position.
· TRUE_LINES_WITHOUT_MEASURES—The output routes will have the exact shape of
the underlying network sources.
· STRAIGHT_LINES—The output route shape will be straight lines connecting
orders and depot visits as per the route sequence.
· NO_LINES—No shape will be generated for the output routes. You will also
not be able to generate driving directions.
U-Turn
Policy (optional)
The U-Turn policy at junctions. Allowing U-turns implies the solver can
turn around at a junction and double back on the same street. Given that
junctions represent street intersections and dead ends, different vehicles may
be able to turn around at some junctions but not at others—it depends on
whether the junction represents an intersection or dead end. To accommodate
this, the U-turn policy parameter is implicitly specified by how many edges
connect to the junction, which is known as junction valency. The acceptable
values for this parameter are listed below; each is followed by a description
of its meaning in terms of junction valency.
· ALLOW_UTURNS—U-turns are permitted at junctions with any number of
connected edges. This is the default value.
· NO_UTURNS—U-turns are prohibited at all junctions, regardless of junction
valency. Note, however, that U-turns are still permitted at network locations
even when this setting is chosen; however, you can set the individual network
location's CurbApproach property to prohibit U-turns there as well.
· ALLOW_DEAD_ENDS_ONLY—U-turns are prohibited at all junctions, except those
that have only one adjacent edge (a dead end).
· ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY—U-turns are prohibited at junctions
where exactly two adjacent edges meet but are permitted at intersections
(junctions with three or more adjacent edges) and dead ends (junctions with
exactly one adjacent edge). Often, networks have extraneous junctions in the
middle of road segments. This option prevents vehicles from making U-turns at
these locations.
If you need a more precisely defined U-turn policy, consider adding a
global turn delay evaluator to a network cost attribute, or adjusting its
settings if one exists, and pay particular attention to the configuration of
reverse turns. Also, look at setting the CurbApproach property of your network
locations.
Restrictions
(optional)
A list of restriction attributes to apply during the analysis.
11. Hierarchy تسلسل
12. Output Option خيارات الإخراج
13. Restrictions قيود
تم شرحهم في أداة سابقة لفهم هذه الفئات اضغط هنا للوصول الى أداة فيهم هذه الفئات مشروحة
اليك صفحه ومجموعة على الفيس بوك لتعلم أكثر بما يخص نظم المعلومات الجغرافية (GIS) و برنامج ArcGIS Pro من خلال هذه الروابط:
تعليقات
إرسال تعليق