Attribute Domains (for ArcMap)

Attribute Domains

In Geography 484: GIS Database Development, you were introduced to attribute domains; however, it is possible to go through that course without having actually implemented them. So we will go over Coded Value Domains and Range Domains in the following section. Some of the material will be review for some of you, but even if you did work with attribute domains in Geography 484, you are apt to be exposed to functionality associated with them that was not covered in that course.

Follow this link to download the data for this part of the lesson: AttributeDomains.zip
The zip archive contains two Esri File Geodatabases:

• AttributeDomainExercise.gdb
• AttributeDomainProject.gdb

A. Coded Value and Range Domains

A coded value domain allows you to choose from a list of values that are allowed in a field. A range domain allows you to specify a valid range for values in a numeric field. Both types of attribute domain thus provide means of enforcing data integrity.

1. Open ArcCatalog (the standalone application, not the Catalog window in ArcMap), and look at the Properties of the Benchmarks feature class found in the AttributeDomainExercise.gdb file geodatabase. Right-click and choose Properties. Click the Fields tab and take note of the Data Type of the ELEVATION field and of the BENCHSPOT field. Close the Feature Class Properties window.
   
   Also Preview the feature class, use the picklist at the bottom of the Preview pane to view the contents of the attribute Table.
   
   The point features in the feature class represent locations of elevation benchmarks and spot elevations. The BENCHSPOT field is meant to hold an s for a spot elevation or a b for a benchmark location. A quick perusal of the values in that field shows that there are some errors. In addition, the elevation in this region ranges from about 1000 feet to about 1900 feet above sea level. We can see that there are some values in the ELEVATION field that violate that range. Our summer intern was not very meticulous.
   
   Let's create and impose a coded value domain that will limit the possible entries in the BENCHSPOT field to s and b. And let's create and impose a range domain on the ELEVATION field that will allow us to verify that the values in that field are within the correct elevation range.
   
   First, we will create a coded value domain named BenchSpotElev.
2. Right-click on the name of the AttributeDomainExercise.gdb file geodatabase and select Properties. This will open the Database Properties window.
   Select the Domains tab.
3. In the first open slot under Domain Name, type BenchSpotElev. Then in the corresponding Description slot, enter a brief description of your choice.
4. Look at the entries in the Domain Properties area. The cell next to Domain Type will let you select either Coded Values or Range. We are creating a coded value domain, so make sure it is set to the Coded Values choice.
5. We know that the values in the existing BENCHSPOT field are Text type; so now in the Domain Properties area, click in the cell to the right of Field Type, and from the picklist choose Text. While we are here, note that based on the choices in the picklist, you can create a coded value domain that can be used with six different field data types.
   After setting the Field Type to Text, the Domain Type will no longer present the Range choice; a Range domain can only be a numeric type.
6. Now in the Coded Values area, we must enter both Code values and corresponding Description values. The values s and b will be our code values, and the respective descriptions will be spot elevation and benchmark.
   
   Your Database Properties window should look like the image below. Your domain Description may be different, and hopefully without the typo that mine has.
7. If all is as it should be, hit the Apply button; this is important to do before we move on.
   

   Figure 5.1: The Database Properties dialog > Domains tab configuration for the BenchSpotElev coded value domain.
   Note: If you have a set of codes and associated descriptions in tabular form already, you can avoid the trouble of re-entering that information as outlined above by using the Table to Domain tool.  And if you are looking to automate the domain pieces of a workflow through either Model Builder or Python scripting, you may want to check out the other tools in the Domains toolset.
8. Do not close the Database Properties window. We still need to create our Range domain for elevation. Go back to the Domain Name column and add an entry named ElevationRange and enter something appropriate for the Description.
9. Change the Field Type to Long Integer and set the Domain Type to Range. Do you know why we need to set the Domain type to Long Integer?
10. Now you will see spaces in which to enter the Minimum value and the Maximum value that we wish to use to constrain the entries in the ELEVATION field in the attribute table of our Benchmarks feature class. For Minimum value, enter 1000, and for Maximum value enter 1900.
11. Your range domain setting should look like those below. Make sure they do, and hit the Apply button.
    

    Figure 5.2: The Database Properties dialog > Domains tab configuration for the ElevationRange range domain.
12. Hit the OK button to close the Database Properties window.
    
    Now we need to apply the two new attribute domains to the BENCHSPOT and the ELEVATION fields.
13. Right-click on the Benchmarks feature class, and select Properties.
    Select the Fields tab if necessary.
14. Click on the ELEVATION field name. In the Field Properties area, there should be a Domain property.
    Click in the cell next to it, and select the ElevationRange domain.
    

    Figure 5.3: Assigning the ElevationRange domain to the ELEVATION field.
15. Click the Apply button. Do not close the Feature Class Properties window.
16. Now, click on the name of the BENCHSPOT field.
    In the cell next to the Domain property, choose the BenchSpotElev domain.
    

    Figure 5.4: Assigning the BenchSpotElev domain to the BENCHSPOT field, and setting the Length property to 1.
17. Again, click the Apply button.
    And you can click the OK button to dismiss the window.
    
    Now, let's go into ArcMap and see how the attribute domains help us control attribute data integrity. In an editing session, with the desired features selected, we can find out if there are any attribute entries that violate the specifications of the attribute domains we established.
18. Open ArcMap.
19. Add the Benchmarks feature class to the data frame and open its attribute table. You will probably notice immediately that the contents of the BENCHSPOT field appear different. While the code values that are a function of having assigned a coded value domain to a field are what are stored in the database, the description values are what display by default in the open attribute table. You can control the display by going into the Table Properties menu (the icon in the upper left), selecting Appearance and checking or un-checking the box for Display coded value domains and subtype descriptions.
20. Start an editing session. Add the Editor toolbar if necessary.
21. From the Table Options list in the open attribute table, choose Select All.
22. Now, from the Editor drop down list on the Editor toolbar, select Validate Features. Two things will happen. You will see a popup that lets you know that there are five features with attribute values in violation of the attribute domain rules, and the selected set of features will be reduced to those five offending features.
    

    Figure 5.5: Popup showing how many attribute values violate attribute domain rules that are in place.
    At this point, you could go ahead and deal with the errors by editing the values in the attribute table.
23. When it comes to adding additional features and corresponding attributes with the coded value domain in place for the BENCHSPOT field, a drop-down list from which either valid value can be chosen will appear when that cell in the attribute table is edited. When it comes to the ELEVATION field, you can either periodically perform the Validate Features step as we did above, or you can go into the Table Options menu > choose Appearance | and check the box for Automatically validate records. With that set, a warning will appear any time you enter an elevation value that is not within the specified range.
    
    Take some time and experiment.
24. Close ArcMap. You can save your map document if you wish. You may want to return to it.

B. Split and Merge Policies

Additional behaviors that can accompany attribute domains allow us to define what values get assigned to the field when a feature is split into two or when two features are merged into one. According to the Esri documentation, "...merge policies are not evaluated when merging features in the Editor. However, developers can take advantage of merge policies when writing their own merge implementations." The scope of this lesson does not include developer-level exercises, so we will visit only the use of split policies.

1. In ArcCatalog, navigate to the AttributeDomainExercise.gdb file geodatabase and Preview the Roads feature class. We will be working with the SurfaceType field and the Length_Feet field.
   View the Feature Class Properties of the Roads feature class, and see that the Length_Feet field is a Float type field, and the SurfaceType field is a Text type field.
   
   Let's create a coded value domain to use with the SurfaceType field and a range domain to use with Length_Feet field.
2. Right-click on the AttributeDomainExercise.gdb file geodatabase, and go to Properties.
   Select the Domains tab.
3. Click in the cell beneath your ElevationRange domain name, and name a new domain LengthFeet, and describe it as Length range in feet.
4. In the Domain Properties area, set the Field Type to Float (do you recall why?), and set the Domain Type to Range.
5. Let's define the Minimum value as 10 and the Maximum value as 264000. We are arbitrarily deciding that when we split a line feature representing a road that no road segment can be shorter than 10 feet or longer than 50 miles (264,000 feet).
6. Now, from the picklist in the cell next to Split policy, choose Geometry Ratio. This setting will make it so that the resulting values (in feet) in the Length_Feet field are in the same ratio as that of the lengths (the geometry) of the two new line features that resulted from the split operation.
   
   Take note of the other two choices in the Split policy picklist. The Default Value is taken from the Default Value property that can be assigned to the field. We will see this below in the context of the coded value domain for the SurfaceType field. In this case, it would not make much sense to assign a default length to road segments, nor would it make sense to use the other choice, Duplicate, to assign the same length to each segment.
   
   We will not interact with the Merge policy setting since we cannot take advantage of it, as mentioned above. But go ahead and look at the choices given if you are curious.
7. Check to be sure your settings are correct, and hit the Apply button, but do not close the Database Properties window.
   

   Figure 5.6: Domain Properties > Domains tab showing settings to create LengthFeet range domain, with the Split policy property set to Geometry Ratio.
8. Next, let's set up a domain for the road surface type values. Name it RoadSurface and describe it as Road surface material.
9. Set the Field Type to Text. Note that this will force the Domain Type to be set to Coded Values. But you knew that would be the case, right?
10. Then set the Split policy to Default Value. As mentioned above, the default value is specified later in the properties of the SurfaceType field.
    (The only Merge policy setting for a coded value domain is Default value.)
11. Now, because this is a coded value domain, we need to enter the Code values and the corresponding Description values. Recall that we learned in the previous section that the codes are stored in the database (and the descriptions appear in the open table). As you noted when you previewed the data in the SurfaceType field of the Roads feature class the existing data values are grass, gravel, asphalt, concrete and cobblestone. We will go ahead and retain those as the code values and set the description values to match. A "code" does not have to be a numeral or a single character (like the s and b used for the Benchmarks above). So go ahead and enter the five surface type category names in both the Code list and the Description list of the Coded Values area. Take care to spell the code entries correctly. A misspelling would result in the existing values in the SurfaceType field not taking part in the domain.
12. Hit the Apply button when certain you have entered the correct settings -- the RoadSurface domain settings should look like this:
    

    Figure 5.7: Domain Properties > Domains tab showing settings to create RoadSurface coded value domain, with the Split policy set to Default Value.
13. Hit the OK button to dismiss the Database Properties window.
    
    Now, let's assign the two new domains to the respective fields in the Roads feature class attribute table.
14. Still in ArcCatalog, right-click on the Roads feature class and select Properties to open the Feature Class Properties window.
15. You've done this before, In the Field Name list, click on the Length_Feet field, then in the Field Properties area assign the LengthFeet domain to the Domain property of the field.
    

    Figure 5.8: Assigning the LengthFeet domain to the Length_Feet field.
16. Hit Apply.
17. Next, click the SurfaceType field, and assign the RoadSurface domain to it. Note that the BenchSpotElev domain also appears in the picklist. Why, do you suppose?
18. Also, in the cell next to Default Value in the Field Properties area, type asphalt. Recall that above we set the Split policy for the RoadSurface domain to Default Value. We are now specifying that default value; it needs to be one of the Code values that is part of the RoadSurface domain. Spell it correctly.
    We can say that we know that most of the future work on the road system in this area will be done by the State, so the "asphalt" surface type is most apt to be involved; hence, we can set it as the default.
    

    Figure 5.9: Assigning the RoadSurface domain to the SurfaceType field, and setting the Default Value to 'asphalt', and the Length property to 25.
19. Hit Apply, then hit OK.
    
    Now, in ArcMap, let's see the behavior imposed on the data by two domains when we perform some edits.
20. Open ArcMap, and add the Roads feature class to the data frame.
21. Open the Roads feature class attribute table.
22. Start an editing session.
23. Select the U.S. Hwy 62 feature; you can click on it in the attribute table. Note the Length_Feet value (23128.34), and the SurfaceType value (concrete).
24. Select the Split Tool from the Editor toolbar, and arbitrarily choose a point on the selected line feature and perform a split. You might want to invoke the Edge Snapping to aid you.
    What happens? If you go to select the U.S. Hwy 62 line feature, it should be in two parts, and there should also be a new record in the attribute table at the bottom.
    What happened to the SurfaceType value for both of the features that are now the U.S. Hwy 62? Are they still "concrete"? Why not?
    What are the Length_Feet values for the two features? Do they add up to 23128.34?
    
    You can use the Undo tool on the standard toolbar to revert to pre-split status if you want to compare the before and after.
25. Experiment with editing some of the other features if you wish.
26. Save your map document if you want, and quit ArcMap.

C. Project - Attribute Domains

For the homework deliverable for this part of the lesson, I am going to have you create two attribute domains to be assigned to existing fields in a feature class attribute table.

You will use the behavior functionality that the domains give you to find several attribute errors that reside in the dataset.

The data you will use is found in the AttributeDomainsProject.gdb file geodatabase. That geodatabase contains a single feature class named BuildingFootprints.

1. Create an attribute domain for the Bldg_Type field (alias Building Type). The three allowed values for the field include C (commercial), R (residential), and P (public). NULL values are also allowed when the building category is not known.
2. The Bldg_Story field (alias Building Stories) should contain values no larger than 7. Create an attribute domain that will allow you to verify that values in that field do not violate that stipulation.
3. Make and submit a screen capture showing the results of discovering the errors that exist in the two fields in question. The image should show (1) the selected offending records in the attribute table, and (2) the popup showing the number of offending records.
4. Submit your AttributeDomainsProject.gdb file geodatabase to the Lesson 5 drop box.
   
   Following are some instructions on how to zip up both your image file and your AttributeDomainsProject.gdb file geodatabase.
   
   In Lesson 5, we are dealing with File Geodatabases. Your AttributeDomainsProject.gdb geodatabase is a folder even though it has the .gdb extension on the name. To compress your file geodatabase along with your screen captured image in order to submit them, do the following:
   1. In a Windows Explorer or a (My) Computer window, select both the geodatabase folder and your Word document file. The assumption is that the geodatabase and the image file are in the same folder, making it possible to select them both.
   2. Then right-click on one of them and choose Send To | Compressed (zipped) Folder.
      
      That will create a .zip file in the same folder. You need to turn in this .zip file. If, for some reason, you do not have the option to compress from within the Windows operating system, you can download a free application called 7-Zip. It works well.
   3. Name your .zip file appropriately, something like: <your name>_Lesson5Domains.zip.

D. Summary

Because attribute domains are stored in the geodatabase, they can be used by any dataset: feature class, table, subtype (covered in the next part of the lesson), within the geodatabase.

You can now move on to the Subtypes part of the lesson.