現在使用しているデータ形式を GTFS に置き換えることに関心がありますが、GTFS ファイル形式に欠陥があることをあちこちで聞いたり読んだりしています。
ほとんどの場合、遅延やリアルタイムのものなど、何らかの形で予測できないことがわかります。彼らは「全体像」を把握できないと言います。
それで、私が尋ねているのは、GTFS の経験が豊富な人がいるかどうかです。初めて見たので、ある種のアプリケーションで GTFS を使用した可能性があり、開発中に直面した問題を伝えることができますか?
誰かがより良い種類のファイル形式についての提案を持っているかもしれません? それともいくつかの形式の組み合わせですか？
既存のフィードをインポートする必要があるかどうかによって異なります。はいの場合は、とにかくそれを処理できる必要があります。私の場合、インポートが必要だったので、PDF 時刻表などの他の形式から派生したデータにも同じものを使用しています。それ以外の場合は、2 つの形式をサポートする必要があります。インポート (またはエクスポート) に必要ない場合は、独自の形式を検討してください。GTFS は実際のネットワークを明らかにしないことがわかりました。
GTFS は、計画に関する質問に答えることができる全体像に到達するために、かなりの解釈と消化が必要です。
停留所が数メートル離れている場合など、近くにある場合はそれらを統合し、10 ～ 50 メートルの場合は「些細な歩行」と想定します。これにより、複数のフィードの組み合わせが自動的に処理されます。
それとは別に、「リンク」テーブルを作成するために、stop_times を大まかに裏返しにします。最終的な結果として、停車地ごとに出発地と目的地のリストが作成されます。
これまでの最大の問題は、GTFS フィードがオペレーターの視点から旅行を記録できることです。バスのヘッドサインが 351 から 285 に変わった場合、乗客はバスに座ったままでよい。つまり、どの旅行が実際に乗客の観点から結合されていると見なされる必要があるかを知る必要があります。
GTFS パーサーに、シーケンス番号を省略してインクリメンタルに生成させる、02.13+1 を 26.13 として認識するなど、編集を容易にするいくつかの構造を受け入れるようにすることで、手動フィード入力の小さな問題を解決しました。