MySQLでもジオメトラー(5)

メモ MySQL GIS

…と、いう訳で実際に触れてみた
途中、間違ってMySQLのシステムDBを消去して再インストとか大変に楽しい事象が勃発したが全スルーだ

まずはPostgreSQLの空間DBからタブを区切りとした"カラムデータのみ"のtxtファイルを作り出す
次にMySQLで空間DBを作成した。予想は外れることなく、すんなり通る
次に、txtデータを読み込んでカラムに格納させてゆく。こちらは多少予想が外れて四苦八苦

LOAD DATA INFILE <file_name> INTO TABLE <table>;

これでokだった。ただし、txtはbinに置かないと404だ
で、これでデータが流し込めたかと思ったのだがどうもエラーが吐かれている。ジオメトリーじゃない情報をジオメトリーに入れるな、とアナウンス
どうやらこの方法では不可能らしい

次の方法は至極簡単な方法
PostgreSQLにPHPで接続、必要な情報を抜き出して、切断。続いてMySQLに接続、インサートを発行してデータを流し込む
アルゴリズムとしては
PostgreSQL接続
↓
全件検索=>配列に順次格納
↓
切断
↓
MySQL接続
↓
配列情報を順次インサート
これにした。PostgreSQLから抜き出してきたデータは

POINT(137.363202111 34.661214848745)

とか

MULTILINESTRING((137.42856021696 34.742044427495,137.4297445524 34.741505477489))

の文字列で格納されている。この文字列を

insert into <table> (<geom_name>) values (GeomFromText('<geom_date>'));

の部分に嵌め込んでクエリー発行。何の問題もなしでうまくいった
これで、PostgreSQLのジオメトリ情報を全てMySQLジオメトリに移せた訳だ。少々強引くさいが
意気揚揚とDOSでselectしてみる。条件なしの全件表示だ

| 11345 |翔ム@モ*a@・7~ケUA@&#63731;ワKPヤ*a@e{&#57401;トUA@|
| 11346 |>Bモ*a@ミ閻FトUA@&#63731;ワKPヤ*a@e{&#57401;トUA@|

格納されているジオメトリが文字化けている!!
ジオメトリはバイナリコードなはずだから、マルチバイトの問題が無いはず。MySQLのテーブルデータをDOSで覗くと、日本語が文字化けている事はままあるが…バイナリが文字化けるとはどういうことか?
MySQLの設定を拝んでも文字コードに問題は見当たらない
PostgreSQLの文字コードがEUC-JPなので、MySQLとの差異で文字化けが発生しているのかとも思ったが、この文字化けは違うらしい
EUC-JP文字コードのphpよりテーブルに日本語を突っ込んでみたが、引き出して出力するとちゃんと日本語で出てくる。特に問題はなさそう
とりあえず、データの格納時にエラーも出ていないのだからこれで良いのかとテスト
ジオメトリの全件検索で返されるジオメトリ情報をWell-Known Textに指定した
カラム名称が要素な連想配列で返されるので、ループしながら順次連想配列を吐かせようとphpを組む。そして起動

MySQLから値が帰ってこないorz
クエリエラーが出ないので、どうやらクエリは正しい様子
では、原因は何なのか
とりあえず吐き出しをダイレクトに要素を指定していたので配列その物にprint_rを掛けてみる(Well-Known Textで要求した場合、$array['astext']で帰ってくる)
結果…

array([id]=>11345 [astext(geom)]=>MULTILINESTRING((
137.44562433574 34.74488685784,137.44631560764 34.744543691275, 
137.4461396955 34.744197014559,137.44520356106 34.744148584475,137.44517758902 34.744219953141, 
137.44562433574 34.74488685784)))

ちょっとまてや(怒
astext(geom)って何だ。いや、()内の名称はジオメトリカラムの名前だが…
何だこの仕様。どうやらpostgreSQLとこの部分が違うらしい

で、データが無事に移行できた事が確認できた
MySQLのジオメトリ情報はバイナリ以前に、何かコーディングされているのか。そういえば、Well-Known Text以外にWell-Known Binaryがあった。それはこの仕様に対するものらしい。…むぅ
だとすれば、MySQLに移したら最後ジオメトリデータを別の媒体に動かすのは労力がいることになってしまうのか。そりゃ、MySQLでGISが組まれない訳だ
後、返されたWell-Known Textを見ていて気が付いたのだが…
yの最下位桁がPostGISより一つ少ない。どうやら四捨五入されて整合性を図ってる様子だ。ますます使えない