MySQL GIS拡張関数： STX_ClosestPoint()

STX_ClosestPoint(geom1, geom2)

　geom2にもっとも近い位置となるような geom1上の点を返す。実は STX_ShortestLine() 関数が返すLINESTRINGの第1点と結果は同じ。

動作紹介

• 第一引数がPOINTならば、必ずそのPOINTが結果となる。

mysql> SELECT ST_AsText(STX_ClosestPoint(
    ->   ST_GeomFromText('POINT(1 0)'),
    ->   ST_GeomFromText('LINESTRING(-1 1, 2 1)'))) g;
+------------+
| g          |
+------------+
| POINT(1 0) |
+------------+
1 row in set (0.000 sec)

.

• 先ほどの引数の順序を逆にしたもの。今度は第1引数がLINESTRINGなので、線上のPOINTが返される

mysql> SELECT ST_AsText(STX_ClosestPoint(
    ->   ST_GeomFromText('LINESTRING(-1 1, 2 1)'),
    ->   ST_GeomFromText('POINT(1 0)'))) g;
+------------+
| g          |
+------------+
| POINT(1 1) |
+------------+
1 row in set (0.000 sec)

.

• PostGISマニュアルにあるPOLYGON/POLYGONの例

mysql> SELECT ST_AsText( STX_ClosestPoint(
    ->          ST_GeomFromText('POLYGON ((190 150, 20 10, 160 70, 190 150))'),
    ->          ST_Buffer(ST_GeomFromText('POINT(80 160)'), 30)
    ->               ) ) AS llinewkt;
+----------------------------------------------+
| llinewkt                                     |
+----------------------------------------------+
| POINT(131.59149149528952 101.89887534906195) |
+----------------------------------------------+
1 row in set (0.000 sec)

## 裏話
　細かい仕様を与えずにAIに開発させたところ、当初は引数として(POINT, GEOMETRY)を取り、更に結果は第2引数上の点であった。何を考えてこのような仕様にしたかは分からないが、こういった「おかしな動作」を発見し、修正するためにこのブログポスト群を書いている。このプロジェクトはいわゆる「バグ報告ドリブン開発(BRDD)」なので、みなさまもぜひお試しいただき、期待と異なる動作があればぜひ報告していただきたい。
　なお、仕様をPostGISに併せてて変更する相談をした際にも、AIとは短い何度かの会話の後「ShortestLineの一部みたいなものなので、そちらと同じくGEOSライブラリを使いましょう」という提案をしてくれて、非常に話が早かった。こういうところは、人間がひとつひとつ調査して検討して結論を得るというスピード感とは雲泥の差で、もはや従来型の開発方法は「ボタン一発でできる事を手作業で時間をかけてやっている」と評価せざるを得ないとの感覚を持った。（もちろん細かいところまで目を行き届かせて、理解、把握する大切さというのはあるが、果たしてそのレベルで開発を行えている人が「プログラマ」の何パーセントいるのか）
　本来であればもう、いま書いているブログのような検証もAIを駆使して、より短い時間で実施することはできるし、効率を考えればそうすべきなのだろうが、これは私の趣味なので（笑）。