【问题标题】:Google places details API call return NOT_FOUND for an existing autocomplete referenceGoogle 将详细信息 API 调用返回 NOT_FOUND 用于现有的自动完成参考
【发布时间】:2013-06-20 01:26:57
【问题描述】:

我有一个问题,也许有人也有同样的问题。

我正在调用 google places 自动完成 api 调用。

然后我向用户展示结果,他可以选择地点。 根据选择,我正在调用地点详细信息并检索地点的详细信息。

我的问题是某些情况下详细信息服务返回 NOT_FOUND。完整的响应看起来像这样

    {\n   \"debug_info\" : [],\n   \"html_attributions\" : [],\n   \"status\" 
: \"NOT_FOUND\"\n}\n

根据 google api 文档,地点详情的 NOT_FOUND 是: NOT_FOUND 表示在 Places 数据库中找不到引用的位置。

但我在 1 秒前从自动完成服务调用中得到了这个参考!

有人有同样的问题吗?

谢谢, 诺姆

【问题讨论】:

    标签: google-maps google-places-api


    【解决方案1】:

    这里有两个索引,一个用于自动完成建议,一个用于地图详细信息。您会看到两个索引在不同时间更新的结果。如果您提供有问题的地址,我可以与相应的团队确认,或者您可以等待几天让索引恢复同步。

    【讨论】:

    • 感谢 Brett,我现在可以看到索引已更新。我不明白使用谷歌地方的最佳做法是什么。问题是我正在向用户展示一个自动完成响应列表。然后他单击一个,如果索引未更新,我会收到错误消息。有没有办法在地点详细信息中过滤掉他们的索引尚未更新的自动完成响应?
    • 没有一种廉价的方法可以过滤掉不在我们的 Places Details 索引中的条目。您最终会为下拉列表中的每个条目执行 Places Details 请求,这将耗尽您的配额。
    • 这个问题有什么进展吗?这个问题每隔几天就会在我的网站上发生一次;这很烦人。我该如何处理导致 NOT_FOUND 错误的“不同步”问题?
    • 奇怪的是,有时 my placeId (ChIJFStDCSZyhlQRVd9Ou2WCei8) 会返回详细信息,但有时会返回NOT_FOUND。这是因为细节调用击中了不同的服务器,其中一些尚未同步,而另一些则已同步?
    • 关于 Place API 要了解的是,它是一个搜索 API,由大型文档语料库提供支持。 Place ID 是在该文档语料库中搜索的关键字。有时语料库的某些部分会离线,例如当机架电源出现故障或服务器因查询而过载时。在这些时间点,您的查询将返回 NOT_FOUND,因为文档语料库未能在查询时间限制内返回对搜索词的命中。
    【解决方案2】:

    这也可能是由于业务已关闭。

    https://developers.google.com/maps/documentation/places/web-service/search-find-place#id-errors

    我在使用 Find Place 端点时遇到了类似的问题。我会得到一个成功的响应并返回一个 place_id,然后调用 Details 端点会返回一个 NOT_FOUND 错误。

    business_status 添加到我对 FindPlace 端点的初始请求的字段后,将返回:

    GET https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=gtdc.org&inputtype=textquery&languagecode=en&fields=place_id,business_status&key={{googlePlacesApiKey}}&locationbias=circle:{{radius}}@{{latitude}},{{longitude}}
    

    回复:

    {
        "candidates": [
            {
                "business_status": "CLOSED_PERMANENTLY",
                "place_id": "ChIJ7buuHhrhwogR_eWFgXkNyjY"
            }
        ],
        "status": "OK"
    }
    

    基本上,您只需忽略状态为 CLOSED_PERMANENTLY 的任何结果,因为这些在详细信息端点上不起作用。

    不幸的是,似乎没有任何方法可以在自动完成端点上返回 business_status,但可能与您看到的问题相同。

    【讨论】:

      猜你喜欢
      • 2017-05-08
      • 2018-01-08
      • 2017-03-17
      • 1970-01-01
      • 2016-10-27
      • 2019-08-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多