オープンソースGISデータストアについて

作成者:hagihara_takayuki 作成日:金, 07/08/2016 - 15:58

オープンソースGISデータベース管理システム

オープンソースのRDBMSと言えば、まずMySQLが頭に浮かび、その次にPostgreSQLが上がるだろう。PostgreSQLはオープンソースでない拡張をして販売することも可能なライセンス体系を有しているので本格的なシステムでOracleの代替を商売にしている拡張ソフトも存在する。

地理空間情報処理の観点で見るとPostgreSQLそのものはgeoJSONを扱う機能がなく、MySQLにはその機能が含まれている。一方で、PostgreSQLの拡張機能であるPostGISはOGC準拠（ただし0.9時代）で、MySQLは一部実装でしかない。参照した「何が違うのか?PostGISと最新版MySQLのGIS機能を徹底比較」にあるようにST_Unionが無いなど、DBMS側で処理できない機能要素がある。また、一定の知識を持っていれば、PostGISの方が高速に処理ができるようで、かなり強力である。

ちなみに、著名な商用DBMSでは、SAP HANAのみがOGCのSimple Features - SQL - Types and Functions 1.2.1の認証を受けている。LuciadやESRI製品をフロントエンドとした地理空間情報アプリが既にいくつも作成されている。

商用製品とオープンソースのそれぞれで一定のレベルの実装が行われ、ハイエンドから予算の限られた研究用途まで利用可能な状況はかなり整ってきたと考えてよい。安価な環境でも相当な事ができることを示したプレゼンテーションとしては、「地理空間とOSGeoとPostGISとを簡単に紹介してみます」が参考になる。

利用者視点で見た地理空間情報処理のアーキテクチャー

災害対策の観点でも、ナビゲーションアプリでも、マーケット分析アプリでも、地理空間情報処理は、通常単一のデータソースだけでは魅力が薄い。公共交通機関が有している情報や、工事情報、気象情報や、入店情報、あるいは社員や会員が所有するスマホ等のGPSデバイスからの時刻付き地理空間情報を用途に合わせて組み合わせる事で様々な付加価値を生むのである。

そういう特性から考えるとサービスを提供する組織は、複数の組織からのデータソースを統合する事ができなければならない。技術面、契約面、課金体系、ライセンス等の課題を解消して初めてサービスを提供することができるようになる。複雑な構成管理は不可欠で、組織がデータを全部取り込んで処理する方式は管理を容易にするが、データを預ける形態が常に妥当であるとは言えない。データの権利者がデータストアとその参照・更新の権限を管理し、統合サービスの提供者がユーザー体験とデータソースとのやり取りを統括し、場合によっては複数の統合サービスを併用するフロントエンドアプリが商売になる可能性もある。概ね3層アーキテクチャで考えて良いだろう。一つの組織がデータを預かって全ての層に責任を持つケースもあるし、複数組織の連携で実現するケースもあるだろうが、技術的には3層構造で考えておくのが得策である。

地理空間情報処理で3層構造を考えると、

  1. 表示層でhtml5ベースでWebGL準拠のアプリケーション能力がある
  2. 処理層に4D処理のエンジンが利用可能
  3. データストアがOGCのSimple Featuresに準拠または相当の能力を有している

が望ましい要件のように感じられる。

アーキテクチャ上の課題

Webベースでアクセスするユーザーの観点に立つと、背景となるラスターデータの扱いが問題となる。用途によってライセンスの問題が起きるので、ユーザーの権利に基づいて、人によってはゼンリンのデータを使い、人によってはオープンストリートマップを提供すると言った構成を検討する必要があるだろう。オープンソースでどこまでできそうかを検討した発表としては、上述の「地理空間とOSGeoとPostGISとを簡単に紹介してみます」が参考になる。

ベクターデータの扱いももちろん易しくない。空間を限定してPostGISにクエリーを出したとしても取り出されるgetJSONが膨大になる可能性がある。クライアントにOpenLayersを使った場合にはデータ量が多くなると困るだろう。中間層との役割分担も重要な論点となるだろう。

Luciad製品の優位性

Luciadは表示層で、Luciad Lightspeed、Luciad RIA、Luciad Mobileという3つの製品を提供している。PCやUnixアプリであればLightspeed、ブラウザアプリケーションとしてはRIA、アンドロイドアプリとしてはMobileがソリューションとなる。

中間層は、Luciad LightspeedとLuciad Fusionがある。Lightspeedは4D処理のきわめて強力なエンジン（ソフトウェアライブラリ）でFusionはラスターデータ管理を中心に優れた統合機能を有している。

データストア層は、Fusionが地理空間情報に固有なラスターデータ管理で優れた機能を有しているが、DBMS機能は保有していない。一方で、中間層のLightspeedはSAP HANAはもちろんDB2 Spatial and GeodeticやオープンソースのPostgreSQLのコネクターも提供している。

研究用に可能な限り無償ソフトを使うとすれば、OpenLayersまたはCesiumでフロントエンドを作成し、ラスターデータのハンドリングを含む中間層はQGISを用いれば良さそうで、バックエンドはPostGIS(postgreSQL)が適当だろう。動きの無いデータはQGISで作成してPostGISに保管すれば良い。

一方で、ミッションクリティカルなアプリケーションであれば、フロントエンドはオープンソースはまだまだ未熟で、Luciad製品は機能面の成熟度の高さもあるが、サポート特にバージョンアップ互換性サポートが重要である。

データストアに関しては、SAP HANAは恐らく最も信頼できるコンポーネントになるだろうが、恐らく混合型のニーズを満たさなければ本格的なサービスを構築することはできない。専門データソースを有する組織は、大抵のケースで、その組織で管理するPostGISのインスタンスを限定公開する程度で十分であろう。

つまり、キーとなるのは中間層で、この部分はLuciadの旗艦製品であるLightspeed(およびFusion)が輝きを放つ。オープンアーキテクチャで任意のgeoJSONを求めるクライアントに対応することができる事はもちろん、データストア層への対応力も非常に高い。中間層アプリケーションを作成する際に必要な座標計算処理のライブラリーの充実度が効く。

おわりに

スマホの普及とプラットホームの成熟に従い、今後リアルタイム地理空間情報システムがいくつも立ち上がっていくだろう。Uberはその一つの事例である。ポータルとなるアプリの覇権争いは必至でその動向は目立つが、一方でインフラを構成するサービスも多く出現するだろう。中間層アプリでは、複数のデータソースを分析して、新たなデータソースを生成するタイプのサービスがでる。人の動きと入店情報や空席情報、割引サービスなどをマッチングさせるサービスは中間層で行われ、そこから生成された新たなデータストリームが複数のポータルに供給される事になるだろう。

そろそろ、この分野の市場の窓が開くのではないかと考えている。