ArcGIS provides tools to help you maintain the quality of your attribute data. Geodatabase attribute domains, subtypes, default values, relationship classes, and validation techniques help you maintain realistic values for the attributes of the features in your geodatabase.
Using attribute domains
Attribute domains are rules that describe the permissible values of a field type and are used to constrain the values allowed for any particular attribute for a table, feature class, or subtype. Each feature class or table can have a set of attribute domains that apply to different attributes. A given attribute domain can be shared by various feature classes and tables in a geodatabase. If a feature class has subtypes, each subtype can have a different domain associated with a given attribute. For example, a water mains feature class and a water laterals feature class can use the same domain for their ground surface type fields.
When you edit a field with a coded value domain, a drop-down list of all the domain values appears. For example, in a water network database, you might have a feature class that stores water transmission main lines. The coded value domain states that water transmission mains can have a diameter of only 10, 24, or 30 inches.
A range domain specifies a valid range of values for a numeric attribute. For example, you could have three subtypes of water mains: transmission, distribution, and bypass. Each of these could have a different range of valid pressures. Distribution water mains can have a pressure between 50 and 75 psi. For a distribution water main object to be valid, its pressure value must be between 50 and 75 psi. A range domain specifies this range of values.
When you edit a field with a coded value domain, you can only choose from a list of all the domain values so you know that you are assigning the field a valid value. When editing fields with range domains, you need to check that the attributes are valid after you have entered them to ensure the value you entered is within the range.
Result on attribute domains after splitting and merging features
Often when editing data, a single feature is split into two features or two separate features are combined, or merged, into a single feature. For example, in a landbase database, a land parcel may be split into two separate land parcels due to rezoning. Similar zoning changes may require two adjacent parcels to be merged into a single parcel.
The behavior of an attribute's values when a feature is split is controlled by its split policy, and when two features are merged, an attribute's value is controlled by its merge policy. Each attribute domain has both a split policy and a merge policy. When a feature is split or merged, ArcGIS looks to these policies to determine what values the resulting feature or features have for a particular attribute.
Editing subtypes
Subtypes are classifications within a feature class or table in a geodatabase. They allow you to logically group features based on a unique characteristic or behavior of the data. This characteristic or behavior is represented by the values of one field in the table. For example, for a table of hydrology, you could have subtypes for different types of waterways, such as creeks, streams, channels, canals, and rivers. For each of these subtypes, you could apply different topology rules, connectivity rules, default values, and relationship rules.
Subtypes are implemented as coded values, where integer values each represent a feature in the subtype. For example, in a water network database, there might be a feature class of water distribution network fittings. Rather than make different feature classes for each type of fitting, you can create one feature class with different subtypes for cap, coupling, plug, tee, and so on. Each subtype can have its own default values and domains.
Default attribute values
Feature templates allow you to assign default attribute values to new features you create using that template. When feature templates are created, they use any default values that have been specified in the geodatabase. If your feature class has geodatabase default values, they are populated automatically as the feature template's default values. For example, when working with transmission main lines, if most of the water lines you are going to create will be 24", you could set 24" as a default value for the DIAMETER field. This way, the DIAMETER attribute for any new feature you create becomes 24". However, feature template field values may differ from their geodatabase default values, in effect overriding the geodatabase default value.
You can use geodatabase default values to assign default attribute values when editing existing features as well. For example, when splitting a line feature, geodatabase default values are populated in the split feature.
Relationship classes
If you have created relationship classes between feature classes and tables in your geodatabase, you can use ArcMap editing tools to take advantage of the relationships. Using ArcMap editing tools, you can find all the objects related to a particular object and edit them. For example, you can select a parcel and find the owner of that parcel, then edit some of the attributes of that owner without ever having to add the table that stores the owners to your ArcMap session.
You can also use ArcMap editing tools to establish a new relationship between objects or to break existing relationships between objects. For example, if a parcel changes ownership, you can delete the relationship between the parcel and its original owner, then establish a new relationship with its new owner.
Relationships are also used with feature-linked annotation. Editing a feature affects its linked annotation because of the composite relationship between them. When the origin feature is moved or rotated, the linked annotation also moves or rotates with it. When an origin feature is deleted from the geodatabase, the linked annotation feature is also deleted. The annotation is also updated when you change an attribute of the feature that the annotation text is based on. When you create new features, you can have new annotation created automatically.
Validating features
Once you have edited your attributes, validate your edits. The Validate Features command on the Editor menu checks for valid subtypes and domains and for other integrity rules (such as geometric networks and relationships). If there are any invalid features, you can fix them as necessary.
Beyond topology a geodatabase supports three broad types of validation rules: attribute validation rules, geometric network connectivity rules, and relationship rules. It is important to understand that these validation rules can be broken; in certain cases, a geodatabase permits invalid objects to be stored in the database.
For example, if you have an attribute rule stating that the valid pressure range for a water distribution main in your water network is between 50 and 75 psi, the geodatabase will not prevent you from storing a value outside that range. However, a distribution main with a water pressure outside this range will be an invalid object in the geodatabase. ArcMap has many editing tools that help you identify invalid features so you can correct them.
The exceptions are edge-edge connectivity rules, edge-junction connectivity rules, and coded value attribute rules. In these cases, ArcMap takes a more active role when editing features with these rules associated with them.
The general approach to the issue of validating features is that the validation process should not result in valid features being flagged as invalid (false negatives); it is, however, allowable to have features that are invalid being reported as valid (false positives). If the geodatabase did not enforce any validation, every feature would effectively be valid. When performing validation on a particular feature, the validation occurs in five steps:
- Validate the subtype.
- Validate the attribute rules.
- Validate the network connectivity rules (if network feature).
- Validate the relationship rules.
- Perform custom validation (using optional class extension).
This strategy means the least expensive validation is performed first. The validation process stops once a feature is found to be invalid. So, for example, if a feature fails the validity test for check number 1, then checks 2, 3, 4, and 5 are never executed.
When checking connectivity and relationship rules, all associated rules must be valid. With network connectivity rules, if you specify one rule, you must specify them all. Thus, if a type of connectivity exists that doesn't have an associated connectivity rule, the network feature is deemed invalid.