[PostGIS] PostGIS 1.3.1 の ST_EndPoint 関数に不具合

LINESTRING オブジェクト（GEOMETRYCOLLECTION の場合は最初の LINESTRING オブジェクト）から最後の点を抽出する ST_EndPoint 関数（EndPoint 関数）を PostGIS 1.3.1 で使用すると、関数が異常終了します（1.2.1 では問題ありません）。例えば、psql 上で ST_EndPoint 関数を使用した SQL 文を実行すると、次のようなエラーが出て PostgreSQL サーバとの接続が切れてしまいます。

サーバとの接続が想定外にクローズされました
        おそらく要求の処理前または処理中にサーバが異常終了
        したことを意味しています。
サーバへの接続が切れました。リセットしています: 失敗。

ユーザ向けのメーリングリストを調べてみると、これはバグのようです。すでにソースコードは修正されたようです。

しかし、ソースコードは修正されたものの、新しいバージョン（1.3.2）は8月28日現在、まだリリースされていません。単純な機能の関数なので、修正されたソースコードを基に関数を定義し直してみました。

CREATE OR REPLACE FUNCTION ST_EndPoint( geom geometry ) RETURNS geometry AS $$
BEGIN
	-- LINESTRING の最後の点を返す
	RETURN ST_PointN( geom, ST_NumPoints( geom ) );
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION EndPoint( geom geometry ) RETURNS geometry AS $$
BEGIN
	RETURN ST_EndPoint( geom );
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE STRICT;

問題のソースコードは C で書かれているので実行時間は劣りますが、機能は同じだと思います。

（；^ω^）1.3.2のリリースまでは、これを代わりに使うことにします。

参考文献

• [postgis-users] Problem with st_endpoint in postgis 1.3.1 for windows
• [postgis-users] Problem with st_endpoint in postgis 1.3.1 for windows（返信）
• /trunk/lwgeom/lwgeom_ogc.cC で書かれた ST_EndPoint 関数（LWGEOM_endpoint_linestring 関数）

2007-12-12 追記

2007年12月1日にリリースされた PostGIS 1.3.2 では、この問題は解決しています。

[PostGIS] GeometryCollection を分解するには、ST_Dump 関数を使用する

MULTILINE や MULTILINESTRING など、複数の幾何（geometry）オブジェクトが含まれるオブジェクト（GEOMETRYCOLLECTION）から各幾何オブジェクトを取り出すには、ST_Dump 関数を使用します。

GEOMETRYCOLLECTION からは、そこに含まれる幾何オブジェクトが1つずつ返され、GEOMETRYCOLLECTION 以外（POINT、LINESTRING など）からはそのオブジェクトがそのまま返されます。

ST_Dump 関数から返されるのは、geometry_dump 型のデータで、これは GEOMETRYCOLLECTION 内のインデックス（path、整数配列型）と幾何オブジェクト（geom、geometry 型）でできた複合型です。GEOMETRYCOLLECTION 以外の場合は、path は空の配列になります。

複合型なので、幾何オブジェクトのみを取り出すには、次のように列を指定します。

( <geometry_dump 型を返す列> ).geom

なお、次のような表記もできるようです。

geom( <geometry_dump 型を返す列> )

road テーブル内の MULTILINESTRING を LINESTRING に分解して取り出す SQL は次の通りです。geometry 型のデータは、the_geom 列に格納されているとします。

SELECT ( ST_Dump( the_geom ) ).geom
FROM road

なお、PostGIS 1.3 未満では、ST_Dump 関数ではなく、 Dump 関数を使用します。

参考文献

• PostGIS Manual
• [postgis-devel] dump(geometry)

忘れがちな真実

「ソフトウェア開発 55の真実と10のウソ」を読みました。ソフトウェア開発では基本となっているにもかかわらず忘れ去られていたり、見逃してしまいがちな真実やウソを数ページずつにまとめた本です。うまくまとめられているので、気軽に読み進めることができました。

本書を通して、ソフトウェア開発における人・保守の重要さ、品質・生産性・見積もりなどの定量化の難しさが繰り返し述べられています。

一部には有名なもの（例えば、「真実3：遅れているプロジェクトに人を追加すると、もっと遅れる。」）もありましたが知らなかった真実がほとんどだったので、非常に参考になりました。中でも、驚くと同時に腑に落ちた真実は、「真実21：対象となる問題の複雑度が25％増加するたびに、ソフトウエアによる解法の複雑度は、100%上昇する。これは、改善しなければならない数字ではなく（複雑性を下げるのは非常に望ましいが）、こうなるのが普通だ。」でした。ソフトウェアを開発していると、つい機能を追加したくなったり、今後のことも考えて汎用性を持たせた設計をしたくなったりします。前者はともかく、後者は保守のことも考えれば必要な方針とは思います。しかし、機能を付ければつけるほど、また汎用性のある設計を行おうとすれば行うほど、モジュールやインタフェースの数は多くなり、見通しがしだいと悪くなっていきます。特に、ちょっとした思い付きで汎用性を持たせた設計にしてしまうと、あとで設計を見直したときに見通しが悪すぎて修正作業や、使い方を理解するのに余計な時間を費やすということもありました。このような経験があったので、真実21はとても納得のいくものでした。汎用性に関しては、「真実17：大規模な再利用は、類似システム間ではうまくいく可能性が高い。応用分野の類似性に依存するため、大規模流用の適用範囲は狭くなる。」も参考になります。結局のところ、しっかりとした方針を定めた上でソフトウェアを構築しないと、あっという間に混沌とした状態になってしまうということなのでしょうね。

（；^ω^）反省です……。

本書には、真実やウソに対する反論も同時に挙げられています。前に挙げた「真実3：遅れているプロジェクトに人を追加すると、もっと遅れる。」に対しては、特定の条件が成り立てば真実3は無視できるという反論が挙げられています。

最終的には、本書に挙げられた真実を基本としながらも、自分でしっかり状況を見定めていくことが重要なのだと感じました。

（；^ω^）こういう面からも、ソフトウェア開発は実に複雑ですね。

[ラジオドラマ] 哲学を身近にするドラマ

「哲ねこ七つの冒険」を聞きました。哲学をテーマにしたファンタジードラマです。

哲学というと、抽象的な言葉が多く、分かるような分からないようなあやふやなイメージを持っていました。本ドラマでは、著名な哲学者を模した猫が日常の生活から真理を見出すという構成になっていて、哲学的な言葉がとても身近に感じることができました。

また、哲学者を模した猫の名前も洒落ていて面白かったです。ソクラニャス（ソクラテス）、ニャリストテレス（アリストテレス）など、猫っぽい名前になっています。

これを機に、哲学も少し勉強してみようかと思うようになりました。

（；^ω^）哲学を学ぶ機会はこれまでにもあったのですが、ことごとく機会を逃していたので……

[Cygwin] GDAL のビルド時は Windows 版 PostgreSQL に注意

PostgreSQL がインストールされている Windows 上の Cygwin で GDAL（Geospatial Data Abstraction Library）をビルドする際には、PostgreSQL との相性に注意する必要があります。

PostgreSQL が Program Files 下などのスペースの入ったパスにインストールされている場合は、configure 時に PostgreSQL への設定ファイルを明示的に設定するか、PostgreSQL OGR サポートを無効にする必要があります。

configure 時に設定を行わないと、次のように configure 中にエラーが発生します。（以下は「C:\Program Files\PostgreSQL」に PostgreSQL がインストールされているとします）

checking for pg_config... /cygdrive/c/Program Files/PostgreSQL/8.2/bin/pg_config
checking for PostgreSQL... ./configure: line 21554: test: /cygdrive/c/Program: binary operator expected
./configure: line 21562: test: /cygdrive/c/Program: binary operator expected
./configure: line 21571: /cygdrive/c/Program: No such file or directory
yes

このままビルドを行うと、「libpq-fe.h」が見つからないというエラーが出て失敗します。

PostgreSQL の設定ファイルを指定するには、configure 時に以下のようにします。

./configure --with-pg=<PostgreSQL の設定ファイルへのパス>

PostgreSQL OGR サポートを無効にするには、以下のようにします。

./configure --without-pg