2018/11/1「標準的なバス情報フォーマット」作成ツールを展示

2018年11月1日(木曜日)に、日本バス協会主催「第67回 中央技術委員会全国大会」が開催されます。

商品展示会場では 宇野バス&標準的なバス情報フォーマット広め隊による「標準的なバス情報フォーマット」作成ツールの展示を行います。バス会社以外の方も商品展示会場には入場可能ですので、興味のある方は是非お越しください。

場所:サンケイプラザ(大手町)3階展示会場
展示時間:9時30分~17時30分

“2018/11/1「標準的なバス情報フォーマット」作成ツールを展示” の続きを読む

「標準的なバス情報フォーマット」ってなに?

「標準的なバス情報フォーマット」ってなに?

路線バスの路線図や時刻表、運賃表などをデータ化する際のフォーマットを定めたものです。国土交通省のWebページにて、ITエンジニア向けに具体的にフォーマットを説明した解説書を公開しています。

どんな風に役に立つの?

共通フォーマットなので、データを利用するベンダが特別な対応なしでそのバスのデータを扱うことが出来ます。乗換案内にデータが使われる可能性が高まりますし、乗換案内以外にも、デジタルサイネージや印刷物の作成などへの応用もこれから広がっていくと考えています。

誰がデータを整備するの?

路線バスを運行している事業者や自治体などが、自ら、またはIT技術に長けた者の力を借りて整備することを想定しています。

どうやったらデータを作れるの?

時刻表を打ち込むと標準的なバス情報フォーマットに変換出来るExcelフォームなどが公開されています.また、代表的なダイヤ編成システムが対応を始めていますし、「その筋屋」という無料で使えるダイヤ編成システムもあります。事業者の規模に応じて適切なツールを選択するのがいいでしょう。

バス事業者の仕事が増えるんじゃない?

網羅的なデータをひとつ整備すれば、そこからの応用は簡単です。例えばバス停に貼り出す時刻表は全て自動的に作れるようになります。そのため、適切に標準フォーマットを導入すれば、全体の業務量は減ると考えています。

乗換案内サービスに既に提供している事業者はどうすればいい?

既にデータを提供しているバス事業者は特に新しい取り組みは必要ありません。ただ、自社でデータを整備していることが、バスロケの導入の時や将来的な業務効率の改善の際に役に立つと考えられます。

日本だけの規格なの?

標準的なバス情報フォーマットは、世界標準の公共交通データフォーマットであるGTFS形式と互換性を持つように作られています。このフォーマットで整備したデータは、日本の乗換案内事業者に届けられるだけなくGoogle Mapsや世界中で作られている様々なツールで活用出来ます。

オープンデータとの関係は?

整備したデータの扱いは、バス事業者や自治体が決められます。オープンデータとしてWeb公開することで、日本だけでなく世界の開発者にデータが使われるチャンスが拡がります。宇野バス山梨交通石川県能美市のコミュニティバスなどこのフォーマットでのオープンデータ公開の事例が既にあります。

初版と書いてあるけど、改訂の予定はあるの?

より日本のバスの実情に合ったフォーマットに育てたいと考えています。
体制を作ろうとしています。

日本モビリティ・マネジメント会議にて発表を行いました

第13回日本モビリティ・マネジメント会議(JCOMM)にて 「標準的なバス情報フォーマット」の普及活動について、口頭発表・ポスター展示を行いました。

【データ作成指針たたき台】agency_jp.txt

(※は議論のための補足説明です。指針には記載しません。枠内は国交省解説書(初版)での表内の説明記述です。)

agency_jp.txt

agency_id
紐づける事業者ID[agency_id(agency.txt)]を設定。

agency.txtに記載したagency_idと同じものをすべて記載します。

agency_official_name
申請等に必要な正式名称を設定。

(別稿 「1.事業者、情報提供者等について」参照)

(※ここで「申請等」とは何を指すのでしょうか。本バスデータのCP等への提供のことでしょうか、それとも、運輸局等へのバス事業関連の申請のことでしょうか。)

agency_zip_number
ハイフンなしの半角数字7桁で設定。

バス事業者の本社、市町村役場の郵便番号を記載します。

agnecy_address
都道府県から入力。住居表示通り略さずに全角で設定。

バス事業者の本社、市町村役場の住所を記載します。住居表示がない場合は地番を記載します。
例:東京都新宿区西新宿二丁目8番1号
長野県長野市大字鶴賀緑町1613番地

agency_president_name
申請者の肩書を設定。

特に記載する必要はありません。(※ここも「申請」の意味が不明です。必要なら「申請」の意図に合わせて記載する必要があります。)

agency_president_name
姓と名の間は、全角スペース1文字を挿入。

特に記載する必要はありません。(※ここも「申請」の意味が不明です。必要なら「申請」の意図に合わせて記載する必要があります。)

 

【データ作成指針たたき台】agency.txt

(※は議論のための補足説明です。指針には記載しません。枠内は国交省解説書(初版)での表内の説明記述です。)

agency.txt

agency_id
事業者の法人番号を設定。
運行委託等を行っている場合、原則として運行委託元の法人番号を設定。自治体等が運営するコミュニティバス等は、原則として運行委託元の法人番号を設定。

別稿「1.事業者、情報提供者等について」を参照。

agency_name
経路検索で案内するのが適当な名称を設置。正式名称である必要はなく、旅客が交通機関を識別しやすい名称を設定。

別稿「1.事業者、情報提供者等について」を参照。

agency_url
原則として、事業者HPのトップページのURLを設定。複数の事業を経営している等の場合、個別の事業のページ(バス事業に関するトップページ等)のURLの設定も可。但し、設定したURLは頻繁な変更がなされないことに留意。
HPがない場合は、その旨を記載。

一つの市町村に複数のコミュニティバスがあり、それぞれのHPがある場合は、それぞれのHPのURLを記載します。ただし、個別のHPがない場合やニュースページ等に掲載されていて固定したページがない場合には市町村のHPのトップページを記載します。

agency_timezone
日本の場合、「Asia/Tokyo」を設定。

(特になし)

agency_lang
日本の場合、「ja」を設定。

任意項目となっているが、Googleでの検索も考慮して「ja」と記載することを推奨します。

agency_phone
全社の窓口となる電話番号(本社代表電話、運輸部門代表電話、お客様センター等)を設定。
運輸委託等を行っている場合は、問合せに対応可能な主体の電話番号を設定。

実際の問合せに対応できる電話番号を記載します。なお、路線により営業所等が異なり、各営業所に問合せる必要がある場合には、office_jp.txtに営業所の名称や電話番号を記載します。

agency_fare_url
利用者が乗車券等をオンラインで購入可能な場合に、そのURLを設定。オンラインでの購入不可の場合は省略。

(特になし。)

(※デマンドバスの予約サイトがある場合に、ここに記載することが適当か)

agency_email
利用者が問合せ等で利用可能なEメールアドレスを設定。

(特になし)

 

 

 

 

 

【データ作成指針たたき台】1.事業者、情報提供者等について

(※は議論のための補足説明です。作成指針には記載しません。データ作成指針は原則、フィールドごとに記述することを想定していますが、この項のように各項目を整理して記載したほうがよいものについては、まとめて指針を記述することを想定しています。)

1.事業者、情報提供者等について

標準的フォーマットには「事業者名称」「事業者正式名称」「提供組織名」「事業者ID」を記載します。これらは、次のように記載することを推奨します。
なお、一つの標準的バス情報フォーマットデータに複数のバスを記載することが可能です、その場合にはagency.txtに列挙します。

(1) 事業者名称[agency.txt → agency_name]

ア 経路検索の結果として表示される名称ですので、利用者に分かりやすい「バスの名称」とします。車両、バス停、チラシ、ホームページ等に記載されている名称とします。市町村名やバス事業者の会社名とはしません。(これは「事業者正式名称」に記載します。)
例:○○市コミュニティバス
○○町コミュニティバスあおぞら
ひまわりバス
○○市営バス

(※このフィールドのほかにバスの名称を記述する適当なフィールドがないので、たぶんこの解釈・方針でよいと思いますが、CPさん等での運用で問題はないでしょうか。このような運用にすると、フォーマット仕様上での「事業者名称」という日本語名はあまり適切ではありません。これを「バス名称」のように変更することも検討してはどうでしょうか。「事業者ID」(agency_id)も「バス名称ID」としてはどうでしょうか。)

イ 一つの市町村内に複数のコミュニティバスがあり、通常、異なる名称を使っている場合には、それぞれの「事業者名称」でデータを作成します。
例:○○市まちなか循環バス、○○市××地域バス

ウ 民営バスでバス会社が分社化されている場合でも、バスの案内表示が同一の場合は、同一の名称とします。
例:○○バス(事業者は○○バス東(株))、○○バス(事業者は○○バス西(株))

(2) 事業者正式名称[agency_jp.txt → agency_official_name]

ア バスを運営する組織の名称を記載します。市町村等が民間事業者に運行委託している場合は市町村を「運営する組織」とします。

イ 民間バス事業者が自治体から補助金を受けて運行している場合は民間バス事業者を「運営する組織」とします。

ウ その他、運行に要する費用の負担等について自治体と民間バス事業者の間で何等かの取り決めを行って運行している場合は、地域の実情に応じて市町村又は民間バス事業者のいずれかを「運営する組織」とします。

(3) 提供組織名[feed_info.txt → feed_publisher_name」

ア このバスデータの提供に責任を持つ組織の名称を記載します。通常は(2)の事業者正式名称と同じとなります。ただし、市町村のコミュニティバスの場合、担当を明確にするため、実際に情報を提供する部署名まで記載してもよいでしょう。
例:○○市市民生活部地域交通課

イ 都道府県や県バス協会等の組織が複数の市町村のコミュニティバスのデータを一括して作成・公開し、問い合わせ対応等も行う場合には、都道府県その他の組織を提供組織とすることも考えられます。

(4) 事業者ID[agency.txt → agency_id、agency_jp.txt → agency_id]

ア (2)の「事業者正式名称」に記載した組織の法人番号とします。
注)法人番号は、国税庁の法人番号公表サイト(http://www.houjin-bangou.nta.go.jp/)で検索できます。

イ 一つの市町村に複数のコミュニティバスがある場合、民営バスでも(1)の事業者名称(実際にはバス名称)が異なるバスがある場合には、法人番号にアンダーバーで枝番を付けた番号とします。つまり、異なるバス名称には異なる事業者IDを付けるようにします。
例:1234567890123 (○○市コミュニティバス)
1234567890123_1(○○市まちなか循環バス)、1234567890123_2(○○市△△地域バス)、1234567890123_3(○○市乗合タクシー)

ウ 一度設定した事業者IDは可能な限り変更しないようにしてください。バス事業者内や市町村内で新たなバスが生じたときは、枝番を追番で作成します。
バスが全部廃止された場合はそのIDは欠番にしておきます。

【データ作成指針たたき台】データを作成する単位

(※は議論のための補足説明です。作成指針に記載するものではありません

データを作成する単位

標準的バス情報フォーマットはバスデータ(バス停、路線、ダイヤ、運賃など)を管理する者が作成することが望ましく、これらに変更があったときには速やかに標準的バス情報フォーマットデータも更新される必要がありますので、データを作成する単位はバスデータを管理する単位、具体的にはバス事業者やコミュニティバスを運営する市町村単位で作成することを推奨します。

ただし、一つの市町村に複数のコミュニティバスがあり、路線計画やダイヤ改正を別々に行っている場合やバスデータを別々に管理している場合(特に担当部署や担当者が異なる場合)には、別々の標準的バス情報フォーマットデータとすることを推奨します。

なお、バスデータをシステムで管理しておりそのシステムから標準的バス情報フォーマットデータを一括して出力できる場合には、システム内に含まれる全データを一つの標準的バス情報フォーマットデータとして作成しても構いません。(※山梨県のデータはおそらくバスコンシェルジュシステムに格納されたデータをGTFSに出力しているので、山梨交通、富士急、複数の市町のデータが1ファイルに含まれています。必要なら後で各者に分割できるので、これでよいと思いますが、CPさん等で特に問題はないでしょうか。)

なお、航空便の時刻表の変更により通常の路線より頻繁にダイヤ改正が行われる空港連絡バス等を別ファイルとして作成することも考えられます。これにより当該空港連絡バス等のダイヤ改正時にはその路線だけの標準的バス情報フォーマットデータを更新すればよいことになります。(※こうすると、一般路線と標柱を共用しているときにデータから標柱掲示時刻表を作成しようとすると、標柱IDを共通にしておくことと、ツールによっては標準的フォーマットデータを2つマージする必要が生じます。)

標準的なバス情報フォーマットデータの作成指針の作成について(提案)

「標準的なバス情報フォーマットデータの作成指針」を作成して公開することを提案します。
1.指針作成の背景
この数年、GTFSによりバスデータを作成・公開する取組みがみられるようになっていましたが、2017年3月に国土交通省がGTFSを拡張した「標準的なバス情報フォーマット」(以下「標準的フォーマット」という。)を公開したこともあり、これらのフォーマットでバスデータを作成・公開しようという取組みが各地で始まっています。
これらのフォーマットの仕様は公開され、各項目にどのような内容を記載すべきかが説明されていますが、これらの説明だけでは実際に何をどのように記載すればよいかが明確ではありません。また、データを利用する側からみて必要な内容が記載されていることが必要です。
そこで、今後、より多くの主体が標準的フォーマットのバスデータを作成するようになると想定されることから、作成される標準的フォーマットが実際に実務で使える質の高いデータとなるよう、より詳細な説明や記載例などを記載したデータ作成の指針を作成することが必要であると考えられます。

2.指針の目的と対象者
標準的フォーマットで作成されたデータはバス事業者によるデータ管理や資料作成、経路検索サービスやバスロケ等のバス情報提供サービス、公共交通分析や地域分析、その他の民間サービスなど様々な場面で利用が想定されますが、本指針では主にバス事業者やコミュニティバスを運営する市町村での利用、経路検索サービス等のバス情報提供サービスでの利用において実用に適した内容のデータが作成されることを目的とします。
また、対象者は、バス事業者や市町村自身のほか、その代行者としてデータを作成する都道府県、NPO、地域コミュニティ、大学等を想定します。
これは、バスデータの速やかな更新を考えると、データ作成はバス事業者・市町村自身(及びそれを支援する者)が行うことが望ましく、彼らの労力とのバランスを考えると、彼らの直接的なメリットとなる内部利用及びバス情報提供サービスに絞ることが現実的と考えられるからです。

3.指針の検討方法
指針のたたき台をこのブログに公開しますので、関係者がメーリングリスト及び検討会の場で議論することにより作り上げていくことを提案します。関係者には、国土交通省、大学、経路検索サービス等のバス情報サービス事業者、バスダイヤ管理システム等のバス事業者が使用するシステムの開発事業者、バス情報の公開・普及の活動を行っている者を含むことを想定しています。また、バス事業者やコミュニティバスを運営する市町村も重要な関係者ですが、多数存在しますので誰にどのように参加してもらうかは皆さんと議論したいと思います。

4.標準的フォーマットの推奨
バスデータのフォーマットとしては、GTFSとそれに日本の経路検索で必要となる項目を追加した標準的フォーマットがあります。2.で示したように本指針ではバスデータが経路検索サービスで使用されることを主たる目的の一つとしているため、標準的フォーマットを推奨することとし、内容も標準的フォーマットデータを作成する指針とします。

5.指針の形式と名義
現在、国土交通省が作成した標準的フォーマットの解説書では、ファイルごとに、表形式で「フィールド名」、「日本語名」、「区分」(必須か任意か)、「日本のバス向けの設定項目」を記載し、「日本のバス向けの設定項目」の欄で記載すべき内容を記述しています。また、表外の本文中に総括的な説明や補足説明をしています。
本指針では、現在の「日本のバス向けの設定項目」よりも詳細な説明が必要だと考えますが、その形式には次のような案が考えられます。
案1:現在の国交省解説書の表の「日本のバス向けの設定項目」欄を拡大して記載する。
案2:現在の国交省解説書の表に「作成指針」の欄を追加して記載する。
案3:現在の国交省解説書の表の前後に平文で記載する。
案4:現在の国交省解説書とは別に、作成指針の文書を作成する(国交省解説書の表は引用する)。その際、形式としては案2、案3と両案が考えられる。
また、名義は案1、2、3では国土交通省になり、案4では国土交通省もしくは他の名義(例えば、標準的なバス情報フォーマット広め隊)が考えられます。

なお、指針のたたき台はおって、本ブログに公開します。

(参考)「標準的なバス情報フォーマット」解説(初版)(平成29年3月国土交通省)

(文責 東京大学空間情報科学研究センター 西沢明)

stops.txt version1→version2改定案

論点

  • バス停の親子関係を設定することを、推奨から任意に格下げする。これにあわせて各表現を変更した。
  • バス停名の読みを追加するという案もあったが、多国語対応を考慮するため、現状用いられている translations.txt による設定を引き続き採用する。

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

停留所と標柱に関する情報を設定します。標柱とはバス停のポールを指し、同じ停留所名称で上りと下りにポールがある場合やターミナル等で複数のポールがある場合は、それぞれ別の標柱として認識します。また、複数の標柱をまとめる概念として停留所を定義します。停留所を一つの代表点として記述することも、標柱ごとのデータを整備することも可能です。後者の場合、停留所と標柱は、停留所・標柱区分[location_type]で区分するとともに、標柱は親停留所情報[parent_station]に停留所・標柱IDを設定し停留所に紐づけます(図表 5参照)。複数の標柱を停留所にまとめることは必須ではありませんが、停留所としてまとめない場合、同じ停留所に属する標柱が同一の停留所として認識されないため、停留所を設定しまとめることを推奨しますが望ましいです。

また、緯度経度情報については、経路検索が任意の場所から任意の場所への検索が主流となってきていることを鑑み必須としていますが、経路検索事業者によっては緯度経度の設定がなくても受け付ける場合もあります。

図表 5 停留所と標柱の考え方
フィールド名日本語名区分日本のバス向けの設定項目(Version 1)Version 2(案)
stops.txt停留所・標柱情報必須標柱を束ねる「停留所(東京駅、市役所前等)」と「標柱(東京駅1番のりば、市役所前駅方向等)」とを定義し、「停留所」と「標柱」は、停留所・標柱区分[location_type]で区分するとともに、「標柱」は親停留所情報[parent_station]により「停留所」に紐付けることを推奨する。停留所の名称や位置情報を記述する。
標柱を束ねる「停留所(東京駅、市役所前等)」と「標柱(東京駅1番のりば、市役所前駅方向等)」とを分けて記述出来る。この場合、停留所・標柱区分[location_type]で区分するとともに、「標柱」と「停留所」の親子関係を標柱の親停留所情報[parent_station]により設定する。
★stop_id停留所・標柱ID必須事業者が内部的に使用しているコードをそのまま設定する等、名称等が変更された場合でもIDは引き継ぐことを推奨する。変更なし。
stop_code停留所・標柱番号任意駅ナンバリングに相当する旅客向けの記号・番号を停留所や標柱が持っている場合は当該番号を設定。旅客案内用の記号番号であることに留意。該当がない場合は省略。変更なし。
stop_name停留所・標柱名称必須標柱は、標柱番号や行き先・方面等を記載する必要がある場合を除き、基本的に停留所名と同一とする。また、同一の漢字で読みが異なる停留所がある場合は、翻訳情報(translations.txt)での変換を考慮し、主要でない停留所によみがなを付す。【例:新宿(にいじゅく)】停留所や標柱の名称を設定する。標柱名称は、標柱番号や行き先・方面等を記載する必要がある場合を除き、基本的に停留所名称と同一とする。また、同一の漢字で読みが異なる停留所がある場合は、翻訳情報(translations.txt)での変換を考慮し、主要でない停留所によみがなを付す。【例:新宿(にいじゅく)】
stop_desc停留所・標柱付加情報任意停留所や標柱に隣接する施設等に関する付加情報を設定。(例:市役所前停留所の最寄りに市民会館がある場合、市民会館が最寄りである旨等)変更なし。
stop_lat緯度必須標柱は標柱が設置されている場所の緯度経度を国土地理院HP等から取得、またはGPS機器を用いて実測し設定。停留所は、代表地点が定められる場合はその地点の緯度経度、特段の代表地点がない場合は代表的な停留所の緯度経度または、親停留所情報[parent_station]で紐付けた標柱の緯度経度を平均した数値を設定。変更なし。
stop_lon経度必須
zone_id運賃エリアID任意標柱の場合のみ設定可。運賃を案内する場合は必須。均一制の場合、運賃エリアを設定。対キロ制の場合、標柱IDを設定。[location_type]を設定した場合、標柱の場合のみ設定可。運賃を案内する場合は必須。均一制の場合、運賃エリアを設定。対キロ制の場合、標柱IDを設定。
stop_url停留所・標柱URL任意停留所・標柱に特化した情報(時刻表やバスロケ等)を案内するための特定のURLがある場合設定。停留所や標柱に紐づくURLがない場合は省略。変更なし。
location_type停留所・標柱区分推奨→任意(Version 2)登録するデータが、停留所なのか標柱なのか設定。停車時刻を設定できるのは標柱のみであることに留意。
 0:標柱
 1:停留所
登録するデータが、停留所なのか標柱なのか設定。値を設定した場合、停車時刻を設定できるのは標柱のみであることに留意。
 0:標柱
 1:停留所
parent_station親停留所情報推奨→任意(Version 2)停留所-標柱の関係を設定することを原則とし、登録するデータが標柱([location_type]=0)の場合、当該標柱が属する停留所([location_type]=1)の停留所ID[stop_id]を設定。停留所-標柱の関係を設定する場合は、登録するデータが標柱([location_type]=0)の場合、当該標柱が属する停留所([location_type]=1)の停留所ID[stop_id]を設定。
stop_timezoneタイムゾーン任意
(不要)
省略した場合、タイムゾーン[agency_timezone(agency.txt)]が設定されるため、日本は設定不要。" 省略した場合、タイムゾーン[agency_timezone(agency.txt)]が設定されるため、日本は設定不要。変更なし。
wheelchair_boarding車椅子情報任意
(不要)
指定した停留所・標柱における車椅子による乗車の可否を設定。バスの場合、停留所・標柱ではなく車両に依存するケースが多いため、当該停留所・標柱に停車するすべての車両が車椅子対応可能な場合で、かつ明確に当該停留所・標柱において車椅子の対応が不可であるようなケースを除き、設定を推奨しない。変更なし。