3.1 Attribute Domains (Coded Value and Range Domains)

Attribute Domains in ArcGIS Pro

Quick Answer: Attribute domains are rules created at the geodatabase level that enforce data integrity by restricting the values that can be entered into specific fields. They prevent data entry errors and ensure consistency across your feature classes and tables.

Data integrity is a cornerstone of GIS. When multiple users are editing a geodatabase, ensuring that attribute values remain accurate, consistent, and logically valid is paramount. In ArcGIS Pro, attribute domains serve as the primary mechanism for enforcing these rules. By defining what values are permissible in a field, domains eliminate typos, standardize terminology, and prevent the entry of impossible measurements.

Understanding Attribute Domains

An attribute domain is a property of the geodatabase itself, not a specific feature class or table. This means that a single domain can be applied to multiple fields across different feature classes within the same geodatabase. For example, a domain defining "Pipe Material" (PVC, Iron, Copper) can be applied to water mains, service lines, and sewer pipes.

There are two primary types of attribute domains in ArcGIS Pro: Coded Value Domains and Range Domains.

Coded Value Domains

Coded value domains provide a predefined list of acceptable values for a field. When an editor interacts with a field that has a coded value domain applied, they are presented with a drop-down menu instead of a free-text entry box. This is particularly useful for text fields but can also be applied to numeric fields.

Key Characteristics:

• Data Types: Can be applied to Text, Short Integer, Long Integer, Float, Double, and Date fields.
• Structure: Consists of a "Code" (the actual value stored in the database) and a "Description" (the human-readable text displayed in the user interface).
• Use Cases: Zoning codes (R1, R2, C1), tree species, pipe materials, road surface types.

Range Domains

Range domains specify a minimum and maximum allowable value for a numeric or date field. Any attempt to enter a value outside this specified range will result in a validation error, preventing the data from being saved.

Key Characteristics:

• Data Types: Restricted to numeric types (Short Integer, Long Integer, Float, Double) and Dates.
• Structure: Requires a strictly defined Minimum Value and Maximum Value.
• Use Cases: Pipe diameters (e.g., between 2 and 48 inches), water pressure (e.g., 0 to 150 psi), historical dates.

Domain Creation and Management

In ArcGIS Pro, domains are managed in the Domains View. This tabular interface allows you to view, create, modify, and delete domains for the entire geodatabase.

To create a domain:

1. Open the Domains View from the Data tab.
2. Enter a unique Domain Name and an optional Description.
3. Select the Field Type (e.g., Text, Long Integer).
4. Select the Domain Type (Coded Value or Range).
5. Define the specific codes/descriptions or the min/max range.
6. Save the changes to the geodatabase.

Applying Domains to Fields

Creating a domain does not automatically enforce it. The domain must be explicitly applied to a field. This is done in the Fields View of the specific feature class or table. You select the field and choose the appropriate domain from the Domain drop-down menu. Once applied and saved, the domain immediately governs data entry for that field.

Split and Merge Policies

When editing GIS data, features are frequently modified. A polygon might be split into two smaller parcels, or two adjacent line segments might be merged into one. When these geometric operations occur, ArcGIS Pro needs to know how to handle the attributes of the resulting features. This is governed by Split Policies and Merge Policies, which are defined as part of the attribute domain.

Split Policies

When a single feature is split into two or more new features, the split policy dictates how the original attribute values are distributed among the new features.

There are three types of split policies:

1. Duplicate: The attribute value of the original feature is copied identically to all new features.
   • Example: A parcel zoned "Commercial" is split. Both new parcels remain zoned "Commercial".
2. Default Value: The attribute value of the new features is set to the default value defined for that field (or subtype).
   • Example: A pipe is split. The "Installation Date" for the new segments reverts to the default (e.g., the current date).
3. Geometry Ratio: The attribute value of the new features is calculated based on the ratio of the new geometry to the original geometry. This is only applicable to numeric fields.
   • Example: A parcel with an assessed value of $100,000 is split exactly in half. Each new parcel receives an assessed value of $50,000.

Merge Policies

When two or more features are combined into a single new feature, the merge policy determines how the attribute values of the original features are combined.

There are three types of merge policies:

1. Default Value: The attribute value of the new merged feature is set to the default value defined for that field.
   • Example: Two parcels with different zoning are merged. The new parcel takes on the default zoning code.
2. Sum Values: The attribute values of the original features are added together. This is only applicable to numeric fields.
   • Example: Two parcels, one with an area of 5 acres and another with 3 acres, are merged. The new feature's attribute is set to 8 acres.
3. Weighted Average: The attribute value of the new feature is calculated as a weighted average of the original values, based on their geometry (length or area).
   • Example: Two crop fields with different expected yields per acre are merged. The new yield attribute reflects a geometry-weighted average of the two original yields.

Best Practices for Domain Management

• Plan Before Creating: Map out all required domains before building the geodatabase schema to maximize reusability.
• Use Consistent Naming: Adopt a naming convention (e.g., dom_MaterialType) to easily identify domains in the drop-down lists.
• Avoid Hardcoding When Possible: Use domains instead of hardcoding validation logic into client applications; this ensures the rules apply regardless of how the geodatabase is accessed.
• Review Split/Merge Policies Carefully: The default policy is often "Default Value", which may not be appropriate for all fields, especially those representing quantities like cost or area.