How to get equivalent accuracy in Google Map Geocoder V3

Question

I want to get geocode from google and I used it with V2 API. Google sends json pretty good information, accuracy, link here: http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy

In V3, Google does not seem to send me exactly the same information. There is an array of "adresse_component" that seems larger if accuracy is better, but not quite. For example, I have the accuracy of the request for the street number, the array has a size of 8. Another request is the accuracy of the route, therefore less accuracy, but the array still has a size of 8, because there is a “sub-publicity” of the line that does not appear in the first case.

Well, as a result, Google sends data types that have “better” precision. These types are here: http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types But there is no real order, and if I don’t get a better result than postal_code, I don’t know how to do it.

So, how can I get this V2 precision equivalent without some kind of dumb and terrible code?

Answer 1

Well, there is a type of location , which is not so bad:

location_type stores additional data about the specified location. The following values ​​are currently supported:

"ROOFTOP" indicates that the returned result is an accurate geocode for which we have location information accurate to the street address.

"RANGE_INTERPOLATED" means that the returned result reflects an approximation (usually on the road) interpolated between two exact points (for example, intersections). Interpolated results are usually returned when rooftop geocodes are not available for a street address.

"GEOMETRIC_CENTER" indicates that the returned result is the geometric center of the result, such as a polyline (such as a street) or a polygon (area).

"APPROXIMATE" indicates that the returned result is approximately.

I am testing if location_type differs from the approximate one and gives good results.

Answer 2

With Google condemning their Geocoding v2 API at the end of this year, a ton of people will be porting their geocoding logic to v3, and this question will arise: how to match the string 'location_type' with the equivalent of 'precision?

Here's a decent display:

"ROOFTOP" -> 9 [Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE") 

If anything other than ROOFTOP is indicated, use the area for northeast and southwest to decide if this is enough for you.

Now, what should happen if you do not get something “exact”? Run the Google Places text search query at the same address. Google Places also performs geocoding, and with Billing turned on you can receive 10,000 text search queries per day (no speed limit), and Google claims that they will not charge a card (they presumably just use it to verify the account records). With billing, you get 100,000 queries, but the “Places” text search queries have a “cost” 10 times that of a regular “Places” query, hence the aforementioned limit of 10,000. Places can be too complicated, and you should only consider responses with one result.

Sometimes "Place" requests do not return zipcode - especially if one is not sent. If you need a zipcode, take the results of the lat / lng Places request and feed it back to the geocoder, which usually spits out the address using zipcode (and very often matches ROOFTOP).

It should be noted that the official politeness limit in the Geocoding API is 2500 requests per day with a speed limit per second per IP address. Therefore, following the above formula, it will probably decrease and may even halve the number of geocoding available to you.

If you need more than the Google Geocoding limit (who doesn't?), Come up with your own mini geocoding service with something like an OpenStreetMap database. Clone the parts of OpenStreetMap that you need and write your own geocoder (or use the library). Then you can geocode in your heart content without quantity or speed limits. If you are still using Google Maps, you can use the Google geocoder as a reserve if the OSM geocoder is not accurate enough for all cases.

Alternatively, if you trust your users not to send dummy data (really?) And should use the Google geocoding service, you can also abuse the user's web browser having the geocoding information for the browser for you, and then submit the results to your server . You can burn the user's daily limit, and you risk someone pushing dummy data, but if you are going to all these problems, do you really care?

In any case, the tips given above should be sufficient for intermediate use for most users to create a working API v3. Go into this problem, so I decided to share a decent solution with the community halfway. I still think v2 was the best API integer of precision ratings instead of the ugly text strings that always win.

Answer 3

Paula's answer is good, but you also need to take into account John’s comments that ROOFTOP can return garbage.

I use post-geocode-query health check to get rid of cases where location_type is 'ROOFTOP' but the address has nothing to do with the address you sent to Google - this health check program compares the new address with the old address and takes into account what has changed and how much. Sometimes Google’s geocoder can correct typos, but it can also make some meaningless decisions — for example, choose a different city, another state, or another country. You need to decide if the result is a typo or if the geocoding logic has gone astray.

Therefore, do not just assume that ROOFTOP == 9. It can also be garbage if the new address is different from the original that you sent.

For things like Apartments or multi-unit buildings, location_type = 'RANGE_INTERPOLATED' can also be accurate if the result type is "subpremise".

Remember, geocoding is not the same as address verification. They have some matches, but Google Geocode logic is trying too hard to get an answer, even if your input is garbage.