本日は, 月々 \1,050 のパケット代だけで自分の全行動を GPS 情報を元に記録出来ちゃうというおハナシ :-)

6 月から続けている圏央道開通に伴うプローブパーソン調査. 3 か月は長いなぁ... (しかも謝礼はたったの \15,000！) と思っていたのですが, もう 2 か月半経とうとしています. この圏央道開通地域を実際に日々使っている人に携帯電話を持たせて GPS ログを採ることによって交通行動の変化, 区間所要時間の変化を見るのが目的の調査, そもそもいくつかの疑問があります.

• 開通前後の状況変化を見るのに, 開通前は 22 日間, 開通後は 69 日間データを採りますが, 3 年間にわたってクルマ通勤している身からすると, 区間所要時間変化はシーズンごとの変動が大きいと感じています. 具体的には, 夏休み期間中 (7 月下旬～8 月のお盆の週 1 週間を除く 8 月一杯) は混んでいます. また, 全体的に, 冬のほうが空いています. よって, 調査期間のうち開通前の 6/4～6/22 は, 1 年のうちでは空いているほうに属します. 一方, 開通後の 7 月中旬以降は 1 年のうち一番混んでいる時期です. そうした季節変動要因は考慮されるのでしょうか?
  
• さらには, 圏央道開通地域における重要な交通状況の変化として,「ひよどり山有料道路」が 6/1 に無料開放されたことがあります. 圏央道開通より, この有料道路の無料化によって朝の通勤時の渋滞が減ったと実感しています. しかし, 無料開放されたからといってすぐにそれにみんなが気づき, 経路を変更するとは限りませんよね. 6/23 の圏央道開通によって交通状況に変化があったのか, ひよどり山有料道路無料開放によって変化したのか, きちんと分析可能なのでしょうか?
  
• 以前も書きましたが, 調査対象となるのは概ね 100m 以上の移動だそうですが, 自宅近辺の散歩やコンビニに行くといった行動がどう圏央道開通に関係するのか私には判りません... (苦笑)

さてそれらはともかく, 調査用の携帯電話で発生パケット数を見て不思議に感じたことがありました. 毎日の通勤時に絶えずパケットを発生させているはずなのに, 確認するとあまりパケットが発生していません. そこでこの調査用 BREW アプリが GPS で取得した緯度経度情報をサーバに送るのにどれくらいのパケットが発生するか, 検証してみることにしました :-)

まず, 緯度は北緯・南緯それぞれを 90 度で示されます. より細かい緯度は 1 度＝60 分, 1 分＝60 秒で示されます. 要するに, 北緯・南緯両方を表現しようとすると最大で 180°59′59″となるようです. ……と Wikipedia には書いてあるのですが, 実際には秒以下を ¹/₁₀₀ まで表すことがあるようで, 180°59′59.99″でしょうか. 単純に度・分・秒・1/100 秒をそれぞれ別のバイトで表すと, いずれも 1Byte で表わすことの出来る 0～255 の範囲に収まっているので, 4Bytes で緯度は表現出来ることになります.
一方, 経度は東経・西経それぞれを 180 度で示しますので度だけは 0～360 度となって 255 を超えますので 2Bytes 必要で, 5Bytes で経度は表現出来ます.
よって, 9Bytes あれば現在位置を正確に表現出来る訳です. が, これだと使わないビットが多くなってもったいないので, 1/100 秒で初めから表わすことを考えます. 緯度は 180×60×60×100 ですから 64,800,000 あればよいので, long int 型, つまり 4Bytes で表わすことが出来ます. 同様に経度は 360×60×60×100 で 129,600,000 なのでこれも long int 型に収まります. すなわち, 先ほどより 1Byte 削減出来て, 8Bytes あれば現在位置を正確に表現出来ることが判りました.

次に, データの送信回数を求めます. 今回の調査では, 配付された資料 (PDF) によると, 携帯電話を操作して移動中にしている間は 10 秒間に 1 回データを送信します. 私の場合, 平均して月に 20～25 日, 1.5 時間くらいかけて会社と往復しています. 遠出をするとき以外は週末のプライベートでの移動のほうが移動時間が短いので, ここでは 1 か月あたりの移動時間を仮に 25 日×1.5 時間として, 37.5 時間移動すると仮定します. 移動時間中は 10 秒間に 1 回ずつデータ送信されるのですから, 37.5 時間×60 分×60 秒÷10 となって, 1 か月あたり 13,500 回程度データ送信される計算となります.

このふたつのデータから, 13,500 回×8Bytes を計算すると 1 か月の概算データ送信量は 108,000Bytes となりました. 1 パケットは 128Bytes なので, わずか 843.75 パケットあれば私の場合, 10 秒間に 1 回の測位・データ送信であれば 1 か月間の自動車での移動をすべて記録出来てしまうんだなぁ... もっと多くのバイト (パケット) 数が必要だとばかり思っていたので, 非常に意外でした.
予想だと, 出発地点でだけフルにデータを送っておき, 後は差分データだけ送信することによってデータ量を圧縮するとか, 調査範囲が非常に限られているので (少なくとも北緯・東経の範囲内だけでよい), 緯度経度を表わす範囲を制限して 8Bytes からより少ないバイト数にするなどの方法を採っているに違いないと思っていたのですが, そんなことは必要ないようです.
ちなみに, 緯度経度の位置情報だけでなく, 時刻だとか, モニター ID とか携帯電話番号等, どのモニターのデータかを特定するデータも送信しているとは思いますし, そもそも送り先のホストデータ (IP アドレス) なんかも送受信パケット数には含まれます. けれど, モニター ID であれば 1Byte あれば十分ですし, ここまでの計算からそれらを含んでもデータ量はいくらも増えないことは予想出来ますね. ちなみに, 緯度経度情報だけだと上記の仮説だと 900 パケット弱でしたが, 7 月 1 か月間に実際に発生したパケット数は冒頭の画像にあるように 11,333 パケットでした.


今まで, 通勤の状況はビデオカメラを車載して記録することをして来ましたが, この程度のパケット数で済むのなら, えーっと... 24 時間×60 分×60 秒÷10×30 日×8 Bytes÷128 Bytes ですから... 1 か月あたり 16,200 パケットで自分の全行動を記録出来ちゃいますね (笑). これなら, au のダブル定額ライトを使えば月額 \1,280 くらいしかかかりません (いやいや, 自宅や仕事中はデータ更新の必要はあまりありませんので, \1,050 の定額料だけで収まりそうです). そのお値段出せば自分がいつどこにいたか (そこまで判れば何をしていたかの記憶を呼び起こすことも容易?) 判る記録が手に入る... うっとりして来ます (爆).