确定搜索请求是在 Google APIS 中使用的地址还是商家的智能方法?

发布于 2024-08-17 02:21:46 字数 214 浏览 11 评论 0原文

问题是,我有一个带有搜索栏的应用程序,用户可以输入“18 街”或“星巴克”之类的内容,它分别使用 Google 地理编码和本地搜索 API 来获取结果。

我想知道是否有一种聪明的方法来确定给定的输入字符串是否是需要进行地理编码的地址,或者是需要使用本地搜索的公司名称。

显然我可以尝试手动一些东西,但我想知道是否有人已经这样做了或者谷歌自己提供了这样的功能。

干杯。

Here is the problem, I have an app with a search bar, the user can input something like "18th Street" or "Starbucks" and it uses the Google Geocoding and Local Search APIs respectively to get results.

I'm wondering is there a smart way to determine whether or not a given input string is an address that needs to be Geocoded, or a business name that needs to use Local Search.

Obviously I could try and handroll something, but I'm wondering if someone has already done this or Google provides such functionality themselves.

Cheers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

提笔落墨 2024-08-24 02:21:46

首先想到的是查找街道地址的正则表达式,但重要的问题是您的系统如何限定地址。

匹配格式相当一致的内容(例如完全限定的街道地址)是足够合理的,但是当它是“18th Street”之类的内容时,您怎么知道他们实际上并不想要一家名为“18th Street”的餐厅?您可能会考虑使用正则表达式,它松散地尝试匹配街道地址,如果找到,则调用地理编码。如果地理编码未返回结果,则默认为本地搜索。

The first thing that comes to mind would be a regular expression that looks for a street address, but the important question is how your system would qualify an address.

It's reasonable enough to match something that is going to be fairly consistent in format like a fully qualified street address, but when it's something like "18th Street" how do you know they don't actually want a restaurant called "18th Street"? What you might consider is a regular expression that loosely attempts to match a street address and, if it finds one, call the Geocoding. In the event no results are returned by Geocoding, then default to a Local Search.

别在捏我脸啦 2024-08-24 02:21:46

事实证明,本地搜索默认执行此操作并处理地理编码和业务搜索。它有一些粗糙,但我想这是可以预料的

你可以通过指定来改变这种行为

地铁?这个可选参数
指定列表的类型
用户感兴趣。有效值
包括:

* 混合 - 请求 KML、本地企业列表和地理编码结果
* kmlonly - 请求 KML 和地理编码结果
* localonly - 请求本地企业列表和地理编码结果

It turns out Local Search by default does this and processes Geocodes and business searches. There is some coarseness to it, but I guess that is to be expected

You can change this behaviour by specifying

mrt? This optional argument
specifies which type of listing the
user is interested in. Valid values
include:

* blended - request KML, Local Business Listings, and Geocode results
* kmlonly - request KML and Geocode results
* localonly - request Local Business Listings and Geocode results
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文