基本方針

GTFS リアルタイムの当初のビジョンを失わないように、この仕様を拡張する際に考慮すべきいくつかの基本方針が確立されてきました。

フィードをリアルタイムで効率的に生成、利用できること。

リアルタイム情報は動的で絶え間のないデータの流れであり、効率的に処理することが必要不可欠です。そこで Google では、この仕様のベースとしてプロトコルバッファを選びました。それは、デベロッパーにとっての使いやすさとデータ転送の効率のよさという点でうまくバランスがとれるためです。GTFS と異なり、GTFS リアルタイムフィードを手作業で編集する交通機関はそれほど多くはないと考えられます。ほとんどの GTFS リアルタイムフィードがプログラムで生成、利用されるであろうという結論から、プロトコルバッファを選択しました。

乗客に関係する情報を扱うこと。

GTFS リアルタイムは、先に策定された GTFS と同じく、一義的には乗客に必要な情報に関する仕様です。つまり、何よりもまず、乗客にとって役立つ情報が含まれていなければなりません。潜在的には、交通機関同士で内部的に伝送できる業務用の情報が多数存在しています。GTFS リアルタイムはそうした目的を意図したものではありません。他の業務用データの規格があれば、業務用の情報にはその方が適している可能性があります。

仕様の変更に後方互換性を持たせること。

仕様に機能を追加する際、既存のフィードが無効になるような変更は避ける必要があります。既存のフィード提供者がフィードに機能を追加するときに余計な作業が増えることは好ましくありません。また可能な限り、更新後のフィードの以前の部分を既存のパーサーで引き続き読み込めるようにする必要があります。既存のプロトコルバッファの慣例では、ある程度は後方互換性が強制的に適用されます。ただし、既存のフィールドに意味的な変更を加えると後方互換性がなくなる可能性があるため、そのような変更も避けることが求められます。

未確認の機能の追加は控えること。

新機能が追加されれば必ず、フィードの作成や読み込みが以前より複雑になります。したがって、効果があると確認できている機能のみを追加するように気をつけなければなりません。どの提案も、その新機能を利用する実際の交通機関用のデータを生成し、その読み取りと表示ができるソフトウェアを作成してテストしてみることが理想的です。

この仕様では、新機能をサポートするために、次のセクションで説明する拡張機能を利用できます。GTFS リアルタイムの制作者と利用者は、拡張名前空間で先に新機能をテストすることができます。採用されることが決まると、正式な GTFS リアルタイムプロトコル定義にこの機能が追加されます。