ArcGIS 10.6.1; data source is a point feature class in a file geodatabase
I have created a Single Field Address Locator to which I am matching addresses that are in the form 1234 S MAIN ST. However, here in Utah we have numeric streets, not just named streets so many address may be in the form of
50 W 200 S
The data the locator uses are address points, and the single field I match to is called (of all things) Address. There is one address point in the point feature class where the value of Address = 50 W 200 S. But.....
I get a tie with 100% scoring for:
50 S 200 W
50 W 200 S
These are two very different locations! One is on a street named S 200 W while the other is on a street named W 200 S, the latter of which I should be matching against. How do I convince the locator that
50 W 200 S
is not a match to
50 S 200 W?
Solved! Go to Solution.
Joe:
First I would use the US – Single House locator style instead of the SingleField style. You can still search using the full address field against the Single House locator, which has the grammar to handle the Utah street naming convention. The Single Field locator style does not have the same grammar and is more of a lookup or exact match type of locator, plus if you are using it as a geocode service, there is a memory for suggestions.
-Shana
Is your address also broken down into mulitple fields where 1 field is the number, 1 field is the prefix direction, 1 field is the suffix type and 1 field is the suffix direction? If not in this format, maybe you can create new fields to accomplish this task and try using the US Address - Street address locator style for more granular control.
The data in the point feature class is parsed out, but the data in the addresses I'm geocoding is not.
Joe:
First I would use the US – Single House locator style instead of the SingleField style. You can still search using the full address field against the Single House locator, which has the grammar to handle the Utah street naming convention. The Single Field locator style does not have the same grammar and is more of a lookup or exact match type of locator, plus if you are using it as a geocode service, there is a memory for suggestions.
-Shana
I just now built one, so I'll let you know how it works out...
edited to add....
That approach took care of the ties: the address in my example is good to go. In fact, the hit is very good with respect to scoring: 8408 records matched, only 180 not at 100%, and those are at 98.5%. (In this particular set of addresses, the overall match rate isn't so great, but I can take care of that with a bit more scrubbing, and using a composite....)
Will you be creating a geocode service from this address locator? If so, will you be needing to update the address locator on a regular basis to account for changes to the address points?
We have a service already based on the address points data; yes that locator gets re-built on a regular basis, and the service(s) refreshed. I'm exploring different options for the address point data.
Due to the implementation of Anti-Malware software on my org's Windows Servers, I am having problems with a similar setup so I was wondering if I could ask you some questions about your setup?
Sure, here or off line? jborgione at slco dot org
Thanks, I just sent you an offline E-mail.