地理编码是将地址（例如街道地址）转换为地理坐标（纬度和经度）的过程，您可以利用此类坐标在地图上放置标记，或在地图上定位。本文档的重点是阐明地理编码地址时涉及的注意事项。其中介绍了何时最好使用 Geocoding API，以及何时最好使用 Places API 地点自动填充服务。
一般来说，对完整地址（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”）进行地理编码时，请使用 Geocoding API。 在对模糊不清（不完整）的地址进行地理编码时，或在对延迟敏感的应用（例如在响应用户输入时）使用 Places API 地点自动补全服务。
用例和 API 建议
| 用例和 API 建议 | |
|---|---|
| 实时响应用户输入（包括用户输入的不明确、不完整、格式不规范或拼写有误的地址） | 使用 Places API 地点自动补全服务获取地点 ID，然后使用 Geocoding API 将地点 ID 地理编码为经纬度。 |
| 自动化系统处理完整、明确的邮政地址（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”） | 使用 Geocoding API 网络服务。 |
| 处理模糊查询的自动化系统（例如，地址不完整、格式不规范或拼写有误） | 建议自动化系统使用 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 Web 服务，然后该服务会返回完整的地址详细信息，并将地址地理编码为经纬度。地点 ID 还可以传递给其他 API，例如 Directions API 和 Distance Matrix API（见下文）。
Geocoding API 中的地址地理编码延迟时间要长得多，并且对于不完整或模糊的查询，生成的结果也不太准确，因此不建议将其用于必须实时响应用户输入的应用。
详细了解适用于 Android、iOS、JavaScript 和 Places API 的地点自动补全服务。
自动化系统
自动化系统处理完整、明确的邮政地址：最好使用 Geocoding API Web 服务处理明确的查询，例如完整的邮政地址字符串（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”）。地址地理编码后端可覆盖全球更多地址，并针对此类完整且明确的查询进行了优化，以提供优质结果。
自动化系统处理含糊不清的查询：含糊不清的查询是指格式不规范、地址不完整或拼写有误的查询。对于自动化系统，我们建议使用 Geocoding API 网络服务。不过，Geocoding API 无法处理模糊查询，对于模糊查询，它可能会生成不太准确的结果或不返回任何结果。如果您的自动化系统处理大量来自用户输入的不明确查询，不妨使用 Places API 中的地点自动补全服务为应用添加交互元素，因为该服务旨在返回多个可能的选项，并允许用户在这些选项中进行选择。Places API 会返回一个地点 ID，该 ID 可作为完全去歧义的位置传递给 Geocoding API Web 服务，然后该服务会返回完整的地址详细信息，并将地址地理编码为经纬度。 详细了解适用于 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 或将地点自动补全服务与 Geocoding API 结合使用，从而创建可为用户提供准确地理编码结果且延迟时间较短的应用。
管理错误和重试
如果您收到 UNKNOWN_ERROR 响应，则说明这些响应是由暂时性错误导致的，最好在短暂延迟后重试。我们建议您使用 Google Maps Platform 网络服务
客户端库，这些库包含重试逻辑并支持 Google Maps Platform 高级计划身份验证。
适用于 Google 地图服务的 Java 客户端、Python 客户端、Go 客户端和 Node.js 客户端 是受社区支持的客户端库，可在 GitHub 上下载和贡献，您还可以在 GitHub 上找到安装说明和示例代码。
如果您收到 OVER_QUERY_LIMIT 状态代码响应，则表示您超出了该 API 的用量限制。我们建议您尝试以下
使用量优化策略。