计算路线

compute_routes 工具会返回给定出行方式下出发地和目的地之间的路线。响应中包含路线的距离和时长。默认情况下,系统会在不考虑实时路况的情况下计算路线。 Pro 增加了路线规划功能,可考虑实时路况和包含更多中间经停点的路线。

本页面介绍了请求选项(包括 Pro 选项)、响应包含的内容以及请求的结算方式。如需查看完整的工具架构,请参阅 compute_routes 参考文档。

请求选项

选项 说明
origin、destination 必需。每个都是一个航点:address(人类可读的地址或 Plus Code)、place_id 或 lat_lng。您可以混合使用多种格式,例如,起点使用地址,终点使用地点 ID。
travel_mode 交通方式:DRIVE(默认)、WALK、BICYCLE 或 TRANSIT。WALK路线功能目前处于 Beta 版阶段,有时可能无法提供清晰的人行道或步行道。对于应用中显示的所有步行路线,您都必须向用户显示此警告。
routing_preference 用于计算路线的交通数据:ROUTING_PREFERENCE_TRAFFIC_UNAWARE(默认)或 ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL(专业版选项)。WALK 或 BICYCLE 不支持 ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL。请参阅可感知路况的路线。
intermediate_waypoints 出发地和目的地之间的有序停靠点。路线会按给定顺序经过这些航点。一个请求最多可包含 10 个中间航点,或者作为专业版选项,可包含 11 到 25 个中间航点。如果请求包含超过 25 个途经点,则会返回 INVALID_ARGUMENT 错误。公交路线不支持中间航点。
departure_time 或 arrival_time 从出发地出发或到达目的地的时间,采用 RFC 3339 时间戳格式。最多只能设置一个。默认值为当前出发时间。对于 TRANSIT,时间可以是过去 7 天内或未来 100 天内的任意时间。对于其他出行方式,时间不能是过去的时间,最多可以是未来 365 天。
compute_alternative_routes 如果为 true,则除了推荐路线之外,响应中还会包含备选路线(如果有)。默认设置为 false。
include_polyline 如果为 true,则响应中的每条路线都包含 encodedPolyline。默认值为 false。
location_bias 用于影响文本航点解析方式的纬度和经度,例如消除地址歧义。

Pro 选项

有两个选项可选择 Pro SKU。使用其中一项或两项功能的请求将按 Pro SKU 计费:

Pro 选项 适用情形
routing_preference 设置为 ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL 用户询问路况、拥堵情况或考虑当前路况的行程时间。请参阅可感知路况的路线。
11 到 25 个intermediate_waypoints 路线在起点和终点之间需要超过 10 个停靠点。

所有其他选项(包括出行方式、时间、备选路线、多段线和位置偏好)均按 Essentials SKU 结算。

路况感知路线规划

默认情况下,系统会在不考虑实时路况信息 (ROUTING_PREFERENCE_TRAFFIC_UNAWARE) 的情况下计算路线。此设置的延迟时间最短。它适用于不考虑或不适用路况信息的请求,例如步行路线或粗略规划。

将 routing_preference 设置为 ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL,以便在有路况数据时,根据当前路况信息计算路线及其时长。当用户询问当前驾车所需时间时,请使用此工具。对于 TRANSIT 路线,此设置会使用实时公交数据(例如延误和取消),前提是这些数据可用。WALK 或 BICYCLE 路线不支持此功能;这些请求会返回 INVALID_ARGUMENT 错误。这是一个 Pro 选项,因此请求会按 Pro SKU 结算。该选项还会增加延迟时间。

在受限正式版期间,如果您的项目不在 Pro 许可清单中,则此选项会被视为 ROUTING_PREFERENCE_TRAFFIC_UNAWARE。如需了解详情,请参阅受限正式版期间的 Pro 选项。

示例

以下请求会查询包含一个中间经停点和编码多段线的路况感知驾车路线。该 SKU 会在 Pro SKU 下计费:

{
  "method": "tools/call",
  "params": {
    "name": "compute_routes",
    "arguments": {
      "origin": {"address": "Ferry Building, San Francisco, CA"},
      "destination": {"address": "Golden Gate Park, San Francisco, CA"},
      "intermediate_waypoints": [
        {"address": "Palace of Fine Arts, San Francisco, CA"}
      ],
      "travel_mode": "DRIVE",
      "routing_preference": "ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL",
      "include_polyline": true
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

响应

响应包含 routes[],按推荐程度从高到低排序。除非 compute_alternative_routes 为 true,否则系统只会返回一条路线。每条路线都包含:

  • distanceMeters:路线的行程距离,以米为单位。
  • duration:沿路线行驶所需的时间。使用 ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL 时,时长会考虑路况信息。
  • encodedPolyline:当 include_polyline 为 true 时,路线的路径(以编码的多段线表示)。您可以使用它与其他 Google Maps Platform API 一起在地图上绘制路线。
  • attribution:您必须随路线一起显示的提供方说明。请参阅提供出处的要求。

Pro 方案在受限正式版阶段的选项

在受限正式版阶段,Pro 选项仅适用于 Pro 许可清单中的项目。如果您的项目尚未列入许可清单:

  • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL 会被视为 ROUTING_PREFERENCE_TRAFFIC_UNAWARE,并且请求会按 Essentials SKU 计费。
  • 如果请求包含超过 10 个中间航点,则会返回 INVALID_ARGUMENT 错误(“最多支持 10 个中间航点”)。

如需申请访问权限,请参阅受限正式版期间的 Pro 选项。

结算和配额

每个 compute_routes 请求都是一个可结算事件:

请求备选路线、多段线、出发或到达时间或不同的出行方式不会更改 SKU。

compute_routes 配额为每个项目每分钟 300 个查询,由两个 SKU 共享。如需了解价格,请参阅主价格表和印度价格表。

限制

  • 一个请求最多可以包含 25 个中间航点;11 到 25 个航点是 Pro 选项。如果请求包含更多内容,则会返回 INVALID_ARGUMENT 错误。
  • 公交路线不支持中间航点。包含中间航点的公交请求会返回 INVALID_ARGUMENT 错误。
  • 步行或骑行路线不支持ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL。
  • 对于公交路线,出发时间和到达时间最多可以设置为过去 7 天或未来 100 天。对于其他出行方式,这些时间不能是过去的时间,但最多可以提前 365 天。
  • 航点坐标必须在有效的地理边界内(纬度介于 -90 到 90 之间,经度介于 -180 到 180 之间)。
  • 该工具不会返回精细导航步骤、路段或公交线路详情。