在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
围绕仓库划定配送区域
一家区域性连锁杂货店开设了第二座仓库，在承诺当日达之前，需要先回答一个简单的问题：哪些客户可以在合理的车程内从新仓库送达，哪些客户仍然由原来的仓库服务更合适。
第一次尝试是手工画线，用圆规加上对道路距离的估计，结果得到的配送区域看起来合理，实际效果却很差。圆圈内的一些地址，沿唯一能到达的道路要开四十分钟。而圆圈外的另一些地址，实际上比地图显示的更近。
更好的方法从把地址转换为坐标开始。调用 /v1/forward 会接收一个地址并返回匹配结果，其中包含纬度和经度字段，这正是距离计算所需要的结构化位置，而不是一个需要路线工具去猜测的街道名称。仓库地址只需地理编码一次。客户列表中的每个订单地址在同一批次中完成地理编码，因为批量请求按每个地址计为一个计费项，而不是按调用次数收费。
两端都有了坐标之后，从仓库到每位客户的直线距离就成了杂货商自己的系统可以直接完成的简单计算。配送区域不再是手绘的圆圈，而是根据实际服务地点构建的边界，每当有新的客户地址进来就会自动更新。当配送时间开始延误、需要缩小仓库的有效范围时，边界可以用同一份数据重新划定，而不是凭肉眼重画。
反方向同样重要。客服有时只能从配送应用拿到一组坐标，没有规范的街道地址，却需要知道这个点属于哪个区域、哪家门店。/v1/reverse 接收一对坐标，返回该位置的地址组成部分，把地图上的一个图钉重新变成仓库路线表可以使用的信息。
这一切都不需要杂货商自建或购买授权一个地图平台。地理编码这一步是唯一缺失的环节，它直接接入了公司已在内部运行的物流软件。新仓库开业时重新地理编码了几千个地址，此后每天只有少量新订单需要地理编码，完全在这种规模的业务通常使用的每日免费配额之内；如果订单量增长，还有预付额度可以扩展。
这个经验不仅适用于杂货配送。任何围绕实体地点划定服务边界的企业，无论是仓库、维修站还是当日上门安装团队，都需要同样的两样东西：一种可靠地把地址转换为坐标的方法，以及在数据从另一个方向到来时，一种可靠地把坐标转换回地址的方法。两者都来自同一个密钥。
这两个端点的请求和响应格式分别记录在 /docs/forward-geocoding/ 和 /docs/reverse-geocoding/。