Palo Alto Run ClubSaturday Morning Runに久々に参加。この日はかなり調子がよく、過去数回の中でも最速に近いペースながらかなり余裕を持って走れた。先週のChristmas Relayで速い動きをしたので体が多少速いペースでも余裕を感じられるようになってるのかも。
この日も当然Forerunner 305持参。ということでgoogle mapsのデータもGPSの記録をもとにupdateした。
さて、いままで、Forerunnerのデータはgpsbabelを使ってKMLに変換していたのだが、細かいところでいろいろ不満な点が出てきて、結局自前で変換スクリプトを書いてしまった。
まず、gpsbabelはGarmin Training Center(GTC)の専用フォーマットである.tcxをサポートしていないため、GPX形式でexportしたものをベースにする必要がある。したがって、心拍数データなどのGTC固有の情報が落ちてしまったりとか、区間距離や速度が知りたくても緯度と経度から計算しないといけない(一方.tcxには累積距離を示す要素がある)ので面倒だったりとかの不都合がある。
また、GTCからのexportは全データ一括でしかできない模様(これはこれでGTCがイケてないと思うのだが)で、そのデータの一部だけを変換することがgpsbabelではできなさそう。なので、結局.gpxを一度自前で変換する必要がある。
最初は手で.gpxをいじってからgpsbabelにかけていたのだが、1, 2回すると当然のように面倒になり、自動化ついでに最終出力まで自力でやった方がいろいろ融通がきいてよさそう、ということで週末を利用して作業した。.tcxはかなり構造のシンプルなXMLファイルなので、自前で変換、といっても大した手間ではない。
ということで、自前のツールが吐いたデータをもとに標高とペースの関係をグラフにしたものが次の図。
往復コースなので標高のグラフはほぼ左右対称になる。前半は4分/kmをちょっと超えるくらいのペースで、折り返し地点前の登り坂(1 mileほどの間に100mくらい登る)で少し減速し、下りに入ってまたぐっと上がって後半は大体4分/km前後、という傾向がよくわかる。こういうデータはやはりおもしろい。
なお、ペースの計算にはちょっと工夫が必要。これはtcx fileの各track point(GPSデータの計測地点)における累積距離と時刻をもとに計算しているが、時刻は秒単位の精度しかなく、一方track point間の距離は20-30m程度と比較的短いため、単純に隣接point間の平均速度を計算してプロットすると、以下の図のようにかなりばらつき(しかも不自然な)が生じてしまう。
そこで、自前変換ツールでは、各track pointを中心に前後(約)250mの区間を対象とした移動平均をそのpointにおける速度としてプロットしている。これによって、最初の図のように、比較的「それっぽい」グラフが得られる。(これを「それっぽく」するまでの試行錯誤でかなり時間を費やしてしまった…)
ちなみに、GTC自身にもいろんなグラフを表示させられるが、これも速度の計算にはかなり誤差があるようで、たとえば同じデータに対しては以下のようなグラフになる(クリックすると拡大される)。ところどころ異常なスパイクがあるのがわかる。GTCの中で速度をどうやって計算しているのかわからないので誤差の原因は不明だが、おそらく上記のような事情なのではないかと思われる。
以下のグラフは、別な日に心拍数(HeartRate)モニタを付けて走ってみたときの記録から作ったもの。このモニタのセンサがどの程度正確なのかはわからないが、実際にこの通りの値だとすると、ペースはほぼ一定(最後の方は少し上がっている)のに心拍数は徐々に落ちてきていることになり、興味深い。普段一人で走るときは比較的ゆっくり目のスピードなので、前半がwarming upのような感じで後半の方が楽に運動できているということか?
と、わずか$180弱でこれだけ遊べるForerunner、やはりお買得です!
2009年February10日 5:25 PM
[…] は手を着けているアレですが、内部実装は超ヘボイが多少まともなサマリが取れるようになってきた。世の中には似たようなことを考えている方もおられるのでもっと頑張らねばならん。 […]
2009年April4日 7:38 PM
[…] るせいで、ペース表示にするとnoisyなスパイクが発生してしまうので。自作のForerunnerのデータ解析(変換ツール)ではある程度の異常値があっても平滑化できるようにはしているのだが、trai […]