GTFS 要求

合作伙伴应提供符合所有标准规范以及下列规范的 GTFS Feed。此 Feed 应涵盖合作伙伴要展示的所有行程。提供此信息后，时间表和路线信息就会在 Google 上显示。请注意，合作伙伴可以选择在提供的 Feed 中针对部分或所有行程公开更多价格和空房信息（如果需要的话）。

默认要求

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

GTFS 最佳实践 - 请遵循强制性最佳实践。

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

更新：请注意，上传 Feed 后，您可以按照此处所述的流程更新 Feed。通常，这些 Feed 更新可能需要 2-3 天才能完全生效。

其他要求

范围

  • 一个 GTFS Feed 必须涵盖单个国家/地区或国家/地区的部分内容。 跨国边界的行程必须在涵盖整个大陆的单独 Feed 中提供。如果 GTFS Feed 涵盖国家/地区以外的任何内容，请与旅行运输团队联系。
    • GTFS ZIP 文件中的文件应小于 4GB。如果文件大于此值，通常意味着存在不良做法，例如忽略 frequencies.txt 或类似功能提供的压缩选项。这可能会导致在处理过程中出现问题。如果您认为自己需要的文件大于 4GB，请通过 transport-help@google.com 与旅行运输团队联系。
    • 每次更新 GTFS 数据时，都应提供 GTFS Feed 中服务未来操作的整个数据。不可按不同的时间段对服务进行细分。
  • 单个 Feed 中必须包含指定运营商的所有日期。

翻译

  • 您可以通过 translations.txt 提供翻译，并且在以下国家/地区必须提供翻译：
    • 向用户提供的信息可能会以不同的字母或非拉丁字母提供
    • 向用户提供的信息可能会以多种语言提供，或者在这些语言中各个实体可能使用不同的命名方式（例如布鲁塞尔/布鲁塞尔/布鲁塞尔）
  • 需要翻译的实体
    • 交通机构/经停点/路线名称
    • 出行/停车标牌

路线名称、行程简称和标牌

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

示例

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

停止时间

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

行程结构

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

车站结构

对于具有多个站台/车站的大型车站，必须在 Feed 中指定车站与站台之间的关系，并且必须通过 stops.txt 中的 platform_code 字段标识特定车站/平台。总是从/抵达某个特定停靠区或平台的车辆应在 GTFS Feed 中关联到该停靠区或平台。如果出发/到达站台或停靠站在不同出发日期/时间发生变化，GTFS 可以实时提供此信息。

车站位置

  • 对于具有多个站台或经停区的大型车站，车站的位置应设置为最显眼的步行入口位置（如果车站有建筑物或结构）或乘客等候区的位置（对于室外车站）。
  • 对于道路一侧较小的停靠站，如果可以识别到充电站，应将停靠站的位置设置为公交站杆的位置。如果无法识别特定的公交杆，该位置应放置在道路的正确一侧，且应放置在车辆停靠点的实际位置附近（最好在 10 米以内）。

其他 GTFS 扩展

仅对希望通过实现合作伙伴 API 显示价格/库存状况信息的合作伙伴而言是必需的。

Google 公交票务扩展程序

  • 合作伙伴应实现 Google 公交票卡扩展规范，该规范是 GTFS-Ticketing 扩展的一部分。
  • 我们对票务 ID 实施以下要求：
    • 工单 ID 应保持稳定（即允许有充分的理由偶尔更改）。如果票务 ID 发生更改，则需要向后兼容性（最短期限至少为 1 周）。
    • 要确定 API 请求中 SegmentKey 的参数，必须提供 ticketing_trip_id（在 trips.txt 中）和 ticketing_stop_id（在 ticketing_identifiers.txt 中）。stop_sequence 上的回退不受支持，因为它不稳定。

GTFS-Fares 版本 1

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