The Thin Road Network tool compiles a simplified collection of roads by identifying segments that can be removed from the display without affecting the general character, density, and overall connectivity of the roads. Features that do not participate in the resulting road collection are identified by an attribute on the input layers that can be used in a definition query or in a selection to create a layer.
About Thin Road Network
Features are not actually deleted by Thin Road Network. To actually remove features, consider using the Trim Line tool.
The degree of road collection thinning is controlled by the Minimum Length parameter. The morphology and character of the road network should be considered. Typically, regular road patterns that include gridded areas, such as those common in North American cities, require a larger minimum length than more organically shaped road collections.
Use the following table as a guideline for values in map units to use with this parameter with different output scales. Refine these values as necessary to achieve desired results.
| Organic, nongridded road patterns | Regular, gridded road patterns | |||||
|---|---|---|---|---|---|---|
Final scale | Map units | Page units | Map units | Page units | ||
1:25,000 | 250 m | 825 ft. | 1 cm | 500 m | 1,650 ft. | 2 cm |
1:50,000 | 500 m | 1,650 ft. | 1 cm | 1,000 m | 3,300 ft. | 2 cm |
1:100,000 | 1,000 m | 3,300 ft. | 1 cm | 2,000 m | 6,600 ft. | 2 cm |
1:250,000 | 2,500 m | 8,250 ft. | 1 cm | 5,000 m | 16,500 ft. | 2 cm |
1:500,000 | 5,000 m | 16,500 ft. | 1 cm | 10,000 m | 33,000 ft. | 2 cm |
Data preparation considerations
You can assess multiple road layers simultaneously to ensure that all classes of roads are considered in the final display. 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 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:
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 the 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 issued, 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).
Geometry below the XY tolerance—In some cases, features in the data may be below the x,y tolerance specified in the map or in the environment of the tool. If features with lengths below the tolerance are detected, a warning is issued 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 issued 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.
Intersecting features—Lines should be split at all true intersections but not at overpasses and underpasses. This allows the tool to identify proper connections between the streets. Intersections that are not split in the appropriate place may produce unexpected results because the connectivity of the streets was not accurately assessed. Use the Features Must Not Self-Intersect and Must Not Intersect or Touch Interior topology rules to view and resolve these issues, if necessary. If intersecting features are detected, a warning is raised, but the tool continues to run. The ObjectIDs of unsplit intersections will be written to a log file named NotSplit#.txt (where # is a numeral that increases incrementally with each log file generated).
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 run the tool without repairing the connectivity, unexpected disconnects may be visually apparent in the results. Any endpoint that is within 0.5 millimeter 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 issued, 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).
In the Windows operating system, log files that are generated when warnings or errors are issued are written to C:\Users\<user name>\AppData\Local\ESRI\GeoProcessing.
Vertices—Extraneous vertices may compromise quality and processing time. Use the Simplify Line tool to remove them.
Reference scale—Ensure that the reference scale is set to specify the Minimum Length parameter in page units (pt, in, mm, cm).
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 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. 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 classification levels 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.
Use multiple invisibility fields—Although only one invisibility field is specified in the tool, consider establishing more than one in the input feature classes and run the tool multiple times using these different fields. This allows you to create and perpetuate different simplified road networks for different scales or to try a range of Minimum Length values to compare results.
- When using shapefiles, the Invisibility field value should be calculated to -1. If processed using the default value of 0, more features will be kept since the tool considers the values in this field while making decisions. If you have not processed your data or you want to process data from first principals, disregarding any previous processing, calculate the values in the this field to -1 first.
Be aware of previous runs of the data—If the state of the Invisibility field value is the starting point of the dataset, the tool takes these values into account when making decisions about each road segment. If you want to process data from first principals, disregarding any previous processing, calculate the values in this field to Null first.
Force significant features to be retained—The Hierarchy Field parameter can be used to lock features, by calculating the Hierarchy Field value to 0 for such features, to force them to remain visible in the resultant simplified road collection regardless of inferiority in length or hierarchy value. An example is a short street that contains a landmark building. Locking one road may affect adjacent road features, causing them to remain visible when they otherwise wouldn't be. This may distort the integrity of the resulting road collection, placing unexpected significance on the roads in the vicinity of a locked feature and increasing feature density in this area.
View the resulting simplified road network—To see the results of the tool, establish definition queries on layers drawing the input feature classes, for example, Invisibility <> 1. To compare to the original set of features, include a layer with no definition query. Consider drawing this layer below the other layer with the same symbology but with a transparency to easily see which features have been removed from the display. Alternatively, use the invisibility field to select all features that are not equal to 1, and create a new feature class. The advantage of leaving all features in the feature class and drawing with a definition query is that the results of the tool can be modified manually by changing the value of the invisibility field for some features.
Check symbology at road connections—The removal of some roads from the display may result in areas where road features are connected, but there is a sudden change in symbology (road classification) that may no longer be appropriate when fewer features are shown.
Consider resolving conflicts for parallel trending features—This tool typically retains features that are trending parallel to one another. When these are symbolized, their close proximity may be too dense at the intended output scale. Consider running the Merge Divided Roads tool to create a single representative line for multilane roads or the Resolve Road Conflicts tool to displace graphically conflicting roads apart.
Partitioning large datasets
This tool operates contextually such that both 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. When partitioning is enabled, the tool sequentially processes the data in logical and manageable chunks. The input features delineated by each partition polygon are 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 by partition, it is possible that roads that cross partition boundaries may be flagged by two adjacent partitions with conflicting results in Invisibility Field. To identify areas of conflict like this, add a field called TRN_DIFF to the input feature classes prior to processing. When defining the Invisibility Field value for each partition, the tool determines if the field is not empty and the new proposed value does not equal the populated value. In this case, a conflict has occurred, and the TRN_DIFF field is populated with a 1.