目标
您经常需要验证某个地点的地理位置。Google Maps Platform 中有几项不同的服务可以帮助您实现此用例。 本文档可帮助您在两个主要地理位置验证服务（Address Validation API 和 Geocoding API）之间做出选择。
Address Validation API 是 Google Maps Platform 提供的一项服务，可帮助客户验证地址是否准确。
地理编码 是指使用 Geocoding API 将地址转换为地理坐标的过程，您可以使用这些坐标在地图上放置标记或在地图上定位。
如需大致了解 Address Validation API 和 Geocoding API 之间的区别，请点击此处。
何时选择 Address Validation API 而非 Geocoding API
关于上述流程图的说明：
- 用户互动用例是指用户在场并与结果互动的情况。
- Places Autocomplete 是一个 JavaScript API，因此适合与用户界面集成。
- 您可能知道现有地址存在数据质量问题。因此，即使您可能只需要地理编码，也建议您通过 Address Validation API 运行这些地理位置，以更正数据集。
根据上述决策树，在许多情况下，您可能会选择使用一种产品而不是另一种产品。但在其他情况下，您可能需要同时使用这两种产品才能实现目标。
在以下情况下，您可能会选择使用 Address Validation API 而非 Geocoding API：
- 数据存在问题的可能性很高，或者获取不正确的地址会对下游产生负面影响。这是因为 Address Validation API 会提供更多反馈，说明输入为何未获得高精度结果。
- 您需要更正用户输入（例如拼写错误或缺少字段），这会提高输出结果的准确性。
- 与 Geocoding API 相比，您的目标区域从 Address Validation API 返回的元数据更多，例如将建筑类型分类为住宅与商业。
在以下情况下，您可能会选择使用 Geocoding API 而非 Address Validation API：
- 您的主要目标是检索地址的地理位置，而各个地址的准确性可能并不重要。
- 例如，您可能想从大型数据集中生成热图。
- 您需要超本地目的地详细信息，例如建筑物入口、建筑物轮廓或接送导航点（可通过 Geocoding API v4 中的 SearchDestinations 方法获取）。
- 您需要一个全球解决方案，但 Address Validation API 并非在所有目标区域都可用。
以下是一些示例，展示了 Address Validation API 相较于 Geocoding API 的功能。
无效地址示例
1 Fake St, Mountain View, CA 94043, USA
Address Validation API 会将此输入分解为各个地址组成部分（街道、城市、州等）。它还可以提供精细的反馈，说明地址为何无效，精确到 PREMISE 级别。
Fake St 在 Mountain View, CA 中不存在，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 处理同一地址时，它能够匹配“California”，如地理编码工具的屏幕截图中所示，您可以在此处试用该工具：
不过，结果是整个州的地理编码，并且关于输入中哪些组成部分可能存在问题的反馈很少。
拼写错误示例
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 表示地理编码器无法返回与原始请求完全匹配的结果，尽管它能够匹配所请求地址的一部分内容。
您可能需要检查原始请求中是否存在地址不完整的情况。部分匹配的最常见原因是请求中所传递的市行政区内不存在相关街道地址。当请求与同一行政区划中的两个或更多位置相匹配时，也可能会返回部分匹配。
例如，无论是 Henry Street 还是 Henrietta Street，“21 Henr St, Bristol, UK”都会返回部分匹配。请注意，如果请求中包含拼写错误的地址组成部分，Geocoding API 可能会推荐备选地址。通过这种方式触发的建议不会标记为部分匹配。
合成地址
Geocoding API 可能会为“合成”地址返回地理位置，这些地址在 Google 的数据库中不存在精确的地理位置。
在这种情况下，响应对象通常包含一个较长的地点 ID，以及以下属性：geometry.location_type=APPROXIMATE。
如果您在响应中遇到这些指标，请考虑将输入地址标记为无效，并尝试通过其他方式重新验证。
注意：这是另一个示例，说明了使用 Address Validation API 时，如果地址不存在，您会获得直接反馈。
了解 Address Validation API 响应
关于如何理解 Address Validation API 的响应，已有非常出色的文档，因此我们在此不再赘述。
- 如需了解响应对象的概览，请点击此处。
- 如需观看演示不同响应组成部分的演示，请点击此处
- 在 Address Validation for checkout 文档 中，详细介绍了如何区分有效地址和无效地址。
最佳实践
指定地理位置
在调用 Address Validation API 或 Geocoding API 时，最佳实践是尝试限制搜索该地址的地理位置。这两个 API 以两种不同的方式实现此目的：
Geocoding API - 区域偏向
如果您知道地理编码将位于某个国家/地区内，则使用 区域偏向 可以获得更好的结果。例如，如果您在加拿大进行地理编码，我们建议您在请求中添加
®ion=ca，以偏向加拿大。请注意，区域偏向只是 优先 显示该区域内的结果。您仍然可以获得该区域以外的结果。Address Validation API - 区域代码
同样，如果使用
regionCode字段在请求中传递 ISO2 代码，Address Validation API 会生成更准确的结果。
存储地点 ID
若要存储 Google Maps Platform 中的地点相关信息以用于将来的请求，您可以在数据库中无限期存储地点 ID，将其作为地点的属性。您应该只需对每个地点 ID 执行一次 “查找地点” 请求。您也可以在每次用户请求交易详情时搜索地点 ID。
为确保您始终获得最新信息，请使用包含 place_id 参数的 地点详情 请求，每 12 个月 刷新一次地点 ID。
注意：请务必查看 Geocoding 的最佳实践指南。
总结
本文档介绍了 Address Validation API 和 Geocoding API 之间的核心区别。 总而言之，在以下情况下，请考虑使用 Address Validation API：
- 需要准确的邮寄地址，尤其是出于可送达性目的。
- 已知输入数据质量较差。Address Validation API 对输入错误更宽容，会突出显示无法验证的地址组成部分，并更正输入数据。
- 需要有关地址的更多信息，例如住宅与商业（在部分区域提供）。
后续步骤
下载通过可靠的地址提升结账、配送和运营效率 白皮书，并观看通过 Address Validation 提升结账、配送和运营效率 网络研讨会。
建议您进一步阅读以下内容：
贡献者
Google 负责维护本文。以下贡献者最初撰写了本文。
主要作者：
Henrik Valve | 解决方案工程师
Thomas Anglaret | 解决方案工程师
Sarthak Ganguly | 解决方案工程师