Loading article…
 | |
| ファイル名拡張子 |
。ジップ |
|---|---|
| 開発者 | グーグル |
| 初回リリース | 2006年9月27日 |
| フォーマットの種類 | 交通スケジュールの形式 |
| 延長 | CSVファイル |
| 標準 | 事実上の標準 |
| オープンフォーマット? | はい、CC BY 3.0 |
| Webサイト | gtfs.org |
GTFS（General Transit Feed Specific）は、公共交通機関のスケジュールと関連する地理情報の共通データ形式を定義します。 [1] GTFSには、公共交通機関のサービスに関する静的またはスケジュールされた情報のみが含まれており、サービスのリアルタイムステータスに関する情報を共有する方法を定義するGTFSリアルタイム拡張機能と区別するために、 GTFS静的またはGTFSスケジュールと呼ばれることもあります。[1] [2]
歴史
GTFSとなるものは、 2005年にGoogle社員のクリス・ハレルソンのサイドプロジェクトとして始まりました。ハレルソンは「オレゴン州ポートランドの交通機関TriMetのITマネージャーであるティムとビビアナ・マクヒュー夫妻から話を聞いて、交通データをGoogleマップに組み込む方法を試行錯誤していました」 [3]。マクヒューは、当時人気のマッピングサービスがすでに使いやすい運転ルート案内を提供していたにもかかわらず、見知らぬ都市で交通ルート案内を見つけることに不満を抱いていたと言われています。[4]
ビビアナとティム・マクヒューは最終的にグーグルと連絡を取り、同社にトライメットのスケジュールデータのCSVエクスポートを提供した。2005年12月、ポートランドはグーグルの「トランジット・トリップ・プランナー」の最初のバージョンに掲載された最初の都市となった。 [5] 2006年9月、さらに5つの米国の都市がグーグル・トランジット・トリップ・プランナーに追加され、データ形式はグーグル・トランジット・フィード仕様としてリリースされた。[6]
米国では、GTFSが登場する前は公共交通機関の時刻表の標準は存在せず、事実上の標準さえありませんでした。長年BARTのウェブサイト管理者を務めたティモシー・ムーア氏によると、GTFSが登場する前、BARTはさまざまなデータ利用者にさまざまなフォーマットを提供する必要があり、標準化された交通フォーマットが非常に望まれていました。[3]公開され無料で利用できるフォーマット仕様とGTFSスケジュールの利用可能性により、開発者はすぐに交通関連のソフトウェアをこのフォーマットに基づいて開発するようになりました。その結果、「何百もの便利で人気のある交通アプリケーション」[4]や、利用可能なGTFSフィードをリストしたカタログが生まれました。これらのアプリケーションが準拠するデータフォーマットは共通であるため、ソリューションを1つの交通事業者向けにカスタマイズする必要はなく、GTFSフィードが利用可能な地域であればどこにでも簡単に拡張できます。
このフォーマットは広く使用されているため、元の名前の「Google」の部分は「一部の潜在的なユーザーがGTFSの採用をためらう原因になる」誤った名称であると見なされました。その結果、2009年に仕様の名前をGeneral Transit Feed Specific（一般交通フィード仕様）に変更することが提案されました。 [7]
アプリケーション
旅程計画
GTFS は、通常、マルチモーダルな 旅程プランナーアプリケーションで使用する公共交通機関のデータを提供するために使用されます。ほとんどの場合、GTFS は、道路/歩行者ネットワークの詳細な表現と組み合わされ、停留所間だけでなく、ポイントからポイントへのルーティングが可能になります。このデータは、遅延、キャンセル、変更された旅行をリアルタイムの旅程プランニング クエリに組み込むために、GTFS-Realtime を使用して拡張されることがよくあります。OpenTripPlanner は、GTFS とOpenStreetMapデータを組み合わせて旅程プランニングを行うことができるオープンソース ソフトウェアです。 [8] ArcMap Network Analyst 拡張機能など、他の汎用アプリケーションも存在し、GTFS を交通ルーティングに組み込むことができます。[9]
GTFS はもともと、オンラインのマルチモーダル旅程計画アプリケーションである Google Transitで使用するために設計されました。
アクセシビリティ研究
GTFSは交通アクセスの調査でよく使われ、通常、一日のさまざまな時間帯に、ある地点から他の多くの地点までの交通機関による移動時間を推定するために使用されます。[10] [11]しかし、研究では、信頼性の問題や定期的なスケジュール不遵守を考慮せずにスケジュールのみに依存しているため、このようなアプリケーションには疑問が投げかけられています。[12]
サービスレベルの比較
GTFSは、実際の[13]または提案された[14]交通サービス提供の変更によるアクセシビリティの変化を測定するために使用されてきました。時間の経過に伴うサービスの変化の分析は、同じ機関の異なる期間に公開されたGTFSデータを比較するだけで実行できます。既存のサービスと提案されたインフラストラクチャまたはサービスの変更を比較するには、提案されたサービス特性に基づいて将来のGTFSを手動で構築する必要がある場合がよくあります。[14]
フィードレジストリ
公開 GTFS フィードは、さまざまなフィード レジストリに集約されています。
- モビリティ データベース (2023 年 - 現在) は、GTFS およびGTFS リアルタイムフィードのディレクトリと、フィード コンテンツを閲覧するためのインタラクティブな Web サイトを管理していた TransitFeeds (2013 年 - 2024 年) を基盤としています。
- Transitland (2014 年 - 現在) は、55 か国以上の GTFS およびGTFS リアルタイムフィードのディレクトリを管理し、フィード コンテンツを照会するためのインタラクティブな Web サイトと API の両方を提供しています。Transitland は元々 Mapzenによって作成され、現在は Interline Technologies によって管理されています。
- GTFS データ交換 (2008 ～ 2016) により、あらゆる規模の公共交通機関が GTFS フィードのコピーをアップロードできるようになりました。この Web サイトは現在はアクティブではありません。
構造
GTFS フィードは、 .zipファイル内に含まれる6 個以上 13 個以下のCSVファイル (拡張子.txt )のコレクションです。推奨される文字エンコードはUTF-8です。関連する CSV テーブルは、乗客に表示される交通システムのスケジュールされた運行を記述します。この仕様は、旅行計画機能を提供するのに十分なように設計されていますが、サービス レベルや一般的なパフォーマンス測定の分析など、他のアプリケーションにも役立ちます。TransmodelやVDV -45X などのヨーロッパの交通業界交換標準とは対照的に、GTFS には、乗客に配布されることを目的としたスケジュールされた運行のみが含まれています。また、スケジュールされた情報に限定されており、リアルタイム情報は含まれていません。ただし、リアルタイム情報は、関連するGTFS リアルタイム仕様に従って GTFS スケジュールに関連付けることができます。[1] [2]
以下に、有効な GTFS データ フィードに必要なテーブルの説明を示します。各テーブルは文字通りテキストCSV ファイルであり、ファイル名はテーブル名に「.txt」という接尾辞が付きます。したがって、以下の「agency」テーブルの場合、「agency.txt」という CSV ファイルが有効な GTFS フィードに含まれます。
必須テーブル
代理店
交通機関テーブルには、名前、Web サイト、連絡先情報など、交通機関に関する情報が記載されています。
必須フィールド:
- 代理店名
- 代理店URL
- 代理店のタイムゾーン
ルート
ルート テーブルは、個別のルートを識別します。これは、複数のルーティング (またはパス) が 1 つのルートに属する可能性がある個別のルーティングとは区別されます。
必須フィールド:
- route_id (主キー)
- ルート短縮名
- ルートの長い名前
- ルートタイプ
- 背景色
- 前景色
旅行
必須フィールド:
- trip_id (主キー)
- route_id (外部キー)
- service_id (外部キー)
オプションフィールド:
- block_id - ブロック ID は、旅行が属するスケジュール ブロックを示します。
停止時間
必須フィールド:
- stop_id (主キー)
- trip_id (外部キー)
- 到着時間
- 出発時間
- ストップシーケンス
停車時間は到着時間と出発時間の差によってモデル化される可能性があることに注意してください。ただし、多くの機関はほとんどの停車地の停車時間をモデル化していないようです。 [オリジナル調査? ]
停止
停留所テーブルは、交通システム内の実際の停留所または駅の地理的位置と、オプションでそれらの停留所に関連付けられているアメニティの一部を定義します。
必須フィールド:
- stop_id (主キー)
- ストップ名
- ストップロン
- 停止_lat
カレンダー
カレンダー テーブルは、たとえば平日毎日のように定期的に実行されるサービス パターンを定義します。1 回限りの特別なイベントなど、繰り返されないサービス パターンは、calendar_dates テーブルで定義されます。
必須フィールド:
- service_id (主キー)
- 月曜日
- 火曜日
- 水曜日
- 木曜日
- 金曜日
- 土曜日
- 日曜日
- 開始日
- 終了日
オプションテーブル
カレンダーの日付
カレンダー日付は、calendar.txt ファイルに例外を追加するオプションのテーブルです。これにより、休日サービスなどの日数を追加したり、日数を削除したりできます。ファイルには、サービス ID、日付、例外タイプ (追加または削除) の 3 つの列のみが含まれます。このテーブルに追加するために、サービス ID が calendar.txt ファイル内にある必要はありません。
運賃属性
運賃規則
形状
交通機関のルートを表すために地図上に線を引くためのルール。
周波数
この表は、サービス頻度が変動するルートの運転間隔（運行間隔）を指定します。
転送
路線間の乗り換え地点での接続に関するルール。
フィード情報
オプションでフィード開始日とフィード有効期限を設定できます。 機関は数日先のフィードを公開する場合があります。 そのため、旅程計画ソフトウェア アプリケーションは、複数のフィード バージョンと、特定の日または時間に適したフィードを保持します。
翻訳
翻訳テーブルは、table_name、field_name、field_value、record_id、record_sub_id、language、translation の列で構成されます。翻訳はそれぞれのテーブルに分割され、任意のテキスト フィールドまたは URL を翻訳できます。GTFS の翻訳では、キー値テーブルで 2 種類のキーが使用されます。record_id は、stop_id や trip_id などのフィールドの ID を使用し、field_value は、field_name の元のコンテンツに一致する値です。stop_times などの 2 つの値のタプルを使用するテーブルでは、タプルを表すために record_id と record_sub_id が使用されます。翻訳列は出力です。
参照
参考文献
- ^ abc 「GTFS Static Overview」。GoogleDevelopers 。 2022年9月29日時点のオリジナルよりアーカイブ。2022年9月29日閲覧。
- ^ ab “GTFS Realtime Overview”. GoogleDevelopers . 2022年9月29日時点のオリジナルよりアーカイブ。2022年9月29日閲覧。
- ^ ab Roush, Wade (2012). 「Google トランジットへようこそ: 検索大手が公共交通機関を再マッピングする方法 (および理由)」(PDF)。コミュニティ交通: 3 。2016 年3 月 14 日閲覧。
- ^ ab ダイソン、ローレン; ゴールドスタイン、ブレット; ネマニ、アビ (2013)。透明性を超えて。コード・フォー・アメリカ・プレス。pp. 125–135。CiteSeerX 10.1.1.674.6114。
- ^ Garg, Avichal. 「Public Transit via Google」。公式 Google ブログ。2016 年 3 月 24 日時点のオリジナルよりアーカイブ。2016年3 月 14 日閲覧。
- ^ Harrelson, Chris. 「Happy Trails with Google Transit」。公式 Google ブログ。2016 年 3 月 24 日時点のオリジナルよりアーカイブ。2016年3 月 14 日閲覧。
- ^ ヒューズ、ジョー。「提案：GTFSの名前から「Google」を削除します」。一般的な交通フィード仕様の変更。Googleグループ。2022年9月29日時点のオリジナルよりアーカイブ。 2016年3月14日閲覧。
- ^ “Home | OpenTripPlanner”. www.opentripplanner.org . 2017年5月8日時点のオリジナルよりアーカイブ。 2017年5月12日閲覧。
- ^ 「Yay, transit! - ArcGIS Network Analyst で GTFS データを使用する」. transit.melindamorang.com . 2017 年 5 月 19 日時点のオリジナルよりアーカイブ。2017 年5 月 12 日閲覧。
- ^ ファーバー、スティーブン、モラン、メリンダ Z.、ワイドナー、マイケル J. (2014 年 9 月 1 日)。「スーパーマーケットへの交通アクセスの一時的変動」。応用地理学。53 :149–159。Bibcode :2014AppGe..53..149F。doi : 10.1016 / j.apgeog.2014.06.012。
- ^ フランセン、クース;ノイテンス、ティジス;ファーバー、スティーブン。デ・マイヤー、フィリップ。デロイター、こんにちは。フランク・ウィトロックス（2015年10月1日）。 「時間依存のアクセシビリティレベルを使用して公共交通機関のギャップを特定する」。交通地理学ジャーナル。48 : 176–187。Bibcode :2015JTGeo..48..176F。土井：10.1016/j.jtrangeo.2015.09.008。hdl : 1854/LU-6956461。
- ^ Wessel, Nate; Allen, Jeff; Farber, Steven (2017年6月1日). 「リアルタイム車両位置フィードとGTFSからのルート可能な遡及的交通時刻表の構築」. Journal of Transport Geography . 62 : 92–97. Bibcode :2017JTGeo..62...92W. doi :10.1016/j.jtrangeo.2017.04.012. ISSN 0966-6923.
- ^ Farber, Steven; Fu, Liwei (2017年3月1日). 「旅行時間キューブを使用した動的な公共交通機関のアクセシビリティ：インフラストラクチャの投資（不投資）の影響を時間経過とともに比較する」.コンピューター、環境、都市システム. 62 : 30–40. Bibcode :2017CEUS...62...30F. doi :10.1016/j.compenvurbsys.2016.10.005.
- ^ ab Farber, Steven; Grandez, Maria (2017). 「交通アクセス性、土地開発、社会経済的優先順位: グレータートロントおよびハミルトン地域の計画された駅集水域の類型」( PDF)。交通および土地利用ジャーナル。10 (1). doi :10.5198/jtlu.2017.980. (注記: 近日公開予定)。
この記事には、Stefan Kaufmann 著「ドイツにおける公共交通機関データの公開」からの抜粋が含まれており、Creative Commons Attribution 3.0 unported ライセンスに基づいて利用できます。
外部リンク
- GTFS仕様に関するGoogleドキュメント
- GTFSの歴史
- GTFS ツール
- MobilityData が管理する GTFS リソース センター
- TransitWiki の一般的な交通フィード仕様に関する記事。歴史、用途とアプリケーション、制作方法、ベスト プラクティスが記載されています。