My Geocode

指南

为落地页添加门店距离计算器

· 阅读约 3 分钟 · My Geocode · #forward-geocoding#distance#landing-page#retail

“你们离我最近的网点有多远”是落地页可以直接回答的问题，不必让访客跳转到另一个地图自己去查。

对访客输入进行地理编码

获取访客在简单表单字段中输入的任何地址或邮政编码，并对其进行地理编码。

GET /v1/forward?q=350 Fifth Avenue, New York&limit=1
{
  "status": "ok",
  "results": [
    {"formatted": "350 Fifth Avenue, New York, NY", "lat": 40.7484, "lon": -73.9857, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "es234", "components": {}}
  ]
}

计算到每家门店的距离

拿到访客的坐标后，使用标准的半正矢公式，计算该点到您每个门店位置的直线距离；门店位置以固定坐标列表的形式保存在您自己的代码中。

for store in stores:
    store.distance_km = haversine(store.lat, store.lon, 40.7484, -73.9857)

显示结果

按计算出的距离对门店列表排序，并显示最近的一家或最近的几家以及距离数值。由于这一切都在表单提交时于服务器端运行，因此不需要任何客户端脚本，页面只需在下一次加载时呈现结果。

第二个示例：显示最近的三家而不是一家

与其只报告最近的一家门店，不如对完整列表排序并显示前三家，这样访客就有了真正的选择；当最近的门店营业时间或库存与稍远一点、访客实际更偏好的门店不同时，这一点尤其有用。这不会产生任何额外成本，因为排序使用的是同一个请求返回的同一组坐标。

处理低置信度匹配

如果访客输入的地址返回的置信度分数较低，请先把格式化后的结果展示给访客确认，再进行距离计算，而不是根据对其意图的猜测自信地报出一个距离。

需要避免的常见错误

如果查询解析出的精度远比访客可能想要的粗略，例如仅有城市或地区名称并匹配到 “locality” 类型的结果，请不要在未先提醒访客的情况下就进行距离计算。从市中心而不是访客实际所在街道算出的距离，可能在任一方向上偏差数公里，足以改变哪家门店看起来最近。在报出一个听起来很确定的距离之前先检查精度字段，可以避免把粗略估算当作精确数值呈现。

让访客在有歧义的匹配中选择

当输入确实有歧义时（例如某个街道名称存在于多个城镇），在地理编码请求中将 limit 设为大于 1 的值，会返回多个候选匹配。展示这份简短的列表，让访客在距离计算之前选出正确的一项，比默默采用恰好排在第一位的候选结果要好。

成本是多少

每次计算都是一次地理编码请求，与您拿结果坐标对比多少家门店无关，因为一旦获得访客的坐标，门店列表本身不再需要任何额外的 API 调用。即使落地页流量可观，该功能也只是每次访客计算使用一次请求，完全在每个密钥附带的每天 2,500 次免费请求之内。

这样的距离计算器直接在页面上回答了一个具体而常见的问题，而不是把访客推到别处去查。完整的请求参数请参阅正向地理编码文档。

更多指南

· 阅读约 4 分钟

将地址与其邮政编码交叉核对

分别解析街道地址和邮政编码，并比较它们实际指向的位置，在订单发货前发现两者不匹配的情况。