OSC2019-Hamanako参画

オープンソース浜名湖(OSC2019-Hamanako)に参画してきました。


f:id:sakaik:20190210112037j:plain

www.ospn.jp

 いつもどおり、日本MySQLユーザ会(MyNA)として、セミナーを1枠もらってのお話と、ブースの出展とで。
申し込みが遅かったので、セミナー枠は埋まっているかな、と思っていたところ、朝イチの枠が空いているとのことで僭越ながらオープニングの枠を務めさせて頂きました。

 OSC浜名湖セミナーは、ワントラックで、来場者全員が(同部屋に併設のブースを見ることもできますが)座ったままですべてのセミナーを聞けるスタイルです。なので、まぁMySQLに特に興味があるわけじゃない人も多いだろうな、と、「データベースってなに?」という層を今回はターゲットとしてみました。 まぁレベル設定はなかなか難しいですね。。分からなくてもいいから最先端の話を聞いてみたいという人も少なくないようで、まだまだ私にとっても、開催スタイルによる話題やレベル感の選定は悩みだらけです。

 浜松は、測量で使用する「三角点」という面からは、日本で2番目の基線が設定された場所でもあり、LTなどではそれをネタに2年連続、お話をさせていただきました。何人かの方には面白がっていただいたり、実際に三角点に興味を持って頂いたり、ささやかな広がりを感じることができました。

 お会いしたかった方とたくさんお話できたり、音楽関係のお話をいっぱい教えてもらえたり、充実のOSC2019-Hamanakoでした。
ランチは、いつもどおり、うなぎ。

f:id:sakaik:20190210124852j:plain
写真はうなぎ

MySQLのSpatialでのPOLYGONの同一性

boiledorange73さんのこの記事を見て、むくむくと疑問が湧き上がったわけですよ。本題とは全然関係ないところで、単に「右回り左回り」というキーワードだけに反応して、妄想全開モードになっただけなのですが。
qiita.com

MySQLは 記述方法の違うポリゴンを同一と見なしてくれるのか

 点A、点B、点C、点D からなるポリゴンって、A-B-C-D-A とも、B-C-D-A-B とも、B-A-D-C-B ともあらわすことができますよね。感覚的にはこれらはすべて同じと見なして欲しいな、と思うのですが、実際にはどうなのだろう。というのが今回の疑問です。
 以降、だらだらと例示が続くので結論を先に書いちゃうと、ちゃんと同じと見なしてくれます。

同一性の確認方法

 MySQLには、ST_Equals() という同一性判定の関数があります。
POINT を例に見ると、以下のように、同一の点であれば「1」が、異なる点であれば「0」が返ってきます。

mysql> SELECT ST_Equals( ST_GeomFromText('POINT(1 1)'), 
    ->                   ST_GeomFromText('POINT(1 1)') ) res;
+------+
| res  |
+------+
|    1 |
+------+

mysql> SELECT ST_Equals( ST_GeomFromText('POINT(1 1)'), 
    ->                   ST_GeomFromText('POINT(1 2)') ) res;
+------+
| res  |
+------+
|    0 |
+------+

LINESTRINGの場合は

 同様に、LINESTRING の場合を見てみます。点Aから点BへのLINESTRINGは、A-B とも B-A とも表せますが、これらを同じ物と見なしてほしな、という実験です。

mysql> SELECT ST_Equals( ST_GeomFromText('LINESTRING(1 1, 1 2)'), 
    ->                   ST_GeomFromText('LINESTRING(1 1, 1 2)') ) res;
+------+
| res  |
+------+
|    1 |
+------+

mysql> SELECT ST_Equals( ST_GeomFromText('LINESTRING(1 1, 1 2)'), 
    ->                   ST_GeomFromText('LINESTRING(1 2, 1 1)') ) res;
+------+
| res  |
+------+
|    1 |
+------+

 はい。「1」が返ってきたので、MySQLはこれら2つの線を同じ物と認めてくれたことがわかりました。
なんかユルユルに、なんでも「1」を返してるんじゃないの?という疑問を消し去るために、明らかに違う2つの線で試してみます。

mysql> SELECT ST_Equals( ST_GeomFromText('LINESTRING(1 1, 1 2)'), 
    ->                   ST_GeomFromText('LINESTRING(1 1, 2 1)') ) res;
+------+
| res  |
+------+
|    0 |
+------+

 ええ、ちゃんと「違う線である」と判断してくれました。

いよいよ本丸のポリゴン

 ちょっとわかりにくいのですが、A(1,1)、B(1,2)、C(2,2)、D(2,1) としたときに、
最初のは、A-B-C-D-A どうしを比べたもの。
2番目のは、A-B-C-D-A と、B-C-D-A-B を比べたもの(記述上の起点が異なる)。
3番目のは、A-B-C-D-A と、D-C-B-A-D を比べたもの(記述上の起点が異なり更に逆回転)。
いずれも「1」(同一)と判定されました。

mysql> SELECT ST_Equals( ST_GeomFromText('POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'), 
    ->                   ST_GeomFromText('POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))') ) res;
+------+
| res  |
+------+
|    1 |
+------+

mysql> SELECT ST_Equals( ST_GeomFromText('POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'), 
    ->                   ST_GeomFromText('POLYGON((1 2, 2 2, 2 1, 1 1, 1 2))') ) res;
+------+
| res  |
+------+
|    1 |
+------+

mysql> SELECT ST_Equals( ST_GeomFromText('POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'), 
    ->                   ST_GeomFromText('POLYGON((2 1, 2 2, 1 2, 1 1, 2 1))') ) res;
+------+
| res  |
+------+
|    1 |
+------+

まとめ

 非常にシンプルなサンプルですが、線の順序やポリゴンの回転方向などの記述方法の如何に依らず、MySQL の ST_Equals() は正しくその形の同一性を見て判断してくれることがわかりました。めでたしめでたし。

JGD2011からのST_Transform()、JGD2011へのST_Transform()

この日記は RDBMS-GIS Advent Calendar20日目の枠です。


 一昨日に書いた MySQL 8.0.13 の ST_Transform()を試す - sakaikの日々雑感~(T)編 に対する返歌を 有意識者の boiledorange73 さんにいただいた(JGD2011の座標系にtowgs84が無いとかそもそもtowgs84って何やねん - Qiita)ので、それに対する恋文返しです。実際には、boiledorange73 さんへのお返事になっているというよりも、boiledorange73 さんにいただいた恋文をこっそりアレンジして他の人に送りつけているような感じと言ったほうが近いかもしれません。

TOWGS84 の 7つの数字の意味

 前の日記で、

(7個ある数字の意味については今後調べていきたいと思います)

 と書きましたが、 boiledorange73 さんが解説してくださいました。ありがとうございます。

 towgs84 = [t_x, t_y, t_z, d, r_x, r_y, r_z]

 で、tが各方向への並行移動量、d が縮尺に関する値、rが回転に関する値であるということです。

SRID:4301(Tokyo)で 、 TOWGS84[-147,506,687,0,0,0,0] と定義されていたのは、最初の3つのみに値が指定されていて残りの4つはゼロであることから、回転や縮尺の変更は伴わずに単純な並行移動のみで変換ができるということをあらわしています。

x,y,z 方向への平行移動の値は、こんなものか?の確認

 この定義によると、x, y, z 方向への並行移動はそれぞれ、-147, 506, 687 とされています。同じ緯度経度の数字とした場合、その指し示す位置は、Tokyo測地系からJGD2000 に向かっておおよそ東南東の方向に約600mほどズレることは、既に知識として持っているので*1、感覚的にこれに合致するかを確認することにします。
 x, y, z と示されていますが、x=-147, y=687 であることから、xが南北方向(北方向をプラス)、yが東西方向(東方向をプラス) に関わる値であると推測できます。
 では、z の 687 というのはどうでしょうか。これも、Tokyo測地系で使用しているベッセル楕円体と、JGD2000が採用しているGRS80 とを比べることで分かります。両者の極半径の差は 674m、赤道半径の差は 740m ですので、まぁなんとなく、論外な値でもなさそうだなと見えます。それっぽいので、終了としたいと思います。(緯度経度の話の中には z軸は出てこない)

行列はキライ

 私は行列は嫌いです。ラーメンは大好きですが、行列してまで食べません。
ということで参照先の紹介だけ。
boiledorange73さんの式の中で出てきた 回転の計算式の R_x, R_y, R_z はそれぞれ、x, y, z方向に関係する 3x3 の行列です。これについては、boiledorange73さんも紹介していた書籍
世界測地系と座標変換
の第2章に詳しく出ているので、興味のある方は参考になさってください。この本、非常に軽妙に、知りたい情報を書いてくれているのですが、私のようなこの分野の素人にとっては、もう少し丁寧に説明して欲しいところもあるというのが率直な感想ですが、3ヶ月前に意味もわからなかった部分が後に少し理解が進んでいることが把握できるなど、自分の成長を感じられる部分もあるのが面白いです。

拡大縮小のパラメタは?

 boiledorange73さんの示してくれた変換式をよく見ると、拡大縮小のパラメタ D を用いる項が目に付きます。「倍率」と示されていますが、倍率であるなら、変化なしの場合に 1 であるべきで、今回のような 0 という設定値には違和感があります。調べてみました。
 正確には、このパラメタ D は、「スケールファクタ(スケール補正量)」と言って、補正なしならゼロ、補正ありなら プラスいくつ、またはマイナスいくつ という値を指定するようです。なお、値の単位は  10^{-8} です。
 

結局 JGD2011 からの/への 座標変換はどうしたらいいの

 JGD2011 と JGD2000 は、地理座標系に於いては同一(=7つの変換パラメタがすべてゼロ)と考えて良いので、boiledorange73さんのエントリでも最後にちらっと書かれていたように、JGD2000を経由して(JGD2011なんだけどJGD2000の値だと見なして)変換処理を行っても問題なさそうです。

一昨日の私のエントリのデータを使って試してみます。

mysql> select ST_AsText(g), ST_SRID(g), ST_AsText( ST_Transform(g, 4301) ) FROM g1  WHERE ST_SRID(g)=6668;
ERROR 3743 (22S00): Transformation from SRID 6668 is not supported. The spatial reference system has no TOWGS84 clause.

 この行のgの値は (towgs84がない)SRID:6668(JGD2011)であるためにエラーになったので、 (変換ではなくそのままの値でSRIDだけ変更する関数である)ST_SRID() を g に噛ますことで、JGD2000ということにして、変換を実施できます。

mysql> select ST_AsText(g), ST_SRID(g), ST_AsText( ST_Transform( ST_SRID(g, 4612) , 4301) ) FROM g1  WHERE ST_SRID(g)=6668;
+---------------+------------+----------------------------------------------------+
| ST_AsText(g)  | ST_SRID(g) | ST_AsText( ST_Transform( ST_SRID(g,4612) , 4301) ) |
+---------------+------------+----------------------------------------------------+
| POINT(35 135) |       6668 | POINT(34.996751668769726 135.00278101474854)       |
+---------------+------------+----------------------------------------------------+


 逆に、Tokyo測地系で与えられた緯度経度を、JGD2011 へと変換したい場合の例は、以下。そのまま 4301(Tokyo)を 6668(JGD2011)へ変換するとエラーになるので、一旦 4612(JGD2000)へと変換し、結果値を 6668(JGD2011)と見なす指示を行うことで、TokyoからJGD2011への変換を実現可能です。

mysql> select ST_AsText(g), ST_SRID(g), ST_AsText( ST_Transform(g, 6668) ) FROM g1  WHERE ST_SRID(g) = 4301;
ERROR 3744 (22S00): Transformation to SRID 6668 is not supported. The spatial reference system has no TOWGS84 clause.

mysql> select ST_AsText(g), ST_SRID(g), ST_AsText(ST_SRID( ST_Transform(g, 4612), 6668) ) FROM g1  WHERE ST_SRID(g) = 4301;
+---------------+------------+---------------------------------------------------+
| ST_AsText(g)  | ST_SRID(g) | ST_AsText(ST_SRID( ST_Transform(g, 4612), 6668) ) |
+---------------+------------+---------------------------------------------------+
| POINT(35 135) |       4301 | POINT(35.003247866817325 134.99721914450956)      |
+---------------+------------+---------------------------------------------------+

 

ST_SRID() 関数って?

 ST_SRID() の2種類の使い方を、何の説明のなく出したので、混乱した人もいるかもしれません。
ST_SRID() 関数は、引数がひとつ(GEOMETRY型)の場合には、それがあらわされているSRIDの数字を返し、第2引数に数字(SRID)を与えた時には、そのSRIDへと変換した GEOMETRY を返す、という挙動をします。
 単に情報を取得したい場合と、変換したい場合とで同じ関数を使うので、慣れるまではちょっとややこしいと私は感じました。

MySQL :: MySQL 8.0 Reference Manual :: 12.16.7.1 General Geometry Property Functions

ということで

 アドヴェントカレンダー用エントリにする程でもなかったかもしれませんが、本日が終わりそうなタイミング(というかこれを書いているまさに今、本日が終わって新しい本日になってしまった)で20日目の枠が空いたままだったので、アドヴェント参加作品(笑)とさせていただきました。
 
f:id:sakaik:20181220121034j:plain
写真は地球。奥のほうにあるのが月。右奥は、日本近郊を切り出した曲面。日本列島が球面の上に乗っていることを体感できます@地図と測量の科学館@つくば

*1:追記:600mではなくて400mでした。指摘くださった ozo360さん、ありがとうございます。600mも差が出る理由はモデルとしている楕円体の違い(ベッセル楕円体とGRS80)で変換するからかなと想像しましたが、今の私にはまだ理解できず、そのうち出直してきます

MySQL 8.0.13 の ST_Transform()を試す

この日記は RDBMS-GIS Advent Calendar の 18日目の枠です。

MySQLの残念な ST_Transform()

 ST_Transform() という関数があります。測地系を変換できる機能です。Tokyo測地系(別名日本測地系)で記述されている緯度経度を、JGD2000/2011 に変換したり、あるいは地理座標系の JGD2011の緯度経度を JGD2011の平面直角座標系の9系の座標*1に変換できたりするもの、だと思います。
 思います、と書いたのは、MySQLでは後者について、バージョン 8.0.13 の時点ではまだ対応してないからです。そもそも、この ST_Transform()関数、8.0.13が出る前から MySQLのリファレンスマニュアルには記載されていて、でも実際には実装すらされていなかったので私は「蕎麦屋の出前詐欺*2」と呼んでいたものです。このたび限定的な機能ながら、 8.0.13 で実装されましたが、地理座標系どうしの変換の一部にのみ対応しているのが、現在の状況です。

 本エントリでは、MySQL 8.0.13 で、ST_Transform() 関数を試してみた結果を紹介します。

データの用意

 様々な地理座標系であらわされた「北緯35度、東経135度」のデータを登録しておきます。

CREATE TABLE g1 (g GEOMETRY);
INSERT INTO g1 VALUES ( ST_GeomFromText('POINT(35 135)', 6668));
INSERT INTO g1 VALUES ( ST_GeomFromText('POINT(35 135)', 4612));
INSERT INTO g1 VALUES ( ST_GeomFromText('POINT(35 135)', 4326));
INSERT INTO g1 VALUES ( ST_GeomFromText('POINT(35 135)', 4301));

mysql> SELECT ST_AsText(g), ST_SRID(g) FROM g1;
+---------------+------------+
| ST_AsText(g)  | ST_SRID(g) |
+---------------+------------+
| POINT(35 135) |       6668 | ← JGD2011
| POINT(35 135) |       4612 | ← JGD2000
| POINT(35 135) |       4326 | ← WGS84
| POINT(35 135) |       4301 | ← Tokyo
+---------------+------------+

 いうまでもないことですが、これらの「35度135度」の点は、兵庫県内の、それぞれ異なる場所を指し示しています(実際には Tokyo 測地系のみが大きく離れていて、あとの3つはほぼ同じ場所を指している)

とりあえず実行してみる

 登録した4件のデータに対して、ST_Transform() 関数を噛ませてみましょう。
まず、SRID:6668(JGD2011)への変換を試みます。

mysql> SELECT ST_AsText(  ST_Transform(g, 6668)  ), ST_SRID(g) FROM g1;
ERROR 3744 (22S00): Transformation to SRID 6668 is not supported. The spatial reference system has no TOWGS84 clause.

 あれれ。「6668への変換はサポートされてないよ」だそうです。
うむ。では、SRID:4326(WGS84)への変換を試みてみましょう。

mysql> SELECT ST_AsText(  ST_Transform(g, 4326)  ), ST_SRID(g) FROM g1;
ERROR 3743 (22S00): Transformation from SRID 6668 is not supported. The spatial reference system has no TOWGS84 clause.

 少しエラーコードとエラーメッセージの内容が変わりました。「6668からの変換はサポートしてないよ」だそうです。

ということで、6668はダメらしいと分かったので、6668以外のものを 4326への変換を試みることにします。残念な6668。

mysql> SELECT ST_AsText(  ST_Transform(g, 4326)  ), ST_SRID(g) org_srid FROM g1 WHERE ST_SRID(g)<>6668;
+---------------------------------------------+----------+
| ST_AsText( ST_Transform(g, 4326) )          | org_srid |
+---------------------------------------------+----------+
| POINT(35 135)                               |     4612 |
| POINT(35 135)                               |     4326 |
| POINT(35.00324786593045 134.99721914450956) |     4301 |
+---------------------------------------------+----------+

 無事実行できて、結果が返ってきました。JGD2000からWGS84への変換は値に変化がありませんが、TokyoからWGS84への変換は、何やら変化があった感じです。この結果は、『Tokyo測地系が「東経135度」と思っている場所は、WGS84に言わせると「東経134.997度」』ということを表しています。(経度だけに着目して語ると)Tokyo測地系の東経135度は明石市役所付近を通り、WGS84やJGD20xxの135度はその東側約400m(天文台の130mくらい西)を通っているという知識を適用すると、これは感覚的には納得できる結果です。

 特に意味はないけど、調子に乗って SRID:4269 にも変換してみちゃう。

mysql> SELECT ST_AsText(  ST_Transform(g, 4269)  ), ST_SRID(g) org_srid FROM g1 WHERE ST_SRID(g)<>6668;
+---------------------------------------------+----------+
| ST_AsText( ST_Transform(g, 4269) )          | org_srid |
+---------------------------------------------+----------+
| POINT(35.00000738369947 135.00001549175067) |     4612 |
| POINT(35.00000738458632 135.00001549175067) |     4326 |
| POINT(35.00325525051159 134.99723463674064) |     4301 |
+---------------------------------------------+----------+

 SRID:4269 というのは、NAD83 です。

mysql> SELECT SRS_NAME, SRS_ID FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID=4269;
+----------+--------+
| SRS_NAME | SRS_ID |
+----------+--------+
| NAD83    |   4269 |
+----------+--------+

なぜ JGD2011 は変換できないのか

 我々がよく使うことになりそうな JGD2011 が ST_Transform() に対応していないというのは、どういうことでしょうか。先ほどのエラーメッセージをよく見ると、「The spatial reference system has no TOWGS84 clause.」と言っています。どうやら、JGD2011には "TOWGS84" 句が記述されていないようです。
 JGD2011の definition を見てみましょう*3(見やすいように整形済)

GEOGCS[
  "JGD2011",
   DATUM["Japanese Geodetic Datum 2011",
         SPHEROID["GRS 1980", 
                  6378137,
                  298.257222101,
                  AUTHORITY["EPSG","7019"]],
         AUTHORITY["EPSG","1128"]],
   PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
   UNIT["degree",0.017453292519943278, AUTHORITY["EPSG","9122"]],
   AXIS["Lat",NORTH],
   AXIS["Lon",EAST],
   AUTHORITY["EPSG","6668"]]

 確かに、TOWGS84 なんて記述はない。。
JGD2000を見てみると、

GEOGCS[
  "JGD2000",
  DATUM["Japanese Geodetic Datum 2000",
        SPHEROID["GRS 1980",
                 6378137,
                 298.257222101,
                 AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6612"]],
  PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
  UNIT["degree",0.017453292519943278, AUTHORITY["EPSG","9122"]],
  AXIS["Lat",NORTH],
  AXIS["Lon",EAST],
  AUTHORITY["EPSG","4612"]]

 ある!!ある!!! TOWGS84 が!!!
 内容はオールゼロですが、これが、先ほどの WGS84 への変換実験で、緯度経度に変化がなかった理由ですね。

ちなみに、SRID:4301(Tokyo)では、

TOWGS84[-147,506,687,0,0,0,0]

となっており、TokyoからWGS84への変換では、結構変化しそうな感じが伝わってきます(7個ある数字の意味については今後調べていきたいと思います)。

なぜ JGD2011には TOWGS84 の記述がないのか

 知りません。わかりません。
ST_SPATIAL_REFERENCE_SYSTEMS の値が、どこか別のところで定められた定義をそのまま持ってきているのであれば、そのおおもとがどうなっているかを辿っていく必要がありそうですし、MySQL独自に定義しているものであれば、JGD2011に TOWGS84を(オールゼロで)記述してもらうようリクエストを出せばよさそうです。
 有識者からの情報に期待したいと思います :-)

TOWGS84 が記述されている座標系

mysql> SELECT SRS_NAME, SRS_ID FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS WHERE definition LIKE 'GEOGCS%' AND definition LIKE '%TOWGS84%' ORDER BY SRS_NAME;
+-------------------------------+--------+
| SRS_NAME                      | SRS_ID |
+-------------------------------+--------+
| Abidjan 1987                  |   4143 |
| Accra                         |   4168 |
:
| Yoff                          |   4310 |
| Zanderij                      |   4311 |
+-------------------------------+--------+
323 rows in set (0.09 sec)

 地理座標系(GEOGCS)は、MySQL 8.0.13 では、479 個が定義されているので、 323/479 に TOWGS84 が記述されているということになります。

今後の期待

 JGD2011にも TO_WGS84 が記述されて、地理座標系どうしの変換仲間にいれてもらうことも勿論ですが、それ以上に 地理座標系と平面直角座標系との変換に期待したいところです。最近のMySQLのリリーススパンは結構安定してきて、その流れに従えば 次回は 2019年1月後半に MySQL 8.0.14 が出ます。ST_Transform() がどの程度進化するのか、どんなGIS関数が追加されるのか、楽しみです。機能が非常に限定された ST_Transform()関数。いま理解しておくと、MySQLの進化とともにあなたも成長します。たぶん。 いま始めれば、あなたも ST_Transform()関数のプロフェッショナル(笑)。ぜひお試しください。


f:id:sakaik:20181218000408p:plain
※写真は「さまざまな135度」

*1:ちなみに緯度経度ではなくメートルで表します

*2:「いまでました!」

*3:select definition FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID=4612; (または6668)で取得できます

オープンソースカンファレンス2018福岡(OSC2018-Fukuoka)参画

 12月8日に福岡で開催された OSC2018-Fukuoka に参加してきました。

www.ospn.jp

 今回も日本MySQLユーザ会として、ブース出展とセミナーの開催を行ってきました。
セミナーは、朝の2枠目(11時から)。事前申込みの人数をみて「まぁこんなものかな」と思っていたら、実際にはそれよりもたくさんの人が聞きに来てくれて、良い感じの規模でお話をさせていただきました。「MySQLGIS(Spatial)機能のイントロダクション」のお話です。一年間(本腰を入れてからは約半年)にわたって全国でお伝えしてきましたが、このレイヤの話は今回が最終回の予定。リクエストがあれば喜んでお話をしに行きますが、それなりに公開資料も蓄積されてきたし、いくつかのポイントさえ押さえれば比較的シンプルな話でもあるので、私からこのテーマを提案してお話するのは、今年いっぱいにしようかなと考えている次第。
 同じ資料を使ってあちこちでお話すればいいのに、毎回少しずつシナリオや強調ポイントを変えながらお話するので結構大変なのですが、今回はある意味、それらの集大成。私の思い入れの部分は前半封印して、とにかく「これだけ覚えたらいいです」をぎゅっと紹介しました。とは言え、根底にある「位置情報を扱うのは楽しい」を隠せるわけがないので、にじみ出る「楽しさ」を感じ取ってもらえたら一石二鳥かなと思います。

f:id:sakaik:20181208141852j:plain


 今後もしばらくはGIS機能を追いかけていくつもりですが、今年獲得した、基本的な扱い方と「緯度・経度のきほん」の知識をもとに、来年は、より、データの操作に近い部分で色々追いかけて行けたらと考えています。その中のひとつとしては、世間にあるオープンデータを利用して遊んでみたり、少し直角平面座標系上での扱いについて追ってみたりなどを予定しています。 どうしても押さえておきたかった主な「聖地」も一段落した感があるので、じっくりデータベースを触る年にしましょうかね。

 あと、今回嬉しかったのが、昨年「会場が自分の学校なので、ちょっと覗いてみました」と言っていた学生さんが、今回は別会場であるにも関わらず参加してくださったこと。こうやって、(OSC方面から見たら)興味を持って参加してくれる人が増えることと、(参加一人一人から見たときに)活動の幅が広がってくれることが生み出されていく場であるというのが、本当にOSCって素敵だなといつも感じる所以です。



 実は、はじめて福岡でOSCが開催されたのも 12月8日だったんですよね。2007年の。あれ以来、発表された日程が嵐の影響で急遽変更された一度を除いてずっとOSC福岡には参加してきましたが、ちょうどひとまわりした感もあるのと、色々とスケジュール等も厳しくなってきたのとで、一旦ここで区切りとして、来年の参加は「白紙」からのスタートにする見込みです。わざわざ宣言するものでもありませんが、「居て当たり前」と見られている存在になっている自覚はあるので、来年驚かれないように、一応軽く表明を致した次第。


 今回のOSC福岡でお話させてくださったみなさま、そして今年1年各地のOSCでセミナーを聞いてくださったり、おしゃべりさせていただいたりしたみなさま、どうもありがとうございました。

i_s.ST_S_R_Sに見る様々な地球

RDBMS-GISアドヴェントカレンダー 7日目です。

本エントリのタイトルの正式名は「INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS ビューに見る様々な地球」です。長いので省略しました。

 MySQLは 8.0 になって初めて「地球が丸い」という事を知りました。これはMySQL的にはどういうことかというと、内部に、地球の形(回転楕円体)のデータを持っているということです。

そもそも地球の形って?

 地球は地「球」というくらいだから球形なんでしょ?と言う人は、今の時代ほとんどいないと思いますが、じゃぁどういう形なの?と聞かれてちゃんと応えられる人もまた、それほど多くはないと思います。赤道方向にぷっくらとひしゃげている、というイメージくらいで捉えているのではないでしょうか。
 そもそも、地球はとってもデコボコです。そりゃ街の中を歩けば平らなところはないのだから、デコボコしてるのくらい知ってるよ、ですか? いえいえそういう話をしているのではありません。海抜ゼロメートルラインが、すでにでこぼこしているのです。それは地球上はそれぞれの場所ごとに重力が異なり(構成されている物質の違いなどにより密度が異なるから)、地球上における測量は常に「重力方向が、真下」というように重量そのものを拠り所としてきたからです。
 そこで、よりシンプルな形に「モデル化」する流れとなります。多くの場合、地球を回転楕円体として取り扱います。概ね赤道半径が6,400km で、 極方向の半径はそれよりもおよそ 298分の1だけ短い、そんなモデルです。
 歴史的経緯や、おそらく「決める人の立場」のために、様々な「地球のモデル」が作られてきました。本エントリでは、MySQLの定義における、これらの「いろいろな地球」を紹介していきたいと思います。

MySQLが知っている「地球」の形

 MySQLの知っている地球について、MySQLの脳内を覗いてみましょう。大丈夫。ソースコードじゃなくて、データとして定義されています。 INFROMATION_SCHEMA の ST_SPATIAL_REFERENCE_SYSTEMS ビューです。
 ここには、地理座標系と呼ばれる、地球を回転楕円体と見なした様々なモデルが 479種類、そのそれぞれに、平面の地図に変換して落として表現するためのモデル4628種類が登録されているのです。

mysql >use information_schema     
mysql> SELECT SUBSTR(definition, 1, 6) g, COUNT(*)  FROM ST_SPATIAL_REFERENCE_SYSTEMS GROUP BY g ORDER BY g;                     
+--------+----------+
| g      | COUNT(*) |
+--------+----------+
|        |        1 |
| GEOGCS |      479 |
| PROJCS |     4628 |
+--------+----------+
3 rows in set (0.02 sec)

 本エントリでは、地理座標系 GEOGCSに焦点を当てて見ていきます。

GEOGCS にはどのような事が記述されているのか

 ST_S_R_S から「様々な地球」の情報を読み解くために、まず、ここにはどのような事が記述されているのかを知っておくと良いでしょう。我々日本人がよく使うことになるであろう、"JGD2011"(6668) の定義を見てみます。definition列の値を整形すると、以下のようになります。

GEOGCS[
  "JGD2011",
  DATUM[
    "Japanese Geodetic Datum 2011",
    SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],
    AUTHORITY["EPSG","1128"]
  ],
  PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
  UNIT["degree",0.017453292519943278, AUTHORITY["EPSG","9122"]],
  AXIS["Lat",NORTH], 
  AXIS["Lon",EAST], 
  AUTHORITY["EPSG","6668"]
]

最初に 座標系の名前が記述された後、DATUM, PRIMEM, UNIT, AXIS 等の順に続きます。
JGD2011では、赤道半径 6378137 km 、極半径はそれよりも 1/298.257222101 だけ短い、と定義されていることがわかります。単位(UNIT)は「度(degree)」であり、1度は 0.017453292519943278ラジアンであることも読み取れます。(1/360 * 2PI)
 AXISは、出てきた順に、第1軸、第2軸、となるようです。

様々な地球:半径と扁平率

それこそ伊能忠敬も知りたかった「地球の大きさ」。その定義が、ここです。1800年台前半頃から、さまざまな地球の大きさが見積もられてきました。また、楕円のつぶれ度合いにつちては、中には扁平率=0(真球)のものもあったりして、なかなか興味深いです。
 JGD2011は、この中で "GRS 1980" という楕円体モデルを採用しています。


続きを読む

MyNA(日本MySQLユーザ会) 望年LT大会2018@赤坂 開催しました

 日本 MySQL ユーザ会(MyNA)の忘年会として、東京は赤坂のワインバーを貸切にしての来たる年に望みをつなぐ 望年LT大会を開催しました。

connpass.com

 率直な感想としては、とにかく無事に終わってほっとしている、という部分が強いのですが、それもこれも皆さんの協力あってこそと感謝しています。

  • 当日お店に寄って、おいしいチーズをいっぱい買ってきてくれました
  • 会場についてからソフトドリンクの調達のお買いものに行ってくれました
  • 受付のための諸準備をしてきてくれました(名簿の印刷、名札やペンの用意等)
  • 会のあいだじゅう、遅れてくる方を気をかけて、しっかりと受付と説明をしてくださいました
  • LT の用意をし、またはその場で用意して、LTで盛り上げてくれました
  • 突然のフリにも関わらず、快くLTのタイムキーパーを引き受けてくれました
  • 食べ物の増減にあわせて、テーブルの上を適宜きれいにするなど気をくばってくれました
  • ぽつりとしている人がいないよう、なんか自然と良い感じに会話を盛り上げてくれました
  • 開催まで、定員割れ(赤字ライン)で泣きそうな幹事を支え、宣伝、集客に協力してくれました
  • ちゃんとみんな来てくれました!

などなど、皆さんそれぞれのできる事で、たくさんの協力をいただきました。本当にありがとうございました。

 都内で何らかの会を開いた場合、ノーショウ率3割4割はあたりまえ!という経験を何度もしているので、こういう会を開くのは非常に怖かったのですが、今回は申し込んだもののお仕事やご家庭の都合で参加できなくなってしまった方は、ちゃんと事前にキャンセルの連絡をくださいましたし、そうでない方は、ちゃんと来てくれました。来たんですよ!意味わかんないんですが出席率100%ですよ!ノーノーショウ!受付用名簿に全部「○」がついているんですよ。鳥肌が立ちました。ありがとう。

 今回、試みとして「学生枠」として、安く参加できる枠を設定してみました。残念ながら今回は学生さんの参加はありませんでしたが、MyNAとして今後も「若い人歓迎。学生さん歓迎」のメッセージは出し続けていきたいと思います。全然リーチしていない感はあるので、データベースに興味のありそうな学生さんが近くにいるオトナの方は、もしよかったら何かの企画の際にも背中をおしてあげていただけたら幸いです。

 今回の反省点のひとつに「参加受付の締切を前日に設定してしまった」ということがありました。受付用名簿を用意する関係と、それまでに自分のスケジュールしっかり決めてね、決められるでしょ、という思いがあって設定したのですが、「参加は無理だと考えて申し込めなかったけど、当日、行けそうな状況になってきた」という方に対して優しくなかったです。反省。twitterで当日の参加希望を呟いて、yoku0825さんがそれに気づいてくれて、参加していただけたのは、この「反省点」の傷を少し軽減していただけたようで、気分的に助かりました。ありがとうございます。


 個人的な面では、とにかく幹事として場が良い感じになっているのを見てほっとして、満足しちゃって、実はあんまり「参加」してた感覚がなかったのです(笑)。初めて来てくださった方ともっとお話ししたかったし、超久々に会った方とももっとお話したかったのですが、なんかへろへろ幹事ですいません。
 極めつけは、せじまさんに「その話超聞きたい!」「壊すデモ!?見たい!見たい!」と超おねだりしたのに、せじまさんのLTの時に聞いていなかったという失礼を。。。すいませんすいませんすいません。こんどまた別の会のときにも聞かせてください!


 最後に重大な御礼です。
今回のイベント開催にあたり、SCSK(株)様より経済的なご支援をいただきました。今回の参加費の設定は、ほぼ会場費(ワイン呑み放題付き)の部分のみでして、あの豪華な食べ物を提供できたのは、SCSKさんのおかげです。どうもありがとうございました。
 SCSKさんは、MySQLがビジネスとして日本に入ってきた最初期の頃からMySQLのサポートをしていて、手前味噌ですが、インタビューして記事を書かせていただいたこともあります(もう12年も前になるのですね)

超・極める!MySQL

超・極める!MySQL


 参加してくれた皆さん、色々お手伝いをしてくださった皆さん、どうもありがとうございました!私もとっても楽しかったです!

参考情報:

今回利用したお店:
●ノムノ赤坂店(赤坂1号店と呼ぶときもあり)
 ワイン50種呑み放題で、ひとり 3,000円+税。食べ物飲み物持ち込み自由(食べ物の提供はお店では、なし)。 
akasaka.nomuno.tokyo

今回お料理をお願いしたお店:
●Tokyo Bistro SCOP
 ノムノの1階にあるお店です。ノムノの「持ち込み」という性質上、本当は自分で買いに行く(取りに行く)ところなのですが、今回は、ご厚意で3階まで何度も配達してくれました(SCOPの店員さんとノムノの店員さんとで)。とっても助かりました。ありがとうございます。
 Tokyo Bistro SCOP - 赤坂見附/ビストロ [食べログ]

写真

 今回、なんだかバタバタふわふわしていて、会が始まってからの写真を一切撮っていないことに気づきました。私にしては珍しい。開始前の扉の外の様子を貼っておきますw
f:id:sakaik:20181203175513j:plain