3

For some addresses that I attempt to geocode, google returns inappropriately inconclusive results.

The following is an example, but it is not an isolated incident. The first returned result is the exact match, however google flags it as a "partial_match":

Street address: 16160 Frederick Rd 
City:           Gaithersburg 
State:          MD
Zip code:       20877

Link: http://maps.googleapis.com/maps/api/geocode/json?sensor=false&address=16160%20Frederick%20Rd,+Gaithersburg,+MD,+20877

My issue here is in determining which is the correct match. In this case, the "partial match" flag is not useful because it is set to "true" on all matching results. In this case, I could test for equality on the street address, city, state, and/or zip, however, if there is even a small difference in spelling between what I send google, and what I get as a response, that will not work either. (Example: "Road" vs "Rd").

Am I doing something wrong here? Is there a conclusive way to distinguish the exact match that I am unfamiliar with?

Thanks!

Matt
  • 22,721
  • 17
  • 71
  • 112
Chris Dutrow
  • 48,402
  • 65
  • 188
  • 258

1 Answers1

3

Google does a wonderful job at address approximation. What you're looking for is address verification. SmartyStreets provides an address verification API that is conclusive in it's results. Here's what the SmartyStreets API returns for that address:

Input:

https://api.qualifiedaddress.com/street-address/?street=16160%20Frederick%20Rd&street2=&city=gaithersburg&state=md&zipcode=20877&candidates=10&auth-token=YOUR_AUTHENTICATION_TOKEN_HERE

Output:

[
    {
        "input_index": 0,
        "candidate_index": 0,
        "delivery_line_1": "16160 Frederick Rd",
        "last_line": "Gaithersburg MD 20877-4011",
        "delivery_point_barcode": "208774011604",
        "components": {
            "primary_number": "16160",
            "street_name": "Frederick",
            "street_suffix": "Rd",
            "city_name": "Gaithersburg",
            "state_abbreviation": "MD",
            "zipcode": "20877",
            "plus4_code": "4011",
            "delivery_point": "60",
            "delivery_point_check_digit": "4"
        },
        "metadata": {
            "record_type": "S",
            "county_fips": "24031",
            "county_name": "Montgomery",
            "carrier_route": "C004",
            "congressional_district": "08",
            "latitude": 39.12162,
            "longitude": -77.17619,
            "precision": "Zip9"
        },
        "analysis": {
            "dpv_match_code": "Y",
            "dpv_footnotes": "AABB",
            "dpv_cmra": "N",
            "dpv_vacant": "N",
            "ews_match": false
        }
    }
]

Notice that the "dpv_match_code" is "Y". That's USPS-speak for a verified delivery point--you know that it's a real address at that point. SmartyStreets uses official, current USPS data and is a CASS-Certified software provider.

Once you've received a result from SmartyStreets you could then geocode it with Google. Full disclosure: I'm a developer at SmartyStreets.

EDIT: Added Latitude/Longitude fields (newly released)

Michael Whatcott
  • 5,603
  • 6
  • 36
  • 50
  • 1
    I'v already integrated Smarty-Streets into my address-verification algorithm. Theres a possibility I've even talked with you on the phone - great phone support by the way! I've tested a few other services and your parser is the best I've encountered. The issue that I have with Smarty-Streets is that it doesn't return longitude and latitude, so if I get something back from smarty-streets, I have to go back and try to get longitude and latitude from somewhere else. – Chris Dutrow Feb 22 '12 at 16:54
  • Understood. Sorry I didn't recognize you! :) Stay tuned for lat/lon at some point is the hopefully-not-too-distant-future. – Michael Whatcott Feb 22 '12 at 18:09
  • 1
    Update! A little delayed here, but as you can see: SmartyStreets now performs geocoding (and has for a while). – Matt Oct 01 '12 at 03:57