MySQL Technology cafe #6 でMySQLのGISの話をしてきました

 そんなわけで、12月5日に開催された Oracle Technology Cafe #6 にて、発表の機会をいただき、あんなことやこんなことを語ってきました。
 この2年間、色々なところでMySQLGISについてお話をしてきて、そろそろ「測地系というのが色々あるらしい」「緯度経度で表すらしい(地理座標系)」「内部バイナリと人間可読な記法の間で変換を明示する必要があるらしい」というあたりは浸透してきているかな、という感触を持っています。それほど難しいわけではないけれども、最初に考え方を理解するのに少しハードルがある部分なので、ここを乗り越えたらあとはみんなが盛り上げてくれるのを楽しく見守るようになれたらいいなぁと思っています。
 今回、これまでの総括的な意味合いも持ち、ゼロベースで構成を作り上げて発表をいたしました。今まで説明してこなかった最後の大ネタである投影座標系の説明も(それなりにたぶんしっかりと)することができて、「伝えることはすべて伝えたぞ!次はきみたちの番だ!」の気分です(笑)。
 発表資料はこちら。

www.slideshare.net

9系原点の場所を勘違い

 日本の平面直角座標系の9系(東京など関東付近)の原点位置を、セミナーの中で何度か「埼玉県の千葉県寄りのあたり」とお話をしましたが、これは誤りでした。自分の発表後にtwitterを見たら、指摘をいただいていました。千葉県民としては、これは不覚!


 1系から19系の各原点は36.0度とか、131.0度とか、129.5度のように切りの良い数字になるように設定されていることが多いのです。対象エリアの真ん中付近にあれば、物理的になにか設置するわけでもないので、ある程度自由に原点を決めることができるからです。ところが、この9系は北緯36度、東経139度50分というちょっと半端な場所が原点として定められています。これはどこかなーと目視で地図を確認した際、私、なぜか139度50分を 139.5度と勘違いして地図を見てしまったみたいなんですよね。
 ひとつ前の記事(http://sakaik.hateblo.jp/entry/20191202/mysql_gis_metre_per_degree)で調べたとおり、北緯35度付近では経度1度はおよそ91kmとなるので、139度50分(≒ 139.833度)と139.5度との差、0.333度 はおよそ30km。30km西側を見てしまったので埼玉県になってしまったのした。次のセミナーでも埼玉県と言い続けていた可能性も高く、ご指摘、感謝です!

「たのしかったです」

 小学生並みの感想ですが、今回本当に楽しかったです。オラクルさん主催の会なので、イベントの告知先も普段のユーザベースの勉強会とは異なるのか、いつもと少し客層の違うたくさんの人が来てくださいました。中にはGISにお詳しい方もいたり、逆にMySQL(をはじめとするRDBMS)でこんなデータを扱えるのかと感心してくださる方もいたり、とにかく「伝わった」感がビシバシ感じられるセミナーでした。楽しかった。
 理想では、もっとゆったりと、アルコール燃料を補給しながら進めたかったのですが、伝えたいことが多く、凄い勢いでまくしたててしまいました(笑)。まだ話し足りないw

GeoHashとかの解説資料

 私の過去の発表の中に、GeoHashや「標高」に関する説明があります。以下の資料が一番整理されているかなと思いますので、よかったらご覧ください。山﨑さんの発表の中で、GeoHash以外の位置の符号化手法について提案がありましたが、その中で「GeoHashは長方形なんですよ」と言っていた意味も、この資料でわかるかと思います(桁数が増えるごとに、タテ・ヨコに交互に長方形になる)

www.slideshare.net

GeoHashは SRID:4326にのみ対応

 山﨑さんの発表のなかで、ちらっと「WGS84にだけ対応しています」という話が出てきました。いくつかの関数でそうだった気がしますが、話題の(?) GeoHashもこれに該当します。少し解説してみますね。

 実験用のテーブルを作ってデータを投入、内容を確認します。

mysql> CREATE TABLE g4 (id INTEGER, g GEOMETRY SRID 6668);                                                                       
mysql> INSERT INTO g4 VALUES (1, ST_GeomFromText('POINT(35.678 136.984)', 6668));
mysql> INSERT INTO g4 VALUES (2, ST_GeomFromText('POINT(36.876 137.011)', 6668));

 内容を確認する際、GEOMETRY系の型はバイナリで格納されているため、テキスト(WKT)に変換する必要があります。ついでに、この位置情報がどの測地系(SRID)で格納されているかも確認してみましょう。ST_SRID()関数で見ることができます。

mysql> SELECT id, ST_AsText(g), ST_SRID(g) FROM g4;
+------+-----------------------+------------+
| id   | ST_AsText(g)          | ST_SRID(g) |
+------+-----------------------+------------+
|    1 | POINT(35.678 136.984) |       6668 |
|    2 | POINT(36.876 137.011) |       6668 |
+------+-----------------------+------------+

 投入したとおりの内容が得られますね(あたりまえ)。
では、もうひとつ取得カラムを追加して、GeoHashを得てみましょうか。ST_GeoHash() という関数があります。第1引数に GEOMETRY、第2引数に得たいハッシュの桁数を指定します。

mysql> SELECT id, ST_AsText(g), ST_SRID(g), ST_GeoHash(g, 6) FROM g4;
ERROR 3682 (22S00): Function st_geohash is only defined for SRID 0 and SRID 4326.

 
 おやおや。 st_geohash は SRID 0と4326 にだけ対応しているそうです。
丁寧に処理をしたければ、今回の JGD2011(6668) の緯度経度を、WGS84(4326)に変換してから ST_GeoHash()に与えるべきですが、幸いにも JGD2011と WGS84はほぼ一致します(数センチくらいの差、だったかな)。なので今回は、(本当は)JGD2011で表した緯度経度なのですが、強引にそのままエイヤとWGS84の緯度経度であるかのように読み替えてしまいましょう。先ほど使った ST_SRID() は、緯度経度の数字は変更せずに測地系だけを読み替える機能も持っています(互いの測地系によっては全然違う場所を指してしまうことになります。たとえば Tokyo 測地系で表された緯度経度をそのままWGS84として読むと、数百メートルずれた場所を指すことになります)。

 ST_SRIDの第2引数に WGS84(4326)を与えて変換し、ST_GeoHash() に喰わせた実行結果が、以下になります。

mysql> SELECT id, ST_AsText(g), ST_SRID(g), ST_GeoHash(ST_SRID(g, 4326), 6) FROM g4;
+------+-----------------------+------------+---------------------------------+
| id   | ST_AsText(g)          | ST_SRID(g) | ST_GeoHash(ST_SRID(g, 4326), 6) |
+------+-----------------------+------------+---------------------------------+
|    1 | POINT(35.678 136.984) |       6668 | xn36vn                          |
|    2 | POINT(36.876 137.011) |       6668 | xn93vc                          |
+------+-----------------------+------------+---------------------------------+

 めでたく GeoHash 値が得られました。
 

ラクルさんのMySQLイベントで発表しよう!

 今回オラクルさんのMySQLイベントに登壇したごほうびに、MySQLのイルカ(sakila)のぬいぐるみをいただきました。大きくて手触り良く、絶対これは良い品! さっそく我が家の先住イルたちに熱烈な歓迎を受けていました。

 

f:id:sakaik:20191207110709j:plain
我が家のイルカたちによる歓迎式典の様子

 オラクルの(いくつかの?)MySQLイベントでは、発表をした人にプレゼントしてくれるらしいので、イルカが欲しい人も、そうでない人も、「発表してみたいなー」という意思表示をしてみると良いかと思います。
 併せて、MySQLユーザ会もときどきセミナー形式のイベントや交流会形式のイベントなどを開催していまして、ユーザ会としても特に「若手」「初心者」「登壇未経験者」に発表の機会を持ってもらいたいと考えています。ちょっと不器用なユーザ会ですので、募集のアピールがうまく伝わらないこともあるかと思いますが、かように熱烈歓迎しておりますので、twitterハッシュタグ #mysql_jp などをウォッチしながら、チャンスだ!と思ったらぜひ手をあげてみていただけたらと思います。

f:id:sakaik:20191207110958j:plain
sakila

参考情報

 この日記は、RDBMS-GIS(MySQL,PostgreSQLなど) Advent Calendar 2019 の5日目の記事として投稿しました。
RDBMS-GIS(MySQL,PostgreSQLなど) Advent Calendar 2019 - Qiitaqiita.com

 今回のイベントのリンクはこちら(各資料へのリンクそしてtwitterまとめへのリンクなども貼られています)
oracle-code-tokyo-dev.connpass.com