The first step to building a locator is defining what type of data you will use to build a locator. This is done by choosing the locator role that fits the 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 to use 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, there are several things to consider, 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. You can use the POI role to find 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. You can use these roles 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.
Point Address
Basic characteristics of the Point Address role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 Laurel Cottage, 26 Pinhoe Rd. | Point Address, Subaddress | 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. 2.8; 10.8.1; Support Subaddress as a feature type for reverse geocoding. |
The Point Address locator role allows you to create locators for common addresses that contain a building name or house number and street name. An address can have both a building name and a house number. 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, you must model all features with ranges. The features that do not have house number ranges are included in the locator if the house number value is stored in either the house number From or To field. This works similar to having the same value in both fields in the reference data. Parity is also supported with house number ranges.
Note:
When building a Point Address locator, if the house number and house number from and to fields are mapped, the values in the house number field are ignored and the values in the house number from and to fields are used to build the locator.
Additionally, the Point Address role supports house number extensions, which duplexes and divided lots can have but are stored in a single field represented as the house number or complete house number, for example, 2B Wingate Rd. or 20 1/2 Rocky Knoll Dr. While 20 Rocky Knoll Dr. was the assigned address of the original building, 20 1/2 was assigned to the adjacent building when the lot was subdivided. A suffix such as B or 1/2 is often used as a house number suffix. Although it is not common, prefixes, such as 28R in 28R 17 Oak St, can be used as a house number prefix. Concatenate all of the house number components (house number prefix, house number, house number suffix) into a single field and use it as the house number field when building the locator. When searching for an address that contains an alphanumeric house number, the full house number, such as 28R in 28R 17 Oak St, must be typed to return suggestions for the address.
To use a feature class as reference data for a Point Address locator, it must have individual fields that contain a house number or building name and street name information, an ObjectID field and a Shape field, as well as an optional address JoinID field that you can assign to the Address Join ID locator role field to link to an alternate name table for alternate house numbers or alternate house number ranges. You can use this, for example, to model English transliteration of Cyrillic house numbers. 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 (an administrative area such as city, neighborhood, and so on). You must also include an optional parcel JoinID field in the reference data if you want to use the Point Address role in conjunction with the Parcel locator role in a multirole locator. To link the address points to the parcels, assign the parcel JoinID field to the Parcel Join ID locator role field. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as POINT_ADDRESS_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
Note:
When you build the locator with the Point Address role, you must map either Building Name, House Number, both House Number From and House Number To, or both Building Name and House Number.
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 are 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. The base address and associated subaddresses must have the exact same admin zones and postal codes to link the subaddresses to the base address. 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.
Note:
To search for the base address, 36 Orchard Ct, using a locator that supports subaddresses, a feature must exist for the base address with no values in the Unit field in the primary reference data.
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, you must model all features with ranges. The features that do not have unit number ranges are included in the locator if the unit value is stored in either the unit From or To field. This works similar to having the same value in both fields in the reference data.
Note:
When building a Point Address locator that supports subaddress, if the unit and unit from and to fields are mapped, the values in the unit field are ignored and the values in the unit from and to fields are used to build the locator.
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 unit name, level type, level name, unit type, and unit name.
Note:
This locator role supports three pairs of subaddress elements: Unit and Unit Type, Level and Level type, and Building Unit and Building Unit Type. You can optionally 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. When searching for an address that contains a subunit, the full subaddress element, such as Unit 101 in 35 Orchard Ct, Unit 101, must be typed to return a match for the subaddress location. If there are multiple subaddresses at an address, there are several options available for returning subaddress information or subaddress candidates as a suggestion in the Locator Properties dialog box. The default subaddress suggest behavior is to type the address and the full subaddress name.
- To return a summary of the subaddress units at an address after the
base address is entered, you must enable the Show summary of
subaddresses with base address suggestion setting. The summary will not show as a suggestion if a base address feature (a feature without values in the Unit field) does not exist in the primary reference data.
- You must enable the Suggest as partial unit is typed suggestion setting
to return valid subaddress suggest candidates after typing part of
the subaddress name with or without an indicator.
- To return a list of subaddresses after entering the base address, enable the Suggest when base address is typed suggestion setting. The list of subaddress suggestions will not show if a base address feature (a feature without values in the Unit field) does not exist in the primary reference data.
Note:
Subaddresses will not be suggested when the base address and associated subaddresses do not have the exact same admin zones, such as city, neighborhood, subregion and region. The base address and subaddresses must to have the exact same street components, admin zones, and postal codes to link to each other. A feature that represents the base address with no values in the Unit field must be present in the locator to see the summary of the subunits after typing the base address.
Parcel
Basic characteristics of the Parcel role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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. | Parcel | Finding parcels or address points | 2.5; 10.8 |
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 searching for addresses with subaddress information. However, does support subaddresses that work similar to subaddress support for the POI role. 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, an ObjectID field, and a Shape field, as well as an optional parcel JoinID field that you can assign to the Parcel Join ID locator role field 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 United States), or zone (an administrative area such as city, neighborhood, and so on). The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as PARCEL_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
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, you must model all features with ranges. The features that do not have house number ranges are included in the locator if the house number value is stored in either the house number From or To field. This works similar to having the same value in both fields in the reference data. Parity is also supported with the house number ranges.
Note:
When building the locator, if the house number and house number from and to fields are mapped, the values in the house number field are ignored and the values in the house number from and to fields are used to build the locator.
Tables of addresses that you can geocode using this locator role must contain the parcel number or both parcel address and an administrative area, such as neighborhood, city, or postal code. Locators created with this locator role support the following search scenarios:
- Search by the exact parcel number when only the parcel number is assigned to the Parcel Name locator role field when building the locator.
- Search by the parcel address when parcel number and address fields are assigned when building the locator. You can also search for just the parcel number when the locator is built in this way.
- Search by parcel number and address when parcel number and address fields are assigned when building the locator. You can also search for just the parcel number when the locator is built in this way.
Street Address
Basic characteristics of the Street Address role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Street Address, Intersection, Street Name | 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. |
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, an ObjectID field, a Shape field, and an optional JoinID field that contains an ID that you can assign to the Street Join ID locator role field to link to an alternate name table 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. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as STREET_SEGMENT_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
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. You can use 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.
Tables of addresses that you can geocode 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. You must include at least one administrative area such as city or postal code in a separate field to improve geocoding quality when matching addresses that have the same street name.
Hyphenated ranges
The Street Address locator role includes support for hyphenated house number ranges, which depict a number that is usually the number of the cross street followed by a hyphen, and then the actual number of the house along the street (for example, 76-20 34th Ave). One location that uses this type of address style is Queens, New York. The first number indicates either the north or west cross street. The second number indicates where on the block the building is located.
In the from address and to address fields of the line feature class, the house number can be a hyphenated number or a simple house number. For example, as shown in the table below, the address ranges 95-1000 – 95-1018 and 95-1001 – 95-1019 must contain a hyphen that separates the cross street and the actual house number. This locator role only supports house number ranging on the right side of the hyphen, so based on the table below you could not have a left range of 95-1000 - 95-1018 and a right range of 95-1001 - 96-1019 for Mahea St and expect to return a match for the address 96-1013 Mahea St.
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. To create a locator that only supports StreetName matches, the reference data must 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.
Street blocks
The Street Address locator role includes support for searching for a group of house numbers representing one or more city blocks. The Addr_type value returned for this type of search is StreetMidBlock. The location of such a feature is the approximated midpoint of the street segments that include the house numbers represented by the block number or block range. A StreetMidBlock match is more precise than a StreetName match and less precise than a StreetAddress match. Street Midblock is also a category of the Street Address role that can be disabled in the Locator Properties dialog box. You can search for a single block or a range of blocks using the syntax <number or range> block | block of <street name>, for example, 100 block of New York St, Redlands, CA or 200-500 block Taylor St, San Francisco. See the REST API web help for additional details about searching for street blocks.
Street between other streets
The Street Address locator role includes support for searching for a location on the street that is between two cross streets. The Addr_type value returned for this type of search is StreetBetween. The location of such a feature is the midpoint of the street segment that is between the two streets that intersect the input street. A StreetBetween match is more precise than a StreetName match and less precise than a StreetAddress match. Street Between is also a category of the Street Address role that can be disabled in the Locator Properties dialog box. You can search for a street that is between two other streets using the syntax <street name> between <street name> and <street name>, for example, 5th St between Victoria Ave & Roberts St, Highland, CA or I-10 W between Exit 75 and Exit 76, Redlands, CA. To use highway exits, model them as street names in the streets reference data. When searching for a street that is between two other streets, the intersection connectors supported by the locator can also be used as the connector between the cross streets, for example, <street name> between <street name> & <street name>. Additional StreetBetween indicators can also be used, such as btw, bt, b/t, or btwn.
POI
Basic characteristics of the POI role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Point of Interest | 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. |
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. You can also use locators created with this role 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 you can use 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, such as water meters or census block groups.
This locator role uses feature classes with point or polygon geometry as primary reference data. In addition to an ObjectID 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. To use categories and subcategories, the primary reference data must contain one or two fields that categorize the features. Optionally, you can include a join field that contains an ID that you can use to link to an alternate name table of alternate place names or alternate categories in the reference data. When building the locator, assign the join field to the Place Join ID locator role field in the primary and alternate name tables. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as PLACE_NAME_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
Note:
- Using polygon geometry for the primary reference data returns optimal reverse geocoding results.
- The POI locator role replaces the need for the place-name alias table, but it requires a point or polygon feature class of place-names along with the associated address in the attribute table.
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 assign a category to each feature in the individual feature classes and merge each of the feature classes into a single feature class since you can only use one primary reference dataset per role. This allows you to search different types of locations using a single locator.
Tables of addresses that you can geocode using this locator role must also contain the place-names and geographical zones or unique name or value that you can use 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, is found in multiple states in the country. If geocoding the POI plus address, include the place name in the address field and the address in an address2 field. You can also use a locator created with the POI role to search for places by name, category, or a combination of name or category and parts of the address. For example, type Starbucks, Orange St, Redlands or gas station, Boulder, CO. Locators created with this locator role support the following search formats:
- Search for places by name, such as Disneyland, Starbucks, or Niagara Falls, or category, such as amusement parks, waterfalls, or coffee shops.
- Search for places by name or category using one or more zones (neighborhood, city, region, postal code) with an optional connector (in or at).
- Search for places by name or category using part of the address, such as street name.
- Search for places by name or category using the address and one or more zones (neighborhood, city, region, postal code).
Subaddress
The POI locator role includes support for points of interest that contain subaddress information such as identifiers for suites in a medical office or stores in a shopping plaza. Subaddresses are found in a wide variety of 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 point of interest that includes the address and subaddress elements of the physical address of the POI, separated into their individual fields. The subaddress is an attribute of the POI, and only a single subaddress can be linked to a single POI feature and not represented as independent features as supported by the Point Address role.
The POI role supports primary reference data that is modeled with unit number ranges for subaddress attributes. 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, you must model all features with ranges. The features that do not have unit number ranges are included in the locator if the unit value is stored in either the unit From or To field. This works similar to having the same value in both fields in the reference data.
Note:
When building a POI locator that supports subaddress, if the unit and unit from and to fields are mapped, the values in the unit field are ignored and the values in the unit from and to fields are used to build the locator.
In addition to the basic address attributes, the feature class providing primary reference data for a POI locator that supports subaddress may contain individual fields for building type, building unit name, level type, level name, unit type, and unit name.
Note:
This locator role supports three pairs of subaddress elements: Unit and Unit Type, Level and Level type, and Building Unit and Building Unit Type. You can optionally 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. The subaddress elements that are mapped when building the locator are returned in the output when associated with the point of interest feature class. Learn more about address elements in the primary reference data.
Locators created with this locator role using POI features that include subaddress information support the same search formats listed above, but return subaddress details in the search results and suggestions as described below:
- Search for places by name.
- Search for places by name or category
Distance Marker
Basic characteristics of the Distance Marker role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Distance Marker | 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. |
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; an ObjectID field; and a Shape field. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as STREET_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
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
Note:
If distance units were included when building the locator with this role, the distance units are currently ignored by the locator when searching for locations.
Distance Range
Basic characteristics of the Distance Range role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Distance Marker | Finding an approximate distance along a highway | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
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; an ObjectID field; and a Shape field. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as STREET_ID. In addition, if there are duplicate features that have alternate street names associated with them, the feature class must contain an indicator field that indicates which feature is used for the primary street name. This indicator field must be mapped to the Primary Street Name Indicator field from the locator role, such as PRIMARY_STREET_NAME or PrimaryStreetFlag. Mapping both the Feature ID field and the Primary Street Name Indicator field is required in order for the Preferred Street Name property to work as expected.
Postal
Basic characteristics of the Postal role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Primary Postal | Finding a specific postal code location | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
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, an ObjectID field, a Shape field, a join field that contains an ID that you can use to link to an alternate name table, and optionally, administrative zones, such as city. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as POSTAL_ID.
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 affects results returned by multirole locators that include Point Address, Parcel, Street Address, or POI roles. You can change which value to return 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 you can geocode using this locator role must contain a field that has the postal code information.
Postal Extension
Basic characteristics of the Postal Extension role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
Points | Each feature represents a single postal extension centroid. | Five-digit ZIP Codes and four-digit extension in separate field | 96822-2323 | Primary Postal, Postal Extension | Finding a specific postal extension location | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
The Postal Extension locator role is for geocoding postal codes with extensions, such as United States ZIP+4 Codes. You can then use this locator role 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). The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as POSTAL_EXTENSION_ID.
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 is 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
Basic characteristics of the Postal Locality role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Primary Postal, Postal Locality | Finding a specific locality | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
The Postal Locality locator role allows you to create a locator for the union of a postal code and a locality. Use this locator to resolve to a more accurate location when a postal code spans multiple localities. For this locator role, feature classes in which each feature in the reference data represents the union between the postal code and the locality must be used. For example, in the image below, the neighborhood boundary of Scripps Estates (in purple) falls within the postal code boundary for 92037 (in black), which is assigned to the city of La Jolla. If you created a Postal locator with the postal code data, searching for 92037, La Jolla returns a match. However, searching for 92037 Scripps Estates does not, because Scripps Estates is not associated with the 92037 postal code feature in the postal reference data. To find 92037, Scripps Estates, you must build a Postal Locality locator.
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, an ObjectID field, a Shape field, and optionally, a join field that contains an ID that you can use to link to an alternate name table. The feature class must also contain an ID field that connects duplicate features with the same location to remove duplicate geometries in the locator. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as POSTAL_LOCALITY_ID. 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 or locality and postal code boundary feature classes in a single feature class with each dataset's attributes.
Administrative areas
Basic characteristics of the Administrative Areas role
| Typical reference dataset geometry | Typical reference dataset representation | Address search parameters | Examples | Supported categories | Applications | Supported ArcGIS Pro and Enterprise versions |
|---|---|---|---|---|---|---|
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 | Block, Sector, Neighborhood, District, City, Metro Area, Subregion, Region, Territory, Country, Zone | Finding a specific administrative zone | 2.3; 10.6.1; Not all locator functionality may be supported prior to Enterprise 10.7. |
The Administrative area roles are for geocoding areas such as cities, neighborhoods, counties, provinces, districts, territories, and states. You can use this role 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.
Reference data for Administrative area role locators must have a field that specifies the administrative area name for the feature, an ObjectID field, a Shape field, and an optional administrative area JoinID field that contains an ID that you can use to link to an alternate name table. You can associate the ID with many features in the primary reference data and use it to link to a unique record in the Join ID field from the alternate name table. There must be a Many-to-Many or Many-to-1 relationship between the primary reference data and the alternate name in the alternate name table. If a primary administrative feature has multiple names, the Join ID field in the alternate name table for the alternate administrative names of the same feature must contain the same unique ID value as illustrated below.
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.
To remove duplicate geometries in the locator, the feature class must also contain an ID field that connects duplicate features with the same location. This process reduces the size of the locator and removes excessive tied candidates from geocoding results. This ID field must be mapped to the Feature ID field from the locator role, such as REGION_FEATURE_ID.
Additional role attributes
In the list of locator roles when you create a locator, 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 an ID value for each record. You can associate the ID with many features in the primary feature class and use it to link to a unique record in the Join ID field from the alternate name table. There must be a Many-to-Many or Many-to-1 relationship between the primary feature class and the alternate name in the alternate name table. The primary feature class must have a field that contains a unique ID value for each record that you can use 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.
Administrative zone fields
Each role contains administrative zone fields, such as Neighborhood, City, Subregion, or State, that you must use 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. You can use the additional fields saved in the output feature class to join to other attribute tables or feature classes for further spatial analysis. You can also use the information when you rematch the addresses and need additional information to determine a correct match.