【发布时间】:2014-03-27 18:46:10
【问题描述】:
自 2009 年以来,我们一直使用 Google 的 Store Locator Example 代码为一个简单、扁平的本地志愿组织数据库提供地理搜索组件,所有这些组织都为一个地理区域提供大致相同类型的服务在一个国家,但不是来自一个可映射的存在点。
搜索量非常低,结果是网页上的纯文本行。它有效。
那么问题出在哪里?
当您的系统由无偿志愿者运行时,您并不总是有时间让代码保持最新。运行 LAMP 服务器甚至共享主机似乎只是为了提供单个页面来搜索“最近的 5”。
Google Places Javascript API 助您一臂之力!
听起来非常适合 JavaScript library component 之类的 Google Places API [FAQ]。
Places Search API 甚至带有一个方便的nearby 方法,使用半径或有界区域。这将是一个完美的 Google Web 应用程序,或者可能是我们的 Google Apps for Non Profits 服务上的一个页面。无需租用服务器,无需更新软件。
作为奖励,不要弄乱任何 CRUD - 我可以设置一个简单的 Google 电子表格作为数据源,任何可以编辑电子表格的人都可以更新后端详细信息。请记住,我们只讨论 5 列表上 300 个左右条目中的最多 5 个结果。我有选择地将数据从 50 倍大的工作表中提取到 Tabletop 中,并使用 Handlebars 毫无问题地呈现数据。只是不必进行地理半径搜索。
但有一个问题。
要使用极其简洁紧凑的 Places API 方法,数据必须实际上已经存在于 Google 地图上,并且适合 types 的范围之一。将我们的 300 项左右的服务列表作为企业或服务添加到 Google 地图是不正确的,因为地图是针对特定的基于位置的服务,而不是特定区域的外展志愿者的集合。如果我们能找到一种方法,将地点 API 附近半径搜索的便利性与自定义数据源(如 Maps API 示例)结合起来,所有问题都将迎刃而解。除了,我知道没有这样的方法。所以...
问题:
我希望允许从 50 英里半径范围内的自定义平面表中搜索最多 5 个结果,而不需要 Google 在其 2009 年 pre-Places 解决方案中建议的 LAMP 堆栈解决方案。
我是否在上面的正确路线上,但遗漏了一些明显的东西,甚至不那么明显?
还是我在这里找错树了?
感谢您在正确方向上的指导或推动。谢谢。
【问题讨论】:
标签: google-maps google-maps-api-3 google-places-api