确定搜索请求是在 Google APIS 中使用的地址还是商家的智能方法?
问题是,我有一个带有搜索栏的应用程序,用户可以输入“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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
首先想到的是查找街道地址的正则表达式,但重要的问题是您的系统如何限定地址。
匹配格式相当一致的内容(例如完全限定的街道地址)是足够合理的,但是当它是“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.
事实证明,本地搜索默认执行此操作并处理地理编码和业务搜索。它有一些粗糙,但我想这是可以预料的
你可以通过指定来改变这种行为
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