核心 GTFS
下文提供建議做法,說明如何在一般大眾運輸動態饋給規格 (GTFS) 中描述大眾運輸服務。這些做法彙整了 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 動態饋給的資料合併為一個資料集。
|
從動態饋給中移除舊服務 (過期日曆)。 |
如果服務修改內容會在 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_lat 和 stop_lon |
停靠站地點必須盡量精確。停靠站地點與實際停靠站位置之間的誤差不得超過四公尺。 | ||||||||
停靠站地點必須十分靠近乘客上車的人行道 (意即與道路上的行駛方向一致)。 | |||||||||
如果不同的資料動態饋給共用一個停靠站地點 (意即兩間運輸公司都使用同一個停靠站/上車設施),請為相關停靠站使用完全相同的 stop_lat 和 stop_lon ,藉此表示該處為共用停靠站。 |
|||||||||
stop_code |
如果有向乘客顯示的停靠站號碼或簡短 ID,則必須在 GTFS 中加入 stop_code 。 |
||||||||
parent_station 和 location_type |
許多車站或總站都有多個上車設施 (視交通工具而定,可能稱為公車停靠區、月台、碼頭、閘門或其他字眼)。在這種情況下,動態饋給製作者應描述車站、上車設施 (又稱子停靠站),以及兩者的關係。
|
||||||||
為車站和子停靠站命名時,請設定乘客耳熟能詳且有助於他們識別車站和上車設施 (公車停靠區、月台、碼頭、閘門等) 的名稱。
|
routes.txt
欄位名稱 | 建議 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
如已在 agency.txt 中定義,則必須加入。 |
||||||||||||||||||||
route_short_name |
如有簡短的服務名稱,則加入 route_short_name 。這必須是乘客熟悉的服務名稱,長度不得超過 12 個半形字元。 |
||||||||||||||||||||
route_long_name |
規格參考資料中的定義:這個名稱一般來說會比 以下列舉幾種全名:
|
||||||||||||||||||||
route_long_name 不應包含 route_short_name 。 |
|||||||||||||||||||||
填入 route_long_name 時,加入完整名稱,其中包含服務身分。範例:
|
|||||||||||||||||||||
route_id |
特定具名路線的所有行程應參照同一個 route_id 。
|
||||||||||||||||||||
如果路線群組包含名稱不同的支線 (例如 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 。以下是幾種可能個案所適用的建議: |
|||||||||||||||
範例表格:
|
|||||||||||||||
請勿以「往」或「到」做為路線牌的開頭。 | |||||||||||||||
direction_id |
如果路線行程提供反向服務,請以 direction_id 欄位區分這些行程群組,並使用值 0 和 1 。 |
||||||||||||||
在整個資料集內一致地使用值 0 和 1 ,意即:
|
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 |
在下列情況中,「南行」可能會誤導客戶,因為車站標示牌中並沒有使用這個字眼。 |
||||||||||||
|
|||||||||||||
|
|||||||||||||
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 |
如果路徑包含環狀或內嵌 (車輛在一趟行程中跨越或行經路徑的相同部分),就必須同時在 如果車輛在行程中的某些形狀點折返或跨越路徑,就必須加入 |
運輸公司可以使用 shape_dist_traveled 欄位明確指定 stop_times.txt 檔案中的停靠站如何融入其個別形狀。shape_dist_traveled 欄位使用的常見值是車輛從形狀起點行駛的距離 (類似里程表讀數)。
|
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 |
如果有多項轉乘方案提供最佳選項 (意即附設額外設施的大眾運輸中心,或是鄰近或連結上車設施/月台的車站),請指定建議的轉乘點。 |
每個資料使用者都會以自己的演算法計算這段期間所需的時間。如果這個值不足,或是有使用者並未考慮的其他條件,您可以在將 |
|
如果有障礙物或其他因素導致在停靠站之間移動的時間增加,請指定轉乘時間下限。 |
|
如有實體障礙導致無法轉乘,或是行人網路包含難以行走的穿越道或路溝而導致轉乘不安全或不方便,請指定這個值。 |
|
如果行程之間可以進行不離座 (排程) 轉乘,則抵達行程的最後一個停靠站必須與出發行程的第一個停靠站相同。 |
依個案歸類的做法建議
這個部分會說明影響檔案和欄位的特殊個案。
環狀路線
環狀路線車輛的行程起點和終點位於相同地點 (有時是指大眾運輸或轉運中心)。車輛通常會持續運行,且持續循環期間,乘客可以留在車上。
因此,請採行路線牌相關建議,以便向乘客顯示車輛行駛方向。
如要表示行駛方向改變,請在 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 中加入第一個/最後一個停靠站兩次。範例如下所示。環狀路線通常可能包含沒有行駛完整個迴圈的第一趟和最後一趟行程。請一併加入這些行程。
|
|||||||||||||||
trips.direction_id |
如果環狀路線依正反方向行駛 (即順時針和逆時針),請將 direction_id 指定為 0 或 1 。 |
|||||||||||||||
trips.block_id |
以相同的 block_id 表示連續環狀行程。 |
套索路線
套索路線結合環狀路線和定向路線的要素。
- 從 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 。
|
||||||||||
trip.trip_headsign |
行程路線牌應該是行程的通用說明 (如時間表所示),例如「林登經盧普至林登」(芝加哥的例子) 或「A 經 B 至 A」(通用例子)。 |
支線
有些路線可能包含支線。這些支線之間會共用路徑和停靠站,但每個支線所服務的停靠站和路徑部分有所不同。支線之間的關係可用路線名稱、路線牌和行程簡稱表示,請參考以下詳細規範。
欄位名稱 | 建議 |
---|---|
所有欄位 | 為支線命名時,建議您遵循其他乘客資訊相關資料中的說明。以下是兩項個案的說明和範例: |
如果時刻表和站牌代表兩個不同名稱的路線 (例如 1A 和 1B),請在 GTFS 中使用 route_short_name 和/或 route_long_name 欄位呈現這項資訊。舉例來說,GoDurham Transit 路線 2、2A 和 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 資料的常見做法和建議。這個工作團隊的成員包括:
- Cambridge Systematics
- Capital Metro
- 南佛羅里達州大學都市交通研究中心
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- 奧勒岡州交通部
- Swiftly
- Transit
- Trillium
- TriMet
- 世界銀行
這份文件目前是由 MobilityData International Organization 所維護。