The Create Locator GP tool should output locators that follow esri tech support best practices

[MikeQuetel1]

The "Create Locator" GP tool will output a locator where the "Match with no zones" option is set to "NO".  This option is not parameterized and the default value is not influenced by the presence or absence of administrative zones in the source data and GP tool configuration. New locators always have this option set to "NO" by default. 

This default value of "NO" is contrary to an esri tech support best practice document and results in poor geocoding success when compared with setting the value to "YES".

We automate the creation of locators with a model or python script.  In order to significantly improve geocoding success and to follow esri best practices, someone must interactively update each locator and change the "Match with no zones" option from "NO" to "YES".  This must be done for each individual locator as well as repeating the process for any composite locator that they participate in.

We would like esri to make this option accessible as a parameter with the "Create Locator" GP tool and if necessary also with the "Create Composite Address Locator", so that output locators do not need to be interactively re-configured in order to follow esri best practices and achieve usable geocoding success.  At minimum, the default should be changed to "YES".

[DanBauer]

In the government sector locator data is often used support critical life safety and emergency response functions. Enabling the Create Locator tool to provide more accurate results will not only align with stated ESRI best practices but more importantly provide better data to first responders which will save time and can ultimately save lives.

[DiegoPortillo_PDX]

Limiting re-configuration interactions is beneficial and increases efficiencies on all areas. Finding addresses is a key function of all business areas, and should be readily available and current. This approach will ensure that.

[PaulCone2]

@DanBauer you said it well.  Our locators built for emergency response need to be built with default YES here since extra keystrokes (e.g. having to type the city) would slow them down.  

[MitchVanderperren1]

Working in an enterprise context and supporting a large and complex environment that has hundreds of users we automate as many processes as possible.  Pieces of these processes that we need to interact with manually introduce opportunities for a step to be forgotten or missed when an operator is busy or distracted.  The more we can build into the automated tools the less opportunity there is for someone to accidently miss a step.

[BradNiemand]

The Create Locator tool will automatically set the "Match with no Zones" property to "Yes" if the locator is built with no administrative zones (city, state, postal, etc...).  The Create Locator tool will default the property to "No" if any administrative zone is mapped when building the locator.  Also, the tech support best practices link you refer to is for our classic ArcMap based locators that are no longer supported in Pro as of Pro 3.0.  This documentation is quite outdated and will be taken down or  updated. 

It is strongly recommended to map the administrative zones when building a locator and it is also strongly recommended that the "Match with no Zones" property is set to "No".  With suggestions support in Pro the need for the "Match with no Zones" property is not as necessary because users have the ability to choose the suggested candidate without needing to enter the entire address or place.  Setting "Match with no Zones" to "Yes" should only be done if there is a specific need that requires it.

[MikeQuetel1]

@BradNiemand this idea was suggested by esri tech support as a follow up to enhancement request ENH-000161600.  That came out of the support case # 03402446.  We found that with an administrative zone set in the locator (we use city as the zone), the findAddressCandidates end point would not return results (or at least all the relevant results).  I was told after lots of back and forth with tech support that setting Match with no Zones to "YES" was both a best practice and a requirement to getting relevant results back. 

Obviously that was quite contradictory to your post above and a bit dispiriting for me since there doesn't appear to be a consensus within esri on what should be done here.  I'm keen to get to the bottom of this issue and it doesn't need to be done here.  Suggestions on the best way forward or should I just follow up with our esri rep?

[BradNiemand]

Thanks for the quick response.

Suggestions are the best way to get quick results without entering the entire address and would be the suggestion from the geocoding team as the best move forward.

I did look into your case and it appears that you might be hitting an issue that was already patched.  Can you have the following patch applied to your server?  https://support.esri.com/en-us/patches-updates/2022/arcgis-server-geocoding-service-quality-patch-80...

[MikeQuetel1]

I believe we are patched for this.  Just pulled from the server.  

The reason we aren't necessarily going to suggestions first, then handing that to the findAddressCandidates is that we have some custom apps that aren't set up to use that capability at this point.  

[ShanaBritt]

@MikeQuetel1 Since you are using the findAddressCandidates operation, are you able to use the location parameter that is described here, https://developers.arcgis.com/rest/services-reference/enterprise/find-address-candidates.htm, in your requests? If your custom apps have a map, can it grab the center of the map and use those coordinates for the location parameter?

[MikeQuetel1]

@ShanaBritt Thank you, I can look into it, but it would require some testing to determine if it actually increases relevant results.  I can imagine scenarios where a location hint might be helpful and others where it maybe wouldn't, such as zoomed in quite a bit, but user is attempting to geocode and navigate to an address across town, so location hint is in the wrong place.