Google geocoding API - search in just one country - google-geocoder

I am looking for geocodes with the google geocode-API:
http://maps.googleapis.com/maps/api/geocode/json?address=london%c2+UK&sensor=false
The problem is, that the input isn't very accurate (specially the street) and sometimes google mixes things up and ignores UK, because the street has a perfect match (as street and city) somewhere else. e.g. US.
Now i cannot solve this issue (input data), but I am wondering if there is a parameter, which forces google to search in UK and return no result instead of a completly wrong result.

You can add component filters in the url to constraint results. In this case you can use:
http://maps.googleapis.com/maps/api/geocode/json?address=london%c2+UK**&components=country:UK**&sensor=false
For more information about how to use component filtering see:
https://developers.google.com/maps/documentation/geocoding/intro#ComponentFiltering

Related

Optimize Google Places API Query for Prominent Parks, Mountains, Conservation Areas

First post on Stackoverflow.
I am using the Google API to sort images taken while traveling into organized folders, append tags and rename files with relevant information. I have my code working well but am not always happy with the results. I want to be able to focus my query results on major tourist attractions such as National Parks, Ski Resorts, Beaches, etc. The problem I am finding is that the prominence "rankby" variable and the "radius" are not giving satisfactory results. Here is a typical query for Zion National Park.
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=37.269486111111,-112.948141666667&rankby=prominence&radius=50000&type=natural_feature,tourist_attraction,point_of_interest&keyword=&key=MYAPIKEY
The most prominent result is Springdale which is the town where you enter the part. Zion National Park is listed much further down in the results. What my code does is use the LAT and LON extracted using EXIF and does a Google API nearby search request to find the Place ID for where the photo was taken. It then does another API request for Place Details using the place_id provided by the previous step to cut down on the information I need to parse.
https://maps.googleapis.com/maps/api/place/details/json?place_id=ChIJ8R5RCzaNyoARegi3rqVkstk&fields=name,address_component&key=MYAPIKEY
I can force the nearby search to return a National Park by searching against "National Park" in the keywords variable but that limits my project to only being able to provide National Park results since the keywords field can only accept one string.
I would like a park of my query to be able to return the most prominent tourist attraction at the general level, i.e. Zion National Park, Yosemite National Park, etc. so I can sort images into the general name folders and another part of the query provides the exact location. i.e. I am on this trail or at this lookout. The problem is the Google API sees these specific locations "Trail, Lookout" as tourist attractions, parks, establishments, etc. as well so it chooses those first.
What I need help with is trying to figure out if there is a better way to structure my query to return the high-level / name of the major park. From my understanding, the types field only searches on the first type even if there is more in the list and the keywords field can only accept one string as well making it impossible for one phase to capture all major destinations at a high level.
Perhaps it needs to be done with more queries but I am trying to limit the number of queries to stay inside the free quota. Maybe it will just take a long time to fully sort my files.
Read through and implemented Google API structure. I hoping someone can provide a more detailed query structure or method to parse out truly prominent locations rather than googles interpretation of prominence as it can be affected by user ratings, etc. It is not always accurate.

GoogleMaps Autocomplete (Places API)

I am trying to fetch airports using the Places API autocomplete feature.
Looking at the types parameter, if this is an airport I display the result or else show it as no airports found.
I want to enhance this app, I want to show terminals within each Airport object that I display on the front end.
I have found the nearby search within places API but it is difficult to create a search query using keyword, and type to get exact results for all the airports around the world.
Does anyone have any idea as to what would be the best way to get airports and their terminals using the Places API?
Well I'm not sure if this is really your expected result but here's what I tried:
Get the placeId of an airport using Place Autocomplete.
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=dublin&radius=500&types=airport&key=API_KEY
Then use that placeId to do a Place Details request and get the coordinates of the airport.
https://maps.googleapis.com/maps/api/place/details/json?place_id=ChIJLxmTab4RZ0gRVfMlt7UbElU&key=API_KEY
This also returns an overview of the airport wherein in this case the result says: "
"Airport with 2 runways, a 2nd terminal opened in 2010 plus buses into Dublin & other towns/cities."
Then after having the coordinates, I use that to do a Nearby Search request.
https://maps.googleapis.com/maps/api/place/nearbysearch/json?keyword=terminal&location=53.42644809999999,-6.249909799999999&radius=10000&key=API_KEY
This managed to get the terminals around it, I just threw in some radius but I guess it should be different on other locations. I also tried this with other Airports and it somehow worked.
If this won't work for your use case. Another thing I think you could do is to store the coordinates of known airports (Please note that coordinates/placeID are the only thing that is allowed for us to store/cache. Please see Specific Terms). And create an object which also stores the coordinate of their corresponding terminals. This would be an extensive work if you want to do this with airports all around the world.
Hope this helps.

search Patient on EPIC FHIR

I'm trying to figure out how the patient searching on EPIC FHIR is working.
Testing all on the sandbox here: https://fhir.epic.com/Documentation?docId=testpatients.
The docs:
Starting in May 2019, Patient.Search requests require one of the following minimum data sets by > default in order to match and return a patient record:
FHIR ID
{IDType}|{ID}
SSN identifier
Given name, family name, and birthdate
Given name, family name, legal sex, and phone number/email
This is working correctly (returning one patient):
/api/FHIR/R4/Patient?family=Lin&given=Derrick&birthdate=1973-06-03
But this is also returning same record (extra character in family, wrong gender)
:
/api/FHIR/R4/Patient?family=Lina&given=Derrick&birthdate=1973-06-03&gender=female
Also this one is returning one record (extra character in family, no given name):
/api/FHIR/R4/Patient?family=Lina&birthdate=1973-06-03
Not sure what I am doing wrong, or is it expected behaviour?
There is a bunch of history here, but Epic's current Patient.search behaves more like Patient.$match. Specifically, the criteria provided to Patient.search are combined using (approximately) OR logic rather than AND logic. Behind the scenes, it is actually more of weighted score, but ultimately, the more criteria you provide, the more possible results you might get. This is often counterintuitive if you are used to how REST API query params normally work. Technically it is spec legal though, since FHIR has a blurb in there about servers being able to return other appropriate results as it sees fit.
https://build.fhir.org/search.html#Introduction
However, the server has the prerogative to return additional search results if it believes them to be relevant.
We don't have any specific updates right now, but there may be changes coming in Soon(tm).
I'm surprised the last one is returning any results, but regarding the first two searches, this is quite possible or even expected with Epic. Epic has special logic in the background that evaluates the parameter values you pass in against certain criteria, such as whether the name matches exactly, the name is similar, the birthdate matches exactly, etc. As a result, oftentimes not only exact matches but also similar matches will be returned by the Patient.Search API. The weighting of the criteria is customizable by Epic customer, so some may have stricter logic than others.
I'd recommend always validating the returned result against your input parameters to verify you are working with an exact match.

Has anything changed on geocode API

I just wanted to know if anything changed on geocode API from 21 st February because before 21st it was validating zip code 9 digits but from yesterday it is giving an error on 9 digits zip code and now it only validating 5 digits zip code.
More information in your question would be helpful.
I haven't noticed any change, but I thought I'd take a look at the GeoCoder Documentation FAQ for you.
Yes, based on that date, I'd say something changed recently.
Perhaps this is what you're referring to, but that's only a speculation since you didn't provide any detail or examples.
Troubleshooting
I’m getting more queries that return ZERO_RESULTS with the new geocoder. What’s going on?
In the new geocoder, ambiguous, incomplete and badly formatted queries, such as misspelled or nonexistent addresses, are prone to produce ZERO_RESULTS. These queries would typically produce incorrect results in the old geocoder, such as returning the suburb if the address could not be found. We believe that returning ZERO_RESULTS is actually a more correct response in such situations.
If your application deals with user input of addresses, the Place Autocomplete feature in the Places API may produce better quality results. Place Autocomplete allows users to select from a set of results based on what they’ve typed, which allows users to choose between similarly named results, and to adjust their query if they misspell an address.
If you have an application dealing with ambiguous or incomplete queries or queries that may contain errors, we recommend you use the Place Autocomplete feature in the Places API rather than the forward geocoder available in the Geocoding API. For more details, see Best Practices When Geocoding Addresses and the Address Geocoding in the Google Maps APIs blog post.
More Information:
Documentation FAQ
Related Issue Tracker

Exact address of a place given its latitude and longitude

I'm developing a web app wherein I need to get the "exact" address given a latitude and longitude pair. I tried Maps Geocode API as well but it doesn't give the exact address. I think Places API would be a good option alas I don't get how to use it.
I'm using golang.
IMO, if you think that reverse geocoding results a bad, Places API results wouldn't make you happier.
Here is the sample of Places API
https://maps.googleapis.com/maps/api/place/search/xml?location=55.753720,37.620144&key=google_map_api_key
And Geocoder to compare
https://maps.googleapis.com/maps/api/geocode/xml?latlng=55.753720,37.620144
As you can see, there is no address in Places API results. The first addresses you may get only after addition radius parameter:
https://maps.googleapis.com/maps/api/place/search/xml?location=55.753720,37.620144&radius=100&key=google_map_api_key
For me, trying to decide which address within 100 meters is right is more complex task than simple use of the best possible result from geocoding.

Resources