Locator won't match close street number in single address locator

11795
77
11-26-2013 06:49 AM
PeterHanmore
New Contributor III
We have built a locator in ArcGIS 10 SP5 which is based on the US Street - Single Address style.
We have been able to tweak most other settings but are still having issues with street number scoring.
Basically, we would like the locator to rank similar house numbers on the same street/town with a high score.
The default action (from my testing and based on one other forum thread) seems to indicate that the locator is VERY strict about the house number matching - to the point that it will give a high ranking to an address that matches the house number and street in a town hundreds of miles away, but fail to even score the address 100' away.
We have tried playing with the scoring of the FullNormalAddress, NormalAddress and House components but nothing seems to allow addresses with close house numbers in the desired city to be ranked higher than exact house number matches in a different city.

For example:
Search for 100 Main Street, Mytown

Geocoder responds with:
Score: 90, Address: 100 Main Street, Yourtown (could be large distance away from Mytown and therefore totally wrong location).

Yet 98 Main Street, Mytown is only two house numbers away from the desired address.  I would like the locator to return something like:

Score: 98, Address: 98 Main Street, MyTown
Score: 50, Address: 100 Main Street, Yourtown

Has anyone found a solution for this?  Any workarounds?  Apparently this worked as desired in 9.3.1 but was "improved" in 10.0?
Tags (2)
77 Replies
JoeBorgione
MVP Emeritus
We have built a locator in ArcGIS 10 SP5 which is based on the US Street - Single Address style.
We have been able to tweak most other settings but are still having issues with street number scoring.
Basically, we would like the locator to rank similar house numbers on the same street/town with a high score.
The default action (from my testing and based on one other forum thread) seems to indicate that the locator is VERY strict about the house number matching - to the point that it will give a high ranking to an address that matches the house number and street in a town hundreds of miles away, but fail to even score the address 100' away.
We have tried playing with the scoring of the FullNormalAddress, NormalAddress and House components but nothing seems to allow addresses with close house numbers in the desired city to be ranked higher than exact house number matches in a different city.

For example:
Search for 100 Main Street, Mytown

Geocoder responds with:
Score: 90, Address: 100 Main Street, Yourtown (could be large distance away from Mytown and therefore totally wrong location).

Yet 98 Main Street, Mytown is only two house numbers away from the desired address.  I would like the locator to return something like:

Score: 98, Address: 98 Main Street, MyTown
Score: 50, Address: 100 Main Street, Yourtown

Has anyone found a solution for this?  Any workarounds?  Apparently this worked as desired in 9.3.1 but was "improved" in 10.0?


I'm a little confused with your term "US Street - Single Address " style of locator. I'm familiar with the US Address One range and the US Address Single House.  That latter of which is a point or polygon type of locator. Perhaps you could clarify.

see: http://help.arcgis.com/en/arcgisdesktop/10.0/help../index.html#/Commonly_used_address_locator_styles...
That should just about do it....
0 Kudos
PeterHanmore
New Contributor III
Sorry for the confusion... I didn't have the style list in front of me and went by memory (which obviously wasn't a good idea).
We did use the Single House locator style and used our parcel polygon layer for the data.
0 Kudos
JoeBorgione
MVP Emeritus
Phew...  Thought I was having a flash back from the 60s... Again...

All seriousness aside: do both the address data and the parcel data have the correct city identifier?
That should just about do it....
0 Kudos
PeterHanmore
New Contributor III
Yes,
The city is correct in both the input address and the data from which the locator was generated.
We also use an extensive alias list for city names which is working just fine.

Here's a specific example:
The source data has a polygon for house_number = 15, street = Barwick, street_type = road, city = TOWNSHIP OF CHAPPLE

If you query for 15 Barwick Road, Chapple you get a score of 100, which is correct (first attached image)
If you query for 13 Barwick Road, Chapple you get a score of 43, matched to 13 Barwick Drive, Barrie (second attached image)

Ideally, I would have gotten a hit on 15 Barwick Road, Chapple with a score close to 100 because it's at least on the right street in the right town and close to the right house number, but it fails to get any kind of score at all.  Instead I get a match (albeit lower score) to the right house number but with a different street type and a totally different city.
It seems that for Single House locators, the house number trumps all other address components - meaning it will force matches to the requested house number even if it has to pick the wrong street/town.




Phew...  Thought I was having a flash back from the 60s... Again...

All seriousness aside: do both the address data and the parcel data have the correct city identifier?
0 Kudos
JoeBorgione
MVP Emeritus
Yes,
The city is correct in both the input address and the data from which the locator was generated.
We also use an extensive alias list for city names which is working just fine.

Here's a specific example:
The source data has a polygon for house_number = 15, street = Barwick, street_type = road, city = TOWNSHIP OF CHAPPLE

If you query for 15 Barwick Road, Chapple you get a score of 100, which is correct (first attached image)
If you query for 13 Barwick Road, Chapple you get a score of 43, matched to 13 Barwick Drive, Barrie (second attached image)

Ideally, I would have gotten a hit on 15 Barwick Road, Chapple with a score close to 100 because it's at least on the right street in the right town and close to the right house number, but it fails to get any kind of score at all.  Instead I get a match (albeit lower score) to the right house number but with a different street type and a totally different city.
It seems that for Single House locators, the house number trumps all other address components - meaning it will force matches to the requested house number even if it has to pick the wrong street/town.


As far back as I can remember, the single address locator styles are pretty unforgiving. I take it that there is no house number 13 on Barwick Rd in Chapple, right?  If I'm correct, you are getting dinged first because there is no 13 house number in Chapple; after that you get double dinged in the street type and city.
That should just about do it....
0 Kudos
PeterHanmore
New Contributor III
You're correct - there is no 13 Barwick Road...... but 15 is RIGHT THERE.... I can see it 😉
I'm not as concerned about the 'double ding' for street type and city - we actually prefer that since it makes it more obvious that those candidates are not very similar to what was requested.  The first ding on the house number is a bit of a show stopper though.  It's especially annoying that it worked as desired in 9.3.1 and now it's 'broken' in 10.
0 Kudos
DanMcCoy
Occasional Contributor III

Peter Hanmore:

It's especially annoying that it worked as desired in 9.3.1 and now it's 'broken' in 10.

I just wanted to confirm that 9.x style locators using "one address" behave as Peter mentions.  It will match to a house number that is close, but it does drop the score.

Dan

0 Kudos
JoeBorgione
MVP Emeritus
You're correct - there is no 13 Barwick Road...... but 15 is RIGHT THERE.... I can see it 😉
I'm not as concerned about the 'double ding' for street type and city - we actually prefer that since it makes it more obvious that those candidates are not very similar to what was requested.  The first ding on the house number is a bit of a show stopper though.  It's especially annoying that it worked as desired in 9.3.1 and now it's 'broken' in 10.


To me it's working.  Since there is no 13 Barick Rd in Chapple, it can't make a match there.  But it gives you a low scoring partial match elsewhere.  The single address types of locators are just that; single address.  It either hits or it dosen't; there's no range involved.  I'm not second guessing you, it just seems very odd that it worked earlier.

If you use a US streets type of locator that provides for a range of addresses you can expect partial hits.  For example if you have an address of 1234 Main St, but the range only goes to 1230, you'll get a partial hit at 1230.  I look at that as suggestion.  It's almost like the locator is saying 'Hey, I don't have exactly what you entered, but I do have this.  Will it do?'
That should just about do it....
0 Kudos
PeterHanmore
New Contributor III
For example if you have an address of 1234 Main St, but the range only goes to 1230, you'll get a partial hit at 1230. I look at that as suggestion. It's almost like the locator is saying 'Hey, I don't have exactly what you entered, but I do have this. Will it do?'


This is exactly what I'd like the single house locator to do.  To me it makes sense that if the locator gives ANY candidate matches back, they should be on the same street and city as what I asked for - even if the house # is incorrect, not some other street name/city with the correct house #.
Whether the locator is based on single address or a range of addresses, it should be able to to give scoring preference to those candidates that exactly match all other address components except the house number.
0 Kudos