2006年11月14日

MySQL4.1以降での空間情報の扱い方

Posted by nene2001 at 01:25 / Tag(Edit): mysql spatial / 2 Comments: Post / View / 2 TrackBack / Google Maps このエントリーを含むはてなブックマーク

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同様使ってやってください。

Related query words in Google & Yahoo
Related Books from Amazon
Trackback to this entry
TrackBack URL :
Trackbacks
[GIS]PostGISのAddGeometryColumnとMySQL
Excerpt: [[ここギコ!: MySQL4.1以降での空間情報の扱い方|http://kokogiko.net/m/archives/001812.html]] か...
Weblog: 飛べない日々
Tracked: 2006年11月17日 01:22
GoogleMapsと連動したいならPostGISの他にmysqlという選択肢も出てきた あとジオメディアサミット関西も
Excerpt: 随分以前に、GoogleMapsと連動したいなら幾何データ型よりPos...
Weblog: ここギコ!
Tracked: 2008年11月13日 12:52
Comments

こんにちは。
http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?MySQL
に.mapファイルの書き方があります。しかし、
DATA "geometry from TELEFON_LINE feature, TELEFON_LINE_bin geometry"
のところが理解できなくて、いろいろ試しても当方ではMySQLテーブルにMapServerからアクセスできません。
もしお分かりになりましたら、ご教示願います。l

Posted by: YuGo at 2006年11月21日 11:57

リンク先見てみましたが、これ、MyGISとかいう名で知られる、空間拡張に対応していない(or 対応していてもそれを利用しないで)MySQLでMapServerとどう連携するかの情報ですね。
4.1以降の空間拡張を利用してMapServerとどう連携するのかは私もよく知りません...確かまだそういう経路はなかったんじゃないかと思います...。

Posted by: ねね at 2006年11月23日 10:16
Post a comment












Remember personal info? 
2006年11月
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

About Me

Navigation

Search
Google
Web
kokogiko.net
Archives
Recent Entries
Recent Comments
Recent Trackbacks
姫路のオモシロ寿司屋(ここギコ!)
0系こだまとひかりレールスターに乗ってきた ドクターイエローも見た
姫路のオモシロ寿司屋(ここギコ!)
位置情報ベース広告AdLocalへ一般からも入札が可能に
「定義できない」とのたまうものを自説根拠の説明の中で延々と使う不誠実(笑)(ここギコ!)
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択
現代アイヌの政治運動は利権獲得のためのようだな。(むにゅう!の平和大好き! はてな基地)
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択
的外れですた恥ずかしい Googleは世界標準の絵文字を作ろうとしてるわけではない、少なくとも、今のところ(ここギコ!)
絵文字標準化でのキャリア批判に思うこと
すごい職場の活性法(これが答えだ)
人員がクラスタ化できている職場と言うのはうらやましい そろそろ限界です
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(ここギコ!)
大和民族の定義云々について
歴史のダイナミズムの元では右翼こそ変わらなければならない(ここギコ!)
右翼はアイヌや沖縄を包摂する論理を構築すべきではないのか
右翼はアイヌや沖縄を包摂する論理を構築すべきではないのか(ここギコ!)
大和民族の定義云々について
政治と祭祀が不可分と考えるなら、全ての祭祀を引き受けるのが筋(ここギコ!)
大和民族の定義云々について
Hatena bookmarked
My del.icio.us

Banners

Syndication
Powered by
Get it!!