みかん箱

以前、「Code Complete 第2版 ――完全なプログラミングを目指して」を読んだことがあったので、頭の中で「Code Complete」と比較しながら読みました。「Code Complete」と比べると、「プログラミング作法」はプログラミングを始めた人も対象とした内容となっています。そのため、手続き型言語やスクリプト言語を中心に取り上げています。また、前者がコードの書き方に重点を置いていたのに対し、後者はコードの書き方から始まってアルゴリズムやリソース管理の方法など、プログラミング全般に渡っています。

両者を見比べてみると、細かい点で違いが見つかります。個人的に最も目に付いたのは、変数名の付け方でした。「プログラミング作法」では、グローバル変数は長くフルスペルで、ローカル変数は短く省略形でという名付け方が推奨されています。しかし、「Code Complete」では特にグローバル変数は、ローカル変数はという違いには触れておらず、ただ単にフルスペルで長く名付ける方法が推奨されていました。グローバル変数、ローカル変数にかかわらずという表現ではなかったので、本当のところは分からないのですが、私としてはグローバル変数、ローカル変数に関わらず、名前はフルスペルで長く付ける方法の方が良いと思います。

（；^ω^）ただ、ここから思うのは、コードを書く作法は決まりきっていないということですね。「Code Complete」にしても「プログラミング作法」にしても、名著と呼ばれている本ですが、細かい部分では著者の考え方によって違いが出てくるわけです。結局のところ、コードの書き方は、コードを書く度にしっかりと考えていかなければならないようです。

category: データベース
DATE : 2007/12/11 (Tue)

[PostGIS] ST_Union( geometry set )が見つからない？

※ これはインストールの仕方が悪かっただけなのかもしれません。ただ、長時間詰まってしまったので、ここにメモしておきます。

ST_Union( geometry set )という関数があります。これは、geometry で指定された幾何オブジェクトを結合する集約関数で、次のように使用します。ここで、幾何オブジェクトが格納されたテーブルは geometry_table で、幾何オブジェクトの列は the_geom と想定します。

SELECT ST_Union( the_geom )
FROM geometry_table;

上の例では、geometry_table テーブル内の the_geom 列に格納されている幾何オブジェクトが全て結合され、その結果、幾何オブジェクトひとつが返されます。

ところが、上の SQL を PostGIS 1.3.2 で実行すると、ST_Union( geometry )とマッチする関数はないというエラーが出てしまいました。

そこで、次のように ST_Union 関数の代わりに GeomUnion 関数を使用してみました。

SELECT GeomUnion( the_geom )
FROM geometry_table;

PostGIS の 1.3 未満では ST_Union の代わりに GeomUnion を使用していたので、昔のバージョンの関数ならば動くのではないかと踏んだのです。

そして、実際にこれはうまくいきました。ところが、PostGIS 1.3 以降は GeomUnion ではなく ST_Union 関数の使用が推奨されているので、このままではしっくりきません。将来のバージョンでは GeomUnion が削除されてしまう可能性もあります。

そこで、PostGIS 1.3 に付属する SQL 文を調べてみました。具体的には、「<PostgreSQL をインストールしたディレクトリ>\share\contrib\lwpostgis.sql」です。このファイルには、PostGIS の関数などが収められています。そのファイル内で、ST_Union や GeomUnion の集約関数の定義を探すと、次のように見つかりました。

-- Deprecation in 1.2.3
CREATE AGGREGATE GeomUnion (
    sfunc = geom_accum,
    basetype = geometry,
    type = geometry[],
    finalfunc = ST_unite_garray
    );

-- Availability: 1.2.2
CREATE AGGREGATE ST_Union (
    sfunc = ST_geom_accum,
    basetype = geometry,
    stype = geometry[],
    finalfunc = ST_unite_garray
    );

この定義を見ると、きちんと定義されているようです。しかも、定義の内容も GeomUnion と ST_Union とでまったく同じです。

そのため、上の ST_Union の定義を実行することで問題が解決しました。

（；^ω^）おそらくインストールの仕方が悪かったのだと思いますが、根本の原因はいまだに不明です。とりあえずの対処療法です。

category: Java
DATE : 2007/11/28 (Wed)

読み込んだ画像がインデックスカラーかどうかを判断するには

ImageIO などで読み込んだ画像がインデックスカラーかどうかを判断するには、その画像のカラーモデルのインスタンスが java.awt.image.IndexColorModel かどうかを判断するだけで分かります。

例えば、java.awt.image.BufferedImage の画像 image がインデックスカラーかどうかを判断するには、次のようにします。（import 文などは省略しています）

if ( image.getColorModel() instanceof IndexColorModel ) {
    // image はインデックスカラー
}

（；^ω^）ImageIO を使った場合、読み込んだ画像のカラーモデルが自動的に設定されるので非常に便利です。

<< 前のページ｜｜次のページ >>

忍者ブログ [PR]

みかん箱

Twitter

Twitter