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.
Two weeks, no answers, so here’s my solution.
The API will return either
ROOFTOP,GEOMETRIC_CENTER,RANGE_INTERPOLATEDorAPPROXIMATE.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.