開発しているとリポジトリ名とか何かとプロジェクトに名前が必要になるので、Account Aggregator を縮めて accagg と名付けました。
前回まででとりあえず三井住友銀行の取引明細を取得することができたので、データを正規化してCSV形式に保存することを考えます。セキュリティを考えると平文のCSV形式なんて論外なのですが、そこは後々実装します。試す場合は個人の責任でお願いします。
前回は main にすべての処理を書いていたので、今後のことを考えてクラス分けしてみます。作ってみたクラス図は以下です。
正直クラス図が合ってるかわかりません(汗 なんとなくやりたいことが伝わればいいかな。
Python と Selenium でスクレイピングのお勉強です。
Selenium は外部プログラムから Web ブラウザを操作することができる仕組みで、元々は Web アプリケーションのテスト自動化のためのツールだったようです。クリック、キー操作を外部アプリから操作できるので、技術的にはWebブラウザでできる全てのことを自動化するが可能です。
Selenium を使える言語としては Java, ruby, C#, Python, JavaScript のバインディングがあるのですが、Web を探してみるとスクレイピングの使い方としては Python + Selenium の情報量が圧倒的に多いため、Python で使ってみたいと思います。一般的には、Python + Selenium(ブラウザ制御) + Beautiful Soup(HTMLパーサ) の構成が多いようです。
概要をサラッと知るには Web よりも本のほうが良さそうなので、以下の書籍を買ってみました。
…続きを読む
SL-6000 シリーズにも SDHC ドライバが欲しいとのコメントを頂きまして、本格的に調査しようと思っていたのですが、私は実機を持っていないのです。試しにオークションを覗いてみたら1万円もするんですね。私にはちょっと気軽に買えません。
そこで会社の人に聞いてみたところ、SL-6000 を持っている人がいたのでを借りてきました。
結構大きいし厚みがありますね。
どれくらいの大きさなのか SL-A300, SL-C1000 と比べてみました。
スライド式のハードウェアキーボードがあるため縦に長いですが、横幅は SL-C1000 より少し小さいようです。
厚みは SL-C1000 より薄く、SL-C1000 の画面を開いた時+α 位のようです。
LCDが反射型液晶なので外での視認性は抜群ですね。qgmap には向いてるかもしれません。
反射型液晶って昔の携帯みたいにあまり発色がよくないイメージがあったんですが、SL-6000は綺麗だったので驚きました。 カラーの反射型液晶ってあまり見かけないだけで結構綺麗なんですね。
早速SDドライバまわりを確認してみましたが、3桁機と同じパスにありました。3桁機と同じ PXA255 なのでカーネルも同じなのでしょう。
ただ、気になったのはドライバのサイズが結構違うこと。各機種の sharp_mmcsd.o のサイズは以下のようになっています。
SL-A300 は限定的ながら SDIO の処理が入っている(PHSカードのみ使用可能)ため大きいのと、4桁機は PXA255 と PXA270 でSDコントローラが違っているため大きくなっているとして、SL-6000は同じ PXA255 のSL-CXX0 より結構サイズが増えています。
作りが変わったりしていなければいいのですが・・・。
久しぶりに開発途中のネタです。
POI の最寄検索や、検索結果表示で現在値からの距離を表示させたくて、任意2点の緯度経度から距離を計算する方法を調べてみました。
地球が球体なら何となく頭をひねれば分かるかもしれませんが、楕円体の緯度経度から距離を求めるのは私には見当もつきません。
ということでググってみると、楕円体を考慮していて、世界中の緯度経度で通用しそうな計算式が2つ見つかりました。
何となく航海で使用する下の公式のほうが正確な気はしますが、上のヒュベニの公式の方が演算が簡単そうな気がします。
また、qgmapでは多少の誤差も許容できるので数％程度(?)の精度で十分です。そこで近似式も候補に入れてみます。
これらの計算式がどの程度の正確さなのか、ランダムに選んだ緯度経度で計算して誤差と計算速度を検証してみました。
とはいえ、検証しようにも正解がわからないので、とりあえず国土地理院のサイトで2点間の距離を計算できるようですので、そのサイトとの誤差を調べました。つまり、実際に正確かどうかの検証ではなくて、国土地理院のサイトの公式に近いかどうかの検証です (^^;
で、結果は以下のとおり。
縦軸は国土地理院サイトで計算した距離(a)と、公式で計算した値(b)の誤差の割合(|a-b|/a) で、横軸が2点間の距離を示しています。
さすが航海算法と呼ばれるだけありLambert-Andoyerの公式は距離によらず 10^-5 以下の誤差率になっています。
ヒュベニの公式は50km以下ではLambert-Andoyerの公式と同等ですが、距離が離れるほど誤差が大きくなっていくようです。
簡易近似式は1000km以下では誤差0.1%前後で、1000kmを越えるとヒュベニの公式と同様誤差が増えていきます。
また、それぞれの公式を Zaurus で計算させた時の時間も測定しました。ちなみに、スペシャルカーネルを使っているので、浮動小数演算が高速化される FastFPE パッチが適用されています。
測地線航海算法のHPにはLambert-Andoyer と式的には同じですが、計算量が少し少ない小野の公式というものも載っていたので、こちらも計測しました。
| 公式 |
1万回の計算時間 |
| 近似式 | 0.2838 sec |
| ヒュベニの公式 | 0.5043 sec |
| Lambert-Andoyerの公式 | 2.8202 sec |
| 小野の公式 | 2.6518 sec |
やはり近似式は演算量が少ないので高速ですね。1万回の計算が0.3秒なら充分実用的です。
ヒュベニの公式は近似式に比べ 1.8倍、Lambert-Andoyerの公式が10倍、小野の公式が9.5倍の時間がかかりました。
やはり精度が高い下の2つの公式は三角関数の演算などが多いため遅いですね。ただ、同じ結果が得られる小野の公式は少し早いようです。
結論
近似式が思いのほか精度が高かったので近似式を使おうと思います。
もともと精度も1%程度あれば十分かなと思っていたので、qgmap には充分ですね。
開発は案外こういう自己満足的な調査が楽しかったりするんですよねー。
ようやく正式版の 0.1.0 をリリースできました。
これもひとえにtera様、y様、sugarware様を初め、他にも qgmap を使っていただいている方々のおかげです。
振り返って見ると、alpha1からちょうど1ヶ月位経つんですね。この1ヶ月でかなり qgmap も私も成長させていただきました。
改めて深く感謝申し上げます。ありがとうございました。
さて、一区切りついた qgmap ですが、まだまだ機能拡張は続ける予定です。
0.1.0 でクラス構成を大きく変更したおかげで、今までの地図画面に重ねて何かを表示することが簡単にできるようになりました。そのため、GPSの軌跡表示や、y様のご提案にあった、フリーハンドで範囲指定して GM_Lite の地図取得コードを出力するような機能が比較的容易に実装できるようになりました。
今のところ考えている機能は以下のとおりです。
ちょっと面白そうという個人的興味で、フリーハンド地図取得範囲指定機能を先に実装しようかなと思っています。
ちまちま作っていきますので、長い目で見守ってください。
これからもよろしくお願いします。
最近めっきり進捗の無い地図レシピも進めないとな・・・(^^;