Scoring options with Create Locator

[JoeBorgione]

(2.4.0 ArcGIS Pro)

I don't see any way to modify the scoring when using create locator; is this by design?  It appears that minimum match scores are set in the project.  What about published locators?  Can minimum match scores be set once a locator is shared?

If a multi-role locator is created, is there a way to have different scoring values for each role?  For example, I'd like the address points to only consider a 95% score as a match, where as a street address role would be more forgiving, along the lines of 80 or 85%.

Shana Britt‌

Eric Anderson‌

[JoeBorgione]

Thanks Brad-

I don't create and/or consume locators in an ad hoc basis; that used to be what I did, but not anymore.  The agency I work for creates and publishes services that are consumed by a wide variety of customers, both internal and external.  Setting locator properties at the project level is big issue for us; in our current workflow with the older style address locators we can tweak the xml file through python. 

The match out of range defaults to yes, and despite Eric's explanation he gives here, I have a difficult time with that: in my experience I'd rather have  no match than a mis-match. I may just be the minority of the geocoding community, but 15 years in the 9-1-1 industry will do that to a guy.

Invalid suggestions are problematic as well.  I find this post from 2018 confusing with respect to your explanation of best practices to in include a Street Name Locator.  Again, just in my experience, a mis-matched address has little to no value.  We (my organization as well as the GIS community at large) pride ourselves in data quality; if the out of the box analyses tools we apply to that data return results that I consider less than optimal, I need a mechanism to control that tool's output parameters. Yes, I can do that in a project, but much of the geocoding I do is scripted and  many of our customers are using web apps to verify addresses. Perhaps there is a mechanism available to change properties at the service level, and if so, please point me in that direction.

I realize that ArcGIS Pro is evolving, and I appreciate the dialog with you and other ESRI staff this forum provides.  I'll take your suggestion of using a composite of single role locators and see if that direction is something we can use.

[BradNiemand]

Joe,

Match out of range doesn't apply for your workflow but it does in many others.  It is there to provide a more spatially accurate result than a StreetName result.  Some workflows allow for StreetName results but if the StreetAddress range is 1-99 and you have a input of 101 or 111 it would be better to get a point at the end of the street segment with a type of StreetAdddressExt than it would be to get a point in the middle of the street segment with a type of StreetName.  This property is set to true by default but you can set it to false for your workflow.

The invalid suggestions you mention was a limitation of the classic locators.  This is not longer an issue with the new locators created with the Create Locator tool.  I understand that many users had challenges with this limitation which is why we worked hard to ensure the new locators didn't have it as well.

As mentioned in a previous comment, we are working to put together a Python API to support modifying properties of a locator after it is created.  Also, there is no way to modify the properties of a locator after it has been published as a service.  Any properties of the service are read-only.

Once again thanks for the feedback and we are doing are best to integrate feedback back into the product each release and welcome continued feedback so we can continue to evolve our products to meet the needs or our users.

Brad

[JoeBorgione]

Just thought of an actual use for the out of range property.  A few years back, I was in contact with a citizen who was complaining about the lack of response to his 9-1-1 calls.  I got his address and went digging.  That particular 9-1-1 center did not have access to address point data, just street centerline data, and it was very good with respect to address range values.

The guy told me his address was something like 910 E Village St.  In the centerline data, E Village St terminated at 900 E, so logically 910 could not exist.  Turns out, the guy built the house  and assigned the address himself; somebody rubber stamped it and the rest is history.

So, there you go!