在地理编码之前规范化杂乱的地址输入

自由文本地址字段会收集到各种各样的格式习惯：多余的空白、不一致的大小写、写法不统一的缩写，以及偶尔从别处粘贴进来的杂散字符。这些不一定会让地理编码请求失败，但先把它们清理掉往往能提高匹配质量。

去掉首尾空白，把连续的空格合并为一个。删除控制字符和明显不属于地址的杂散标点。不要改动实际的地址内容，因为正向地理编码端点本就是为解析自由文本而设计的，不需要您自己把它拆分成单独的街道、城市和邮政编码字段。

GET /v1/forward?q=221b   baker st,  london&limit=1

对于像这样格式松散的输入，端点通常仍然能够解析，因为它是为处理真实世界的地址文本而不是僵硬的模板而构建的，但在数据确实杂乱的情况下，更干净的输入字符串可以降低出现歧义或低置信度匹配的几率。

使用常见缩写的查询，例如用“St”表示“Street”，用“Ave”表示“Avenue”，不需要在发送前展开。

GET /v1/forward?q=500 5th Ave, New York&limit=1

在发送请求之前自己展开每一个缩写是额外的工作，很少会改变结果，因为端点在解析普通地址文本时已经能处理标准缩写。请把清理精力放在真正有问题的输入上，例如粘贴进来的换行符或编码残留，而不是去改写从来就不是问题的缩写。

如果您已经知道某个地址应该在哪个国家，例如来自存档的账单地址或网站的地区定位，请通过 countries 参数传入，以减少与世界其他地方同名地点的歧义匹配。

GET /v1/forward?q=Springfield Main Street&countries=US&limit=3

过度清理地址、删除任何看起来不寻常的内容，可能会去掉地理编码器实际需要的信息。附在街道地址上的单元或公寓号、楼层标识或建筑名称是有意义的内容，而不是噪音，尽管它看起来与地址的其他部分不同。请把清理限制在空白、编码和明显的杂散字符上，凡是可能属于地址一部分的内容都不要动。

规范化可以减少错误匹配，但不能完全消除。请始终检查结果中的 confidence 字段，而不要仅仅因为请求成功就假定返回的结果自动正确。

在发送之前清理输入字符串，不会改变查询所消耗的请求数，仍然是每个地址一次请求。它改变的是您发出的这一次请求返回有用结果的几率，从而无需再发一次修正后的请求，而那样会多消耗一次请求。

一开始就把规范化做好，意味着更少浪费的查询和更干净的下游数据。完整的支持参数（包括 countries 和 limit）见正向地理编码文档。

更多指南