Using parameters with network attributes

Network attribute values sometimes depend on variable conditions. For example, a vehicle's height can determine if a road segment with a low overpass is traversable or not. Present weather conditions may scale down travel speeds and thus affect network time costs. You can model restrictions based on vehicle height, travel costs based on scale factors, and other variable aspects of network analysis with one of two approaches. One method is to create a network attribute for every variation in height or weather condition; however, this approach is unwieldy as the number of permutations grows. A more versatile approach is to use a single network attribute with a parameter that contains the variable aspect of the attribute.

Parameters are placeholders for values that you can change for a particular analysis. They each have a meaningful default value that is overridden by the user when needed. In ArcCatalog, parameters are added to network attributes and referenced by the attribute's evaluators. The parameter values can be changed in ArcMap when setting up network problems so that the values of the network attribute can be determined at run time using the expression and the current parameter value.

How parameterized network attributes work

A parameterized network attribute has an evaluator that makes use of a parameter on the network attribute as well as another network attribute to help determine its value.

Because the parameter values may change at run time, the network attribute values are not written to the database; rather, they are only computed on demand. Consequently, the network dataset doesn't need to be rebuilt when the parameter value changes.

Parameters on restriction attributes

The default Restriction Usage parameter

One parameter is automatically added to any restriction attribute you create: Restriction Usage. It specifies whether the restriction attribute prohibits, avoids, or prefers travel on elements that use the restriction. If it avoids or prefers elements, you further specify the degree to which they are avoided or preferred. Specifically, Restriction Usage can be assigned any of the following values (the numeric values in parentheses are described in the Dive-in section below the list):

• Prohibit—(-1) Travel on associated network elements is completely prohibited. This is the most common restriction usage.
• Avoid: High—(5) It is very unlikely the solver will use network elements associated with the restriction.
• Avoid: Medium—(2) It is unlikely the solver will use network elements associated with the restriction.
• Avoid: Low—(1.3) It is somewhat unlikely the solver will use network elements associated with the restriction.
• Prefer: Low—(0.8) It is somewhat likely the solver will use network elements associated with the restriction.
• Prefer: Medium—(0.5) It is likely the solver will use network elements associated with the restriction.
• Prefer: High—(0.2) It is very likely the solver will use network elements associated with the restriction.

Dive-in:

Each of these seven text values is internally represented by a fixed numeric value, which is shown in parentheses in the list above. The provided text choices, and their underlying numeric values, are sufficient for almost all users. Still, if you need to fine-tune the degree to which elements are avoided or preferred, you can do so by entering your own numeric values.

To help you understand whether to enter a custom value, you need to know how they influence the solver. In general, the cost of elements with restrictions is multiplied by these numeric values to increase or decrease the cost, which in turn makes the elements less or more attractive during the analysis. Preferred elements, for instance, are multiplied by a parameter value greater than 0 and less than 1 to reduce their cost and make the solver more likely to include those elements in the results. The value Prefer: High has a value closer to 0, and Prefer: Low has a value closer to 1. (Note that entering a value of 0 isn't allowed; it causes an error at solve time.) For elements you want to avoid, the Restriction Usage numeric values are set to numbers greater than 1 since multiplying by these values increases costs. To prohibit elements, the Restriction Usage value is internally set to -1. For simplicity, you can think that Network Analyst interprets negative cost values as nontraversable, but the internal process is more involved than this.

Understand that the solver only uses these scaled costs temporarily; they are never included in the output of an analysis or in turn-by-turn directions.

To enter a custom value, simply replace the text choices (Restricted, Prefer: High, and so on), where provided, with a number. If you enter a numeric value that matches one used by a text value, the text value is displayed.

Legacy:

If you are using a network dataset from an ArcGIS version prior to 10.1, the Restriction Usage parameter won't be present on any restriction attributes; the restrictions always prohibit network elements in this case. Upgrade the network dataset to enable the option of changing restrictions to avoid or prefer elements.

Parameters for modeling vehicle characteristics

Network Analyst always adds the default parameter, Restriction Usage, to every restriction attribute. You can also add parameters for setting vehicle characteristics to refine which network elements a given vehicle can traverse.

For example, you can add a restriction attribute along with a vehicle-height parameter to compare the height of your vehicle with a descriptor attribute that holds the clearance under overpasses or through tunnels. If the vehicle height is greater than the clearance, the edge is prohibited. This can result in different routes for different vehicles: as illustrated below, a short vehicle might follow a direct route under a low bridge, whereas a tall vehicle would take a different route that avoids the low clearance.

Note:

In most cases, Restriction Usage is set to Prohibit when the restriction attribute is dependent on a vehicle-characteristic parameter. Accordingly, this subsection assumes the restriction attribute prohibits elements.

In such a scenario, you might create two attributes: a descriptor attribute and a restriction attribute, perhaps respectively naming them MaxHeight and HeightRestriction. MaxHeight would pull in clearance values from the source data, and HeightRestriction would read the values from MaxHeight and compare them with a parameter holding the current vehicle height. The diagram below shows a generalized version of this process.

Parameters on cost attributes

You might instead want a parameterized cost attribute that can reference another cost attribute and scale it. This is useful when inclement weather, like ice, fog, or heavy rain, descends on your study area and hinders the normal flow of traffic. By having a parameter already outfitted on a cost attribute, you can adjust travel-time expectations to correspond with changes in traffic speeds.

You could create two network attributes: DriveTime, to store the normal drive-time impedances with values coming from fields in your source data, and DriveTime_scaled, to take the DriveTime attribute value and scale it by a parameter on the DriveTime_scaled attribute that holds the current scale factor.

Setting up a parameterized attribute

Once you have created the necessary network attributes, you can set up the parameterized attribute, which consists of two primary steps:

1. Add a parameter to a network attribute.
2. Set up the attribute's evaluator to use the parameter.

These steps are carried out in ArcCatalog using the Attributes tab of the Network Dataset Properties dialog box.

Learn more about editing network datasets

Adding a parameter

You can follow the next steps to create a parameter. The example below is tailored for a restriction attribute, HeightRestriction, but the same procedure works for cost attributes.

A new parameter, Vehicle Height, is added to the HeightRestriction attribute and assigned a default value of 0. (With a vehicle height of 0, it is assumed the vehicle can fit under any clearance.) You can change the parameter's value from its default when you perform a network analysis in ArcMap.

Setting up the evaluator

After the parameter is added, you need to design an evaluator that incorporates the parameter and either a constant or another network attribute that stores information related to the parameter. In the example below, the parameterized restriction attribute, HeightRestriction, is assigned an evaluator that will compare the Vehicle Height parameter with the descriptor network attribute, MaxHeight, which contains the clearance measurements for network elements.

Tip:

Since the script evaluator calculates its values at the time of analysis using the VBScript or Python environment, specifying this evaluator tends to negatively affect analysis performance. Esri strongly recommends using the function evaluator instead of the script evaluator when possible for best performance during analysis.

Learn more about the types of evaluators used by a network

The function evaluator was chosen for this example. The Function Evaluators dialog box below shows the expression that is evaluated for each street. Anytime the function evaluator returns True, the network element is restricted. If it returns False, the network element isn't restricted and can be used in the solution.

For the sake of comparison, a parameterized cost attribute, DriveTime_scaled, was set up with a function evaluator (shown below) that makes use of the DriveTime Factor parameter. The evaluator reads the drive time from the DriveTime cost attribute and multiplies it by the value of the DriveTime Factor, which is specified at run time.

You can change the parameter at run time from its default value of 1. A value of 1.5 would slow drive times by 50 percent of their normal times. A network element with a DriveTime value of 5 minutes would have a DriveTime_scaled value of 7.5 minutes.

Rebuilding the network dataset

Since function evaluators don't store their values in the database but rather compute them at run time, it is not necessary to rebuild your network dataset after adding or modifying a function evaluator or corresponding attribute parameters within ArcCatalog. However, if you make changes to its related attribute based on a field evaluator, you need to rebuild the network dataset to make use of the new values.

With the parameterized attribute prepared in ArcCatalog, you can begin using it to solve network problems in ArcMap. When you change the value of the parameter from its default, there isn't a need to rebuild the network.