1 日何をしたか, しなかったかがお上 (？) にばればれな生活を続けてはや 4 か月近く. 行動を監視された生活もあと 1 週間で終わりです...

思えばあっという間ですな. モニター活動終了とともに今までのログが見られるサイトにアクセス出来なくなりそうなので, 暇を見つけては過去の行動ログを copy & paste して保存しています.
GPS ログはハードコピーを取る以外に保存の方法がないのでパスして, とりあえずいつ・どこから・どこへ・何で・何をしに行ったか, のログだけ保存中...

1 か月分として単純に \5,000 (相当) 増額ですか... 別に金に困ってる訳じゃないし (笑), 迷いますな.

本日は, 月々 \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 の定額料だけで収まりそうです). そのお値段出せば自分がいつどこにいたか (そこまで判れば何をしていたかの記憶を呼び起こすことも容易?) 判る記録が手に入る... うっとりして来ます (爆).

モニターとして参加している圏央道プローブパーソン調査で渡されているのは au の W43H という携帯電話.
GPS を使って, 移動中の現在位置を 10 秒ごとに取得し, そのデータをサーバに送るため, この携帯電話にプローブパーソン調査用の BREW アプリ (EZ アプリ) が入れられています. つまるところ, GPS ログが取れてサーバに送れれば携帯電話である必要はないはずですが, 今あるインフラで (モニターにとっても) 簡単にそうしたシステムを実現しようとすると携帯電話が一番適切だったという訳でしょう.
という訳でこの携帯電話, 電話としてのあらゆる機能が殺されています. ダイヤル発信制限はもとより, アドレス帳, スケジュール帳等は暗証番号を入れないと起動出来ない「アクセス制限」がかかっており, ワンセグアプリに至ってはご丁寧に削除されています.
けれど謎なのが, PC サイトビューアは制限されているのに, EZWeb 制限が解除されていること. BREW アプリが通信するのに必要なためなんだと思いますが, この制限がないために, やろうと思えば携帯電話からの Web アクセスを人のオカネでやり放題です :-)
が, au の公式サイトから使用パケット数を見てみるとあまりパケットが発生していません. 10 秒に 1 回の移動経度情報をデータ送信していればかなりの分量になると思うのですが (緯度経度って何 bit で表せるのだろう?), 何か別の方法を使っているのでしょうか? au サイトから確認出来ない料金区分が法人契約にはあるのかも知れませんが, それであれば少しだけパケットが発生しているのもおかしいです. 6 月のパケット数を控えておくのを忘れてしまったので, 7 月末には忘れずに控えておこうと思っています...

という訳でこの携帯電話, もともと「調査以外の目的では決して使わない. 調査以外に使って損害を発生させた場合は補償する」てな約束で渡されているとはいえ, 携帯電話としてはまったく役立たない状況が続いています... (~_~;
自分のもの, 会社のものに加えて 3 台の携帯電話を持ち運ぶ生活にだいぶ疲れて来ました... (苦笑)

以前は割引制度など皆無といってよかった高速道路. ETC 導入と民営化に前後して色々と割引が導入されているのはよいことですが, 説明が判りづらいことこの上なし.

ということで, 圏央道関係の割引制度をまとめてみました. いずれも, ETC 装着車両のみが対象です.

早朝夜間割引 (圏央道は一般有料道路だが特例として適用)
5 割引	22:00～06:00 に入口か出口を通過したとき (100km 以内)	2007.06.23～
社会実験	休日渋滞ポイントにおける時間帯料金割引
5 割引	日曜日・祝日に, 関越道・上信越道等の特定 IC で入り, 圏央道で出た場合で, 入口か出口を 20:00～22:00 に通過したとき	2007.06.24～
深夜割引 (圏央道は一般有料道路だが特例として適用)
3 割引	0:00～04:00 に利用したとき	2007.06.23～
社会実験	圏央道全線利用割引
3 割引 (\500)	圏央道を全線利用したとき	2007.08～
社会実験	中央道（高井戸方面）圏央道連続利用割引
\300 引	圏央道各 IC と中央道八王子本線料金所との両方を利用し, 中央道均一区間 (八王子～高井戸) を走行したとき (八王子 IC～圏央道間では適用されない模様)	2007.08～
通勤割引
\200 引 (*)	6:00～9:00, 17:00～20:00 に入口か出口を通過したとき (100km 以内)。(*) 圏央道関係は八王子 JCT～八王子 IC 間分のみ	2007.06.23～
キャンペーン	ETC マイレージポイントプレゼント (キャンペーン期間終了)
160points (*)	関越道練馬～花園間・圏央道内と中央道高井戸～甲府昭和・河口湖間とを通行したとき。各種割引と重複適用可。 (*) 160points は 最大で \160 に相当	2007.06.23～07.22

冒頭の図はこれらをタイムテーブルで表したもの. 適用される割引条件が重複したときは, 割引率が高いものが適用されることになっています. 利用区間によっても違って来ると思いますが, 上に行けば行くほど優先して適用される割引率が高いものです.


【訂正 2007.08.17】
中央道（高井戸方面）圏央道連続利用割引について, 八王子 IC～圏央道間では適用されない模様と書きましたが, この区間の利用であっても割引は適用されます.