GTFS 規定

合作夥伴應提供符合所有標準規格的 GTFS 動態饋給，以及下列規格。這個動態饋給應涵蓋合作夥伴想顯示的所有行程。提供這項資訊後，Google 就能顯示時刻表和路線資訊。請注意，合作夥伴可能會選擇在提供的動態饋給中，顯示部分或所有行程的額外價格和供應情形資訊。

預設條件

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

GTFS 最佳做法 - 請遵循最佳做法，視為必要條件。

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

更新：請注意，動態饋給上傳後，可以按照這裡說明的程序更新。一般來說，動態饋給更新最多可能需要 2 至 3 天才會全面生效。

額外規定

範圍

  • 單一 GTFS 動態饋給必須涵蓋單一國家/地區或國家/地區的一部分。如果行程跨越國界，必須在個別的洲際動態饋給中提供。如果 GTFS 動態饋給涵蓋的範圍大於一個國家/地區，請與旅遊交通團隊聯絡。
    • GTFS ZIP 檔案中的檔案大小應小於 4 GB。 如果檔案大於這個大小，通常表示您採用了不良做法，例如忽略 frequencies.txt 提供的壓縮選項或類似功能。這可能會導致處理期間發生問題。如果您認為需要大於 4 GB 的檔案，請透過 transport-help@google.com 與 Travel Transport 團隊聯絡。
    • 每次更新 GTFS 資料時，都應提供 GTFS 動態饋給中整個未來營運期間的服務資料。服務不得依不同時間區隔。
  • 特定營運商的所有日期都必須包含在單一動態饋給中。

翻譯

  • 您可以使用 translations.txt 提供譯文，且在下列國家/地區必須提供譯文：
    • 向使用者提供的資訊可能採用不同文字，或拉丁文字以外的文字
    • 向使用者提供的資訊可能有多種語言版本，或實體在這些語言中可能使用不同的命名 (例如布魯塞爾/布魯塞爾/布魯塞爾)
  • 要翻譯的實體
    • 機構/車站/路線名稱
    • 行程/停靠站標誌

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

  • 所有行程都必須提供路線牌，可透過 trips.txt (如果路線牌在整個行程中保持一致) 或 stop_times.txt (如果路線牌在行程的不同階段有所變更) 提供。
  • 頭牌應與使用者在地面上看到的資訊一致。例如車輛或看板上顯示的路線牌。
  • 如果路線有名稱，則必須在 routes.txt 中提供 long_name。
  • 如果路線有特定的數字或英數字元 ID，適用於該路線的所有行程和雙向行程，則必須在 routes.txt 中提供做為 short_name。
  • 如果路線中的行程有個別 ID (例如列車號碼)，則必須以行程簡短名稱的形式提供這類 ID。
  • 對於沒有路線號碼或名稱的長途服務，選擇路線名稱會變得有問題。在這種情況下，一般原則是路線名稱和目的地標誌的組合應有助於使用者明確識別車輛。舉例來說，營運機構的名稱可做為路線名稱，而行程目的地 (如顯示在車輛上) 則應做為行程路線牌。

範例

  • 印度鐵路 Kamayani Express 列車 11071，從孟買到瓦拉納西。注意： 11071 是指從孟買到瓦拉納西的特定火車行程，而非路線本身。
    • routes.txt：
      • short_name: <empty>
      • long_name: Kamayani Express
    • trips.txt：
      • trip_short_name: 11071
      • 路線牌：瓦拉納西
  • Chevallier Bus 營運的布宜諾斯艾利斯到科爾多瓦巴士。注意：行駛這項服務的巴士不會顯示特定路線名稱。而是會醒目顯示營運機構的名稱和目的地。這趟特定行程沒有個別號碼/ID，因此無法與同一機構營運或行駛相同路線的其他行程區別。在這種情況下，可以將「Chevallier」同時做為機構名稱 (在 agencies.txt 中) 和路線 long_name (在 routes.txt 中)。目的地應做為目的地標誌。trip_short_name 應保持空白。
    • routes.txt：
      • short_name: <empty>
      • long_name: Chevallier
    • trips.txt：
      • trip_short_name: <empty>
      • 路線牌：哥多華

停止時間

抵達時間和出發時間都必須以 stop_times.txt 格式提供。

行程結構

  • 如果長途行程會經過多個城市/區域，請提供端對端行程，不要分段 (例如 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 v1

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