How Merge Divided Roads works

About the Merge Divided Roads tool

The Merge Divided Roads tool merges road segments that are parallel along a significant distance into one center line.

Matched pairs of roads or lanes are merged if they are the same road class, trend generally parallel to one another, and are within the merge distance apart. The road class is specified by the Merge Field parameter. All nonmerged roads from the input collection are copied to the output feature class.

This tool is generally used to simplify a relatively large-scale road collection at a smaller scale, where it is appropriate to depict divided highways and boulevards as a single line. At medium scales, it may be preferable to retain divided roads as separate features. In this case, you can use the Resolve Road Conflicts tool instead to ensure that symbolized lanes are displayed without symbol conflicts. If both Resolve Road Conflicts and Merge Divided Roads tools will be run on the same collection of roads, it is advisable to run Merge Divided Roads first.

Data preparation considerations

This tool is optimized for the spatial relationships typically found in a road network. Unexpected results may be produced if the tool is used to process other themes. 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 road collection. Take note of the following input data requirements and suggestions:

Caution:

A warning is raised if the input features are not in a projected coordinate system. This tool relies on linear distance units, which will create unexpected results in an unprojected coordinate system. It is strongly suggested that you run this tool on data in a projected coordinate system to ensure valid results. An error is raised and the tool will not process if the coordinate system is missing or unknown.

• 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 line 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).

  If the reference scale is unavailable, a value twice the tolerance of the spatial reference is used to detect false dead ends.

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

• Track merged features: To determine which features were detected as equal class and trending parallel for an adequate distance, add a field called MDR_TYPE (short or long integer) to the input feature class. This field will be copied to the output feature class. In the input feature class, matched pairs of roads that will be merged are coded MDR_TYPE = 1 and MDR_TYPE = -1. In the output feature class, the resulting merged road is codedMDR_TYPE = 1. You can use this information for quality control checking or to identify features that may need different symbology for a more appropriate depiction.

• Reference scale: Ensure that the reference scale is set to specify the Merge Distance parameter in page units (pt, in, mm, cm).

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

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:

• Establish road classifications appropriately. The Merge Field parameter is used to identify unique classes of roads. This will likely correspond to or be the same as the field that you use to symbolize the roads. For parallel roads to merge, they must have the same, nonzero integer merge value. If one or both features in a parallel pair have a merge value of 0, they will not be merged.

  Caution:

  In cases where very small segments of otherwise parallel-trending, equal merge value roads have incompatible values, the roads will be merged together for their entire length. The assumption is that these small anomalies are data attribution errors and not reflective of an actual change in road classification. In cases where these situations are detected, a warning message is raised and the segments in question, along with other inconsistent segments, are written to a log file named InconsistentValues#.txt (where # is a numeral that increases incrementally with each log file generated).

• Determine an appropriate merge distance. If you are not following a cartographic specification that guides you on how close features must be before merging, you may want to use the Measure tool on the Tools toolbar in ArcMap to determine an average separation distance between parallel lanes. Use a value slightly larger than this as the Merge Distance parameter.

• Merge only specific features. To ensure expected results, consider running this tool only on a selection of features, such as just divided highways, instead of the entire dataset. This will speed processing time and/or allow you to process a larger data extent at once. In this workflow, it is imperative that you reestablish connectivity of the roads following the merge. Do this by running this tool with the optional Output Displacement Feature Class parameter. Use the resulting displacement feature class as an input, along with the merged roads, in the Propagate Displacement tool to reestablish these connections. This displacement feature class can also be used with the Propagate Displacement tool to reestablish the spatial relationships of other themes whose location is relative to the merged roads.

• Understand the nature of the output features. Merged features will take the attribution, including z- and m-values, from only one of the parent features. All output features, even if they are unmerged, may undergo some line simplification during the merge process. The tolerance for this simplification is one-tenth the Merge Distance parameter value.

• Consider resolving conflicts for parallel trending features. There may be areas on your map where you want to retain multiple features, but they are too close to be symbolized and displayed clearly at your output scale. Consider running the Resolve Road Conflicts tool to displace graphically conflicting roads apart. If you will run both tools on the same road collection, it is advisable to run the Merge Divided Roads tool prior to the Resolve Road Conflicts 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. Using a large amount of input data 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 processing the Merge Divided Roads tool by partition, the resulting roads from each partition are appended into the output feature class. The roads will be split at the partition edges. Where merged roads are created, they are snapped at a common node at the partition boundary. Every effort is made to ensure consistent results across partition boundaries, but it is possible that in geometrically complex or dense areas, there may be situations where a road is snapped to an incorrect road, or a road is merged in one partition but not when it crosses into another. By adding the additional fields to the input feature class outlined below (short or long integer), you can query and display potential issues. These fields will be present and populated in the output feature class.

• MDR_TYPE: A value of 1 specifies a merged road.
  • A value of 0 specifies that the feature is not a merge candidate.
  • A value of -1 specifies that the feature is parallel on its left side to another feature (when considering the direction of a feature from its from-node to its to-node.)
  • A value of 1 specifies that the feature is parallel on its right side to another feature (when considering the direction of a feature from its from-node to its to-node.)
  • A value of 2 specifies that the feature is parallel on both sides to other features.
• MDR_SNAP:
  • A value of 0 specifies that the tool did not need to make any snapping decision.
  • A value of 1 specifies that a snap larger than the tolerance was necessary to ensure continuity at a partition boundary.
  • A value of 2 specifies that the tool had difficulty determining the correct node to use for snapping in ambiguous configurations. These areas should be examined to verify or modify the continuity of merged roads across partition boundaries.

When an input road feature exactly follows a partition boundary, for example, a road follows the county line and counties are the partition feature class, the road will appear twice in the output, once for each adjacent partition processed.