Add Find Input fields to Primary Locator Role FindAddressCandidate responses

06-16-2020 12:50 PM
Status: Open
Labels (1)
Regular Contributor

For the new primary locator roles it would be really helpful to get the input search field values in the response. This way it can be checked to matched candidate.

We are trying to use the new PointAddress and Streets Roles but getting invalid matches which did not occur in the SubAddress locator in 10.x. Due to these mismatches it would helpful to see what the input search address was so it can be compared to the result. 

In this example below, we are entering and a single line input: 4791 PELL DR STE 1, SACRAMENTO, 95837

However the match comes back without the STE which is not correct and should not have the 100% match score.

The 10.x SubAddress locator returned no matches which is a better result but realistically there should be a candidate match with a lower score than 100.

If the search input was in the result we would easily be able to compare the search string with the match string to weed thru these mismatches. 


I think you need to put a hash tag in front of your STE 1 for it to work:

4791 PELL DR #STE 1

Of course provided your address points have that data.

See :  &

Proper use of Unit and Unit Type in Point Address Role &

Provide Units In Suggested Addresses 


Thanks for the reference links and suggestion. This candidate does not exist yet so in this situation introducing the #STE did not work. We are expecting a no match like the SubAddress 10.x locator or the match without the unit with a score less than 100. This is one way we detect if an address exists or not. If addresses coming back with 100% score but do not match the input address this is a concern and should show up in the component scores but those don't appear to be available yet in the new locator roles. 

For us to inject # before the unit type into the single line input string will be challenging from our enterprise system if not nearly impossible. That does not seem like a reasonable solution. 

Shana Britt


@RonnieRichards Is this still a problem with input addresses that contain subunits if you have recreated the locator in a newer release of ArcGIS Pro and publish the service? Does the data to create the locator include 'STE' as a unit type or as part of the value in the unit field that was mapped when building the locator? If the value in the unit field that was mapped when the locator was built is "STE 1", then you will need to include '#STE 1' as part of the input address. If the value in the unit field mapped when the locator was built was '1', then to get the best results you should include a unit indicator like # or STE, but you do not have to include one with locators created in Pro 2.7 or later.