My Geocode

指南

对包含公寓号或单元号的地址进行地理编码

· 阅读约 4 分钟 · My Geocode · #forward-geocoding#apartments#address-parsing

在街道地址后加上公寓号，是许多真实地址的正常组成部分。与其在发送请求前把它删掉（这是一种常见但不必要的习惯），不如了解地理编码查询是如何处理它的。

发送完整地址

将公寓号或单元号作为自由文本查询的一部分包含在内，与地址的其他任何部分一样。

GET /v1/forward?q=Apt 4B, 350 Fifth Avenue, New York&limit=1
{
  "status": "ok",
  "query": "Apt 4B, 350 Fifth Avenue, New York",
  "results": [
    {
      "formatted": "350 Fifth Avenue, New York, NY",
      "lat": 40.7484,
      "lon": -73.9857,
      "type": "address",
      "precision": "house",
      "confidence": 0.95,
      "place_id": "es234",
      "components": {"house_number": "350", "street": "Fifth Avenue", "city": "New York", "region": "NY", "country": "US"}
    }
  ]
}

为什么单元号不会体现在坐标中

地理编码查询返回的坐标标识的是一栋建筑物，而不是其中的某个具体单元，因为单独的公寓不像建筑物那样拥有各自独立的地图位置。地址中的公寓或单元部分本来就不会改变 lat 和 lon 的值，它不出现在 components 对象中也是预期之内的，并不表示输入被忽略或处理不当。

第二个示例：商业建筑中的套房号

对于带有套房号或楼层号的商业地址，同样的规律也适用。

GET /v1/forward?q=Suite 200, 1 Example Plaza, Chicago&limit=1

一栋容纳数十家不同企业的大型办公楼，无论查询中指明的是哪个套房，地理编码结果仍然是同一组建筑物坐标，与公寓楼的情况完全相同。任何用于在该建筑内区分不同租户的信息，都需要保存在您自己的记录中，而不是坐标里。

需要避免的常见错误

不要为了弥补缺失的单元组成部分，事后自己把它附加到邮政编码或其他组成部分字段上，例如把邮政编码写成“20500 Apt 4B”。这样做会破坏一个其他系统（包括您自己的验证逻辑和任何下游地址查询）都认为只应包含真实邮政编码的字段。请将单元号保存在独立的字段中，与所有地理编码组成部分完全分开。

单独存储单元号

与其每次都把单元号并入要进行地理编码的地址字符串中，不如在您自己的数据模型中将其作为独立字段，与经过地理编码的建筑物地址一起存储。这样地理编码请求就能专注于真正影响结果的内容，也就是建筑物的位置，同时仍然为快递标签或内部记录保留单元信息。

对投递至关重要的时候

快递员或邮政服务在实际投递时需要单元号，尽管它对坐标没有任何作用。请在最终的投递记录中同时保留这两部分信息，即经过地理编码的建筑物坐标和单独存储的单元号，这样在整个过程中就不会丢失任何信息。

一个值得了解的边界情况

一个建筑物地址可能容纳大量不同的住户或租户，他们共享相同的坐标和相同的邮政编码查询结果。如果您正按照邮政编码交叉核对指南中介绍的方法，将客户的邮政编码与正向地理编码得到的地址进行交叉核对，请记住，单元与建筑物之间的这种多对一关系是预期之内的，其本身并不表示数据有问题。

费用不受影响

无论地址是否包含公寓号或单元号，查询仍然只消耗一个请求，与其他任何正向地理编码调用相同。

在查询中包含单元号不会有任何坏处，要实现准确的地理编码也不必将其删除，不过事后将其拆分到单独存储的字段中，能让您的数据更整洁。完整的组成部分列表请参阅正向地理编码文档。

更多指南

· 阅读约 4 分钟

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

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