我正在使用 Foursquare API 来获取某个类别的场地列表。一个重要的要求是清单是详尽的，即包括所有相关点。v2/venues/search API 端点对输出实施了 50 个场所的限制。所以想到的第一个想法是将区域分成几个部分（使用“sw”和“ne”参数），然后组合结果。
显然，点的密度会因位置而发生巨大变化，因此我们需要使用某种自适应算法来灵活调整搜索窗口的大小，使其包含所有点。此外，遇到速率限制的风险也会增加，因此我们可能需要算法在其请求配额用完时停止。
最后，似乎判断搜索窗口是否应该进一步缩小的唯一方法是计算结果中的点数：如果我们有少于 50 个的点，那么我们就有了这部分的完整列表，并且可以继续下一个；否则，我们应该进一步拆分它。这似乎很浪费，因为我们将丢弃中间结果（即我们的搜索树中除了叶子之外的所有结果）。
所以这里有一些问题：
提前致谢！
一个重要的免责声明是，当您在同一区域执行大量搜索时，foursquare 不喜欢它。
话虽如此，您应该考虑在场地搜索 api 中尝试使用 categoryId 过滤器。foursquare 上的大部分数据都与食物（餐馆）和夜生活相关。
因此，如果您排除这些（通过包括其他人，无法排除），您可以在更大的区域进行搜索，但仍会得到 50 个以下的结果。
从来没有真正尝试过使用这样的算法，因为 categoryId 过滤效果很好，但理论上，算法很简单，每个 lat/lng 0.001 约为 111 米。
使用小半径（大都市地区约为 200）和三角（扫描）区域进行搜索。
让我们最初执行大量搜索（后来停止这样做）的原因是有时foursquare会在不询问您的情况下过滤掉结果（对我来说，它看起来像错误，对他们来说是算法的一部分）。因此，例如，我会在 50 米半径范围内搜索，找到我想要的地方（我知道我在搜索什么），扩展到 500 米，但没有找到它（得到的结果少于 50 个 - 所以它没有被丢弃，因为我击中了上限，它被退出了，因为???），将我的搜索位置向北移动约 300 米，找到它 -> 零星行为。
我的观点是（以及我们停止进行大量搜索并改变方法的原因），鉴于当前的 API 和当前的使用政策，您想要实现的目标是“完全覆盖”非常困难，并且 - > 这真的不重要。在玩了几个月之后，我们发现我们应该查询foursqaure 以了解我们的用户正在寻找和需要什么，我们缓存结果 - 随着时间的推移，我们将获得完整的覆盖，也许一开始我们会错过几个点，但从长远来看，它并不重要。
希望这不是您正在做的事情，但作为一个友好的提醒：抓取foursquare 的网站和/或API 是其服务条款非常禁止的。