跳轉到

GTFS Schedule 最佳實踐

這些是 一般運輸供給規範 (GTFS) 中描述公共運輸服務的建議做法。 這些實踐是根據 GTFS 最佳實踐工作小組 成員的經驗和特定於應用程式的 GTFS 實踐建議。

有關更多背景資訊，請參閱常見問題。

文件結構

實踐分為四個主要部分：

資料集發布和一般實踐

  • 資料集應發佈在公共的永久 URL 上，包括 zip 檔案名稱。 （例如，www.agency.org/gtfs/gtfs.zip）。 理想情況下，URL 應可直接下載，無需登入即可存取文件，以便於透過使用軟體應用程式進行下載。 雖然建議（也是最常見的做法）公開下載 GTFS 資料集，但如果資料提供者確實需要出於許可或其他原因控制對 GTFS 的訪問，則建議使用 API 金鑰控制對 GTFS 資料集的訪問，這將有助於自動下載。
  • GTFS資料以迭代形式發布，因此在穩定位置的單一文件始終包含交通機構（或多個機構）的最新官方服務描述。
  • 在資料迭代中盡可能維護stop_id、route_id、和agency_id持久標識符（id 欄位）。
  • GTFS資料集應包含目前和即將推出的服務（有時稱為「合併」資料集）。 Google transitfeed 工具的合併功能可用於從兩個不同的資料集建立合併GTFS資料集。
  • 隨時發布GTFS資料集應至少在接下來的 7 天內有效，理想情況下，只要營運商確信時間表將繼續運行即可。
  • 如果可能的話，GTFS資料集應至少涵蓋接下來 30 天的服務。
  • 從資料集中刪除舊服務（過期日曆）。
  • 如果服務修改將在7 天或更短的時間內生效，請透過GTFS-realtime Feed（服務建議或行程更新）表達此服務更改）而不是靜態 GTFS 資料集。
  • 網路伺服器託管GTFS資料應配置為正確報告檔案修改日期（請參閱在第14.29節下的HTTP/1.1 - Request for Comments 2616 ）。

按文件組織的實踐建議

本節顯示按檔案和欄位組織的實踐，與GTFS參考。

所有文件

欄位名稱 推薦
混合大小寫 所有面向客戶的文字字串（包括站點名稱、路線名稱和車頭標誌）都應使用混合大小寫（而不是全部大寫），遵循本地約定，以便在能夠顯示小寫字符的顯示器上將地名大寫。
例子：
布萊頓邱吉爾廣場
馬恩河畔維利爾斯
市場街
縮寫 避免在整個提要中使用名稱和其他文字的縮寫（例如 St. 代表街道），除非該地點以縮寫名稱來稱呼（例如「JFK 機場」）。 縮寫可能會影響螢幕閱讀器軟體和語音使用者介面的可存取性。 消費軟體可以設計為可靠地將完整單字轉換為縮寫詞以供顯示，但從縮寫轉換為完整單字更容易出錯。

agency.txt

欄位名稱 推薦
agency_id 應提供，即使提要中只有一個機構。 (另請參閱建議包含agency_id在routes.txt和fare_attributes.txt)
agency_phone 除非不存在此類客戶服務電話，否則應提供。
agency_email 除非不存在此類客戶服務電子郵件，否則應提供。
agency_fare_url 除非該機構完全免費，否則應提供。

例子：

  • 巴士服務由幾家小型巴士公司經營。 但是有一個大機構負責調度和票務，並且從用戶的角度來看其負責公共汽車服務。 此大機構應該定義為提要中的機構。 即使資料在內部由不同的小型公車業者拆分，提要中也應該只定義一個機構。

  • 提要提供者運行票務門戶，但有不同的機構實際營運服務並且用戶知道其為營運負責。 實際營運服務的機構應定義為提要中的機構。

stops.txt

字段名稱 推薦
stop_name 如果沒有發布的站點名稱，請在整個提要中遵循一致的站點命名約定。
默認情況下，stop_name 不應包含通用或冗餘詞，如“Station”或“Stop”，但允許一些極端情況。
  • 當它實際上是名稱的一部分時（聯合車站、中央車站
  • 當stop_name過於籠統時（比如如果它是城市的名稱）。“車站”、“終點站”或其他詞使含義清晰。
stop_lat & stop_lon 停止位置應盡可能準確。與實際停止位置相比，停止位置的誤差應不超過 __4 米。
停靠點應放置在非常靠近乘客上車的行人通行權處（即街道的正確一側）。
如果在不同的數據饋送中共享停靠點位置（即兩個代理機構使用完全相同的停靠/登機設施），則通過對兩個停靠點使用完全相同的 stop_lat 和 stop_lon 來指示該停靠點是共享的。
parent_station & location_type 許多車站或航站樓有多個登機設施（根據模式，它們可能被稱為巴士站、站台、碼頭、登機口或其他術語）。在這種情況下，飼料生產者應描述車站、寄宿設施（也稱為兒童站）及其關係。
  • 車站或終點站應定義為 stops.txt 中的記錄，location_type = 1。
  • 每個登機設施應定義為停靠站，location_type = 0。 parent_station 字段應引用登機設施所在車站的 stop_id。
在給車站和兒童站命名時，設置讓乘客容易識別的名稱，並能幫助乘客識別車站和上車設施（公交車站、站台、碼頭、登機口等）。
母站名稱子站名稱
芝加哥聯合車站芝加哥聯合車站 19 號站台
舊金山渡輪大廈航站樓舊金山渡輪大廈航站樓 E 門
Downtown Transit CenterDowntown Transit Center Bay B

routes.txt

字段名稱 推薦
agency_id 應該包括在內，即使 Feed 中只有一家機構。 （另見建議包括agency_id在agency.txt和fare_attributes.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 藍線”
“快速騎行”
新墨西哥州阿爾伯克基的 ABQ 騎行		 route_long_name 應包含品牌（Rapid Ride）和具體路線名稱“Rapid Ride Red Line”
“Rapid Ride Blue Line”
route_id 給定命名路線上的所有行程都應引用相同的“route_id”。
  • 不應將路線的不同方向劃分為不同的 route_id 值。
  • 不應將路線的不同運營跨度劃分為不同的 route_id 值。即不要在 routes.txt 中為“Downtown AM”和“Downtown PM”服務創建不同的記錄）。
    		•
    如果路由組包含明確命名的分支（例如 1A 和 1B），請按照路由 branches 案例中的建議來確定 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. Destination-only提供終點站目的地。例如“交通中心”、“波特蘭市中心”或“詹岑海灘”>
    2B.帶航點的目的地<destination>通過<航點> “通過查令十字街的海格特”。如果在車輛通過這些航點後航點從向乘客顯示的航標中刪除，請使用 stop_times.stop_headsign 設置更新的航標。>
    2℃。帶有本地站點的區域地名如果目的地城市或自治市內有多個站點，請在到達目的地城市後使用stop_times.stop_headsign。>
    2D。僅方向使用諸如“北行”、“入站”、“順時針”或類似方向等術語表示。>
    2E。方向與目的地<direction>到<終點站名稱>例如“南行至聖何塞”>
    2F。帶有目的地和航路點的方向<direction>通過<航點>到<目的地> （“北行經查令十字到海格特”）。>
    不要以“To”或“Towards”作為頭標的開頭。
    direction_id 在整個數據集中始終使用值 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 一般來說，headsign 的值也應該與車站的標誌相對應。

    在以下情況下，“Southbound”會誤導客戶，因為它沒有用於車站標誌。
    在紐約，對於 2 南行：
    對於 stop_times .txt 行：使用 stop_headsign 值：
    直到曼哈頓到達曼哈頓和布魯克林
    直到到達市中心市中心和布魯克林
    直到到達布魯克林布魯克林
    一旦到達布魯克林布魯克林（新地段大道）
    在波士頓，紅線南行，Braintree 支線：
    對於 stop_times.txt 行：使用 stop_headsign 值：
    直到到達市中心進入布倫特里
    一旦到達市中心Braintree
    市區後出站到Braintree
    shape_dist_traveled 必須為具有循環或內聯的路線提供“shape_dist_traveled”（車輛在一次行程中穿過或經過相同的路線部分）。請參閱 shapes.shape_dist_traveled 建議。

    calendar.txt

    字段名稱 推薦
    所有領域 包含一個 calendar.service_name 字段也可以增加 GTFS 的可讀性，儘管這在規範中沒有採用。

    calendar_dates.txt

    字段名稱 推薦
    所有領域 包含一個 calendar.service_name 字段也可以增加 GTFS 的可讀性，儘管這在規範中沒有被採用。

    fare_attributes.txt

    字段名稱 推薦
    agency_id 應該包括在內，即使 Feed 中只有一家機構。 （另見建議包括agency_id在agency.txt和routes.txt)
    如果票價系統無法準確建模，請避免進一步混淆並將其留空。
    包括票價（fare_attributes.txt 和 fare_rules.txt）並儘可能準確地對其建模。在票價無法準確建模的極端情況下，票價應表示為更貴而不是更便宜，這樣客戶就不會試圖以不足的票價登機。如果絕大多數票價無法正確建模，請不要在提要中包含票價信息。

    fare_rules.txt

    字段名稱 推薦
    所有領域 如果票價系統無法準確建模，請避免進一步混淆並將其留空。
    包括票價（fare_attributes.txt 和 fare_rules.txt）並儘可能準確地對其建模。在票價無法準確建模的極端情況下，票價應表示為更貴而不是更便宜，這樣客戶就不會試圖以不足的票價登機。如果絕大多數票價無法正確建模，請不要在提要中包含票價信息。

    shapes.txt

    字段名稱 推薦
    所有領域 理想情況下，對於共享的路線（即，在路線 1 和 2 在同一段道路或軌道上運行的情況下），路線的共享部分應該完全匹配。這有助於促進高質量的交通製圖。
    路線應遵循車輛行駛的通行權的中心線。如果沒有指定車道，這可能是街道的中心線，也可能是沿車輛移動方向行駛的道路一側的中心線。

    路線不應“鋸齒”到路邊停靠點、平台或登機位置。
    shape_dist_traveled 如果路線包括循環或內聯（車輛在一次行程中穿越或經過同一路線部分），則必須在“shapes.txt”和“stop_times.txt”中提供。
    如果車輛在旅行過程中在點處回溯或穿過路線路線，shape_dist_traveled 很重要，以闡明 shapes.txt 中的點部分 code> 與 stop_times.txt 中的記錄對應。
    shape_dist_traveled 字段允許機構準確指定 stop_times.txt 文件中的停靠點如何適合其各自的形狀。用於 shape_dist_traveled 字段的常用值是車輛行駛時到形狀起點的距離（想想類似於里程表讀數的東西）。
  • 路線路線（在 shapes.txt 中）應在行程服務的停靠點 100 米範圍內。
  • 簡化路線，以便 shapes.txt 不包含多餘的點（即刪除直線段上的多餘點；請參閱線簡化問題的討論）。
    		•

    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 規範，initalics，並附有額外的實踐建議。

    字段名稱 推薦
    transfer_type 0 或（空）：這是路線之間的推薦換乘點。
    如果有多個換乘機會，包括一個更好的選擇（即具有額外便利設施的中轉中心或具有相鄰或連接的登機設施/平台），指定推薦的換乘點。
    1：這是兩條路線之間的定時換乘點。出發的車輛應該等待到達的車輛，有足夠的時間讓乘客在路線之間換乘。
    這種換乘類型會覆蓋所需的間隔以可靠地進行換乘。例如，谷歌地圖假設乘客需要 3 分鐘才能安全換乘。其他應用程序可能會採用其他默認值。
    2：此轉移需要在到達和離開之間的最短時間以確保連接。換乘所需時間由 min_transfer_time 指定。
    如果有障礙物或其他因素會增加停靠站之間的行駛時間，請指定最短換乘時間。
    3：在此位置的路線之間無法進行換乘。
    如果由於物理障礙而無法進行換乘，或者由於難以穿越的道路或道路上的縫隙而使換乘變得不安全或複雜，請指定此值行人網絡。
    如果行程之間允許進行座位內（塊）換乘，則到達行程的最後一站必須與出發行程的第一站相同。

    feed_info.txt

    應包含feed_info.txt，所有字段都在下面。

    字段名稱 推薦
    feed_start_date & feed_end_date 應該包括
    feed_version 應該包括
    feed_contact_email & feed_contact_url 提供至少一個

    按案例組織的實踐建議

    本節涵蓋具有跨文件和字段含義的特定情況。

    循環路線

    在循環路線上，車輛的行程在同一地點開始和結束（有時是中轉或換乘中心）。車輛通常連續運行並允許乘客在車輛繼續其循環時留在車上。

    因此，應採用頭標建議，以便向乘客顯示車輛行駛的方向。

    要指示行進方向的變化，請在“stop_times.txt”文件中提供“stop_headsigns”。 stop_headsign 描述了從其定義的站點出發的行程方向。將“stop_headsigns”添加到行程的每個站點允許您更改行程中的 headsign 信息。

    不要在 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_idstop_id stop_sequence
    90001011
    90001022
    90001033
    90001014
    trips.direction_id 如果循環以相反的方向運行（即順時針和逆時針），則將 direction_id 指定為 0 或 1。
    trips.block_id 用相同的 block_id 表示連續的循環行程。

    套索路線

    套索路線結合了循環路線和定向路線的各個方面。

    示例：
    地鐵路線（芝加哥）
    郊區巴士到市區路線（St. Albert 或 Edmonton)
    CTA 布朗線（CTA 網站 和 TransitFeeds)
    字段名稱 推薦
    trips.trip_id “車輛往返”的全部範圍（參見插圖 上圖）包括從 A 到 B 再到 B 並返回 A。整個車輛往返可以表示為：
  • trips.txt中的__single__trip_id值/記錄
  • trips.txt中的__Multiple__trip_id值/記錄，連續旅行由block_id指示。
    • 李>
    stop_times.stop_headsign 沿 A-B 段的停靠點將雙向通過。 stop_headsign 便於區分行進方向。因此，建議為這些行程提供 stop_headsign。example_table:
    Examples:
    “A 通過 B”
    “A”
    < tbody>
    芝加哥交通局的紫線
    “南行至環路”
    “北行經環路”
    “北行至林登"
    埃德蒙頓公交服務線路，此處39
    “盧瑟福”
    《世紀公園》
    trip.trip_headsign 旅行頭標應該是旅行的全局描述，如時間表中顯示的那樣。可以是“Linden to Linden via Loop”（芝加哥示例），或“A to A via B”（通用示例）。

    分支

    一些路線可能包括分支。這些分支之間共享對齊和停止，但每個分支也服務於不同的停止和對齊部分。使用下面的進一步指南，可以通過路線名稱、頭標和行程短名稱來指示分支之間的關係。

    字段名稱 推薦
    所有領域 在命名支線時，建議遵循其他旅客信息資料。以下是兩種情況的描述和示例：
    如果時間表和路標表示兩條明確命名的路線（例如 1A 和 1B），則使用“route_short_name”和/或“route_long_name”字段在 GTFS 中顯示。示例：GoDurham Transit 路線 2、2A 和 2B 在大部分路線中共享一個共同路線，但它們在幾個不同的方面有所不同。
    • Route 2 是核心服務，大部分時間運行。
    • Route 2 包括 Main Street 晚上、週日和節假日的偏離。
    • Route 2A 和 2B 運營週一至週六的白天時間。
    • 路線 2B 在偏離共享路線的路線提供額外停靠點。
    如果機構提供的信息將分支描述為同名路線，則使用“trips.trip_headsign”、“stop_times.stop_headsign”和/或“trips.trip_short_name”字段。示例：GoTriangle route 300 根據一天中的時間前往不同的位置。在通勤高峰時段，標準路線上增加了額外的支路，以容納進出城市的工人。

    常見問題 (FAQ)

    為什麼這些 GTFS 最佳實踐很重要？

    GTFS 最佳實踐的目標是：

    • 改善公共交通應用程序中的最終用戶客戶體驗
    • 支持廣泛的數據互操作性，使軟件開發人員更容易部署和擴展應用程序、產品和服務
    • 促進 GTFS 在各種應用類別中的使用（超出其最初對旅行計劃的關注）

    如果沒有協調的 GTFS 最佳實踐，各種使用 GTFS 的應用程序可能會以不協調的方式建立需求和期望，這會導致不同的需求和特定於應用程序的數據集以及互操作性降低。在發布最佳實踐之前，對於格式正確的 GTFS 數據的構成存在更大的歧義和分歧。

    它們是如何開發的？誰開發了它們？

    這些最佳實踐由參與 GTFS 的 17 個組織組成的工作組制定，包括應用程序提供商和數據消費者、交通提供商以及廣泛參與 GTFS 的顧問。該工作組由 [落基山研究所] (http://www.rmi.org/mobility) 召集和推動。

    工作組成員對每個最佳實踐進行投票。大多數最佳實踐均獲得一致投票通過。在少數情況下，大多數組織都批准了最佳實踐。

    為什麼不直接更改 GTFS 參考？

    好問題！檢查規範、數據使用和需求的過程確實觸發了規範的一些更改（參見 GitHub 中的關閉拉取請求)。規範參考修訂受到比最佳實踐更高的審查和評論標準。然而，仍然需要就一套明確的最佳實踐建議達成一致。

    工作組預計一些 GTFS 最佳實踐最終將成為核心 GTFS 參考的一部分。

    GTFS 驗證器工具是否檢查是否符合這些最佳實踐？

    目前沒有驗證器工具檢查是否符合所有最佳實踐。各種驗證器工具檢查是否符合其中一些最佳實踐。有關 GTFS 驗證器工具的列表，請參閱 GTFS 驗證器。如果您編寫了引用這些最佳實踐的 GTFS 驗證器工具，請發送電子郵件至 specifications@mobilitydata.org。

    我代表一個運輸機構。我可以採取哪些步驟來使我們的軟件服務提供商和供應商遵循這些最佳實踐？

    請向您的供應商或軟件服務提供商推薦這些最佳實踐。我們建議在採購 GTFS 生產軟件時參考 GTFS 最佳實踐 URL 以及核心規範參考。

    如果我發現 GTFS 數據饋送不符合這些最佳實踐，我應該怎麼做？

    如果在它們存在，或在運輸機構或飼料生產商網站上查找聯繫信息。在將問題傳達給提要生產者時，請鏈接到正在討論的特定 GTFS 最佳實踐。 （請參閱 “鏈接到此文檔”）。

    我想建議對最佳實踐進行修改/添加。我該怎麼做呢？

    發送電子郵件至 specifications@mobilitydata.org 或在 GitHub GTFS 最佳實踐倉庫 中打開問題或拉取請求最佳實踐）。

    我如何參與？

    電子郵件 specifications@mobilitydata.org。

    關於本文檔

    目標

    維護 GTFS 最佳實踐的目標是：

    • 支持公交數據更大的互操作性
    • 改善公共交通應用程序中的最終用戶客戶體驗
    • 讓軟件開發人員更輕鬆地部署和擴展應用程序、產品和服務
    • 促進 GTFS 在各種應用類別中的使用（超出其最初對旅行計劃的關注）

    如何提議或修改已發布的 GTFS 最佳實踐

    GTFS 應用程序和實踐不斷發展，因此本文檔可能需要不時修改。要對本文檔提出修改建議，請在 GTFS 最佳實踐 GitHub 存儲庫 中打開一個拉取請求並倡導修改。您可以將任何評論通過電子郵件發送至 specifications@mobilitydata.org。

    鏈接到此文檔

    請在此處鏈接，以便為飼料生產商提供正確形成 GTFS 數據的指導。每個單獨的推薦都有一個錨鏈接。單擊建議以獲取頁內錨鏈接的 URL。

    如果使用 GTFS 的應用程序對 GTFS 數據實踐提出了此處未描述的要求或建議，則建議發布包含這些要求或建議的文檔以補充這些常見的最佳實踐。

    GTFS 最佳實踐工作組

    GTFS 最佳實踐工作組由 落基山研究所 於 2016-17 年召集，由公共交通提供商、GTFS 消費應用程序的開發人員、顧問和學術組織組成，以定義常見的GTFS 數據的實踐和期望。 該工作組的成員包括：

    今天，該文檔由 MobilityData 維護。