GTFS 要求

合作伙伴应提供符合所有标准规范以及以下规范的 GTFS Feed。此 Feed 应涵盖合作伙伴想要展示的所有行程。提供此信息后，Google 便会显示时刻表和路线信息。请注意，合作伙伴可以选择在提供的 Feed 中针对部分或所有行程公开额外的价格和库存状况信息。

默认要求

静态 GTFS 参考 \- 应用所有默认要求。

GTFS 最佳实践 \- 请遵循最佳 实践，就像它们是必需的一样。

上传 GTFS Feed - 请按照此流程上传 GTFS Feed。

更新：请注意，Feed 上传后，可以按照 此处所述的流程 进行更新。一般来说，这些 Feed 更新可能需要 2-3 天才能完全传播。

其他要求

范围

  • 单个 GTFS Feed 必须涵盖单个国家/地区或国家/地区的一部分。跨越国境的行程必须在单独的洲际 Feed 中提供。如果 GTFS Feed 涵盖的范围大于一个国家/地区，请与 旅游交通团队联系。
    • GTFS zip 文件中的文件应小于 4GB。 如果文件大于此大小，通常表示存在不良做法，例如忽略 frequencies.txt 或类似功能提供的压缩选项。这可能会在处理过程中导致问题。如果您 认为需要大于 4GB 的文件，请通过 transport-help@google.com与旅游 交通团队联系。
    • 对于 GTFS Feed 中服务的整个未来运营期，应在每次更新 GTFS 数据时提供相应数据。按不同时间段细分服务是不可接受的。
  • 给定运营商的所有日期都必须包含在单个 Feed 中。

翻译

  • 可以使用 translations.txt 提供翻译，并且在以下国家/地区是必需的：
    • 向用户提供的信息可能采用不同的脚本，或者采用拉丁文以外的脚本
    • 向用户提供的信息可能采用多种语言，或者实体可能在这些语言中使用不同的命名（例如 Brussels/Brussel/Bruxelles）
  • 要翻译的实体
    • 代理机构/车站/路线名称
    • 行程/车站目的地

路线名称、行程短名称和目的地

  • 必须为所有行程提供目的地，可以在 trips.txt 中提供（如果目的地在整个行程中保持一致），也可以在 stop_times.txt 中提供（如果目的地在行程的不同阶段发生变化）。
  • 目的地应与用户在地面上找到的信息一致。 例如，车辆上或标牌上显示的目的地。
  • 如果路线有名称，则必须在 routes.txt 中以 long_name 的形式提供。
  • 如果路线有特定的数字或字母数字标识符，适用于该路线上的所有行程且适用于双向行程，则必须在 routes.txt 中以 short_name 的形式提供。
  • 如果路线中的行程有单独的标识符（例如火车车次），则必须以行程短名称的形式提供此类标识符。
  • 对于没有路线编号或名称的长途服务，选择路线名称会成为一个问题。在这种情况下，一般准则是，路线名称和目的地的组合应有助于用户明确识别车辆。例如，运营代理机构的名称可用作路线名称，而行程的目的地（如果显示在车辆上）应作为行程目的地。

示例

  • 印度铁路 Kamayani Express 列车 11071，从孟买到瓦拉纳西。注意：编号 11071 标识的是从孟买到瓦拉纳西的特定列车行程，而不是路线本身。
    • routes.txt：
      • short_name：<空>
      • long_name：Kamayani Express
    • trips.txt：
      • trip_short_name：11071
      • headsign：瓦拉纳西
  • 由 Chevallier Bus 运营的从布宜诺斯艾利斯到科尔多瓦的公交车。注意：运营此服务的公交车不显示特定的路线名称。而是醒目地显示其运营代理机构的名称及其目的地。此特定行程没有单独的编号/标识符，可将其与同一代理机构运营或服务于同一路线的其他行程区分开来。在这种情况下，可以将“Chevallier”同时用作代理机构名称（在 agencies.txt 中）和路线 long_name（在 routes.txt 中）。目的地应作为目的地。trip_short_name 应保持为空。
    • routes.txt：
      • short_name：<空>
      • long_name：Chevallier
    • trips.txt：
      • trip_short_name：<空>
      • headsign：科尔多瓦

车站时间

必须在 stop_times.txt 中提供 arrival_time 和 departure_time。

行程结构

  • 服务于多个城市/区域的长途行程应以端到端的方式提供，不得分段（例如 A->B->C，而不是 [A->B,A->C,B->C]），其中 A、B、C 是城市区域。例如，从布宜诺斯艾利斯到科尔多瓦的长途公交车，在罗萨里奥停靠，应表示为在三个城市停靠的行程，而不是三个行程“布宜诺斯艾利斯 - 罗萨里奥”“布宜诺斯艾利斯 - 科尔多瓦”和“罗萨里奥 - 科尔多瓦”
  • 如果数据提供商无法获取有关正确行程结构的信息，则可以根据具体情况提供分段的城市间行程。如果此类城市间行程在一个城市（城市区域）内有多个上车点或下车点，则不允许按车站分段 - 所有上车点和所有下车点都应列在单个行程中。

车站结构

对于有多个站台/泊位的大型车站，必须在 Feed 中指定车站-站台关系，并且必须通过 stops.txt 中的 platform_code 字段标识特定泊位/站台。始终从特定泊位或站台出发或到达的车辆应在 GTFS Feed 中链接到该泊位或站台。如果离开或到达站台或泊位在不同的离开日期/时间发生变化，则可以在 GTFS Realtime 数据中提供此信息。

车站/站点位置

  • 对于有多个站台或泊位的大型车站，车站的位置应设置为其最显眼的行人入口的位置（如果车站有建筑物或结构），或设置为乘客候车区的位置（对于室外车站）。
  • 对于路边较小的站点，如果可以识别公交车杆，则站点的位置应设置为公交车杆的位置。 如果无法识别特定的公交车杆，则位置应放置在道路的正确一侧，并且在车辆停靠的道路沿线实际位置附近（理想情况下，在 10 米内）。

其他 GTFS 扩展程序

仅当合作伙伴想要通过实现合作伙伴 API 显示价格/库存状况信息时才需要。

Google 公共交通票务扩展程序

  • 合作伙伴应实现 Google 公共交通票务扩展程序规范 ，该规范是 GTFS 票务扩展程序的子集。
  • 我们对票务 ID 施加以下要求：
    • 票务 ID 应保持稳定（即，允许因正当理由而偶尔更改）。如果票务 ID 发生变化，则需要向后兼容（至少 1 周的最短期限）。
    • 如需确定 API 请求中 SegmentKey 的参数，必须 提供 ticketing_trip_id（在 trips.txt 中）和 ticketing_stop_id（在 ticketing_identifiers.txt 中）。不支持 回退到 stop_sequence，因为它不稳定。

GTFS-Fares v1

静态 GTFS 参考指定了可选的 fare_attributes.txt 和 fare_rules.txt 文件。如果合作伙伴与合作伙伴 API 集成，则不应提供这些文件。