GTFS schedule¶

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

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

仕様修正プロセス¶

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

基本原則¶

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

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

フィードは簡単に解析できる必要がするべきである
フィードリーダーは、できるだけ少ない作業で、探している情報を抽出できるするべきである。するべきである。(ただし、最終的にはフィードリーダーよりもフィードパブリッシャーの数が多くなるため、作成を容易にするするべきである。)

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

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

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