My Geocode

指南

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

· 阅读约 4 分钟 · My Geocode · #邮政编码#正向地理编码#验证#配送

客户可能输入了一个真实的街道地址和一个真实的邮政编码，但两者实际上并不匹配，最常见的原因是数字颠倒，或者把旧的邮政编码抄到了新地址上。单看任何一个字段都发现不了问题，因为两者各自都是有效的。

分别解析每个字段

用 /v1/forward 对完整地址进行地理编码，查看它实际解析到的邮政编码；再用 /v1/postcode 单独查询客户输入的邮政编码，查看它覆盖的区域。

GET /v1/forward?q=10 Downing Street, London&limit=1
{
  "status": "ok",
  "results": [
    {"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {"postcode": "SW1A 2AA", "city": "London"}}
  ]
}
GET /v1/postcode?code=SW1A 1AA&country=GB
{
  "status": "ok",
  "postcode": "SW1A 1AA",
  "country_code": "GB",
  "results": [{"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London"}}]
}

比较两个结果

如果地址查询结果中的邮政编码部分与客户输入的邮政编码不一致，就像本例这样，那么即使地址和邮政编码各自都被核实为真实存在，这也是一个值得标记的不匹配。直接比较这两个组成部分，比比较两组坐标之间的距离更可靠，因为邮政编码区域可能小到即使真正匹配，其坐标也不会恰好落在地址的坐标上。

第二个示例：值得更早发现的更大不匹配

同样的检查也能发现一种明显得多的错误：输入的邮政编码属于与街道地址完全不同的国家或地区，例如英国格式的编码搭配了一个实际解析到另一个国家的地址。在进行更详细的邮政编码比较之前，先把地址结果中的国家部分与邮政编码查询所用的 country 参数进行比较，是一个低成本的初步检查，可以尽早过滤掉这类较大的错误。

发现不匹配后怎么办

把两个值并排展示给客户，请其确认哪一个是正确的，而不是悄悄地选择其中一个，或者直接拒绝订单。数字颠倒一经指出就很容易改正，而邮政编码确实横跨两个常用值之间边界的真实边缘情况非常少见，通过快速的人工确认就能处理。

需要避免的常见错误

不要用距离阈值直接比较两组坐标来代替比较邮政编码组成部分本身。邮政编码区域在地理上可能小到即使完全正确的匹配，其代表点与地址所在建筑的具体坐标之间也会有一定距离；而一个编码区域在地理上也可能大到一对真正不匹配的值仍然落在宽松的距离阈值之内。直接比较邮政编码文本，比试图从距离推断是否匹配更直接、更可靠。

值得考虑的边缘情况

恰好位于两个行政区域边界上的邮政编码区域，可能会因为由哪个端点解析而合理地返回看起来略有不同的组成部分，即使两者都是正确的。对于接近但不完全一致的文本匹配，例如仅仅是地区名称的写法不同，处理时应比对待完全不同的邮政编码更宽松。

一次核对大量订单

如果要处理的是一批已有订单而不是单个新提交，两个端点都接受批量 POST 数组，因此可以把地址作为一个批量请求发送到 /v1/forward，把邮政编码作为另一个批量请求发送到 /v1/postcode，然后按位置比较两个结果数组，从而核对积压的订单。

请求成本

这项检查每个订单使用两个请求，一个用于地址，一个用于邮政编码，两者都与其他任何查询一样计入您的每日额度。为了发现原本会以配送失败的形式暴露出来的错误，这个成本是合理的。

在订单发货前发现不匹配的邮政编码，值得为此多花一个请求进行核对。两个端点的详细说明请参阅正向地理编码文档和邮政编码查询文档。

更多指南