topic Re: Scoring options with Create Locator in Addressing Questions

Scoring options with Create Locator

JoeBorgione — Mon, 18 Nov 2019 18:45:24 GMT

(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‌

Re: Scoring options with Create Locator

MichaelVolz — Mon, 18 Nov 2019 19:37:19 GMT

Interested in the answer to this question as well.

Re: Scoring options with Create Locator

EricAnderson17 — Tue, 19 Nov 2019 16:19:23 GMT

Hey Joe, (will always sing that in Hendrix's voice)

Can you clarify what you mean? You should have the ability to modify the Minimum Match Score and Minimum Candidate Score from the locator properties like you always have:

I do like your idea about having different minimum match/candidate scores for different roles within a single multi-role locator. Is this something you've put on our ArcGIS Ideas page?

-Eric

Re: Scoring options with Create Locator

JoeBorgione — Tue, 19 Nov 2019 16:37:54 GMT

Hey Eric- (somehow Hendrix doesn't work here...)

As I understand it, I can only adjust those properties after the locator is created, not while creating it. We update our locators programatically with python as a scheduled task. Then we publish them for consumption. Make sense? In the older style locators and their xml files, we can change properties there...

Re: Scoring options with Create Locator

EricAnderson17 — Tue, 19 Nov 2019 16:51:06 GMT

Got it! Yes you are correct, these properties can only be modified once the locator has been created, there is no option to do it within the Create Locator tool. You should be able to change them from the *.loc file as well using a text editor:

Re: Scoring options with Create Locator

JoeBorgione — Tue, 19 Nov 2019 17:08:02 GMT

That's interesting, and that tells me any property can be changed, right?

Re: Scoring options with Create Locator

EricAnderson17 — Tue, 19 Nov 2019 17:28:48 GMT

That's correct. Most of the locator properties exposed in the UI can be modified from the *.loc file.

Re: Scoring options with Create Locator

BradNiemand — Wed, 20 Nov 2019 22:56:06 GMT

Joe,

Thanks for the feedback. We are looking into adding support for modifying properties via Python for an upcoming release so automation of this process will allow for this going forward.

With regards to modifying the .loc file, it can be done but it is discouraged and not supported.

As for adjusting the score for individual roles in a multirole locator, this is currently not supported. I would like to understand your workflow in a bit more detail though to understand what you are trying to do.

Is the score more important to batch geocoding?
Why is it acceptable to have a score less than 95 for StreetAddress but not for PointAddress? Is it because PointAddress is considered more spatially accurate so you want to ensure the result has a high confidence?
If so, what is done with the lower confidence StreetAddress matches after geocoding? Are they used at all?
Can the minimum match score just be set to 95 for everything and then the confidence is high for all geocodes?

Locators created with the Create Locator tool can still be added to a composite locator and each participating locator can have the score adjusted appropriately but I just want to make sure that it is really needed before we go down that path because you will lose out on some of the benefits of these new locators using this approach (size, deduplication of results, etc...).

Brad

Re: Scoring options with Create Locator

JoeBorgione — Thu, 21 Nov 2019 01:05:12 GMT

Hi Brad: here are the respective answers...

1. Sometimes. A couple of applictions we have specifically verify addresses for tax entities. If you are familiar with Utah addresses, we always a prefix direction but human nature is lazy so that is one of the address elements often left off. For tax purposes, address points are the best to use as they will intersect with the tax zone data.

2. As mentioned the address points are our go to data. So we want them held to a higher standard. However, as a fall back the streets work, especially if the input is not only missing a pre dir, but may be missing or have an incorrect type, or a two word street name is provided as one or vice versa. That said, for the tax apps we are distancing ourselves from the centerline data in favor of a single address point role.

3. See # 2.

4. Since that appears to be our only option with the new style locators, that's what we'll have to go with, but we aren't yet totally in love with the new styles. Don't get me wrong, they do show a lot of promise but they can put a strain on us with the little gotchas.

We are at a cross roads (all puns intended) with our locators. Traditional address locators in a composite have a nasty habit of offering suggestions that do not exist. I can provide examples if you'd like. The new locators show promise but they take control away from us humans. Call me old fashioned, but locators work for me not the other way around.

Re: Scoring options with Create Locator

BradNiemand — Thu, 21 Nov 2019 17:26:51 GMT

Joe,

Some follow up questions. You state the following above:

"Since that appears to be our only option with the new style locators, that's what we'll have to go with, but we aren't yet totally in love with the new styles. Don't get me wrong, they do show a lot of promise but they can put a strain on us with the little gotchas."

What about the new locators are you not totally in love with at this time? What can't you do with the new locators that you could with the previous ones? You can still modify the properties such as score and you have even more flexibility to modify things like what categories to match to and what features should be supported for reverse geocoding to name a few. Also, if needed you can still create a composite locator with participating locators that have adjusted scores if your workflow requires this.

We appreciate any additional feedback you can provide.

Brad

Re: Scoring options with Create Locator

JoeBorgione — Thu, 21 Nov 2019 19:17:40 GMT

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.

Re: Scoring options with Create Locator

BradNiemand — Thu, 21 Nov 2019 19:58:34 GMT

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

Re: Scoring options with Create Locator

JoeBorgione — Thu, 21 Nov 2019 20:19:43 GMT

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!