Foursquare API: Getting an exhaustive list of venues in a given area -

i'm using foursquare api list of venues of category. 1 important requirement list exhaustive, i.e. includes relevant points. v2/venues/search api endpoint enforces limit of 50 venues on output. first idea comes mind splitting area several sections (using "sw" , "ne" params) , combining results.

clearly, density of points vary dramatically depending on location, we'll need use kind of adaptive algorithm flexibly adjust size of search window contains points. also, there's increased risk of running rate limit, might need algorithm stop when it's used quota of requests.

finally, seems way tell if search window should shrunk further count number of points in result: if have less 50, we've got complete list section , can move on next one; otherwise, should split further. seems wasteful we'll throwing away intermediate results (i.e. results in our search tree except leaves).

so here questions have:

• is best way put exhaustive list? maybe i'm missing api functionality?
• is there specific algorithm you'd use in case?
• how go reducing number of results have thrown away?

thanks in advance!

an important disclaimer foursquare not when perform lot of searches in same area.

having said that, should experimenting categoryid filter in venue search api. of data on foursquare food (restaurants) , nightlife related.

so if exclude these (by including others, no way exclude) can search on larger area , still below 50 results.

never tried using such algorithm because categoryid filtering worked enough, in theory, algorithm simple, each lat/lng 0.001 ~111 meters.

search using small radius (~200 large metropolitan areas) , triangulate (scan) areas.

what got perform lot of searches (and later stop doing so) foursquare filter out results without asking (for me, looks bugs, them part of algorithm). example search on 50 meter radius, find place want (i know searching for), expand 500 meters, not find (and less 50 results - not dropped out because hit cap, dropped out because ???), move search location ~300 meters north, find -> sporadic behavior.

my point (and reason why stopped making lot of searches , changed our approach), trying achieve, 'complete coverage' very hard given current api , current usage policy, , -> not important really. after few months of playing it, figured out should query foursqaure our users looking , require @ moment, cache results - on time have complete coverage, maybe @ start miss few spots, long run not important.