GTFS 最佳做法

核心 GTFS

下文提供建議做法，說明如何在一般大眾運輸動態饋給規格 (GTFS) 中描述大眾運輸服務。這些做法彙整了 GTFS 最佳做法工作團隊成員的經驗，以及應用程式專屬的 GTFS 實務建議。如需更多背景資訊，請參閱常見問題。

文件結構

做法主要分為三個部分：

常見問題

這些 GTFS 最佳做法的重要性何在？

GTFS 最佳做法的宗旨如下：

  • 改善大眾運輸應用程式的使用者體驗
  • 支援廣泛的資料互通性，方便軟體開發人員部署及擴充應用程式、產品和服務
  • 在各種應用程式類別中推廣使用 GTFS (不侷限於原本的行程規劃用途)

不過，會使用 GTFS 的應用程式應該採用經過統整的 GTFS 最佳做法，以避免各自設立不同的規定和預期目標，造成彼此專屬的資料集和相關規定產生分歧，進而降低互通性。在最佳做法推出前，業界對於 GTFS 的正確資料格式該由哪些要素構成，彼此說法不一，並無明確論調。

如何制定最佳做法？由誰制定？

這些最佳做法是由參與 GTFS 的 17 個機構所組成的工作團隊制定而成，這些機構包括應用程式供應商和資料使用者、大眾運輸服務供應商，以及廣泛參與 GTFS 制定工作的顧問。至於這個工作團隊，則是由 Rocky Mountain Institute 召集和促成。

每一項最佳做法都是由工作團隊成員投票表決，大部分在無異議的情況下通過。在少數情況下，最佳做法是由大多數的機構投票通過。

為何不直接修改 GTFS 參考資料？

好問題！在檢驗規格、資料使用和需求的過程中，規格確實會有一些變動 (請參閱 GitHub 中的已關閉提取要求)。相較於最佳做法，規格參考資料的修訂內容需要通過更高標準的審查和評議。雖然如此，還是需要議定一套明確的最佳做法建議。

工作團隊推測，GTFS 核心參考資料終究會納入部分的 GTFS 最佳做法。

GTFS 驗證工具能檢查是否符合這些最佳做法嗎？

目前還沒有驗證工具能檢查是否符合所有最佳做法。不過，有多種驗證工具能檢查是否符合部分最佳做法。如需 GTFS 驗證工具清單，請參閱「測試動態饋給」一文。如果您編寫的 GTFS 驗證工具參照這些最佳做法，請來信至 gtfs@rmi.org。

我是運輸公司代表。該如何讓軟體服務供應商和廠商遵循這些最佳做法？

請向廠商或軟體服務供應商介紹這些最佳做法。採購使用 GTFS 製作的軟體時，建議您參考 GTFS 最佳做法網址，以及核心規格參考資料。

如果發現 GTFS 資料動態饋給不符合這些最佳做法，該怎麼辦？

請使用 feed_info.txt 中建議的 feed_contact_email 或 feed_contact_url 欄位 (如有)，或是前往運輸公司或動態饋給製作者的網站查詢聯絡資訊，找出動態饋給的聯絡人。與動態饋給製作者討論問題時，不妨附上特定的 GTFS 最佳做法連結。請參閱「連結至這份文件」部分。

我想提議修改/補充最佳做法，該怎麼做？

請來信至 gtfs@rmi.org，或在 GitHub GTFS 最佳做法存放區中提出問題或提取要求。

如何參與制定最佳做法？

請來信至 gtfs@rmi.org。

資料集發布與一般做法

一般建議
資料集必須發布至公開永久網址，包括 ZIP 檔案名稱 (例如 www.agency.org/gtfs/gtfs.zip)。在理想情況下，使用者可以直接透過網址下載檔案，無需登入，以便使用軟體應用程式進行下載。雖然我們建議您開放下載 GTFS 資料集 (這也是最常見的做法)，但如果資料供應商基於授權等原因而需要控管 GTFS 的存取權，建議使用 API 金鑰控管 GTFS 資料集的存取權，以利自動下載。
GTFS 資料會反覆發布，這樣位置固定的單一檔案永遠都會包含運輸公司的最新官方服務說明。
在資料疊代作業中，盡可能讓 stop_id、route_id 和 agency_id 使用固定 ID (ID 欄位)。
一個 GTFS 資料集應包含目前和未來的服務 (有時稱為「合併」資料集)。使用 Google 大眾運輸動態饋給工具的合併函式，可將來自兩組不同 GTFS 動態饋給的資料合併為一個資料集。
  • 不論何時，GTFS 資料集發布後至少 7 天內應維持有效。理想情況下，只要業者確保表定時間的車班會正常營運，該資料集應繼續保持有效狀態。
  • 如果可以，GTFS 資料集應涵蓋接下來至少 30 天的服務。
從動態饋給中移除舊服務 (過期日曆)。
如果服務修改內容會在 7 天內生效，請透過 GTFS Realtime 動態饋給 (服務公告或行程更新) 來傳達服務異動，而不要使用靜態的 GTFS 資料集。
妥善設定代管 GTFS 資料的網路伺服器，以便正確回報檔案修改日期 (請參閱第 14.29 節的「HTTP/1.1 - Request for Comments 2616」)。

依檔案歸類的做法建議

本節說明依檔案和欄位歸類的做法 (遵循 GTFS 參考資料)。

所有檔案

欄位名稱 建議
混合大小寫 所有向客戶顯示的文字字串 (包括停靠站名稱、路線名稱和路線牌) 都應採用混合大小寫 (而非全部大寫) 的方式，並遵循當地慣例在支援小寫字元的顯示器上使用地名大小寫。
範例：
Brighton Churchill Square
Villiers-sur-Marne
Market Street
縮寫 避免在動態饋給中使用縮寫來代表名稱和其他文字 (例如用 St. 代表 Street)，除非地點名稱本來就包含縮寫 (例如「JFK 機場」)。對於螢幕閱讀器軟體和語音使用者介面等無障礙輔助工具，縮寫可能會造成判別方面的問題。瀏覽軟體在經過精心設計後，就能可靠地將原文轉換為縮寫加以顯示，但如果是從縮寫轉換為原文，往往就可能更容易出錯。

agency.txt

欄位名稱 建議
agency_id 應加入此欄位，即使動態饋給只包含一間運輸公司 (另請參閱在 routes.txt 和 fare_attributes.txt 中加入 agency_id 的建議)。
agency_lang 應加入此欄位。
agency_phone 應加入此欄位，除非沒有客服電話。
agency_email 應加入此欄位，除非沒有客服電子郵件信箱。
agency_fare_url 應加入此欄位，除非運輸公司完全不收費。

範例：

  • 假設客運服務是由多家小型客運公司提供，但排班和售票則是由一間大型客運公司負責，從使用者的角度來看，等於是這間大型公司在提供客運服務。因此，該大型客運公司在動態饋給內應定義為運輸公司。即使公司內部是按照不同的小型客運業者劃分資料，但在動態饋給中還是只能定義一間運輸公司。
  • 售票入口網站是由動態饋給供應商經營，但實際提供服務且使用者認定為負責方的卻是不同的運輸公司。實際提供服務的運輸公司應在動態饋給內定義為運輸公司。

stops.txt

欄位名稱 建議
stop_id 如果停靠站位於不同的實體地點 (也就是車輛在指定路線上停靠的精確指定地點各有不同，可能依照站牌、候車亭或其他這類公共資訊區分，位於不同街角或代表不同上車設施，例如月台或公車停靠區，即使彼此之間相隔不遠也一樣)，應該就要有不同的 stop_id。
stop_id 是乘客看不到的內部 ID。
在資料疊代作業中，相同停靠站的 stop_id 應保持不變 (請參閱「資料集發布與一般做法」部分)。
stop_name stop_name 必須與運輸公司在停靠站、車站或上車設施顯示的公開名稱相符，例如在時刻表上刊印、在網路上發布，及/或在該地點標示的名稱。
假如沒有任何已發布的停靠站名稱，在整個動態饋給中，停靠站名稱應遵循一致的命名慣例。
除了通常用縮寫來稱呼的地點，請盡量避免使用縮寫。請參閱「所有檔案」部分下方的「縮寫」(#2)。
針對向客戶顯示的文字欄位，我們建議遵循當地慣例，停靠站名稱以英文大小寫混用表示。
根據預設，stop_name 不得包含一般或冗餘字詞，例如「車站」或「停靠站」，但在少數情況下可以使用。
  • 實際上是名稱的一部分 (聯合車站、中央車站)
  • stop_name 過於籠統 (例如城市名稱)。加上「車站」、「總站」或其他字詞可更清楚指出地點。
stop_lat 和 stop_lon 停靠站地點必須盡量精確。停靠站地點與實際停靠站位置之間的誤差不得超過四公尺。
停靠站地點必須十分靠近乘客上車的人行道 (意即與道路上的行駛方向一致)。
如果不同的資料動態饋給共用一個停靠站地點 (意即兩間運輸公司都使用同一個停靠站/上車設施)，請為相關停靠站使用完全相同的 stop_lat 和 stop_lon，藉此表示該處為共用停靠站。
stop_code 如果有向乘客顯示的停靠站號碼或簡短 ID，應在 GTFS 中加入 stop_code。
parent_station 和 location_type 許多車站或總站都有多個上車設施 (視交通工具而定，可能稱為公車停靠區、月台、碼頭、閘門或其他字眼)。在這種情況下，動態饋給製作者應描述車站、上車設施 (又稱子停靠站)，以及兩者的關係。
  • 車站或總站應在 stops.txt 中使用 location_type = 1 定義為記錄。
  • 每個上車設施應使用 location_type = 0 定義為停靠站。parent_station 欄位應參照上車設施所在車站的 stop_id。
為車站和子停靠站命名時，請設定乘客耳熟能詳且有助於他們識別車站和上車設施 (公車停靠區、月台、碼頭、閘門等) 的名稱。
母車站名稱 子停靠站名稱
芝加哥聯合車站 芝加哥聯合車站 19 號月台
舊金山渡輪大廈總站 舊金山渡輪大廈總站 E 閘門
下城轉運中心 下城轉運中心 B 公車停靠區

routes.txt

欄位名稱 建議
agency_id 如已在 agency.txt 中定義，則必須加入。
route_short_name 如有簡短的服務名稱，則加入 route_short_name。這必須是乘客熟悉的服務名稱，長度不得超過 12 個半形字元。
route_long_name 規格參考資料中的定義：這個名稱一般來說會比 route_short_name 更一目瞭然，通常包含路線的目的地或停靠站。視情況而定，必須指定 route_short_name 和/或 route_long_name。如果路線沒有全名，請指定 route_short_name，並使用空白字串做為這個欄位的值。

以下列舉幾種全名：

主要行駛路徑或專用道
路線名稱 形式 運輸公司
「N」/「Judah」 route_short_name/
route_long_name		 Muni (舊金山)
「6」/「ML King Jr Blvd」 route_short_name/
route_long_name		 TriMet (奧勒岡州波特蘭)
「6」/「Nation - Étoile」 route_short_name/
route_long_name		 RATP (法國巴黎)。
「U2」/「Pankow - Ruhleben」 route_short_name/
route_long_name		 BVG (德國柏林)
服務說明
「哈特韋爾區域快捷公車」
route_long_name 不應包含 route_short_name。
填入 route_long_name 時，加入完整名稱，其中包含服務身分。範例：
服務身分 建議 範例
「MAX 輕軌」
TriMet (奧勒岡州波特蘭)		 route_long_name 應包含品牌 (MAX) 和特定路線名稱 「MAX 紅線」
「MAX 藍線」
「Rapid Ride」
ABQ Ride (新墨西哥州阿布奎基)		 route_long_name 應包含品牌 (Rapid Ride) 和特定路線名稱 「Rapid Ride 紅線」
「Rapid Ride 藍線」
route_id 特定具名路線的所有行程應參照同一個 route_id。
  • 一條路線的不同方向不應分為不同的 route_id 值。
  • 路線的不同營運時段不應分為不同的 route_id 值。意即請勿在 routes.txt 中針對「市中心 (上午)」和「市中心 (下午)」服務建立不同的記錄。
如果路線群組包含名稱不同的支線 (例如 1A 和 1B)，請按照支線情況的相關建議來決定 route_short_name 和 route_long_name。
route_color 和 route_text_color 必須與看板和書面/線上客戶資訊一致 (因此如果沒有在其他地方使用，就不需加入)。

trips.txt

  • 查看環狀路線的特殊案例：環狀路線是指行程起點和終點都在同一個停靠站的情況，而線形路線則有兩個不同的總站。環狀路線必須按照特定做法加以說明。查看「環狀路線案例」部分。
  • 查看套索路線的特殊案例：套索路線是線形和環狀幾何圖形的混合，車輛只有一部分的路線是環狀行駛。套索路線必須按照特定做法加以說明。查看「套索路徑案例」部分。
欄位名稱 建議
trip_headsign 請勿在 trip_headsign 或 stop_headsign 欄位中提供路線名稱 (與 route_short_name 和 route_long_name 相符)。
應包含車輛路線牌顯示的目的地、方向和/或其他行程名稱文字，可用於區分路線中的行程。決定 GTFS 資料集所提供的路線牌時，與車輛顯示的方向資訊一致是主要且優先的目標。只有在不違反這個主要目標的情況下，才能加入其他資訊。如果路線牌在行程期間有所變動，請以 stop_times.stop_headsign 覆寫 trip_headsign。以下是幾種可能個案所適用的建議：
範例表格：
路線說明 建議
2A：僅限目的地 提供終點站目的地，例如「轉運中心」、「波特蘭市中心」或「珍森海灘」。
2B：包含路線控點的目的地 <destination>經<waypoint> (「高門經查令十字」)。如果路線控點會在車輛通過後從乘客看到的路線牌中移除，請使用 stop_times.stop_headsign 來設定更新的路線牌。
2C：包含當地停靠站的區域性地點名稱 如果目的地的城市或自治市鎮境內有多個停靠站，請在抵達目的地城市後使用 stop_times.stop_headsign。
2D：僅限方向 使用「北行」、「入城」、「順時針」或類似方向等字眼來指示。
2E：包含目的地的方向 <direction>至<terminus name>，例如「南行至聖荷西」。
2F：包含目的地和路線控點的方向 <direction>經<waypoint>往<destination> (「北行經查令十字往高門」)。
請勿以「往」或「到」做為路線牌的開頭。
direction_id 如果路線行程提供反向服務，請以 direction_id 欄位區分這些行程群組，並使用值 0 和 1。
在整個資料集內一致地使用值 0 和 1，意即：
  • 如果 1 在紅色路線上代表出城，則 1 在綠色路線上也代表出城
  • 如果 1 在路線 X 上代表北行，則 1 在路線 Y 上也代表北行
  • 如果 1 在路線 X 上代表順時針，則 1 在路線 Y 上也代表順時針

stop_times.txt

環狀路線：環狀路線需要注意特別的 stop_times 相關事項 (請參閱「環狀路線案例」部分)。

欄位名稱 建議
pickup_type 和 drop_off_type 不提供載客服務的非營利 (空駛) 行程，在所有 stop_times 列中都應標示為 pickup_type 和 drop_off_type 的值等於 1。
在營利行程中，內部用於監控營運績效的「時間點」以及乘客無法上車的調度站等其他地點，應標示為 pickup_type = 1 (無法上車) 和 drop_off_type = 1 (無法下車)
timepoint 應提供 timepoint 欄位。這個欄位代表業者會試著嚴格遵守哪個 stop_times (timepoint=1)，且其他停靠時間為預估值 (timepoint=0)。
arrival_time 和 departure_time arrival_time 和 departure_time 欄位應盡可能指定時間值，包括時間點之間的非強制預估或插補時間。
stop_headsign

stop_headsign 值會覆寫 trip_headsign (位於 trips.txt)。如果路線牌顯示的文字在行程期間有所變動，則應提供 stop_headsign 值。stop_headsign 值不會「沿用」到後續停靠站，因此如果停靠站的路線牌維持不變，就必須重複輸入這些值。一般來說，路線牌值也應與車站內的標示牌對應。

在下列情況中，「南行」可能會誤導客戶，因為車站標示牌中並沒有使用這個字眼。
紐約市南行的 2 號線：
在 stop_times.txt 列中： 使用 stop_headsign 值：
抵達曼哈頓前 Manhattan & Brooklyn
抵達下城前 Downtown & Brooklyn
抵達布魯克林前 Brooklyn
抵達布魯克林後 Brooklyn (New Lots Av)
波士頓南行的紅線 (布倫特里支線)：
在 stop_times.txt 列中： 使用 stop_headsign 值：
抵達下城前 Inbound to Braintree
抵達下城後 Braintree
過了下城 Outbound to Braintree
shape_dist_traveled 如果是環狀或內嵌 (車輛在一趟行程中跨越或行經路徑的相同部分) 路線，則必須提供 shape_dist_traveled。請參閱 shapes.shape_dist_traveled 中的相關建議。

calendar.txt

欄位名稱 建議
所有欄位 calendar_dates.txt 只能包含時間表的少數例外狀況。請使用 calendar.txt 來設定定期排程的服務。
加入 calendar.service_name 欄位也能讓 GTFS 更易讀，但此規格未採用這個做法。

calendar_dates.txt

欄位名稱 建議
所有欄位 calendar_dates.txt 只能包含時間表的少數例外狀況。請使用 calendar.txt 來設定定期排程的服務。
加入 calendar.service_name 欄位也能讓 GTFS 更易讀，但此規格未採用這個做法。

fare_attributes.txt

欄位名稱 建議
所有欄位 如果 agency.txt 有 agency_id 欄位，則 fare_attributes.txt 也應包含該欄位。
如果無法準確模擬票價系統，請將此欄位留空以免造成混淆。
加入並盡可能準確模擬車資 (fare_attributes.txt 和 fare_rules.txt)。在少數情況下，如果無法準確模擬車資，寧可顯示更高價格也不要顯示較低價格，這樣客戶上車時才不會遇到車資不足的情況。如果絕大多數的車資都無法正確模擬，請勿在動態饋給中加入車資資訊。

fare_rules.txt

欄位名稱 建議
所有欄位 如果 agency.txt 有 agency_id 欄位，則 fare_attributes.txt 也應包含該欄位。
如果無法準確模擬票價系統，請將此欄位留空以免造成混淆。
加入並盡可能準確模擬車資 (fare_attributes.txt 和 fare_rules.txt)。在少數情況下，如果無法準確模擬車資，寧可顯示更高價格也不要顯示較低價格，這樣客戶上車時才不會遇到車資不足的情況。如果絕大多數的車資都無法正確模擬，請勿在動態饋給中加入車資資訊。

shapes.txt

欄位名稱 建議
所有欄位 在理想情況下，如果有共用路徑 (意即路線 1 和 2 共用相同的路段或軌段)，則路徑的共用部分應完全相符，這有助於提高大眾運輸的製圖品質。
路徑應以車輛行駛道路的中心線為準。這可以是街道的中心線 (如果沒有指定車道)，也可以是車輛行駛方向的道路中心線。

路徑不得「卡入」路邊停靠站、月台或上車地點。
shape_dist_traveled

如果路徑包含環狀或內嵌 (車輛在一趟行程中跨越或行經路徑的相同部分)，就必須同時在 shapes.txt 和 stop_times.txt 中提供。

內嵌路線

如果車輛在行程中的某些形狀點折返或跨越路徑，就必須加入 shape_dist_traveled 來說明 shapes.txt 中部分形狀點與 stop_times.txt 中記錄的對應關係。
運輸公司可以使用 shape_dist_traveled 欄位明確指定 stop_times.txt 檔案中的停靠站如何融入其個別形狀。shape_dist_traveled 欄位使用的常見值是車輛從形狀起點行駛的距離 (類似里程表讀數)。
  • 路徑 (位於 shapes.txt) 應在行程停靠站地點的 100 公尺以內。
  • 簡化路徑，避免 shapes.txt 包含多餘的形狀點 (意即移除直線段上的額外形狀點；請參閱路線簡化問題的相關討論)。

feed_info.txt

必須加入 feed_info.txt 以及下方所有欄位。

欄位名稱 建議
feed_start_date 和 feed_end_date 必須加入
feed_version 必須加入
feed_contact_email 和 feed_contact_url 至少提供一個

frequencies.txt

欄位名稱 建議
所有欄位 如果是 frequencies.txt 參照的行程，系統會略過實際停靠時間。只有以頻率為準的行程，才需要重視停靠站之間的行駛時間間隔。為求清晰可讀，frequencies.txt 中所參照行程的第一個停靠時間應始於 00:00:00 (第一個 arrival_time 值為 00:00:00)。
block_id 可針對以頻率為準的行程提供。

transfers.txt

transfers.transfer_type 可以是 GTFS 中定義的四個值之一。這些 transfer_type 定義是引用自下方的 GTFS 規格，並附上其他做法建議。

欄位名稱 建議
transfer_type 0 或 (空白)：此為路線之間的建議轉乘點。

如果有多項轉乘方案提供最佳選項 (意即附設額外設施的大眾運輸中心，或是鄰近或連結上車設施/月台的車站)，請指定建議的轉乘點。
1：此為兩條路線之間的定時轉乘點。即將出發的車輛應等候正要抵達的車輛，並讓乘客有足夠的時間轉乘其他路線大寫規則。

每個資料使用者都會以自己的演算法計算這段期間所需的時間。如果這個值不足，或是有使用者並未考慮的其他條件，您可以在將 transfer_type 設為 2 之後覆寫計算出的時間，並在 min_transfer_time 中指定允許的時間下限 (以秒為單位)。
2：這類轉乘從抵達到離開至少需要一段時間，才能順利完成轉接。轉乘所需時間是由 min_transfer_time 指定。

如果有障礙物或其他因素導致在停靠站之間移動的時間增加，請指定轉乘時間下限。
3：這個地點無法轉乘不同路線。

如有實體障礙導致無法轉乘，或是行人網路包含難以行走的穿越道或路溝而導致轉乘不安全或不方便，請指定這個值。
如果行程之間可以進行不離座 (排程) 轉乘，則抵達行程的最後一個停靠站必須與出發行程的第一個停靠站相同。

依個案歸類的做法建議

這個部分會說明影響檔案和欄位的特殊個案。

環狀路線

環狀路線車輛的行程起點和終點位於相同地點 (有時是指大眾運輸或轉運中心)。車輛通常會持續運行，且持續循環期間，乘客可以留在車上。

下圖：環狀路線。車輛在一趟行程中會回到起點。某些環狀路線只有單向行駛，某些則會雙向行駛。
環狀路線

因此，請採行路線牌相關建議，以便向乘客顯示車輛行駛方向。

如要表示行駛方向改變，請在 stop_times.txt 檔案中提供 stop_headsigns。stop_headsign 說明從定義的停靠站出發的行程方向。在行程的每個停靠站加入 stop_headsigns，即可變更行程沿途的路線牌資訊。

請勿在 stop_times.txt 檔案中為兩點來回提供載客服務 (例如同一輛公車往返) 的路線定義單一環狀行程，請改為將行程分成兩個不同的行程方向。

環狀行程模擬範例：

每個停靠站都會變更路線牌的環狀行程：

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

包含兩個路線牌的環狀行程：

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
欄位名稱 建議
trips.trip_id 針對只有一趟行程的迴圈，模擬完整來回路線。
stop_times.stop_id 針對環狀行程，在 stop_times.txt 中加入第一個/最後一個停靠站兩次。範例如下所示。環狀路線通常可能包含沒有行駛完整個迴圈的第一趟和最後一趟行程。請一併加入這些行程。
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id 如果環狀路線依正反方向行駛 (即順時針和逆時針)，請將 direction_id 指定為 0 或 1。
trips.block_id 以相同的 block_id 表示連續環狀行程。

套索路線

套索路線結合環狀路線和定向路線的要素。

下圖：套索路線是從 A 經過 B 到 A 的環狀路線，分為三個部分：
  • 從 A 到 B 的直線段；
  • B 本身的迴圈；
  • 從 B 到 A 的直線段。
套索路線
範例：
地鐵路線 (芝加哥)
市郊往市中心的公車路線 (聖艾伯特或愛德蒙)
CTA 棕線 (CTA 網站和 TransitFeed)
欄位名稱 建議
trips.trip_id 「車輛來回」的整個範圍 (請參閱上方插圖) 包含從 A 開到 B、B 開到 B，以及 B 開到 A。整個車輛來回路線可用下列方式表示：
  • trips.txt 中的單一 trip_id 值/記錄
  • trips.txt 中的多個 trip_id 值/記錄，並以 block_id 表示連續行駛。
    		•
    stop_times.stop_headsign A 到 B 部分沿途的停靠站會有去程和回程車經過。stop_headsign 有助於區分行駛方向。因此，建議您針對這類行程提供 stop_headsign。
    範例：
    「A 經 B」
    「A」
    芝加哥交通管理局的紫線
    「南行至盧普」
    「北行經盧普」
    「北行至林登」
    埃德蒙頓運輸服務公車路線，此為 39 號
    「魯德福」
    「世紀公園」
    trip.trip_headsign 行程路線牌應該是行程的通用說明 (如時間表所示)，例如「林登經盧普至林登」(芝加哥的例子) 或「A 經 B 至 A」(通用例子)。

    支線

    有些路線可能包含支線。這些支線之間會共用路徑和停靠站，但每個支線所服務的停靠站和路徑部分有所不同。支線之間的關係可用路線名稱、路線牌和行程簡稱表示，請參考以下詳細規範。

    下圖：支線的三種可能設定。主要路徑為黑色。支線為金色。
    支線設定
    欄位名稱 建議
    所有欄位 為支線命名時，建議您遵循其他乘客資訊相關資料中的說明。以下是兩項個案的說明和範例：
    如果時刻表和站牌代表兩個不同名稱的路線 (例如 1A 和 1B)，請在 GTFS 中使用 route_short_name 和/或 route_long_name 欄位呈現這項資訊。舉例來說，GoDurham Transit 路線 2、2A 和 2B 的大部分路線相同，但在幾個方面有差異。
    • 路線 2 為核心服務，營運時段最多。
    • 路線 2 在主要街道設有分岔路線，營運時間為夜間、週日和假日。
    • 路線 2A 和 2B 的營運時間為週一到週六白天。
    • 路線 2B 在共用路徑的分岔路線增設停靠站。
    如果運輸公司提供的資訊將支線描述為同名路線，請使用 trips.trip_headsign、stop_times.stop_headsign 和/或 trips.trip_short_name 欄位。例如：GoTriangle 路線 300 會根據時段開往不同的地點。在通勤尖峰時段，標準路線會加開班次，方便上班族進出市區。

    關於這份文件

    目標

    遵守 GTFS 最佳做法的目的如下：

    • 提高大眾運輸資料的互通性
    • 改善大眾運輸應用程式中的使用者體驗
    • 方便軟體開發人員部署及擴充應用程式、產品和服務
    • 在各種應用程式類別中推廣使用 GTFS (不侷限於原本的行程規劃用途)

    如何提議或修訂已發布的 GTFS 最佳做法

    GTFS 應用程式和做法與時俱進，因此這份文件可能需要不時修訂。如要提議修訂這份文件，請前往 GTFS 最佳做法 GitHub 存放區提出提取要求，並提議進行修改。如有任何意見，也可以來信至 specifications@mobilitydata.org。

    連結至這份文件

    請連結至此，為動態饋給製作者提供正確的 GTFS 資料建立指引。每項建議都有一個錨定連結。按一下建議即可取得網頁內錨定連結的網址。

    如果使用 GTFS 的應用程式針對本文未提及的 GTFS 資料做法提出要求或建議，建議您發布包含這些要求或建議的文件，以便補充這些常見最佳做法。

    GTFS 最佳做法工作團隊

    GTFS 最佳做法工作團隊由 Rocky Mountain Institute 於 2016 年至 2017 年間召集，成員包括大眾運輸服務供應商、利用 GTFS 資料的應用程式開發人員、顧問及學術機構，全體共同定出 GTFS 資料的常見做法和預期目標。這個工作團隊的成員包括：

    這份文件目前是由 MobilityData International Organization 所維護。