地理编码是将地址（例如街道地址）转换为地理坐标（纬度和经度）的过程，您可以使用地理编码在地图上放置标记或定位地图。本文档的重点是澄清对地址进行地理编码时涉及的注意事项。它说明了何时适合使用 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 号”），因此能够对不完整且模糊的地址进行地理编码是有益的，因为这可以让用户更快地获得结果。
- 响应用户输入的应用极易受到延迟时间的影响。
这两个因素使得 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 网络服务处理。地址地理编码后端可以实现更广泛的全球地址覆盖范围，并针对这些类型的完整、清晰的查询类型进行优化，以获取高质量的结果。
自动化系统处理模糊查询：模糊查询是指包含格式不正确的地址、不完整地址或拼写错误的查询。对于自动化系统，我们建议您使用 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 相同的后端来对这些地址进行地理编码，然后再计算路线。与指定与经纬度或地点 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 的用量限额。我们建议您尝试这些
使用优化策略。