各項目の設定方法

各項目の設定方法をファイル別に説明します。表中の赤文字のファイルおよび項目は、GTFS-JPとGTFS必須事項、青文字のファイルおよび項目はGTFS-JPで必須事項です。

事業者情報（必須：agency.txt）・事業者追加情報（任意：agency_jp.txt）

事業者の基本的な情報を設定します。事業者名称等が経路検索の結果として表示されます。一度設定した事業者ID[agency_id]は、可能な限り変更しないよう留意が必要です。 法人番号は、国税庁法人番号公表サイトにて確認できます。

agency.txt

agency_jp.txt

コミュニティバス等における設定方法

自治体と事業者が協力して運行するコミュニティバス等においては、agencyに自治体と事業者のどちらの情報を記載するか分かりづらいことがあります。下記の基準を目安に、自治体と事業者合意のもとagencyの情報を設定してください。

なお、「ふれあい号」などのバスの愛称については、agencyではなくroute_long(short)_nameに含めるようにしてください。

市町村営バス、福祉バス（79条自家用有償運送）

運営責任・運行は自治体（NPOが運行するケースあり）。事業者に運転手を派遣してもらうこともある。

• データ作成主体：自治体
• agency：自治体

いわゆるコミュニティバス（4条）

自治体の政策としてバスを運行。運営責任は自治体。運輸支局への申請は運行委託先事業者。時刻表のPRは自治体が基本的には行う。経路検索CPでは自治体として扱っている。

• データ作成主体：①自治体 / ②事業者（データ作成を委託業務に含める） ※複数事業者に委託している場合は自治体が作成することが望ましい
• agency：自治体

廃止代替バス

事業者路線が不採算で廃止するが、自治体が補填することにより、路線を存続。 バス車両・停留所標識は事業者のものを使用し、営業面・運賃は事業者の制度。 時刻表のPRは事業者が基本的には行う。利用者からすると事業者路線と変わらない。

• データ作成主体：事業者
• agency：事業者

停留所・標柱情報(必須:stops.txt)

停留所と標柱に関する情報を設定します。

標柱と停留所

• 標柱とはバス停のポールを指します。同じ停留所名称で上りと下りにポールがある場合やターミナル等で複数のポールがある場合は、それぞれ別の標柱となります。
• 停留所とは複数の標柱をまとめる概念です。
• 両者は停留所・標柱区分[location_type]で区別します。
• 標柱は親停留所情報[parent_station]に停留所・標柱IDを設定し停留所に対応づけられます。

標柱と停留所の設定パターン

標柱と停留所の設定パターンは次の3つがあります。下記の特徴を踏まえて、データ整備工数や熟練度、現地の複雑さ等に応じた方法を選択してください。

• 代表点のみ：データ作成は簡易ですが、乗降場所が正確でなく、徒歩ルートが正しく出ない可能性があります。
• 標柱のみ：データ作成は簡易ですが、同一停留所の標柱が正しく名寄せされない可能性があります。また代表緯度経度が不適切になるため、バス停検索時の表示位置がずれたり、路線図やデータ分析結果をマップ上に表現する際に不適切になることがあります。
• 親子設定：データ作成の手間はかかりますが、乗降場所、同一停留所であること、代表緯度経度をデータ利用者に伝えることができます。複雑なターミナルでは推奨される設定方法です。

stops.txt

経路情報（必須：routes.txt）・経路追加情報（任意：routes_jp.txt）

バスの運行経路の情報を設定します。ここでいう経路とは、運行ルートの最小単位をいい、同一経路を運行する便ID[trip_id(trips.txt、後述)]を経路ID[route_id]に紐付けることで、同一経路を運行する複数の便をまとめて管理することになります（図表 6参照）。

経路の分け方

GTFS-JPでは、経由違いや途中止まり、往路・復路は別の経路として設定することを基本とします。図表 6の右の図の例では6つの経路ができる形となります。また、運賃は経路に紐付くため、同一経路でも運賃が異なる場合（深夜バス含む）も別経路として設定が必要です。 運賃、系統番号、路線名に違いが無いのであれば、GTFSと同様、入力簡易化のため往路・復路、経由違いや途中止まりを同一経路にしてもかまいません。ただし、別経路にした場合に比べ国内経路検索による取込に時間がかかる可能性があります。

経路のくくり方

また、路線ID[jp_parent_route_id]に経路ID[route_id]を紐付けることで、路線や系統に相当する概念を表現することができます。路線や系統の括りかたについては、事業者ごとに任意に設定することが可能です。

参考）Google Mapsではroute_short_name優先でroute_long_nameとどちらかのみ表示

Google Mapsでは、route_short_nameが設定されている場合はroute_long_nameは表示されません。route_short_nameが設定されていない場合はroute_long_nameが表示されます。

系統番号の設定方法については国交省ガイドラインを参照

系統番号を新たに導入または改良する場合は、国土交通省が定めた「乗合バスの運行系統のナンバリング等に関するガイドライン」を参考にしてください。(http://www.mlit.go.jp/jidosha/jidosha_tk3_000091.html) 下記等の方針が示されています。

• 市区町村の行政区域に拘らず、生活圏・交通圏単位で検討する
• 「アルファベット＋数字」又は「数字のみ」によって表現する

系統番号の導入・普及状況に応じた経路名設定方法

route_short_nameには系統番号の設定が原則なため、下記のような設定方法を推奨します。

routes.txt

routes_jp.txt

便情報（必須：trips.txt）

運行する便の情報を設定します。便情報は、「GTFS-JP」における運行情報設定の最小単位で、旅客が連続して乗車可能な１回の運行を1つの便情報[trip_id]として設定します。

trips.txt

営業所情報（任意：office_jp.txt）

営業所情報は、国内の経路検索事業者向けに設定された項目で、設定は任意です。営業所情報は、便情報に紐づくものであり、当該便を運行する営業所の情報を設定します。経路検索事業者によっては、ここで設定された情報に基づき、運行営業所の案内を行う場合があります。

office_jp.txt

通過時刻情報（必須：stop_times.txt）

停留所の通過時刻を便ごとに設定します。 複数の事業者が共同運行する場合は、自社便の情報のみを設定することを原則としますが、相手会社の情報も混在している場合、その旨を経路情報[route_desc(routes.txt)]に注記が必要です。 乗車専用はpickup_type、降車専用についてはdrop_off_typeに1を設定します。ただし、発着の組み合わせによる乗降可否は表現しきれないため、経路情報[route_desc(routes.txt)]に注記をします。

stop_times.txt

オンデマンドバスの設定例

各種オンデマンドバスについては、pickup_type、calendar_dates.txt等を用いて設定します。典型的なパターンの設定例を下記に示します。

途中で打ち切り

利用者がいなくなった時点で運行終了（途中停留所は降車専用） 始発停留所で利用がなければ、運行終了（途中停留所はデマンド） 例：高山市「のらマイカー」 http://www.city.takayama.lg.jp/_res/projects/default_project/_page_/001/004/689/h30kiyomi3.pdf

設定方法：pickup_typeを1にする

路線の一部がオンデマンド・時刻変更なし

例：松阪市「機殿朝見コミュニティバス」 https://www.city.matsusaka.mie.jp/uploaded/attachment/19558.pdf

設定方法：pickup_typeを2にする

経路検索事業者によって、下記のように表示の仕方が異なる場合がある。

• 「要予約」と注記を表示：ナビタイムジャパン等
• 注記を表示しない：スマートフォン用のGoogle Maps等
• 表示対象としない：ヴァル研究所等

路線の一部がオンデマンド・時刻変更あり

路線の一部がオンデマンド区間があり、オンデマンド区間で利用がない場合と利用がある場合で時刻が変化する。 例：設楽町「稲武線」
http://www.town.shitara.lg.jp/odekake/files/route/time/inabusenn.pdf

時刻逆転が起きる可能性があり、経路検索事業者が取り込まない場合が多いので、データ整備の優先度は低い。

臨機応変な運行・運休日

登校日のみ運行、夏休み運休、学校行事や部活により運行/運休 など。

設定方法：calendar_dates.txtを設定する、GTFSリアルタイムのAlertを設定する、route_descまたはjp_trip_descに記載する、などの方法がある。

フリー乗降方式

停留所を設定できない場合はGTFS-JPデータを作成できないため、区間または路線単位で整備対象外とする。

運行区分情報(必須:calendar.txt)・運行日情報(任意:calendar_dates.txt)

平日や休日といった運行区分に関する情報を設定します。運行区分情報は必須、運行日情報は任意の設定となります。曜日ごとに運行・運休といった基本パターンを運行日ID[service_id]として設定し、祝日等で平日ダイヤが休日ダイヤとして運行するような場合は運行日情報（calendar_dates.txt）で、当該日に運行ダイヤが変わる旨を設定することが基本であり、祝日に限らず、学校休業日や年末年始等でイレギュラーな運行がある場合も同様です。 このような運用が可能な場合は、正確に日程を設定することが望ましいですが、継続的に日付を設定することが難しい場合は、標準として用意された「平日（月〜金）」「平日（月〜土）」「土曜」「日曜」「祝日」「日曜・祝日」「土曜・日曜」「土曜・日曜・祝日」の8つの運行日ID[service_id]により、運行日を表現することも可能とします。この場合、国内の経路検索事業者等は祝日等に応じた対応が可能となりますが、海外等でGTFSとして使用される場合、運行日情報（calendar_dates.txt）で運行日の例外を設定しないと祝日等の運行が正しく案内されない可能性があることに留意が必要です。また、学校休業日等祝日以外で運休（または運行）される場合は、便情報[jp_trip_desc(trips.txt)]で「学校休業日運休」といったような注記が必要になります。

calendar.txt

calendar_dates.txt

運賃属性情報(推奨:fare_attributes.txt)・運賃定義情報(推奨:fare_rules.txt)

運賃に関する情報を設定します。GTFSでは任意となっていますが、国内の経路検索事業者において運賃は必須情報であることから、GTFS-JPにおいては必須としています。また、運賃定義情報も必須としていますが、運賃を設定する場合は必要であり、対キロ制の場合、全ての経路の全ての区間に対して運賃を設定する必要があります。 表現しきれない複雑な運賃の場合 本フォーマットでは、1日に何度乗っても固定料金、乗継割引等の複雑な運賃は表現しきれません。運賃に関する注記事項を[route_desc(routes.txt)]に設定することで、経路検索サービス等で注記が表示される可能性があります。

fare_attributes.txt

fare_rules.txt

運賃設定例

運賃については、stops.zone_id、fare_attributes.txt、fare_rules.txtを連携して設定する必要があります。以下に、代表的な運賃パターンの設定例を示します。

例1：全線均一運賃

運賃：全線200円均一

fare_attributes.txtの設定

fare_rules.txtの設定：不要

例2：ゾーン制

運賃：停留所A～Bはeastゾーン　停留所C～Dはwestゾーン（系統1001）

fare_attributes.txtの設定

fare_rules.txtの設定

例3：対距離制と均一制の併用

運賃：停留所A～Cは200円均一、その他は対距離制（系統1001）

fare_attributes.txtの設定

fare_rules.txtの設定

描画情報（任意：shapes.txt）

標柱以外の通過ポイントを指定する場合に設定します。描画情報を設定しない場合、標柱間を単純に結んだ線が経路として表示されるため、より正確に運行ルートを表現したい場合に設定します。通常は設定しなくても、経路検索は可能です。

shapes.txt

運行間隔情報(任意：frequencies.txt）

定められた時刻表がなく、一定間隔で運行する場合に設定します。運行間隔情報はGTFSのファイルとして定義されていますが、国内の経路検索で設定する必要性は低いと考えられます。

frequencies.txt

乗換情報（任意：transfers.txt）

通常は、標柱の緯度経度情報に基づき乗換ルートが案内されますが、明示的に乗換地点を指定したい場合に設定します。乗換情報はGTFSのファイルとして定義されていますが、国内の経路検索で設定する必要性は低いと考えられます。

transfers.txt

提供情報(必須:feed_info.txt)

データを公開している組織の情報や作成したデータの有効期間を設定します。GTFSでは必須ではありませんが、GTFS-JPとしては必須となります。

提供組織(feed_publisher_name, feed_publisher_url)

整備・配信をシステム会社や運行委託先のバス事業者が行っている場合は、委託先のシステム会社・バス事業者名に設定しても構いません。

有効期間開始・終了日(feed_start_date, feed_end_date)

ダイヤ改正日に正しくデータを切り替えられるようにするため、有効期間開始日にはダイヤ改正日を設定します。交通事業者がダイヤ改正等の連絡を情報利用者側に伝達することを失念するようなケースを想定し、1年程度の期間で提供終了日を設定し、少なくとも1年に1回程度は経路検索事業者へ最新データを提供する事が望ましいといえます。

feed_info.txt

翻訳情報(任意:translations.txt)

日本語（漢字名称や注記）をよみがなや英語、その他の言語に変換する際に設定します。

よみがなは必須

国内の経路検索事業者においては、よみがなを必須としていることから、よみがな(lang=ja-Hrkt)を設定することを必須としています。

翻訳対象項目

各項目の末尾に_name,_desc,_url,_headsignが付された項目に設定してある日本語（漢字等）に対応するよみがなや英語を設定します。

translations.txt

整備優先度

外国語対応に関しては、全ての項目に対して設定する必要はなく、停留所名称や行き先といった必要性の高い項目から、優先順位をつけて対応する等、業務負荷と必要性を比較考量した上で対応を検討する必要があります。

参考）Google Mapsの挙動を踏まえた設定例

Google Mapsの挙動を踏まえると下記の設定が必要になります。

• 多言語を設定したtrans_idに対しては日本語(lang=ja)も設定する
（そうしなければ、日本語表示の際に別の言語が表示される）
• 日本語(lang=ja)のレコードがよみがな(lang=ja-Hrkt)よりも前の行に設定する
（そうしなければ、日本語表示の際によみがなが表示される）

以上を考慮した設定例を示します。

翻訳表記方法

外国語データの作成にあたっては、日本バス協会訪日外国人旅行者のバス利用を想定した多言語対応に関するガイドラインを参考にしてください。下記のような事項が記載されています。

• 原則として発音通りローマ字表記とする

  • 例：金閣寺前 → Kinkakuji-mae
• 訪日外国人の関心が高くローマ字表記で理解しがたい場合は（）で補足表記する

  • 例：永代橋 → Eitaibashi （Eitai Bridge）
• 「駅」は「StationまたはSta.」と表記する

  • 例：吉祥寺駅 → Kichijoji Sta.

同一漢字で読みが異なる場合

下記の方法等により、同一漢字の停留所に異なるよみがなを設定可能です。

• 方法1. stop_nameおよびtrans_idを漢字名ではなくID(stop_id等)とする

stops.txt

translations.txt

• 方法2. あらかじめよみがなを振っておく

stops.txt

translations.txt

更新履歴

初版

平成29年3月31日 発行

文書修正

• 誤字の正誤表を作成（平成30年7月5日）

第2版

平成31年3月27日 発行

仕様変更

追加

• のりば名(stops.platform_code)を追加。
  • 理由：停留所名と独立してのりば名を設定可能にするため。

必須化（JP推奨項目の廃止）

• 運賃(fare_attributes.txt, fare_rules.txt)を推奨から必須に変更。
  • 理由：国内の経路検索事業者において運賃は必須情報であるため。

必須化

• 翻訳情報(translations.txt)のうち、よみがな(lang=ja-Hrkt)の設定を必須とした。
  • 理由：国内の経路検索事業者においてよみがなは必須情報であるため。

任意化（JP推奨項目の廃止）

• 停留所-標柱の親子設定(stops.parent_station)を推奨から任意に変更。
  • 理由：簡易なデータ作成を許容するため。

JP拡張仕様の緩和

• 経路(routes.txt)を、経由違いや途中止まり、往路・復路を同一経路(route_id)にすることを許容。ただし、運賃、系統番号、路線名に違いが無い場合に限る。
  • 理由：GTFSにおいて推奨されている往路・復路を同一経路にする方法を許容するため。簡易なデータ作成を許容するため。

運賃定義の経路ID(fare_rules.route_id)を必須から任意に変更。

• 理由：全路線均一運賃制やゾーン制など、経路に関わらず同一な運賃設定を簡易に入力するため。

文書修正

文書構成・全体

• 「標準的なバス情報フォーマット」の動的データへの拡張に伴い全体的に修正。
• 「標準的なバス情報フォーマット」作成の目的、フォーマット作成の手法、データ作成例、付録の各章を廃止し、本文書および各種手引き・ガイドラインに再構成。
• 静的バス情報フォーマット（GTFS-JP）の概要
• 「条件付必須」が任意または必須になっていた誤訳を修正。
• 平成29年1月時点のGTFSリファレンスに基づいている旨を記載。
• 環境依存文字への注意喚起を記載。
• 主キーを明確化し相関図とデータ項目表に追加。
• 日本向け拡張仕様について記載。

事業者情報(agency.txt)

• 1事業者が複数データセットを作成する場合に法人番号に枝番を設定する旨を記載。
• コミュニティバス等における設定方法を記載。

停留所・標柱情報(stops.txt)

• 標柱と停留所の設定パターンを記載。

経路情報(routes.txt)

• Google Mapsにおいてroute_short_nameが優先的に表示される旨を記載。
• 系統番号の、経路名への設定方法、国交省のナンバリングガイドラインに基づく設定方法を記載。

通過時刻情報(stop_times.txt)

• オンデマンドバスの設定例を記載。

提供情報(feed_info.txt)

• 提供組織は委託先業者でも良い旨を記載。
• ダイヤ改正日をfeed_start_dateに設定する旨を記載。

翻訳情報(translations.txt)

• Google Mapsの挙動を踏まえた設定例を記載。
• 日本バス協会の多言語対応ガイドラインに基づく設定方法を記載。