Geodatabase tables and feature classes store objects of the same type—that is, objects that have the same behavior and attributes. For example, a feature class called WaterMains may store pressurized water mains. All water mains have the same behavior and have the attributes ReferenceID, Depth, Material, GroundSurfaceType, Size, and PressureRating.
Although all objects in a feature class or table must have the same behavior and attributes, not all objects will share the same attribute domains. For example, it may be true in a water network that only transmission water mains can have a pressure between 40 and 100 psi, while distribution water mains can have a pressure of between 50 and 75 psi. You would use an attribute domain to enforce this restriction. To implement this kind of validation rule, you do not have to create separate feature classes for transmission and distribution water mains, but you would want to distinguish these types of water mains from each other to establish a separate set of domains and default values. You can do this using subtypes.
When to use subtypes
An important geodatabase design issue arises when you must decide where it is appropriate to use subtypes and where additional feature classes are required. When you distinguish objects by their default values, attribute domains, connectivity rules, and relationship rules, it is recommended that you create separate subtypes for a single feature class or table.
When you distinguish objects based on different behaviors, attributes, or access privileges or whether the objects are multiversioned, you must create multiple feature classes.
Subtype workflow
The following steps are used to create subtypes for a feature class or table:
- Set Subtype Field: Defines the field in the Input Table or Feature Class that stores the subtype codes
- Add Subtype: Adds a new subtype to the set of subtypes in a feature class or table
- Set Default Subtype: Sets a subtype's unique default value, also referred to as code.
In the following example, subtypes are created to represent different fitting types within a water pipe fittings feature class.
The first step is to define the field used to store the subtype information:
import arcpy
arcpy.env.workspace = "C:/data/Montgomery.gdb"
arcpy.SetSubtypeField_management("Water/Fittings", "TYPECODE")After the subtype field is defined, subtype codes are added to the subtype list:
arcpy.AddSubtype_management ("Water/Fittings","0", "unknown")
arcpy.AddSubtype_management ("Water/Fittings", "1", "bend")
arcpy.AddSubtype_management ("Water/Fittings", "2", "cap")
arcpy.AddSubtype_management ("Water/Fittings", "3", "cross")
arcpy.AddSubtype_management ("Water/Fittings", "4", "coupling")
arcpy.AddSubtype_management ("Water/Fittings", "5", "expansion joint")
arcpy.AddSubtype_management ("Water/Fittings", "6", "offset")
arcpy.AddSubtype_management ("Water/Fittings", "7", "plug")
arcpy.AddSubtype_management ("Water/Fittings", "8", "reducer")
arcpy.AddSubtype_management ("Water/Fittings", "9", "saddle")
arcpy.AddSubtype_management ("Water/Fittings", "10", "sleeve")
arcpy.AddSubtype_management ("Water/Fittings", "11", "tap")
arcpy.AddSubtype_management ("Water/Fittings", "12", "tee")
arcpy.AddSubtype_management ("Water/Fittings", "13", "weld")
arcpy.AddSubtype_management ("Water/Fittings", "14", "riser")The final step is to set the default subtype code:
arcpy.SetDefaultSubtype_management ("Water/Fittings", "2")