GTFS Schedule¶

GTFS 仕様は固定されたものではありません。GTFS を使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されるオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。そのプロセスを管理するために、次の手順とガイドラインが確立されています。

公式の仕様、リファレンス、ドキュメントは英語で書かれています。別の言語への翻訳が英語のオリジナルと異なる場合は、後者が優先されます。すべてのコミュニケーションは英語で行われます。

仕様修正プロセス¶

1.プロトコル定義、仕様、ドキュメントファイル (翻訳を除く) の関連部分をすべて更新した git ブランチを作成します。 1. https://github.com/google/transit でpull requestを作成します。プルリクエストには、パッチの詳細な説明を含める必要があります。pull requestの作成者が_提唱者_になります。 1.pull requestが登録されたら、提唱者はpull requestへのリンクを含めて GTFS 変更メーリングリストで発表する必要があります。発表されると、pull requestは提案と見なされます。pull requestは、簡単に相互参照できるように、Google グループの発表へのリンクを含むように編集する必要もあります。 - 提唱者は貢献者であるため、pull requestが承認される前に貢献者ライセンス契約に署名する必要があります。 1.提案について次に説明します。プルリクエストのコメントは、唯一のディスカッションフォーラムとして使用する必要があります。 - ディスカッションは、アドボケートが必要と考える限り続きますが、少なくとも 7 暦日間は継続する必要があります。 - アドボケートは、同意したコメントに基づいて、提案 (pull request) をタイムリーに更新する責任があります。 - アドボケートは、いつでも提案を放棄したと主張できます。 1.アドボケートは、ディスカッションに必要な最初の 7 日間の期間が経過した後、いつでも提案のバージョンに対する投票を呼びかけることができます。 - 投票を呼びかける前に、少なくとも 1 人の GTFS プロデューサーと 1 人の GTFS コンシューマーが提案された変更を実装する必要があります。 GTFS プロデューサーは、一般向けの GTFS フィードに変更を組み込み、pull requestのコメント内にそのデータへのリンクを提供することが求められます。また、GTFS コンシューマーは、pull requestのコメント内に、変更を重要な方法で利用しているアプリケーション (つまり、新しい機能または改善された機能をサポートしているアプリケーション) へのリンクを提供することが求められます。 1.投票は、14 暦日間をカバーするのに十分な最短期間続きます。投票は 23:59:59 UTC に終了します。 - アドボケートは、投票開始時に具体的な終了時刻を発表する必要があります。 - 投票期間中は、提案に対する編集上の変更のみが許可されます (意味が変わらない限り、タイプミスや文言の変更は可能です)。 -pull requestへのコメントの形式で、誰でも賛成/反対の投票を行うことができ、投票は投票期間の終了まで変更できます。投票者が投票を変更する場合は、元の投票コメントを更新して、投票を取り消し線で消して新しい投票を記入することをお勧めします。 - 投票期間開始前の投票は考慮されません。 - 投票の開始と終了は、GTFS 変更メーリングリストで発表する必要があります。 1.少なくとも 3 票の賛成で全員一致の同意が得られた場合、提案は承認されます。 - 提案者の投票は、投票の合計は 3 票です。たとえば、提案者 X がpull requestを作成して賛成票を投じ、ユーザー Y と Z が賛成票を投じた場合、賛成票の合計は 2 票としてカウントされます。 - 反対票は、根拠を示し、できれば実用的なフィードバックを提供する必要があります。 - 投票が否決された場合、アドボケートは提案の作業を続行するか、提案を放棄するかを選択できます。アドボケートのどちらの決定も、GTFS 変更メーリングリストで発表する必要があります。 - アドボケートが提案の作業を続行する場合は、いつでも新しい投票を呼びかけることができます。 1. 30 暦日間非アクティブのままになっているpull requestはすべてクローズされます。pull requestがクローズされると、対応する提案は放棄されたものとみなされます。アドボケートは、会話を継続または維持したい場合は、いつでもpull requestを再開できます。 1.提案が承認された場合: - Google は、投票されたバージョンのpull requestをマージし (貢献者が CLA に署名している場合)、5 営業日以内にpull requestを実行することに尽力します。 - 元のpull requestに翻訳を含めることはできません。 Google は、サポートされている言語に関連する翻訳を最終的に更新する責任を負いますが、コミュニティからの純粋な翻訳のプルリクエストは歓迎されており、すべての編集コメントに対応次第受け入れられます。 1.pull requestの最終結果 (承認または放棄) は、pull requestが最初に発表された同じ Google グループスレッドで発表する必要があります。

基本原則¶

GTFS の当初のビジョンを維持するために、仕様を拡張する際に考慮すべきいくつかの基本原則が確立されています。

フィードは簡単に作成および編集できる必要があります
CSV を仕様のベースとして選択したのは、スプレッドシートプログラムやテキストエディタを使用して簡単に表示および編集できるため、小規模な代理店にとって便利だからです。また、ほとんどのプログラミング言語やデータベースから簡単に生成できるため、大規模なフィードを発行するパブリッシャーにとっても便利です。

フィードは簡単に解析できる必要があります
フィードリーダーは、できるだけ少ない作業で、探している情報を抽出できる必要があります。フィードへの変更や追加は、フィードリーダーが実装する必要のあるコードパスの数を最小限に抑えるために、できるだけ幅広く役立つものにする必要があります。(ただし、最終的にはフィードリーダーよりもフィードパブリッシャーの数が多くなるため、作成を容易にすることが優先されます。)

この仕様は乗客情報についてです
GTFS は主に乗客情報に関係しています。つまり、仕様には、何よりもまず乗客のパワーツールに役立つ情報が含まれている必要があります。交通機関がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性があります。GTFS はその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能性があります。

仕様の変更は下位互換性を保つ必要があります
仕様に機能を追加する際、既存のフィードが無効になるような変更は避けたいと考えています。既存のフィードパブリッシャーがフィードに機能を追加したいと思うまで、作業を増やしたくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。

推測的な機能は推奨されません
新機能が追加されるたびに、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能のみを追加するように注意する必要があります。理想的には、新機能を使用する実際の交通機関のデータを生成し、それを読み取り、表示するソフトウェアを作成して、すべての提案をテストする必要があります。GTFS では、公式のパーサーと検証ツールによって無視される追加の列とファイルを追加することで、形式を簡単に拡張できるため、提案を簡単にプロトタイプ化して既存のフィードでテストできます。