3D Analyst Tools ArcToolbox

Make Vehicle Routing Problem Layer, Solve and Update Analysis Layer Attribute Parameter Tools

Make Vehicle Routing Problem Layer

How to use Make Vehicle Routing Problem Layer Tool in Arc Toolbox ArcMap ArcGIS??

Make Vehicle Routing Problem Layer

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.

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.

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.

2.    Output Layer Name

Name of the vehicle routing problem network analysis layer to create.

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.

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.

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.

1. Seconds
2. Minutes
3. Hours
4. 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.

1. Miles
2. Kilometers
3. Feet
4. Yards
5. Meters
6. Inches
7. Centimeters
8. Millimeters
9. Decimeters
10. NauticalMiles

7.    Default Date (optional)

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)

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.

1. Today—12/30/1899
2. Sunday—12/31/1899
3. Monday—1/1/1900
4. Tuesday—1/2/1900
5. Wednesday—1/3/1900
6. Thursday—1/4/1900
7. Friday—1/5/1900
8. 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.

8.    Capacity Count (optional)

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)

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.

9.    Time Window Violation Importance (optional)

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)

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:

1. 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.
2. Medium—This is the default setting. The solver looks for a balance between meeting time windows and reducing the overall solution cost.
3. 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.

10. 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.

11.  Hierarchy

12.  Output Option

13.  Restrictions

No. 11,12 and 13 were explained in a previous tool to understand these categories. Click here to access a tool in which these categories are explained.  

Solve

How to use Solve Tool in Arc Toolbox ArcMap ArcGIS??

Solve Tool

Path to access the tool

:

Solve Tool, Analysis Toolset, Network Analyst Tools Toolbox

 

Solve

Solves the network analysis layer problem based on its network locations and properties.

1.    Input Network Analysis Layer

The network analysis layer on which the analysis will be computed.

2.    Ignore Invalid Locations (optional)

Specifies whether invalid input locations will be ignored.

1. Checked—The solver will skip over network locations that are unlocated and solve the analysis layer from valid network locations only. It will also continue solving if locations are on nontraversable elements or have other errors. This is useful if you know your network locations are not all correct, but you want to solve with the network locations that are valid. This is the default.
2. Unchecked—Do not solve if there are invalid locations. You can then correct these and rerun the analysis.

3.    Terminate on Solve Error (optional) 

Specifies whether tool execution should terminate if an error is encountered during the solve.

1. Checked—The tool will fail to execute when the solver encounters an error. This is the default.
2. Unchecked—The tool will not fail and continue execution even when the solver encounters an error. All of the error messages returned by the solver will be converted to warning messages. You should use this option when background processing is enabled in your application.

4.    Simplification Tolerance (optional)

1. The tolerance that determines the degree of simplification for the output geometry. If a tolerance is specified, it must be greater than zero. You can choose a preferred unit; the default unit is decimal degrees.
2. Specifying a simplification tolerance tends to reduce the time it takes to render routes or service areas. The drawback, however, is that simplifying geometry removes vertices, which may lessen the spatial accuracy of the output at larger scales.
3. Because a line with only two vertices cannot be simplified any further, this parameter has no effect on drawing times for single-segment output, such as straight-line routes, OD cost matrix lines, and location-allocation lines.

5.    Overrides (optional)

1. Specify additional settings that can influence the behavior of the solver when finding solutions for the network analysis problems.
2. The value for this parameter needs to be specified in JavaScript Object Notation (JSON). For example, a valid value is of the following form {"overrideSetting1" : "value1", "overrideSetting2" : "value2"}. The override setting name is always enclosed in double quotation marks. The values can be either a number, Boolean, or a string.
3. The default value for this parameter is no value, which indicates not to override any solver settings.
4. Overrides are advanced settings that should be used only after careful analysis of the results obtained before and after applying the settings. A list of supported override settings for each solver and their acceptable values can be obtained by contacting Esri Technical Support.

Update Analysis Layer Attribute Parameter

How to use Update Analysis Layer Attribute Parameter Tool in Arc Toolbox ArcMap ArcGIS??

Update Analysis Layer Attribute Parameter

Path to access the tool

:

Update Analysis Layer Attribute Parameter Tool, Analysis Toolset, Network Analyst Tools Toolbox

 

Update Analysis Layer Attribute Parameter

Updates the network attribute parameter value for a network analysis layer. The tool should be used to update the value of an attribute parameter for a network analysis layer prior to solving with the Solve tool. This ensures that the solve operation uses the specified value of the attribute parameter to produce appropriate results.

1.    Input Network Analysis Layer

Network analysis layer for which the attribute parameter value will be updated.

2.    Attribute

The network attribute whose attribute parameter will be updated.

3.    Parameter

The parameter of the network attribute that will be updated. The parameters of type Object cannot be updated using the tool.

4.    Value (optional)

The value that will be set for the attribute parameter. It can be a string, number, date, or Boolean (True, False). If the value is not specified, then the attribute parameter value is set to Null.

If the attribute parameter has a restriction usage type, the value can be specified as a string keyword or a numeric value. The string keyword or the numeric value determines whether the restriction attribute prohibits, avoids, or prefers the network elements it is associated with. Furthermore, the degree to which network elements are avoided or preferred can be defined by choosing HIGH, MEDIUM, or LOW keywords. The following keywords are supported:

1. PROHIBITED
2. AVOID_HIGH
3. AVOID_MEDIUM
4. AVOID_LOW
5. PREFER_LOW
6. PREFER_MEDIUM
7. PREFER_HIGH

Numeric values that are greater than one cause restricted elements to be avoided; the larger the number, the more the elements are avoided. Numeric values between zero and one cause restricted elements to be preferred; the smaller the number, the more restricted elements are preferred. Negative numbers prohibit restricted elements.

If the parameter value holds an array, separate the items in the array with the localized separator character. For example, in the U.S., you would most likely use the comma character to separate the items. So representing an array of three numbers might look like the following: "5,10,15".