Does the v3 Google Maps Geocoding API have a field that represents accuracy?

Question

I have some code that I'm porting over from API v2 to v3. In the old code we had an accuracy field that came back in the xml (not sure of the name, but it did represent a confidence level of sorts). In the new API, I don't see any field like that.

If I put "Oregon, USA" into the search field I get 5 matches. The first 2 are "Oregon, USA" and "Oregon, OH, USA". They both have "partial_match" = false. This doesn't seem right, one seems partial and one doesn't. Plus, they're both coming back with the same "location_type" (APPROXIMATE). In fact, all matches are showing as not-partial and have same location type.

My question is, do any of the fields in the result set convey some sort of confidence in the accuracy of the result? In my sample it really seems like one result is much more accurate than any other -- so much so that the input string exactly matches the QuickAddress field that's returned.

Enculturation

Answer 1

Two weeks, no answers, so here's my solution.

The API will return either ROOFTOP, GEOMETRIC_CENTER, RANGE_INTERPOLATED or APPROXIMATE.

Rooftop is essentially "dead on" -- the API resolved the address to a building. Other than that, you get varying degrees of "close". My solution was to use the bounding box that was returned to determine how close close was. So if you ask for a street (Avenue of the Americas, NY, NY) you'll get a huge bounding box. Ask for an address on that street that the API thinks is an actual address but isn't a Rooftop, you'll get a very small bounding box. I used the area of the bounding box to determine the accuracy of the result. My accurate/not accurate break was at 0.9E-6 but I think you'd have to tinker with it to make sure you are comfortable with that number.

Enculturation

Very clever. Would not have thought of that. I did some testing with our "non-rooftop" addresses and found a huge range. We have four breakdowns, rooftop, street (i.e. block, or ZIP+4), ZIP+2, and ZIP. For each of the Google non-rooftop location-types I created logic to further analyze the accuracy because sometimes APPROXIMATE ends up more like ZIP+4 (which, in urban areas is usual pretty close to rooftop) and RANGE_INTERPOLATED is more like ZIP, i.e. huge. – Short

One other thing I noticed was that sometimes Google gives ROOFTOP with just the street address but adding suite/unit/apt/whatever... made it switch to APPROXIMATE even though the lat/lon stayed the same. This is where your idea came in handy. Other times just the street address APPROXIMATE while adding the sub-unit makes it switch to ROOFTOP. I saw more of the first, i.e. more data, less "confidence". I'm thinking of building in logic to try without sub-unit first and if not ROOFTOP try with sub-unit. If still not ROOFTOP, then compare the bounding boxes and use the smaller one. – Short

@AndrewS thanks, I was feeling like I was the only one in this particular corner of the internet -- never got an answer on google groups as I recall... – Enculturation

Answer 2

I have found this useful when updating legacy V2 code dependent on a 0 to 9 score
//Hack to convert location_type (string) to 0-9 Geocode score as 0-9 Geocode score doesn't exist in v3 API

function get_numeric_score(results) {
switch(results[0].geometry.location_type){
        case "ROOFTOP":
            return 9;
        break;

        case "RANGE_INTERPOLATED":
            return 7;
        break;

        case "GEOMETRIC_CENTER":
            return = 6;
        break;

        case "APPROXIMATE":
            return 4;
        break;

        default:
            return 0;

    }
}

Barmy