GTFS Scheduleのベスト プラクティス¶
これらは、General Transit Feed Specification (GTFS) で公共交通機関のサービスを記述するための推奨プラクティスです。これらのプラクティスは、GTFS ベスト プラクティス ワーキング グループ メンバーの経験と アプリケーション固有の GTFS プラクティス推奨事項 から統合されました。
詳細な背景については、よくある質問をご覧ください。
ドキュメントの構造¶
プラクティスは、4つの主要なセクションに分かれています。
- データセットの公開と一般的なプラクティス: これらのプラクティスは、GTFSデータセットの全体的な構造と、GTFSデータセットが公開される方法に関連しています。
- ファイル別にまとめたプラクティスの推奨事項: 推奨事項は、GTFS内のファイルとフィールド別にまとめられており、プラクティスを公式のGTFSリファレンスにマッピングしやすくなっています。
- ケース別にまとめたプラクティスの推奨事項: ループルートなどの特定のケースでは、プラクティスを複数のファイルとフィールドに適用する必要がある場合があります。このような推奨事項は、このセクションにまとめられています。
データセットの公開と一般的なプラクティス¶
- データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります。(例: www.agency.org/gtfs/gtfs.zip) 理想的には、ソフトウェア アプリケーションを使用してダウンロードしやすいように、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできる必要があります。 GTFS データセットはオープンにダウンロード可能にすることが推奨されています (最も一般的な方法) が、データ プロバイダーがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することが推奨されます。
- GTFS データは反復的に公開されるため、安定した場所にある 1 つのファイルには常に、交通機関 (または複数の機関) のサービスの最新の公式説明が含まれます。
- 可能な限り、データの反復にわたって
stop_id、route_id、およびagency_idの永続的な識別子 (id フィールド) を維持します。 - 1 つの GTFS データセットには、現在のサービスと今後のサービス (
統合データセットと呼ばれることもあります) を含める必要があります。 Google トランジットフィード ツールの マージ機能 を使用すると、2 つの異なる GTFS フィードからマージされたデータセットを作成できます。- 公開された GTFS データセットは、いつでも少なくとも今後 7 日間は有効である必要があります。理想的には、運行会社がスケジュールが継続して運用されると確信している限り有効です。
- 可能であれば、GTFS データセットは少なくとも今後 30 日間のサービスをカバーする必要があります。
- フィードから古いサービス (期限切れのカレンダー) を削除します。
- サービスの変更が 7 日以内に有効になる場合は、静的な GTFS データセットではなく、GTFS-realtime フィード (サービス アドバイザリまたはルート更新) を使用してこのサービスの変更を表現します。
- GTFS データをホストするウェブサーバーは、ファイル変更dateを正しく報告するように設定する必要があります (HTTP/1.1- Request for Comments 2616、セクション 14.29 を参照してください。
ファイル別にまとめた実践推奨事項¶
このセクションでは、GTFS リファレンス に沿って、ファイルとフィールド別にまとめた実践方法を示します。
すべてのファイル¶
| フィールド名 | 推奨事項 |
|---|---|
| 大文字と小文字の混在 | 顧客向けのすべてのテキスト文字列 (停留所名、路線名、行先標識を含む) では、小文字を表示できるディスプレイ上の地名の大文字化に関するローカルな慣例に従い、大文字と小文字の混在 (すべて大文字ではない) を使用する必要があります。 |
| 例: | |
| Brighton Churchill Square | |
| Villiers-sur-Marne | |
| Market Street | |
| 略語 | 場所が略称で呼ばれている場合 (例: “JFK Airport”) を除き、フィード全体で名前やその他のテキストの略語を使用しないでください。略語は、スクリーン リーダー ソフトウェアや音声ユーザー インターフェイスによるアクセシビリティに問題が生じる可能性があります。表示用に完全な単語を略語に確実に変換するようにソフトウェアを設計することはできますが、略語から完全な単語に変換すると、エラーが発生するリスクが高くなります。 |
agency.txt¶
| フィールド名 | 推奨事項 |
|---|---|
agency_phone |
そのようなカスタマー サービス電話番号が存在しない限り、含める必要があります。 |
agency_email |
そのようなカスタマー サービス メールが存在しない限り、含める必要があります。 |
agency_fare_url |
完全に無料の旅行会社でない限り、含める必要があります。 |
例:
- バス サービスは、いくつかの小さなバス会社によって運営されています。しかし、スケジュールとチケット発行を担当し、ユーザーの観点からバス サービスを担当する 1 つの大きな会社があります。フィード内では、1 つの大きな会社を代理店として定義する必要があります。データが複数の小規模バス運行会社によって内部的に分割されている場合でも、フィードに定義される代理店は 1 つだけにする必要があります。
- フィード プロバイダーはチケット ポータルを運営しますが、実際にサービスを運営し、ユーザーに責任があることが知られている代理店は複数あります。実際にサービスを運営する代理店は、フィード内で代理店として定義する必要があります。
stops.txt¶
| フィールド名 | 推奨事項 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
stop_name |
停留所名が公開されていない場合は、フィード全体で一貫した停留所の命名規則に従います。 | ||||||||
デフォルトでは、 stop_nameにStationやStopなどの一般的な単語や冗長な単語を含めないでください。ただし、一部の例外は許可されます。
|
|||||||||
stop_latとstop_lon |
停留所の位置はできる限り正確である必要があります。実際の停留所の位置と比較して、停留所の位置の誤差は 4 メートル以内である必要があります。 | ||||||||
| 停留所の位置は、乗客が乗車する歩行者通行権のすぐ近くに配置する必要があります (つまり、道路の正しい側)。 | |||||||||
停留所の位置が別のデータ フィード間で共有されている場合 (つまり、2 つの機関がまったく同じ停留所/乗車施設を使用している場合)、両方の停留所にまったく同じstop_latとstop_lonを使用して、停留所が共有されていることを示します。 |
|||||||||
parent_stationとlocation_type |
多くの駅やターミナルには複数の乗車施設があります (モードに応じて、バス ベイ、プラットフォーム、埠頭、ゲート、またはその他の用語で呼ばれる場合があります)。このような場合、フィード作成者は、駅、乗車施設 (子停留所とも呼ばれます)、およびそれらの関係を説明する必要があります。
|
||||||||
駅や子供用停留所に名前を付ける場合は、乗客によく知られ、乗客が駅や乗車施設（バス停、プラットホーム、埠頭、ゲートなど）を識別できるような名前を付けてください。
|
routes.txt¶
| フィールド名 | 推奨事項 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
route_long_name |
仕様リファレンスの定義:この名前は、通常、 長い名前の種類の例を以下に示します。 |
|||||||||
route_long_nameにはroute_short_nameを含めないでください。 |
||||||||||
route_long_nameを入力するときは、サービス ID を含む完全な指定を含めます。例:
|
||||||||||
route_id |
指定された名前付きルート上のすべての旅行は、同じroute_idを参照する必要があります。route_id値に分割しないでください。route_id値に分割しないでください。つまり、 routes.txtにn AMサービスとnPMサービスに異なるレコードを作成しないでください。 |
|||||||||
ルート グループに明確に名前が付けられた分岐 (1A と 1B など) が含まれる場合は、ルート branches の場合の推奨事項に従って、 route_short_nameとroute_long_nameを決定します。 |
||||||||||
route_colorとroute_text_color |
標識や印刷物およびオンラインの顧客情報と一致している必要があります (したがって、他の場所に存在しない場合は含めないでください)。 |
trips.txt¶
- ループ ルートの特殊なケースを参照してください: ループ ルートは、2 つの異なる終点がある線形ルートとは対照的に、旅行が同じ停留所で開始および終了する場合です。ループ ルートは、特定のプラクティスに従って記述する必要があります。ループ ルートのケースを参照してください。
- ラッソ ルートの特殊なケースを参照してください: ラッソ ルートは、線形ジオメトリとループ ジオメトリのハイブリッドであり、車両はルートの一部のみをループして移動します。ラッソ ルートは、特定のプラクティスに従って記述する必要があります。 Lasso ルートのケースを参照してください。
| フィールド名 | 推奨事項 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
trip_headsignまたはstop_headsignフィールドにルート名 (route_short_nameおよびroute_long_nameと一致するもの) を指定しないでください。 |
||||||||||||||
ルート内の旅行を区別するために使用できる、車両のヘッドサイン上に表示される目的地、方向、およびその他の旅行指定テキストを含める必要があります。車両に表示される方向情報との一貫性は、GTFS データセットで提供されるヘッドサインを決定するための最優先の目標です。その他の情報は、この主要目標を損なわない場合にのみ含める必要があります。旅行中にヘッドサインが変更される場合は、trip_headsignをstop_times.stop_headsignで上書きします。以下に、考えられるいくつかのケースに対する推奨事項を示します。 |
|||||||||||||||
|
|||||||||||||||
ヘッドサインの先頭にToやTowardsという言葉を使用しないでください。 |
|||||||||||||||
direction_id |
データセット全体で一貫して 0 と 1 の値を使用します。つまり
|
||||||||||||||
bikes_allowed |
フェリー旅行の場合、自転車が許可されている (または許可されていない) ことを明示的に指定します。データが欠落しているためにフェリー旅行を避けると、通常、大きな迂回につながります。 |
stop_times.txt¶
ループ ルート: ループ ルートでは、特別なstop_timesの考慮が必要です。(参照: ループ ルートのケース)
| フィールド名 | 推奨事項 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_typeおよびdrop_off_type |
旅客サービスを提供しない無収入 (回送) 旅行では、すべてのstop_times行でpickup_typeおよびdrop_off_typeの値を1に設定する必要があります。 |
||||||||||||
有償運行の場合、運行状況を監視するための内部のグ ポイントや、乗客が乗車できない車庫などのその他の場所は、pickup_type=1(乗車不可) およびdrop_off_type=1` (降車不可) でマークする必要があります。 |
|||||||||||||
arrival_timeおよびdeparture_time |
arrival_timeとdeparture_timeフィールドには、可能な限り、拘束力のない推定時間またはタイム ポイント間の補間時間を含め、時間値を指定する必要があります。 |
||||||||||||
stop_headsign |
一般に、ヘッドサイン値は駅の標識にも対応する必要があります。 以下の場合、 南行きは駅の標識では使用されていないため、顧客に誤解を与える可能性があります。 |
||||||||||||
|
|||||||||||||
|
|||||||||||||
calendar.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | calendar.service_nameも` GTFS の可読性を高めることができますが、これは仕様では採用されていません。 |
calendar_dates.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | calendar.service_nameも` GTFS の可読性を高めることができますが、これは仕様では採用されていません。 |
fare_attributes.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| 運賃システムを正確にモデル化できない場合は、混乱を避けるために空白のままにしておきます。 | |
運賃 (fare_attributes.txtおよびfare_rules.txt) を含めて、できるだけ正確にモデル化します。運賃を正確にモデル化できないエッジケースでは、運賃を安くするのではなく高く表現して、顧客が不足運賃で搭乗しないようにする必要があります。運賃の大部分を正しくモデル化できない場合は、運賃情報をフィードに含めないでください。 |
fare_rules.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | 運賃システムを正確にモデル化できない場合は、混乱を避けるために空白のままにしておきます。 |
運賃 (fare_attributes.txtおよびfare_rules.txt) を含めて、できるだけ正確にモデル化します。運賃を正確にモデル化できないエッジケースでは、運賃を安くするのではなく高く表現して、顧客が不足運賃で搭乗しないようにする必要があります。運賃の大部分を正しくモデル化できない場合は、運賃情報をフィードに含めないでください。 |
shapes.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | 理想的には、共有されている線形の場合 (つまり、ルート・路線系統1 と 2 が同じ道路または線路のセグメントで動作している場合)、線形の共有部分は完全に一致する必要があります。これにより、高品質の交通地図作成が容易になります。 |
| 線形は、車両が走行する道路の中心線に沿う必要があります。これは、指定された車線がない場合は道路の中心線、または車両の移動方向の道路側の中心線のいずれかになります。 配置は、縁石の停留所、プラットフォーム、または乗車場所に対して ギザギザになってはなりません。 |
|
shape_dist_traveled |
shape_dist_traveledフィールドを使用すると、機関はshape_dist_traveled stop_times.txtファイル内の停留所がそれぞれの形状にどのように適合するかを正確に指定できます。shape_dist_traveled フィールドに使用する一般的な値は、車両が移動した形状の開始点からの距離です (走行距離計の読み取り値のようなものと考えてください)。shapes.txt内) は、旅行がサービスを提供する停留所の位置から 100 メートル以内である必要があります。shapes.txtに余分な点が含まれないように配置を簡素化します (つまり、直線セグメント上の余分な点を削除します。線の簡素化の問題に関する説明を参照してください)。 |
frequencies.txt¶
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | frequencies.txtで参照される旅行では、実際の停車時刻は無視されます。定期運行の旅行では、停車時刻間の移動時間間隔のみが重要です。明確さと可読性のため、 frequencies.txtは00:00:00 (最初のarrival_timeが 00:00:00) から開始することをお勧めします。 |
block_id |
定期運行の旅行に指定できます。 |
transfers.txt¶
transfers.transfer_typeは、GTFSで定義 の 4 つの値のいずれかになります。これらのtransfer_type定義は、以下の GTFS 仕様から 斜体 で引用されており、追加の推奨事項が実践されています。
| フィールド名 | 推奨 |
|---|---|
transfer_type |
0 または (空): これはルート間の推奨される乗り換えポイントです。 複数の乗り換え機会があり、その中により優れた選択肢（追加の設備を備えた交通センター、または隣接または接続された乗車施設/プラットフォームを備えた駅など）がある場合は、推奨される乗り換えポイントを指定します。 |
1: これは、2 つのルート間の時間指定の乗り換えポイントです。出発車両は、乗客がルート間を乗り換えるのに十分な時間、到着車両を待つことが期待されます。 この乗り換えタイプは、乗り換えを確実に行うために必要な間隔をオーバーライドします。たとえば、Google マップでは、乗客が安全に乗り換えを行うには 3 分かかると想定しています。他のアプリケーションでは、他のデフォルトを想定する場合があります。 |
|
2: この乗り換えでは、接続を確実にするために、到着と出発の間に最小限の時間が必要です。乗り換えに必要な時間は、 停留所間の移動時間が長くなる障害物やその他の要因がある場合は、最小乗り換え時間を指定します。 |
|
3: この場所ではルート間の乗り換えはできません。 物理的な障壁のために乗り換えが不可能な場合、または困難な道路横断や歩行者ネットワークの隙間によって乗り換えが安全でなかったり複雑になったりする場合は、この値を指定します。 |
|
| 乗車間で座席内 (ブロック) 乗り換えが許可されている場合、到着乗車の最後の停車地は、出発乗車の最初の停車地と同じである必要があります。 |
事例別に整理された実践推奨事項¶
このセクションでは、ファイルやフィールド全体に影響を与える特定の事例について説明します。
ループルート・路線系統¶
ループ ルートでは、車両の乗車は同じ場所 (場合によってはトランジット センターまたは乗り換えセンター) で始まり、終わります。車両は通常、連続的に運行し、車両がループを続ける間、乗客は車内にとどまることができます。
したがって、乗客に車両の進行方向を示すために、行先表示の推奨事項を適用する必要があります。
移動方向の変更を示すには、 stop_times.txtファイルにstop_headsignsを指定します。stop_headsignは、定義されている停留所から出発する旅行の方向を説明します。旅行の各停留所にstop_headsignsを追加すると、旅行中のヘッドサイン情報を変更できます。
2つのエンドポイント間で動作するルート (同じバスが往復する場合など) に対して、 stop_times.txtファイルで 1 つの循環旅行を定義しないでください。代わりに、旅行を 2 つの別々の旅行方向に分割します。
循環旅行のモデリングの例:
- 停留所ごとにヘッドサインが変化する循環旅行
| trip_id | arrive_time | department_id | stop_sequence | stop_headsign |
|---|---|---|---|---|
| trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 |
| trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 |
| trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 |
| trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 |
| trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 |
| trip_1 | 06:35:00 | 06:35:00 | stop_A | 6 |
- 2 つの行先標識がある循環旅行
| trip_id | arrive_time | departmental | stop_id | stop_sequence | stop_headsign |
|---|---|---|---|---|---|
| trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 | "outbound" |
| trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 | "outbound" |
| trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 | "outbound" |
| trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 | "inbound" |
| trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 | "inbound" |
| trip_1 | 06:35:00 | 06:35:00 | stop_F | 6 | "inbound" |
| trip_1 | 06:40:00 | 06:40:00 | stop_A | 7 | "" |
| フィールド名 | 推奨事項 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
ループの完全な往復を 1 回の旅行でモデル化します。 | |||||||||||||||
stop_times.stop_id |
ループである旅行の場合は、 stop_times.txtに最初/最後の停車地を 2 回含めます。以下に例を示します。多くの場合、ループ ルートには、ループ全体を移動しない最初と最後の旅行が含まれることがあります。これらの旅行も含めます。
|
|||||||||||||||
trips.direction_id |
ループが反対方向 (つまり時計回りと反時計回り) に動作する場合、 direction_id を0 または1に指定します。 |
|||||||||||||||
trips.block_id |
同じblock_idプ` トリップを示します。 |
Lassoルート・路線系統¶
Lasso ルートは、ループ ルートと方向ルートの側面を組み合わせたものです。
| 例: |
|---|
| 地下鉄ルート・路線系統(シカゴ) |
| 郊外からダウンタルート・路線系統へのバス路線 (セント アルバート または エドモントン) |
| CTA ブラウン ライン (CTA ウェブサイト および TransitFeeds) |
| フィールド名 | 推奨事項 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
車両の往復の全範囲 (上記 の図を参照) は、A から B、B、そして A に戻る移動で構成されます。車両の往復全体は、次のように表すことができます。trips.txtのsingletrip_id値/レコード</li><li>trips.txtは 複数の trip_id値/レコードがあり、連続した移動はblock_idで示されます。 |
||||||||||
stop_times.stop_headsign |
AB セクションに沿った停留所は両方向に通過します。stop_headsign により移動方向の区別が容易になります。したがって、これらの旅行ではstop_headsignを指定することをお勧めします。example_table:
|
||||||||||
trip.trip_headsign |
旅行の行先標識は、スケジュールに表示されるような旅行の全体的な説明である必要があります。n から Linden へ、Loop 経由(シカゴの例) またはAから A へ、B 経由(一般的な例) などです。 |
分岐¶
一部のルートには分岐が含まれる場合があります。これらの分岐間では配置と停留所が共有されますが、それぞれが異なる停留所と配置セクションも提供します。分岐間の関係は、以下の追加のガイドラインを使用して、ルート名、行先標識、旅行の短縮名で示すことができます。
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | 分岐ルートに名前を付ける場合は、他の旅客情報資料に従うことをお勧めします。以下は、2 つのケースの説明と例です。 |
時刻表と路上標識が 2 つの異なる名前のルート (例: 1A と 1B) を表している場合は、 route_short_nameフィールドやroute_long_nameフィールドを使用して、GTFS でそのように示します。例: GoDurham Transit ルート 2、2A、および 2B は、ルートの大部分で共通の配置を共有していますが、いくつかの異なる側面で異なります。
|
|
機関が提供する情報に同じ名前のルートとして分岐が記載されている場合は、 trips.trip_headsign、stop_tiを使用します。 |
mes.stop_headsign、および/またはtrips.trip_short_name`フィールド。例: GoTriangle route 300 は、時間帯に応じて異なる場所に移動します。通勤ラッシュ時には、市内に出入りする労働者に対応するために、標準ルートに追加の区間が追加されます。 |
よくある質問（FAQ）¶
これらの GTFS ベスト プラクティスはなぜ重要ですか？¶
GTFS ベスト プラクティスの目的は次のとおりです。
- 公共交通機関アプリにおけるエンドユーザーのカスタマー エクスペリエンスを向上させる
- 幅広いデータの相互運用性をサポートし、ソフトウェア開発者がアプリケーション、製品、サービスを導入および拡張しやすくする
- さまざまなアプリケーション カテゴリで GTFS の使用を促進する（旅行計画という当初の重点を超えて）
GTFS ベスト プラクティスが調整されていないと、GTFS を利用するさまざまなアプリケーションが、調整されていない方法で要件と期待を確立する可能性があります。その結果、要件とアプリケーション固有のデータセットが分散し、相互運用性が低下します。ベスト プラクティスがリリースされる前は、正しい形式の GTFS データを構成する要素について、より大きな曖昧さと意見の不一致がありました。
これらはどのように開発されたのですか？誰が開発しましたか?¶
これらのベスト プラクティスは、GTFS に深く関わっているアプリ プロバイダーとデータ コンシューマー、交通機関プロバイダー、コンサルタントなど、GTFS に関わる 17 の組織からなるワーキング グループによって開発されました。ワーキング グループは Rocky Mountain Institute によって招集され、運営されました。
ワーキング グループのメンバーは、各ベスト プラクティスに投票しました。ほとんどのベスト プラクティスは満場一致で承認されました。少数のケースでは、ベスト プラクティスが組織の大多数で承認されました。
GTFS 参照を変更しないのはなぜですか?¶
よい質問です。仕様、データの使用法、ニーズを調査するプロセスによって、実際に仕様にいくつかの変更が加えられました (GitHub のクローズされたプル リクエスト を参照)。 仕様参照の修正は、ベスト プラクティスよりも厳しい精査とコメントの対象となります。特定のベスト プラクティスは、採用レベルとコミュニティの合意に基づいて仕様に統合されています。最終的には、すべての GTFS ベスト プラクティスがコア GTFS リファレンスの一部になる可能性があります。
これらのベスト プラクティスへの準拠を確認するにはどうすればいいですか?¶
Canonical GTFS Schedule Validator は、これらのベスト プラクティスへの準拠を確認します。この検証ツールの詳細については、検証ページ を参照してください。
私は交通機関の代表です。ソフトウェア サービス プロバイダーとベンダーがこれらのベスト プラクティスに従うようにするには、どのような手順を踏めばよいでしょうか?¶
ベンダーまたはソフトウェア サービス プロバイダーにこれらのベスト プラクティスを勧めてください。 GTFS を生成するソフトウェアを調達する際は、GTFS ベスト プラクティスの URL とコア仕様リファレンスを参照することをおすすめします。
GTFS データ フィードがこれらのベスト プラクティスに準拠していないことに気付いた場合はどうすればよいですか?¶
- feed_info.txt * に 提案された feed_contact_email または feed_contact_url フィールドがある場合はそれを使用して、または交通機関またはフィード プロデューサーのウェブサイトで連絡先情報を検索して、フィードの連絡先を特定します。フィード プロデューサーに問題を伝えるときは、議論中の特定の GTFS ベスト プラクティスにリンクします。 （
このドキュメントへのリンクを参照してください）。
参加するにはどうすればいいですか？¶
specifications@mobilitydata.orgにメールを送信してください。
このドキュメントについて¶
目的¶
GTFS ベスト プラクティスを維持する目的は次のとおりです。
- 交通データの相互運用性の向上をサポートする
- 公共交通機関アプリにおけるエンドユーザーの顧客エクスペリエンスを向上させる
- ソフトウェア開発者がアプリケーション、製品、およびサービスを導入および拡張しやすくする
- さまざまなアプリケーション カテゴリで GTFS を使用できるようにする（当初の重点である旅行計画を超えて）
公開されている GTFS ベスト プラクティスを提案または修正する方法¶
ベスト プラクティスは、現在仕様に統合中です。新しいベスト プラクティスを提案したい場合は、GTFS リファレンス GitHub リポジトリ にアクセスして問題を報告または PR を作成するか、specifications@mobilitydata.org にお問い合わせください。
このドキュメントへのリンク¶
フィード プロデューサーに GTFS データを正しく作成するためのガイダンスを提供するために、ここにリンクしてください。個々の推奨事項にはそれぞれアンカー リンクがあります。推奨事項をクリックすると、ページ内のアンカー リンクの URL が表示されます。
GTFS を利用するアプリケーションが、ここで説明されていない GTFS データの取り扱いに関する要件や推奨事項を提示している場合は、これらの一般的なベスト プラクティスを補足するために、それらの要件や推奨事項を記載したドキュメントを公開することをお勧めします。
GTFS ベスト プラクティス ワーキング グループ¶
GTFS ベスト プラクティス ワーキング グループは、2016 ～ 2017 年に Rocky Mountain Institute によって招集され、公共交通機関、GTFS を利用するアプリケーションの開発者、コンサルタント、学術機関で構成され、GTFS データに関する一般的な取り扱いと期待を定義します。 このワーキンググループのメンバーは次のとおりです:
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research at University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation
- Swiftly
- Transit
- Trillium
- TriMet
- World Bank
現在、このドキュメントは MobilityData によって管理されています。