実行環境 インポート時にgeomety_columnsspatial_ref_sysテーブルも作られる 空間参照系カタログのspatial_ref_sys1行しかない(以上、102日) 地図で見る統計(統計GIS)から4種類のシェープファイルを準備(103日) 投入先データベース作成(文字コードUTF-8) インポート結果 : SRIDは単純に1からの連番だった PostGISと違い、生の空間データを見ても無意味(以上、104日)
Contents


同じ空間参照系シェープファイルの準備、インポート

忙しくて1週間空いてしまったけど、引き続きMySQL 5.7.8rcへのシェープファイル投入を試しました。作業前のデータベースは ↓ こんな感じで、4つの異なる空間参照系のテーブルが一つずつ。それぞれのSRIDは、空間参照系の識別でよく使われるEPSGコードと無関係に1からの連番になってます。

ogr2ogrで空間参照系が別々のシェープファイルをMySQLにインポートすると上のようになることは前回分かりましたが、今日は、同じ空間参照系のデータを追加で投入してみます。SRIDの言葉どおり同じSRIDになれば、EPSGコードと違うとは言えDB上で空間参照系を簡単に区別できます。

使うデータは、前回までと同じ総務省統計局「地図で見る統計(統計GIS)」から。
103に書いたのと同じ手順で、4つの空間参照系のシェープファイルのZIPをダウンロード。↓

ZIPファイル名は空間参照系で別々になっている一方、中に入っているシェープファイル名はどの空間参照系も同じ。ogr2ogrでインポートする際、ファイル名がテーブル名になるのがデフォルトの動作なので、そのままでは面倒。そこで各ファイルに空間参照系別の接頭辞を付けました。↓


インポートコマンドは
104の時のファイルパスを変えるだけで ↓ 特に問題なくできました。
$ cd
D:\AppsPortable\GDAL\release-1500-gdal-1-11-1-mapserver-6-4-1\bin

$ gdal\apps\ogr2ogr -progress -f "MySQL"
 MySQL:estat,user=root,password=******** R:\estat\XYSJC_h22ka01102.shp
# just one line actually

$ gdal\apps\ogr2ogr -progress -f "MySQL"
 MySQL:estat,user=root,password=******** R:\estat\XYSWC_h22ka01102.shp
$ gdal\apps\ogr2ogr -progress -f "MySQL"
 MySQL:estat,user=root,password=******** R:\estat\DDSJC_h22ka01102.shp
$ gdal\apps\ogr2ogr -progress -f "MySQL"
 MySQL:estat,user=root,password=******** R:\estat\DDSWC_h22ka01102.shp


結果:同じ空間参照系には同じSRIDが付いてた

まずテーブル一覧を見ると ↓ 確かに4つのシェープファイルごとに作成されてます。
mysql> show tables;

テーブルgeometry_columnsを見ると ↓ インポート前にあったSRIDがきちんと把握され、同じ空間参照系に同じSRIDが振られていました。一般的なEPSGコードとは違いますが、空間参照系ごとに一意の番号が付くので便利。なおSRIDの付け方はデータ投入順に依存するので、異なるデータベース間ではSRIDの共通性は基本的にありません(空間参照系ごとに投入順を決めて守らない限り)。
SELECT F_TABLE_NAME, F_GEOMETRY_COLUMN, SRID, TYPE
FROM geometry_columns;
+------------------+-------------------+------+---------+
| F_TABLE_NAME     | F_GEOMETRY_COLUMN | SRID | TYPE    |
+------------------+-------------------+------+---------+
| xysjc_h22ka01101 | SHAPE             |    1 | POLYGON |
| xyswc_h22ka01101 | SHAPE             |    2 | POLYGON |
| ddsjc_h22ka01101 | SHAPE             |    3 | POLYGON |
| ddswc_h22ka01101 | SHAPE             |    4 | POLYGON |
| xysjc_h22ka01102 | SHAPE             |    1 | POLYGON |
| xyswc_h22ka01102 | SHAPE             |    2 | POLYGON |
| ddsjc_h22ka01102 | SHAPE             |    3 | POLYGON |
| ddswc_h22ka01102 | SHAPE             |    4 | POLYGON |
+------------------+-------------------+------+---------+
8 rows in set (0.00 sec)

SELECT SRID, AUTH_NAME, AUTH_SRID, LEFT(SRTEXT, 35)
FROM spatial_ref_sys;
+------+-----------+-----------+-------------------------------------+
| SRID | AUTH_NAME | AUTH_SRID | LEFT(SRTEXT, 35)                    |
+------+-----------+-----------+-------------------------------------+
|    1 | NULL      |      NULL | PROJCS["Japan_Zone_12",GEOGCS["GCS_ |
|    2 | NULL      |      NULL | PROJCS["JGD_2000_Japan_Zone_12",GEO |
|    3 | NULL      |      NULL | GEOGCS["GCS_Tokyo",DATUM["Tokyo",SP |
|    4 | NULL      |      NULL | GEOGCS["GCS_JGD_2000",DATUM["JGD_20 |
+------+-----------+-----------+-------------------------------------+
4 rows in set (0.00 sec)

補足:ogr2ogrによるSRID設定について

下記によれば、ogr2ogrは「時々」投入先DBspatial_ref_sysテーブルから元データに合う投影系を見つけられず、その時は新しい行をspatial_ref_sysテーブルに追加するようです。最近はどうか分からないけど(記事には日付がなく、コメントから推測すると20092012年の間の状況らしい)。

When OGR guesses wrong or fails to guess
(...)
Sometimes OGR can't match the projection to one in your spatial_ref_sys table so creates a new entry in that table. In these cases you have to tell OGR what the output projection is. You do this with the -a_srs flag.

ということは、今回追加インポートしたデータに既存のSRIDがきちんと付いたのは、MySQLの機能というよりogr2ogrが正常に働いた結果っぽい。投入先DBspatial_ref_sysテーブルを見て、投入するデータの空間参照系を自動的に設定してくれるとは便利です。PostGIS付属のshp2pgsqlにはそういう機能がないので、いつも手動でSRIDを設定してました。今度、PostGISにもogr2ogrを試してみます。