京都バスではGTFS-JPに加えてGTFS-RTが公開されています。
定期便では、以下のようにレスポンスされます。
GTFS-JPで便情報が定義されている定期便のリアルタイム情報は、trip_idを用いてGTFS-JPのtrips.txtを参照しjp_pattern_idを取ることで正確に系統を判別することができます。
京都バスにおいてjp_pattern_idは、既存の音声合成システムの音声合成番号４桁にアンダーバーを挟み、往路復路のどちらかを示す1または2を付け加えた文字列となっています。
このtrip_idの場合は、jp_pattern_idが3320_2です。
つまり、音声合成番号で言うところの3320という系統であると考えることができます。
一方、臨時便のGTFS-RTは以下のようになります。
（当たり前ですが）GTFS-JPのtrip_idに紐づかない臨時便では、trip_idからjp_pattern_idを辿ることができず、GTFS-JPデータを使った系統の識別ができません。
GTFSのリファレンス的に正攻法で系統を判別するroute_idは配信されてはいますが、こちらも系統名を調べるために使うには当てになりません。
先にこの便の系統の正体を言ってしまえば「特急系統・国際会館駅発・大原行き・停車は途中の八瀬駅前のみ」です。この場合のroute_id “10015”を実際にroutes.txtで見てみると、
そもそも”10015″なるroute_idは存在しないものであることが分かります。
（おそらく、GTFSの推奨事項として各種IDを定義するのは実際にデータ内で使われる場合のみ、という制約を守って一般に公開するGTFSには”10015″が含まれていないのだと考えています。）
しかも、京都バスのGTFS-JPにおけるroute_idは、10000番台もしくは20000番台で小さい方から順にランダムに割り振られており、更新毎に路線ごとのroute_idが変動するという不安定さ付きです。
では、どうやって正確な系統を調べればよいのでしょうか？
先ほどの臨時便のTripUpdateフィードのうち、entity内のid: フィールドを見ると、RE_1903_2_116となっています。（京都バスオタクなら見覚えのある数列のはずです）
結論から言うと、京都バスの臨時便のentity idは、「RE_[音声合成番号4桁]_[往復どちらかで1or2]_[vehicle_id]」となっていて、idフィールドに含まれる音声合成番号の文字列から正確な系統を推測できます。
この例では、GTFS-JPデータのpattern_jp.txtに1903_2は現バージョンも過去バージョンにも一度も含まれていないので、自力で何処かしらから系統情報を知る必要があります。
（知る方法の詳細は省きます）
私の kyotobus.turutaru.com/kyotobus では、一度も公式のpattern_jp.txtに含まれていないjp_pattern_idに関連する情報を独自に調査し、公式のデータと混ざらないよう非公式であることを判別できるフラグを付けてデータベースに登録しています。一部のバスに「【系統情報に注意】」というテキストが表示されるのは、このフラグの有無というわけです。
ちなみに、jp_pattern_idで紐付けられるのは始発バス停(origin_stop)、経由地(via_stop)、行き先(destination_stop)だけです。「17」「臨東山」みたいな系統名(route_short_name)はroutes.txtでroute_idと一緒に登録されていますので、系統名や系統色(route_color)も独自に設定します。
あくまで独自に調べた非公式データであるため、ユーザーに注意を促す必要があります。
将来的には独自調査データオンオフボタンで表示を切り替えられるようにしたいですね。
コメント