The first step to building a locator is defining what type of data you have with which to build a locator. This is done by choosing the locator role that fits your data. The locator role defines the type of data that is being used (parcel, street centerline, postal, points of interest [POI], and so on) and provides the appropriate fields that should be used when building the locator. Once created, a locator contains a snapshot of the reference data that is used for geocoding, as well as indexes and local addressing knowledge that help return the best match during the geocoding process.
When choosing a primary locator role on which to build your locator, several things should be considered, including the type of geometry in your reference data and the format of the data you want to geocode. The Point Address locator role is commonly used to model addresses at a single location. The POI role can be used for finding features that are identified by a name or code.
The following table shows some of the basic characteristics of each of the primary locator roles provided with ArcGIS Pro. These roles can be used to geocode an address with some additional zone information, such as 320 Madison St., 53606 or 329 Holiday Court, La Jolla, CA 92122. Locator roles are further extended to include an alternate name table, which allows you to geocode addresses based on the alternate name for the primary features.
Basic characteristics of locator roles provided with ArcGIS Pro
| Roles | Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
Point Address | Points or polygons Polygons recommended for optimal reverse geocoding results | Each feature represents an address. Each feature represents an address with optional subaddress elements. | All address elements in a single field | 71 Cherry Ln. W1700 Rock Rd. 38-76 Carson Rd. 15 Lakeshore Dr. Apt. 24A | Finding parcels, buildings, or address points Finding apartment units, townhouses, duplexes, or stores in a shopping plaza | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Parcel | Points or polygons Polygons recommended for optimal reverse geocoding results | Each feature represents a parcel. Each feature is identified by a parcel ID (number, APN, and so forth) or an address. | All address elements in a single field | 1760820300 1760820300, 935 Feather Ln. 935 Feather Ln. | Finding parcels or address points | 2.5; 10.8 |
Street Address | Lines | Each feature has the address range for both sides of the street segment. Each feature has a street name and optional zone name. | All address elements in a single field Address elements without a house number in a single field | 320 Madison St. N2W1700 County Rd. 105-30 Union St. 5th St. NE & Cherry St. NE Raspberry Lane, San Antonio, TX | Finding a house on a specific side of the street or street intersections Finding features by street names | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
POI | Points or polygons Polygons recommended for optimal reverse geocoding results | Each feature represents a particular geographic place-name or landmark. Each feature is identified by a text string, name, or code (code can contain numbers but must be represented by a text string). | All place-name elements in a single field | Leeds Castle, England Sapporo, Japan Cafe Cabrillo N1N115 |
Finding geographic place-names or landmarks in an area of the world Finding features that are identified by a name or code | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Distance Marker | Points | Each feature represents sequentially numbered markers placed along roads at regular intervals. | Distance marker in a single field | Mile 25 I-5 N, San Diego, CA | Finding a distance marker sign on a highway | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Distance Range | Lines | Each feature represents the distance marker range for each line segment. | Distance marker range in a single field | Carr 682 KM 4.4, Barceloneta, 00617 | Finding an approximate distance along a highway | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Postal | Points or polygons Polygons recommended for optimal reverse geocoding results | Each feature represents a single postal code region or centroid. | Postal code in a single field | 22066 B4N 1Z5 | Finding a specific postal code location | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Postal Extension | Points | Each feature represents a single postal extension centroid. | Five-digit ZIP Codes and four-digit extension in separate field | 96822-2323 | Finding a specific postal extension location | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Postal Locality | Points Polygons recommended for optimal reverse geocoding results | Each feature represents the union of postal code and city in a postal code boundary or centroid. | Postal code and city in a single field | 7132 Frauenkirchen | Finding a specific locality | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Administrative areas | Points or polygons Polygons recommended for optimal reverse geocoding results | Each feature represents a particular administrative area such as city, neighborhood, metro area, territory, region, and so on. | Administrative area name in a single field | British Columbia North Park, San Diego | Finding a specific administrative zone | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
Point Address
The Point Address locator role allows you to create locators for common addresses that contain a street number and street name. This locator role uses feature classes with polygon or point geometry as the primary reference data. Each feature in the primary reference data corresponds to a single address. For example, you can use a feature class containing building footprints or parcel centroids (the center points of parcel polygons) as the primary reference data for a Point Address locator. Each address you want to search must be present in the primary reference data. As shown below, the Point Address locator role requires that each feature in the reference data correspond to a single address value, such as a parcel or building.
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
The Point Address role also supports primary reference data that is modeled with house number ranges. A single location, such as a parcel, with multiple addresses associated with it, has a range of house number values in house number From and To fields. If there are some features that have house number ranges, all features should be modeled with ranges. The features that do not have house number ranges should use the same value for the house number From and To fields. Parity is also supported with house number ranges.
To use a feature class as reference data for a Point Address locator, it must have individual fields that contain a street number and street name information and a Shape field, as well as an optional address JoinID field that can be used to link to an alternate name table. In addition, you can specify fields that contain the street's prefix direction, prefix type, street type, suffix direction, postal code, postal extension code (such as ZIP+4 for the USA), or zone (administrative area such as city, neighborhood, and so on).
Subaddress
The Point Address locator role includes support for addresses that contain subaddress information such as identifiers for apartment units, townhouses, duplexes, or stores in a shopping plaza. Subaddresses can be found in a wide variety of residential and commercial buildings, as well as special structures and establishments such as airports, trailer parks, piers and docks, and school campuses.
Each feature in the point or polygon primary reference data corresponds to a single address with subaddress information. You can use a feature class containing building footprints or address points as reference data. Each address you want to search must exist in the reference data. Exact locations cannot be extrapolated or interpolated from any type of range of addresses on a street, unless the house number values are modeled in the reference data with house number ranges as described in the Point Address role section. As shown below, subaddresses require that each feature in the reference data corresponds to a single address value, such as buildings or address points.
Subaddress also supports primary reference data that is modeled with unit number ranges. A single location, such as a building in a shopping plaza, with multiple units associated with it has a range of unit number values in From and To fields. If there are some features that have unit number ranges, all features should be modeled with ranges. The features that do not have unit number ranges should use the same value for the unit From and To fields.
In addition to the basic address attributes, the feature class providing primary reference data for a Point Address locator that supports Subaddress may contain individual fields for building type, building name, level type, level name, unit type, and unit number.
Note:
The locator role supports three pairs of subaddress elements: Unit and Unit Type, Level and Level type, and Building Unit and Building Type. It is optional to use each pair of subaddress elements or use only one pair in the locator. You can map the pairs with fields that apply, for example, Apt F or Building A or Floor 1. Learn more about address elements in the primary reference data.
For the best results when searching for addresses that contain subaddress information, an indicator (#, Apt, Suite, Bldg, Floor) must precede the subaddress unit; otherwise, the address is matched to the record in the data that returns the highest score.
Parcel
The Parcel locator role allows you to create locators for addresses that contain parcel numbers and common addresses that contain a street number and street name. This locator role is similar to the Point Address role, but does not support addresses with subaddress information. This locator role uses feature classes with polygon or point geometry as the primary reference data. Each feature in the primary reference data corresponds to a single parcel. For example, you can use a feature class containing parcel polygons or parcel centroids (the center points of parcel polygons) as the primary reference data for a Parcel locator. Each parcel or address you want to search must be present in the primary reference data. As shown below, the Parcel locator role requires that each feature in the reference data correspond to a single parcel or address value, such as a parcel or parcel centroid.
To use a feature class as reference data for a Parcel locator, it must have individual fields that contain a parcel number or a house number, street name information, and a Shape field, as well as an optional parcel JoinID field that can be used to link to the Point Address role in a multirole locator. In addition, you can specify fields that contain the street's prefix direction, prefix type, street type, suffix direction, postal code, postal extension code (such as ZIP+4 for the USA), or zone (administrative area such as city, neighborhood, and so on).
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
The Parcel role also supports primary reference data that is modeled with house number ranges. A single location, such as a parcel with multiple addresses associated with it, has a range of house number values in house number From and To fields. If there are some features that have house number ranges, all features should be modeled with ranges. The features that do not have house number ranges should use the same value for the house number From and To fields. Parity is also supported with the house number ranges.
Street Address
The Street Address locator role allows you to create locators that support searching for common addresses with house numbers, street intersections, and only street names. One advantage of this locator role is that it permits you to provide a range of house number values for both sides of a street segment. With this, the locator can not only deliver a location along the street segment, but it can also determine the side of the street segment where the address is located.
This locator role uses feature classes with line geometry. Each feature in the primary reference data represents a street segment with two ranges of addresses that fall along that street segment, one for each side of the street.
To use a feature class as the primary reference data for the Street Address locator role, it must have four fields that contain From address and To address information for each side of the street, as well as street name information, a Shape field, and an optional JoinID field that contains an ID that can be used to link to an alternate name table that should be in the reference data. In addition, you can specify fields that contain the street's prefix direction, prefix type, street type, suffix direction, or zone.
This locator role supports normal block ranges, alphanumeric addresses with grid zone, or hyphenated addresses containing cross street information in the house number. Street intersections are also supported by this locator role. Optional fields such as ZIPL and ZIPR (Postal for each side of the street), left and right city, and state or province abbreviation fields in the reference feature class can be used.
Tables of addresses that can be geocoded against the locators created with this locator role must have an address field containing the street number and street name in addition to the street's prefix direction, prefix type, street type, or suffix direction, if any. Intersection descriptions (for example, Eureka Blvd. & Vine St.) can also be included in this field. Searching for street names is also an option with a locator created with the Street Address role, and the address field in a table of addresses must contain the street name in addition to the street's prefix direction, prefix type, street type, or suffix direction, if any.
Street Name
The Street Address locator role includes support for street names. Addresses searched based only on street name, for example, Orchard Court, Lansing MI, return a StreetName match. If an address that is searched includes the house number, a StreetName match is only returned if no other option is available. This happens when there are no house numbers associated with the street segment in the reference data. In order to create a locator that only supports StreetName matches, the reference data would need to have NULL or empty strings for each record in the house number range fields, or a single field with NULL or empty strings that is mapped to each of the From and To house number range fields from the locator role. When an address is found, the matched location is placed on the middle of the street segment.
POI
The POI (Points of Interest) locator role allows you to create locators for data that contains names of landmarks, places, or buildings. The role also allows you to create locators for address data that contains alphanumeric strings for identifying locations, such as N1N115. You can use locators created with this role to find features such as mountains, bridges, rivers, cities, and so on. Locators created with this role can also be used to find cellular towers, census tracts, and virtually any unique feature represented in a feature class. This locator role also allows you to assign categories and subcategories to each feature that can be used to limit results when geocoding, or just for additional information about the feature once it is geocoded.
Tip:
Use the Create Feature Locator tool to build a locator if you only have short, unique names or identifiers for the features in the reference data, like water meters or census block groups.
This locator role uses feature classes with point or polygon geometry as primary reference data. In addition to a feature ID field and Shape field, feature classes used as reference data for the locator must have attributes representing the names and geographical zones, such as city, state, and country, to distinguish the location of the feature, or a specific field that contains the unique name or value for that feature. You can also include the address elements of the physical address of the POI, separated into their individual fields. Optionally, a join field that contains an ID that can be used to link to an alternate name table should be in the reference data. To use categories and subcategories, the primary reference data should contain 1–2 fields that categorizes the features.
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
Tip:
If you have features that represent different types of places or locations in multiple feature classes, such as bus stops, metro stops, parks, and schools, it is recommended that you merge each of the feature classes into a single feature class since only one primary reference dataset can be used per role.
Tables of addresses that can be geocoded using this locator role must also contain the place-names and geographical zones or unique name or value that can be used to identify the locations. The geographical zone information is used to narrow down the search since it is common that the same name, such as Rochester, can be found in multiple states in the country. You can also use a locator created with the POI role to search for places by name, category, address, or a combination of name or category and parts of the address. For example, Starbucks, Orange St, Redlands or gas station, Boulder, CO.
Distance Marker
The Distance Marker locator role allows you to create locators for distance markers (sequentially numbered markers placed along roads at regular intervals). This locator role uses feature classes with point geometry, and each feature in the reference data represents a distance marker or sign.
To use a feature class as reference data for a Distance Marker locator, it must have fields that contain distance value, a unit of measure, and street name information; a feature ID field; and a Shape field.
To geocode a table of locations using a Distance Marker locator, the table must have a text field that contains all address elements in a single field in one of the following formats:
- Kilometer 152 MEX-400
- Km 152 MEX-400
- MEX-400 Kilometer 152
- MEX-400 Km 152
Distance Range
The Distance Range locator role allows you to create a locator for street segments with distance marker ranges. This locator role uses feature classes with line geometry, and each feature in the reference data represents a street segment with one range of distance markers that fall along that street segment. To use a feature class as reference data for a Distance Range locator, it must have fields that contain distance from, distance to, a unit of measure, and street name information; a feature ID field; and a Shape field.
Postal
The Postal locator role allows you to create a locator for postal codes. This locator role uses feature classes with point or polygon geometry, and each feature in the reference data represents a postal polygon or its centroid.
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
Reference data for a Postal role locator must have a field that specifies the postal code for the feature, a Shape field, optionally administrative zones, such as city, and a join field that contains an ID that can be used to link to an alternate name table.
When city name values are included with the postal codes in the reference data, the city values are stored as postal city values when building a locator. In some countries, including the United States, the postal city is returned by default when geocoding. This will affect results returned by multirole locators that include Point Address, Parcel, Street Address, or POI roles. You can change what value should be returned in the locator to the local city or the city that was matched by changing the default value for Preferred city name on the locator properties dialog box.
Tables of addresses that can be geocoded using this locator role must contain a field that has the postal code information.
Postal Extension
The Postal Extension locator role is for geocoding postal codes with extensions, such as United States ZIP+4 Codes. This locator role can be used to create locators that use point feature classes as primary reference data.
Each feature in the primary reference data source represents a postal code extension point. In addition to ObjectID and Shape fields, the reference data feature class or shapefile must have a text field that represents the postal code (in the United States, the five-digit ZIP Code) of the feature and another text field that contains the postal extension code (in the United States, the four-digit ZIP+4 Code).
To geocode a table of addresses using a Postal Extension locator, the table must have a text field that contains the entire postal code plus the postal extension code. For example, in the United States, this would be the ZIP+4 Code (the five-digit ZIP Code as well as the ZIP+4 code), as in 12345-6789, 12345 6789, or 123456789. 
Postal Locality
The Postal Locality locator role allows you to create a locator for the union of a postal code and a locality. The locator provides the ability to resolve to a more accurate location when a postal code spans multiple localities. This locator role expects feature classes where each feature in the reference data represents the union between the postal code and the locality. For example, in the image below the Redlands postal code boundary (in gray) for 92374 falls within the city boundary for Highland (in orange). Searching for 92374, Redlands will return a match, but searching for 92374, Highland will not because the reference data for the postal code does not include the area where the city and postal boundaries intersect (in the circle).
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
Reference data for a Postal Locality role locator must have a field that specifies the postal code and city for the feature, a Shape field, and optionally a join field that contains an ID that can be used to link to an alternate name table. To create reference data to use to create a locator with the Postal Locality role, use the Union tool to compute the geographic union of the city and postal code boundary feature classes in a single feature class with each datasets attributes.
Administrative areas
The Administrative area roles are for geocoding areas such as cities, neighborhoods, counties, provinces, districts, territories, and states. This role can be used to create locators that use point or polygon feature classes as primary reference data. When you build a locator with multiple roles that includes both address level and administrative areas, the administrative area polygons are used to populate missing administrative zone attributes from address data.
Note:
Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
Additional role attributes
As you look over the list of locator roles when you create a locator, you'll notice that there are other attributes to distinguish the various locator roles.
Join ID Fields
You can use a table to define alternate names for the features in your reference data feature class. Using alternate street names allows you to match an address to a feature using one of many names for the feature. For example, if Bridge Street is also known as Slash Road, you can find the same address using 266 Bridge Street as you can using 266 Slash Road.
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.
Administrative zone fields
Each role contains administrative zone fields, such as City, State, and Postal, that should be used wherever possible to further increase the likelihood of a correct match. There may be a long street that crosses multiple zones, such as Lake Shore Drive in Chicago, IL, USA, which spans the city and crosses through more than five postal codes. Given the previous example, if only a street address without the postal code is geocoded, multiple matches are returned without the ability to determine which one is correct.
Custom output fields
Each locator role allows for additional custom output fields to be added to the locator. These fields are optional. You can choose any field or fields from the reference feature class to be included as a custom output field or fields. When you search for an address using a locator that has a specified additional field, the information from the corresponding field in the reference data is displayed in the address candidates and saved in the output feature class.
Common examples include Block ID, special identifiers, or names of property owners. The additional fields saved in the output feature class can be used to join to other attribute tables or feature classes for further spatial analysis. The information can also be useful when you rematch the addresses and need additional information to determine a correct match.