Sometimes features such as streets, cities, or places in primary address data are referenced by more than one name. For example, a highway might be known by a street name as well as a particular highway number. Street names and city names can change over time. In these instances, you may find that your address data refers to the same location by using a variety of alternate names. Alternate name tables can be used for all of the supported locator roles and support alternate names for the features in the primary reference data.
To geocode these locations, a locator can be created using an alternate name table containing alternate street names for the primary features. Using this locator, you can geocode locations based on the name specified in the primary feature class or the alternate name table.
Contents of an alternate name table
Names of features, such as streets, can change over time. For example, Jefferson Road is a new official name for the street that was previously called Old Country Road. You may have a neighborhood in a city or an official city name versus a commonly used name in which either could be used when searching for an address. For example, North Park is a neighborhood in San Diego. Searching for a feature by all of its possible names can increase the success rate of geocoding. The alternate name table contains fields for the additional names. Each record represents one name for a feature. Additional names can be added to the table.
Join ID
The alternate name table must have an ID field that can be used to join the records to the primary feature class. If the alternate name table contains multiple names for a single feature, the JoinID field will contain the same value for each alternate feature name record in the alternate name table.
The primary feature class must have a field that contains a unique ID value for each record that can be used to link to the Join ID from the alternate name table.
Note:
Do not map the ObjectID in the primary reference data and alternate name table to the Join ID locator role field when building the locator. Using the ObjectID can increase the size of the locator and reduce batch geocoding performance as well as geocoding quality.
Fields such as ObjectID, GUID, or GlobalID are not recommend for use as a join ID field to link primary features to alternate name table records when building a locator with the tool. The join ID field associated with the primary reference data role must contain a value that will be associated with many records in the primary reference data and a unique record in the alternate name table. There must be a many-to-many or many-to-one relationship between the primary data and the alternate name in the alternate name table. For example, each unique city for a Point Address locator must have one join ID value for all alternate names for that city. If Redlands is the primary city name and has a join ID value of 1, each corresponding alternate name also has the join ID value of 1. All primary records that are associated with Redlands have a join ID value of 1.
Table attributes
Depending on the locator role you choose and the type of features you want to search, attributes in the alternate name table are similar values that are found in the primary feature class. For instance, the primary attributes for street address include prefix direction, prefix type, street name, street type, and suffix direction, and the same attributes are used for the alternate names in the alternate name table.
Learn more about reference data requirements for the variety of locator roles
Note:
If the data is normalized and the primary table does not contain city name values, but the alternate name table does, for example, when building the locator, the Primary Name Indicator field can be mapped to a field in the alternate name table that contains a value that indicates if the record is the primary field (for example, True/False, Yes/No). If this field is not mapped, the first record in the alternate name table will be used as the primary value.
