# GTFS各項目の設定方法ガイド（対象者別）ボツ
## はじめに
### 本ガイドブックの目的
+ 本ガイドブックの目的は、次の条件のもとで、質が高く、利用する価値が高いGTFSデータが作成されることです。
+ GTFSの仕様書及びベストプラクティス、標準的なバス情報フォーマット（GTFS-JP）仕様書を踏まえる。
+ Googleが乗換案内にGTFSデータを受け入れる際に行う品質審査の状況を踏まえる。（**※基準が公開されていないので「状況」と記載）**
+ 国内の経路検索サービス事業者（コンテンツプロバイダ、以下「CP」という。）、バスロケーション事業者などのGTFSデータ利用者の要望を踏まえる。
+ バス事業者やコミュニティバスを運行する市町村が持つバス情報の制約及びGTFSデータ作成に要する手間・コストの制約を踏まえる。
+ バス情報を管理しGTFSを出力する機能を持つダイヤ管理システムやGTFSデータ作成ツールの開発者の要望を踏まえる。

### 本ガイドブックの見方
+ GTFS（GTFS-JPで拡張されたファイル、項目を含む）のファイル、項目ごとに設定すべき内容を説明しています。
+ また、次の対象者ごとに行うべき内容を説明しています。
+ GTFS出力機能を持つダイヤ管理システム等の開発者（システム開発者）
+ GTFS出力機能を持つダイヤ管理システム等を利用するバス事業者・市町村（システム利用者）
+ GTFSデータ作成ツールの開発者（ツール開発者）
+ GTFSデータ作成ツールを利用してGTFSを作成するバス事業者・市町村（ツール利用者）
+ ダイヤ管理システム等の利用者においては、システム開発者向けの箇所も一読して参考にしてください。さらに、実際に使われているシステム開発者に、GTFSデータをどのように出力しているか（出力される項目や出力の制限事項などを含む）を確認することを推奨します。
+ （理由）ダイヤ管理システム等からのGTFSデータ出力は、データ入力と直結しておらず、どのようにGTFSデータが出力されているのかが分からないため。
+ その他のGTFSデータを作成する者及びGTFSデータの作成を受託する者は、以上の者に対する説明に準じて、GTFSデータを作成してください。

+ また、本文中では記載の理由を次のように略記しているところがあります。
+ （←GTFS仕様書）：GTFS仕様書の記載によるもの。
+ （←GTFSベストプラクティス）：GTFSベストプラクティスの記載によるもの。
+ （←GTFS-JP仕様書）：GTFS-JP仕様書の記載によるもの。
+ （←Google品質審査例）：Google乗換案内にGTFSデータを提供した際の品質審査で指摘された例によるもの。
+ Google品質審査の指摘は新規にGTFSデータを提供する場合のもので、既にGoogle乗換案内に掲載されているバス事業者・市町村では対応しなくても構いません。
+ **※本当に対応不要か要確認**

---

## 事業者情報（agency.txt）【必須】
### ⇒システム開発者、ツール開発者
#### agency_name（事業者名称）【必須】、agency_id（事業者ID）【必須】、agency_url（事業者URL）【必須】
+ 各項目を入力する画面を作成します。この3項目は必須です。
+ １つのGTFSデータに複数のagencyを含むことが可能（←GTFS仕様書）ですので、複数の事業者情報を入力できる画面を作成することも考えられます。

#### agnecy_timezone（タイムゾーン）【必須】、agency_lang（言語）【必須】
+ 国内では次のとおり固定ですので、GTFSデータにこのとおり出力します。(←GTFS-JP仕様書)
+ agnecy_timezone="Asia/Tokyo"
+ agnecy_lang="ja"
#### agency_phone（電話番号）【任意】、agency_fare_url（オンライン購入URL）【任意】、agency_email（事業者Ｅメール）【任意】
+ 各項目を入力する画面を作成します。この３項目の設定は任意です。設定は任意ですが、システムとしては入力画面は用意しておきます。

### ⇒システム利用者、ツール利用者
+ システムやツールの入力画面に次のように入力します。
#### agency_name(事業者名称)【必須】
+ バス会社、コミュニティバスを運行する市町村名などを設定します。
+ バス事業者名（会社名）、バス名、市町村名、コミュニティバス名、地域のNPOなどの運行団体名などのうちから適切な名称を設定します。
+ ただし、HP（agency_urlで設定したHP）のヘッダー部に表示されるバス事業者名、市町村名、運行組織名を設定することを推奨します。市町村コミュニティバスではHPのヘッダーに市町村名が表示されていることが多いので（コミュニティバス名ではなく）市町村名としておいたほうが無難です。会社名では"株式会社"等が有無も一致させてください。（←Google品質審査例）
+ 例：十勝バス、青森市営バス、山陽タクシー株式会社、南砺市、ぐるっと生瀬運行協議会
+ なお、使用しているシステム・ツールが複数事業者の入力に対応している場合には、１つのGTFSデータの中に複数の事業者を含めることが可能です。

#### agency_id(事業者ID)【必須】
+ バス事業者、市町村の法人番号を設定します。（←GTFS-JP仕様書）同一法人が複数のGTFSデータを作成する場合には、アンダースコア区切りにより枝番号を設定することを推奨します。
+ agency_nameが地域のバス運行協議会などで法人格を持たない場合は、バスが走っている市町村の法人番号を設定します。
+ 例：8000020130001_1
+ 法人番号は国税庁のウェブサイトで検索できます。
+ [国税庁法人番号公表サイト](https://www.houjin-bangou.nta.go.jp/)
#### agency_url（事業者URL）【必須】
+ バス事業者や市町村のHPのトップページではなく、バスの情報のページ（路線図、時刻表、運賃等が掲載されているページ、もしくはこれらのページへのリンクがあるページ）のURLを設定します。（←Google品質審査例）
+ 路線バスだけでなく貸切バスやタクシーなども行っている事業者では路線バスのページのURLを設定します。
+ 市町村ではコミュニティバスのページのURLを記載します。コミュニティバスのページがない場合は、公共交通のページなどコミュニティバスの時刻表などへのリンクがあるページのURLを設定します。（←Google品質審査例）
#### agency_timezone（タイムゾーン）【必須】
+ システム、ツール側が自動で出力する場合は設定不要です。設定画面がある場合は、"Asia/Tokyo"と設定します。（←GTFS-JP仕様書）
#### agency_lang（言語）【必須】
+ システム、ツール側が自動で出力する場合は設定不要です。設定画面がある場合は、"jp"と設定します。（←GTFS-JP仕様書）
#### agnecy_phone（電話番号）【任意】
+　バス利用者が直接問合せできる電話番号を設定します。ない場合は設定しません。（←GTFSベストプラクティス）
#### agency_emial（事業者Eメール）【任意】
+ バス利用者が直接問合せできる電子メールアドレスを設定します。ない場合は設定しません。（←GTFSベストプラクティス）
#### agency_fare_url（オンライン購入URL）【任意】
+ 乗車券や乗車カードをオンラインで購入できるHPのURLを設定します。ない場合は設定しません。（←GTFS仕様書）オンラインで購入不可の場合は設定しません。

---
## 事業者追加情報（agency_jp.txt）【任意】
### この項目の目的
+ agency_jp.txtはバス事業者が国土交通省（地方運輸局）への届出・申請をする際に、GTFSデータを使用して書類を作成したり電子申請することを想定して設定されたものです。
+ さらに、市町村が運行するコミュニティバスについて、補助金申請等の際に利用することも考えられます。
+ **※これは事実か要議論**
### ⇒システム開発者、ツール開発者
#### agency_id（事業者ID）、agency_official_name（事業者正式名称）、agency_zip_number（事業者郵便番号）、agency_address（事業者住所）、agency_president_pos（代表者肩書）、agency_president_name（代表者氏名）
+ 現時点（2021年6月現在）では届出・申請業務におけるGTFSデータの活用は実用化されていないため、このファイルは作成不要ですが、将来、活用が期待されるので、システム開発においては、agency_jp.txtを出力する機能を含めておくことを推奨します。
+ 各項目を入力する画面を作成します。agency_jp.txtを作成する場合はagency_idは必須ですが、agency.txtの入力画面で入力させたものを使用しても構いません。

### ⇒システム利用者、ツール利用者
+ 現時点（2021年6月現在）では届出・申請業務におけるGTFSデータの活用は実用化されていないためこのファイルは作成不要ですが、作成しておいても構いません。
+ このファイルを作成する場合は、システムやツールの入力画面に次のように入力します。（←GTFS-JP仕様書）
#### agency_id（事業者ID）
+ agency.txtで設定したagency_idと同じです。
#### agency_official_name（事業者正式名称）
+ 申請・届出書類等に記載する事業者名称を設定します。
+ 例：霞が関バス株式会社、長野県北佐久郡軽井沢町
#### agency_official_zip_code（事業者郵便番号）
+ ハイフンなしの半角数字７桁で設定します。
+ 例：1000013、3890192
#### agency_address（事業者住所）
+ 都道府県から入力。住居表示、地番表示通りに略さず全角で設定します。
+ 例：東京都千代田区霞が関２丁目１番３号、長野県北佐久郡軽井沢町大字長倉２３８１番地１
#### agency_president_pos（代表者肩書）
+ 申請者の肩書を設定します。
+ 例：代表取締役社長、町長
#### agency_president_name（代表者氏名）
+ 申請者の氏名を設定します。姓と名の間に全角１文字のスペースを空けます。
+ 例：東京　太郎、碓氷　武尊

---
## 停留所・標柱情報（stops.txt）
### 停留所・標柱の説明
+ 標柱はバスを乗り降りする位置を示すポール（ポール以外の塀や壁にバス乗り場であることを示すバス停名や時刻表を貼ったものを含みます）のことです。
+ ただし、道路の片側にしかポールがなくても両方向のバスが止まり、一方向のバスはポールからみて道路の反対側で乗降する場合には、道路の反対側にもポールがあるものとします。
+ 停留所は同名の標柱（上り、下り、１番乗り場、２番乗り場など）をまとめたものです。標柱と停留所は対応関係（親子関係）にあるため、停留所を「親停留所」と呼ぶことがあります。
+ 経路検索サービスでは乗降場所を正確に示す必要があるときには標柱の位置を案内しますが、多数の標柱を地図上や検索結果で表示すると煩雑になることから停留所単位で案内表示をするほうが適当な場合あります。このため、停留所の情報も重要です。
+ ただし、現時点（2021年6月）で、Google乗換案内のGTFS品質審査において、親停留所データを設定する条件が限定されている（建物があるバスターミナルに限る）ため、親停留所をGTFSデータに含めないことが多くなっています。
+ なお、現在、建物以外の親停留所を設定する仕様が検討されており、GTFSデータを出力するシステムを開発する際には、location_typeとparent_stationを出力する機能を含めて開発されることを推奨します。

### ⇒システム開発者
+ ここでは、ダイヤ管理システム等でバス停情報を管理し、バス停ID、バス停名、座標等の情報を保持しているものとして説明します。
+ ダイヤ管理システム等で保持しているバス停に関する情報をGTFSデータに出力機能を開発します。
+ ダイヤ管理システム等で保持していない項目については、必要に応じて追加の入力機能を持たせてください。
#### stop_id（停留所・標柱ID）【必須】
+ ダイヤ管理システム等で使用しているIDを出力することを原則とします。
+ ただし、ダイヤ改正などでGTFSを更新するときでもstop_idは変更しないようにします。また、バス停名の変更があったときでもstop_idは継承することとします。
+ （理由）経路検索事業者においては地図データベースにおいてバス停と周辺の施設等を結び付けて管理しており、stop_idを変更するとデータメンテナンスの手間が生じ、新しいダイヤの反映が遅れてしまうおそれがある。
#### stop_code（停留所・標柱番号）【任意】
+ 停留所ナンバリングに相当する記号・番号を出力します。特にない場合はこの項目は出力しません。
#### stop_name（停留所・標柱名称）【必須】
+ システム内で保持している停留所名を出力します。
+ 停留所名には副名称を記述しても構いません。
+ 例：八丁堀（福屋前）
#### stop_desc（停留所・標柱付加情報）【任意】
+ 情報を入力できる機能の開発を推奨します。
#### stop_lat（緯度）、stop_lon（経度）【必須】
+ システムが保持している座標を出力します。
+ 座標はバス停の代表点ではなく、標柱ごとに管理できるようにします。
+ 座標の精度の向上、バス停の新設・移設時の座標取得を容易にするため、システムに座標取得機能を付加することも考えられます。
#### zone_id（運賃エリアID）
+ ダイヤ管理システム等が保持している運賃データから出力します。システムが運賃データをもっていない場合には、運賃システムと連携して運賃データを出力します。
+ この標柱を通る路線がすべて均一運賃の場合は、設定不要です。
+ ゾーン制運賃の場合は運賃ゾーンIDを設定します。
+ それ以外の場合は標柱ごとに任意のIDを設定してよいのですが、stop_idと同じものを設定しておくことを推奨します。
+ 運賃情報の設定方法は、運賃情報の項で詳しく説明します。

### ⇒システム利用者
+ システム利用者は、日常のダイヤ管理業務においてシステムを利用していれば、GTFSデータ作成に必要な情報はシステム内に保持されています。
+ ただし、システムに入力機能がない項目、システムがGTFSデータ出力機能を持たない項目については、GTFSデータに含めることができません。
+ また、次の項目については、GTFSデータの品質向上のため留意してください。
#### stop_id（停留所・標柱ID）【必須】
+ ダイヤ改正などでGTFSを更新するときでもstop_idは変更しないようにします。また、バス停名の変更があったときでもstop_idは継承することとします。
+ （理由）経路検索事業者においては地図データベースにおいてバス停と周辺の施設等を結び付けて管理しており、stop_idを変更するとデータメンテナンスの手間が生じ、新しいダイヤの反映が遅れてしまうおそれがある。
#### stop_desc（停留所・標柱付加情報）【任意】
+ 停留所・標柱に隣接する施設等に関する付加情報を設定します。（←GTFS-JP仕様書）
+ 現時点では、stop_descに記述した内容は、経路検索結果に必ずしも表示されるわけではありません。
+ ※この情報がCPでどのように利用されているのか要確認。
+ ※GTFS仕様書では、単に「場所の説明」と定義されている。
+ ※また、停留所に関する何等かの注意書きを記載することは適当なのかも要議論。
#### stop_lat（緯度）、stop_lon（経度）【必須】
+ 標柱の座標はバスを待つ位置（ポールの位置。ポールからみて道路の反対側からも乗降するときは反対側の位置も。）の座標を設定することを基本とします。
+ ただし、システム内で標柱（ポール）だけ管理している場合には、ポールの位置だけでも構いません。
+ Google乗換案内のGTFS品質審査では誤差5mを目安としています。標柱の位置を道路や交差点の真ん中にとると不正確な案内になってしまいますので、座標を修正してください。
+ 標柱の座標データの取得方法、精度の向上については、別稿「標柱座標の取得方法及び精度の向上ガイド」（**※未作成**）をご覧ください。
#### zone_id（運賃エリアID）【条件付き必須】
+ ダイヤ管理システム等にデータを入力してあれば、システムから運賃データが出力されます。

### ⇒ツール開発者
#### stop_id（停留所・標柱ID）【必須】、stop_code（停留所・標柱番号）【任意】、stop_name（停留所・標柱名称）【必須】、stop_desc（停留所・標柱付加情報）【任意】、stop_lat（緯度）【必須】、stop_lon（経度）【必須】、zone_id（運賃エリアID）【条件付き必須】、stop_url（停留所・標柱URL）【任意】、location_type（停留所・標柱区分）【任意】、parent_station（親停留所情報）【任意】、stop_timezone（タイムゾーン）【不要】、wheelchair_boarding（車椅子情報）【不要】、platform_code（のりば情報）【任意】
+ 各項目を入力する画面を開発します。
+ ツール内で生成できる項目については、入力画面を省略しても構いません。
#### stop_lat（緯度）、stop_lon（経度）【必須】
+ 座標の精度の向上、バス停の新設・移設時の座標取得を容易にするため、システムに座標取得機能を付加することも考えられます。
#### zone_id（運賃エリアID）【条件付き必須】

### ⇒ツール利用者
+ ツールの入力画面に次のように入力します。
#### stop_id（停留所・標柱ID）【必須】
+ バス事業者、市町村において標柱を内部的に管理しているIDがあるときは、そのIDをstop_idとします。
+ 1_1、1_2のようにアンダースコアの前に停留所の番号をつけ、アンダースコアのあとの枝番で標柱を区分するといった方法が分かりやすいでしょう。
+ ダイヤ改正などでGTFSを更新するときでもstop_idは変更しないようにします。また、バス停名の変更があったときでもstop_idは継承することとします。
+ （理由）経路検索事業者においては地図データベースにおいてバス停と周辺の施設等を結びつけて管理しており、stop_idを変更するとデータベースメンテの手間が生じ、新しいダイヤの反映が遅れてしまうおそれがある。
#### stop_code（停留所・標柱番号）【任意】
+ 駅ナンバリングに相当する記号・番号を設定します。特にない場合はこの項目は設定しません。
#### stop_name（停留所・標柱名称）【必須】
+ 停留所名を設定します。
+ HP等で公表している時刻表に記載されている名称と一致させることを推奨します。（←GTFSベストプラクティス）
+ 停留所名には副名称を記述しても構いません。
+ 例：八丁堀（福屋前）
+ 乗り場番号（１番のりば、２番のりばなど）は後述のplatform_codeに設定するので、ここには含めません。
+ 例：×柏駅西口（2番のりば）
+ **※親停留所との関係でplatform_codeを設定できなかった事例の扱いは要検討**
#### stop_desc（停留所・標柱付加情報）【任意】
+ 停留所・標柱に隣接する施設等に関する付加情報を設定します。（←GTFS-JP仕様書）
+ 現時点では、stop_descに記述した内容は、経路検索結果に必ずしも表示されるわけではありません。
+ ※この情報がCPでどのように利用されているのか要確認。
+ ※GTFS仕様書では、単に「場所の説明」と定義されている。
+ ※また、停留所に関する何等かの注意書きを記載することは適当なのかも要議論。
#### stop_lat（緯度）、stop_lon（経度）【必須】
+ 標柱の座標はバスを待つ位置（ポールの位置。ポールからみて道路の反対側からも乗降するときは反対側の位置も。）の座標を設定することを基本とします。
+ ただし、ポールの管理台帳などに記載された座標から座標データを作成する場合はポールの位置だけでも構いません。
+ Google乗換案内のGTFS品質審査では誤差5mを目安としています。標柱の位置を道路や交差点の真ん中にとると不正確な案内になってしまいますので避けてください。
+ 標柱の座標データの取得方法、精度の向上については、別稿「標柱座標の取得方法及び精度の向上ガイド」（**※未作成**）をご覧ください。
#### zone_id
+ この標柱を通る路線がすべて均一運賃の場合は、設定不要です。
+ ゾーン制運賃の場合は運賃ゾーンIDを設定します。
+ それ以外の場合はstop_idと同じものを設定しておきます。
+ 運賃情報の設定方法は、運賃情報の項で詳しく説明します。
#### location_type
+ 停留所には"1"を、標柱には"0"を設定します。
+ ただし、現在（2021年6月）、Googleの品質審査では、ここを"1"とする停留所は建物を持つバスターミナルに限定されているため、停留所のデータは設定しておかないほうが無難です。
+ なお、親停留所の設定条件について新しい仕様（建物がないバスターミナルや路上の標柱をまとめた場合を含む）が検討されており、今後、親停留所を設定することが推奨されるようになる可能性があります。GTFSデータを作成するシステムを開発する際には、親停留所を設定する機能を含めておくことを推奨します。
#### parent_station
+ 標柱の親停留所のstop_idを設定します。親停留所を設定していない場合は不要です。
#### stop_timezone
+ GTFS-JPではagency_timezoneを設定するので、stop_timezoneは不要です。
#### platform_code
+ 乗り場の番号を設定します。数字・記号のみを記述します。
+ これまで、Google乗換案内のGTFS品質審査では、platform_codeを設定した場合には親停留所の設定も必要とされ、一方、建物がない親停留所（location_type=1）が認められていなかったため、事実上、platform_codeが記述できませんでしたが、最近、親停留所がなくてもplatform_codeの設定が認められる例も出てきています。

## 経路情報（routes.txt）
### 設定ガイド
#### 経路（ルート）の説明
+ いわゆる「路線」として、１つの路線名のもとで認識され、案内されているものをルート(route)としてIDをつけ設定します。具体的には次の要件を考慮します。
1. 同一路線名は一つのルートとし、上り・下り、右回り・左回り、途中止まり、途中始発、若干の経由違いなども区別せず一つのルートとする。
2. 路線名、路線番号・系統番号、路線図等での表示色が異なるものは別々のルートとする。
3. 運賃が異なるもの（深夜便など）は別々のルートする。
+ 1.はGTFSベストプラクティスで示されている要件です。Google乗換案内のGTFS品質審査でもこの点を求められます。
+ 2.3.はGTFSの仕様として、別々のルートとしないと路線名や運賃が記述できません。
+ 2.3.の理由でルートを分けて設定したときは、Google乗換案内のGTFS品質審査を開始する際にGoogleに説明しておくとよいでしょう。
+ バスロケ等で使用するために便の停車パターン（始発から終点までの停車するバス停の並び）を区別して表現したいときは、jp_pattern_idを使用します。jp_pattern_idはtrips.txtに記述します。
+ ルートの設定例１（兵庫県猪名川町）
+ 時刻表では「青ルート」、「緑ルート」、「赤ルート」、「黄ルート」の４つのルートで案内しており、GTFSでもこの４つのルートを設定しています。各ルートには往復や行先・経由が異なるものを含んでます。
+ route_long_nameにはコミュニティバス名を含めて「ふれあいバス・青ルート」のように記述しています。
+ [猪名川町コミュニティバス路線図・時刻表](https://busdata.or.jp/files/inagawa.pdf)

+ ルートの設定例２（）
+ ルートの設定例３（）

#### route_id
+ ダイヤシステムなどでルートを管理しているIDがあれば、それをそのまま使います。
#### agency_id
+ agency.txtで記述したagency_idを設定します。
#### route_short_name
+ 系統番号（例：「東01」）を設定します。現在（2021年6月）、6文字までという制限があります。記号・符号のみを記述し、路線名などは記載しないようにします。
+ 系統数の多いバス事業者などでバスの方向幕、ＨＰやバス停表示で主に系統番号で案内をしている場合には、route_short_nameを設定します。
#### route_long_name
+ 路線名を設定します。コミュニティバスなどの名称を案内する必要があるときはそれも含めて記述します。系統番号がなくroute_short_nameを設定できない場合は、route_long_nameに路線名を設定します。
+ 例：「ふれあいバス・赤ルート」
+ route_short_nameとroute_long_nameはどちらか一つは必ず設定する必要がありますが、Google乗換案内では両方が記述されている場合、route_short_nameしか検索結果に表示されません。このため系統番号と路線名の両方を表示したい場合にはroute_long_nameに両方を設定します。
+ 例：東０１市民病院線
#### route_desc
+ 現時点では、route_descに記述した内容は、経路検索結果に必ずしも表示されるわけではありません。
#### route_color
+ HPで公開している路線図や時刻表で使用している路線の色を設定します。
+ Google乗換案内のGTFS品質審査では、route_colorを設定するよう指摘されることが多くあります。また、路線図等の色と一致していることが求められます。
#### route_text_color
+ route_colorが濃い色のときは薄い色（例えば白）、route_colorが薄い色のときは濃い色（例えば黒）を設定します。
+ route_colorとroute_text_colorのコントラストがないと、FeedValidatorで警告が出て、Google乗換案内のGTFS品質審査で指摘されることが多くあります。
#### jp_parent_route_id
+ ルートの設定には、路線名、運賃等が異なるものは別々のルートするなどの要件がありますので、これらの要件により分けざるをえなかったルートをまとめて取り扱う必要があるときに設定します。
+ 特に必要がない場合はこの項目は設定不要です。

## 便情報（trips.txt）
### 設定ガイド
#### 便の単位について
+ 便は、１つの路線の中で始発バス停から終点バス停までを走る１回の運行を単位とします。ダイヤ管理システムや時刻表で１つの便としているものをそのまま使用します。
+ JR山手線のように環状の路線を複数回回り続ける場合は、１周を１便とし、GTFSの「便結合」で連続する便を結合し、継続して乗車できることを表現します。
#### trip_id
+ 通し番号のような付け方でも構いませんが、GTFS作成ツール等では視認性を高めるため、route_id、系統番号、service_id、始発時刻、direction_id、便番号などを組み合わせて生成しています。
+ 例："平日_05時35分_系統101"、"1全日_08時20分_系統111001"、1+1+平土+1"
#### trip_headsign
+ 便の行き先を設定しますが、バス車体での表示（方向幕など）、ＨＰ掲載の時刻表での表示、バス停での表示などに一致させることを推奨します。
+ 始発バス停に戻ってくる循環路線の場合、行き先＝始発バス停名 とならないようにし、途中の主なバス停名、団地名、施設名などに"方面"を付けることを推奨します。"方面"を付けるのはそこが終点でないことを示すためです。
+ ただし、バスの方向幕やＨＰ、バス停の表示が循環路線であることを示すものとなっている場合はその通りに記載します。
+ 例："ひばりが丘団地方面"、"柏市内循環"
+ 循環路線であってもなくても、途中で方向幕やバス停での行先の案内が変わるときは、stop_times.txtのstop_headsignで途中から行き先表示を変更することができます。後述のstop_headsignの項を参照してください。
#### trip_short_name
+ 便に固有の名称がある場合に設定します。路線の愛称（例："空港シャトル"、"市民病院連絡バス"）やバス車両の愛称（例："そよかぜ号"）などは設定できません。特に便に固有の名称がなければ設定は不要です。
#### direction_id
+ バスの上り・下り、行き・帰り、右回り・左回りなどを区別するために設定します。上り・下り等の区分を明示しておくと、時刻表の作成、バスデータの集計や分析などのGTFSデータ利用時に便利なことが多いため、設定することを推奨します。
+ 復路（帰り）を"0"、往路（行き）を"1"と設定することなっていますが、上り・下りはどちらを"1"と設定しても構いません。
#### block_id
+ X便（始発：Aバス停→終着：Bバス停）とY便（始発：Bバス停→終着：Cバス停）があったとき、X便の車両がそのままY便になり、乗客もBバス停で降りずにそのまま乗車していられるとき、X便とY便は連続便であるといいます。
+ 連続便であるX便とY便のblock_idに同じIDを設定します。さらに、Y便とZ便が連続便である場合には、Z便のblock_idにも同じIDを設定します。
#### shapes_id
+ shapes.txt（バスの走行するルートの座標データ）を作成している場合に設定します。shapes.txtがない場合は設定しません。詳細はshapes.txtの項をご覧ください。
#### jp_trip_desc
+ 運行日情報（calendar.txt、calendar_dates.txt）で表現できない運行日情報（"学休日運休"）や便に固有の情報（"ボンネットバスで運行"）などを設定できます。
+ ただし、現時点では経路検索結果などで表示されるとは限りません。
+ **※CPなどに要確認**
#### jp_trip_desc_symbol
+ 時刻表作成時に便に補足情報をつける符号を設定できますが、GTFS-JPに凡例情報（符号が何を意味するかの説明）を記がないため、この項目を設定する意義はあまりありません。
#### jp_office_id
+ 忘れ物や定期運賃の問合せなどのために、乗換案内結果にバスの営業所の連絡先を表示するために利用されます。詳細はjp_office.txtの項をご覧ください。
+ **※CPに実際に利用しているか、必要か要確認**
#### jp_pattern_id
+ GTFSデータをバスロケや音声案内合成などで利用する場合に、停車パターン（バス停の並び順）の情報が必要な場合に設定します。GTFSデータがこれらの用途に使用される場合に、バス事業者・市町村がバスロケや音声案内合成事業者などと協議して、どのように設定するかを決めてください。
+ GTFS-JPの仕様書では、具体的にどのようなバス停並びなのかを記述するかが定められていないため、上記のように用途が特定されている場合でなければ設定不要です。

## 営業所情報（office_jp.txt）
### 設定ガイド
+ 忘れ物や定期運賃等の問合せ先となる営業所の情報を設定します。
+ コミュニティバスでfeed_infoの運行事業者（agency）を市町村とした場合、運行を委託しているバス・タクシー事業者等の連絡先をここに設定することができます。

## 停車パターン情報（pattern_jp.txt）
### 設定ガイド
+ この項目はバスロケシステムなどの特定の利用者がGTFSデータを利用する際に必要となる項目ですので、どのように設定するかは利用者と協議の上決めてください。
#### jp_pattern_id
+ データ利用者と協議のうえ決めてください。
#### origin_stop、via_stop、destination_stop
+ GTFS-JPの初版ではバス事業の申請業務用に設定されていた項目ですが、jp_pattern_idの利用者が限定されるため、これらの項目の設定の必要性も含めてデータ利用者と協議して決めてください。

## 通過時刻情報（stop_times.txt）
### 設定ガイド

## 運行区分情報（calendar.txt）
### 設定ガイド
+ 運行日の設定は、calendar.txtで曜日単位に運行する（しない）を設定し、calendar_dates.txtで祝日、お盆、年末年始などの曜日に係わらず運行する（しない）を設定します。
+ ただし、お盆ダイヤ、年末年始ダイヤのように数日のみのダイヤの場合は、calendar.txtには設定せず、calendar_dates.txtに運行する年月日のみを設定することでも構いません。

#### service_id
+ GTFS-JP仕様書では、「標準の８区分のservice_idについてはcalendar_dates.txtでの祝日設定を行わなくても国内CPでは祝日を考慮した案内を実施」と記載してありますが、Google乗換案内をはじめ、その他の利用者も間違いなく利用できるようにcalendar_dates.txtで祝日設定してください。

#### start_date、end_date
+ service_idで示される運行区分（平日、土休日など）の有効期間を設定します。これにより例えば「平日夏：20210401、20210930」、「平日冬：20211001、20220331」と設定すれば、夏ダイヤと冬ダイヤを表現することができます。
+ feed_info.txtで設定するGTFSデータ全体の有効期間を「20210401、20220331」と設定し、calendar.txtの設定を「毎日：20210401、20210930」とだけすると、20211001～20220331の期間は全便運休という意味になります。

## 運行日情報（calendar_dates.txt）
### 設定ガイド
+ 祝日は毎年日付が変わりますので、間違えないように毎年データ更新を行ってください。お盆、年末年始の運行日の設定も忘れずにしてください。
+ 特に2021年はオリンピック開催のため祝日が変更されていますので注意してください。
+ 春分の日、秋分の日は天文暦により決まります。正式には前年２月に官報告示されますが、国立天文台のHPに将来の春分日、秋分日の予想が掲載されています。
+ [何年後かの春分の日・秋分の日はわかるの？](https://www.nao.ac.jp/faq/a0301.html)

## calendar.txtとcalendar_dates.txtの組み合わせ例（特殊ケース）
### 設定ガイド
#### 例１：お盆ダイヤ（2021年8月13日（金）～16日（月）に適用）
+ 例1-1 service_idの"平日"、"土休日"、"お盆"をcalendar.txtで定義し、"平日"、"土休日"についてcalendar_dates.txtでお盆期間の運行を除外する。
**calendar.txt**

|service_id|monday|tuesday|wednesday|thursday|friday|saturday|sunday|start_date|end_date|
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 平日 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |20210401|20220331|
|土休日| 0 | 0 | 0 | 0 | 0 | 1 | 1 |20210401|20220331|
| お盆 | 1 | 0 | 0 | 0 | 1 | 1 | 1 |20210813|20210816|

**calendar_dates.txt**
|service_id|date|exception_type|
| --- | --- | --- |
|土休日|20210814|2|
|平日|20210813|2|
|土休日|20210815|2|
|平日|20210816|2|

+ 例1-2 service_idの"お盆"はcalendar.txtに定義せず、calendar_dates.txtでお盆期間の運行を設定する.
**calendar.txt**

|service_id|monday|tuesday|wednesday|thursday|friday|saturday|sunday|start_date |end_date |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | ---|
| 平日 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |20210401|20220331|
|土休日| 0 | 0 | 0 | 0 | 0 | 1 | 1 |20210401|20220331|

**calendar_dates.txt**

|service_id|date|exception_type|
| --- | --- | --- |
|お盆|20210813|1|
|平日|20210813|2|
|お盆|20210814|1|
|土休日|20210814|2|
|お盆|20210815|1|
|土休日|20210815|2|
|お盆|20210816|1|
|平日|20210816|2|

#### 例２：行楽期間中（4月29日～5月6日、7月20～8月31日）のみ運行する
+ calendar.txtの期間（開始日、終了日）は１つしか記述できないので、service_id="行楽期間"はcalendar.txtには設定せず、calendar_dates.txtに運行日をすべて列挙する。
**calendar_dates.txt**

| --- | --- | --- |
|service_id|date|exception_type|
|行楽期間|20210429|1|
|行楽期間|20210430|1|
|～|～|～|
|行楽期間|20210506|1|
|行楽期間|20210720|1|
|～|～|～|
|行楽期間|20210831|1|

## 運賃属性情報（fare_attributes.txt）
### 設定ガイド

## 運賃定義情報（fare_rules.txt）
### 設定ガイド

## 描画情報（shapes.txt）
### 設定ガイド
+ GTFSデータをバスロケで使用する場合、正確な路線図を作成したい場合、経路検索結果で正確なバスルートを表示したいなどの理由がある場合には、設定することを推奨します。
+ GTFSデータの整備をshapes.txtも含めて外注した場合、データ更新時にshapes.txtの更新が困難になる場合がありますので、更新体制について検討しておくことが必要です。

## 運行間隔情報（frequencies.txt）
### 設定ガイド
+ この項目は定められた時刻表がなく、運行間隔だけが決まっている場合に設定しますが、それ以外の場合には設定は不要です。

## 乗換情報（transfers.txt）
### 設定ガイド

## 提供情報（feed_info.txt）
### 設定ガイド
#### feed_publisher_name
+ ここにはバス事業者、市町村もしくはこれらからGTFSデータの作成・公開を委託されている会社の名称を設定します。
+ GTFSデータがバス事業者、市町村が自らもしくはこれらからの委託により作成されたものでない場合には、データ作成・公開する者の名称を設定します。
#### feed_start_date、feed_end_date
+ データの有効期間の設定については、別稿（GTFSデータの作成期間と有効期間の設定方法ガイド）で説明します。

## 翻訳情報（translations.txt）
### 設定ガイド