Fix for a valid nearby_search that was throwing an error unnecessarily. #16
Conversation
kingb
commented
Jun 27, 2013
kingb
commented
- name, lat_lng, radius, and rankby=ranking.DISTANCE.
- Test for error was:
- if keyword is None and types == []
- Should be:
- if keyword is None and types == [] and name is None
- Test for error was:
* name, lat_lng, radius, and rankby=ranking.DISTANCE. * Test for error was: * if keyword is None and types == [] * Should be: * if keyword is None and types == [] and name is None
* Modified Places object to deal with Radar Search not returning basic details like name and vicinity. * Added GooglePlaces.radar_search method. * FIXME: There a few additional parameters that could be included: * https://developers.google.com/places/documentation/search#RadarSearchRequests * FIXME: Making these results useful pretty much requires calling place_instance.get_details() which is very slow for all 40 results. * FIXME: Need to deal with: * A Radar Search request must include at least one of keyword, name, or types.
|
Sorry for the delay - I can't even begin to explain how busy I've been. I'll going to spend some time updating this from this weekend - I'll be sure to include your fix. Thanks! |
|
No worries at all! Take your time, I understand being busy. Can you double check Radar Feature before merging it? I'm not 100% sure it's needed after I did more work... I think more work might need to be done to make it work. It's been awhile since I worked on it. I think it turned out the results returned less attributes than other queries which may have led to errors being thrown when trying to use the returned data. I'd have to double check. Ah, right, I included the FIXMEs in the commit that described some of the issues. Anyway, let me know if you have an questions and I'll look into this some more if you do. -Brandon |
2 participants
