I was trying obtain "latitude-longitude" information for multiple addresses using google API. However, I observed that for few addresses I was getting different "latitude-longitude" values over a period of time. Can "latitude-longitude" change over a period of time? If yes, why? Or is it just a bug (or may be due to an update) in google API?
latitude-longitude pair define a geo-location in earth, and that point is generally not moving. If you get different results for same address information, then it is the service which for some reason gives different values. Thus do check that what actually is happening, either you are giving a different address, or the service is interpreting it diffferently. Best way to determine what has happened is to see what values were actually used in the query, and check all data given in replay (many APIs are giving also the address detail for the location given as result value)
Related
I'm trying to use the java client to get information about duration between 2 city but i need also the duration with traffic information. I'm using the java client 0.1.11 and i only get the duration without traffic information, there is no method about traffic mode so how can i do ?
EDIT : I want to use this part of the documentation :
traffic_model (defaults to best_guess) which is optional parameter.
According to the documentation provided by google you can get the "duration_in_traffic" but not the traffic details.And moreover this facility is only available to the google premium plan users.
Read this https://developers.google.com/maps/documentation/javascript/distancematrix#distance_matrix_results
The "traffic_model" option can take the following values
trafficModel (optional) specifies the assumptions to use when calculating time in traffic. This setting affects the value returned in the duration_in_traffic field in the response, which contains the predicted time in traffic based on historical averages. Defaults to best_guess.
The following values are permitted:
google.maps.TrafficModel.BEST_GUESS (default) or string value best_guess indicates that the returned duration_in_traffic should be the best estimate of travel time given what is known about both historical traffic conditions and live traffic. Live traffic becomes more important the closer the departureTime is to now..
google.maps.TrafficModel.PESSIMISTIC or string value pessimistic indicates that the returned duration_in_traffic should be longer than the actual travel time on most days, though occasional days with particularly bad traffic conditions may exceed this value.
google.maps.TrafficModel.OPTIMISTIC or string value optimistic indicates that the returned duration_in_traffic should be shorter than the actual travel time on most days, though occasional days with particularly good traffic conditions may be faster than this value.
The Google Maps Distance Matrix API is design for calculating the distances and the durations of multiple origin and multiple destination.
This api does not return traffic information. Please read the official document (before asking).
https://developers.google.com/maps/documentation/distance-matrix/intro
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 new to geocoding so I'm not certain this is even the question I should be asking, but all of the other discussions I've seen on this topic (here and on the Google API forum) are so application specific that I feel like I might be missing a very elementary step - I don't need to know how to implement a store finder - I need to know if I should.
Here is my specific situation - I have been contracted to design an application wherein we will build a database of shops (say, independently owned bars and pubs). This list will continually grow and change as shops close and new ones open. The user can enter his/her point of origin (zip code or address) and be shown a list or map containing all the various shops within a given radius in order of proximity.
I know how to deliver these results from a static database:
One would store the longitude and latitude as columns for each row and then just use that information to check distances.
But I have inherited an (already fairly large) database of shops which have addresses but not coordinates - so I'm not sure what the best way to get those addresses is. I could write a script to query them one at a time against google geocoding, I could have a data entry person manually look up the coordinates for each one and populate the data that way, or maybe there is a third option I'm not aware of.
Is this the right place to be asking this question? Google Maps Geocoding doesn't host a forum of their own, but refers people to Stack Overflow. Other forums on the net dealing with this topic are all relating to a specific technical question but no one seems to be talking about it from a top-down perspective (ie the big picture).
Google imposes a 2,500 queries per day limit on free users and a 100,000 queries a day limit on paid ones - neither of these seem to be up to the task of a site with even moderate traffic if, every time a user makes a request, the entire database (perhaps thousands of shops) are being checked against Google's data. It seems certain we must store the coords locally but even storing them locally, there will have to be checks against Google in order to plot them on a map. If I had a finite number of locations (if, for example, I had six hardware shops) and I wanted to make a store locator, there would be a wealth of discussions, tutorials, and stack overflow questions available to point the way for me, but I'm dealing with a potentially vast number of records and not sure how to proceed or where to begin.
Any advice would be welcome - Additionally, if this is not the best place to be asking this question, a helpful response would be to indicate a better place to post it. I've searched for three days but haven't found what looks like a good resource for asking such subjective questions.
The best way of course would be when you use a geocoding-service to get coordinates and store the coordinates in your DB. But it's not possible with google's geocoding-service, because it's not permitted to store geocoded data permanent.
There are free services without this restriction, some keywords to search for: mapquest, nominatim, geonames(but these services are less accurate than google)
Another option would be to use a FusionTable. The geocoding would run automatically(but the daily limits are the same as for the geocoding-service). The benefit: the geocoding is permanent(you can't access the locations directly by e.g. downloading the DB-dump), but you may use the coordinates for plotting markers(via a FusionTablesLayer) or filtering(e.g. by distance)
The number of entries shouldn't be an issue, 100k is no problem for a database
When geocoding human readable address into lat lng e.g. 3 mystreetname, myarea, mycity, mypostcode.
Should I use full address or just some part of it, for instance post code?
I know that it works ether way, but I'd like to know what would be the best practice to avoid errors geocoding locations.
Some cities span multiple postal codes, and some postal codes span multiple cities. You might not have problems with smaller data sets but as you start dealing with a lot of addresses things like that can pop up. It's entirely possible that there are two 201 Main Streets in the same zip code, located in two different cities.
So yep, give as much detail as you can.
I'd really recommend storing your information in a spatial datatype if your database supports that as well.
This link is the google's documentation of geocoding
https://developers.google.com/maps/documentation/geocoding/?csw=1
And refer below link for the real time sample..!
http://gmaps-samples.googlecode.com/svn/trunk/geocoder/singlegeocode.html
And for better results use more information so that you will get accurate answers
Hope it helps
I would try running the queries with as much detail as possible, and if a query fails rerun without the zip, as sometimes the zip causes problems with the google api (especially zips greater then 5 digits).
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.