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

[Mike_Quetel]

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".

[ShanaBritt]

@Mike_Quetel When the geocode service is used in a map like in ArcGIS Pro or the MapViewer for example the center of the map is used as the location that is included in the requests to the service. Is you custom app in a browser or mobile device? You could test using the REST endpoint and include coordinates, maybe from the center of the data used to build the locator in the request. When using the REST endpoint to test the service you should include location since there is no map to grab the location from.

[Mike_Quetel]

@ShanaBritt Unfortunately I'm not seeing a benefit from adding the location parameter (with a nearby X/Y coordinate).  A result that should be easily returned by my provided inputs still isn't found.

[ShanaBritt]

@Mike_Quetel Is creating a multirole locator an option for you rather than using a composite locator for the service? Do you have any differences when using location when not using SingleLine and just using Address or Place?

https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/combine-multiple-layers-into-a-single-l...

https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/tutorial-create-a-multirole-locator.htm

[Mike_Quetel]

@ShanaBritt It might be in the future, but would require source-level data changes we don't want to tackle quite yet... as long as composite locators are still supported.  It's our understanding that in a multi-role locator, only one dataset can occupy a single role at the same time... and it seems like for aliasing purposes this is true also?  We have a street name alias table that is used with point addresses and another used with street centerlines (the primary keys used for addresses and centerlines are different).  These would need to be combined into a single alias table that could occupy the street name alias role, if my understanding of the documentation is correct.  Our initial goal was to change as few things as necessary to be able to retire our classic locators and adopt the new locators. 

[Mike_Quetel]

@ShanaBritt Answering the 2nd part of your question:  In general we don't see any meaningful difference (result wise) between SingleLine and Address/Place.  The exception is that SingleLine used to allow the inclusion of the City parameter in classic locators but does not anymore.  The City parameter  must be paired with the Address parameter or the administrative zone value must be concatenated to the SingleLine value in order to be considered in the new locators.  I tried to file a bug for that but it was closed because the behavior was "by design".  Fair but it is a partially breaking change to the REST API behavior  🙂

[ShanaBritt]

@Mike_Quetel Regarding multirole locators, you are correct that each primary or alternate name role can only be used once in a multirole locator. So if you had multiple point address sources you would have to merge them together to build the multirole locator with the PointAddress role as described in this tutorial for a POI locator, https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/tutorial-create-a-locator-with-more-tha.... The same would be true for the alternate street name table, the data for the point address and street address roles would need to have the same join id value to link to the street name from any primary role to the alternate name table role.

[BradNiemand]

@Mike_Quetel 

You are correct in your statement above.  SingleLine is intended to be the entire input address with all relevant information, including the address, city, state, postal, etc...  It was never intended to be used with any of the multiline input fields except for CountryCode.  The fact that it worked before was not intentional and really shouldn't be used.  If you would like to use multiple fields for input, you should be using Address and City instead.

You can read more about these parameters for the online service (it would function the same with custom locators as well).  https://developers.arcgis.com/rest/geocode/api-reference/geocoding-find-address-candidates.htm#ESRI_...

[GIS_Spellblade]

I'll just drop this here. Seems like it could solve this issue if these parameters were exposed.

https://community.esri.com/t5/arcgis-pro-ideas/create-locator-additional-options-when-creating/idc-p...

[BradNiemand]

The technical article is outdated and will be removed or updated with current best practices.