Geocoding returns two possible locations but presents wrong address as most accurate and right address is least accurate - api

using https://www.google.ca/maps and the geocoding api gives the same results:
using https://www.google.ca/maps and searching for:
143 GARRISON CIR , RED DEER, AB , Canada
returns two results:
143 Garrison PL
143 Garrison Cir
using the API reveals that it considers the first one '... Pl' more accurate than '... Cir' when clearly the second one is more true to the original addressed used to search since it contains 'Cir'...
using:
https://maps.googleapis.com/maps/api/geocode/xml?address=143%20GARRISON%20CIR%20%2C%20RED%20DEER%2C%20AB%20%2C%20Canada
reveals the first result's accuracy is:
ROOFTOP
and the second result's accuracy is:
RANGE_INTERPOLATED {not as accurate}
WHY???
Interestingly... if I use the postal code in the full address {which I verified with Canada Post as being correct}:
'143 GARRISON CIR , RED DEER, AB T4P0P5, Canada'
I get no results from either method!
again... WHY???

The RANGE_INTERPOLATED result means that there is no exact street address feature in the Google database and the service tries to guess where the address is located. Maybe due to this reason the exact ROOFTOP result is scored higher than an interpolation. Especially taking into account that the coordinates of both results are very close to each other:
https://google-developers.appspot.com/maps/documentation/utils/geocoder/#q%3D143%2520GARRISON%2520CIR%2520%252C%2520RED%2520DEER%252C%2520AB%2520%252C%2520Canada
In order to solve this you should report a missing address to Google using Send feedback mechanism:
https://support.google.com/maps/answer/3094045
Also note that an interpolated result for the address has a different postal code T4N 3M4. Even more, if I try to search the postal code T4P 0P5, I'll get back only postal code prefix T4P:
https://google-developers.appspot.com/maps/documentation/utils/geocoder/#q%3D%26options%3Dtrue%26in_country%3DCA%26in_postal_code%3DT4P%25200P5
That means the postal code T4P 0P5 is also missing from Google database and you should report it as well.
As the postal code is missing you are getting ZERO_RESULTS for complete string 143 GARRISON CIR , RED DEER, AB T4P0P5, Canada
https://google-developers.appspot.com/maps/documentation/utils/geocoder/#q%3D143%2520GARRISON%2520CIR%2520%252C%2520RED%2520DEER%252C%2520AB%2520T4P0P5%252C%2520Canada%26options%3Dtrue
As you mentioned, we can see that the same behavior is reproducible on maps.google.com. There are two options for the address and Garrison Pl is the first item while Garrison Cir is the second. That confirms that this is a data issue rather than API issue:
I hope this explains your doubt.

Related

Odd results from Google Reverse Geocode API

Recently I've been occasionally receiving odd results from the Google Reverse Geocode API.
For example when looking up the address for coordinates 43.2379396 -72.44746565 the result I get is:
6HQ3+52 Springfield, VT, USA
In another case looking up 43.703563 -72.209753 results with:
PQ3R+C3 Hanover, NH, USA
Does anyone know what the initial 7 bytes of the returned address symbolize? When I receive this type of result it's always 4 bytes of alphanumeric data followed by a plus sign then 2 more alphanumeric bytes.
After some additional research I found that these are Plus Code addresses, a relatively new feature in Google Maps. These are used for places that don't have a street address. These seem to have some similarities to "what 3 words" addresses.

Amadeus flight-offers search GET API won't return flights for AA

I'm learning to use the Amadeus API...
I'm able to search flights using "flight-offers-search", but as the title states, if I restrict results to American Airlines (AA), it returns nothing.
There absolutely are AA flights from DFW on the specified day (I'm on one), so not sure why it would fail.
So far I am unable to return ANY flights on ANY day, if "includedAirlineCodes=AA" is specified.
What is special about American Airlines? What am I missing?
url <- "https://test.api.amadeus.com/v2/shopping/flight-offers?originLocationCode=DFW&destinationLocationCode=SAN&departureDate=2021-09-03&travelClass=ECONOMY&adults=1&max=5&currencyCode=USD&includedAirlineCodes=AA"
Content from American Airlines is not included in the Self-Service APIs as described in the API overview.

NYT article search API not returning results for certain queries

I have a set of queries and I am trying to get web_urls using the NYT article search API. But I am seeing that it works for q2 below but not for q1.
q1: Seattle+Jacob Vigdor+the University of Washington
q2: Seattle+Jacob Vigdor+University of Washington
If you paste the url below with your API key in the web browser, you get an empty result.
Search request for q1
api.nytimes.com/svc/search/v2/articlesearch.json?q=Seattle+Jacob%20Vigdor+the%20University%20of%20Washington&begin_date=20170626&api-key=XXXX
Empty results for q1
{"response":{"meta":{"hits":0,"time":27,"offset":0},"docs":[]},"status":"OK","copyright":"Copyright (c) 2013 The New York Times Company. All Rights Reserved."}
Instead if you paste the following in your web browser (without the article 'the' in the query) you get non-empty results
Search request for q2
api.nytimes.com/svc/search/v2/articlesearch.json?q=Seattle+Jacob%20Vigdor+University%20of%20Washington&begin_date=20170626&api-key=XXXX
Non-empty results for q2
{"response":{"meta":{"hits":1,"time":22,"offset":0},"docs":[{"web_url":"https://www.nytimes.com/aponline/2017/06/26/us/ap-us-seattle-minimum-wage.html","snippet":"Seattle's $15-an-hour minimum wage law has cost the city jobs, according to a study released Monday that contradicted another new study published last week....","lead_paragraph":"Seattle's $15-an-hour minimum wage law has cost the city jobs, according to a study released Monday that contradicted another new study published last week.","abstract":null,"print_page":null,"blog":[],"source":"AP","multimedia":[],"headline":{"main":"New Study of Seattle's $15 Minimum Wage Says It Costs Jobs","print_headline":"New Study of Seattle's $15 Minimum Wage Says It Costs Jobs"},"keywords":[],"pub_date":"2017-06-26T15:16:28+0000","document_type":"article","news_desk":"None","section_name":"U.S.","subsection_name":null,"byline":{"person":[],"original":"By THE ASSOCIATED PRESS","organization":"THE ASSOCIATED PRESS"},"type_of_material":"News","_id":"5951255195d0e02550996fb3","word_count":643,"slideshow_credits":null}]},"status":"OK","copyright":"Copyright (c) 2013 The New York Times Company. All Rights Reserved."}
Interestingly, both queries work fine on the api test page
http://developer.nytimes.com/article_search_v2.json#/Console/
Also, if you look at the article below returned by q2, you see that the query term in q1, 'the University of Washington' does occur in it and it should have returned this article.
https://www.nytimes.com//aponline//2017//06//26//us//ap-us-seattle-minimum-wage.html
I am confused about this behaviour of the API. Any ideas what's going on? Am I missing something?
Thank you for all the answers. Below I am pasting the answer I received from NYT developers.
NYT's Article Search API uses Elasticsearch. There are lots of docs online about the query syntax of Elasticsearch (it is based on Lucene).
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html#query-string-syntax
If you want articles that contain "Seattle", "Jacob Vigdor" and "University of Washington", do
"Seattle" AND "Jacob Vigdor" AND "University of Washington"
or
+"Seattle" +"Jacob Vigdor" +"University of Washington"
I think you need to change encoding of spaces (%20) to + (%2B):
In your example,
q=Seattle+Jacob%20Vigdor+the%20University%20of%20Washington
When I submit from the page on the site, it uses %2B:
q=Seattle%2BJacob+Vigdor%2Bthe+University+of+Washington
How are you URL encoding? One way to fix it would be to replace your spaces with + before URL encoding.
Also, you may need to replace %20 with +. There are various schemes for URL encoding, so the best way would depend on how you are doing it.

Google map api returns Notfound result for valid postal-cod for distance calculation

We are using Google map api to find distance between two postalcodes. We can get the distance between any two postalcodes by using google map api Working Map API example. Some of the postal-code this api returns NotFound error when the postal-code is sent without any space, but for the same postal-code if we give space after 3 letters it works well and returns the distance correctly.
API URL
http://maps.googleapis.com/maps/api/distancematrix/json?origins=H3W3C4&destinations=H1C0A6&mode=driving&language=en-EN&sensor=false
Example 1:
url:http://maps.googleapis.com/maps/api/distancematrix/json?origins=H3W3C4&destinations=H1A0C2&mode=driving&language=en-EN&sensor=false
postal-code: H1A0C2,
api result : NotFound
Example 2:
url:http://maps.googleapis.com/maps/api/distancematrix/json?origins=H3W3C4&destinations=H1A 0C2&mode=driving&language=en-EN&sensor=false
postal-code: H1A 0C2,api
result : returns correct distance
Below are list of postal codes for which api returns NotFound if we give postal-code without space(but if we give space like 'H1A 0C2' it will return results)
H1A0C2
H1A0C3
H1A0C4
H1B0B7
H1C0E3
H1C0E4
H1C0E5
H1C0E6
H1C0E7
H1C0E8
H1C0E9
H1C0G1
H1C0G2
below list postalcodes for which api returns the distance correctly if we give with/without space( like works well if we give 'H1C 0A7' and 'H1C0A7'.
H1C0A7
H1C0A8
H1C0A9
Though it works with or without space for most of the postalcodes, for few it does not return values without spaces. What could be the reason?
I would suggest checking if the postal code exists in the Google database.
For example the postal code H1A0C2 seems to be missing
https://developers-dot-devsite-v2-prod.appspot.com/maps/documentation/utils/geocoder/#q%3D%26options%3Dtrue%26in_country%3DCA%26in_postal_code%3DH1A0C2
As you can see, the geocoder tool returns only postal code prefix HA1, but not the postal code itself.
For the postal code H1C0A9 geocoder returns a complete postal code:
https://developers-dot-devsite-v2-prod.appspot.com/maps/documentation/utils/geocoder/#q%3D%26in_country%3DCA%26in_postal_code%3DH1C0A9
I think the distance matrix cannot find distance for missing postal codes. However, when you add an empty space it can find a postal code prefix and calculates distance based on coordinates of postal code prefix. So the result might be not precise enough in this case.
You can report missing postal codes to Google as described in the following support doc:
https://support.google.com/maps/answer/3094088
Hope this helps!

Google maps geocoding API address correction hierarchy

I'm trying to understand in what order and what precedence the geocoding API takes when processing the pieces of the address that was passed to it.
I have this example of why I'm asking the question. The correct address is:
2608 N Ocean Bv
Myrtle Beach, SC 29577
Running that into the API, absolutely no problems:
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+myrtle+beach+sc+29577&sensor=false
However, take this typoed version of the address:
2608 N Ocean Bv
Mrytle Beach, NC 29577
The city is spelled wrong, and it has the wrong state. Street number, name and zip code are correct. Mrytle Beach does not exist anywhere, and not in NC.
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+mrytle+beach+nc+29577&sensor=false
Google comes back with:
2608 N Ocean Bv
North Myrtle Beach, SC 29582
Now, that is a valid address. But why did Google decide that was the address I was looking for?
If you remove the incorrect state, and don't replace it with anything:
http://maps.googleapis.com/maps/api/geocode/json?address=2608+n+ocean+bv+mrytle+beach+29577&sensor=false
Google returns a corrected version of the correct address. So it seems that state trumps zip code - however, North Myrtle Beach does not exist in NC.
I'm thinking that omitting city and state eliminates most of this issue - but I'd like to understand why - if possible. Thanks.
Edit:
After some further playing around - it seems that Google looks for a city match as highest priority, then state - ignore all else. In this case:
Can't find a city called "Mrytle Beach" anywhere in the world.
Let's start in NC then and find the closest match to the street address if there is one.
Ah, here is the closest one to NC - in North Myrtle Beach.
If you change the state in my example above from NC to FL, the more southern Myrtle Beach match is closer to Florida than the more northern North Myrtle Beach address, and that is what Google returns.
I'm trying to understand the reasoning behind this. It seems that this sort of logic would be near last resort - or at least after making use of the zip code passed - which it appears it doesn't use at all.