Make OD Cost Matrix Layer (Network Analyst)

AllSource 1.3    |

Summary

Makes an origin–destination (OD) cost matrix network analysis layer and sets its analysis properties. An OD cost matrix analysis layer is useful for representing a matrix of costs going from a set of origin locations to a set of destination locations.

Usage

  • After creating the analysis layer with this tool, you can add network analysis objects to it using the Add Locations tool, solve the analysis using the Solve tool, and save the results on disk using the Save To Layer File tool.

  • When using this tool in geoprocessing models, if the model is run as a tool, the output network analysis layer must be made a model parameter; otherwise, the output layer is not added to the contents of the map.

Parameters

LabelExplanationData Type
Input Analysis Network

The network dataset on which the OD cost matrix analysis will be performed.

Network Dataset Layer
Output Layer Name

Name of the OD cost matrix network analysis layer to create.

String
Impedance Attribute

The cost attribute that will be used as impedance in the analysis.

String
Default Cutoff
(Optional)

Default impedance value at which to cut off searching for destinations for a given origin. If the accumulated impedance becomes higher than the cutoff value, the traversal stops. The default can be overridden by specifying the cutoff value on the origins.

Double
Default Number of Destinations to Find
(Optional)

Default number of destinations to find for each origin. The default can be overridden by specifying a value for the TargetDestinationCount property on the origins.

Long
Accumulators
(Optional)

A list of cost attributes to be accumulated during analysis. These accumulation attributes are for reference only; the solver only uses the cost attribute specified by the Impedance Attribute parameter to calculate the route.

For each cost attribute that is accumulated, a Total_[Impedance] property is added to the routes that are output by the solver.

String
U-Turn Policy
(Optional)

Specifies the U-turn policy that will be used at junctions. Allowing U-turns implies that 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 a dead end. To accommodate this, the U-turn policy parameter is implicitly specified by the number of edges that 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_UTURNSU-turns are permitted at junctions with any number of connected edges. This is the default value.
  • NO_UTURNSU-turns are prohibited at all junctions, regardless of junction valency. However, U-turns are still permitted at network locations even when this option is specified, but you can set the individual network location's CurbApproach property to prohibit U-turns there as well.
  • ALLOW_DEAD_ENDS_ONLYU-turns are prohibited at all junctions, except those that have only one adjacent edge (a dead end).
  • ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLYU-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. You can also set the CurbApproach property of your network locations.

String
Restrictions
(Optional)

A list of restriction attributes that will be applied during the analysis.

String
Use Hierarchy in Analysis
(Optional)
  • Checked—The hierarchy attribute will be used 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 rather than local roads when possible—even if that means a longer trip. This option is active only if the input network dataset has a hierarchy attribute.
  • Unchecked—The hierarchy attribute will not be used for the analysis, and the result will be an exact route for the network dataset.

The parameter is inactive if no hierarchy attribute is defined on the network dataset used to perform the analysis.

Boolean
Hierarchy Rank Settings
(Optional)

Legacy:

Prior to version 10, this parameter allowed you to change the hierarchy ranges for the analysis from the default hierarchy ranges established in the network dataset. At version 10, this parameter is no longer supported. To change the hierarchy ranges for the analysis, update the default hierarchy ranges in the network dataset.

Network Analyst Hierarchy Settings
Output Path Shape
(Optional)
  • NO_LINESNo shape will be generated for the output routes. This is useful when you have a large number of origins and destinations and are interested only in the OD cost matrix table (and not the output line shapes).
  • STRAIGHT_LINESThe output route shape will be a single straight line between each of the origin-destination pairs.

Regardless of the output shape type specified, the best route is always determined by the network impedance, not Euclidean distance. This means that only the route shapes are different, not the underlying traversal of the network.

String
Start Time
(Optional)

Indicates the departure time from origins.

If you have chosen a traffic-based impedance attribute, the solution will be generated given dynamic traffic conditions at the time of day specified here. A date and time can be specified as 5/14/2012 10:30 AM.

Instead of using a particular date, a day of the week can be specified 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 travel should begin at 5:00 PM on Tuesday, specify the parameter value as 1/2/1900 5:00 PM.

Date

Derived Output

LabelExplanationData Type
Network Analyst Layer

The newly created network analysis layer.

Network Analyst Layer

Environments