地理编码是将地址（例如街道地址）转换为地理坐标（纬度和经度）的过程，您可以利用此类坐标在地图上放置标记，或在地图上定位。本文档重点阐明了对地址进行地理编码时需要考虑的事项。其中介绍了何时最适合使用 Geocoding API，以及何时适合使用 Places API 地点自动补全服务。
一般而言，在对完整地址（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”）进行地理编码时，请使用 Geocoding API。 在对不明确（不完整）的地址进行地理编码时，或对于对延迟敏感的应用（例如在响应用户输入时），请使用 Places API 的“地点自动补全”服务。
用例和 API 建议
| 用例和 API 建议 | |
|---|---|
| 实际到达、高级目的地选择、最后一公里配送、拼车接送、建筑物入口或校园导航 | 使用 Geocoding API v4 中的搜索目的地 (SearchDestinations) 方法检索建筑物入口、可规划路线的导航点、建筑物轮廓和附近地标。请参阅选择地理编码方法。 |
| 实时响应用户输入（包括用户输入的模糊、不完整、格式不规范或拼写错误的地址） | 使用 Places API 的地点自动补全服务获取地点 ID，然后调用 SearchDestinations（获取超本地化详情）或 GeocodePlace（获取基本坐标）。 |
| 自动化系统处理完整、明确的邮政地址（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”） | 使用 Geocoding API v4 网络服务（SearchDestinations 用于获取超本地化详情，或 GeocodeAddress 用于查找坐标）。 |
| 处理不明确查询的自动化系统（例如，不完整、格式不规范或拼写错误的地址） | 建议自动化系统使用 Geocoding API 网络服务。不过，如果自动化系统因用户输入而产生大量含糊不清、不完整或拼写错误的查询，则可以考虑添加交互式地点自动补全 widget，以便用户选择结果，从而避免拼写错误。 |
| 使用 Directions API（旧版）或 Distance Matrix API（旧版）时，如果将出发地、目的地或航点指定为地址字符串，则会出现延迟问题 | 使用 Places API 地点自动补全服务获取地点 ID，然后将地点 ID 传递给 Directions API（旧版）或 Distance Matrix API（旧版），从而缩短地理编码延迟时间。 |
响应用户输入
实时响应用户输入的应用有两个主要考虑因素会影响 API 的选择：
- 用户输入通常涉及逐步输入地址（例如“123 Main Street”），因此能够对不完整、不明确的地址进行地理编码是有益的，因为这样可以让用户更快地获得结果。
- 响应用户输入的应用极易受到延迟时间的影响。
这两点考虑因素使得 Places API 中的地点自动补全服务非常适合响应用户输入。地点自动补全功能旨在返回多个可能的选项，并允许用户在这些选项之间进行选择。Places API 可限制为仅搜索地理编码或地址，同时排除商家。此外，自动补全查询功能可以偏向于返回特定于某个位置的结果。Places API 会返回一个地点 ID，该 ID 可作为完全消除歧义的位置传递给 Geocoding API 网络服务，后者随后会返回完整的地址详细信息，并将该地址地理编码为经纬度。地点 ID 也可以传递给其他 API，例如 Directions API（旧版）和 Distance Matrix API（旧版）（请参阅缩短延迟时间）。
Geocoding API 中的地址地理编码延迟时间要长得多，而且对于不完整或不明确的查询，其结果也不太准确，因此不建议在必须实时响应用户输入的应用中使用。
详细了解适用于 Android、iOS、JavaScript 和 Places API 的地点自动补全服务。
自动化系统
处理完整、明确的邮政地址的自动化系统：明确的查询（例如完整的邮政地址字符串，如“48 Pirrama Rd, Pyrmont, NSW, Australia”）最好由 Geocoding API Web 服务处理。地址地理编码后端在全球范围内提供更广泛的地址覆盖范围，并针对这些类型的完整、明确的查询进行了优化，以提供高质量的结果。
处理不明确查询的自动化系统：不明确的查询是指包含格式不规范的地址、不完整的地址或拼写错误的查询。对于自动化系统，我们建议使用 Geocoding API 网络服务。不过，Geocoding API 并非旨在处理不明确的查询，并且可能会针对不明确的查询生成不太准确的结果或零结果。如果您的自动化系统处理大量源自用户输入的模糊查询，您可能会受益于使用 Places API 中的地点自动补全服务向应用添加互动元素，因为该服务旨在返回多个可能的选项，并允许用户在这些选项之间进行选择。Places API 会返回一个地点 ID，该 ID 可作为完全消除歧义的位置传递给 Geocoding API 网络服务，然后该服务会返回完整的地址详细信息，并将地址地理编码为经纬度。 详细了解适用于 Android、iOS、JavaScript 和 Places API 的地点自动补全服务。
缩短 Directions API（旧版）和 Distance Matrix API（旧版）的延迟时间
如果起点、终点或航点指定为地址字符串，Directions API（旧版）和 Distance Matrix API（旧版）会使用与 Geocoding API 相同的后端，在计算路线之前对这些地址进行地理编码。与将相同位置指定为 latlng 或地点 ID 相比，这会显著增加延迟时间。
如果您的应用在对延迟时间敏感的情况下（例如响应用户输入）使用 Directions API（旧版）或 Distance Matrix API（旧版），并且您的起点、终点或航点最初指定为地址字符串，我们建议您使用 Places API 的地点自动补全服务将地址字符串转换为地点 ID，然后将地点 ID 传递给 Directions API（旧版）或 Distance Matrix API（旧版），以最大限度地缩短延迟时间。详细了解适用于 Android、iOS、JavaScript 和 Places API 的地点自动补全服务。 另请参阅 地点自动补全和路线的 JavaScript 示例。
总结
根据您的应用场景，您可以单独使用 Geocoding API，也可以将其与地点自动补全服务结合使用。这样，您就可以构建提供准确地理编码结果并缩短延迟时间的应用。
管理错误和重试
如果您收到 UNKNOWN_ERROR 响应，这些响应是由暂时性错误引起的，最好在短暂延迟后重试。我们建议您使用 Google Maps Platform Web 服务
客户端库，其中包含重试逻辑并支持 Google Maps Platform 专业版方案身份验证。
适用于 Google 地图服务的 Java 客户端、Python 客户端、Go 客户端和 Node.js 客户端是社区支持的客户端库，可在 GitHub 上下载和贡献代码，您还可以在 GitHub 上找到安装说明和示例代码。
如果您收到 OVER_QUERY_LIMIT 状态代码响应，则表示您已超出该 API 的用量限额。我们建议您尝试这些
用量优化策略。