موقع GIS for WE نظم المعلومات الجغرافية (GIS) وبرامج ArcGIS

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 من خلال هذه الروابط:

مجموعة على الفيس بوك ArcGIS Pro من هنا.

مجموعة على الفيس بوك GIS for WE - ArcGIS Pro من هنا.

صفحة الفيس بوك GIS for WE من هنا.