地理编码是将地址（例如街道地址）转换为地理坐标（纬度和经度）的过程，您可以利用此类坐标在地图上放置标记，或在地图上定位。本文档的重点是阐明地理编码地址时涉及的注意事项。其中介绍了何时最好使用 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 的地点自动补全服务。
自动化系统
自动化系统处理完整、明确的邮政地址：对于完整的邮政地址字符串（例如“48 Pirrama Rd, Pyrmont, NSW, Australia”）等明确的查询，最好使用 Geocoding API Web 服务进行处理。地址地理编码后端可覆盖全球更多地址，并针对此类完整且明确的查询进行了优化，以提供优质结果。
自动化系统处理含糊不清的查询：含糊不清的查询是指格式不规范、地址不完整或拼写有误的查询。对于自动化系统，我们建议使用 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 的用量限制。我们建议您尝试以下
使用量优化策略。