Customizing Locator definitions in ArcGIS Pro

[JustinMartinek]

Is there any up-to-date guidance in customizing ArcGIS Pro locator definitions similar to how ArcGIS 10 had the attached technical paper for customizing locator definitions?

[ShanaBritt]

@JustinMartinek Is there something that is not working with the locators you create with the Create Locator tool in ArcGIS Pro that requires customization?

[HXiao]

We have the same question. Our reference data can not match any of the existing locator role in ArcGIS Pro. We had to customize the locator style in ArcMap to build a locator against the data. We're wondering how to customize the locator role in ArcGIS Pro. Does anybody have an idea? Thanks.

[JustinMartinek]

Unfortunately, the guidance I received was to use a database view to fit the data that was broken up into one of the existing definitions.  This article describes the process.

[ShanaBritt]

@HXiao Locator roles cannot be customized in ArcGIS Pro. What type of customizations do you make to the address locator style in ArcMap that is missing from locators created with the Create Locator tool in ArcGIS Pro?

[MichaelVolz]

Shana:

If my input data has street suffix (Road Thoroughfare Type) as La but the Create Locator default (standard) is Ln, do I have the ability to modify (customize) the Create Locator to recognize that La is equivalent to Ln in geocode scoring?

I was able to do this in the past with previous address locators.

[ShanaBritt]

@MichaelVolz You do not have the ability to make a modification to the street suffix types as you did with the classic locators, however you could use an alternate street name table that contains 'La' for the street suffix type for the street name. I would suggest submitting an enhancement request through Support to get this added for evaluation for a future release of ArcGIS Pro. If there are any other enhancement or improvements you would like to see with the new locators, please submit them so that the Geocoding Development team can evaluate them or offer workarounds. I'm curious about your data as well, was it created in-house or purchased from a data vendor?

[MichaelVolz]

Hi Shana:

I investigated your proposed solution which would not work without an enormous amount of work and create a maintenance issue when new address points are added to address point layer that is the source of the address locator.  Currently the Create Address Locator has an xml file that can handle converting input street suffix type from La, Ln, Lan, Lne, and Lane to La so they have equivalent match score.

In order to replicate this behavior in Create Locator I would need an alternate name table to have all 5 suffix types for all address points that have La as their current street suffix type.

This same setup would need to be applied to other address points as well with different street suffix types (e.g. Rd should be converted from Rd, Road; Bl should be converted from Bl, Blvd, Boulevard; etc).  The alternate name table for this locator would be unwieldly and new roads added that have address points associated with it would need all the alternate names added for each new point.

[ShanaBritt]

@MichaelVolz As far as the alternate name table I would create a StreetNameID field in the primary reference data and give each record/feature with the same street name the same ID, so if you have 10 'E Orange Lane' features they will get the same ID. Then in the alternate street name table you would have a StreetNameID field and record1 for 'E Orange La' would get the same ID as the 10 features in the  primary data layer. Then record2 for 'E Orange Lan' would get the same ID as the 10 features in the primary data layer. You data would have a Many (primary)-to-Many (alternate table) relationship and look similar to the image below.

The most common and I believe the USPS street types are already included in the geocoding rules and any abbreviation you have that is not working by default should go in the alternate name table. Then the Preferred Street Name settings in the locator properties you can specify which street name will be returned.

[BryanLynn1]

We have parcel ids that have 2 spaces in the the middle of the id. For instance 001  001. The locators are trimming the multiple spaces to a single space and causing problems downstream. Since we can't modify the locator rules to account for this situation, how do we handle it? Or is there a locator style that already has support for multiple blank spaces?