I need to fetch location data based on given text.
As example if I search Aldi in google map it shows me lot of data with pagination. I need to get that result using google places api.
I tried it with two API calls. But it returns me following result
https://maps.googleapis.com/maps/api/place/textsearch/json?query=Aldi&key=MY_KEY
Result
{
"html_attributions" : [],
"results" : [],
"status" : "ZERO_RESULTS"
}
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=ALDI&inputtype=textquery&fields=place_id,name,formatted_address,geometry&key=MY_KEY
Result
{
"candidates" : [],
"status" : "ZERO_RESULTS"
}
I need to fetch data based on the given name. Can anyone find out the reason.
There are three types of searches provided by the Places API: Find Place, Nearby Search and Text Search. Each allows you to specify a location with radius to start the search from. The location is specified as a latitude/longitude pair. You received ZERO_RESULTS because you didn't specify a location for your request. If the location parameter is not specified "the API uses IP address biasing by default" according to the documentation. So, there are no Aldi stores within range of the location of your IP address.
Find Place will only return one result though, in my experience, it sometimes returns two. Both Nearby Search and Text Search will return up to 60 place results. All three of the Place search requests allow specifying a radius around your location of up to 50 kilometers. If you need to find Aldi places worldwide you'll need to make quite a few requests.
I am weeks into a similar project to find all locations for a list of restaurant chains in the US. I have found that Nearby Search is a better choice for my use case and should be considered always before committing to Text Search for a project. I've tested Aldi searches with both Nearby Search and Text Search and found that they provide the identical set of place_id results. This Nearby Search request will find all Aldi locations within 50 kilometers of New York City:
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=40.785276%2C-73.9651827&name=Aldi&radius=50000&key=MY_API_KEY
Here is the same as a Text Search:
https://maps.googleapis.com/maps/api/place/textsearch/json?query=Aldi&location=40.785276%2C-73.9651827&radius=50000&key=MY_API_KEY
So why should we care? Text Search according to API documentation "... returns all of the available data fields for the selected place, and you will be billed accordingly." Furthermore "... the Text Search service is subject to a 10-times multiplier. That is, each Text Search request that you make will count as 10 requests against your quota." A Nearby Search request is less expensive and not subject to the 10x multiplier. It returns a subset of the available data fields that you might find sufficient. If you need additional data fields, you can get only what you need from a Places Detail request. Do the math for your application before you select Text Search. It might be dramatically less expensive to implement using Nearby Search followed by Places Detail requests if necessary. In any case, you don't want to be shocked when you hit quota limits unexpectedly because of the 10x multiplier OR the billed transaction costs are more than you expect!
I have found additional hurdles that should be considerations for projects attempting to find all locations for a business in a large area:
The Places API will prefer places within your radius but will include places outside your radius if it determines they are relevant and within the 60 place limit. I have had places returned more than 450 kilometers from my requested search position.
Results are going to be returned for places with names that are NOT what you searched for. In my search for the restaurant Benihana in Seattle a Nearby Search request only returns a restaurant with the name Hamansu. Upon investigation, this is because there is not a Benihana in Seattle, however, Hamansu is similar to Benihana in that it serves Japanese dishes grilled tableside. The API documentation states your search term will be "matched against all content that Google has indexed for this place, including but not limited to name, type, and address, as well as customer reviews and other third-party content."
Results are returned 20 at a time. If there are more results, a page_token is provided to make a request to get the next page of up to 20 results. Each request is chargeable. You will be billed for the 3 requests required to get 60 results. I'm not saying this is bad, just be aware of the expense and quota usage you are incurring with this API.
If there are more than 60 results for your radius then you haven't found all the possible locations within it. And, you can't determine with certainty what the effective radius covered was for the 60 results. You need to search with a small enough radius to return < 60 results for each request. A worldwide search is going to require a large quota and $ budget to pursue.
You should be aware that Places API search is not designed to provide results world wide. In your examples you specify only text value 'Aldi'. However, in order to get results you should specify also where you are searching.
For example, if I want to bias results towards Barcelona area in Spain I have to add location and radius in my request
https://maps.googleapis.com/maps/api/place/textsearch/json?query=Aldi&location=41.3850639%2C2.1734035&radius=10000&key=MY_API_KEY
This request will return Aldi supermarkets in Barcelona area as shown in my screenshot
The same thing for Find place, you should specify location bias
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=Aldi&inputtype=textquery&fields=formatted_address,geometry,name,place_id&locationbias=circle%3A1000%4041.3850639%2C2.1734035&key=MY_API_KEY
Also note that Find place returns only one result.
I hope this addresses your doubt.
#Art answer, which is marked with higher upvotes, is only partially correct. The answer suggests that the Find Place api (e.g. maps/api/place/findplacefromtext) will usually return 1 result, at most 2. I tend to agree with him. Even if your search hits multiple targets, only one would be returned with the Find Place api. Consequently, he recommends to use Nearby Search or Text Search, both of which would yield at most 60 results.
However, these two searches require some form of location parameter, otherwise they will likely return 0 results, defaulting to using your IP address, as he indicates. But he recommends using a location accompanied with a radius parameter. The problem with this is the radius parameter has a maximum limit. So it will not target all types of things you want if you are searching over the stretch of an entire country, such as the United States.
The truth is you do not need to use the location and radius. There is another option called region. And you can use region to search the entire distance of a country.
What #Art suggested:
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=25.7392%2C-80.3103&name=Law%Offices%of%Alex&radius=50000&key=KEY
https://maps.googleapis.com/maps/api/place/textsearch/json?query=Law%Offices%of%Alex&location=25.7392%2C-80.3103&radius=50000&key=KEY
A more encompassing alternative:
https://maps.googleapis.com/maps/api/place/textsearch/json?query=Law%Offices%of%Alex®ion=us&key=KEY
You need to specify the location of your search.
Related
I would like to calculate the number of unique kilometers of roadways in my city. More generally, I wish to sum the distance of every road within a bound, for simplicity a rectangle will do.
Is this possible using the Google Maps suite of APIs? If so, how would you go about doing it? If anyone has any resources related to this type of problem, I would be interested in reading them regardless of language (or even solutions with other mapping tools).
Bonus points: A general solution to this problem that can be applied to the pre set "cities" (example) that appear in Google Maps with well defined city limits.
You can use OpenStreetMap to calculate the total road length of a specific country or geographic area. There are multiple solutions available, based on multiple similar questions already asked.
Approach 1 from Total road length in Kilometers for a country at help.openstreetmap.org:
Use the Perl script osm-length-2.pl. There is an example at a mailing list post.
Approach 2 from Actual road length of exported map at help.openstreetmap.org:
Import your data (the planet or an country or area extract) into a PostGIS database, then use the following queries proposed by Frederik Ramm:
SELECT way AS clip
INTO clipping_polygon
FROM planet_osm_polygon
WHERE boundary='administrative' AND admin_level='8' and name='My City';
SELECT name, highway, ST_INTERSECTION(way, clip)
INTO clipped_roads
FROM planet_osm_line, clipping_polygon
WHERE ST_INTERSECTS(way, clip) AND highway IS NOT NULL;
SELECT highway, SUM(ST_LENGTH(way::geography))
FROM clipped_roads
GROUP BY highway;
Essentially I have an extensive list of different intersections. My end goal is to create points and lines for Intersection A to Intersection B for each order I have which contains a starting point and ending point. The problems I am running into are as followed:
1). Using API I have only found a way to get lat and long by entering each individual intersection and putting the output in an excel file. But, this will take way too long as I have multiple different intersections. I am looking for a different way to get the lat and long points for all of these maybe something through R or Python but everything I have read uses addresses.
2.) Once I get these lat and long points I want to put this on a map as points and connect the points to make lines for each of the start and end points on an order?
Any kind of help to push me in the right direction would be great.
This is only one of what I'm sure is many answers. Whether or not an API allows intersection geocoding is dependent on the vendor. For instance, the MapQuest API allows you to geocode intersections and will return the geocode type in the response: https://developer.mapquest.com/documentation/samples/geocoding/v1/address/
I did a simple test with this intersections and the first result was an intersection: https://www.mapquestapi.com/geocoding/v1/address?key=KEY&inFormat=kvp&outFormat=json&location=12th+ave+and+speer+blvd%2C+Denver%2C+CO&thumbMaps=false
The first link I provided is a testing console so you can see if it will suit your needs. You would need to filter out your responses to only include results with the type "geocodeQuality": "INTERSECTION"
They support batch geocodes, but I would use the single location geocoder as a test.
Our website lets people create listings and these include a location field, which is populate by Google's API, just like on Airbnb, for example. You start typing any part of your address and then you select from the Google's suggestions of matching places.
People can search the listings by location (same Google API populated location field, and you can choose what distance from that location), and this seems to work fine in principle.
The issue is that the search doesn't seem to work for areas, e.g. counties. It seems to take a point within the region and measures from that. So, if I search for listings in "United Kingdom" I get hardly any results 'Within 10 miles' but I get a lot 'Within 250 miles'.
Instead, I want to get all results within the UK if I search for United Kingdom (or a UK county, or within a large city like London).
Why doesn't it work right now, and how can this be done?
To restrict the Autocomplete Box (I guess this is the component you're using) to a country, you can use componentRestrictions as described here (scroll to Restrict the search to a specific country )
If you need to restrict your search in a specific area, such as "10 miles around a defined point", it's a little more complicated. According to the doc, you'll have to
Set the bounds on creation of the Autocomplete object.
Change the bounds on an existing Autocomplete.
Set the bounds to the map's viewport.
Restrict the search to a specific country.
You can find an exemple here on paragraph Set the bounds on creation of the Autocomplete object
Google Maps API does a great job trying to locate a match for nearly every query. But if I'm only interested in real locations, how can I filter out Google's guesses?
For example, according to Google, "under a rock" is located at "The Rock, Shifnal, Shropshire TF11, UK". But a person who answers the question, "Where are you?" with "Under a rock" does not mean to indicate that they are in Shropshire, UK. Instead they just don't want to tell you — well, either that or they are in real trouble, thankfully with web access, stuck under some rock.
I have several million user generated location strings that I'm attempting to find coordinates for. If someone writes "under a rock" I'd rather just leave the coordinates null instead of putting an obviously wrong point in Shropshire, UK.
Here are some other examples:
under a rock => Shropshire, UK
planet earth => Cheshire, UK
nowhere => Scituate, RI, USA
travelling => Madrid, Spain
hiding => Anderson, CA, USA
global => Midland, TX, USA
on the web => North Part, ON, Canada
internet => Frisco, TX, USA
worldwide => Mie Prefecture, Japan
Ultimately I'm after a solid way to return coordinates from a string but return false if the location is like the above.
I need to build a function that returns the following:
Twin Cities => Return the colloquial coordinates of Minneapolis-St. Paul
right behind you => false [Google get's this one "right" -- at least for my purposes]
under a rock => false
nowhere => false
Canada => Return coordinates
Mission District San Francisco => Return coordinates
Chicago => Return coordinates
a galaxy far far away => false [Google also get's this "right" — zero results]
What do you recommend?
Here's a comma-delimited array for you to play at home:
'twin cities','right behind you','under a rock','nowhere','canada','mission district san francisco','chicago','a galaxy far far away','london, england','1600 pennsylvania ave, washington, d.c.','california','41.87194,12.56738','global','worldwide','on the internet','mars'
And here's the url format:
'http://maps.googleapis.com/maps/api/geocode/json?address=' + query + '&sensor=false'
ex: http://maps.googleapis.com/maps/api/geocode/json?address=twin+cities&sensor=false
It seems most of your incorrect results have a "partial_match" attribute set to "true".
e.g.
Twin Cities, no partial match:
http://maps.googleapis.com/maps/api/geocode/json?address=Twin%20Cities&sensor=false
under a rock, 10+ results, all with partial match:
http://maps.googleapis.com/maps/api/geocode/json?address=under%20a%20rock&sensor=false
Though the original purpose of this attribute is not to tell wether a locality is correct or not, it's still pretty accurate on the dataset you provided.
From Google Maps API documentation:
partial_match indicates that the geocoder did not return an exact match for the original request, though it was able to match part of the requested address. You may wish to examine the original request for misspellings and/or an incomplete address.
Partial matches most often occur for street addresses that do not exist within the locality you pass in the request. Partial matches may also be returned when a request matches two or more locations in the same locality. For example, "21 Henr St, Bristol, UK" will return a partial match for both Henry Street and Henrietta Street. Note that if a request includes a misspelled address component, the geocoding service may suggest an alternate address. Suggestions triggered in this way will not be marked as a partial match.
This might not be the direct answer to your question.
If you are currently going through 1000s of user input saved in db, and filter out the invalid ones, I think it is too late and not feasible. The output can be only good as input.
The better way is to make input as valid as possible, and end users don't always know what they want.
I would suggest you that user enter their address through autocomplete, so that you will always have the valid address
User enters text, and select the suggestions
An marker and info window will be shown
When user confirms input, you save info window text as user input, not from text input.
By doing this way, you don't need to validate or filter user input.
I know there are Bayes Classifier implementations in javascript. Never tried them though, I currently use a Ruby implementation which works correctly.
You could have two classifications (Real and Unreal), training each of them with how many samples you want (30, 50 samples each?). "If your classifier is well trained, it will be more accurate".
Then you'd have to test the location before calling GoogleMaps API to filter Unreal locations.
To truly succeed here you are going to have to build a database driven system that facilitates both positive and negative lookups with AI that gets smarter over time, just like Google did. I don't believe that there is a single algorithm that will filter out results based on cosmetics alone.
I looked around and found a site that contains every city in the world. Unfortunately, it doesn't give it as a single list so you'd have to spend a bit of time harvesting data. the site is http://www.fallingrain.com/world/index.html.
They seem to be using individual directories for organizing countries, states, and cities. Then, broken down further by alphabet. It is however the only comprehensive that I could find.
If you manage to get all of these locations into a database then you will have the beginnings of a positive lookup system for your queries. Also, you'll need to start building separate lists of bi, tri, and quad-city areas as well as popular destinations and land marks.
You should also store a negative lookup table for all known mismatches. People have a tendency to generate similar false data and type-o's across large populations. So, the most popular "nowhere" and "planet earth" answers will be repeated over and over again and, in every language you can think of.
One of the benefits of this strategy is that you can run relational queries against your data to get matches in bulk instead as well as one at a time. Since some false negatives will occur at the beginning then your main decision is to determine what you want to do with unmatched items. You may want to adopt a strategy where you have the ability to both reject non-matches as well as substituting partial matches with the nearest actual match.
Anyhow, I hope this helps. It is a bit of effort but if it's important it will be worth it. Who knows, you may end up with a database that's actually worth something. Maybe even a Google maps gateway service for companies/developers who need the same functionality. (:
Take care.
I'm using http://maps.google.com/maps/geo? web service to geocode some addresses.
The problem I have is that a fuller address doesn't necessarily give a more accurate geocode.
e.g passing in Llantysilio, Denbighshire, UK is far more accurate than Llantysilio, Llangollen, Denbighshire, UK
The Accuracy attribute in the XML doesn't seem very helpful in deciding which address to pick.
How have other people dealt with this issue? Is there a good way to pick the best geocode that works most/all of the time?
*edit
A bit of extra info - when I put in the fuller address the first line of the address is ignored and the geocoder jumps to a different, but exact, address which is a central street located in the extra line added to the address. In this example, it picks Castle Street in the middle llangollen, seemingly disregarding Llantysilio.
Edit by kdgregory: here are the two API requests that I used (missing API key doesn't seem to be an issue):
http://maps.google.com/maps/geo?q=Llantysilio,+Denbighshire,+UK&sensor=false&output=xml
http://maps.google.com/maps/geo?q=Llantysilio,Llangollen,++Denbighshire,+UK&sensor=false&output=xml
You have to interpret the accuracy my friend. There are usually 2 parts to an accuracy, first the address macthing. The second part is the important part. You can geocode something to a accuracy level of the United States, or a city level, zipcode centroid, street interpolated level or an actual parcel precision level. The first example has a 4 and the second is 9. For this service higher is better.
Accuracy Value Description
0 Unknown accuracy.
1 Country level accuracy.
2 Region (state, province, prefecture, etc.) level accuracy.
3 Sub-region (county, municipality, etc.) level accuracy.
4 Town (city, village) level accuracy.
5 Post code (zip code) level accuracy.
6 Street level accuracy.
7 Intersection level accuracy.
8 Address level accuracy.
9 Premise (building name, property name, shopping center, etc.) level accuracy.
It's probably good to note that Google does not follow the XAL specs, but rather implements them in a subset.
So, this means that you won't necessarily be able to do:
place.AddressDetails.Country.AdministrativeArea.Locality.LocalityName
place.AddressDetails.Country.AdministrativeArea.AdministrativeAreaName
place.AddressDetails.Country.CountryName
Because a country and sub-locality may be provided while a administrative area is not.
The data that is returned is identified with an accuracy gauge that gives you a relative idea of what you can expect for data. So, you can store objects and chop off parts of the full address using this variable and try to geocode in such a fashion - It's not recommended though.
Typically, a full address is (without the thoroughfare) is a good way of finding the general location. You can use some of the weighted-preferential logic Google provides to refine the address.
E.g. Use the setViewPort or setCountryCode to give your searches a bit more accuracy.
Remember, Geocoding is not a science. You can't expect consistent results.
A geocode response.Placemark[0] via gmap you can check what you got, and take the level or try again. I chose default in the order
place.AddressDetails.Country.AdministrativeArea.Locality.LocalityName
place.AddressDetails.Country.AdministrativeArea.AdministrativeAreaName
place.AddressDetails.Country.CountryName
It could be more logically named as seen above. gmaps 3 works somewhat incompatible with v2.
You can try a very ugly hack which consists in geocoding your full adresse and all subsets of the words your adress contains, you get a lot of geocodes that you use to get the adresses related to them with reverse geocoding tool.
Once you have plenty of adresses you compare them with the one you first gave, then you take the most accurate geocode...
Many requests, lot of iteration growing with each word you add to your adress, well an ugly work but can be fun to make some statistics ^^
In the end I concluded that there are far too many weird blips in address consistency with google's geocoding webservice in the UK, but eventually managed to figure out a way of using postcodes instead, which is far more accurate: how it's done