AnsweredAssumed Answered

Geocoding 10.0 SP4 issue with 'Match_addr' coming up w/ "2106 PACIFIC AV, TA, 98402"?

Question asked by geonetadmin on Apr 27, 2012
Latest reply on May 7, 2012 by glund_UW_Tac
Original User: gwlgis

Scenario:
Simple Geocoding function, using ArcInfo 10.0 SP4.
Used 'US Addresses - Dual Ranges' because I have Line data as my reference (From Left, To Left, From Right, To Right, etc.)
My table to be geocoded has (among others) these 4 fields: address '2106 Pacific Ave' City 'Tacoma' State "WA" and Zip '98402'
I have: 'The field containing:' all set up by default Street-street, City-city, and Zip-zip.

In the results however, the 'Match_addr' field comes up with the abbreviated city as 'TA' as though it was a state abbreviation.
But it was Tacoma.
Also, the matches are coming up with 95.29 percent.

I found a work-around, by (in the Address Locator Properties) clicking on 'City' in "The field containing:", and then deleting all of the items in "is recognized if it is named:" I run it after that and I get 100% matches, on all the matches that were formerly 95.29.

Image of my initial Address Locator below.

[ATTACH=CONFIG]13904[/ATTACH]

Geocode result 1 below.

[ATTACH=CONFIG]13905[/ATTACH]

Image of my 2nd (the fix) Address Locator below

[ATTACH=CONFIG]13906[/ATTACH]

Geocode results showing 100% for same exact Address locator, except with the city taken out. (still have "TA" for Tacoma.)

[ATTACH=CONFIG]13907[/ATTACH]

Exact same thing, except without the city stuff, I get 100%.
Is it safe to say that there is something wrong?
I can continue this work around, but it would be great if it could/would work properly.

by the way, I am an instructor and this is a Lab that was designed for my students by a professor at the college. It worked fine in 9.2 and 9.3, but with the switch to 10.0 SP1, SP2, SP3 and SP4 all have this issue.

Any input would be greatly appreciated!

Thanks
Greg Lund

Outcomes