在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
构建网约车上车点半径检查
一家根据校园及周边社区协议运营的小型网约车服务，有一条不能违反的硬性规定：上车和下车地点必须位于划定的运营区域内，这一区域是与最初批准该服务的地方主管部门商定的。司机在边界之外放客，哪怕只超出很短的距离，也会让整个运营协议面临风险，而依靠司机在纸质地图上目测边界，永远不可能可靠。
该服务围绕坐标而不是地址构建这项检查，因为乘客的上车点标记本来就是在应用内地图上放下的一个坐标，而不是输入的文本。对于这个原始坐标，服务使用 /v1/reverse 换回可读的地址及其行政区域，这既可用于向乘客显示确认的上车地点，也便于工作人员事后审查任何被标记的行程，因为人很难快速核对一个单纯的坐标，而核对解析出的地址则很容易。
实际的边界检查本身是一项简单的几何比较，由应用自己的后端在乘客坐标与描述获批运营区域的多边形之间运行，一旦有了要检测的坐标，这项计算就不需要外部服务。位置端点的作用在于确保这项检测始终有真实的坐标可用：如果乘客在应用中输入的是地址而不是放置标记，就先通过 /v1/forward 把输入的内容转换为坐标。
位于边界内的上车请求照常进行。位于边界外的请求，哪怕只超出一点点，也会在派出司机之前就被拒绝，并附上一条消息，说明该服务依法不能在获批区域之外运营，而不是等司机到达后才发现自己不被允许接客。尽早拒绝既节省了司机的时间，也节省了乘客的时间，同时留下了清晰的记录，表明该服务在主动执行自己的边界，而不只是事后才发现违规。
对于被标记或有争议的行程，该服务也会使用逆地理编码得到的地址，因为少数上车点恰好落在边界边缘，需要有人确认请求实际上是在获批区域之内还是之外，而根据解析出的街道地址和社区名称来判断，远比根据内部控制台上一对原始坐标来判断容易得多。
一旦位置相关的部分到位，这类边界执行就不是复杂的技术问题。难点在于确保每个上车和下车地点，无论以何种方式输入应用，最终都能成为后端几何检查真正可用的坐标，而这取决于数据来自哪个方向，由 /v1/forward 和 /v1/reverse 协同完成。
请求量与乘车量直接挂钩，每次行程查询一到两次，对于在单个有限区域内运营的这种规模的服务，这样的工作量保持在每天的免费配额之内。两个端点的文档分别位于 /docs/forward-geocoding/ 和 /docs/reverse-geocoding/。