2006年11月14日
MySQL4.1以降での空間情報の扱い方
Web2.0ワークショップで講演するのに、ただでさえ一人だけ素人でまともな講演できるか不安なのに、勉強せずに今の知識だけではいかんだろうということで、今までほったらかしてきたMySQL4.1以降の空間情報利用法を勉強。
といっても、こちらに4.1の日本語マニュアルあるので全然苦労なしだが。
ただ動作確認は5.1でやっているので、英語版5.1マニュアルとの照らし合わせはやってますけど。一応。
PostGISとの比較で書くと、PostGISの場合、PostgreSQL本体とは別のプラグインであるせいか、位置情報カラムのついたテーブルはいっぺんにはできない。
例えば、geodbデータベースに、idと位置情報カラムgeom(ここではPOINTだけを含むカラムとする)を含み、かつ位置情報カラムに空間インデックスを張ったテーブルgeotableを作る場合の、PostGISでのSQLはこんな感じ。
CREATE TABLE geotable
( id SERIAL NOT NULL PRIMARY KEY);
SELECT AddGeometryColumn
('geodb', 'geotable', 'geom', 4326, 'POINT', 2);
CREATE INDEX geom_idx ON geotable
USING GIST ( geom GIST_GEOMETRY_OPS );
これに対し、DB本体に空間拡張が組み込まれているMySQLでは、この空間カラム入りテーブル作成、ついでにインデックス張りが一気にできる。
CREATE TABLE `geotable` ( `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , `geom` POINT NOT NULL, SPATIAL INDEX(geom) ) ENGINE = MYISAM ;
注意すべきは、PostGISでは4326(世界測地系WGS84での経緯度座標系を表すEPSGコード=SRID)のように空間参照座標系を指定できるのに対し、MySQLではこの情報をカラムに対しては持っていないこと。
MySQLでも、データの挿入時にSRIDをオプションでつけたデータを入れることはできるのだが、将来のバージョンでは不明だが今のところはSRIDは単なる参考情報扱いで、空間情報カラム内ではSRID情報は全く参照されず、空間参照系情報を持たないベタな単一の2次元直交座標系として扱われる(つまり、SRID=4301だろうがSRID=4326だろうが、POINT(135.0 35.0)はカラム中では同じ点を表す)。
よって、PostGISならばSQLひとつでできるような、測地系変換や投影変換のような芸当は、MySQLにはできない。
また、今のところ空間カラムを含むテーブルの作成はMyISAMでしか作れない点にも留意が必要。
すみません、誤情報でした。5.0.16からInnoDBなどでも使えるようになったようです。
今度は、データの挿入。
世界測地系東経135度、北緯135度のデータを挿入するなら、PostGISだとこんな感じになる。
INSERT INTO geotable (geom)
VALUES (GeomFromText('POINT(135.0 35.0)',4326));
MySQLだと、こんな感じ。
INSERT INTO geotable (geom)
VALUES (GeomFromText('POINT(135.0 35.0)'));
SRIDの設定がない以外は(先にも書いた通り、オプションで入れられるが)、PostGISとそっくり同じである。
これは別に真似をしたからではなくて、この辺の空間データベースでどのように空間データを扱うかという事はOGCというところで標準的なインタフェースが定められているので、それに従った結果だ。
続いて、南西角東経130度・北緯30度から、北東角東経140度・北緯40度の範囲の矩形内に含まれるデータを検索する場合、PostGISならこんな感じ。
SELECT id,AsText(geom) FROM geotable
WHERE geom && GeomFromText
('LINESTRING(130.0 30.0, 140.0 40.0)',4326);
空間カラムと東経130度・北緯30度-東経140度・北緯40度を結ぶ直線の間を&&演算子で演算した結果をSELECTしているが、&&演算子は自動的に引数となる2項の空間情報それぞれのMBR(Minimized Boundary Rectangle、最小外接矩形)を求め、その間の重なり関係を空間インデックスを用いて演算してくれるので、これでやっていることとしてはいい事になります。
AsText関数は、空間カラムをそのまま表示すると訳の判らんバイナリ表示になるので、WKT(Well Known Text)形式と言う、例としてはPOINT(135.0 35.0)のような人間にも判り易いOGC標準の記述形式に直してくれる関数です。
MySQLだとこんな感じ。
SELECT id,AsText(geom) FROM geotable
WHERE MBRContains(GeomFromText
('LineString(130.0 30.0,140.0 40.0)'),geom);
単に、PostGISの2項演算子&&が、2引数の関数MBRContainsに変わっただけという感じですね。
というふうな感じで、PostGISと比べるとまだ今のところできるのはMBR間の関係を用いた検索のみで、PostGISでできる測地系変換や投影変換、距離を元にした検索、空間データの結合や差分演算なんかはできないみたいですが、それでも例えば、Google Mapsの表示範囲の矩形を取得して、その範囲にある空間データを検索して表示される、くらいのことはMySQLの空間拡張でも十分できるようになっています。
これまで情報がなかったのであまり使われていないかもしれませんが、こいつもPostGIS同様使ってやってください。
Excerpt: [[ここギコ!: MySQL4.1以降での空間情報の扱い方|http://kokogiko.net/m/archives/001812.html]] か...
Weblog: 飛べない日々
Tracked: 2006年11月17日 01:22
Excerpt: 随分以前に、GoogleMapsと連動したいなら幾何データ型よりPos...
Weblog: ここギコ!
Tracked: 2008年11月13日 12:52
こんにちは。
http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?MySQL
に.mapファイルの書き方があります。しかし、
DATA "geometry from TELEFON_LINE feature, TELEFON_LINE_bin geometry"
のところが理解できなくて、いろいろ試しても当方ではMySQLテーブルにMapServerからアクセスできません。
もしお分かりになりましたら、ご教示願います。l
リンク先見てみましたが、これ、MyGISとかいう名で知られる、空間拡張に対応していない(or 対応していてもそれを利用しないで)MySQLでMapServerとどう連携するかの情報ですね。
4.1以降の空間拡張を利用してMapServerとどう連携するのかは私もよく知りません...確かまだそういう経路はなかったんじゃないかと思います...。
![[ここギコ!]](http://kokogiko.net/logo.png)



・「定義できない」とのたまうものを自説根拠の説明の中で延々と使う不誠実(笑)(むにゅう!)
・絵文字標準化でのキャリア批判に思うこと(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・絵文字標準化でのキャリア批判に思うこと(ひゅ〜)
・絵文字標準化でのキャリア批判に思うこと(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)