コンテンツにスキップ

指針

GTFS の本来のビジョンを維持するために、仕様を変更する際に考慮すべきいくつかの指針が定められています。

フィードは作成と編集が容易であるべきです
仕様の基盤として CSV を選んだのは、スプレッドシートプログラムやテキストエディタを使って簡単に閲覧・編集できるためであり、これは小規模な事業者にとって有用です。また、ほとんどのプログラミング言語やデータベースから容易に生成できるため、大規模なフィードを公開する事業者にとっても適しています。

フィードは解析が容易であるべきです
フィードリーダーは、できるだけ少ない作業で必要な情報を抽出できるべきです。フィードへの変更や追加は、できる限り幅広く有用であるべきであり、フィードリーダーが実装しなければならないコードパスの数を最小限に抑える必要があります。(ただし、作成の容易さを優先すべきです。最終的にはフィードリーダーよりもフィード発行者の方が多くなるためです。)

仕様は乗客向け情報に関するものです
GTFS は主に乗客向けの情報を対象としています。つまり、仕様にはまず第一に乗客向けツールを支援できる情報を含めるべきです。交通事業者がシステム間で内部的にやり取りしたい運用指向の情報は大量に存在する可能性がありますが、GTFS はその目的のためのものではなく、他の運用指向のデータ標準の方が適している場合があります。

仕様の変更は後方互換性を保つべきです
仕様に機能を追加する際には、既存のフィードを無効にしてしまうような変更は避けたいと考えています。既存のフィード発行者に対して、彼らがフィードに新しい機能を追加したいと思うまで余計な作業を課したくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。

推測的な機能追加は推奨されません
新しい機能を追加するたびに、フィードの作成と読み取りの複雑さが増します。そのため、本当に有用であると分かっている機能のみを追加するよう注意する必要があります。理想的には、提案は実際の交通システム向けに新機能を用いたデータを生成し、それを読み取り表示するソフトウェアを作成してテストされているべきです。なお、GTFS は公式のパーサーやバリデータによって無視される追加のカラムやファイルを通じてフォーマットを拡張できるため、提案は既存のフィード上で容易にプロトタイプ化・テストすることが可能です。