The alias is one of the first characteristics of the geodatabase that will be assigned. This alias will be shown in the Contents pane when the layer is added to a project; consequently, it also could be used in a legend. The alias should be very descriptive of the data to distinguish it from other datasets.
This feature class will have fields to store data, and these fields are recorded on the second design form. From the city planner’s description, you can determine that the feature class will have fields for the subdivision name, block designation, lot designation, street address, and a land-use code. The content of the first three fields is self-explanatory. They will need to contain alphanumeric characters, so their field types will be Text.
5.On the Tables worksheet (page 2), write the name of the new feature class on the first line. Under the field name, enter the first field as Sub_Name. Note its type as Text. Add another field for Blk as Text and Lot_No as Text.
Simple so far, but there is other information to enter that will start impacting the future use of the data. The first is the field alias, which is another characteristic of the geodatabase. The alias is typically similar to the field name, with the important difference that it is allowed to have spaces in the text. This alias will be shown in many of the ArcGIS tools, the attribute table, any classification schemes, and many more places when the data is accessed. The field alias also should be descriptive of what data the field contains.
6.Next to the field name Sub_Name, write the description Subdivision Name as the alias. Then write the alias Block Designation for Blk and Lot Number for Lot_No.
Those notations have taken care of some of the fields, but there are more. The next is street address information. The address could be entered as a single field, but if you ever want to geocode against this dataset, it would be better to have each component of the address in a separate field. The common fields for geocoding are street prefix type, prefix direction, address number, street name, street type, suffix direction, and zip code. Fields such as city name or state name may be necessary if you are geocoding a broader region, but because all the features that this dataset will contain are specific to Oleander, you can leave them out. All the listed fields must be included in the table.
One interesting thing is that if the fields are given certain names that ArcGIS uses as a standard for address components, they will be filled in automatically when you make an address locator. An address locator is a special file that ArcGIS builds using your dataset that will allow addresses to be found easily when geocoding or using the Find tool. This address locator can also be used in routing and network applications. A list of preferred field names for each field is stored in the address locator style file, which was loaded when you installed ArcGIS Pro. You can open the file in the <install directory>\ArcGIS\Pro\Resources\Locators folder and view the list by searching for the phrase Preferred Field Names. You may add your own field names to the list as needed.
7.Open a file explorer window. Navigate to the folder containing your ArcGIS installation (e.g., C:\Program Files\ArcGIS\Pro\Resources), and open the Locators folder. Scroll down to the file USAddress.lot.xml, right-click, and click Open with > Notepad.
8.Use the Find tool, or scroll down to the area labeled “Reference data style for Single House.”
9.Within the section, scroll down to the area labeled Primary.House.
As you can see, there are many acceptable names for this field. The advantage of using one of these suggested field names over a new incarnation is that prebuild geocoders and geoprocessing tools will automatically recognize these field names and, in some cases, can validate that you have the correct field name chosen for a given data type. Look over the rest of the list to see what the choices are for other field types such as Primary.StreetName, Primary.Locality, or Primary.Postal. It is important to try to use one of the preset abbreviations or add your own field names to this list whenever possible. This use of existing names will make the entry of field names in certain tool parameters almost automatic. The ones shown in this geodatabase design were all derived from this list.
10.On the Tables worksheet, write the following field names, field types, and aliases:
•Pre_Type, Text, Prefix Type
•Pre_Dir, Text, Prefix Direction
•House_Num, Text, House Number
•Street_Name, Text, Street Name
•Street_Type, Text, Street Type
•Suffix_Dir, Text, Suffix Direction
•ZIP_Code, LI (Long Integer), ZIP Code
These fields will add a lot of functionality to the dataset that may be valuable later. For example, you could select all the parcels in a certain subdivision, all the parcels that front a certain street, or use the House_Num field to put address labels on the map.
The last bit of data that the city planner mentioned was the land-use code. The land-use code is split into two sets of codes. The primary land-use code is one of seven main codes, and each primary code has many secondary codes that are more descriptive of the land use. The use of two codes helps in making both a generalized land-use map and a detailed land-use map.
11.On the Tables worksheet, add the field Primary_Use, with the field type Text and the alias Primary Land Use Code, and the field Secondary_Code, with the field type Text and the alias Secondary Land Use Code.
The data entered so far has involved information that the city planner wanted. One more piece of data is necessary for you to maintain a connection to certain third-party data that is important to the project. The identity of the property owner is not stored in the parcel’s attribute table but is stored in an external table. You will need to add a field to your data structure that will allow you to set up a relationship between the field and the external table. The procedure is discussed later in the tutorial, but for now, you will need to add a field to accommodate the relationship.
12.On the Tables worksheet, add the field Georeference, with the field type Text and the alias Georeference Index.
Design for data integrity
The design looks good so far, but imagine what will happen when people start putting data in the table. If they left the Sub_Name field blank, there would be no way to identify the legal record of a piece of property. What about address number or the land-use code? These fields shouldn’t be left blank, or there could be gaps in the data. On the other hand, not every street will have a value for prefix type, so there will be instances when a field value can be left blank and still be correct. You can set up parameters in the geodatabase to control these data integrity rules.
One way to build data integrity rules into your table is to set the flag for allowing null values, or no value, for a field. If nulls are not allowed, a validation check of the data will produce an error for any records entered without all the necessary values being provided. Perhaps, as an example, the person entering the data accidentally skipped the field during data entry or tried to enter data before all the information was known. Either way, it could cause problems with your data if nulls are not allowed.
The solution is to mark in the design table which fields are allowed to have nulls and which must have a value entered.
1.On the Tables worksheet, mark the following fields to allow null values by placing a Y in the Nulls column:
•Pre_Type
•Pre_Dir
•Suffix_Dir