客观
您经常需要验证地点的位置。Google Maps Platform 中有几项不同的服务可帮助您满足此用例需求。本文档可帮助您在两种主要的位置验证服务之间进行选择：Address Validation API 和 Geocoding API。
Address Validation API 是 Google Maps Platform 提供的一项服务，可帮助客户验证地址是否准确。
使用 Geocoding API 进行地理编码是将地址转换为地理坐标的过程，可用于在地图上或地图上的位置放置标记。
点击此处，大致了解 Address Validation 和 Geocoding API 之间的区别。
何时选择 Address Validation 与 Geocoding API 的对比
有关上述流程图的注意事项：
- “用户互动”用例是指用户与搜索结果互动的情况。
- 地点自动补全是一个 JavaScript API，因此适合与界面集成。
- 您可能注意到现有地址存在数据质量问题。因此，如果您只需要地理编码，建议通过 Address Validation API 运行这些营业地点，以更正数据集。
在很多情况下，您可以根据上面的决策树，选择使用某种产品而不是另一种产品。但在某些情况下，您可能需要同时使用这两种产品才能实现您的目标。
在以下情况下，您可以选择使用 Address Validation API 而不是 Geocoding API：
- 很有可能存在可疑数据，或者如果收到错误的地址，会对下游产生负面影响。这是因为 Address Validation API 会针对输入为何未获得高精确率结果提供更多反馈。
- 您需要更正用户输入的内容（例如拼写错误或缺失的字段），从而提高输出准确结果的可能性。
- 与 Geocoding API 相比，您的目标地区通过 Address Validation API 返回更多元数据，例如将建筑物类型归类为住宅与商业。
在以下情况下，您可以选择使用 Geocoding API over Address Validation API：
- 您的主要目标是检索某个地址的位置，而各个地址的准确性可能并不重要。
- 例如，根据大量数据生成热图。
- 您需要一个全球性的解决方案，但 Address Validation API 并非在所有目标地区都可用。
以下是一些示例，分别展示了 Address Validation API 与 Geocoding API 的功能对比。
无效地址示例
1 Fake St, Mountain View, CA 94043, USA
Address Validation API 将此输入分解成各个地址组成部分（街道、城市、州/省等）。它还可以针对地址无效的原因提供精细的反馈，具体到 PREMISE 级别。
加利福尼亚州山景城不存在 Fake St，并且 Address Validation API 在返回的组件级详细信息中反映了这一点：
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
在本例中，要检查的重要属性是 confirmationLevel。通过针对 Fake St 返回 UNCONFIRMED_BUT_PLAUSIBLE，API 已确定某条街道可以采用该名称作为名称，但无法将其与辅助性地址数据匹配。
使用 API 结果作为反馈，可以推断出此输入的街道组成部分 (Fake St) 出错。
使用与 Geocoding API 相同的地址，它可以匹配“加利福尼亚州”（如地理编码工具的屏幕截图所示），您可以在此处试用：
然而，结果是整个状态的地理编码，并且对于输入上的哪些组件可能存在故障的反馈很少。
拼写错误示例
76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB
上述地址中出现了几处拼写错误，一个出现在街道名称中，另一个出现在市行政区中。
Address Validation API 和 Geocoding API 都可以更正这些错误，并实现 76 Buckingham Palace Road, London, SW1W 9TQ 的结果。不过，Address Validation API 可以提供有关该流程的更多信息。
我们来看一下输入时拼写错误的地址组成部分之一：
{
"componentName": {
"text": "Buckingham Palace Road",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "CONFIRMED",
"spellCorrected": true
}
}
Address Validation API 会返回一个标志，以表明已对该字段进行了更正。可以针对此标志实现业务逻辑，以再次向数据提供商（例如进行电子商务结账的客户）检查更正情况。
缺少数据和拼写错误示例
Bollschestraße 86, 12587, DE
上述地址中的街道名称有拼写错误，并且缺少柏林的城市（市行政区）。
Address Validation API 能够修正这两个错误，并返回 PREMISE 级别的地理编码，以及一个经过 PREMISE 级别的验证的地址：
Bölschestraße 86, 12587 Berlin, DE
在这种情况下，Geocoding API 无法成功克服输入错误，并返回 ZERO_RESULTS 的结果。
其他地址元数据示例
111 8th Avenue Ste 123, New York, NY 10011-5201, US
此地址是正确的，但建筑物内不存在单元号 (Ste 123) 除外。
Address Validation API 能够验证PREMISE（111 8th Ave）的地址，并提供关于该房源的一些元数据，包括其用于商业用途
前提：
"business": true
此外，作为响应中 uspsData 的一部分返回的 dpvConfirmation 值是 S：
"dpvConfirmation": "S"
如果 dpvConfirmation 的值为 S，则表示地址已通过 PREMISE 级别验证，但输入内容中提供的单位号与该地址无关。
Geocoding API 无法提供此信息。
了解 Geocoding API 响应
概览
如果您使用 Geocoding API，地理编码结果会在响应中包含各种线索，可用于了解所提供地址的详情。
Geocoding API 的工作原理是解析层次结构中的地址组成部分。
例如，**123 Example Street, Chicago, 60007, USA 按以下顺序解析：
“/ Example Street/ Chicago/ 60007/ USA ”将按照该顺序进行评估。在此例中，第一个匹配项为芝加哥，更具体地说是 60007 邮政编码。因此，它会返回该邮政编码的以下 Place_id：
ChIJwRKzf8ixD4gRHiXqucwr_HQ
Geocode API 在响应中包含以下信息：
"partial_match": true,
"place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
"types": [
"postal_code"
]
Geocoding API 可以确认该地址属于哪种类型。点击此处可查看 Geocoding API 所返回的地址 types 的列表。
如果输入的任何组成部分均未解析，则 API 会返回以下内容：
{
"results": [],
"status": "ZERO_RESULTS"
}
如果只请求街道地址但没有门牌号，则会传回以下形式的结果：
"types": [
"route"
]
这意味着 Geocoding API 无法找到或匹配门牌号。
注意：如需了解某个地址是否存在，请检查 Geocoding API 响应中是否设置了任何参数（例如 types、partial_match, results, status)）。这会逐渐提高地址可能存在的可信度，但并非 100% 准确。这就是我们需要 Address Validation API 的原因。
您可以运用上述技巧，仅通过 Geocoding API 响应来提高地址准确性的置信度。不过，与 Address Validation API 结果不同的是，Geocoding API 不会返回确切的反馈来确定结果的准确性。
位置类型
要正确理解此部分，您需要了解从 Geocoding API 响应中可能返回的不同位置类型：
- ROOFTOP，表示返回的结果是一个精确的地理编码，我们能够获得精确到街道地址的位置信息。
- RANGE_INTERPOLATED，用于表示返回的结果是一个近似值（通常为道路上的地址），该地址处于两个精确点（例如交叉路口）之间。当某个街道地址的 rooftop 地理编码不可用时，通常会返回内插值结果。
- GEOMETRIC_CENTER，用于表示返回的结果是多段线（例如街道）或多边形（区域）等结果的几何中心。
- APPROXIMATE，用于表示返回的结果不是以上任何一项。
如果 Geocoding API 返回的 location_type 为 ROOFTOP 或 RANGE_INTERPOLATED，并不一定表示该地址存在。同样，如果 Geocoding API 在返回时将 partial_match 标志设置为 true，这仍可能是适合您的结果。
利用 Geocoding API 解决此类错误匹配是一个非常困难的问题。您至少可以考虑对请求/响应的国家/地区和市行政区进行一些基本的后期处理验证。更棒的是，还可以比较实际街道地址是否存在拼写错误和/或地址不完整的情况。
注意：如果您决定使用 Geocoding API，建议您在发送初始请求到 Geocoding API 响应之间定期执行数据质量检查。
部分匹配和假匹配
如果某个地址是部分匹配，则意味着 Geocoding API 无法准确识别该地址，那么响应会包含：
"partial_match": true,
"types": [
"locality",
"political"
]
比上述地理位置类型更重要的是，考虑 partial_match = true 何时在响应中 。partial_match 表示 Geocoding API 不能返回与原始请求完全匹配的内容，但它可以匹配所请求的地址的一部分。
您可能需要检查原始请求中是否有不完整的地址。部分匹配最常见于请求中指定的市行政区内不存在的街道地址。当请求与同一行政区划中的两个或更多位置相匹配时，也可能会返回部分匹配。
例如，“21 Henr St, Bristol, UK”会返回 Henry Street 和 Henrietta Street 的部分匹配结果。请注意，如果请求中包含拼写错误的地址组成部分，Geocoding API 可能会建议备选地址。以这种方式触发的建议不会标记为部分匹配。
合成地址
如果“合成”地址在 Google 数据库中不再是精确位置，Geocoding API 可能会返回这些地址。
在此类情况下，响应对象通常包含长的地点 ID 和以下属性：geometry.location_type=APPROXIMATE。
如果您在响应中遇到上述标识，请考虑将输入的地址标记为无效，并尝试通过其他方式重新验证该地址。
注意：这是另一个示例，借助 Address Validation API，如果地址不存在，您会收到直接反馈。
了解 Address Validation API 响应
关于如何理解 Address Validation API 的响应，您已经有非常详尽的文档了，所以我们在这里不作进一步的讨论。
最佳实践
指定地理位置
在调用 Address Validation API 或 Geocoding API 时，最佳实践是尽量限制在哪些地理位置搜索相应地址。这两个 API 可通过以下两种不同的方式实现此功能：
Geocoding API - 地区偏向
如果您知道地理编码将位于某个国家/地区内，那么通过使用区域自定义调整，您可以获得更好的结果。例如，如果您在加拿大进行地理编码，我们建议在请求中添加
®ion=ca，以偏向加拿大。请注意，区域自定义调整只是优先显示该区域内的结果。在该地区以外，您仍然可以获得搜索结果。Address Validation API - 地区代码
类似地，如果在请求中传递 ISO2 代码（使用
regionCode字段），Address Validation API 会生成更准确的结果。
存储地点 ID
如需存储来自 Google Maps Platform 的关于该营业地点的信息，以用于将来的请求，您可以在数据库中无限期存储地点 ID 作为该营业地点的属性。您应该只需为每个地点 ID 发出一次查找地点请求。您也可以在每次用户请求交易详情时搜索地点 ID。
为确保您始终拥有最新的信息，请使用带有 place_id 参数的地点详情请求，每 12 个月刷新一次地点 ID。
注意：还请务必查看与地理编码有关的最佳实践指南。
总结
本文档介绍了 Address Validation API 和 Geocoding API 之间的核心区别。总而言之，在以下情况下，请考虑使用 Address Validation API：
- 必须提供准确的邮寄地址，尤其是出于配送目的时。
- 已知输入数据质量不佳。Address Validation API 可以更容忍输入错误，突出显示无法验证的地址组成部分，并更正输入数据。
- 需要提供更多信息来提供一个地址，例如住宅或商用（适用于部分地区）。
后续步骤
下载使用可靠的地址改进结账、配送和运营 白皮书，并观看利用地址验证功能改进结账、配送和运营 在线讲座。
建议深入阅读：
贡献者
本文由 Google 维护。它最初是由以下贡献者编写的。
主要作者：
Henrik Valve | 解决方案工程师
Thomas Anglaret | 解决方案工程师
Sarthak Ganguly | 解决方案工程师