Bruce Harold,
Bruce,
Thanks for the insight, this is helpful! I have also been trying to understand the internal algorithm used for ESRI geocoding.
One thing I find strange is that when there are multiple candidates found for an address, the geocoder will pick whatever the first one, instead of the "best" one.
For example, a search for address "2725 30TH STREET SE, Washington DC" will get a match at "2725 30th St NE, Washington, District of Columbia, 20018" with a score of 92.43, when geocoded using ArcMap. The match is wrong, due to the street directional. Of course, a manual rematch will find a 100 match, but this won't be feasible for batch geocoding.
Below shows all candidates returned by findAddressCandidates REST API, but geocodeAddresses will only return the first one that is in fact wrong. The desktop geocoder is the same as geocodeAddresses. I imagine this is done for performance/speed reasons? But this is not right. What can we do to avoid the wrong matches? One options would be to redo the filtering algorithm by picking the biggest score if using findAddressCandidates. But anything for geocodeAddresses? Thanks and it's much appreciated!
Jian
####search for address "2725 30TH STREET SE, Washington DC", return by findAddressCandidates:#####
Shape:
Point:
X:
Y:
Score: 92.43
Address: 2725 30th St NE, Washington, District of Columbia, 20018
Score: 100.0
Address: 2725 30th St SE, Washington, District of Columbia, 20020
Address: 2725 30th St NW, Washington, District of Columbia, 20008
Score: 83.35
Address: 2725 30th Pl NE, Washington, District of Columbia, 20018
Score: 79.0
Address: 2726 30th St SE, Washington, District of Columbia, 20020
Thank you, Bruce! I'll cross post to How are geocoding scores calculated in ArcGIS? at GIS Stack Exchange.
- Nathan
Hello
Score calculation is not documented in detail, but I can give you a thumbnail.
If you open USAddress.lot.xml in Firefox from its installed location at file:///C:/Program Files (x86)/ArcGIS/Desktop10.<version>/Locators you will see a navigable tree.
In Top Level Elements navigate to FullNormalAddress; the superscript numbers for NormalAddress (70) and Zone (30) are the relative weights for score contributions from those elements. Coincidentally they sum to 100 but only the relative weight is relevant.
Navigating further from NormalAddress you will see 70/100 of the score is contributed 15/75 and 60/75 by House and FullStreetName respectively, where 75 is the sum of the weights, and further down you can see the elements prefix (5/92), pretype (6/92), StName (70/92), suftype (6/92) and suffix (5/92) weights where 92 is the sum of those weights.
An individual score for any lowest level element (like how to calculate a score contribution from an imperfect street name) may be determined by the Spelling/Scoring section of the XML file if an anticipated spelling correction is required to match the reference data, or by a proprietary algorithm for unanticipated spelling errors or noise or repeated characters, as when you have keybounce.
Scores are weight summed, with percentage normalization, from the bottom up. Missing elements do not penalize a score, they simply do not contribute.
Regards
Thanks, Tim - but the GeoServices REST Specification provides information on how geocoding match scores may be returned. It doesn't tell how a score is determined.
The GeoServices REST Specification provides information on how geocoding match scores may be returned from a REST but does not describe how geocoding match scores are determined with detail.
D.E. Wright's response at How are geocoding scores calculated in ArcGIS? at GIS Stack Exchange gives some insight, although it is quite general.
The MATCH commands in the ArcGIS 9.2 Geocoding Rule Base Developer Guide looks close. The guide is introduced at Accommodating changes in the geocoding rule base files in the ArcGIS Desktop 9.3 Help, as well as in EDN documentation and other locations.
Since many things changed with the geocoding engine upon the release of ArcGIS Desktop 10.0 and 10.1 SP1 (particularly) it is not clear how similar (or how much of) the logic from 9.x geocoding is used in products today.
Resources listed at the Good resources on geocoding algorithms on StackExchange are interesting, but (may? or) may not answer the specific question on how match scores are calculated in present ArcGIS address location geocoding engine(s).
A response at the Geocoding Developer's Kit for ArcGIS 10.0? thread on GeoNet refers to a technical paper whose URL is no longer valid (at least as of today).
Sincerely, Nathan Lowry
GIS Outreach Coordinator
P 303.764.7801 | F 303.764.7764
601 East 18th Avenue, Suite 220, Desk D-23, Denver, CO 80203-1494
nathan.lowry@state.co.us | www.colorado.gov/oit
How am I doing? Please contact my manager Jon Gottsegen (jon.gottsegen@state.co.us) for comments or questions.
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.