目标
您经常需要验证某个地点的地理位置。Google Maps Platform 中有多种不同的服务可帮助您实现此使用情形。 本文档可帮助您在两种主要的位置验证服务（地址验证 API 和地理编码 API）之间做出选择。
地址验证 API 是 Google Maps Platform 提供的一项服务，可帮助客户验证地址是否准确。
使用 Geocoding API 进行地理编码是将地址转换为地理坐标的过程，您可以使用这些坐标在地图上放置标记或在地图上定位。
如需大致了解地址验证 API 与地理编码 API 之间的区别，请点击此处。
何时选择 Address Validation API 而不是 Geocoding API
关于上述流程图的说明：
- 用户互动使用情形是指用户在场并与结果互动。
- 地点自动补全是一项 JavaScript API，因此适合与用户界面集成。
- 您可能知道现有地址存在数据质量问题。因此，虽然您可能只是想获取地理编码，但建议您通过 Address Validation API 运行这些位置信息，以更正数据集。
在许多情况下，您可能会根据上述决策树选择使用某款产品。但在其他情况下，您可能需要同时使用这两款产品才能实现目标。
在以下情况下，您可能会选择使用 Address Validation API 而不是 Geocoding API：
- 存在可疑数据，或者获取不正确的地址会产生负面的下游影响。这是因为地址验证 API 可提供更多反馈，说明输入为何未获得高精度结果。
- 您需要更正用户输入（例如拼写错误或缺少字段），这会提高输出结果的准确性。
- 与 Geocoding API 相比，目标区域从 Address Validation API 返回的元数据更多，例如建筑类型（住宅与商业）的分类。
在以下情况下，您可能会选择使用 Geocoding API 而不是 Address Validation API：
- 您的主要目标是检索地址的位置，单个地址的准确性可能并不重要。
- 例如，根据大量数据生成热图。
- 您需要一个全球解决方案，但地址验证 API 并非在所有目标区域都可用。
以下是一些示例，展示了 Address Validation API 相较于 Geocoding API 的功能。
无效地址示例
1 Fake St, Mountain View, CA 94043, USA
Address Validation API 会将此输入内容分解为各个地址组成部分（街道、城市、州/省/自治区等）。它还可以提供精细的反馈，说明地址无效的原因（精确到 PREMISE 级别）。
Fake St 不存在于加利福尼亚州山景城，地址验证 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
上述地址包含几处拼写错误，一处在街道名称中，另一处在地点中。
地址验证 API 和地理编码 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
上述地址的街道名称存在拼写错误，并且缺少柏林市（地区）。
地址验证 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
此地址正确无误，只是楼宇内没有 123 室。
Address Validation API 能够验证地址 (111 8th Ave)，并提供有关该房产的一些元数据，包括该房产是商业房产PREMISE
premises:
"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 无法找到或匹配街道号码。
注意：如需了解地址是否存在，请检查地理编码 API 响应中是否设置了任何参数（例如 types、partial_match, results, status)）。这会逐渐提高地址可能存在的置信度，但不会使其达到 100% 的准确度。因此，我们需要 Address Validation API。
您可以单独使用 Geocoding API 响应中的地址，并运用上述技巧来提高对地址准确性的信心。不过，与地址验证 API 结果不同的是，Geocoding API 不会返回确切的反馈来确定结果的准确性。
位置类型
为了正确理解本部分，您需要了解 Geocoding API 响应可能会返回的不同位置类型：
- ROOFTOP 表示返回的结果是一个精确的地理编码，我们掌握的位置信息精确到街道地址级别。
- RANGE_INTERPOLATED 表示返回的结果反映了插值到两个精确点（例如交叉路口）之间的大概位置（通常是在道路上）。当某个街道地址的 rooftop 地理编码不可用时，通常会返回内插值结果。
- GEOMETRIC_CENTER 表示返回的结果是多段线（例如街道）或多边形（例如区域）等结果的几何图形中心。
- APPROXIMATE 表示返回的结果不属于上述任何一种。
如果 Geocoding API 返回的 location_type 为 ROOFTOP 或 RANGE_INTERPOLATED，并不一定表示相应地址存在。同样，如果地理编码 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 无法返回与原始请求完全匹配的结果，尽管它能够匹配所请求地址的一部分内容。
建议您检查一下原始请求中是否存在地址不完整的情况。部分匹配的最常见原因是请求中所传递的市行政区内不存在相关街道地址。当请求与同一行政区划中的两个或更多位置相匹配时，也可能会返回部分匹配。
例如，无论是 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 响应的详尽文档，因此在此不再赘述。
最佳做法
指定地理位置
在调用地址验证 API 或地理编码 API 时，最佳做法是尽量限制搜索相应地址的地理位置范围。这两个 API 通过两种不同的方式实现此功能：
Geocoding API - 区域偏向
如果您知道地理编码将位于某个特定国家/地区内，则使用区域自定义调整可获得更好的结果。例如，如果您在加拿大进行地理编码，建议您在请求中添加
®ion=ca以偏向加拿大。请注意，地区性调整只是优先显示该地区内的结果。您仍然可以获得该区域以外的结果。Address Validation API - 区域代码
同样，如果使用
regionCode字段在请求中传递 ISO2 代码，Address Validation API 会生成更准确的结果。
存储地点 ID
若要存储 Google Maps Platform 中的营业地点相关信息以用于将来的请求，您可以在数据库中无限期存储此地点 ID，将其作为营业地点的一种属性。您应该只需对每个 placeID 执行一次查找地点请求。您也可以在每次用户请求交易详情时搜索地点 ID。
为确保您始终获得最新信息，请使用包含 place_id 参数的地点详情请求，每 12 个月刷新一次地点 ID。
注意：请务必同时查看地理编码最佳实践指南。
总结
本文档介绍了地址验证 API 和地理编码 API 之间的核心区别。总而言之，在以下情况下，请考虑使用 Address Validation API：
- 必须提供准确的邮寄地址，尤其是在需要确保邮件送达的情况下。
- 已知输入数据质量较差。Address Validation API 对输入错误容忍度更高，会突出显示无法验证的地址组成部分，并更正输入数据。
- 需要提供地址的更多信息，例如住宅地址与商业地址（仅在部分地区提供）。
后续步骤
下载通过可靠的地址提升结账、配送和运营效率 白皮书，并观看通过地址验证提升结账、配送和运营效率 网络研讨会。
建议的延伸阅读内容：
贡献者
Google 负责维护本文。以下贡献者最初撰写了此内容。
主要作者：
Henrik Valve | 解决方案工程师
Thomas Anglaret | 解决方案工程师
Sarthak Ganguly | 解决方案工程师