MySQLはLat-Lon記述順にST_SPATIAL_REFERENCE_SYSTEMSの定義を参照しているのか？

mysql gis

MySQLでは、より正確に書くと、我々がよく使う JGD2011やWGS84を使う際には、緯度(Lat)と経度(Lon)を表す際 (Lat Lon)の順序で記述します。これは PostGISなど他のGISツールでよく使われている記述順序と逆のものです。この挙動は「ST_SPATIAL_REFERENCE_SYSTEMS上にある JGD2011の定義情報の中で Lat-Lon の順序で示されているからだ」と私は理解し、そのように語ってもきました。
　しかし考えてみたら、本当にST_SRSを参照しているのか。実は決め打ちで (Lat-Lon)なのではないか、というウラを取ったことがなかったので、このたび、動作を確認してみました。 MySQL 8.1.0を使用しています。

SRS:6668の定義の確認

INFORMATION_SCHEMA内でST_SPATIAL_REFERENCE_SYSTEMSテーブルの内容を確認します。SRS_IDが 6668(JGD2011)の定義は以下のようになっています。なおこの定義は、先日の当ブログの記事「MySQLのJGD2011での座標系変換/換算にトライ」にてTOWGS84に対応済みのものとなっています（デフォルトの情報とは異なっているのでご注意ください）。

mysql> select * FROM st_spatial_reference_systems where srs_id=6668;
+----------+--------+--------------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
| SRS_NAME | SRS_ID | ORGANIZATION | ORGANIZATION_COORDSYS_ID | DEFINITION                                                                                                                                                                                                                                                                                                                                          | DESCRIPTION |
+----------+--------+--------------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
| JGD2011  |   6668 | EPSG         |                     6668 | GEOGCS["JGD2011",DATUM["Japanese Geodetic Datum 2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],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"]] | NULL        |
+----------+--------+--------------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+

AXIS["Lat",NORTH],AXIS["Lon",EAST],　の順で記述されていますね。

SRS:4326から6668への変換

　WGS84からJGD2011への変換を試みましょう。
ここへは掲載しませんが、SRS:4326(WGS84)も(Lat-Lon)なので、値は変化しないと予測されます。

mysql> SELECT ST_AsText( ST_Transform( ST_GeomFromText('POINT(35 135)',4326), 6668 )) g;
+---------------+
| g             |
+---------------+
| POINT(35 135) |
+---------------+

　ちょっと分かりにくいですが上のクエリは、

  • SRS4326 (WGS84)で、POINT(35 135)を作成し、
  • それを ST_Transform で 6668 (JGD2011) に変換し、
  • ST_AsTextで可読化している

というクエリです。

WGS84で与えられた (35 135) が、JGD2011での (35 135)へと無事変換されていることが確認できました。

Lon-Lat順で定義されたSRSへと変換したら？

　いま私たちは「実際には存在しない測地系を作成する」ワザを持っています（先日のエントリ）。
ここで、SRS:6668をコピーしてLat/Lonの順序だけを入れ替えた SRS:16668を作成して確認することにしましょう！

mysql> CREATE OR REPLACE SPATIAL REFERENCE SYSTEM 16668
    -> NAME 'JGD2011LonLat'
    -> ORGANIZATION 'EPSG' IDENTIFIED BY 16668
    -> DEFINITION 'GEOGCS["JGD2011",DATUM["Japanese Geodetic Datum 2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","1128"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943278,AUTHORITY["EPSG","9122"]],AXIS["Lon",EAST],AXIS["Lat",NORTH],AUTHORITY["EPSG","16668"]]';
Query OK, 0 rows affected, 1 warning (0.01 sec)

　名称や数字など細々いじっていますが、ポイントは AXIS["Lon",EAST],AXIS["Lat",NORTH] 順の定義にしたことです。
warningが出ていますが、指定したIDに関するものなのでここでは無視します。

mysql> show warnings;
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                                                                          |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Warning | 3715 | The SRID range [0, 32767] has been reserved for system use. SRSs in this range may be added, modified or removed without warning during upgrade. |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+

SRS:4326から今作った16668への変換

　先ほどと同様に、WGS84(SRS:4326)からJGD2011(Lon-Lat順) (SRS:16668) への変換を試みましょう。

mysql> SELECT ST_AsText( ST_Transform( ST_GeomFromText('POINT(35 135)',4326), 16668 )) g;
+---------------+
| g             |
+---------------+
| POINT(135 35) |
+---------------+


おおお！！！ Lon-Lat順の数値が返ってきました！

まとめ

　このことから、MySQLの Lat/Lon の記述順序は、その測地系のものとして定義された内容に従うことを確認できました。
すばらしきMySQL！

平面直角座標系でのタテヨコ移動の際の緯度経度の変化について整理

gis

昨日のエントリで、「平面直角座標系で、X軸の値のみ、またはY軸の値のみを変更したのに、緯度・経度の片方ではなく両方変わってしまうのは、おかしい」という意味のことを書きました。
すかさず「それで正しいのだ」と とーかさんからご指摘をいただき、幾度かのやりとりに加えて自分でも考え調べて、少しだけですが理解が進んだ気がするので、ここにまとめておきます。いつもありがとうございます。
やりとりについて眺めてみたい方は、以下のポストから始まるツリー（ちょっと複雑に枝分かれしています）を追いかけると良いでしょう。



私がおかしいと思った挙動

前のエントリで書いた内容の繰り返しになりますが、私が当初「こおかしい」と判断した挙動を書いておきます。

平面直角座標系II系の原点位置を緯度経度に変換します。小数点以下深い部分で数値誤差を無視することにして、原点なのでこんな緯度経度が得られます。正しいです。

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 6670), 6668));
+---------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 6670), 6668)) |
+---------------------------------------------------------------------+
| POINT(33.00000000000004 131.0000000000001)                          |
+---------------------------------------------------------------------+


MySQL 8.1.0現在の平面直角座標系変換にはどうも挙動に誤りがあるようで、平面直角座標系の座標を北-東の順に (X Y) で与えるべきところ (Y X)で与えないといけない（誤った動作）があります。今回の実験はこの挙動をいったん受け入れて先に進むことにします。

先のエントリで私が「おかしい」と書いた挙動（今は正しいと理解している）は以下のもの。
平面直角座標系で Y のみを動かしてXは動かしていないのに、Xに対応する緯度も変化してしまっている、というのがその（勘違いの）おかしな挙動です。

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(-10000 0)', 6670), 6668));
+--------------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(-10000 0)', 6670), 6668)) |
+--------------------------------------------------------------------------+
| POINT(32.99995413312006 130.8929839645656)                               |
+--------------------------------------------------------------------------+

原点からXのみを変更した場合は

　ちなみに、原点から X（緯度方向）のみを変更した場合はどうなるか。
この場合は、予想通りに緯度のみが変化し、経度は変化しません。

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 10000)', 6670), 6668));
+-------------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 10000)', 6670), 6668)) |
+-------------------------------------------------------------------------+
| POINT(33.090176066766794 131.0000000000001)                             |
+-------------------------------------------------------------------------+

横メルカトルは緯線経線が直交しない

　私が漠然と勘違いし続けていたことがあります。横メルカトルが「メルカトル」という聞き慣れた響きを含むことから、緯線と経線が直交したあの見慣れた図が脳内に浮かんでいました。(縦)メルカトル図法で直交するのは、赤道付近に紙を巻くイメージで考えた時、隣(というのも変ですが5度離れた、とか10度離れた、という程度の意味に捉えてください)の緯線は赤道と平行に存在しています。
　一方の横メルカトル。ある子午線に紙を巻くイメージで同様に考えて見えると、隣の子午線は軸となる子午線と並行になりません。南北の極点でぶつかるのが隣の子午線です。だからこれは平面に落としたときに軸となる子午線とは平行にならない。このことを理解できるまでに、随分時間がかかりました。。アタマ堅いなぁ。。　でも沢山のヒントをいただいて考える時間を取ってひとつずつ理解できる内容が増えていく過程は、本当に楽しいものですね。

平面直角座標系と緯度との関係

　そんなわけで自分なりに整理した図が、以下のもの。

平面直角座標系II系を例にしています。原点は NE(33.0 131.0)です。
原点からこのまま北方向に、つまりX値のみを加えた場合、緯度のみが変化し経度は変化しません。「Xのみを・・・」の節で示した結果と一致します。

一方、Y値のみを加える場合、つまり平面直角座標系に於いては座標上を右に移動する場合は、図に示したとおりどんどん緯度が小さくなっていきます。(クエリ例では -10km つまり西方向に10km移動させましたが、同じことです）

これが、平面直角座標系で X、Yの片方のみを変更したのに緯度も経度も変化してしまったという事象のカラクリです。正しいのです。

原点以外の場所からの X, Yそれぞれの移動は？

　話をシンプルにするために原点からの移動を話題にしましたが、ここで原点以外の地点からの移動を考えてみたいと思います。
Y軸に沿った方向への移動は図からも明らかなとおり、X軸よりも右側ではYが大きくなるほど緯度は小さくなり、Yが小さくなれば緯度が大きくなります。X軸の左側でも同様に考えることができます。
　では原点以外の場所から X のみを変化させた場合はどうなるでしょうか。細かい調査と確認過程の説明は省略しますが、図にするとこんな感じになります。北半球、特に具体的に言えばII系を念頭に書いています。この図を見れば Yを固定してXを上下に動かしたときに経度がどのように変化するかイメージできるかと思います。

まとめ

　メルカトルという名前に引きづられて「緯線と経線が直交している」と思い込んでいた横メルカトル。今回ようやくその実態に少し近づくことができた気がします。平面直角座標系、おもしろい。
なお、今回のMySQLでの実行結果（JGD2011での 地理座標計と平面直角座標系II系の変換）は、先日の当ブログで紹介した方法で、MySQL 8.1.0でも JGD2011定義に TOWGS84パラメタが付加された状態のもので実施したものです。お手元の素のMySQLで実施したい場合は JGD2011ではなく JGD2000を使えば同様の確認ができますので、ぜひお試しください。

MySQLのJGD2011での座標系変換/換算にトライ

mysql gis

MySQLのJGD2011の SRS定義には towgs84が含まれていないために座標系の変換や換算できない課題について、「EPSG 9.0や9.1には、JGD2011にtowgs84の定義は含まれていない。EPSG v10.042 以降をMySQL開発チームが採用してくれれば全て解決する」との予想的結論をひとつ前のエントリで書きました。
sakaik.hateblo.jp


このエントリーでは一足先に、JGD2011でtowgs84を含んだ定義での動作を得るための方法を実験します。本稿は MySQL 8.1.0で動作確認しています。

SRSの定義の変更

　MySQLのソースコードの、mysql_system_tables_data.sql ファイルにSRSの定義が納められているので、ここを書き換えてビルドするなどの方法がありそうですが、少し手順が戻りすぎの感があるので、ここでは既に稼働しているMySQL上でどうにかする方法を考えます。
　MySQL には、CREATE OR REPLACE SPATIAL REFERENCE SYSTEM という素晴らしい命令があります。これを使いましょう。

現在の課題点の確認

課題(1) JGD2011からWGS84への変換がエラー

WGS84, JGD2000, JGD2011それぞれからの WGS84への変換を試みます。

データ作成

CREATE TABLE p (g geometry);
INSERT INTO p VALUES( ST_GeomFromText('POINT(35.5 135)',4612));
INSERT INTO p VALUES( ST_GeomFromText('POINT(35.5 135)',4326));
INSERT INTO p VALUES( ST_GeomFromText('POINT(35.5 135)',6668));

データ確認

mysql> SELECT ST_AsText(g), ST_SRID(g) FROM p;
+-----------------+------------+
| ST_AsText(g)    | ST_SRID(g) |
+-----------------+------------+
| POINT(35.5 135) |       4612 |
| POINT(35.5 135) |       4326 |
| POINT(35.5 135) |       6668 |
+-----------------+------------+
3 rows in set (0.01 sec)

これらのデータを ST_Transform()関数を使って SRID 4326 への変換を試みると、SRID 6668からの変換ができない旨エラーとなります。

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

念のため、SRID 6668の行を除外して実施すれば期待通りに動作するので、SRID 6668の行が問題であることが確認できました。

mysql> SELECT ST_AsText(ST_Transform(g, 4326)), ST_SRID(g) fromsrs, ST_SRID(ST_Transform(g, 4326)) tosrs FROM p
    -> WHERE ST_SRID(g)<>6668;
+----------------------------------+---------+-------+
| ST_AsText(ST_Transform(g, 4326)) | fromsrs | tosrs |
+----------------------------------+---------+-------+
| POINT(35.5 135)                  |    4612 |  4326 |
| POINT(35.5 135)                  |    4326 |  4326 |
+----------------------------------+---------+-------+
2 rows in set (0.00 sec)
課題(2) 平面直角座標系との換算がエラー

　JGD2000の平面直角座標系2系(SRID 2444)から地理座標計への換算を確認します。末尾数値が少し気になりますが、正しく2系原点の緯度経度を返してくれることが確認できます。

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 2444), 4612));
+---------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 2444), 4612)) |
+---------------------------------------------------------------------+
| POINT(33.00000000000004 131.0000000000001)                          |
+---------------------------------------------------------------------+
1 row in set (0.00 sec)

同様にして JGD2000の平面直角座標系2系から地理座標計への換算を試みると、エラーになります。towgs84が含まれていないためです。

mysql> SELECT ST_Transform( ST_GeomFromText('POINT(0 0)', 6670), 6668);
ERROR 3743 (22S00): Transformation from SRID 6670 is not supported. The spatial reference system has no TOWGS84 clause.

JGD2011の定義を変えちゃう！

　ST_SPATIAL_REFERENCE_SYSTEMSテーブルのに格納されている定義を変更してしまいます。やりたいことは、JGD2011の定義に、JGD2000にあるのと同様の形となるよう TOWGS84 の情報を追加することです。 ST_SPATIAL_REFERENCE_SYSTEMS テーブルは INFORMATION_SCHEMAにあり、一見普通のテーブルに見えますが、これを直接書き換えることはできません。専用の命令「CREATE OR REPLACE SPATIAL_REFERENCE_SYSTEM」文を使用します。

まず現在のJGD2011の定義を確認します。今回は 地理座標計と2系だけを見れば良かったのですが、ちょっと目視しておこうと、周辺のものも少し見てみました。

SELECT * FROM information_schema.ST_Spatial_reference_systems WHERE srs_id in (6668,6669,6670,6671);
+------------------------------------------+--------+--------------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
| SRS_NAME                                 | SRS_ID | ORGANIZATION | ORGANIZATION_COORDSYS_ID | DEFINITION                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | DESCRIPTION |
+------------------------------------------+--------+--------------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
| JGD2011                                  |   6668 | EPSG         |                     6668 | 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"]]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | NULL        |
| JGD2011 / Japan Plane Rectangular CS I   |   6669 | EPSG         |                     6669 | PROJCS["JGD2011 / Japan Plane Rectangular CS I",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"]],PROJECTION["Transverse Mercator",AUTHORITY["EPSG","9807"]],PARAMETER["Latitude of natural origin",33,AUTHORITY["EPSG","8801"]],PARAMETER["Longitude of natural origin",129.5,AUTHORITY["EPSG","8802"]],PARAMETER["Scale factor at natural origin",0.9999,AUTHORITY["EPSG","8805"]],PARAMETER["False easting",0,AUTHORITY["EPSG","8806"]],PARAMETER["False northing",0,AUTHORITY["EPSG","8807"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",NORTH],AXIS["Y",EAST],AUTHORITY["EPSG","6669"]]              | NULL        |
| JGD2011 / Japan Plane Rectangular CS II  |   6670 | EPSG         |                     6670 | PROJCS["JGD2011 / Japan Plane Rectangular CS II",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"]],PROJECTION["Transverse Mercator",AUTHORITY["EPSG","9807"]],PARAMETER["Latitude of natural origin",33,AUTHORITY["EPSG","8801"]],PARAMETER["Longitude of natural origin",131,AUTHORITY["EPSG","8802"]],PARAMETER["Scale factor at natural origin",0.9999,AUTHORITY["EPSG","8805"]],PARAMETER["False easting",0,AUTHORITY["EPSG","8806"]],PARAMETER["False northing",0,AUTHORITY["EPSG","8807"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",NORTH],AXIS["Y",EAST],AUTHORITY["EPSG","6670"]]               | NULL        |
| JGD2011 / Japan Plane Rectangular CS III |   6671 | EPSG         |                     6671 | PROJCS["JGD2011 / Japan Plane Rectangular CS III",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"]],PROJECTION["Transverse Mercator",AUTHORITY["EPSG","9807"]],PARAMETER["Latitude of natural origin",36,AUTHORITY["EPSG","8801"]],PARAMETER["Longitude of natural origin",132.177777777778,AUTHORITY["EPSG","8802"]],PARAMETER["Scale factor at natural origin",0.9999,AUTHORITY["EPSG","8805"]],PARAMETER["False easting",0,AUTHORITY["EPSG","8806"]],PARAMETER["False northing",0,AUTHORITY["EPSG","8807"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",NORTH],AXIS["Y",EAST],AUTHORITY["EPSG","6671"]] | NULL        |
+------------------------------------------+--------+--------------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+

別途、JGD2000の定義を見て、TOWGS84を入れる場所を確認しておきます。
また、その測地系が使用されていると更新できないらしいので、念のため、使用されていないことも確認しておきます。

-- JGD2011(geom)
mysql> SELECT * FROM INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS WHERE SRS_ID=6668;
Empty set (0.00 sec)

-- JGD2011(平面直角2系)
mysql> SELECT * FROM INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS WHERE SRS_ID=6670;
Empty set (0.00 sec)

　さて、定義の書き換えです！　まず地理座標計のほう。 DEFINITIONにTOWGS84を加えた以外は元の値をそのままコピーして記述しています。WARNINGが出るのは、EPSGの予約範囲のID（0～32767と6000万台）および20億台の一部に該当するIDであるためです。warningは出るけど正常にデータは更新されます。

mysql> CREATE OR REPLACE SPATIAL REFERENCE SYSTEM 6668
    -> NAME 'JGD2011'
    -> ORGANIZATION 'EPSG' IDENTIFIED BY 6668
    -> DEFINITION 'GEOGCS["JGD2011",DATUM["Japanese Geodetic Datum 2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],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"]]';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                                                                          |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Warning | 3715 | The SRID range [0, 32767] has been reserved for system use. SRSs in this range may be added, modified or removed without warning during upgrade. |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

同様に平面直角座標2系の定義も更新。

mysql> CREATE OR REPLACE SPATIAL REFERENCE SYSTEM 6670
    -> NAME 'JGD2011 / Japan Plane Rectangular CS II'
    -> ORGANIZATION 'EPSG' IDENTIFIED BY 6670
    -> DEFINITION 'PROJCS["JGD2011 / Japan Plane Rectangular CS II",GEOGCS["JGD2011",DATUM["Japanese Geodetic Datum 2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],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"]],PROJECTION["Transverse Mercator",AUTHORITY["EPSG","9807"]],PARAMETER["Latitude of natural origin",33,AUTHORITY["EPSG","8801"]],PARAMETER["Longitude of natural origin",131,AUTHORITY["EPSG","8802"]],PARAMETER["Scale factor at natural origin",0.9999,AUTHORITY["EPSG","8805"]],PARAMETER["False easting",0,AUTHORITY["EPSG","8806"]],PARAMETER["False northing",0,AUTHORITY["EPSG","8807"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",NORTH],AXIS["Y",EAST],AUTHORITY["EPSG","6670"]]';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                                                                          |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
| Warning | 3715 | The SRID range [0, 32767] has been reserved for system use. SRSs in this range may be added, modified or removed without warning during upgrade. |
+---------+------+--------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

　これでJGD2011の地理座標と2系のSRS定義が更新されました。

いざ、JGD2011での変換／換算へ！

ST_Transform()での WGS84への変換。
mysql> SELECT ST_AsText(ST_Transform(g, 4326)), ST_SRID(g) fromsrs, ST_SRID(ST_Transform(g, 4326)) tosrs FROM p;
+----------------------------------+---------+-------+
| ST_AsText(ST_Transform(g, 4326)) | fromsrs | tosrs |
+----------------------------------+---------+-------+
| POINT(35.5 135)                  |    4612 |  4326 |
| POINT(35.5 135)                  |    4326 |  4326 |
| POINT(35.5 135)                  |    6668 |  4326 |
+----------------------------------+---------+-------+
3 rows in set (0.00 sec)

まったく問題ありません。

平面直角2系から地理座標への換算

JGD2011での換算もエラーなく実施できるようになりました！

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 6670), 6668));
+---------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(0 0)', 6670), 6668)) |
+---------------------------------------------------------------------+
| POINT(33.00000000000004 131.0000000000001)                          |
+---------------------------------------------------------------------+
1 row in set (0.00 sec)


　実はこの、平面直角座標系から地理座標への変換、色々おかしいぞ？という動作をしているのですが、これはもう少し調査をしてから話題にしたいと思います。ちなみに以下のようなクエリで、2つほど「おかしいぞ」があります:-)

mysql> SELECT ST_AsText(ST_Transform( ST_GeomFromText('POINT(-10000 0)', 6670), 6668));
+--------------------------------------------------------------------------+
| ST_AsText(ST_Transform( ST_GeomFromText('POINT(-10000 0)', 6670), 6668)) |
+--------------------------------------------------------------------------+
| POINT(32.99995413312006 130.8929839645656)                               |
+--------------------------------------------------------------------------+

まとめ

　SRS定義を変更することで、JGD2011定義にも TOWGS84を加えることができることの確認を行いました。
実際の運用に於いては、この定義テーブルを書き換えることのリスク（バージョンアップ時に元に戻ってしまう可能性、それを確認して全DBサーバの定義を再度書き直す手間とその際の操作ミス等のリスクなど）が許容できる場合には、有効な手段になるのではないでしょうか。
　なお、今回は平面直角座標系は2系のみを定義変更しましたが、言うまでもなく、実際に運用される場合は1～19系全ての定義に TOWGS84を加える必要があることに留意ください。



.


.
先ほどの「おかしいぞ」の答えを書いておくと

  • X軸のみを南に10km移しているのに、もう一方の軸の値も変わってしまっているぞ？（実際は様々な距離で試して、値がどう変化するのかを確認しています）
  • 第1引数はX軸。X軸って、、、どっちだっけ？ そう。北側ですね。変化した軸は・・・経度！？

→追記(2023/09/09)：X Y の順序はともかく、1番目の「X軸のみを南に移動」の件は、これで正しいことがわかりました。平面直角座標系に関する私の知識がまったく不足していたことが原因で、以下のエントリを読むと平面直角座標系がよくわかりますのでぜひご覧ください。
sakaik.hateblo.jp

続・MySQLのJGD2011定義にtowgs84がない話(一旦決着)

mysql gis

　先日書いた 「MySQLのJGD2011定義にtowgs84がない話」に、一定の結論が出た気がします。
とーかさん（@tohka38）のブログ(下記)と、MySQLの大塚さんとのやりとりをさせていただいた中から調査の糸口がみつかりました。どうもありがとうございます。

qiita.com

前提知識

  • EPSGの定義には、バージョンがある。年10回以上更新されている。本日時点の最新版は v10.094
  • MySQLの ST_SPATIAL_REFERENCE_SYSTEMS テーブルに登録されている情報は、
    • MySQL 8.0が EPSG v9.0 を元にしたもの
    • MySQL 8.1が EPSG v9.1 を元にしたもの

結論めいたもの

　これが正しい考えなのかを検証する手段を私は持たないのですが、十分に納得感がある思考に到達したので、「結論めいたもの」としてまとめます。

　EPSGの定義の中には、測地系どうしの値を変換するための情報が含まれています。これは WGS84への変換のみでなく、それ以外の測地系相互の変換に関する情報が含まれている場合もあります（MySQLでは WGS84への変換情報以外は無視しており、使用していない＝取り込んでいない＝です）。
WGS84への変換について、MySQL 8.0 で使用している EPSG v9.0には「JGD2000 to WGS 84」は存在しているが「JGD2011 to WGS 84」が存在していません。
EPSG v9.1 も同様です。
「JGD2011 to WGS 84」が登場するのは、EPSG v10.042 (2021-12-30) になってからです。そのひとつ前の EPSG v10.041(2021-12-03)には存在していませんでした。

　ということで、MySQL 8.0/8.1 のST_SRSに JGD2011からWGS84への変換情報が含まれていないのは、
『使用しているEPSGの定義が古いから～』
でしたぁ。（チコちゃん風に）


実際の定義の確認

JGD2000 to WGS84 の定義のひとつ：
4612から4326への変換であることが示されています(パラメタ値はこれとは別に epsg_coordoperationparamvalue にて定義されています。)

INSERT INTO epsg_coordoperation 
     (coord_op_code, coord_op_name, coord_op_type, source_crs_code, target_crs_code, coord_tfm_version, coord_op_variant, area_of_use_code, coord_op_scope, coord_op_accuracy, coord_op_method_code, uom_code_source_coord_diff, uom_code_target_coord_diff, remarks, information_source, data_source, revision_date, change_id, show_operation, deprecated) 
  VALUES (1826, 'JGD2000 to WGS 84 (1)', 'transformation', 4612, 4326, 'EPSG-Jpn', 1, Null, '', 1., 9603, Null, Null, '', 'OGP', 'EPSG', '2020-03-14', '2020.027', 1, 0);

EPSG v10.142で加えられた JGD2011 to WGS84の定義：
6668から4326への変換であることが示されています。

INSERT INTO epsg_coordoperation 
    (coord_op_code, coord_op_name, coord_op_type, source_crs_code, target_crs_code, coord_tfm_version, coord_op_variant, area_of_use_code, coord_op_scope, coord_op_accuracy, coord_op_method_code, uom_code_source_coord_diff, uom_code_target_coord_diff, remarks, information_source, data_source, revision_date, change_id, show_operation, deprecated) 
    VALUES (9936, 'JGD2011 to WGS 84 (1)', 'transformation', 6668, 4326, 'EPSG-Jpn', 1, Null, '', 1., 9603, Null, Null, '', 'IOGP', 'EPSG', '2021-12-30', '2021.116', 1, 0);

今後に期待

　JGD2011を使用したい我々としては、MySQL開発チームが EPSG v.10.142以降を採用してくれる日を待ちたいと思います。早く来るといいな。
中の人のみなさんがご覧になって、尽力していただけたら嬉しいです。

参考エントリ

sakaik.hateblo.jp

qiita.com

登記所備付地図データ更新公開(202308)＆サマリ集計しました

moj xml gis

2023年1月に初めて公開された法務省の「登記所備付地図データXML」。更新は年1回程度を予定とのことだったので年内は何もないと思っていたら、少し前に「8月31日に更新データを公開します」との発表がありました。素晴らしい！！！

https://www.moj.go.jp/MINJI/minji05_00494.html

概略集計しました

　今回も、メタデータ部分について簡単な集計をしました。
都道府県毎のファイル数、任意座標と公共座標の数と率、座標系毎のファイル数などを公開しています。
「今ここ何番地？」の白土さんとも協力して、かなり正確な数値になっています。

github.com

kuwanauchiプロジェクト

　1月公開のデータに私がハマったのは、kuwanauchiプロジェクトのおかげでした。
大元では二重ZIPで公開されていたファイル群を1段階展開して扱いやすくしたり、それらを GitHub で公開して git pull 一発で全データを取得できるようにしてくれていたおかげで、速やかに「データの中身を覗いてみる」という本質にたどり着くことができ、大変感謝をしています。
github.com


　その恩返しというのは烏滸がましいのですが、8月公開データでは、これから始める方々のために kuwanauchi での公開に何か役に立ちたいと思い、データを集める作業（＝ダウンロード）を頑張りました。やってみて分かったのは、ほんとにこれ、大変です。3人で手分けしてようやく深夜（未明？）にダウンロードが完了しましたが、全国分のデータ欲しかったら、自分ひとりで手作業でやるような作業じゃぁないです。改めて 1月のkuwanauchiプロジェクトへの感謝の念が強くなりました。
　現在、ファイルの確認作業は完了し、公開に向けての作業をやってもらっているところです。公開されたらぜひ活用ください！

MySQLのJGD2011定義にtowgs84がない話

mysql gis

承前

　タイトルを見て何の事を言ってるのかわかる人向けのメモ書きです。結論としては「私もよくわかっていない」の段階ですが、調査して（正しいかどうかは分からないけど）多少の情報と仮説ができてきたので、メモとして記す次第です。

最終目的

　MySQLの INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS の JGD2011の定義には「towgs84」の記述が含まれていません。JGD2000には含まれています。Tokyoにも（値がなんかおかしいのは別の問題として一応）値は含まれています。JGD2000に含まれているのにJGD2011に含まれていないのはおかしい。含めて欲しい、というのが当方の立場です。

MySQLの立場

　測地系に関する定義情報は、ソースコードの scripts/mysql_system_tables_data.sql に含まれています。このファイルの JGD2011の行に towgs84 を書いてくれればすべて解決です*1。しかし、MySQL開発チームはこれをやってくれません。
　というのは、私の長年の活動の中で見聞きした感覚では、最近のMySQLの開発方針として「外部の組織が定めているものはそれに従うこととし、MySQL独自の部分的な変更や例外対応などはしない」というものがあるように思えます。文字コード（Unicode）もそうですし、今回の測地系の情報についても同じです。なので、大元の定義にないものを「JGD2011には towgs84が必要だから入れて」と言っても、簡単には対応してもらえない、という立場を取っていることを私は理解しています。
　今回のケースでは EPSGの元の定義情報に何らかの変更が加わるか、そこからmysql_system_tables_data.sqlに変換する際のルールに（結果としてJGD2011に towgs84が加えられるような）合理的な変更の提案ができるか、のいずれかが、今採れる対応なのかな、と考えています。

登場する測地系情報

ここでは Tokyo（日本測地系）、JGD2000、JGD2011 を比較しながら眺めていきます。それぞれの SRIDは以下のとおりです。

TOKYO 4301
JGD2000 4612
JGD2011 6668

それぞれのEPSGによる定義

Tokyo

https://epsg.io/4301

GEOGCS["Tokyo",
    DATUM["Tokyo",
        SPHEROID["Bessel 1841",6377397.155,299.1528128],
        TOWGS84[-146.414,507.337,680.507,0,0,0,0]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4301"]]
JGD2000

https://epsg.io/4612

GEOGCS["JGD2000",
    DATUM["Japanese_Geodetic_Datum_2000",
        SPHEROID["GRS 1980",6378137,298.257222101,
            AUTHORITY["EPSG","7019"]],
        AUTHORITY["EPSG","6612"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4612"]]
JGD2011

https://epsg.io/6668

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.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","6668"]]

Tokyo測地系の課題

　Tokyo(4301)の ST_SRS上の定義です。

mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='4301'\G
*************************** 1. row ***************************
                SRS_NAME: Tokyo
                  SRS_ID: 4301
            ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 4301
              DEFINITION: GEOGCS["Tokyo",DATUM["Tokyo",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[-147,506,687,0,0,0,0],AUTHORITY["EPSG","6301"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943278,AUTHORITY["EPSG","9122"]],AXIS["Lat",NORTH],AXIS["Lon",EAST],AUTHORITY["EPSG","4301"]]
             DESCRIPTION: NULL

　ここにはちゃんと(?) TOWGS84 が含まれています。ただし、EPSGの定義と見比べると分かりますが、値がなんか変です。一致していません。本件については更に調査を進めているところなので、本稿ではこれ以上触れません。何か分かったら別途書きたいと思います。

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

JGD2000の場合

　JGD2000の場合は、EPSGの定義中には towgs84は含まれていませんが、MySQLの ST_SRS上には TOWGS84が含まれた定義が登録されています。何ででしょうね。このあと考察します。　

mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='4612'\G
*************************** 1. row ***************************
                SRS_NAME: JGD2000
                  SRS_ID: 4612
            ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 4612
              DEFINITION: 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"]]
             DESCRIPTION: NULL

JGD2011の場合

　JGD2011の場合は、EPSGの定義中にはtowgs84は含まれず、MySQLのST_SRSの定義中にもTOWGS84が含まれていません(含んで欲しい)。JGD2000とほぼ同等と見なして良いはずなのに、なぜでしょうね。

mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='6668'\G
*************************** 1. row ***************************
                SRS_NAME: JGD2011
                  SRS_ID: 6668
            ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 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"]]
             DESCRIPTION: NULL

JGD2000とJGD2011の違い

　ここから先は、完全に推測だけで書く内容です。仕様を確認して裏取りをした話ではなく、データを見て「もしかしてこういうことじゃね？」と想像した内容ですので、この点ご了承ください。
追記：その後の調査で、この段まるごと、まったく関係ないことが分かりました。こんなことを考えていたこともあったな、という記録として残しておきますので、内容は真に受けないようにお願いいたします。追記ここまで。

　似たような JGD2000とJGD2011なのに、方やMySQLに持ってきたときにTOWGS84値を持ち、方や持たない、という状況になっています。MySQL上での定義は、EPSGの定義を元にあるルールに従って変換しているだけのはずなので、何かが違うはずです。どこが違うのかな。
　関係ない（と私が判断した）ところをざっくりと畳んでみました。違いが分かるでしょうか。そう、DATUMの AUTHORITY が異なりますね。

GEOGCS["JGD2000",
    DATUM["Japanese_Geodetic_Datum_2000",
                 SPHEROID[....],
                 AUTHORITY["EPSG","6612"]],
    PRIMEM[....],
    UNIT[....],
    AUTHORITY["EPSG","4612"]]
GEOGCS["JGD2011",
    DATUM["Japanese_Geodetic_Datum_2011",
        SPHEROID[....],
        AUTHORITY["EPSG","1128"]],
    PRIMEM[....],
    UNIT[....],
    AUTHORITY["EPSG","6668"]]


JGD2000のDATUM EPSG:6612、JGD2011のDATUM EPSG:1128それぞれの定義を見てみます。正直なところ、この追跡に意味があるか（正しいか）すら確証なく、とりあえず見てみている状態です(笑)。

JGD2000のEPSG:6612(一部省略)。DATUMに TOWGS84の記述が含まれています。ただしなんで NAD83に紐付いているのか、とか、これそもそも投影座標系じゃないかとか、意味がわからない点が多々ありますが、ここはもうEPSGの番号だけで追ってみました。
https://epsg.io/6612

PROJCS["NAD83(2011) / Wyoming East (ftUS)",
    GEOGCS["NAD83(2011)",
        DATUM["NAD83_National_Spatial_Reference_System_2011",
            SPHEROID["GRS 1980",6378137,298.257222101],
            TOWGS84[0,0,0,0,0,0,0]],
    ....
    AUTHORITY["EPSG","6612"]]


一方の JGD2011。こちらは EPSG:1128。COORDINATEOPERATIONという見たことのないタイプであり、名前が "Cape to WGS 84"という、なぜこれがJGD2011から参照されているのか理解に苦しみます（ケープペンギンさんのいるケープのことですかね？）。意味不明だなと思いながら、とりあえずこの長い定義の中には towgs84 が含まれていない、ということを押さえておきます。

https://epsg.io/1128

COORDINATEOPERATION["Cape to WGS 84 (1)",
    VERSION["DMA-Zaf"],
    SOURCECRS[
        GEOGCRS["Cape",
            DATUM["Cape",
                ELLIPSOID["Clarke 1880 (Arc)",6378249.145,293.4663077,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["geodetic latitude (Lat)",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["geodetic longitude (Lon)",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]],
            ID["EPSG",4222]]],
        .....

結論にならない結論

　MySQL開発チームが scripts/mysql_system_tables_data.sql ファイルをどのようにして作成しているのかは、恐らく存在するであろう変換スクリプトを見ないと分からないのですが、EPSGの定義ではJGD2000と2011の間の違いらしい違いはDATUMのAUTHORITYくらいだなということを今回確認できました。
　なお、QGISで JGD2000と JGD2011の定義をそれぞれ見てみると、どちらにも

Proj4
+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

が含まれています。QGISはMySQLとはまた別の変換ルールを持っているようですね。（TOWGS84定義がなければオールゼロで定義する、など）


　MySQLのJGD2011にTOWGS84が追加される日を願って、今日のところはこれくらいで。


追記：Transformationを見るべきだ！

とーかさんが最新情報を調べて、ブログに整理してくれました！
色々書いてありますが、towgs84の話に絞って書くと、結論としては
「EPSG-CRSの定義だけでなく、EPSG-Transformationの定義も見るべきだ（そちらに書いてある）」ということです。
番号の紐付けは不明。一旦ぜんたいを見直したり検索したりして、別エントリにまとめるかもしれません（まとめないかもしれません）。


qiita.com

*1:手元のマシンに適用したいだけなら、自分で JGD2011の行にtowgs84を書き加えて、その行のクエリ(REPLACE文)を実行すればめでたしめでたしです

FOSS4G Tokai 2023参加

gis geo foss4g

ようやく世界が動き出した！

　というか、私の気持ちの中での話なのですが、昨年開催された FOSS4G Tokai 2022の時期にはまだ、遠征しようという気持ちにはなれなかったところ、今年はいよいよリアル会場で参加するぞ！という気分が盛り上がってきました。日程情報のリークを受けた後はなかなかイベント詳細情報が公開されずにやきもきしていましたが、誰が何を話す場になっても面白い事は間違いないので、行くことは早々に決めていました。
foss4gtokai.my.canva.site

前夜祭こそ本体

　私にとって前夜祭は、遠征（宿泊を伴うイベント参加）の最大の楽しみと言っても過言ではありません。今回は特に公式の前夜祭は開催されなかったので、現地の関係者、前日入りの関係者の方々とお食事をしました。前日入りというか、この日はすでに「ハンズオン」のイベントが開催されていたんですけどね。私はハンズオンには参加せずに、少し早く名古屋入りして、今まで行く機会のなかった念願の名古屋城詣で等をしてきました。名古屋城、美しかったです！(写真)
　

　前夜祭では期待通り、いや、期待以上に様々な話で盛り上がりました。色々教えてもらったり、話を聞いてもらったり、満腹になるまで食べたのに驚くほど安かったし、あまりにも満足度が高すぎたので思わず出たのが、恒例の(?)「やー！　今年も良い FOSS4G Tokaiだった！」。

今年2度目のFOSS4G Tokai 開幕！

　翌朝。　昨晩のうちに「今年も良いFOSS4Gだった」と満足のうちにイベントを終えた私は、改めて「今年2回目の参加」の気分でFOSS4G Tokaiへ。1度の遠征で2度おいしい。
　普通にセミナーを聞くだけの「一般参加者」として申し込んでいたのですが、昨晩「明日、9時に来てね」と言われて、まぁ前夜祭楽しかったし、ホテルも近くだし、行けば行ったで何かお役にたてるかも、とも思ったので、9時少し過ぎに会場へ(要するに少し遅刻)。配信のための確認作業など「配信チーム」的な役割の片隅で、少しは役に立てたようです。いやぁ、配信のあれこれ、本当に全てギリギリでしたねぇ(笑)。動画音声を会場に流すことができなかった事だけが残念でしたが、全体として事故なく配信が完了できて良かったです。　運営スタッフさんが食べるお弁当の注文にも混ぜてもらい（実費）、ヒモノ照ラス&スタンドヒモ子 のお魚のお弁当を。こういう所で食べるお弁当とは思えないほどしっかりしたお魚がついていて、激烈においしかったです！

ゆったりセミナー

　今回のFOSS4G Tokaiは、ほぼ運営側からの指名で講演者が決まったようで、公募があればちょっと応募したかったところではあったのですが、まぁ来月福井で発表枠をいただけたので、私の発表はそちらで。 ひとつひとつの講演時間をゆったり取ってあり、この手のイベントではどうしても「多くの人に発表してもらおう」として慌ただしくなりがちなところ、じっくりと話を聞くことができ、また、sli.doを通した質疑の時間もたっぷり取ったことで、「講演者が用意したスライドをしゃべるだけではない」生の考えや知識などを効かせてもらうことができたのが、とても良かったです。

  • FOSS4Gの歴史
  • 点群の公開からずっと気になる存在の静岡県さん。前任者(?)からも脈々と思いと情報が継承されている事が分かり嬉しかったです。
  • デジタルツイン。データ公開。公開のレベル。
  • 衛星データの(深い話もしてくれたのですが私にとっては)沢山の基礎知識。そもそも衛星がいつ写真撮ってるのかもよく知らず、そういった生のお話に興奮しました。
  • 衛星画像、航空写真の精緻化。何故こんなにキレイになるのかは理解できなかったけど、元画像に歪みがある（車の形がゆがむなど）なら精緻化した画像も変である、という話を聞いて少し安心しました。
  • ダイナミックタイリング。DB屋からすると(というか普通にシステム屋として考えても)、レスポンスとなり得るデータをすべて予めファイルとして用意しておくなんてあり得ないわけで、文化の差にまず驚くわけですが、ただファイルだけを返すよりも絶対に遅くはなるので、そのメリットとレスポンスタイムのバランスの中で便利でダイナミックな用法が提案できると良いなと思いました。今はまだ、タイルに要求されているバリエーションが単純すぎるので、「もっと自由に要求していいんだよ」というのが当たり前になってくると、「ダイナミックタイリングするのが当たり前」になっていくのだろうなと想像しました。ここ、もうちょっと詳しくなって、私ももっと語れるようになりたい(笑)。
  • MySQL。簡単に言うとGIS機能はこの1年進化していない。・・・という所がポイントではなく、データを自由に扱えるという観点から ST_Transform()の充実は大きな進化。ジオメトリとジオグラフィの話も整理されていて良かったです。


　私は集中力がないときはないので、こんな丸1日もセミナー聞いていたら、どこかで意識を失う時間帯があるのが通常運転なのですが、今回はそんな間もなく、LTを含めたすべての講演を興奮しながら聴かせてもらいました。良かった。

マスコットのロボット

　今回の FOSS4G Tokai のマスコットのロボットくん。子どもが描いたような雰囲気を出しつつ、絶妙にバランスが良くて、なんだか愛着がわくキャラだなぁと感じました。イベント終了後、画伯自らに、3Dプリンタで印刷されたキャラを「さかいさんも、どうぞ」って戴いちゃって、ふふふ、ちょっと嬉しい(笑)。

懇親会

　懇親会こそイベントの本体！　（また言ってる(笑)）
盛り上がったら写真撮るのを忘れるから、と開始早々、まだ食べ物が出てくる前に一応撮っておいた写真が、案の定、懇親会で撮った唯一の写真になってしまいました。最初に撮っておいてよかった。たくさんの人とお話したいと思いつつ、例によって一旦座ったらそのまま根っこが生えてしまったのですが、まわりが程よく入れ替わってくれて、多くの人とおしゃべりができました。ありがとうございました。

やっぱりオフライン！

　みんなが興味を持っていることを聞かせてもらえたり、自分がちょっと知りたかったことが解決したり、新たな視点をもらって興味の幅が拡がったり、自分の確証を持てなかった知識の裏付けが取れたり、やはり同じ分野に興味を持っている人たちがオフラインで集うのは良いな、と改めて感じた2日間でした。参加して良かった。
　3週間後には、FOSS4G Japan が福井で開催されます。こちらは「たくさんの人に発表してもらう」イベントとなりそうなので、Tokaiとはまた少し違って幅広い話題に触れるチャンスとも言えます。ご興味あればぜひこちらもご参加検討ください（こちらは私も運営委員の片隅におります）。
https://www.osgeo.jp/events/foss4g-2023/foss4g-2023-japan-at-fukui


追記：お部屋の写真も。
　見直してみたら食べ物の写真だらけだったので、開始前に撮ったお部屋入り口からの写真を追記しておきます:-)

資料・動画へのリンク

オープニングトーク(FOSS4Gのれきし)：

speakerdeck.com

デジタルツインの民主化：

speakerdeck.com

Dynamic Tiling：

docs.google.com

MySQLで処理するGIS：

speakerdeck.com

LT:名古屋からどこに降りているのか(大都市交通センサス)：

speakerdeck.com

  • デモサイト：

https://where-to-get-off-from-nagoya-station-webgis.vercel.app/

LT:FOSS4GとAmazon Location Serviceの親和性：

speakerdeck.com

LT:OSGeoJPに入会して 1年で理事になった件：

docs.google.com

  • 登壇ブログ

https://asahina-lab.vercel.app/posts/20230826_foss4g_tokai_lt

講演動画：

www.youtube.com




集合写真：