# GTFS各項目の設定方法ガイド
+ **※GTFS-JP（第３版）の仕様書は2021年7月30日現在の公表版**
+ **※GTFS仕様書、GTFS-JP仕様書の該当箇所はリンクで表示**

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

### 本ガイドブックの見方
+ GTFS（GTFS-JPで拡張されたファイル、項目を含む）のファイル、項目ごとに設定すべき内容を説明しています。
+ 適宜、このような説明とした理由を記載しています。記載の理由を次のように略記しているところがあります。
+ （←GTFS仕様書）：GTFS仕様書の記載によるもの。
+ （←GTFSベストプラクティス）：GTFSベストプラクティスの記載によるもの。
+ （←GTFS-JP仕様書）：GTFS-JP仕様書の記載によるもの。
+ （←Google品質審査例）：Google乗換案内にGTFSデータを提供した際の品質審査で指摘された例によるもの。
+ GTFS仕様書、GTFSベストプラクティスは適宜、改訂がなされるものです。本ガイドブックでは2021年6月現在のものを参照しています。
+ ファイル名、フィールド名に記載してある【必須】、【条件付必須】、【任意】は次のような意味です。
+ 【必須】どのGTFSデータでも必ず含まなければならないファイル、フィールド
+ 【条件付必須】２つのフィールドのうちどちらかは必ず必要な場合のように、条件によって必須となるファイル、フィールド
+ 【任意】必要に応じて設定するファイル、フィールド。ただし、GTFSデータ作成者の自由な選択に任されているものではなく、GTFSデータを正しく利用してもらうためには、一定の条件下では必ず設定すべき場合もあります。例：途中で行き先表示が変わる場合のstop_headsign

### 既にGoogle乗換案内に掲載されているGTFSデータの取扱い
+ Google品質審査の指摘は新規にGTFSデータを提供するときに行われます。既に審査を通って掲載済のバスについてGTFSデータを更新しアップロードするときには、原則、再度の品質審査は行われないため、現在のGoogleの審査基準に沿わないGTFSデータでも、すぐに支障が生じるわけではありません。
+ ただし、将来、Googleが提供されたGTFSデータをチェックする可能性がありますので、本ガイドラインに沿ってGTFSデータを更新することを推奨します。

+ **※新しいvalidatorでエラー、警告になる事象への対応をどこまでどう記載するか要検討**
　　+ Error：旧方式のtranslations.txt
　　+ Warning：non ascii or non printabal char

---
## 事業者情報（agency.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#agencytxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F01_agency.txt.PNG)
### 各項目の設定ガイド
#### agency_name（事業者名称）【必須】
+ 経路検索で案内するのが適当な名称を設定します。（←GTFS-JP仕様書）
+ バス事業者名（会社名）、バス名、市町村名、地域のNPOなどの運行団体名などのうちバス停、ＨＰやチラシなどに掲載している利用者が分かりやすい名称を設定します。
+ 例：十勝バス、青森市営バス、山陽タクシー、南砺市、ぐるっと生瀬運行協議会
+ コミュニティバス名（例：ふれあいバス）はagency_nameには記載せず、routes.txtのroute_long_nameに記載します。
+ Google乗換案内のGTFS品質審査では、HP（agency_urlで設定したHP）に掲載されている名称とするよう指摘されることがあります。（←Google品質審査例）ただし、ＨＰのヘッダーには会社の正式名称が記載されていても、バス停等には通称のバス名が記載されているある場合には、agency_nameにはバス名を設定するのが適当です。Google品質審査で指摘された場合にはその旨説明説明してください。
+ 例：×東埼玉運輸株式会社　○東さいたまバス
+ なお、１つのGTFSデータの中に複数の事業者を含めることが可能です。この場合、agency_id、agency_nameなどに複数のデータを設定することになります。

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

---
## 事業者追加情報（agency_jp.txt）【任意】
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F02_agency_jp.txt.PNG)
### 概要
+ agency_jp.txtはバス事業者が国土交通省（地方運輸局）への届出・申請をする際に、GTFSデータを使用して書類を作成したり電子申請することを想定して設定されたファイルです。
+ 現時点（2021年6月現在）では届出・申請業務におけるGTFSデータの活用は実用化されていないため、このファイルは作成不要です。
+ ただし、将来、活用が期待されるので、GTFSデータを出力するシステムを開発する際には、agency_jp.txtを出力する機能を含めておくことを推奨します。
+ 各フィールドには、国土交通省への届出・申請を行う際に記載しているものを設定します。
### 各項目の設定ガイド
#### 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）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#stopstxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F03_stops.txt.PNG)

### 停留所・標柱の説明
+ 標柱はバスを乗り降りする位置を示すポール（ポール以外の塀や壁にバス乗り場であることを示すバス停名や時刻表を貼ったものを含みます）のことです。
+ ただし、道路の片側にしかポールがなくても両方向のバスが止まり、一方向のバスはポールからみて道路の反対側で乗降する場合には、道路の反対側にもポールがあるものとします。
+ 停留所は同名の標柱（上り、下り、１番乗り場、２番乗り場など）をまとめたものです。標柱と停留所は対応関係（親子関係）にあるため、停留所を「親停留所」と呼ぶことがあります。
+ 標柱データは、乗換案内でバスの乗降場所を正確に示し、出発地・目的地からバス停までの徒歩ルートを正確に表示するために用いられます。GTFSデータでは標柱ごとに座標データを作成することを原則とします。
+ 停留所データは、多数の標柱を地図上や検索結果で表示すると煩雑になる場合に簡潔にバス停の情報を示し、分かりやすい表示にするために用いられます。また、バスデータの分析などでバス停ごとの集計や表示を行う場合に用いられます。
+ ただし、現時点（2021年6月）で、Google乗換案内のGTFS品質審査において、親停留所データを設定する条件が限定されている（建物があるバスターミナルに限る）ため、親停留所をGTFSデータに含めないことが多くなっています。
+ なお、親停留所の設定条件について新しい仕様（建物がないバスターミナルや路上の標柱をまとめた場合を含む）が検討されており、今後、親停留所を設定することが推奨されるようになる可能性があります。GTFSデータを作成するシステムを開発する際には、親停留所を設定する機能を含めておくことを推奨します。
### 各項目の設定ガイド
#### stop_id（停留所・標柱ID）【必須】
+ バス事業者、市町村において標柱を内部的に管理しているIDがあるときは、そのIDをstop_idとします。
+ 改めて標柱にIDを付ける場合には、1_1、1_2のようにアンダースコアの前に停留所の番号をつけ、アンダースコアのあとの枝番で標柱を区分するといった方法が分かりやすいでしょう。
+ ダイヤ改正などでGTFSを更新するときでもstop_idは変更しないようにします。また、バス停名の変更があったときでもstop_idは継承することとします。（←GTFSベストプラクティス、GTFS-JP仕様書）
+ （理由）経路検索事業者においては地図データベースにおいてバス停と周辺の施設等を結び付けて管理しており、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以内としています。（←GTFSベストプラクティスでは4m以内）
+ 標柱の位置を道路や交差点の真ん中にとると不正確な案内になってしまいますので避けてください。
+ 緯度、経度は10進数の度単位で設定します。度分秒単位は不可です。また、緯度と経度を逆に設定しないように注意してください。
+ ○139.5（139.5度）　×1393000（139度30分00秒）
+ 標柱の座標データの取得方法、精度の向上については、別稿「標柱座標の取得方法及び精度の向上ガイド」（**※未作成**）をご覧ください。
#### zone_id（運賃エリアID）【条件付必須】
+ この項目は、運賃情報の設定方法によって変わります。詳細は運賃情報の項目を参照してください。運賃情報の項目での説明での推奨方法を採用すると、設定は次のようになります
+ この標柱を通る路線がすべて均一運賃の場合は、設定不要です。
（理由）均一運賃の場合は運賃を路線単位で指定できる。
+ この標柱を通る路線がすべて均一運賃かゾーン制運賃の場合は運賃ゾーンIDを設定します。
+ それ以外の場合はstop_idと同じものを設定します。

#### location_type（停留所・標柱区分）【任意】
+ 停留所には"1"を、標柱には"0"を設定します。
+ ただし、現在（2021年6月）、Googleの品質審査では、ここを"1"とする停留所は建物を持つバスターミナルに限定されています。（←Google品質審査例）また、親停留所を設定すると、Googleマップ上でバス停アイコンが代表点１つになり標柱ごとにバス停アイコンが表示されなくなるため、停留所のデータは設定しないことを推奨します。
+ なお、現在、建物以外の親停留所を設定する仕様が検討されており、GTFSデータを出力するシステムを開発する際には、location_typeと次項のparent_stationを出力する機能を含めて開発することを推奨します。
#### parent_station（親停留所情報）【任意】
+ 標柱の親停留所のstop_idを設定します。親停留所を設定していない場合は不要です。
+ 停留所には設定しません。
#### stop_timezone（タイムゾーン）【不要】
+ stop_timezoneは不要です。
+ （理由） GTFS-JPではagency_timezoneを設定する。
#### wheelchair_boarding（車椅子情報）【不要】
+ 設定を推奨しない。
+ （理由）バスの場合、車椅子の利用可否は停留所・標柱ではなく車両に依存するケースが多いため。（←GTFS-JP仕様書）
#### platform_code（のりば情報）【任意】
+ 乗り場の番号を設定します。数字・記号のみを記述します。
+ これまで、Google乗換案内のGTFS品質審査では、platform_codeを設定した場合には親停留所の設定も必要とされ、一方、建物がない親停留所（location_type=1）が認められていなかったため、事実上、platform_codeが記述できませんでしたが、最近、親停留所がなくてもplatform_codeの設定が認められる例も出てきています。

---
## 経路情報（routes.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#routestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F04_routes.txt.PNG)

### 経路（ルート）の設定方法
+ いわゆる「路線」として、１つの路線名のもとで認識され、案内されているものをルート(route)の単位としてIDをつけ設定します。
+ ただし、系統番号が異なる、路線色が異なる、運賃が異なる場合には別々のルートとしてIDをつけます。
#### 例１：路線名ごとに設定
+ 基本的には路線名ごとに集約します。（←Googleベストプラクティス）


#### 例２：系統番号ごとに設定
+ 系統ごとに案内の単位が異なる（バスに表示する系統番号が異なる）場合は、案内の単位ごとに集約します。
+ （理由）：ルートを分けないと異なる系統番号を定義できない。


#### 例３：案内の単位（路線色）ごとに設定
+ 系統ごとに案内の単位が異なる（シンボルカラーが異なる）場合は、案内の単位ごとに集約します。
+ （理由）：ルートを分けないと異なる路線色を定義できない。


#### 例４：運賃が異なる系統をルートを分ける
+ 深夜バス等、運賃が異なる系統がある場合、運賃が異なる系統はルートを分けます。
+ （理由）：ルートを分けないと運賃を定義できない。


+ 例２～例４のようにベストプラクティスに示された方法でない方法でルートを分けて設定したときは、Google乗換案内のGTFS品質審査を開始する際にGoogleに説明しておくとよいでしょう。

### jp_pattern_idによる系統の表現
+ バスロケーションシステムなどで個々の系統のデータが必要な場合には、jp_pattern_idで設定します。
+ jp_pattern_idはtrips.txtに記述します
+ 上記の例２の場合の設定例


### 各項目の設定ガイド
#### route_id（経路ID）【必須】
+ ダイヤシステムなどでルートを管理しているIDがあれば、それをそのまま使います。
#### agency_id（事業者ID）【必須】
+ agency.txtで記述したagency_idを設定します。
+ 一つのGTFSデータに複数の事業者を含む場合は、当該経路を運行する事業者のagency_idを設定します。
#### route_short_name（経路略称）【条件付き必須】
+ route_short_nameと次のroute_long_nameはどちらか一方は設定する必要があります。
+ 系統数の多いバス事業者などでバスの方向幕、ＨＰやバス停表示で主に系統番号で案内をしている場合には、route_short_nameに系統番号を設定します。
+ 例：学01、1-1
+ 現在（2021年6月）、6文字までという制限があります。記号・符号のみを記述し、路線名などは記載しないようにします。（←GTFSベストプラクティス）
#### route_long_name（経路名）【条件付き必須】
+ 路線名を設定します。系統番号がなく路線名で案内したい場合はroute_long_nameに路線名を設定します。
+ 例：西大寺線
+ コミュニティバスなどの名称を案内する必要があるときはそれも含めて記述します。
+ 例：ふれあいバス・赤ルート
+ route_short_nameとroute_long_nameはどちらか一つは必ず設定する必要がありますが、両方が設定されている場合、Google乗換案内ではroute_short_nameしか検索結果に表示されません。このため系統番号と路線名の両方を表示したい場合には、route_short_nameは空欄とし、route_long_nameに両方を設定します。
+ 例：東０１市民病院線
#### route_desc（経路情報）【任意】
+ ルートに関する情報を設定します。
+　例：学休日運休（calendar_dates.txtで記述できない場合）
+ 現時点では、route_descに記述した内容は、経路検索結果に必ずしも表示されるわけではありません。
+ **※CPに現状を確認する**
#### route_type（経路タイプ）【必須】
+ 交通機関の種類（路面電車、鉄道、バス、フェリーなど）をコードで設定します。バスは"3"です.
#### route_url（経路URL）【任意】
+ ルートに特化した情報を案内をするための特定のURLがある場合にそのURLを設定します。特にない場合は設定しません。
#### route_color（経路色）【任意】
+ HPで公開している路線図や時刻表で使用している路線の色を設定します。
+ Google乗換案内のGTFS品質審査では、route_colorを設定するよう指摘されることが多くあります。また、路線図等の色と一致していることが求められます。（←Google品質審査例）
#### route_text_color（経路文字色）【任意】
+ 路線をroute_colorで表示したとき、その上に路線名を記載するときの色を設定します。route_colorが設定されているときは、この項目も設定します。
+ route_colorが濃い色のときは薄い色（例えば白）、route_colorが薄い色のときは濃い色（例えば黒）を設定します。（←Google品質審査例）
+ （理由）：路線と路線名を重ねて表示したときに、色のコントラストがないと見にくい。


#### jp_parent_route_id（方面・路線ID）【任意】
+ ルートの設定には、路線名、運賃等が異なるものは別々のルートするなどの要件がありますので、これらの要件により分けざるをえなかったルートをまとめて取り扱う必要があるときに設定します。
+ 例えば、GTFSデータを用いてバス停掲示用の時刻表を作成する予定があり、方面や路線をまとめて１枠に収めたい場合などの使用できます。
+ 特に必要がない場合はこの項目は設定不要です。

---
## 便情報（trips.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#tripstxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F05_trips.txt.PNG)

### 便の単位について
+ 便は、通常の、１つの路線（ルート）の中で始発バス停から終点バス停までを走る１回の運行を単位とします。ダイヤ管理システムや時刻表で１つの便としているものをそのまま使用します。
+ JR山手線のように環状の路線を複数回回り続ける場合は、１周を１便とし、GTFSの「便結合」で連続する便を結合し、継続して乗車できることを表現します。（←GTFSベストプラクティス）

### 各項目の設定ガイド
#### route_id（経路ID）【必須】
+ 便が属するルートのroute_idを設定します。
#### service_id（運行日）【必須】
+ 便が運行する日を示すservice_idを設定します。詳細は、運行日の設定（calendar.txt、calendar_dates.txt）の項で説明します。
#### trip_id（便ID）【必須】
+ 便のIDを設定します。通し番号のような付け方でも構いませんが、GTFS作成ツール等では視認性を高めるため、route_id、系統番号、service_id、始発時刻、direction_id、便番号などを組み合わせて生成しています。
+ 例１：平日_05時35分_系統101
+ 例２：1全日_08時20分_系統111001
+ 例３：1+1+平土+1
#### trip_headsign（便行き先）【任意】
+ 便の行き先を設定しますが、バス車体での表示（方向幕など）、ＨＰ掲載の時刻表での表示、バス停での表示などに一致させることを推奨します。
##### 循環路線の場合の注意
+ 始発バス停に戻ってくる循環路線の場合、行き先＝始発バス停名 とならないようにし、途中の主なバス停名、団地名、施設名などに"方面"を付けることを推奨します。"方面"を付けるのはそこが終点でないことを示すためです。
+ さらに、trip_headsignに表示した地点を通過したあとはstop_times.txtのstop_headsignに最終の行先を設定します。（左例）
+ もしくは、すべてのバス停にstop_headsignを設定します。この場合、headsignはすべて上書きされますので、headsignは空欄で構いません。（右例）

+ ただし、バスの方向幕やＨＰ、バス停の表示が循環路線であることを示すものとなっている場合はその通りに記載します。
+ 例：柏市内循環
##### 途中で行き先表示が変わる場合（stop_headsignの設定）
+ 循環路線であってもなくても、途中で方向幕やバス停での行先の案内が変わるときは、stop_times.txtのstop_headsignで途中から行き先表示が変わることを示します。後述のstop_headsignの項を参照してください。
#### trip_short_name（便名称）【任意】
+ 便に固有の名称がある場合に設定します。路線の愛称（例："空港シャトル"、"市民病院連絡バス"）やバス車両の愛称（例："そよかぜ号"）などは設定できません。特に便に固有の名称がなければ設定しません。
#### direction_id（往復区分）【任意】
+ バスの上り・下り、行き・帰り、右回り・左回りなどを区別するために設定します。データ利便性の向上のため設定することを推奨します。
+ 0：復路　1：往路（←GTFS-JP仕様書）
+ （理由）時刻表の作成、バスデータの集計や分析などのGTFSデータ利用時には方向を区別する必要があることが多く、direction_idを設定しているとその区分を用意に把握できる。
+ 復路（帰り）を"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（描画ID）【任意】
+ shapes.txt（バスの走行するルートの座標データ）を作成している場合に設定します。shapes.txtがない場合は設定しません。詳細はshapes.txtの項をご覧ください。
#### wheelchair_accessible（車椅子利用区分）【任意】
+ 車いすの乗車可否を次のコードで設定します。
+ 0 または空欄：車いすの乗車可否情報なし
+ 1：少なくとも1台の車いすによる乗車可能
+ 2：車いすによる乗車不可
#### bikes_allowed（自転車持込区分）【任意】
+ 自転車の持ち込み可否について次のコードで設定します。
+ 0 または空欄：自転車持ち込み可否の情報なし
+ 1：少なくとも1台の自転車の持ち込み可能
+ 2：自転車の持ち込み不可
#### jp_trip_desc（便情報）【任意】
+ 運行日情報（calendar.txt、calendar_dates.txt）で表現できない運行日情報（"学休日運休"）や便に固有の情報（"ボンネットバスで運行"）などを設定できます。
+ ただし、現時点では経路検索結果などで表示されるとは限りません。
+ **※CPなどに要確認**
#### jp_trip_desc_symbol（便記号）【任意】
+ 時刻表作成時に便に補足情報をつける符号を設定できます。ただし、GTFSに凡例情報（符号が何を意味するかの説明）を記述することができないため、この項目だけでは、設定する意義はあまりありません。
#### jp_office_id（営業所ID）【任意】
+ 忘れ物や定期運賃の問合せなどのために、乗換案内結果にバスの営業所の連絡先を表示するために利用されます。詳細はjp_office.txtの項をご覧ください。
+ **※CPに実際に利用しているか、必要か要確認**
#### jp_pattern_id（停車パターンID）【任意】（GTFS-JP仕様書第３版で追加）
+ GTFSデータをバスロケや音声案内合成などで利用する場合などで、停車パターン（バス停の並び順）の情報が必要な場合に設定します。GTFSデータがこれらの用途に使用される場合に、バス事業者・市町村がバスロケや音声案内合成事業者などと協議して、どのように設定するかを決めてください。
+ または、バス事業者が社内管理用の系統コードを記載しておきたい場合には、ここに設定することができます。

---
## 営業所情報（office_jp.txt）【任意】
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F06_office_jp.txt.PNG)

### 概要
+ 忘れ物や定期運賃等の問合せ先となる営業所の情報を設定します。
+ コミュニティバスでfeed_infoの運行事業者（agency）を市町村とした場合、運行を委託しているバス・タクシー事業者等の連絡先をここに設定することができます。
### 各項目の設定ガイド
#### office_id（営業所ID）【必須】
+ 営業所のIDを設定します。
#### office_name（営業所名）【必須】
+ 営業所名を設定します。
#### office_url（営業所URL）【任意】
+ 営業所のHPのURLを設定します。営業所のHPがない場合は設定しません。
#### office_hpne（営業所電話番号）【任意】
+ 営業所の代表（問い合わせ用）電話番号を設定します。

---
## 停車パターン情報（pattern_jp.txt）
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F07_pattern_jp.txt.PNG)

### 概要
+ この項目はバスロケシステムなどの特定の利用者がGTFSデータを利用する際に必要となる項目ですので、どのように設定するかは利用者と協議の上決めてください。
+ また、系統の社内管理用コードを記載したいときは、そのコードを記載します。
+ 停車パターン情報を利用する予定がなければ、この項目は設定する必要はありません。
### 各項目の設定ガイド
#### jp_pattern_id（停車パターンID）【必須】
+ データ利用者と協議のうえ決めてください。もしくは、系統の社内管理用コードを記載します。
#### route_update_date（ダイヤ改正日）、origin_stop（起点）、via_stop（経過地）、destination_stop（終点）【いずれも任意】
+ GTFS-JPの初版ではバス事業の申請業務用に設定されていた項目ですが、jp_pattern_idの利用者が限定されるため、これらの項目の設定の必要性も含めてデータ利用者と協議して決めてください。
+ 系統の社内管理用コードを記載した場合は、その系統のダイヤ改正日、起点、経過地、終点を設定します。

---
## 通過時刻情報（stop_times.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#stop_timestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F08_stop_times.txt.PNG)
### 概要
+ この項目では、便、停留所（標柱）ごとに発着時刻を設定します。
### 各項目の設定ガイド
#### trip_id（便ID）【必須】
+ trips.txtで設定したtrip_idを設定します。
#### stop_id（標柱ID）【必須】
+ stops.txtで設定した標柱のstop_idを設定します。標柱ですので、親停留所（stops.txtでlocation_type=1としたもの）のstop_idは設定できません。
#### arrival_time（到着時刻）【必須】
+ その標柱への到着時刻を設定します。
+ HH:MM:SS形式とし、24時以降は24時、25時・・と表示します。
+ 例：09:20:00、23:55:00、24:10:00、25:20:00
+ 始発バス停では、空欄にせず出発時刻（departure_time）と同じ時刻を設定します。
+ 前後のバス停と同時刻になっても構いません。
+ （理由）GTFS-JP仕様書では、「同一trip_idにおいて同一時刻の設定不可」されているが、GTFS仕様書、ベストプラクティスにはそのような記載はなく、Google品質審査でも指摘されていない。
#### departure_time（出発時刻）【必須】
+ その標柱からの発車時刻を設定します。
+ HH:MM:SS形式とし、24時以降は24時、25時・・と表示します。
+ 例：09:20:00、23:55:00、24:10:00、25:20:00
+ 終点バス停では、空欄にせず到着時刻（arrival_time）と同じ時刻を設定します。
+ 前後のバス停と同時刻になっても構いません。
+ （理由）GTFS-JP仕様書では、「同一trip_idにおいて同一時刻の設定不可」されているが、GTFS仕様書、ベストプラクティスにはそのような記載はなく、Google品質審査でも指摘されていない。
#### stop_sequence（通過順位）【必須】
+ その便での当該標柱の通過順序を昇順で設定します。必ずしも連番である必要はありません。


#### stop_headsign（停留所行先）【任意】
+ 便の行き先はtrip_headsignで設定しますが、途中で行き先表示が変わる場合にはstop_headsignで設定します。
+ バスの方向幕やバス停の行き先表示に合わせます。
+ stop_headsignは次のバス停に引き継がれないので、次のバス停以降にもstop_headsignを設定する必要があります。


#### pickup_type（乗車区分）【任意】
+ 降車専用の標柱には"1"を設置します。通常の乗降両方できる標柱には"0"を設定します。
+ その他、交通機関に乗車予約の電話が必要な標柱には"2"を設定します。これにより、デマンド運行を表現できます。ただし、2021年11月現在、Googleでは全区間が予約必要の路線のデータを受付けていません。また、一部区間が予約必要の場合は、alertでの表示が必要とされています。（←Google品質審査例）
+ また、運転手への事前連絡が必要な場合は"3"を設定することになっていますが、バスの場合、具体的に該当するケースが明らかになっていません。

#### drop_off_type（降車区分）【任意】
+ 乗車専用の標柱には"1"を設置します。通常の乗降両方できる標柱には"0"を設定します。
+ その他、交通機関に降車予約の電話が必要な標柱には"2"を設定します。これにより、デマンド運行を表現できます。ただし、2021年11月現在、Googleでは全区間が予約必要の路線のデータを受付けていません。また、一部区間が予約必要の場合は、alertでの表示が必要とされています。（←Google品質審査例）
+ また、運転手への事前連絡が必要な場合は"3"を設定することになっていますが、バスの場合、具体的に該当するケースが明らかになっていません。

#### shape_dist_traveled（通算距離）【任意】
+ 起点からの距離を設定することとなっていますが（←GTFS-JP仕様書）、国内のGTFSデータではほとんど設定されておらず、特に設定する必要はありません。
+ （理由）GTFS-JP仕様書では、当初、この距離をバスの運賃計算に利用することが意図されていましたが、営業キロと実キロは必ずしも一致するものではないことから、使用されていません。
+ shapes_dist_traveledを設定すると、shapes.txtにおいてもshape_dist_traveledを設定する必要がありますが、国内のGTFSデータ作成ツールでこれに対応したものはないと思われます。
+ 本来は、バスの走行ルートを示すshapes.txt内の座標とバス停を結びつけるためのもので、同じバス停を複数回通る場合に、走行ルートのどの地点かを示すものです。

#### timepoint（発着時間精度）【任意】
+ 到着時刻、出発時刻が時刻表に基づく正確なものであるか、概算や補間により求めた時刻であるかの区分を示します。ただし、日本では使用しません。（←GTFS-JP仕様書）

---
## 運行区分情報（calendar.txt）【条件付必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#calendartxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F09_calendar.txt.PNG)

### 運行日設定の概要
+ 運行日の設定は、calendar.txtで曜日単位に運行する（しない）を設定した上で、祝日、お盆、年末年始などの曜日に係わらず運行する（しない）場合をcalendar_dates.txtで設定して上書きします。
+ ただし、お盆ダイヤ、年末年始ダイヤのように数日のみのダイヤの場合は、calendar.txtには設定せず、calendar_dates.txtに運行する年月日のみを設定することでも構いません。
### 各項目の設定ガイド
#### service_id（運行日ID）【必須】
+ 運行日を示すIDを設定します。
+ 例：平日、土、土休日、月水金、お盆、年末年始、秋祭り
+ GTFS-JP仕様書では、「標準の８区分のservice_idについてはcalendar_dates.txtでの祝日設定を行わなくても国内CPでは祝日を考慮した案内を実施」と記載してありますが、Google乗換案内をはじめ、国内CP以外の利用者も間違いなく利用できるようにcalendar_dates.txtで祝日設定してください。
#### monday、tuesday、wednesday、thursday、friday、saturday、sunday（各曜日の運行設定）【必須】
+ 各曜日について、運行する場合は"1"、運行しない場合は"0"を設定します。
#### 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）【条件付必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#calendar_datestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F10_calendar_dates.txt.PNG)
### 運行日情報設定上の注意
+ 祝日は毎年日付が変わりますので、間違えないように毎年データ更新を行ってください。お盆、年末年始の運行日の設定も忘れずにしてください。
+ 特に2021年はオリンピック開催のため祝日が変更されていますので注意してください。
+ 春分の日、秋分の日は天文暦により決まります。正式には前年２月に官報告示されますが、国立天文台のHPに将来の春分日、秋分日の予想が掲載されています。
+ [何年後かの春分の日・秋分の日はわかるの？](https://www.nao.ac.jp/faq/a0301.html)
### 各項目の設定ガイド
#### service_id（運行日ID）【必須】
+ 運行日を示すIDを設定します。calendar.txtに設定したものと同じです。
#### date（日付）【必須】
+ 運行日を設定する日付をYYYYMMDD形式で指定します。
+ 例：202107023（2021年7月23日）、20211231（2021年12月31日）
### calendar.txtとcalendar_dates.txtの組み合わせ例（特殊ケース）
+ 特殊なケースについて、calendar.txtとcalendar_dates.txtの設定方法を説明します。
#### 例１：お盆ダイヤ（2021年8月13日（金）～16日（月）に適用）
+ 例1-1 service_idの"平日"、"土休日"、"お盆"をcalendar.txtで定義し、"平日"、"土休日"についてcalendar_dates.txtでお盆期間の運行を除外する。
+ （注）このように設定をすると、すべての"平日"、"土休日"の便はお盆期間中は運行しないという意味にあるので、一部の路線はお盆特別ダイヤでなく通常の平日ダイヤ、土休日ダイヤで運行する場合でも、すべての路線にお盆ダイヤの便のデータを作成する必要があります。


+ 例1-2 service_idの"お盆"はcalendar.txtに定義せず、calendar_dates.txtでお盆期間の運行を設定する.
+ （注）この場合も例1-1の注記内容に留意してください。


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


---
## 運賃属性情報（fare_attributes.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#fare_attributestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F11_fare_attributes.txt.PNG)

### 運賃設定の概要
+ 運賃は、「金額、支払いタイミング（乗車時か降車時か）、乗継ぎの可否」が同じものを「運賃の単位」としてIDをつけて設定し、その「運賃の単位」がどの路線のどの区間（乗降標柱の組み合わせ）に適用されるのかを設定します。


### 各項目の設定ガイド
#### fare_id（運賃ID）【必須】
+ 「運賃の単位」のIDを設定します。
#### price（運賃）【必須】
+ 運賃の金額（円）を設定します。
#### currency_type（通貨）【必須】
+ 日本の場合は"JPY"を設定します。
#### payment_method（支払いタイミング）【必須】
+ 運賃の支払いタイミングを次のコードで設定します。
+ 0：乗車後（降車時）
+ 1：乗車前（乗車時）
#### transfers（乗換）【必須】
+ この運賃を支払ったときに、追加料金なしで乗換（乗継）乗車ができるかどうかを次のコードで設定します。
+ 0：乗換乗車はできない
+ 1：１度の乗換乗車ができる
+ 2：２度の乗換乗車ができる
+ ””（空白）：乗換回数に制限なし
#### agnecy_id（事業者ID）【条件付必須】
+ GTFSデータに複数の事業者（agency）があるとき、この運賃が適用される事業者のIDを設定します。
+ GTFSデータに複数のagencyがある場合は、この項目は必須です。（←GTFS仕様書）
#### transfer_duration（乗換有効期限）【任意】
+ 乗換え可能な場合に、乗換制限事案を秒で設定します。
+ 乗換え不可の場合は設定しません。

---
## 運賃定義情報（fare_rules.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#fare_rulestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F12_fare_rules.txt.PNG)
### 各項目の設定ガイド
#### fare_id（運賃ID）【必須】
+ fare_attributes.txtで設定した運賃IDを設定します。
#### route_id（経路ID）【任意】
+ ルートIDを設定します。
+ 任意項目となっていますが、全線が同一の均一運賃、同一のゾーン運賃の場合以外は必ず設定します。
+ 全線が同一の均一運賃または同一のゾーン運賃の場合は、route_idを設定する必要はありません。
+ （理由）ルートにより運賃が異なることがないため。
+ 路線により均一運賃が異なる場合は、route_idを設定します。

#### origin_id（乗車地ゾーン）、distination_id（降車地ゾーン）【任意】
+ 乗車地、降車地を示すIDを設定します。
+ 均一運賃の場合は設定不要です。

+ 運賃がゾーン制の場合はゾーンID（ゾーン番号）を設定します。


+ 均一運賃、ゾーン運賃以外の場合は、stop_idと同じにしておくとよいでしょう。
+ この場合、stops.txtのzone_idのフィールドにはstop_idと同じものを設定しておきます。


---
## 描画情報（shapes.txt）【任意】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#shapestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F13_shapes.txt.PNG)

### 概要
+ この項目は、バスが実際に走るルート（道路）を座標を列挙して表現するものです。
+ GTFSデータをバスロケで使用する場合、正確な路線図を作成したい場合、経路検索結果で正確なバスルートを表示したいなどの理由がある場合には、設定することを推奨します。
+ GTFSデータの整備をshapes.txtも含めて外注した場合、データ更新時にshapes.txtの更新が困難になる場合がありますので、更新体制について検討しておくことが必要です。
+ 例：下のマップの緑線のバスルートについて黒点の座標を列挙します。
### 各項目の設定ガイド
#### shape_id（描画ID）【必須】
+ 描画するバスルートを特定するIDです。
+ 上り、下りで全く同じ道路を通る場合でも、shape_idは別々に設定します。
+ （理由）バスの走る方向に座標の並び順を設定する必要がある。
+ 同じshape_idをtrip_idにも設定して、その便がこのルートを走ることを明示します。
#### shape_pt_lat（描画緯度）、shape_pt_lon（描画経度）【必須】
+ バスルートを折れ線で表現し、折れ線の曲がり角の座標を列挙します。
+ 緯度、経度は10進数の度単位で設定します。度分秒単位は不可です。また、緯度と経度を逆に設定しないように注意してください。
+ ○139.5（139.5度）　×1393000（139度30分00秒）
#### shape_pt_sequence（描画順序）【必須】
+ 点の順番を設定します。昇順であればよく、連続した値にする必要はありません。
#### shape_dist_traveled（描画距離）【不要】
+ ルートの起点からの距離を設定する項目ですが、特に設定する必要はありません。

---
## 運行間隔情報（frequencies.txt）【任意】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#frequenciestxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F14_frequencies.txt.PNG)

### 概要
+ この項目は定められた時刻表がなく、運行間隔だけが決まっている場合に設定しますが、それ以外の場合には設定は不要です。
### 各項目の設定ガイド
#### trip_id（便ID）【必須】
+ 便IDを設定します。
#### start_time（開始時刻）、end_time（終了時刻）【必須】
+ 定間隔運行の開始時刻、終了時刻を設定します。HH:MM:SS形式で設定します。
#### headway_secs（運行間隔）【必須】
+ 運行間隔を秒で設定します。
#### exact_times（案内精度）【任意】
+ 運行案内を行うときに、具体的な時刻を案内しない場合は"0"を、案内する場合は"1"を設定します。

---
## 乗換情報（transfers.txt）【任意】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#transferstxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F15_transfers.txt.PNG)

### 概要
+ 経路検索サービスでは標柱の緯度経度やサービス事業者が設定した乗換え駅・バス停などによりルートが表示されますが、明示的に乗換地点や乗換所要時間を指定したい場合に設定します。
+ Google乗換案内では乗換所要時間を4分として検索しますが、ここで４分未満の時間を設定しておけば、着発の時間差が４分未満であっても乗換可能となります。
### 各項目の設定ガイド
#### from_stop_id（乗換元標柱ID）【必須】
+ 乗換元の標柱のstop_idを設定します。
#### to_stop_id（乗換先標柱ID）【必須】
+ 乗換先の標柱のstop_idを設定します。
#### transfer_type（乗換タイプ）【必須】
+ 設定したい内容を次のコードで設定します。
+ 0：２つのルート間の推奨乗換地点を指定する。
+ 1：２つのルート間で便の待ち合わせが行われる乗換地点を指定する。出発便は前の便が到着して乗換に必要な時間を確保してから出発する。（←GTFS仕様書）
+ 2：乗換に必要な最低限の時間が必要な乗換地点を指定する。乗換に必要な最低限の時間はmin_transfer_timeで設定する。
+ 3：ルート間の乗換が不可能なことを指定する。
#### min_transfer_time（乗換時間）【任意】
+ transfer_typeが"2"の場合に、乗換に必要な時間を秒単位で設定する。


---
## 提供情報（feed_info.txt）
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#feed_infotxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F16_feed_info.txt.PNG)

### 概要
+ GTFSデータの提供者とデータの有効期限に関する情報を設定します。
+ データの有効期間は【任意】となっていますが、経路検索サービスでは重要な意味を持つため、必ず設定してください。
### 各項目の設定ガイド
#### feed_publisher_name（提供組織名）【必須】
+ ここではGTFSデータを公開している組織の情報を設定しています。
+ 通常は、ここにはバス事業者、市町村もしくはこれらからGTFSデータの作成・公開を委託されている会社等の名称を設定します。
+ GTFSデータがバス事業者、市町村が自らもしくはこれらからの委託により作成されたものでない場合には、データを作成・公開する者の名称を設定します。
#### feed_publisher_url（提供組織URL）【必須】
+ 上のfeed_publisherのURLを設定します。
#### feed_start_date（有効期間開始日）、feed_end_date（有効期間終了日）【任意】
+ データの有効期間をYYYYMMDDの形式で設定します。
　　+　例：20210723（2021年7月23日）、20211231（2021年12月31日）
+ 設定の詳細については、別稿（GTFSデータの作成期間と有効期間の設定方法ガイド）で説明します。
#### feed_version（提供データバージョン）【任意】
+ 提供しているデータのバージョンを設定します。
+ ダイヤの管理と合わせて、ダイヤのバージョンやダイヤ改正の日付等で設定することを推奨します。

---
## 翻訳情報（translations.txt）【必須】
[GTFS仕様書](https://developers.google.com/transit/gtfs/reference#translationstxt)
[GTFS-JP仕様書第３版](https://busdata.or.jp/files/F17_translations.txt.PNG)

### よみながと翻訳情報の概要
+ GTFSデータ内の漢字表記によみがなをつけます。また、日本語を英語その他の言語に変換するための情報を設定します。
+ バス停（標柱）名のよみがなは必ず設定します。（←GTFS-JP仕様書）
+ （理由）国内の経路検索サービス事業者においてよみがなが必要である。
+ **※よみがなが必要なのはバス停名だけかＣＰに要確認**
+ 翻訳対象となるのは、末尾に"name"、"desc"、"url"、"headsign"が付いているフィールドに設定されている日本語（漢字）です。
+ 次の２つの設定方法があります。混在していても構いません。
1. 翻訳対象語のテーブル名とフィールド名を指定し、その中のどの語を翻訳するのかをIDで指定する。（record_idを用いる方法）
1. 翻訳対象語のテーブル名とフィールド名を指定し、その中の翻訳対象語そのものを記述することにより指定する。（field_valueを用いる方法）


### 各項目の設定ガイド
#### table_name（テーブル名）【必須】
+ 翻訳する語を含むテーブル名を設定します。拡張子（".txt"）は付けません。
#### field_name（フィールド名）【必須】
+ 翻訳する語を含むフィールド名を設定します。
#### language（言語）【必須】
+ よみがなの場合はja-Hrktと設定します。外国語への翻訳の場合は翻訳先の言語を２文字のISO639-1コードで設定します。
+ 例：en（英語）、fr（フランス語）、ko（韓国語）、pt（ポルトガル語）、zh（中国語）
+ [ISO639-1コード](https://datahub.io/core/language-codes#resource-language-codes)
#### translation（翻訳先言語）【必須】
+ 翻訳先の語を設定します。
+ よみがなは、原則としてそのままの読みを設定します。
+ （例）：とうきょうえきじゅうばんのりば
+ 外国語データの作成については、日本バス協会「訪日外国人旅行者のバス利用を想定した多言語対応に関するガイドライン」を参考にしてください。
+ [訪日外国人旅行者のバス利用を想定した多言語対応に関するガイドライン](http://www.bus.or.jp/news/tagengo.pdf)
#### recode_id（レコードID）、record_sub_id（レコードサブID）【条件付必須】
+ 翻訳対象をIDで指定します。例えば、標柱名を翻訳するときはrecode_idに対象のstop_idを設定します。
+ ただし、stop_headsignを翻訳するときはrecord_idに対象のtrip_idを設定し、record_sub_idにstop_sequenceを設定します。record_sub_idを使うのは、stop_headsignの場合だけです。


### 同一漢字で読みが異なる場合の設定
+ 漢字が同じで読みが異なるバス停（標柱）がある場合には、record_idで設定します。