1年ちょいログの閲覧と管理にAscentを使ってるけど、saveするたびに全entryをディスクに書き出すダメ実装ゆえに遅くてたまらんのです。ストレージはTokyo Cabinetが間違いなくお勧めなんだけどLGPLなので、public domainなSQLiteでマジお願いします。Golden Cheetahを試そうとおもた。試しにGarmin Edge 705のFW2.60あたりのろぐをぶちこんだらたいへんなことになってた。
2009年7月のMt.鳥海バイシクルクラシックの第1ステージTTのログなんだけど、速度が20,000km/hとかになってたり、心拍と標高以外の値がしばらく0に落ちてる区間があったりたいへんなかんじ。
TcxParser.cppを眺めてみても別に変な事はしてないまっとうな作りだけど、Garmin Edge 705のバグ？対策で変位が0以下の時にpower & cadenceを0にしてる部分がちょっと気になる。
GarminのTCXファイルをPowerTapとかのCSVファイルに変換する自家製のtcx2csvコマンドでダンプしてみたら
Minutes, Torq (N-m),km/h,Watts,Km,Cadence,Hrate,ID
...
13.017,,708.469,193,23.826,105,197,0
13.033,,-58720.669,178,7.515,105,197,0
13.050,,50.281,194,7.529,103,197,0
おいこら。-58,720km/hとかになってるエントリが。なんぞこれ.... distanceも増えたり減ったり、変わってない区間があったりとひどいことに。このデータのせいでGolden CheetahのTcxParser.cppが残念な動きをしたかんじ。
じっさいTCXがどんなことになってるかxmllintで整形して眺めてたら、tcx2csvでダンプしたとおり
//TrainingCenterDatabase/Activities/Activity/Lap/Track/Trackpoint/DistanceMeters/text()
が増えたり減ったり飛んだりしてた。Trackpointの時刻は問題なし。
今データの管理に使ってるAscentで問題なく処理できていたのはDistanceMetersではなくて
//TrainingCenterDatabase/Activities/Activity/Lap/Track/Trackpoint/Position
を優先して距離と速度を計算してたんだろうか？ GPSは誤差があるからそれは最後の手段かなぁ。直前のvelocityからあり得ないDistanceMtersが現れたら無視する実装かなぁ。
結論としてこの点に関して(基本的には)Golden Cheetahは悪くなくて、Garmin Edge 705のFW2.60のログがダメだったという感じ。FW2.90だと奇麗で問題なさそうに見える。
いつぞやのFW2.80にからむPowerのスパイクとか含め、元データとしてダメなTCXファイルを奇麗に修正しておいた方が後々幸せか。Ascentは取り込んだ生データを編集する機能があるので実はあまり困らないのは秘密。というわけでGolden Cheetahを評価する前にtcxlintを書くことになりそうな今日この頃。
うーん、このへんの深追いは楽しいんだけど自転車に関してはこれ系であまり時間とりたくないなぁ...