number, couldn’t be constrained in this way; there would be too many values. But the field street type might be a good candidate. The US Postal Service has a standard set of street type abbreviations, and from time to time, you may be asked to generate a mailing list from this table. So, it would be a good idea to add a domain to this field.
The table includes many acceptable street type abbreviations; you would not want to list all of them on the Domains form, and you wouldn’t want to type them into a domain. So, a command exists to take a file listing of street types and read them into a domain, and a file named Suffix.txt with these abbreviations is provided in the downloaded materials. The abbreviations it contains were found on a US Postal Service website, and the file contains all the recognized suffix names. The process of turning this file into a domain will be demonstrated in tutorial 2-1, but for now you can write the file name Suffix.txt on the design worksheet.
8.On the Tables worksheet, write St_Type_Abbrv as the domain name for the field Street_Type, and add (D3), noting that it is a domain.
9.Next, go to the Domains worksheet, and write the name St_Type_Abbrv, a description of Street Type Abbreviations, a field type of Text, and a domain type of Coded Values. Under Code, write the file name to identify the file holding the domain values.
Now is a good time to investigate other aspects of how the data will be used and see if there are any other data integrity techniques that might be employed—most notably, the subtypes.
Consider the situation with property. It is either platted by a legal survey or unplatted and recorded as a single deed. You might separate property as either platted (divided into developed lots with utilities) or unplatted (raw agricultural land). It is important to know the distinction for legal purposes and for the sale of property. It would be possible to put the platted land into one feature class and the unplatted property in another. If both feature classes were in the same geodatabase, they could both be easily stored and edited at the same time. The symbology and annotation would work well for both, and each feature class could have different data integrity rules. So dividing them into two feature classes would work and might be beneficial.
But consider how the data might be used in a query. If a list of all property owners in a given region was needed, it would have to come from two separate files, and exporting the list would create two tables. Although it would be beneficial in some respects to put property data into two feature classes, using the data would be problematic. That’s where subtypes can be valuable.
Using a subtype is a way to create a virtual subdivision of data within the same feature class, and then apply different data integrity rules to each category. It’s the best of both worlds: the data can be separated into logical categories and be given data integrity rules for each category but keep the convenience of being edited, queried, and managed in a single feature class. You’ll also see later, in tutorial 1-2, how subtypes can be used to set default values, establish unique attribute domains, set connectivity rules, and establish relationship rules for each subcategory created. They’ll even make it easier to symbolize and label data.
A field to contain the subtype code must be added to the table. The field type must be Integer, and the codes will be established along with a description. For this data, you’ll make a code 1 for Platted Property, code 2 for Unplatted Property, and code 3 for Plat Pending. This last code will be for property that has been approved by the city but is awaiting the filing data from the county. This will be a simple subtype, without any additional data integrity rules added.
10.On the Tables worksheet, add a new field on the bottom named Plat_Status, make its field type SI (short integer), give it an alias of Plat Status, and don’t allow for null values. Because most new property being added to the dataset will be platted, record its default value as 1. Finally, write the name Plat_Subtype for the subtype name, with a notation of (S1).
11.Go to the Subtypes worksheet (page 5). Write the name of the subtype as Plat_Subtype, and add the three codes described previously:
1 = Platted Property
2 = Unplatted Property
3 = Plat Pending
Extend the data model
This work concludes the initial design phase of the Parcels feature class, but there’s another component to investigate. When these polygons are symbolized, they can each have a solid fill and a line style for their perimeter. When maps are made, however, the boundaries of the parcels must be symbolized differently. The edge of the parcel that fronts a street will be drawn with a thicker line; the edges representing property lines between properties will be a thinner line; if someone owns two adjacent pieces of property, the line between them should be dashed.
Consider creating a set of lines that will duplicate the boundaries of each parcel. Then these lines can be symbolized as described. The only field the feature class will need is a code describing which type of line to draw. This field would benefit from having a data integrity rule (a domain) with the three categories of lines described.
A behavior will need to be created between the polygons representing property and the lines representing their boundaries. If the shape of any polygon is modified, the lines will need to automatically adjust to coincide. This type of relationship is called topology and will be discussed in chapter 7. For ArcGIS to manage this topology, the feature classes must reside within the same feature dataset.
Feature datasets are another way to segregate data inside a geodatabase. If any behavior is to be built for a feature class, such as topologies, network databases, geometric networks, relationships, or terrains, the feature class must reside in a feature dataset. For this example, you will establish a feature dataset for your feature classes, so that the corresponding topology can be built.
1.On the Geodatabase worksheet (page 1), write the name of the feature dataset as PropertyData. Next, write the new feature class name LotBoundaries on a blank line. Give it a feature type of LINE and an alias of Lot Boundaries.
2.Next, go to the Tables worksheet, and write the name of the new table as LotBoundaries. Then write the single attribute of this table, Line_Code. Give it a field type of Text, add an alias of Line Code, and do not allow nulls. Add a notation that there is a domain for this field, and name it (D4) Parcel_Line_Codes.
3.Finish by filling in the information for the domain. On the Domains worksheet (page 3), add the name of the domain as Parcel_Line_Codes, a description of Line Codes for Parcels, and a field type of Text, and note the domain type as Coded Values. Then write the three domain values described previously:
•ROW = Edge of Right-of-way
•LOT = Lot Line
•SPLIT = Split Lot Line
Design a relationship class
The
