GTFS 規定

合作夥伴應提供符合所有標準規格和下列規格的 GTFS 動態饋給，這項動態饋給應涵蓋合作夥伴想要顯示的所有行程。提供這項資訊可讓時間表和路線資訊顯示在 Google 上。請注意，合作夥伴可以選擇在提供的動態饋給中，公開部分或所有行程的額外價格和供應情形資訊 (如有需要)。

預設規定

Static GTFS 參考資料 - 套用所有預設規定。

GTFS 最佳做法 - 請依規定遵循最佳做法。

上傳 GTFS 動態饋給：請按照此程序上傳 GTFS 動態饋給。

更新：請注意，動態饋給上傳後，即可按照這裡所述的程序更新動態饋給。一般來說，這類動態饋給更新作業可能需要 2 至 3 天才能完全傳播。

補充規定

範圍

  • 單一 GTFS 動態饋給必須包含單一國家/地區或部分國家/地區的部分。 跨國家/地區邊界的行程必須在個別洲別的個別動態饋給中提供。如果 GTFS 動態饋給涵蓋的範圍大於國家/地區，請與旅遊運輸團隊聯絡。
    • GTFS ZIP 檔案中的檔案不得超過 4 GB。大於此規則的檔案通常代表出現錯誤做法，例如忽略 frequencies.txt 或類似功能提供的壓縮選項。這可能會在處理過程中造成問題。如需超過 4 GB 的檔案，請透過 Transport-help@google.com 與旅遊運輸團隊聯絡。
    • 每次更新 GTFS 資料時，都必須針對 GTFS 動態饋給內整個未來服務的資料提供資料。系統不接受按不同時間範圍區隔服務。
  • 指定業者的所有日期都必須包含在單一動態饋給中。

翻譯

  • 翻譯可透過 translations.txt 提供，且在下列國家/地區需要提供翻譯：
    • 使用者的資訊可能會以不同的指令碼或拉丁字母提供給使用者
    • 資訊可能會以多種語言提供，或是實體可能會針對這些語言使用不同的命名 (例如 Brussels/Brussel/Bruxelles)
  • 待翻譯的實體
    • 運輸公司/停靠站/路線名稱
    • 行程/停靠的路線牌

路線名稱、行程簡稱和路線牌

  • 所有行程都必須提供路線牌，如果路線在行程期間維持一致，請設為 trips.txt (如果路線牌在行程期間保持一致) 或 stop_times.txt (如果路線牌在行程的不同階段有所變動)。
  • 路線牌應與使用者在當地可能找到的資訊相符。例如車輛或看板上展示的路線牌。
  • 當路徑有名稱時，必須在 routes.txt 中提供 long_name 的名稱。
  • 如果路線具有特定編號或英數字元 ID，且適用於該路線的所有行程和雙向的所有行程，則必須在 routes.txt 中以 short_name 的形式提供。
  • 如果路線中的行程含有個別 ID (例如火車號碼)，就必須提供這類 ID 做為行程簡稱。
  • 對於沒有路線編號或名稱的長途服務，選擇路徑名稱會發生問題。在這類情況下，一般原則是將路線名稱和路線牌的組合結合，協助使用者明確識別車輛。舉例來說，可以用營運商的名稱做為路線名稱，而行程的目的地 (如果顯示於車輛上) 則應做為行程路線牌。

範例

  • 從孟買到 Varanasi 的 Indian Railways Kamayani Express Train 11071 鐵路。注意：數字 11071 識別從孟買到瓦拉納西的特定列車行程，而非路線本身。
    • path.txt：
      • short_name：<空白>
      • long_name：Kamayani Express
    • Trip.txt：
      • Trip_short_name：11071
      • 路線牌：Varanasi
  • 從布宜諾斯艾利斯到科爾多瓦的公車，由 Chevallier Bus 營運。注意：提供服務的公車不會顯示特定路線名稱。而是醒目顯示營運運輸公司的名稱和目的地。這趟特定行程沒有個別號碼/ID，無法與同一運輸公司營運或提供同一條路線的其他行程有所區別。在這種情況下，可以使用「Chevallier」做為運輸公司名稱 (在 agencies.txt 中) 和路線 long_name (位於 routes.txt 中)。目的地應用於路線牌。trip_short_name 應保持空白。
    • path.txt：
      • short_name：<空白>
      • Long_name： Chevallier
    • Trip.txt：
      • Trip_short_name：<空白>
      • 頭標牌：科爾多瓦

停止時間

必須在 stop_times.txt 中提供完整的抵達時間和 Depart_time。

行程結構

  • 有多個城市/區域提供服務的長程行程應提供無區隔的端對端行程 (例如 A->B->C，而不是 [A->B,A->C,B->C])，其中 A、B、C 是城市區域。舉例來說，從布宜諾斯艾利斯到科爾多瓦的長程公車應顯示為這三個城市的停靠站，而非「布宜諾斯艾利斯 - 羅薩裡奧」、「布宜諾斯艾利斯 - 科爾多瓦」和「羅薩裡歐 - 科爾多瓦」的三趟行程。
  • 如果資料供應商無法取得正確行程結構的相關資訊，系統可能會根據個案情況提供區隔城市與城市的行程。如果這類城市到城市的行程在某個城市 (城市區域) 中有多個上車或下車點，則不允許使用停靠站到停靠站區隔，且所有上下車點和下車點均應在同一趟行程中列出。

車站結構物

如果大型車站有多個平台/海灣，就必須在動態饋給中指定車站和月台關係，且必須使用 stops.txt 中的 platform_code 欄位來識別特定海灣/月台。如果車輛一律從特定海灣或月台出發，則應在 GTFS 動態饋給中連結至該海灣或月台。如果出發/抵達平台或海灣在不同的出發日/時間有變動，這項資訊可在 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 第 1 版

Static GTFS 參考資料會指定選用的 fare_attributes.txt 和 fare_rules.txt 檔案。如果合作夥伴與合作夥伴 API 整合，請勿提供這些檔案。