GISソフトウェアとしての地位を確立したQGIS
今回の目的は、私のところのような小さなエンジニアリング企画事務所においてQGISが商用GISソフトウェアの補完または代替品としてどの程度使えるかを評価することだった。GISソフトウェアは分析ツールとしても地図作成ツールとしても欠かせないが、非常に高価だ。とてもではないが、事務所にいるプランナー全員にGISソフトウェアのライセンスを揃える経済的余裕はない。近年、利用頻度の高いプロプライエタリソフトウェアの代替品となりうる無料または安価なFOSSソフトウェアがかなり注目を集めている。FOSSであるQGISにかかるコストは、たとえ有償サポートを受けたとしても、同等のプロプライエタリ製品に比べると著しく低い。
QGISのビルド
QGISのダウンロードページには、CentOS 5、Gentoo、Ubuntu GutsyおよびHardy、Fedora 8および9、openSUSE 10.3および11用の各バイナリの一覧が用意されている。もちろん、ソースコードもダウンロードできる。Slackwareユーザの私はこちらをダウンロードした。
入手は簡単なQGISだが、ビルドはそうはいかない。事実、QGISはこれまで私がビルドしたなかでは最も複雑なソフトウェアだった。その大きな理由は、QGIS本体のコンパイル前にビルドが必要な依存関係モジュールの多さにある。オプションのパッケージといえども、実際には必要なものと思っておいたほうがよい。それらがないと、有力なQGISプラグインは動作しないからだ。また、UbuntuやopenSUSEにあるような自動でパッケージを処理してくれる機能を利用している場合も、念のためにパッケージ管理システムによってすべてのインストールが正しく行われたことを確認すべきだろう。ビルドをさらに困難にしているのは、ソースコードに付属するLinux向けのビルド手順がUbuntuにしか対応していないことだ。もっと広い範囲をカバーした手順になっているとありがたい。
依存関係にある大半のパッケージは、src2pkgと、Slackbuilds.orgにあるslackbuildスクリプトを使ってビルドした。Slacky.euからも、必要なパッケージのほぼすべてがバイナリやslackbuildスクリプト付きのソースコードとして入手できる。ただし、それらのバイナリを手に入れても、解決されない依存関係が残るため、依存関係のあるモジュール群を注意して適切な順序でビルドする必要がある。
こうした準備作業がすべて完了したら、いよいよQGISのビルドとインストールに入る。現時点でSlacky.euから入手できるのは、QGIS 0.10.0（1つ前のバージョン）のバイナリとslackbuildスクリプト付きのソースコードである。今回は、ダウンロードしたslackbuildスクリプトのバージョン番号を修正することで、最新版であるQGIS 0.11.0のビルドを行った。ビルドしたパッケージのインストールと動作確認は何の問題もなく済んだ。
機能とパフォーマンス
インストールしたQGISの動作は、満足のいくものだった。インタフェースはすっきりしていて、論理的に配置されたツールバーやアイコンの使い方もおおよそ理解できる。基本的なタスクなら難なくこなせるはずだ。また、ESRIのshapeファイルを問題なくインポートできたほか、TIFF形式のラスタファイルのインポートや表示もできた（ただし、MrSID形式のラスタファイルはインポートできなかった）。レイヤのプロパティを変更すれば期待どおりの効果が得られ、透明度の設定など、シンボロジ（レイヤの各種属性の表示方法）の変更も比較的容易だった。さらに、あるレイヤ上で適切に設定したシンボロジは、スタイルとして保存することでほかのレイヤに適用できる。
QGISの機能の大部分は、プラグインとして提供される。公式リポジトリには、ジオプロセシング（データレイヤの操作）、フィーチャのバッファリング、属性によるレイヤ内フィーチャの選択など、GISの基本タスクの多くを扱ったプラグインが用意されている。なお、（ジオプロセシングのような）多数の基本機能は、PostgreSQLデータベースにインポートされたデータレイヤでしか利用できない。サードパーティ製のプラグインは、QGISのWikiページに記載のリポジトリから多くのものが入手できる。私が特に気に入ったのは、Carson Farmer氏のリポジトリ（上記Wikiページの2番目に載っているもの）にあるプラグイン群だ。とりわけ便利なものとして、プロジェクションの管理、属性の結合、属性の空間結合、重心の生成、ジオメトリの計算といったプラグインがある。最後のプラグインは、フィーチャの長さや面積の算出といったGISで最も一般的なタスクの実行に用いる。
QGISにはいくつかの問題があるほか、少なくとも1つ欠如している機能がある。問題の1つは、試行錯誤なしにはラベルをうまく配置できないことだ。これは、ラベルのダイアログボックス上にある各種オプションがラベルの配置、位置調整、外観にどう影響するかがわかりにくいためである。また、属性によるフィーチャ選択は不自然な動作をする。属性で検索をかけると、該当するフィーチャが地図上と属性テーブル内で強調表示される。ところが、選択したフィーチャだけを属性テーブルに表示するには、属性テーブル内でクエリを再実行しないといけない。さらに、新たにインポートしたshapeファイルは、QGISでエクスポートし直してから地図に追加しないと編集できない。
欠けている機能というのは、あるレイヤから別のレイヤのフィーチャ内にあるフィーチャ（共通領域など）を選択するという、場所による選択機能である。たとえば、特定の郡区内にあるすべての州間高速道路を選択する場合がこれにあたる。こうした機能は、QGISにはまったくないようだ（マニュアルにもプラグインリポジトリにも見当たらなかった）。しかし、GISで十分なデータ分析を行うには重要な機能である。多くの人にとってGISは地図を作成するためのものだが、GISの本当の価値はデータと地図との対応付けにある。この機能はデータレイヤが1つの場合でも十分に有効だが、複数のレイヤを結合してさまざなデータレイヤの関係を空間的に示す場合に効果を発揮することがある。単純にいえば、GISシステムは、各レイヤをテーブルとし、テーブル間の関係をデータの地理的な位置に対応させたデータベースである。そのため、場所による選択の機能は、レイヤ間の関係を扱ううえで欠かせない。
まとめと要望
QGISは相当な力を秘めているが、プロプライエタリなGISソフトウェアを置き換えるという私の事務所のニーズには十分に適合していない。場所による選択の機能がないため、私たちが行っているような分析の作業にはあまり使えない。しかも、根底にあるデータベースエンジンはPostgreSQLである。PostgreSQLは、独自仕様で業界の主力アプリケーションになっている。このデータベースでは、管理者がセットアップを行い、複数のユーザがいるネットワーク上で実行して使うことが想定されている。これは、ネットワーク環境で作業する場合など、集中管理型のデータリポジトリを構築する場合に有利である。その反面、ネットワーク化されたデータベースをきちんと管理するにはそれなりの時間をとられる。そのため、シングルユーザ環境の場合、PostgreSQLはかなりのオーバースペックといえる。
いずれにせよ、事務所のメンバーたちが新しいインタフェースの操作を覚えるのをいとわなければ、QGISはプロプライエタリのGISソフトウェアを補完するものとして十分に使えただろう。shapeファイルが簡単に読めるという利点を活かし、効果的なプラグインを注意深く選べば、データの読み取りや操作を行うための優れたアプリケーションになるはずだ。
バージョン番号から察するに、QGISの開発チームは今後もまだまだ多くの取り組みを予定しているようだ。私としては、開発チームに次のような機能の追加を検討してもらいたい。
- MrSIDラスタファイルのインポート機能
- 場所による選択の機能
- 個人向けのジオデータベース（できればPostgreSQLの代わりにOpenOffice.org Baseのデータベースを利用したもの）
ビルドが難しく、重要な機能の欠如も見られるが、QGISはプロプライエタリなGISソフトウェアの代替となる強力なFOSSである。QGISのダウンロードとインストールを行い、ニーズに合うかどうかを確認することをお勧めする。私自身は、QGISの動向に注意しながら今後の改良に期待している。
Drew Amesはペンシルバニア州ハリスバーグの輸送プランナー。
