GTFSベースとする場合の項目について #9
Description
現時点で考えられる論点を列挙します。
(1) GTFSとGTFS-JPの違いでもあるが、routeが系統主義をとるか
運賃等の面からも、routeはできるだけ細分化した上で、parent_routeを充実させるのはどうか。
GTFS-JPではjp_parent_route_idが有効に機能していない。各parent_routeに対してroute_color、route_text_color等を設定できないこと、1つのrouteに1つのparent_routeしか設定できないこと、parent_routeのparent_routeが設定できないこと、等の問題がある。
以下、GTFS-JPのroute（できるだけ細分化されたroute）を仮にjp_routeと書く。
(2) 各routeが通るstop_idとstop_sequenceの情報が無いこと
GTFSでは、各routeが通るstop_idとstop_sequenceの情報が無く、stop_times.txtに各tripが通るstop_idとstop_sequenceが含まれている。
特にGTFS-JPでは、stop_times.txtのうち、trip_id、arrival_time、departure_time以外は、同jp_routeの各tripで共通（冗長）と考えられるため、stop_sequence、stop_headsign、pickup_type、drop_off_type、shape_dist_traveled、timepointは各jp_routeでまとめられるのではないか。
その場合、stop_times.txtはtrip_id、arrival_time、departure_time、stop_sequenceとなるが、arrival_timeとdeparture_timeは縦に交互に並べれば、横にtripを並べて時刻表状にできる。
また、複数jp_routeをまとめた時刻表を作る場合、(1)で述べたparent_routeに対してもstop_idとstop_sequenceがほしい。そうでないと、各jp_routeのstop_sequenceを予め調整しておく（柔軟性が無い）か、各jp_routeのstopを適当に寄せ集めるしかない。
なお、GTFS to HTMLでは、timetables.txtのtimetable_idで時刻表に表示する系統群をまとめ、各時刻表に対してtimetable_stop_order.txtで停車地の順序を定めているようである。
また、各jp_routeのstop_idとstop_sequenceがあれば、時刻表が無いデータを作成することができる。これは時刻表無しでバスマップを作成する場合の手間の軽減や、過去の時刻表が入手できない場合にも使える。（余談、便時刻表は公開したくないが、役に立たない停留所時刻表はオープンにしてもいいという弱い標準化の問題はどうするか。）
(3) shapes.txtの問題（重複部分の冗長性）
GTFSのshapes.txtは同じ道路を通る異なるshapeのshape_pointを別々に設定しているため、冗長である上にGPSやその筋屋マップのように各shapeのshape_pointが一致しない可能性がある。
例えば、国土地理院ベクトルタイル道路中心線からshapeを作る事に決めておけば、shapeの一部をなす各折れ線に対して、ベクトルタイルのidをつけることができる事等が考えられる。
情報構造については、アーク・ノード・ポリライン構造や、国土数値情報バスルートのようなやり方等も考えられる。