Protocol Buffers入門から各地のGTFS Realtimeを覗いてみよう
•
1 j'aime•3,377 vues
2019年4月20日開催「標準的なバス情報フォーマット/GTFS勉強会 #1」での発表資料です。
Recommandé
Contenu connexe
Plus de Masaki Ito
Plus de Masaki Ito (20)
Dernier
Dernier (12)
Protocol Buffers入門から各地のGTFS Realtimeを覗いてみよう
- 1. Protocol Buffers入門から 各地のGTFS Realtimeを覗いてみよう 東京大学 生産技術研究所 標準的なバス情報フォーマット広め隊 伊藤昌毅 標準的なバス情報フォーマット/GTFS勉強会 第2部 コースC. GTFSプログラミング 2019年4月20日 東京大学 生産技術研究所
- 2. GTFSリアルタイム基礎 • アプリ開発者が交通事業 者のサーバ（バスロケ） に問い合わせる際のプロ トコル • アプリとサーバの通信は アプリ開発者の役割 – アプリから直接接続しない • GTFSの存在が前提
- 3. 事業者 配信元 ベンダー Vehicle Position Trip Update Alert ライセンス 宇野バス 配信元 その筋屋 ○ ○ ○ CC BY 4.0 両備バス・ 岡電バス 配信元 Bus-Vison（リオス） ○ ○ CC BY 4.0 和歌山バス 配信元 Bus-Vison（リオス） ○ ○ CC BY 4.0 佐賀市交通局 配信元 ○ ○ ○ CC BY 4.0 中津川市コミュ ニティバス 配信元 SkyBrain（ヴァル研究所） ○ ○ CC BY 4.0 オープンデータとして提供されている GTFSリアルタイムデータ
- 4. • GTFSリアルタイムのデータを格 納する方式 • 構造のあるデータをシリアライ ズする形式 – プログラミング言語非依存 – 動作環境（プラットフォーム）非依存 – 拡張可能な仕組み • XMLより小容量で高速 Protocol Buffersとは？ https://developers.google.com/protocol-buffers/
- 6. • データ構造を定義する表現 – 例：polyline.proto • 表現されること – データの型 – データの必要性 • required, optional, repeated（配列） • プログラミング言語毎のprotocでコンパ イルすることで、言語毎にシリアライズ、 デシリアライズするためのプログラムが 得られる プロトコル定義ファイル (Proto Definition file (.proto) polyline.proto
- 8. • gtfs-realtime-bindings – .NET、Go、Java、node.js（JavaScript）、 php、Python、Ruby • 開発者の手間を省くために提供 各言語向けのコンパイル済み ファイルが用意されている https://github.com/MobilityData/gtfs-realtime-bindings
- 9. • 国交省資料でも紹介 • ダウンロードして解凍、インス トーラを実行 • Windows/Macで動作確認済み • Macの場合は以下に起動スクリプ トがインストールされる – /Applications/RecordEdit/ProtoBuf/bi n/runEditor.sh ProtoBufEditor: Protocol Buffersをとりあえず眺めるツール https://sourceforge.net/projects/protobufeditor/
- 11. データを眺めて みよう
- 12. • 今回はJavaScript（node.js）を利用 • gtfs-realtime-bindings はnpm で取得可能 プログラムからGTFSリアルタイムにアクセス $ npm init $ npm install --save gtfs-realtime-bindings $ npm install --save request
- 14. var GtfsRealtimeBindings = require('gtfs-realtime-bindings'); var request = require('request'); var requestSettings = { method: 'GET’, url: 'http://www3.unobus.co.jp/GTFS/GTFS_RT-VP.bin’, encoding: null }; request(requestSettings, function (error, response, body) { if (!error && response.statusCode == 200) { var feed = GtfsRealtimeBindings.FeedMessage.decode(body); console.log(JSON.stringify(feed)); } }); コピペ用テキスト
- 15. 実行結果
- 18. • 1つのヘッダ • 複数のFeedEntity – ひとつが1台の車両に対応 全体の構造
- 19. • TripUpdate、VehiclePosition、Alertが格納出来る • 実際はどれかひとつを入れる場合が多い – この例ではVehiclePositionのみ FeedEntityの構造
- 20. • TripDescriptor – 便を指定している。trip_id があればよい。無い場合には、 trip_id が一意に定まる情報を格納する • VehicleDescriptor – 車両を特定する情報。ナンバー番号も入る • Position – 位置情報など、GPSから得られる情報 • current_stop_sequene – 同じバス停を複数回停まる便もあるので、何番目のバス停かの 情報が大事 • current_status • Timestamp – 全体のタイムスタンプと異なっていい VehiclePositionの構造（宇野バス）
- 21. • 項目が入力されているか否か – trip_id があれば他は不要ではある • VehicleDescriptorのラベル – Webアプリで車両を指定するIDと同 一か？ – 「サンタバスナビ」作れるよね • stop_id – 不要だが、SQL叩いてさがすのが面 倒なのでうれしいかも 岡電と宇野バスの比較
- 22. • TripDescriptorは同一 • VehicleDescriptorは何故か含まれず • StopTimeUpdate – 直前の実績値のみを格納 • それ以上の過去や未来予測は含まず • StopTimeEvent – arrivalはなし。departureのみ • departureのStopTimeEvent – 300秒の遅れ。秒単位だが、60秒単位に丸めている可能性あり • delay – trip 単位でのdelayは設定していない TripUpdate（宇野バス）
- 23. • TripDescriptor、VehicleDescriptorは VehiclePositionと同一 • stop_time_update を複数持っている TripUpdate（岡電）
- 24. • 全ての停車バス停ごとに遅れ時間を提供 – 秒単位の情報提供 • 通過済みの場合 – 実績値を提供 – uncertainty=0 • 未通過の場合 – uncertainty=300 StopTimeUpdate の詳細
- 25. select tr.trip_id, ro.route_short_name, ro.route_long_name, st.stop_sequence, stops.stop_id, stops.stop_name, st.arrival_time, st.departure_time, case when stop_headsign is not null then stop_headsign else trip_headsign end as headsign, pt.geom from stop_times as st inner join stops as stops on st.stop_id = stops.stop_id inner join trips as tr on st.trip_id = tr.trip_id inner join routes as ro on tr.route_id = ro.route_id inner join patterns as pt on tr.shape_id =pt.shape_id where tr.trip_id = '221_2104216_20190401' order by stop_sequence
- 27. • aa aa