使用“Near”而不是“LL”的地点搜索 API 不准确答案

【问题标题】：Venue Search API Inaccurate Using "Near" Instead of "LL"使用“Near”而不是“LL”的地点搜索 API 不准确
【发布时间】：2014-05-20 05:53:49
【问题描述】：

当我通过 API 搜索场所时，我得到的结果与foursquare 网站不同。例如，我正在“加利福尼亚州旧金山”附近寻找一个名为“Nopalito”的场所。我的印象是这应该返回相关匹配：

我只收到一个名为“Invocation”的场所的结果。但是，当我通过foursquare.com 网站运行类似查询时，我得到了我所期望的结果：

网站搜索产生了位于加利福尼亚州旧金山的两个名为 Nopalito 的场所。

似乎是一个非常基本的查询，潜在结果数量有限。这是怎么回事？我在这里遗漏了什么明显的东西吗？

【问题讨论】：

好的，所以我像往常一样回答我自己的问题，而不是花几天时间把我的头撞在墙上。检查一下...从我的 URL 和 bada-bing 中删除 &intent=match。诺帕利托的两场比赛。但是，我将此作为一个悬而未决的问题，因为从文档中我相信我的原始查询仍然是正确的。我挑战你证明我错了四方。挑战。
挑战似乎已经完成？ :-)

【解决方案1】：

乍一看，我建议删除 intent=match，intent=match 会产生非常严格的查询。 intent=match（来自https://developer.foursquare.com/docs/venues/search）的目的是为了

“查找与给定查询和 ll 几乎完全匹配的场所。这在尝试将现有地点数据库与foursquare 相关联时很有帮助。它对提供的位置高度敏感。结果将被排序为最佳匹配首先，考虑距离和拼写错误/变化。”

对于这种类型的查询，我建议使用 intent=browse。

【讨论】：

抱歉，我认为您的回复并不能真正解决根本问题。尽管删除 intent=match 会有所帮助，但这并不是真正可以解释的。我也得到了比必要更多的结果。我提供的场地名称与他们在数据库中的名称完全匹配。我希望看到foursquare 纠正这一点，或者至少提供更好的文档说明为什么它不能直观地工作。不过还是谢谢。
所以intent=match的目的是匹配一个特定的场地，所以尝试用它进行城市搜索并不是一个好主意。如果您有一个特定的纬度/经度，场地接近，那么它会更有意义。正如 api 文档所说“它对提供的位置高度敏感”。
我同意纬度/经度可能是理想的，但不幸的是我的用例中没有它。我还有其他例子，其中名称/城市是 1:1 结果，但我明白你的意思。必须是设计决策。匹配只需要非常狭窄的标准。仍然希望这在文档中更清晰一点，但我会在澄清后给出这个答案。