PostGIS に規約を導入してみる

PostGIS における規約について意識してみます。

私はどのようにしてRDBMSの嫌さを克服しつつあるか

稼働サービスの裏に直接 PostGIS がある構成には贅沢さと脆弱さが潜むと考えますが、話題をサービスではなくてプロセッシングに限れば、PostGIS は素晴らしい処理系だと思います。

私は、RDBMS でデータを扱う場合に、テーブルの設計がプログラムに乗らなかったり、処理結果がファイルシステム上ではっきりと見えなかったり、複数の処理でデータベースが成長していくので一連の処理の再現が難しかったり（データベースが絡んだ場合のテストの困難性と同根の問題？）、特定のステップでのデータ処理の失敗が取り返し困難（「サヨナラボーク」）であったりする点が嫌いでした。本当はプログラムに書いちゃいけないパスワードの存在も精神的障壁となりました（実際にはローカルで処理しているだけなのに）。そのため、geotools.rb を使って、Shapefile を UNIX の IO ストリームの処理に近い方法で取り扱うのを好んでいました。

しかし、geotools.rb を使うのと比べ、PostGIS に ruby-postgres を組み合わせる方法には、プログラムの記述が簡潔になる他、日本語の処理が安定しているなどの利点もあります。QGIS で直接 PostGIS データを扱えるなどの進展もあり、いま地理空間情報のプロセッシングを行うなら、PostGIS を使うのはとても良い選択だと思います。（複雑な幾何処理になったときだけ、WKBHEX 表記を媒介して JTS Topology Suite を使えば良く、その場合 JTS の設計が素直なため、定数の問題がなくなって rjb (Ruby Java Bridge) で全ての処理を実施できるはずです。）

そのため、私は次のような工夫をして RBDMS 嫌いを克服しつつあります。

• テーブル作成するためのSQL文は、Evernote に下書きするようにし、テーブル作成後その下書きがいつでも見れるようにしました。これで、テーブル作成処理の再現性を確保し精神衛生を向上しました。
• ユーザ名やパスワードは規約として公開することにしました。Shapefile で処理をしている場合、計算機を守ることでデータを守りますが、PostGIS の場合にも、データの防護は計算機を守ることで実施することにし、PostgreSQL のユーザ名やパスワードには防護の役割を持たせないことにしました。
• テーブル名にも標準的なものを決め込むことにしました。

その他の問題については、まだ克服できていませんが、ひょっとするとファイルシステム的に一時テーブルを多用していくなどの工夫をしていくのかもしれません。

規約重要

Ruby の影響を受けている者として、名前重要というか、下手に設定の自由度を自由のままに残しておくよりも規約してしまうことで精神衛生を確保することは大事だと思っており、PostGIS の扱いで出てくる設定項目に規約を設けることで本質できでない思考を節約しようと思っています。そこで、次の規約を導入します。

• Radiohead の Fitter Happier の歌詞にちなんで、地理空間情報を扱うデータベース名・ユーザ名・パスワードは fitter, happier, more_productive にする。
• 地理空間情報のテーブル名に規約を導入する。例えば基盤地図情報の道路縁であれば、gsi_fgd_rdedg と決める。決めたものをある程度公開することが重要と思っています。

標準化未満の規約の影響力は現在とても高いと感じています。EPSG:900913 など、もともと洒落のようなネーミング（900913 は GOOGLE）によるカジュアルな約束事で、正規の規格ではない規約の一種なのに、この規約が存在していることで世界中でいろいろな人の手間が省略されているはずです。

そういったものを、これからあとで書くことにしたいと考えています。

OK コンピューター