In a situation where we have a lot of similar features, roads for example, that we want to easily assign separate attribute values to and symbolize differently, etc., we can designate them as what Esri calls subtypes. The alternative for managing such data and information would be to create separate feature classes for, in this example, each type of road. This practice can affect the performance and ease of use of the database.
Subtypes can be created for spatial features in a feature class or for objects (records) in a nonspatial, stand alone table. Subtypes can be created based on an existing field or a new field is created to hold the subtype values.
A subtype is defined by a code and a description. The codes are stored in a field in the attribute table and must be either Short or Long Integer values. Each code value is equated to a descriptive category. Sounds a lot like a coded value domain but, as you will see, they are not the same.
In our exercise example, we will be creating road subtypes from integer values that represent six different road type categories.
Follow this link to download the data for this part of the lesson: Subtypes.zip
The zip archive contains two Esri file geodatabases:
A. Assigning features to subtypes
We are going to place roads in subtype categories according to the values in an existing field that contains integer values that represent six road type categories.
- Open ArcGIS Pro.
- Navigate to the SubtypesExercise.gdb geodatabase in the Catalog pane and take note of its two attribute domains: MaintPeriod and RoadSurface.
- Now look into the Roads feature class that resides in the SubtypesExercise.gdb geodatabase. Investigate the attribute data and the properties of the fields. The data in the RoadType field will be the basis for our subtypes, and we will see how attribute domains are involved, too.
As mentioned above an existing field containing either Long or Short Integer values can be used as the basis for establishing subtypes. The integer values 1 - 6 in the RoadType field represent the following categories of road. Each will become a subtype within our Roads feature class.
- 1 - Primary Hwy
- 2 - Secondary Hwy
- 3 - Light Duty
- 4 - Unimproved
- 5 - 4WD
- 6 - Trail
- Let's use those descriptions to establish our subtypes. Open the Subtypes View for the Roads feature class (right-click, select Design > Subtypes).
- Click the Create/Manage button on the ribbon to begin creating the subtype.
- In the Manage Subtypes dialog that appears, select RoadType as the Subtype Field.
- Skipping over the Default Subtype for now, let us proceed to enter the Code values and their corresponding Description values using the list of road types above.
- The Default Subtype should be automatically set to Primary Hwy, assuming it was the first subtype you entered. But let's assume that we know that a roads improvement project will be beginning that will result in new Light Duty type roads being created. So, let's change the Default Subtype to Light Duty.
Your Manage Subtypes dialog should look like this:
- Click OK to finishing creating the subtypes.
Upon clicking OK, you should see new headings appear in the Subtypes View, one for each of the subtypes. The Light Duty heading will be in bold, indicating that it's the default subtype. Beneath each heading, you should see two columns: Domain and Default Value. As you can probably guess, this enables you to configure each subtype to have its own domain and default value, if desired.
- Notice that, by default, the first subtype listed has become the Default Subtype. Let's change that.
- Under the Primary Hwy heading, make the following settings:
- specify the Default Value for the Surface Type field by selecting concrete from the dropdown list
- assign the MaintPeriod range domain to the MaintPeriod field (yes, the domain and the field have the same name)
- specify a Default Value of 2 (months) for the MaintPeriod field
- For each subtype, proceed to set a default value for the Surface Type field, assign the MaintPeriod range domain to the MaintPeriod field, and set a default value for the MaintPeriod field. Do so according to the following list.
- Primary Hwy | SurfaceType = concrete | MaintPeriod = 2 (already taken care of above)
- Secondary Hwy | SurfaceType = concrete | MaintPeriod = 2
- Light Duty | SurfaceType = asphalt | MaintPeriod = 6
- Unimproved | SurfaceType = cobblestone | MaintPeriod = 8
- 4WD | SurfaceType = gravel | MaintPeriod = 12
- Trail | SurfaceType = grass | MaintPeriod = 12
- Your Subtypes View should look like the following. (The green bars indicate settings that haven't been saved.)
- Be sure to click Save to apply your settings, then you may close the Subtypes View.
Now we will see what the implementation of the subtypes has put at our disposal.
- If you haven't already, add the Roads feature class to the map.
One thing that is an implication of having subtypes assigned will be readily apparent. In the Contents pane, you will see that each subtype is listed along with a distinct symbolization. Go ahead and alter the symbol for each road type if you wish.
- Now, click the Edit tab, followed by the Create button. In the Create Features pane that opens, notice that each subtype has its own editing template. This serves to reinforce that each subtype is a category unto itself.
- Go ahead and choose one of the Roads subtype editing templates, then sketch a new line feature. It doesn't need to be a real road, you're simply testing out the subtype behavior. When you complete the sketch of the new line feature, a new record appears in the attribute table, complete with the default values pertinent to whatever subtype category you chose.
- Experiment further if you wish. Save your edits if you wish.
- Close ArcGIS Pro, saving your project if you desire.
So instead of creating separate feature classes for the different road types, we put the road line features into subtypes which gave us the ability to specify unique default values for each new feature of a different road type category, and to assign, or not, certain attribute domains to each category.
B. Project - Subtype Creation
As was mentioned above, subtypes can be created for objects (records) in a nonspatial table. In this homework project, that is what you will do.
Investigate the field structure and attribute data in the Encounters table residing in the SubtypesProject.gdb geodatabase. In addition to the OBJECTID field that is automatically created by the GIS, you will find the following five fields: ID, Encounter, Category, EducationLevel, and BloodAlcohol.
The values of 1 and 2 in the Encounter field represent Distant Encounters and Close Encounters respectively.
The descriptions of the values in the Category field are as follows:
- DE-1 - Nocturnal Light
- DE-2 - Daylight Disc
- DE-3 - Radar-visual
- CE-1 - Light/object in Proximity
- CE-2 - Physical Trace
- CE-3 - Occupant
The encounter data descriptions are based on information I took from the UFO Casebook site: http://www.ufocasebook.com/Hynek.html
The values in the EducationLevel field are the number of years of school attended.
The values in the BloodAlcohol field are blood alcohol content measures. (Wikipedia Blood Alcohol Content Page/ http://en.wikipedia.org/wiki/Blood_alcohol_content)
Here is what I want you to do for this project:
- Create an attribute domain for the three Distant Encounter categories (the DE values)
- Create an attribute domain for the three Close Encounter categories (the CE values)
- Create an attribute domain for the education level data
- Create an attribute domain for the blood alcohol content data
- Create subtypes based on the values in the Encounter field and associate the appropriate attribute domains with each
- Based on the data choose a default subtype (in spite of the small sample size)
- Based on the data specify default values for the two encounter subtypes (again, in spite of the small sample size)
When finished, zip your SubtypesProject.gdb geodatabase and submit it to the Project 5 Drop Box.
It can be problematic if the result of zipping your file geodatabase results in an archive name like Sloan_SubtypesProject.gdb.zip -- the embedded .gdb needs to be avoided.