I have been working recently with the geocoding API and had a few questions regarding the accuracy of geocoding requests. If I geocode an address using the API and then reverse geocode the coordinates generated from the initial result the two street addresses usually do not match (usually by two houses or so).
Is this an issue with geocoding accuracy or reverse? Is there anything I can do to combat this or is this merely inherent within the API. If so is there any way that I can provide a margin of error when performing these actions, i.e is this inaccuracy documented anywhere?
Obviously it is to be expected that the geocoding API cannot be completely accurate 100% of the time, but I would like to able to see some numbers or documentation on the subject is anyone has any suggestions?
Thanks in advance,
Best,
Chris.
Edit I realise this is an old question but it was never answered and if recently come across the issue again, and have been questioned on this by clients paying for business licences before.
The level of detail in the data that Google has/provides varies from location to location.
The GeocoderLocationType in the GeocoderGeometry you receive indicate how precise the geocoding is:
APPROXIMATE
The returned result is approximate.
GEOMETRIC_CENTER
The returned result is the geometric center of a result such a line (e.g. street) or polygon (region).
RANGE_INTERPOLATEDThe returned result reflects an approximation (usually on a road) interpolated between two precise points (such as intersections). Interpolated results are generally returned when rooftop geocodes are unavailable for a street address.
ROOFTOPThe returned result reflects a precise geocode.
Related
Regarding Google's Geocoding Webservice: Is there documentation (beyond Google's documentation), articles, or anything out there regarding how to format addresses to get accurate results.
Some of my locations have names preceding the address. If it recognizes a street address in the string, I can usually get rooftop back. In some cases having a single quote or special character in the name will cause it to just recognize the address and geocode rooftop.
However, I am also seeing cases where it finds the exact place correctly as an establishment, a church for example, but still says the 'location_type' is approximate. Other cases where having words preceding the address causes it to only seem to recognize the zip code and it just geocodes the zip.
I am wondering if anyone has insight into how Google's Geocoding webservice API recognizes/parses locations? What causes it to see the address in one case, but only see a zip in another?
Also, is there maybe a better way to interpret accuracy than just that 'location_type' field?
So basically you have to follow the standard mailing address format that is used by the respective country the address falls in and refrain from using apt/house/suite numbers. Use street number for the building/complex/entity rather than names.
This is what you need to go through. However, please do your research first and ask a question as a last resort.
I'm not a coder or programmer, but I have hired someone to do so for me. I'm also not completely naive when it comes to computer capabilities...
I am being told by the developer that it is impossible to reverse geocode in google maps api and have it accurately return the correct city. I don't believe this because I see the api return a formatted address with the city in it. The developer is saying that they can only pull one field from the API and because city names are located in either the locality field or neighborhood fields, they have no way of determining which to use for the different coordinates. Are these true statements?
I am also being told that reverse geocoding for the nearest city when the coordinates exists over water (mostly in the ocean), is impossible. For example, is it true that a coordinate 5 miles directly west of San Diego is impossible to have it return San Diego as the nearest city?
I have searched on here for solutions and found a few related to this, which I have forwarded to the developer... but I am hoping to take this exact thread and show it to them as well. Are these things really impossible with Google Maps API?
Thank you for the help!
Look in this document for reverse geocoding in the Google Maps JavaScript API, for a detailed description how to convert coordinates in a readable address.
Your first statement is kind of true:
You can read all fields from the arrays in the results of the Geocoder if necessary. If the address_components array has an element locality in the types, the city name is part of it. But it's NOT guarenteed that there is always this element or the desired element contained. Have a look at the hierarchie of the types in the link above, which may be part of the response. When you say you have to search the elements neighborhood and locality, it sounds to me you wanna force a specific name. This is almost impossible to determine.
The second statemant, about the nearest city is true. Here is a statement from the docs:
Reverse geocoding is not an exact science. The geocoder will attempt
to find the closest addressable location within a certain tolerance.
There is nothing stated about the dimensions of this tolerence. Your example of 5 miles west of San Diego can return data about San Diego, the North Pacific Ocean or Coronado, which is in San Diego County.
Trust your developer!
Edit: It depends what you wanna do. If you always wanna have the city name in your request, forget it you can't guarantee that.
There are some zipcode APIs which are described in this answer. But again, you have to get the Zipcode somehow, and the postal_code isn't always part of the response. There are no other APIs like geocoding ones which can convert coordinates to readable addresses. But there are some out there listed here.
It is possible to achieve what you want. I think most people try to have Google do the work for them and that's why it's tricky to find a solution.
You want the nearest city. All you need to do is query the coordinates. If an address type "locality" exists, that's your city. If not, make a new request for a nearby point and repeat until you find an result that has "locality".
Based on the algorithm you use to search around your initial point you can adjust accuracy and the amount of requests you need to find your answer.
Is there a way to determine what traffic condition is at specified concrete point or street? I figured out i could just "ask directions" and divide by length but it would be more convenient to have such stuff in the api, i.e., get the full list of streets where is currently a traffic jam in one city.
I have been looking for those API's myself. Dont think they are available.
I want to get geocode from google, and I used to do it with the V2 of the API.
Google send in the json a pretty good information, the accuracy, reference here : http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy
In V3, Google doesn't seem to send me exactly the same information. There is the array "adresse_component", which seem bigger if the accuracy is better, but not exactly.
For example, I have a request accuracy to the street number, the array is of size 8.
Another query is accuracy to the route, so less accuracy, but the array is still of size 8, as there is a row 'sublocality', which not appear in the first case.
Ok, for a result, Google send a data 'types', which have the 'best' accuracy. This types are here : http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types
But, there is no real order, and if I wan't the result better than postal_code, I have no clue to how to do that.
So, how can I get this equivalent of the V2 accuracy, whithout some dumb and horrible code ?
Well, there is the location type, 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 a precise geocode for which we have location information accurate down to street address precision.
"RANGE_INTERPOLATED" indicates that the returned result reflects an
approximation (usually on a road) interpolated between two precise
points (such as intersections). Interpolated results are generally
returned when rooftop geocodes are unavailable for a street address.
"GEOMETRIC_CENTER" indicates that the returned result is the geometric
center of a result such as a polyline (for example, a street) or
polygon (region)."
"APPROXIMATE" indicates that the returned result is
approximate.
I test if the location_type is different of approximate, and it gives some good results.
With Google deprecating their Geocoding v2 API later this year, there's going to be a ton of people migrating their geocoding logic to v3 and this very question is going to crop up: How to map the 'location_type' string to an equivalent 'accuracy'?
Here's a decent mapping:
"ROOFTOP" -> 9
[Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE")
If something other than ROOFTOP is specified, use the area of 'northeast' and 'southwest' to decide if it is accurate enough for you.
Now what should happen if you don't get something "accurate"? Run a Google Places text search query for the same address. Google Places does geocoding as well and, with Billing enabled, you can get 10,000 Places text search queries per day (no rate limit) and Google claims they won't charge the card (they supposedly just use it for verifying the account). With Billing, you get 100,000 queries, but Places text search queries have a "cost" of 10 times the amount of a regular Places query, hence the aforementioned 10,000 limit. Places can be finicky though and you should only consider responses with one result.
Sometimes Places queries will not return a zipcode - especially if one isn't sent. If you need the zipcode, take the lat/lng results of the Places query and feed it back into the geocoder, which will usually spit out an address with a zipcode (and very frequently a ROOFTOP match).
It should be noted that the official Geocoding API courtesy limit is 2,500 requests per day with a rate limit of one per second per IP address. Therefore, following the above formula will likely decimate and may even halve the number of geocodings available to you.
If you need more than the Google Geocoding limit (who doesn't?), invent your own mini geocoding service with something like the OpenStreetMap database. Clone the parts of OpenStreetMap that you need and write your own geocoder (or use a library). Then you can geocode to your heart's content with no quantity limit or rate limit. If you still use Google Maps, you can use Google's geocoder as a fallback should the OSM geocoder not be accurate enough for all cases.
Alternatively, if you trust your users to not submit bogus data (really?) and have to use the Google geocoding service, you could also abuse a user's web browser by having the browser geocode information for you and then feed the results to your server. You might burn through the user's daily limit and you risk someone pushing bogus data, but if you are going to all that trouble, do you actually care?
At any rate, the tips above should suffice for interim usage for most users to get a working v3 API set up. Ran into this issue myself, so figured I'd share with the community a halfway decent solution. I still think v2 was the better API - integer accuracy ratings instead of ugly text strings always wins out.
Paula's answer is good but you do need to also consider John's comment that ROOFTOP can return garbage.
I use a post-geocode-query sanity checker to get rid of those cases where location_type is 'ROOFTOP' but the address has nothing to do with the address you sent to google - this sanity checker compares the new address with the old address and considers what changed and by how much. The google geocoder is good at fixing typos, sometimes, but it can also make some non-sensical decisions - for instance choose a different city, a different state, or a different country. You need to decide if the result is a fix in a typo or if the geocode logic went astray.
So, don't just assume ROOFTOP == 9. It can also be garbage if the new address is way off from the original that you sent.
For things like Apartments or building with multiple units, the location_type = 'RANGE_INTERPOLATED' may also be accurate when the result type is 'subpremise'.
Remember, geocoding is not the same thing as address validation. They have some overlap but google geocode logic tries too hard to get you an answer, even when your input is garbage.
For example, searching for "36 High Street Clapham London SW4 7UR" using the geocoder gives a significantly different location from the main map search, rendering the geocoding service useless, for my purposes at least.
Anyone know why this is and if there's a workaround?
One thing to watch out for in UK geocoding is that the Royal Mail owns the copyright to UK postcode geographic information, and has refused to sell Google a licence to redistribute that information. Google has a licence hat allows it to use the information for geocoding on its own websites, but not for other people's websites. That doesn't explain that particular address, but it does affect the geocoding of many UK locations.
There was a bug in the API geocoder (maps.google.com geocoding was not affected) a while ago that caused it to get wrong information about the existence of certain house numbers in a street. It's possible that this might be happening again. Note that "34 Clapham High Street, London" geocodes correctly, but the API thinks that 36 doesn't exist, and just returns a location with accuracy=6 (street) instead of accuracy=8 (address). This might possibly be happening again. If you think that's what's happening, find several convincing examples and post them to the discussion group.
Well for one thing there's nothing that says the map search uses the geocoder service. Clearly, it's related, but may not be the same thing.
Also, the main map search is influenced by the current viewport of the map pane. If you're zoomed in one one country or location, the search will be biased by that. if you use the geocoder, you can supply various optional parameters including viewport bias.