How Resolve Building Conflicts works

The Resolve Building Conflicts tool resolves symbol conflicts among buildings and with respect to linear barrier features by moving or hiding buildings so that they do not graphically overlap or violate spacing requirements defined by a cartographic specification.

Data preparation considerations

The Resolve Building Conflicts tool improves the display of a collection of buildings by adjusting the position, orientation, size, and visibility of buildings. The representative pattern and distribution is maintained. Graphic conflicts between buildings and between buildings and barrier features like roads are resolved. Small polygon buildings are also enlarged to a minimum size to meet a specification.

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.

Take note of the following input data requirements and suggestions:

• Input type: Input buildings must be either points or polygons. Line input building features are not accepted. Both point and polygon buildings can be assessed and resolved simultaneously by inputting more than one layer into the tool.

• Polygon building size: The Minimum Building Size parameter is used to enlarge polygon buildings to the smallest sensibly discernible size for the output scale, or to match a cartographic specification. Input point buildings are ignored with respect to this parameter. In the course of processing, some polygon buildings may be slightly reduced in size to resolve conflicts. Polygon buildings will not be reduced below the minimum building size.

• Point building size: Even if the symbols displaying point buildings are smaller than the minimum allowable building size at scale, they are not enlarged. This is based on the assumption that point buildings have been deliberately symbolized to meet a map specification or desired appearance. Typically, associated input point building features are symbolized with a marker symbol that matches this minimum polygon building size. Point buildings are rotated or moved as necessary to resolve conflict. Point rotations are stored as geometry overrides if the input layers are drawn with representations.

• Aggregated and simplified buildings: For best results, buildings should not be heavily aggregated prior to using this tool. Large aggregated buildings leave little option for movement to resolve conflicts, so a high percentage of buildings is ultimately hidden. Building footprints can be simplified prior to conflict resolution.

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

• 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 a new output road feature class(es) but instead modifies the input feature class(es) 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, simply remove the overrides using the Remove Override tool, or alternatively, remove the override of a few specific features manually during an edit session in ArcMap. If the input layers are not drawn with representations, make a copy of your feature classes before processing to preserve their original state.
• Remove extraneous features first. Depending on the density of the building distribution, it is best to remove very small or cartographically insignificant buildings first if they aren't appropriate for the final output scale. This creates more space to resolve conflicts and generally produces better results. This can be done using a layer definition query or a selection to remove polygon buildings below a certain size or point or polygon buildings that meet additional criteria.
• Establish feature hierarchy directly. The optional Hierarchy Field parameter is used to identify the relative importance of buildings. More significant buildings will take precedence at the expense of less significant ones. Less significant buildings are more likely to be moved or hidden to accommodate important buildings. A hierarchy value of 1 indicates the most important buildings; higher integer values indicate progressively less significant buildings. For best results, don't apply more than about five classes of hierarchy across the dataset. A more detailed classification increases processing time and makes it more difficult for the tool to achieve sensible solutions to densely distributed buildings. 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.
• Establish feature hierarchy automatically. The Hierarchy Field parameter is optional for the Resolve Building Conflicts tool. If it is not specified, buildings are assigned a relative importance internally based on the perimeter of the building and proximity to barriers. Perimeter is used rather than area to give more prominence to buildings that were specifically captured with high building footprint detail. Keep this in mind if you choose to simplify building footprints prior to resolving building conflicts. Larger buildings closer to more than one barrier are assessed as more significant than smaller buildings relatively far from a barrier. The Hierarchy Field parameter can be used effectively with a partially populated Hierarchy field; the significant buildings on a map can be attributed with a hierarchical value and all other features (with a NULL value) will have relative significance internally calculated.
• Force specific features to remain visible. Hierarchy values of 0 force the visibility of features, ensuring that they are not flagged for masking in the Invisibility field. These buildings are considered locally important, so the visibility and positioning of nearby buildings may be compromised more than they would if the building was not forced to remain visible. Hierarchy 0 buildings may still be transformed (moved, rotated, resized) to resolve conflicts and match other required parameters.
• Define barrier features. The Input Barrier Layers parameter lists line or polygon layers that restrict where buildings can be moved. Roads layers are typically used to prevent buildings from moving across roads. At least one barrier layer must be specified, but multiple layers can be accepted. It is important to keep in mind that the more barrier constraints there are in place, the harder it is for the tool to find acceptable conflict resolution solutions.
• Orient buildings to barrier layers. Buildings can optionally be oriented to align their dominant face to barrier features. For example, buildings can be oriented to align to nearby roads. If the Barrier Layer Orient parameter is TRUE, all buildings that meet the size and proximity requirements are oriented with respect to that barrier layer. If the parameter is FALSE, no specific orientation occurs, but nearby features may be incidentally rotated slightly in the course of conflict resolution.
  • Size requirements: All point buildings, and only polygon buildings that meet the Minimum Allowable Building Size parameter value (that is, have both bounding box sides less than or equal to the value), are oriented. This includes those buildings that have been enlarged to the minimum building size value. Larger buildings are not oriented. Buildings forced to remain visible (hierarchy = 0) are oriented only if they meet the size requirements.
  • Proximity requirements: Only buildings within two times the minimum allowable building size parameter distance away from a barrier feature are considered for orientation. This distance is measured from the graphic edge of the building symbol to the graphic edge of the barrier feature symbol.
• Move buildings in relation to barrier features. The space between buildings and barriers can be optionally controlled by the Barrier Layer Gap parameter. This value specifies the distance that all buildings must be from the barrier features. Any building graphically closer to a barrier feature than the barrier gap value is displaced outward to honor the gap distance. Buildings are not moved closer to the barrier to match this gap (unless that movement is incidentally necessary for conflict resolution). Control spacing by setting barrier layer gap values as follows:
  • Gap equal to zero: Buildings are snapped directly to the graphic edge of the barrier feature. Any building that has a portion within the Minimum Allowable Building Size value away from the graphic extent of the barrier feature is snapped to the edge of the barrier. Any building touching or overlapping the barrier feature is snapped to the edge of the barrier.
  • Gap greater than zero: Buildings are moved away from the barrier as necessary to achieve this spacing.
  • Gap in NULL: Buildings are not moved in relation to the barrier, except in the case of conflict resolution processing. This is the default.
• Remove masked features from display. Masked buildings are controlled by the Invisibility Field parameter. Buildings that the tool determines should be removed from the display to resolve conflicts are given an invisibility value of 1. Those that should remain have a value of zero. To change the visibility of a building, simply change the value in the invisibility field. To display the results on a map, add a definition query to the layer to show only visible buildings (invisibility field = 0).
• Review results. The Detect Graphic Conflict tool can be run to identify areas that the tool was not able to resolve. Run this tool with a conflict distance just below the building gap parameter to identify areas where the tool was not able to honor the building gap.
• To review the final size of buildings, add a double or float field on any of the input building feature classes called RBC_SIZE. As the tool processes, this field will be updated with the shortest side of a rotated bounding box around each feature. This field is a good way to see which features were enlarged to meet the Minimum Allowable Building Size parameter value. If the outputs are stored as shape overrides, the value will reflect the size of the shape override. If the input is point geometry, the values in this field will reflect the size of the point symbol at the reference scale.

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 building conflicts are resolved by partitioning, only the buildings that originate within or on the border of each partition will be modified. Modifications made by the tool may include resizing, rotating, moving, or not displaying. A building may even be moved outside of the partition. The barriers and buildings in the buffer zone surrounding the partition will be taken into consideration when the partition buildings are processed, but they will not be modified.

Feedback on this topic?