【データ作成指針たたき台】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
日本の場合、「ja」を設定。

実際の問合せに対応できる電話番号を記載します。なお、路線により営業所等が異なり、各営業所に問合せる必要がある場合には、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車椅子情報任意
(不要)
指定した停留所・標柱における車椅子による乗車の可否を設定。バスの場合、停留所・標柱ではなく車両に依存するケースが多いため、当該停留所・標柱に停車するすべての車両が車椅子対応可能な場合で、かつ明確に当該停留所・標柱において車椅子の対応が不可であるようなケースを除き、設定を推奨しない。変更なし。

Agency.txt version1→version2改定案

論点

  • Agency IDにおいて枝番号を必須にするかオプションとするか。現在の案ではオプションとしている。
  • IDをExcelで開いたときに文字列として認識させるために、枝番を必須とするという意見もあった。

4-2-1. 事業者情報(必須:agency.txt)・事業者追加情報(任意:agency_jp.txt)

事業者の基本的な情報を設定します。事業者名称等が経路検索の結果として表示されます。一度設定した事業者ID[agency_id]は、可能な限り変更しないよう留意が必要です。

フィールド名日本語名区分日本のバス向けの設定項目(version 1)version 2
agency.txt事業者情報必須
★agency_id事業者ID必須事業者の法人番号を設定。
運行委託等を行っている場合、原則として運行委託元の法人番号を設定。自治体等が運営するコミュニティバス等は、原則として運行委託元の法人番号を設定。
事業者の法人番号を設定。
運行委託等を行っている場合、原則として運行委託元の法人番号を設定。自治体等が運営するコミュニティバス等は、原則として運行委託元の法人番号を設定。
ひとつの法人が複数のバスを運営している場合、法人番号のあとアンダーバーを挟んで枝番号を加える。
agency_name事業者名称必須経路検索で案内するのが適当な名称を設定。正式名称である必要はなく、旅客が交通機関を識別しやすい名称を設定。変更無し。
agency_url事業者URL必須原則として、事業者HPのトップページのURLを設定。複数の事業を経営している等の場合、個別の事業ページ(バス事業に関するトップページ等)のURLの設定も可。但し、設定したURLは頻繁な変更がなされないことに留意。
HPがない場合は、その旨を記載。
変更無し。
agency_timezoneタイムゾーン必須 (固定)日本の場合、「Asia/Tokyo」を設定。変更無し。
agency_lang言語任意
(固定)
日本の場合、「ja」を設定。変更無し。
agency_phone電話番号任意全社の窓口となる電話番号(本社代表電話、運輸部門代表電話、お客様センター等)を設定。
運行委託等を行っている場合は、問合せに対応可能な主体の電話番号を設定。"
変更無し。
agency_fare_urlオンライン購入URL任意利用者が乗車券等をオンラインで購入な場合に、そのURLを設定。オンラインで購入不可の場合は省略。変更無し。
agency_email事業者Eメール任意利用者が問合せ等で利用可能なEメールアドレスを設定。変更無し。
フィールド名日本語名区分日本のバス向けの設定項目(version 1)version 2
agency_jp.txt事業者追加情報任意
agency_id事業者ID必須紐づける事業者ID[agency_id(agency.txt)]を設定。変更なし。
agency_official_name事業者正式名称任意申請等に必要な正式名称を設定。変更なし。
agency_zip_number事業者郵便番号任意ハイフンなしの半角数字7桁で設定。変更なし。
agency_address事業者住所任意都道府県から入力。住居表示通りに略さずに全角で設定。変更なし。
agency_president_pos代表者肩書任意申請者の肩書を設定。変更なし。
agency_president_name代表者氏名任意姓と名の間は、全角スペース1文字を挿入。変更なし。

管理人や記事の著者について

本Webページは、東京大学生産技術研究所の伊藤昌毅が個人的に管理しているページです。標準的なバス情報フォーマットを制定した「バス情報の効率的な収集・共有に向けた検討会」において座長を務めましたが、本ページ自体は国土交通省とは独立して運用しております。本ページの記事は、伊藤以外にも関連する方に書いて頂くつもりです。

伊藤昌毅 プロフィール

東京大学生産技術研究所 助教。IT×公共交通を専門とし、産官学を繋ぐ実践志向の研究者。ITと交通とを橋渡しするカンファレンス「交通ジオメディアサミット」の開催や、現場に寄り添った公共交通オープンデータの推進活動などを行っている。国土交通省バス情報の効率的な収集・共有に向けた検討会 座長 (経路案内データの標準化作業検討会)、情報処理学会モバイルコンピューティングとパーベイシブシステム研究会 運営委員、くらしの足をみんなで考える全国フォーラム実行委員地域公共交通総合研究所 研究員など。

標準的なバス情報フォーマット広め隊

標準的なバス情報フォーマットに関わる皆様を、勝手ながら「標準的なバス情報フォーマット広め隊」と呼んでおります。2017年10月28日,29日に開催された「くらしの足をみんなで考える全国フォーラム」にて発表したポスターを公開します。印刷、配布等は自由としますので、標準的なバス情報フォーマットの普及のためにどうぞご利用ください。

印刷用PDF:標準的なバス情報フォーマット広め隊ポスター

公共交通データ議論用メーリングリストを開設しました

GTFSや標準的なバス情報フォーマットに関する話題を扱うメーリングリストを開設しました。国交省「標準的なバス情報フォーマット」の改定案などについてこの場で議論したいと思っています。もちろん、それ以外の話題も扱えればと思います。公共交通データの充実に向けた議論にご関心のある方、是非ご参加下さい。

管理人:伊藤昌毅

1. メンバー

メーリングリストの初期のメンバーは、2017年9月27日に開催した「「標準的なバス情報フォーマット」相互運用性の向上に向けての勉強会」の参加者、それ以外に管理者(伊藤)が聞き及んでいる範囲でのGTFS、標準的なバス情報フォーマット関係者です。1月12日現在で、 IT事業者28名、行政11名、大学など8名、交通事業者6名、その他8名となっています。メーリングリスト参加者一覧は公開の予定はありません。

2. 入退会

入会を希望される場合は、本文の先頭に subscribe Your Name と書いたメール(HTMLメールには対応していません)を discuss-ctl@gtfs.jp まで送り、返信メールの指示に従ってください。管理者が承認した後、入会が完了します。退会されるときは、本文の先頭に bye と書いたメールを discuss-ctl@gtfs.jp まで送ってください。

3. 投稿

MLへの投稿は参加者どなたでも可能です。匿名やハンドルネームも可能ですが、狭いコミュニティですので、顔が見える形での情報発信を推奨します。MLで扱う話題は、GTFSおよび標準的なバス情報フォーマットに関する話題全般と考えており、技術的な議論だけでなく、関連するニュース、商用製品やサービスの宣伝、初心者からのご質問、オフ会のお誘いなどにも自由にお使いください。データそのものだけでなく、データを扱うツールについての議論も歓迎します。ただし投稿出来るメールアドレスは本MLに登録したアドレスのみとなっておりますので、ご所属先とは切り離してご発信したいというような場合は、別途私用のメールアドレスを登録してください。

4. 投稿内容の公開ポリシー

本MLの参加者は特に制限いたしませんので、ご投稿は不特定への公開を前提としてください。しばらく運営して問題が無ければ、過去メールのWeb公開も検討しております。

5. 運営ポリシーなどについて

GTFSや「標準的なバス情報フォーマット」についての情報交換の場の必要性は、多くの方にご理解頂けると思っておりますが、情報交換の場の形式に関しては、様々なご意見があるかと思います。ツールや手段、運営ポリシーなどの提案を歓迎いたします。また、ML以外での議論の場作りも歓迎いたします。