GoogleMapsと連動したいなら幾何データ型よりPostGIS

なんか向こうのコメントに書き込んだのだが、よく判らんが削除されてしまったのでこっちのエントリで取り上げる。

データベース上の位置情報を効率的に検索する方法(PostgreSQL編) -Web屋のネタ帳-

たとえばおいしいケーキ屋さんの位置情報がデータベース上にあるとしよう。...GoogleMapsなどである範囲の地図を表示したとして、お店の位置を地図上にマーキングさせたい場合には、その地図の範囲の情報をキーにしてデータベース上の緯度経度を検索する必要がある。
　　.........
だが、ひとたび

• ある1点から半径rの円内に該当するデータを検索したい
• さらにその検索結果を、中心点からの距離でソートしたい

といったことになると、とたんに難しくなる。しかし、PostgreSQLにもう5年以上前から実装されている幾何データ型、幾何関数、幾何演算子を使えば、SELECT一発でできることだ。

幾何データ型という親しみのない型に関していろいろ情報公開してくれるのはいい事なんだけど（俺も知らないことあったし）、こと「GoogleMapsと連携」等と分野を絞って記事を書いた途端、すげえ的外れな記事になる。
それを3桁に及ぶ人が軒並み「GoogleMaps」、「GIS」、ありがたやありがたやとタグ付けてるの見ると、この業界もまだまだ知られてないんだなあ...とがっくりくる。

まだMySQL使ってるのなら判らないでもないが、なんでPostgreSQL使っているのに、位置情報扱うのに組み込みの幾何データ型使う必要がある？
なんでPostGIS使わない？

座標（当然GoogleMaps等との連携で考えてるのだから経緯度データを考えてるのだろう）で突っ込んだデータを、幾何データ型使うと半径ｒの円検索できる！と元記事では書いてたけど、経緯度ベースで円検索して何が嬉しいんだ？
この辺見たら判るとおり、経度に沿った緯度1度分の長さと、緯度に沿った経度1度の長さは全然違うぞ。緯度に沿った経度1度分の長さは、その地点の緯度によっても大きな誤差が出る。
それとも、Proj.4ライブラリ使って、mベースの座標系である19座標系に変換した上で格納するのか？Proj.4インストールして使いこなせるなら、素直にPostGIS使っとけ。

少なくとも、飽くまでPostGISは難しすぎる、組み込み幾何データ型でざっくりGoogle Maps連携できる！とか記事書くんなら、むちゃくちゃとんでもなく荒すぎる近似だけど、東経135度、北緯35度付近の経度1秒分の長さ25.36m、緯度1秒分の長さ30.82mで日本全体を近似して、

CREATE FUNCTION metrize(point) RETURNS point AS'
    DECLARE
        ret point;
    BEGIN
        ret = point(($1[0]-135.0)*60*60*25.36,($1[1]-35.0)*60*60*30.82);
        RETURN ret;
    END;'
LANGUAGE 'plpgsql';

みたいな各経緯度座標値を東経135度、北緯35度からのざっくりm座標系に修正する関数でも定義して、それをベースにインデックスは

    create index testindex on geodata using gist(circle(metrize(geo),0));

検索式は(東経140度、北緯40度を中心とした超雑雑ざっくりいい加減周辺400m検索)

    select * from geodata where circle(metrize(geo),0) @ circle(metrize(point(140,40)),400);

みたいにする、とでも書かなきゃ、幾何データ型でGoogle Maps云々は嘘だろう。
別にPostGISがあるんだから、こんな言い加減な事するの薦めないけど。

別にPostGISの導入は難しくない。
Windows版のインストーラなら、標準で最初に導入を選択できるオプションとして付いてくる。
ソースからのインストールだって、前提となるProj.4ライブラリ・GEOSライブラリも、以前は難しかった記憶があるが今は、昨日久々にインストールしてみたらconfigure実行するだけで普通にコンパイルできた。
PostGIS自体も、以前はPostgreSQLのソースツリーの中に突っ込まないとコンパイルできなかった記憶があるが、今は普通にpg_configの場所さえ指定してやれば後から追加できる。
簡単簡単。
たったこれだけで、ちゃんと地理座標系を考慮した、多次元のPOINT型はもちろんLINE型、POLYGON型といった地理図形オブジェクトが格納できるし、共通に空間インデックスを張る事もできる。
distance_sphereやdistance_spheroid系の関数を使えば、ちゃんと地球という回転楕円面上で測定した距離を元に、検索することもできる。
地理図形オブジェクト同士の衝突や接触、内包判定から、地理オブジェクトをマージして、新たな地理オブジェクトを作る、といったことも簡単に出来る。
他でもないPostgreSQLで、地理データを扱うと言うのに、PostGISを使わずに何を使うと言うのか。

また最近ではPostLBSなんてのも出てきてて、円検索どころか、道沿いに一定距離歩いて/運転して到達出来る範囲の検索や、巡回セールスマン問題とかだって、「PostgreSQLのSQLクエリーの上で」解けるようになっている。

最近横浜スローライフさんは、Where2.0の雑感記事で、

れからは「ポータルサイト（GoogleMapsとか）」と「オープンソース」がこの業界（GIS・位置情報）を動かすようになると思う。
それらは互いに対立することもあり得るが、同時に「ポータルサイトの公開API」に「オープンソース」を組み合わせる（Mush up）ことが”常識”にもなっていくだろう。

と書かれていたけど、世間ではその「オープンソース」とやらは、所詮LAMP（「L＝Linux（プラットフォーム）」「A＝Apache（プレゼンテーション層）」「M＝MySQL（データ層）」「P＝PHP（ロジック層）」）の言葉で代表される分野にしか視野は当たってなくて、それ以外の世界があるという事にも気付いていないのだなあと実感。
常に動きの中心にいるGoogleが、最初は測地系も投影法もろくに判っていないところからGoogle Maps始めて、いまや押しもきらないGIS分野の中心プレーヤーになりつつあるというのに、その信奉者連中にはまだ全然GISの情報等浸透していないのだなあ、と思うとがっくりくる。

手前味噌ながら、この本でも読んで勉強しなはれ。