Use 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 approach 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. Parameters are added to network attributes and referenced by the attribute's evaluators. The parameter values can be changed 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 one or more assigned evaluators that make use of a parameter on the network attribute as well as another network attribute to help determine its value.

Some evaluator assignment values are cached upon network build (for example, Field Script) and do not use parameters. However, evaluators that are queried at run time to determine their value (for example, Function and Element Script) can utilize parameters to affect the result value.

Parameters for modeling vehicle characteristics

In the following example, you can add parameters for setting vehicle characteristics to refine which network elements a given vehicle can traverse.

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.

Example of a truck routing around a bridge with a low clearance

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 following diagram shows a generalized version of this process:

Finding values for a parameterized restriction attribute

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, such as 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.