Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Protocol Buffers入門から各地のGTFS Realtimeを覗いてみよう

681 views

Published on

2019年4月20日開催「標準的なバス情報フォーマット/GTFS勉強会 #1」での発表資料です。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Protocol Buffers入門から各地のGTFS Realtimeを覗いてみよう

  1. 1. Protocol Buffers入門から 各地のGTFS Realtimeを覗いてみよう 東京大学 生産技術研究所 標準的なバス情報フォーマット広め隊 伊藤昌毅 標準的なバス情報フォーマット/GTFS勉強会 第2部 コースC. GTFSプログラミング 2019年4月20日 東京大学 生産技術研究所
  2. 2. GTFSリアルタイム基礎 • アプリ開発者が交通事業 者のサーバ(バスロケ) に問い合わせる際のプロ トコル • アプリとサーバの通信は アプリ開発者の役割 – アプリから直接接続しない • GTFSの存在が前提
  3. 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. 4. • GTFSリアルタイムのデータを格 納する方式 • 構造のあるデータをシリアライ ズする形式 – プログラミング言語非依存 – 動作環境(プラットフォーム)非依存 – 拡張可能な仕組み • XMLより小容量で高速 Protocol Buffersとは? https://developers.google.com/protocol-buffers/
  5. 5. • 何らかの関係性を表現した、コンピュータのメモリ上の複雑な 情報の構造をゼロイチのデータ列に直すこと – メモリにデータが置かれる形はプログラミング言語やコンピュータの種類などに よって異なるため、交換する際にはコンピュータに依存しない形で表現し直す必 要がある シリアライズ? シリアライズ デシリアライズ 01101100010101101010010101110101101111
  6. 6. • データ構造を定義する表現 – 例:polyline.proto • 表現されること – データの型 – データの必要性 • required, optional, repeated(配列) • プログラミング言語毎のprotocでコンパ イルすることで、言語毎にシリアライズ、 デシリアライズするためのプログラムが 得られる プロトコル定義ファイル (Proto Definition file (.proto) polyline.proto
  7. 7. • GTFSリアルタイム仕様書をプロ グラム向けに具現化したもの • GoogleのWebページからダウン ロード可能 GTFSリアルタイムの protoファイル https://developers.google.com/transit/gtfs-realtime/gtfs-realtime-proto
  8. 8. • gtfs-realtime-bindings – .NET、Go、Java、node.js(JavaScript)、 php、Python、Ruby • 開発者の手間を省くために提供 各言語向けのコンパイル済み ファイルが用意されている https://github.com/MobilityData/gtfs-realtime-bindings
  9. 9. • 国交省資料でも紹介 • ダウンロードして解凍、インス トーラを実行 • Windows/Macで動作確認済み • Macの場合は以下に起動スクリプ トがインストールされる – /Applications/RecordEdit/ProtoBuf/bi n/runEditor.sh ProtoBufEditor: Protocol Buffersをとりあえず眺めるツール https://sourceforge.net/projects/protobufeditor/
  10. 10. 起動画面と必要な設定→ブラウズ開始 1. protoファイルを設定 2. 読み込むファイルを設定 3. ブラウズ開始
  11. 11. データを眺めて みよう
  12. 12. • 今回はJavaScript(node.js)を利用 • gtfs-realtime-bindings はnpm で取得可能 プログラムからGTFSリアルタイムにアクセス $ npm init $ npm install --save gtfs-realtime-bindings $ npm install --save request
  13. 13. データを取得、JSONで表示する最小のコード
  14. 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. 15. 実行結果
  16. 16. • Webにいくつかサービスがあります JSONの整形 https://lab.syncer.jp/Tool/JSON-Viewer/
  17. 17. • 1つのヘッダ • 複数のFeedEntity – ひとつが1台の車両に対応 全体の構造
  18. 18. • TripUpdate、VehiclePosition、Alertが格納出来る • 実際はどれかひとつを入れる場合が多い – この例ではVehiclePositionのみ FeedEntityの構造
  19. 19. • TripDescriptor – 便を指定している。trip_id があればよい。無い場合には、 trip_id が一意に定まる情報を格納する • VehicleDescriptor – 車両を特定する情報。ナンバー番号も入る • Position – 位置情報など、GPSから得られる情報 • current_stop_sequene – 同じバス停を複数回停まる便もあるので、何番目のバス停かの 情報が大事 • current_status • Timestamp – 全体のタイムスタンプと異なっていい VehiclePositionの構造(宇野バス)
  20. 20. • 項目が入力されているか否か – trip_id があれば他は不要ではある • VehicleDescriptorのラベル – Webアプリで車両を指定するIDと同 一か? – 「サンタバスナビ」作れるよね • stop_id – 不要だが、SQL叩いてさがすのが面 倒なのでうれしいかも 岡電と宇野バスの比較
  21. 21. • TripDescriptorは同一 • VehicleDescriptorは何故か含まれず • StopTimeUpdate – 直前の実績値のみを格納 • それ以上の過去や未来予測は含まず • StopTimeEvent – arrivalはなし。departureのみ • departureのStopTimeEvent – 300秒の遅れ。秒単位だが、60秒単位に丸めている可能性あり • delay – trip 単位でのdelayは設定していない TripUpdate(宇野バス)
  22. 22. • TripDescriptor、VehicleDescriptorは VehiclePositionと同一 • stop_time_update を複数持っている TripUpdate(岡電)
  23. 23. • 全ての停車バス停ごとに遅れ時間を提供 – 秒単位の情報提供 • 通過済みの場合 – 実績値を提供 – uncertainty=0 • 未通過の場合 – uncertainty=300 StopTimeUpdate の詳細
  24. 24. 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
  25. 25. • aa aa

×