目标
您通常需要验证某个地点的位置。Google Maps Platform 中有一些不同的服务可以帮助您实现此用例。本文档可帮助您在以下两种主要的位置验证服务之间进行选择：Address Validation API 和 Geocoding API。
Address Validation API 是 Google Maps Platform 中的一项产品，可帮助客户验证地址是否准确。
使用 Geocoding API 进行地理编码是将地址转换为地理坐标的过程，通过地理坐标可在地图上或某个位置上放置标记。
如需简要了解 Address Validation 和 Geocoding API 之间的区别，请点击此处。
何时选择地址验证与 Geocoding API
有关上述流程图的注意事项：
- 用户互动用例是指用户与结果互动的情况。
- 地点自动补全是一个 JavaScript API，因此适合与界面集成。
- 您可能已经注意到现有地址存在数据质量问题。因此，尽管您可能只需要地理编码，但最好通过 Address Validation API 运行这些位置，以更正数据集。
根据上面的决策树，在很多情况下，您可能会选择使用一种产品而不是另一种产品。但还有一些情况可能需要同时使用这两种产品来实现您的目标。
在以下情况下，您可以选择使用 Address Validation API 而非 Geocoding API：
- 很有可能出现有问题的数据，或者获得错误的地址会对下游产生负面影响。这是因为 Address Validation API 提供了有关输入无法获得高精确度结果的更多反馈。
- 您需要更正用户输入（例如拼写错误或缺少字段），这会提高生成准确结果的可能性。
- 与 Geocoding API 相比，您的目标区域从 Address Validation API 中返回更多的元数据，例如建筑物类型分类为住宅与商业。
在以下情况下，您可以选择使用地理编码而非 Address Validation API：
- 您的主要目标是检索地址的位置，各个地址的准确度可能并不重要。
- 例如，利用大量数据生成热图。
- 您需要全球解决方案，但 Address Validation API 并未在所有目标区域提供。
以下示例展示了与 Geocoding API 相比 Address Validation 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)）。这会逐渐提高某个地址可能存在的可信度，但并非百分百准确。这就是为什么我们需要 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 代码，那么 Address Validation API 会使用
regionCode字段生成更准确的结果。
存储地点 ID
若要存储 Google Maps Platform 中关于该位置的信息以供日后请求使用，您可以在数据库中无限期存储地点 ID 作为该位置的属性。您只需要为每个 placeID 发出一次查找地点请求。您也可以在每次用户请求交易详情时搜索地点 ID。
为确保您始终掌握最新的信息，请每 12 个月使用带有 place_id 参数的地点详情请求刷新地点 ID。
注意：另请务必查看地理编码的最佳做法指南。
总结
本文档介绍了 Address Validation API 和 Geocoding API 之间的核心区别。总的来说，在以下情况下，请考虑使用 Address Validation API：
- 必须提供准确的邮寄地址，尤其是为了便于配送。
- 已知输入数据质量不佳。Address Validation API 能够更宽松地处理输入错误，会突出显示无法验证的地址组成部分，并更正输入数据。
- 需要提供更多信息，例如住宅与商用地址（仅在部分地区提供）。
后续步骤
下载利用可靠地址改善结账、配送和运营 白皮书，并查看利用地址验证改进结账、配送和运营 在线讲座。
建议深入阅读：
贡献者
本文由 Google 维护。该博文最初由以下贡献者编写。
主要作者：
Henrik Valve | 解决方案工程师
Thomas Anglaret | 解决方案工程师
Sarthak Ganguly | 解决方案工程师