How Resolve Road Conflicts works

The Resolve Road Conflicts tool adjusts symbolized road features so that they do not graphically overlap. Graphic overlaps typically occur when road data is displayed at a scale smaller than the one at which it was created. When an appropriate line symbol is applied, adjacent roads may conflict with one another.

How Resolve Road Conflicts works

The input features are assessed for their proximity and parallelism to one another as they are symbolized at the reference scale. They are ranked and categorized based on the value in the Hierarchy Field. Features (or portions of features) are displaced slightly to resolve graphic overlaps and clarify the display. The transition is handled smoothly when only a portion of a feature is moved. The displacement that took place can be optionally stored in a polygon output feature class. Use this feature class as an input to the Propagate Displacement tool to ensure that spatial relationships to other features are maintained.

The tool displaces features based on their spatial relationships and relative hierarchy:

• Unlike features: Unlike features have differing hierarchy values. An example is a service road running alongside a highway lane. Wherever the edges of the symbols of these features lie within 0.3 mm of each other at the reference scale, they are displaced outward to honor a 0.3 mm visual gap between them. High-hierarchy value (low importance) features are moved to accommodate low-hierarchy value (higher importance) features.

• Like features: Like features have equal hierarchy values. An example is two lanes of a highway or two lanes of a boulevard. Wherever these features are parallel (or nearly parallel) and the edges of their symbols physically overlap at the reference scale, they are displaced apart so that their symbols lie adjacent to each other with no gap. Similarly, if the two symbols are very close together, they will be snapped together so that the symbols lie adjacent to one another.

• Dead ends: Dead-end roads (dangling features not connected at one end) are shortened slightly if there is not a visually discernible space between the end and another road. This is to prevent the appearance of a connected intersection where none exists. Wherever the edge of the symbol of an unconnected road segment is less than 0.5 mm at the reference scale from another input feature, the dead end is shortened to honor the 0.5 mm spacing.

• Circles: Circular (or nearly circular) features such as roundabouts are enlarged (expanded outward) to ensure a visually discernible gap of 0.3 mm at the reference scale between the inside edges of the symbol.

Data preparation considerations

The Resolve Road Conflicts tool adjusts line features to ensure that they are graphically distinguishable when symbolized at the output scale. More than one layer can be assessed and processed at a time. It is very important that the geometry of the input features is correctly established for the tool to maintain the relationship of the features as they coexist in a transportation network. Take note of the following input data requirements and suggestions:

• Single-part features: The input features cannot contain multipart features. Use the Multipart To Singlepart tool or create a topology with a Must Be Single Part rule to convert features to single part.

• Shared segments: Input features should not overlap one another so that they share segments. Create a topology with Must Not Overlap and Must Not Self-Overlap line rules to resolve these issues. If the tool is being run with more than one input layer, create a topology with the Must Not Overlap With rule. If shared segments are detected, a warning is raised, but the tool continues to run. The ObjectIDs of the features involved are written to a log file named SharedGeom#.txt (where # is a numeral that increases incrementally with each log file generated).

• Self-intersecting features: Input line features that cross over themselves or share common start and endpoints may cause unexpected results. Create a topology with Must Not Self-Intersect line rule to identify these areas. If self-intersecting features are detected, a warning is raised and the tool will continue to process. The ObjectIDs of self-intersecting features are written to a log file named SelfIntersect#.txt (where # is a numeral that increases incrementally with each log file generated).

• Geometry below the XY tolerance: There may be some cases where there are features in the data that are below the XY tolerance specified in the map or in the environment of the tool. If features with lengths below the tolerance are detected, a warning is raised and these features are ignored by the tool. The ObjectIDs of features with geometry below the tolerance are written to a log file named GeomBelowTolerance#.txt (where # is a numeral that increases incrementally with each log file generated).

• Empty or null geometry: The input features must consist of valid geometries. If features with zero or null shape length are detected, a warning is raised and these features are ignored by the tool. The ObjectIDs of features with empty or null geometry are written to a log file named EmptyGeom#.txt (where # is a numeral that increases incrementally with each log file generated). If necessary, use the Repair Geometry tool to repair these features.

• False dead ends: A false dead end is an unconnected segment that appears visually connected when symbolized at the final map scale. These may be areas where you expect connectivity based on visual appearance, but features are not actually connected. If you process the tool without repairing the connectivity, unexpected disconnects may be visually apparent in the results. Any endpoint that is within 0.5 mm from another line segment is detected as a false dead end, taking into account the reference scale. If false dead ends are detected, a warning is raised, but the tool continues to process. Detected false dead ends are written to a log file named DeadEnd#.txt (where # is a numeral that increases incrementally with each log file generated).

• Vertices: Extraneous vertices may compromise quality and processing time. Use the Simplify Line tool to remove them if applicable.

• This tool operates by assessing graphic conflicts of symbolized features. The symbology extent and the reference scale are considered in conjunction with one another. Run this tool only after you have finalized the appearance of your symbols and ensure that the reference scale corresponds to the final intended output scale.

• An error will be raised if line and outline symbol widths equal zero. To eliminate certain features from display, consider using a definition query on the layer.

  Features detected with symbol widths equal zero are written to a log file named NoLineWidth#.txt (where # is a numeral that increases incrementally with each log file generated)

• To assess the coordinate system, the Cartographic coordinate system environment variable is used, if it is set; otherwise, the coordinate system of the data frame is used, if the tool is run in the foreground in ArcMap. If neither of these are available, the coordinate system of the input layers is used.

• The location of the log files that may be generated when warnings or errors are raised is different depending on your operating system:

  • On Windows XP, log files are written to C:\Documents and Settings\<user name>\Application Data\ESRI\GeoProcessing.
  • On Windows Vista and Windows 7, log files are written to C:\Users\<user name>\AppData\Local\ESRI\GeoProcessing.

Workflow considerations

This tool is generally most effective when used in conjunction with other generalization and graphic conflict resolution tools. Here are some tips to help you use these tools together with other layers and other tools in a workflow:

• Understand that input feature classes will be modified. This tool does not create new output road feature classes but instead modifies the input feature classes directly. Consider symbolizing the input layers with representations (with the editing property set to store geometry overrides). In this case, all modifications made by the tool are stored as geometry overrides. If the results are not acceptable, or to rerun the tool with different parameters, remove the overrides using the Remove Override tool. If the input layers are not drawn with representations, make a copy of your feature classes before processing to preserve their original state. Since the displacement that occurs resolves the conflicts, running the tool a second time should have no effect, because there will no longer be conflicts to resolve.
• Remove extraneous features first. Depending on the density of the road network, it is best to remove extraneous minor road features first to create more space to resolve conflicts. This can be done with a definition query or a selection to remove one or more classes of roads or with more refinement using the Thin Road Network tool.
• Merge roads before displacing roads. The Merge Divided Roads tool is essentially the opposite of the Resolve Road Conflicts tool. It assesses road features that are near one another and essentially parallel—usually individual lanes of a single divided road feature—and generates a representative line to use to display the road more clearly. Both approaches are valid solutions to the problem of coalescing roads. In general, at larger output scales, it is preferable to visually separate individual lanes, while at smaller scales, they should be merged to a single line. At midrange scales, it may be preferable to use both approaches for different classes of roads. If both tools will be used together in a single workflow, run Merge Divided Roads first on the relevant features and use the results of that tool as inputs to the Resolve Road Conflicts tool.
• Establish feature hierarchy. The Hierarchy Field parameter is used to identify the relative importance of road features. Typically, this corresponds to the way roads are classified and symbolized. Less significant roads are adjusted to accommodate the display of more significant ones. A hierarchy value of 1 indicates the most important roads; higher integer values indicate progressively less significant roads. For best results, don't apply more than about five classes of hierarchy to the input data. All input layers are assessed collectively for feature hierarchy, so each layer must contain a field of the same name, using the same classification values.
• Consider locking specific features. The Hierarchy Field parameter can also be used to lock features, by calculating the Hierarchy Field value to 0 for such features. A locked feature will not be moved or displaced at all. This is useful when a road cannot be shifted because of its relationship with other map features, especially continuous data such as elevation. For example, a section of road may run through a very steep, narrow valley, and it would be cartographically incorrect to move the road away from its current location. Locking can also be used to introduce barriers to the road displacement.
• Use locking to define barriers. Locking can also be used to introduce barriers to the road displacement. For example, a railways layer can be included in the Input Road Layers list along with roads. If all the railway features are assigned a hierarchy value of 0, the roads are assessed for graphic conflicts with railways and are not displaced on top of or over them, but the railway features themselves are not modified.

• The optional Output Displacement Feature Class parameter creates a feature class of polygons that indicates the amount and direction of displacement that took place. This feature class can be used for visual inspection, for spatial querying, or as an input to the Propagate Displacement tool.

Partitioning large datasets

This tool acts contextually such that adjacent and connecting features are considered when determining the final state of each individual feature. Multiple datasets can be input at once, which means they are all considered simultaneously. Using a large amount of input data (or many separate input layers) can exceed memory limitations. To avoid this limitation, consider enabling partitioning when running this tool by specifying a partition feature class in the Cartographic Partitions geoprocessing environment variable. Partitioning allows the tool to sequentially process the data in logical and manageable chunks. The input features delineated by each partition polygon is loaded into the tool, along with additional data from a buffer zone surrounding the partition. The additional data is considered as processing proceeds. This ensures that the resulting feature classes are seamless and the states of features spanning across partition boundaries are consistent.

When road conflicts are resolved with partitioning, the features that lie in the buffer beyond the border of each partition will also be modified. At the partition boundary, they will match the displacement that was made within the partition. Traveling away from the partition edge, the amount of displacement will diminish, resulting in a smooth transition. This is done so that the connectivity of the road network stays intact when each partition is processed. When the adjacent partition is processed, the diminishing displacement is detected as a conflict and resolved as normal. The result is that road displacements are consistent across partition boundaries.

Feedback on this topic?