我在替換目前使用的GTFS格式的數據，但我從這裏和那裏聽到並讀到了GTFS文件格式存在的缺陷。GTFS有哪些問題？
大多數情況下，我看到你不能以某種方式預測一些事情，如延遲或某些實時的東西。他們說你無法與他們一起獲得「全貌」。
所以我問的是，有沒有人對GTFS有更多的經驗，因爲我只是第一次看到它們，可能在某種應用中可能使用GTFS，並可以告訴他們在開發時遇到的問題？
也許有人對更好的一種文件格式有什麼建議？或者一些格式的組合？
很難說GTFS是否適合您的應用程序而不知道您的應用程序的要求是什麼，但我可以提供一些評論。
如果你的目標是向用戶提供實時數據，你應該看看GTFS-realtime，這是一種補充數據格式，專門用於發佈實時更新。對於大多數公共交通應用而言，將GTFS和GTFS實時饋送結合在一起確實可以提供關於公交網絡的「全貌」，或者足夠接近。
就GTFS本身而言，我的主要抱怨是，它似乎專門設計了的路線規劃應用程序，並且以這種格式將數據用於任何其他目的可能很困難。例如，雖然GTFS Feed記錄了有關公交站點和路線的信息，但如果數據跨越多個董事會時段，則不要求每個站點都有一個單一的規範條目—，但幾乎總是會有（似乎）重複的條目。
如果你基於繪製的路線上其中當一個人旅行，因爲對象之間的聯繫，確保你總是產生正確的結果。這並不重要。如果您只從一個人的位置開始，想知道「附近有哪些交通資源可用？」，可靠地提供準確的答案需要一些扭曲。
這取決於您導入現有Feed的需求。如果是，那麼你需要能夠以任何方式處理它。在我的情況下，導入是必需的，所以我使用相同的數據來源於其他格式，如PDF時間表。否則，你需要supoprt兩種格式。如果你不需要導入（或導出），你可以考慮你自己的格式：我發現GTFS沒有揭示實際的網絡。
GTFS需要一些解釋和消化才能最終得出整個圖片，您可以回答規劃問題。
如果它們靠近，就像相隔幾米一樣，我會合並在一起，並且如果10-50米，假設「平凡步行」。這會自動處理multipe feed的組合。
除此之外，我將stop_times大致從內向外轉爲創建「鏈接表」。最終的結果是，每個站點你都有一個出發列表和他們的目的地。
直到現在最大的問題是GTFS提要可以從操作員的角度記錄旅行。如果將頭目從351轉換爲285，乘客可以保持坐在公交車上，在車上乘坐新駕駛員並繼續行駛。這意味着你需要知道什麼旅行實際上需要被視爲以乘客的方式加入。
我解決了一個小問題，通過讓我的GTFS解析器接受一些易於編輯的構造，比如忽略序列號讓它逐步生成，並將02.13 + 1識別爲26.13，從而解決了手動饋入條目的小問題。
首先，謝謝你的回答。在你寫下最後一段之前，一切都很好？爲了幫助我理解，你能告訴我一些什麼樣的標準來定義「附近有哪些交通資源可用？」 ？ – dimrizo
下面是一個例子。假設你想回答，「距離我目前所在地最近的五個交通站點是什麼？」僅使用GTFS數據很難回答，因爲單個交通車站在「stops」表中可能有多個相應的記錄。您必須確定哪個記錄對您發佈查詢的時間有效，但GTFS中沒有定義簡單的「有效期」字段 - 您必須從Feed提供的時間表信息後退。但請注意，如果您只是生成旅行計劃，則這都不是問題。 –
很酷。謝謝。 – dimrizo