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

余はなぜGIS機能に魅せられしか/今年の活動の整理

この日記は RDBMS GIS アドベントカレンダー2018の1日目です。


 この一年、 GIS 機能についてさまざまな経験をしたり学びを得たりしてきました。
この日記では一年の振り返りと、なぜ私がここまで GIS 機能に惹かれたのかについて紹介していきたいと思います。 直接の技術的な話はありませんが、データベースで扱うデータに対して、どのように興味関心を持って接しているか、という視点でお読みいただければ。

1 GIS機能とは。MySQLGIS 機能とは。

ここで言う GIS 機能とは、位置の情報を取り扱うための機能のことです。 MySQL ではバージョン8.0になって地球上の位置の情報を取り扱うしくみが大幅に整備されました。 具体的には、それまでのバージョンでは平面上の座標のみを取り扱うことができたものが、バージョン8.0になって初めて、MySQLは地球が丸いことを覚えたのです。緯度と経度、または基準として定めた点からの南北方向東西方向への距離という形で地球上の位置を取り扱います。
 MySQL では、実はあまり 「GIS」というキーワードは使わず、Spatial(空間の)という言葉を使用します。空間情報ですね。

2 私のこの一年

 地球上の位置を表す方法はいろいろありますが、ここでは緯度経度を例にして話をしますと、緯度経度それ自体は単なる二つの数字のセットです。無味乾燥な数字です。ですが、データベースにこれらの値を登録したりシステムでこれらの値を扱うような開発を行うとき、その数字がどういう意味を持っているのかを知っていたほうが、いつでも、より適切なイメージを持って値を取り扱うことができるようになります。


 そんな考えですから、MySQL でコマンドを叩くだけでなく、 緯度経度が表している数字をよりリアルに感じたいという流れになるのは、必然です。つまり、位置をあらわすということの「実態」をこの目で見ることにも重点を置いてきました。こう書くととても崇高な感じはしますが、率直に言えば、ただ見たかっただけです(笑)。
 また、 この1年でいただけた各地での発表の機会を使って、この1年はほとんど、GIS 機能について紹介をしてきました。データベースに格納されるデータは、有効に利用されてこそ価値が生まれるものですから、位置に関する情報が世の中にどのように活用されているのかを知るためにも、データベースの世界とは離れ、GIS の情報を取り扱うプロフェッショナル方達からも色々と教えていただく機会を多く得ました。そういう方たちの世界では、データの格納方法という視点ではなく、データをエンドユーザーにどのように見せたいのか、どんな切り口で見せたいのかなどの活用方法について、彼らそれぞれの「あたりまえ」に触れることができたのは、非常にわくわくする体験でした。


 この一年の、関連する私の活動を以下に整理しました。各地での発表資料については slideshare に上がっていますので、内容については、そちらを参照ください。
https://www.slideshare.net/sakaik/

●2017/11/02 水準原点を見に行ってしまう
●2017/12/26 日本経緯度原点を見に行く
●2018/02/10 浜松の一等三角点を見に行く
■2018/02/11 OSCHamanakoLT 「MySQLGIS機能がやってきた」
●2018/05/23 水準原点公開日に見に行く
●2018/07/06 札幌の基線南端北端に行く
■2018/07/07 OSC Hokkaido 「MySQLに本格GIS機能がやってきた」
■2018/07/23 日本MySQLユーザ会会(MyNA会) 「MySQLGIS機能とか超入門」
●2018/08/29 伊能忠敬記念館に行ってみる
■2018/08/31 ClubMySQL 「周辺知識から理解するMySQLGIS機能」
●2018/10/07 明石東経135度線を見に行く
■2018/10/28 OSCTokyo/Fall 「MySQL8.0の新機能"地理情報" を理解しよう入門~いまからはじめるGIS
■2018/11/04 FOSS4GOkayama 「MySQL 8.0で強化されたGIS機能のご紹介」
■2018/12/08(予定) OSCFukuoka 「MySQL 8.0 で強化されたGIS(地理情報)機能を使ってみよう」
(■は発表、●はリアルな「位置」関連視察:-))


3 なぜここまで GIS 機能に惹かれるのか

 かように私の興味を引き立てた GIS 機能ですが、100人のMySQLユーザーがいれば当然100人が興奮してこの機能に飛び付くと思っていました(やや誇張あり)。実際には、あれれ、意外とみんな、そこまで興味はなさそうと感じることもあり、なぜ自分がこんなにも位置情報を扱えることに心を惹かれているのかということについて考えてみました。


 ひとえに「RDBMSに興味がある」と言っても、大きくふたつに分けることができるようです。ひとつは RDBMSの仕組みそのものに興味がある場合。もうひとつが、RDBMSで扱うことができるデータに興味がある場合です。
 前者は、RDBMSが安定して運用されるためにやるべきこと、なるべく高速に動作させるために工夫すべき事などに関心があるのではないでしょうか。そのノウハウは、セミナーや書籍などのネタにもなりやすく、比較的目立ちやすいこともあって、「RDBMSを知るっていうのは、こういうことだ!」という印象が強くなる傾向があるかと感じます。実際にお仕事で RDBMSの運用をするというのは、こういうノウハウを蓄積していることでもあるので、現場感のある人にとって必然的な姿勢かと思います。
 一方、私はというと、特にこの数年はそういった運用の現場感が全然ない環境にいることもあって、運用に関わる話題は、聞くのは好きだしわくわくもするけれども、どことなく身近に感じられない、異世界の話題のように感じるときもあるのです。
 そんな私が今回気づいたのが、自分は「RDBMSが扱う "データ" に興味があるのだ」ということでした。これはこの数年の立ち位置のせいだけではなく、思い起こせば昔からそういう傾向があったような気がします。小売店で全国の支店の売り上げがSQLを叩くだけで手に取るように分かるとか、紙でファイリングしていた大量の資料を一元管理できることで今まで見えなかった情報相互の関係を分析しやすくなったとか、そういった「現実世界とつながったデータ」にわくわくしながら、RDBMSと付き合ってきました。10年程前に、元お茶の水大の増永先生にサインをいただいたときに「地球まるごとデータベース」というキャッチコピーを添えてくださったのですが、今まで私が触れてきたデータベースとは、まさに「地球まるごと(のごく一部)」だったわけです。

 この視点の違いに気づけば、当初の「なぜGISに惹かれるか」の答えは見えたようなものです。

 今までMySQLでは、文字、数字、日付時刻の情報を中心としたデータを取り扱ってきました。これは「地球まるごと」を格納するためには、致命的に不足している情報タイプがあったのです。そう、それが「位置」に関する情報です。大きく分類すれば位置でさえ「数字のセット」でしかありませんが、数量や重量、金額などをあらわしていた「数字」とはまったく異なるポテンシャルを持っているのが「位置」の情報なのです。
 単なる平面座標ではなく、球体(正確には回転楕円体)である地球上の位置を、気楽に扱えるこの仕組みこそ、今までのMySQLに欠けていたものでした。(他のRDBMSには、本体またはプラグインの形で実装されているものが多かったけど)バージョン 8.0 になり、MySQLでもこれらの位置の情報を扱える仲間入りを果たしたということが、私にとっては、MySQLの表現力が格段にレベルアップしたと言ってよいほどに感動的な出来事だったというわけです。
 だからこそ、MySQLでの位置の情報の操作方法といった基本的な事を押さえた後は、この「Spatial型」に入れるべき現実世界はどうなっているのか、という点に興味が広がるわけですし、その過程で知った「おもしろそうな場所」に、適度に気楽に行けるのであれば行って自分の目で見てみたいと思い行動してきた、この1年でした。


 世の中の様々な場所をあらわすために「緯度、経度」という連続的な数字のセットがあり、それら数字を MySQL などに格納し、取り扱うことができるようになった。この、現実世界との連動こそが、データベースの大きな魅力であることを再確認できた、この1年間でした。

f:id:sakaik:20180523135120j:plain



追記(2018/12/02):とみたさんより、(1)仕組みへの興味、(2)データへの興味、に続く第三の興味関心の軸を提示頂いたので、紹介します:-)

MySQL Innovation Day

Oracle MySQL Innovation Day 2018 秋 に参加してきました。平日の午後から、夕食休憩を挟んで夜の早めの時間くらいまで、という変則的開催。
参加してみるとなるほど、明るい時間には比較的まじめにしっかりとした話を聞いて、夜枠はどちらかというとコミュニティに寄せた感じなのだな、と納得。当たり前のように両者が融け合う、名構成だったと思います。企画者GJ!

ほんとね、もっと英語聞けるようになりたいって思いますよ、こういう会に出ると。
たどたどしいながらも、自分がしゃべる側は言い換えながら頑張れるんだけど、返答を聞き取れないのが辛すぎて。

夜枠の、海外ゲストへの質問コーナー。予め(と言っても当日)Webサイト上で募った大量の質問に対して、MySQLの開発トップであるUlinさんをはじめとした海外ゲストがテンポ良く答えていく運びで、ライブならではの迫力がありました。「次のバージョンは 8.1 なのか 9なのか」という質問には「決まってない」とシンプルに答えてくれたけど、ここは「ナインはないん。」と答えて欲しかった(無理)。

夜枠にてLTをやらせていただきました。この1年間、MySQLGIS機能を追いかけてきた報告と、MySQLGIS機能をこれから使おうという方のための簡単な情報を紹介しました。

www.slideshare.net

 いや、、「MySQLGIS機能を」追っていたかというと、実はちょっと自信ないのですけど、MySQLGIS機能に登録するための数字(緯度経度)の意味という視点で追いかけ回していた感じですかね。


 やはり海外ゲストが来てくれるカンファレンスというのはユーザ会ベースではなかなか難しいし、来てくれるとやっぱり内容にも一層迫力があるしと、とても素敵なので、来年もまた何度か開催してもらいたいと思います。

 ありがとうございました。
f:id:sakaik:20181121100944j:plain