位置情報HACK4題

位置情報関係のHACK4題です。

まずはMapServer関係のHACKから、Nakamura-KU ADDICTさんとこで、自分のサイトを訪れた人の所在地（国）をGeoIPで解析して、訪問者数を色の変化で表してくれるHACKが公表されてます。

GeoIP + Shapelib + MapServerで国別の主題図

GeoIP(Python) + Shapelib(Python) + MapServerでApache logの国別の主題図を作ってみました.

Blogを飾るマスコットとしてなかなかかっちょいいです。
うちで導入してから紹介しようと思ってたのですが、pythonなので慣れてなくてなかなかうちでは環境が作れないので、お先に紹介しました。
一応うちで掴んでる限り、

• GeoIP Library　（C及びpython）
• Shapefile C Library
• pyshapelib

アタリをインストールしないといけないみたいです。
これだけでよいかは、まだ環境作成に成功していないので不明ですが。
あ、もちろんMapServerもね。

続いて、なおっきさんちの、京ぽん位置情報を使ってGoogleローカル携帯版でのサーチを行うHACK。

Google LocalをAIR-EDGE PHONEの位置情報対応版！さらに便利に

Google LocalをAIR-EDGE PHONEの位置情報対応版！さらに便利にしてみました！

Googleローカル携帯版の登場自体は、私にとっては、ここギコを始める一つの契機にもなった1998年NTTソフト研のモーバイルインフォサーチ２実験を知った衝撃から、大昔にこの辺の記事を書いたあたりの、個人の思いの系譜に一つの区切りがついた感じで、語りだすと長暑苦しいアレになりそうなのでまたの機会にまわすけれど、

このHACK、同じ方法でauのGPSケータイでもできそうですね。
というか、単にau版のGoogleローカルで同じ事をやっただけでは、地図画像が配信されないので（なんでいつもGoogleはauをみそっかすにするのか！）ゲートウェイを作る必要がありますが。
とりあえず地図画像部分は、地図部分のURLが取得できさえすれば、auで叩いても画像の閲覧ができる事は確認しました。
あと、アイデアとしては、DoCoMoのオープンiエリアでも、東京とかの大都市圏だけですが、取得できるエリア名がまさにGoogleローカルの地名としてそのまま使えそうなアレなので、エリアを取得した後そのエリア名（／で複数地名があるものは選択するようにして）を地名欄に突っ込むHACKとかもできそうですね。

お次はジオコーディングのHACK。

日本の住所のGeocoding - Digital Life Innovator

Google Maps APIを使っているとリアルタイムに住所を経度緯度情報に変換したくなります。
そこで、他力本願ながらGeocodingのRESTサービスもどきを作成してみました。

これで、Nakamura-KU ADDICTさんとこの逆ジオコーダと合わせて正逆そろったので、いろいろ応用が効きそうですね。
ただ、負荷的には、同じく公開サービスである CSVアドレスマッチングサービスへの外注なので、できる人はそっちを直接叩いた方がいいでしょうが、
とはいえそちらは取り合いがファイル交換を模してやらなければならず、結構鬱陶しいところを、こっちはRESTでお手軽なので、非常に有用そうです。

最後に、Google Mapsで世界測地系を透過的に扱うように、Google Maps APIを拡張するHACK。

wgsgmap.js - Tociyuki::Diary

Google Maps APIと合わせて使うための、世界測地系(WGS)の経緯度座標と長方形領域を扱うjavascriptのクラス・ライブラリです。
昨日のものと同等ですが、もしもGoogle様がきまぐれで測地系を修正しても、修正個所が少なくて済むように作り直しました。
BSDライセンスです。

測地系の変換法としては平行移動を採用されているので、マップモードで使う場合は　こちらのエントリに書いた誤差が生じる可能性があるので注意が必要。
というか、比較的正確な測地系変換を採用した方がいいと思います＞作者の方
三角関数を使わない方法と、Molodensky法では、私のPC上でfirefoxでやる限りでは、100件くらい変換してベンチマークを取ってもほとんど変わらない、というか平均する限りMolodensky法の方が速い（そんなはずはないので、何か三角関数を使わない方でミスしてるかもしれないけど...でも計算結果は両者でほぼ一致）ので、他のところでも有意差がなければMolodensky法を使った方がよいかと。

うちでも同じ事を考えてて作っているところだったんだけど、うちの場合、開発の実力や時間がないのもさる事ながら、計画力がないのが最大の問題かな、という気がしてきた...。
もともと、JSANモジュールの形態でPerlのLocation::GeoTool互換に近いものを作ろうと取り組んでいたんだけど、でもGoogle Mapsと連携して動作させるならGPointクラスのラッパとして動作する方がいいかなと方針転換、でもいざある程度できてみたら、テストの際に変換結果を表示させてみて度表示でしか出てこないのが気に入らなくて、度表示をdms表示にフォーマット変換するインタフェースも欲しいな、やっぱりLocation::GeoToolベースで作るか、Location::GeoToolのオブジェクトから対応するGoogle APIのオブジェクトを生成する形の方がよいかも...と仕様が2転3転。
もうちょっと事前に計画してから物事進めるようにしましょう　＞　俺。