仕様の修正プロセス¶

GTFS仕様は確定したものではありません。その代わり、GTFSを使用する交通機関、開発者、その他の関係者のコミュニティによって開発・維持されるオープンな仕様となっています。GTFSデータの生産者と消費者からなるこのコミュニティは、新しい機能を実現するために仕様の拡張を提案することが期待されています。そのようなプロセスを管理するために、以下の手順とガイドラインが設定されています。

本仕様書、参考資料、ドキュメント類は英語で書かれています。他言語へのTranslation英語の原文と異なる場合は、後者が優先されます。すべてのコミュニケーションは英語で行われます。

プロトコル定義、仕様書、ドキュメントファイルの関連部分をすべて更新したgitブランチを作成する(翻訳を除く)。
https://github.com/google/transit にプルリクエストを作成します。プルリクエストには、パッチの拡張説明を含める必要があります。プルリクエストの作成者は、_支持_者になります。
プルリクエストが登録されたら、その支持者によって、GTFS Changes メーリングリストに、プルリクエストへのリンクを含めて発表されなければなりません。発表された時点で、そのプルリクエストは提案とみなされます。また、プルリクエストは、Googleグループでの発表へのリンクを含むように編集され、簡単に相互参照できるようにする必要があります。
提唱者は貢献者であるため、プルリクエストを受け入れる前に貢献者ライセンス契約に署名しなければなりません。
提案の議論は以下の通りです。プルリクエストコメントを唯一の議論の場として使用する。
議論は提唱者が必要と感じる限り続きますが、少なくとも7暦日以上でなければなりません。
提案者は、自分が同意したコメントに基づいて、提案 (すなわちプルリクエスト) を適時に更新する責任があります。
提唱者は、いかなる時点でも提案の放棄を主張することができます。
提唱者は、議論に必要な最初の7日間の間隔が経過した後の任意の時点で、その提案のバージョンに対する投票を要求することができます。
投票を求める前に、少なくとも1つのGTFSの生産者と1つのGTFSの消費者が、提案された変更を実行する必要があります。また、GTFS利用者は、プルリクエスト・コメントにおいて、その変更を自明ではない方法で利用している(すなわち、新機能または改良機能をサポートしている)アプリケーションへのリンクを提供することが期待されています。
投票は暦の上では7日、スイスの営業日では5日をカバーするのに十分な最小限の期間だけ行われます。投票は 23:59:59 UTC に終了します。
投票者は投票開始時に具体的な終了時刻を発表すべきです。
投票期間中は、提案の編集上の変更のみが許されます (誤字脱字、意味を変えない限り文言の変更は可能です)。
誰でもプルリクエストにコメントする形で賛成・反対を投票することができ、投票期間の終了まで投票を変更することができます。投票者が投票を変更する場合、元の投票コメントを取り消し、新しい投票を書き込むことで更新することが推奨されます。
投票期間開始前の投票は考慮されません。
投票の開始と終了は、GTFS Changes メーリングリスト上で告知されなければなりません。
提案は、少なくとも3票を投じて全会一致の賛成が得られた場合に受理されます。
提案者の票は3票の合計にカウントされません。たとえば、提案者Xがプルリクエストを作成して賛成票を投じ、ユーザYとZが賛成票を投じた場合、合計で2票の賛成票としてカウントされます。
反対票は動機付けされたものでなければならず、理想的には実行可能なフィードバックを提供するものでなければなりません。
投票が失敗した場合、支持者はその提案の作業を継続するか、あるいはその提案を放棄するかを選ぶことができます。提唱者のいずれの決定も、GTFS Changes メーリングリストにおいて発表されなければならない。
提唱者が提案の作業を継続する場合、いつでも新しい投票を呼びかけることができます。
30暦日間、非アクティブのままのプルリクエストはクローズされます。プルリクエストが閉じられると、対応する提案は放棄されたとみなされます。提唱者は、会話を継続または維持したい場合、いつでもプルリクエストを再開することができます。
提案が受理された場合
Googleは、投票されたバージョンのプルリクエストをマージし（貢献者がCLAに署名していることが条件です）、5営業日以内にプルリクエストを実行することを約束します。
翻訳は、元のプルリクエストに含めてはいけません。 Google は最終的に関連する翻訳をサポートされている言語に更新する責任がありますが、コミュニティからの純粋な翻訳プルリクエストは歓迎され、すべての編集コメントが対処され次第、受理される予定です。
プルリクエストの最終結果（受理または放棄）は、プルリクエストが最初に発表されたのと同じGoogleグループのスレッドで発表されるべきです。

指導方針¶

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

フィードの作成と編集が容易であること
CSVを仕様のベースとして選んだのは、表計算ソフトやテキストエディタで簡単に表示・編集できるため、小規模な機関にとって
便利だからです。
また、ほとんどのプログラミング言語やデータベースから簡単に生成できるため、大規模なフィードを発行する場合にも適しています。

フィードの解析が容易であることフィードの
読者は、できるだけ少ない作業で求めて
いる情報を抽出できる必要があります。
フィードの変更や追加は、できるだけ広範囲に渡って有用であるべきで、フィードの読者が実装しなければならないコードパスの数を最小にしなければなりません。(ただし、最終的にはフィードの発行者がフィードの読者よりも多くなるため、作成を簡単にすることが優先されるべきです)。

旅客情報についての仕様であること
GTFSは、旅客情報を主な対象として
います。
つまり、ライダーのためのパワーツールに役立つ情報を、まず第一に仕様に盛り込むべきである。交通機関がシステム間で内部的に伝送したいと考える運用志向の情報は、潜在的に大量に存在する可能性があります。GTFSはそのためのものではなく、より適切な他のオペレーション指向のデータ標準が存在する可能性がある。

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

投機的な機能は推奨されない
新しい機能を追加するたびに、フィードの作成と読み込みが複雑に
なります。
したがって、有用であることが分かっている機能のみを追加するように注意したいと思います。理想的には、どのような提案であっても、その新機能を使用する実際の交通システムのデータを生成し、それを読み込んで表示するソフトウェアを作成することによって、テストされている必要があります。GTFSは、公式のパーサーやバリデーターが無視するような列やファイルを追加することで、フォーマットの拡張を容易に行えることに留意してください。

改訂履歴¶

2023年3月14日

運賃メディアを追加しました。ディスカッションをご覧ください。

2022年7月26日

座席内オプションでトリップ間移動ができるようになりました。ディスカッションを参照。

2022年5月17日

GTFS-Fares V2ベースの実装。ディスカッションを参照。

2021年10月22日

プライマリおよびフォーリンidフィールドを追加しました。ディスカッションを参照。

2021年10月05日

トリップ間、ルート間の転送を追加しました。ディスカッションを参照。

2021年9月15日

運賃ゲート（pathway_mode=6）が双方向であることを許可しました。ディスカッションを参照してください。

2021年9月13日

stop_nameベストプラクティスを更新しました。ディスカッションを参照。

2021年8月27日

GTFSスケジュールをRFC2119に更新しました。ディスカッションを参照。

2021年1月4日

stop_times.stop_id記述を明確化しました。詳細については、「ディスカッション」を参照してください。
正と非ゼロのフィールド符号を定義した。ディスカッション参照。

2020年10月2日

frequencies.headway_secsフィールドタイプを非負の整数から正の整数に変更しました。ディスカッションを参照してください。

2020年5月25日

pathways.txt、levels.txt、attributions.txt翻訳可能なテーブルとして定義しました。多言語のsignposted_as値を翻訳するための推奨事項を追加しました。ディスカッションを参照してください。

2020年5月13日

routes.txt stop_times.txt continuous_pickup continuous_drop_off追加しました。shape_id"Optional "から "Conditionally required "に変更しました。ディスカッションを参照。

2020年3月24日

音声合成のフィールドを定義し、stops.txt tts_stop_name追加しました。ディスカッション参照。

2020年2月5日

トロリーバス、モノレールのroute_types追加しました。ディスカッション参照。

2020年1月9日

translations.txt追加しました。ディスカッション参照。

2019年12月26日

route_typecable tramとaerial liftの定義を更新しました。議論参照。

2019年12月20日

attributions.txt追加しました。ディスカッション参照。

2019年8月26日

stop_lat stop_lon乗客が乗車するために待つ場所に配置されるように指定した。ディスカッション参照。

2019年7月9日

到着時刻と出発時刻のベストプラクティスを追加しました。ディスカッション参照。
ヘッドサインのベストプラクティスを追加しました。考察を参照。
stop_idベストプラクティスを追加。ディスカッションを参照してください。

2019年6月25日

シェイプポイントとストップの関係を明確にしました。ディスカッションを参照してください。

2019年4月4日

stops.txt platform_codeフィールドを追加しました。ディスカッションを参照。

2019年3月27日

pathways.txt levels.txtを追加しました。ディスカッションを参照。

2019年2月6日

編集と書式を明確化するための変更。議論を参照。

2018年10月2日

因数分解されたフィールドタイプ。説明を参照。

2018年9月14日（金

"Conditionally required"の概念を追加。説明を参照。

2018年9月4日

agency_lang feed_lang定義を統一しました。議論を参照。

2018年8月27日（木

CHANGES.md最終更新日を更新。考察を参照。

2018年8月22日（金

feed_info.txt feed_contact_email feed_contact_urlフィールドを追加しました。ディスカッションを参照してください。

2017年12月11日（木

routes.txt route_sort_order追加しました。議論を参照。

2017年3月15日（木

提案者の投票が合計にカウントされないことを明確にした。議論参照。
投票を呼び出す前に、少なくとも1つのGTFSプロデューサーと1つのGTFSコンシューマーが変更案を実装している必要があることを規定した。議論参照。

平成29年2月7日

block_id service_id関係を明確にした。考察を参照。
頻度ベースのサービスは車両出発時に開始されることを明確化。考察参照。
stop_id stop_code表記を明確にした。ディスカッション参照。

2017年12月11日（木

routes.txt route_sort_orderフィールドを追加しました。ディスカッション参照。

2016年11月27日（金

stops.location_type駅入口を追加しました。ディスカッション参照。

2016年9月2日（金

fare_attributes.txt下にagency_id追加するようにドキュメントを更新しました。ディスカッションを参照してください。

2016年3月16日（金

GTFSのドキュメントをGithub（https://github.com/google/transit）へ移行。

2016年2月3日（金

agency.txt agency_email追加仕様への提案：議論

2015年2月2日（金

stop_times.txt 'timepoint'案を仕様に追加:ディスカッション

2014年2月17日

trips.txt 'bikes_allowed' の提案を仕様に追加：議論

2012年10月15日

trips.txt の 'wheelchair_accessible' 提案を仕様に追加：議論

2012年6月20日

wheelchair_boarding」案を仕様書に追加：議論

2012年2月2日

stop_timezone」案をspec:discussionに追加。

2012年1月18日

古いcode.google.comから新しいdevelopers.google.comにドキュメントを移行しました。

2011年9月26日

仕様書に'feed_info'案を追加：議論

2011年9月6日

仕様書に'agency_fare_url'案を追加：議論
仕様に'exact_times'案を追加：議論

2009年3月30日

トランジットフィードを一般に公開するための新しいセクションです。これは、厳密にはデータの解釈や書き方を変えるものではないので、以前はグループ内で議論されていませんでした。しかし、GTFS形式のデータを利用できるアプリケーションは増えているため、Google以外のGTFSの利用方法についての議論を含めることは有益であると、Googleの一部の人々は考えたのです。
CSV形式の明確化：検討
route_color および route_text_color フィールドの説明に、対照的な色を選択する方法に関するガイダンスを追加しました。
trip_short_name は、以下のスレッドで提案され、テストされています: a と b。
ドキュメントの最後に含まれるサンプルデータの小さな誤り（停留所S7にparent_station S8を与える）の修正。
コメント期間中にMarcyから提案された、ドキュメント末尾のサンプルデータへの「agency_lang」情報の追加：議論。
サイドバーのOCTAのGTFSフィードへのリンクを更新しました。
元の要約を参照。

2009年2月26日

現時点ではGTFSデータを消費する他の多くのアプリケーションが存在するため，Google固有のフィード送信に関する説明の大部分を削除しました．
サイドバーのオレンジ郡OCTAの公開フィードへのリンクが壊れていたのを修正。

2008年8月7日

8月6日のバージョンで誤って省略されたstop_urlフィールドを復活させました。
サンプルデータに agency_phone を追加
Googleにフィードを送信する際に、データ利用規約について言及するようにしました。

2008年8月6日

transfers.txtファイルを追加し、フィード発行者が好ましい転送動作に関するヒントを提供できるようにした(原案)
stops.txtにlocation_typeとparent_stationフィールドを追加し、停車駅を駅にグループ化できるようにした(原案)
代理店の音声電話番号を提供するためのagency_phoneフィールドを追加（原案）。
オープンソースのテストツールについて言及した「Testing Your Feeds」セクションを追加
CSVフォーマット、agency_timezone、agency_lang、route_color、route_text_color、arrival_time、 departure_time、calendar.txt vs. calendar_dates.txt 、 fare tables、 frequencies.txt について説明文を追記しました。
フィード履歴のドキュメントへのリンクを追加し、一部の公開フィードのリンクを修正しました。
現在のGoogle Maps UIを表現するためにサンプル画像を更新
ドキュメント内のサンプルデータを更新・修正

2008年2月29日

stops.txtにstop_codeフィールドを追加し、ライダー向けの停車駅コードを指定できるようにした（原案）。
routes.txtのroute_short_name、route_long_nameの記述の明確化
stop_times.txtのarrival_timeとdeparture_timeの記述を明確にしました。
サンプルデータの誤字を修正

2007年11月20日

block_idの記述の明確化
Google Transitを強調しない表現に変更（Google以外のアプリケーションもGTFSを使用しており、乗り換え案内はGoogle Mapsに統合されているため）、また誤字脱字を修正
現在のGoogle Maps UIにおけるGTFSフィールドの表示方法を反映するため、スクリーンショットの例を更新しました。
乗り換え案内データ提供者のGoogle連絡先メールアドレスを更新しました。
書式を更新

2007年10月5日

stop_sequenceとshape_pt_sequenceを変更し、非負の整数を増加させることができるようにしました。
説明文の明確化、誤字の修正

2007年5月31日

ページのスタイルを更新し、HTMLをよりすっきりさせ、よりアクセスしやすくしました。
公開されているフィードの例やその他の有用なサイトへのリンクを追加しました。
個々のフィールドの説明から例を削除

2007年4月9日

フィードの送信に関するセクションを追加
Example Demo Transit Agencyのフィードを追加。
すべてのサービスの日付がcalendar_dates.txtで定義されている場合、calendar.txtは省略可能であることを追記。
1つの機関のみを含むフィードでは、agency_idフィールドをオプションにしました。これにより、agency_id を持たない既存のフィードも有効であり続けることができる。
agency_url、stop_url、route_url の詳細な指定と、これらのフィールドの値の例を追加した。
有効な route_type の値として、6（ゴンドラ）、7（フニクラ）を追加しました。

2007年3月8日

2月28日のアップデートでstop_urlフィールドが誤って指定されていたstop_times.txtからstops.txtに移動するマイナーエディットを行いました。

2007年3月5日

route_long_nameフィールドの説明をより明確にするためのマイナー編集を行いました。

2007年2月28日

ヘッドウェイベースのスケジュールサポートのために、frequencies.txtを追加しました。
同じフィードに複数のエージェンシーを含めることができるようになりました。agencies.txt と routes.txt に新しい agency_id フィールドを追加し、どのルートがどのエージェンシーによって運営されているかを指定できるようにしました。
ルート単位、停留所単位のURLを追加しました。
trips.txtにdirection_idフィールドを追加。
stop_times.txtにstop_headsignフィールドを追加し、トリップ途中のヘッドサイン変更に対応。
routes.txtにオプションでroute_colorとroute_text_colorを追加し、ルートの色をサポート。
ストリートアドレスを使った停留所指定機能を削除した。前バージョンの仕様では、stop_street, stop_city, stop_region, stop_postcode, stop_country フィールドで、ストリートアドレスを使用して乗り換え駅の位置を指定することができました。現在は、stop_latで緯度、stop_lonで経度を指定する必要があり、この方が多くのアプリケーションで有用である。
routes.txt の route_type フィールドにケーブルカーの車種を追加した。
変更点については、Headwayブログの原案記事まとめをご覧ください。

2006年11月29日

shapes.txt によるトリップ形状情報に対応した。
stop_sequence の定義の明確化
pickup_typeとdrop_off_typeをオプションでマークするようにした

2006年10月31日

運賃情報を追加しました
個別ファイル名から日付を削除
route_type の値の定義を変更
サービス期間が重ならない限り、複数のフィードファイルを同時に掲載できるようにした
trips.txtのblock_idが正しくOptionalと表示されるよう修正
カラムヘッダは必ず含めるようにした

2006年9月29日

例題のいくつかの誤りを修正するためにマイナーな編集を行いました。

2006年9月25日

初期バージョン。