なんとかプロトタイプをPlone Productsとして実装したものの、まだまだ課題山積。今回はそれをやっつけに行きます。最大の山はGPXログのポイント数間引きですなぁ・・・（；´Д｀）

前回の課題に入る前に・・・

　いやいや、GPXログファイル解析の根幹となる緯度経度の差から走行距離を算出する計算が間違ってましたｗ

　総走行距離が200kmぐらいあるログでもせいぜい1～2kmぐらいしか誤差が出てこなかったのでこんなもんかと思ってたのですが、方位角を算出するとなんだか有らぬ方向へ飛びまくり。処理を見直してみると緯度と経度、三角関数上のX軸、Y軸の関係が逆になってた訳でした。・・・そりゃぁ有らぬ方向へ飛ぶ罠・・・。

　ということでバグを修正しつつ、新たに解析の題材となる以下の各ポイント間の数値を算出するように処理を追加。

1. 方位角 - (北が0°、東が90°と時計回りに増えてく)
   
2. 沿面走行距離 - (今までの距離は平面上でのものなので、距離をX軸、高度差をY軸とした長辺の距離を算出)
   
3. 加速度 - (使うかどうか分かりませんが単純に”a=(v1-v2) / t”で算出)
   

　ちなみに誤差判定はカシミール3DでGPSログを読み込ませた結果を基準として使用し、ヲレ解析結果と見比べてます。うーん。やっぱりカシミールは高機能だよなぁ・・・。

前回の課題対応

　ということで以降は前回の課題に対して行ったものをつらつら柿升。

１．GPXログ間引き処理実装

　間引き方法をgoogle神にて探してたら基礎となる理論を発見。・・・なるほど。でも、この「誤差」をどこのデータを元にして算出するかが問題だったのですが、いろいろ試してみたら「隣接ログポイントの距離」に落ち着きました。

　方法としてはこんな感じです（←）。

　こうすれば、直線は間違いなく間引かれて、逆に角度が鋭角になるほど距離の誤差が大きくなって残りやすくなるし、角度が鈍角でもポイント間の距離が離れれば離れるほど残りやすくなる・・・はず。

　実際、この方法で生のGPSトラックログでは3,018pointある直線あり、ワインディングありのツーリングで記録したものを25%の753pointまで間引いてみたところ、なかなかいい感じに出来上がってました。

もうちょっと間引いてdefaultを20%ぐらいにしてみてもいいかなと。取りあえずこれで間引き処理はFix。

２．速度グラフ、高度グラフのY軸方向の値を平均化

　高度グラフは諦めましたorz 隣同士の高度差が50m以上だったらそのポイントは抹消するみたいなロジックを一回組んでみたのですが、うまくいかず。速度のほうはそれなりにできたので実装。これでマッハを越える速度が出なくなりました。

　とは言っても、平均化ではなく、単純に車とかバイクではあり得ないような加速を示す計算結果が出てきたら、どうにかして間引くようにしたので主旨がちょっと違いますけどね。

↑の異常加速閾値として、ヲレのバイク(CBR1100XX)のSPEC上での0-100km/h 到達時間、2”36 をもうちょっとふやかして採用してます。倍ぐらいにしてたっけ？忘れちゃったｗ　でもグラフの「見た目」がよくなったのでよしとしてます（つまり、理論的裏付けが皆無ｗｗｗうぇｗｗ）

３．測定開始時のバタつきログ消去

　カシミール3D とかでログファイルを読み込んで見た目では「ここがバタついてる」とか「この高度差はないわｗ」とかは分かるんですが、ロジックにできないこのもどかしさｗ

　一点集中型（？）で、隣接するデータで高度差、速度差、方位角など一定の閾値以上のやつは消してみるとかやってみましたけど、実際はそのポイントを消すのではなく、直前のポイントデータを消すとそれなりになるとかあったり（トンネルに入って出たときによくあるパターンでした）、と検出方法が全く確立できない。

　よって、この機能は手動でｗ　Ploneにうｐする前に、上記のソフト等で読み込んで手動フィルタリングする方式（？）を採用。

４． GPXログ解析処理起動ポイントの変更

　Archetypes のソースを hack してたら見つけました。・・・こんなのがあったのか。

◆[$INSTACE_HOME]/Products/Archetypes/BaseObject.py

class BaseObject(Referenceable):
      :
      :
    # This method is only called once after object creation.
    security.declarePrivate('at_post_create_script')
    def at_post_create_script(self):
        pass

    # This method is called after every subsequent edit
    security.declarePrivate('at_post_edit_script')
    def at_post_edit_script(self):
        pass
      :

　新規に作成したときに at_post_create_script() を、編集されたときに at_post_edit_script() をそれぞれのフィールドの更新が完了して表示処理に移行する直前で呼んでくれるみたいです。すばらしぃ～～～。

　これを使わない手はありません。今回の処理は、新規、編集共に同じことをさせたいのでこんな感じに。

class GGPXPolyline(ATCTContent, HistoryAwareMixin):
      :
      : 
    security.declarePrivate('at_post_edit_script')
    def at_post_edit_script(self):
    
        #### GPXログファイル読み込み＆解析処理をココに
        #### 各フィールド更新処理もここに

    security.declarePrivate('at_post_create_script')
    def at_post_create_script(self):
        self.at_post_edit_script( )

５．kmlファイル作成時のパラメータチューニング

　うーん。ムリですなｗ　やっぱり、<LookAt> タグの中で動的に変えられるのは <latitude> と <logitude> のタグぐらいでした。あとは見た目で固定値に。

６．クラス構成の見直し＆Pythonコード的にもうちょっと・・・

　そりゃムリな注文です。現状維持確定ｗｗｗｗ

７．GPS情報入り画像ファイル用「GImageMarker」を新規作成

　ざっくり作成。EXIFの位置情報の測位系が Tokyo のやつもあるので、簡易的な Tokyo → WGS-84 変換機能も装備させました。

　しかし、動かすには バグ修正版の exif.py が必要（下記にリンク張ってあります）。これがないと多分作成時に error が出ます・・・(;´Д`)

そんなわけで

　取りあえず動くので、勝手にリリース。GImageMakerを使うのならば↓の exif.py も持って行って、$[INSTANCE_HOME]/Products/ATContentTypes/thirdparty/exif.py と差し替えてから Zope をリスタートさせて下さいな。

↑ ATPhoto関連でいじったので余分なもんが入っていますが、基本処理には支障なすですというか、いじらないとロクに動いてないのですｗｗ　だれもEXIF情報なんて見ないからこのバグバグ君ソースが表に出てないんだろうなぁと推測。

　次回は・・・GPＸファイル解析処理系はこれでFixさせておいて、表示関係に重点を置くべきかなと。