2. 導入

2.1. 空間データベースとは?

PostGISは空間データベースです。Oracle SpatialやSQL Server (2008以降)も空間データベースです。これはどういう意味でしょうか?通常のデータベースを空間データベースにするにはどうすればいいでしょうか?

短い答えとしては...

空間データベースは空間オブジェクトを、データベース内の他のオブジェクトのように格納して操作するものです。

ここでは、空間データベースの進化について簡単に説明し、データタイプ、インデックス、関数という*空間*データをデータベースに関連づける三つの側面を見ていきます。

  1. **空間データタイプ**はポイント、ライン、ポリゴンといった形状を指します。

  2. 多次元**空間インデックス**は空間演算の効率的な処理に使用されます。

  3. **空間関数**は SQL で示されていますが、空間プロパティと空間関係に関するクエリに使われます。

空間データタイプ、インデックス、関数を組み合わせることで、能率と解析の最適化のための柔軟な構造が得られます。

2.1.1. はじめに

従来の第1世代の GIS 実装では、全ての空間データがフラットなファイルに格納され、データの解釈と操作に、専用の GIS ソフトウェアが必要です。これらの第1世代の管理システムはユーザのニーズに合わせたデザインになっていて、全ての求められるデータがユーザの組織の内部にありました。これらはプロプライエタリで、空間データを処理するために作られた自己完結型システムです。

第2世代の空間システムはリレーショナルデータベース (通常は「属性」または非空間部)内のデータを格納しますが、直接統合するだけの柔軟性はありませんでした。

空間の地物を第一級データベースオブジェクトとして扱うようになった時に真の空間データベースが生まれました。

空間データベースは完全に空間データをリレーショナルデータベースに統合します。システムの方向性がGIS中心からデータベース中手に変わります。

_images/beginning.png

注釈

空間データベース管理システムは地理世界以外のアプリケーションでも使われることがあります。空間データベースは人体解剖、大規模集積回路、分子構造、電磁場等に関連するデータを管理するために使用されます。

2.1.2. 空間データタイプ

通常のデータベースは文字列、数字、日付を持ちます。空間データベースでは、追加的な**地理フィーチャー**タイプを表現する空間タイプが追加されています。

_images/hierarchy.png

空間データ型は階層構造をなしています。各サブタイプは、スーパタイプの構造 (属性)と振る舞い (メソッドや関数)を継承します。

2.1.3. 空間インデックスとバウンディングボックス

通常のデータベースは、データの部分集合に対する高速かつランダムなアクセスのために**インデックス**を提供します。標準の型 (数値、文字列、日付)のインデックスには、 B木 が使われます。

B木は、階層木にデータを入れるために自然な並び替え順序を使用してデータを区分けします。数値、文字列、日付の自然な並び順は簡単に決まります。ある値が、他の値と比較して、小さいか、大きいか、同じか、を見ます。

しかし、ポリゴンは他のポリゴンにオーバラップすることや、包含することがありますし、2次元 (以上) の空間に配列されます。このため、効率的なインデックスとしてはB木は使えません。実際の空間データベースでは、B木に代わって「指定したバウンディングボックス内にあるオブジェクトはどれか」という質問に答える「空間インデックス」が提供されます。

**バウンディングボックス**は、座標軸に平行で、指定された地物を含むことができる最小の長方形です。

_images/boundingbox.png

「AはBの内側にあるか?」という質問に対する計算は、ポリゴンを使う場合には計算負荷が非常に高くなり、長方形の場合には非常に速い処理になるため、バウンディングボックスが使われます。最も複雑なポリゴンとラインストリングでも、簡単な長方形で表現できます。

インデックスは、役に立たせるためには迅速な処理が必要です。空間インデックスはB木で行っているような正確な結果を提供する代わりに、おおよその答えを出します。「どの線がこのポリゴンの内側にあるか?」という問いは、空間インデックスでは「どのラインのバウンディングボックスがポリゴンのバウンディングボックスの内側にあるか?」に解釈されます。

空間インデックスの実装はデータベースシステムによって大きく異なります。最も一般的な実装は`R木 <https://ja.wikipedia.org/wiki/R%E6%9C%A8>`_ と `四分木<https://ja.wikipedia.org/wiki/%E5%9B%9B%E5%88%86%E6%9C%A8>`_ です (PostGISで使われています)。しかし、他の空間データベースシステムでは`grid-based indexes <http://en.wikipedia.org/wiki/Grid_(spatial_index)>`_ と ジオハッシュ の実装もあります。

2.1.4. 空間関数

クエリ中のデータ操作のために、通常のデータベースは、文字列結合、文字列のハッシュ演算、数値計算、日付からの情報展開等を行う**関数**を提供します。

空間データベースは、ジオメトリ要素の解析、空間関係の計算、ジオメトリ操作に使う関数の完全なセットを提供します。これらの空間関数は、空間プロジェクトの構成要素として機能します。

全ての空間関数は次の5個のカテゴリのいずれかに入ります:

  1. 変換: ジオメトリの外部データフォーマットとの*変換*を担う関数。

  2. 管理: 空間テーブルとPostGISシステムの*管理*を担う関数。

  3. 検索: 属性やジオメトリの測定の*検索*を担う関数。

  4. 比較: 空間関係に関する二つのジオメトリの*比較*を担う関数。

  5. 生成: 他からの新しいジオメトリの*生成*を担う関数。

考えられる関数を一覧にすると非常に大きいですが、一般的な関数のセットは:term:OGC :term:`SFSQL`で定義されていて、PostGISで (便利な追加関数とともに) 実装されています。

2.2. PostGISとは?

PostGISは PostgreSQL データベース管理システムに、空間型、空間インデックス、空間関数の三つを追加することで、空間データベースに変えるものです。PostGISは、PostgreSQL上で構築されているので、重要な「エンタープライズ」機能と実装のオープン標準を自動的に継承します。

2.2.1. ではPostgreSQLとは?

PostgreSQLは強力な関係データベース管理システム (RDBMS) です。BSDスタイルライセンスでリリースされていて、よって、無償のオープンソースソフトウェアです。多数のオープンソースプログラムと同じで、PostgreSQLは単一の企業に制御されてはいません。開発者のグローバルコミュニティ と複数の開発企業とがあります。

PostgreSQL は、型の拡張を念頭に置いてデザインされたので、新しいデータ型、関数、インデックスを実行時に追加する能力を持っています。このため、PostGIS エクステンションは別の開発チームが開発することができるのに、PostgreSQL データベースに非常に緊密に統合できます。

2.2.1.1. なぜ PostgreSQL を選んだのですか?

オープンソースデータベースに精通している人々からのよくある質問に「なぜ PostGIS は MySQL で作らなかったのか?」があります。

PostgreSQL は次の機能を持っています:

  • 証明されたデフォルトの信頼性とトランザクション完全性 (ACID)

  • SQL標準 (完全なSQL92) の慎重な対応

  • 入れ替え可能な型拡張と関数拡張

  • コミュニティ指向の開発モデル

  • 大きな GIS オブジェクトに対応するために必要なカラムサイズ無制限 ("TOAST"可能なタプル) 機能

  • R木インデックスを可能にした一般性のあるインデックス構造 (GiST)

  • カスタム関数の追加が容易

あわせて、PostgreSQLは新しい空間型を追加するための非常に簡単な開発パスを提供してくれます。プロプライエタリの世界では Illustra (現在の Informix Universal Server) だけがこのような簡単なエクステンションが可能でした。これは決して偶然ではありません。Illustra は、1980年代からオリジナルの PostgreSQL コードベースから作り直したプロプライエタリです。

PostgreSQL への型の追加の開発順路が非常に素直だったので、ここから開始するのは意味のある事です。MySQL が 4.1版で基本的な空間型をリリースした時に、PostGIS チームはコードを見て、前に PostgreSQL を使用した決断を補強しました。

MySQL 空間オブジェクトは文字列型の先頭を特別に扱う必要がありました。このため、MySQLコードはコードベース全体に及びました。PostGIS 0,1の開発は1ヶ月とかかりませんでした。"MyGIS" 0.1を開発しようとしていたなら、もっと長い時間が必要になり、日の目を見なかったかも知れません。

2.2.2. なぜファイルではないのですか?

GIS ソフトウェアが最初に書かれた時から、Shapefile (と Esri File Geodatabase や GeoPackage のような他のフォーマット) は、空間データの格納と使用の標準的な手法であり続けました。しかしながら、これらの「平坦な」ファイルは次の欠点を持ちます:

  • ファイルは読み書きに特別なソフトウェアを必要とします SQLはランダムデータアクセスや分析のための抽象化です。この抽象化が無い場合には、全てのアクセスと分析のコードを自身で書く必要があります。

  • 複数ユーザの同時利用は破損と速度低下を引き起こす可能性があります。同一ファイルへの複数書き込みがデータ破損を起こさないことを保証するよう外部コードを書くことができますが、こういった問題解決と関連する効率上の問題を解決するまでの時間で、データベースシステムの大部分を書くことができます。標準データベースを使用することをお勧めします。

  • 複雑な質問に答えるには複雑なソフトウェアが必要です。データベース内の1行のSQLで表現できる、複雑で興味深い質問 (空間結合、集約など) は、ファイルに対するプログラムを書く時は、答えるのに数百行の特別なコードを必要とします。

ほとんどの PostGIS ユーザは複数アプリケーションがデータにアクセスすることを期待するシステムをセットアップしているので、標準 SQL アクセス方法を持つことで、配備と開発を単純化できます。大きなデータセットで作業を行うユーザは、ファイルを使う場合には複数ファイルに分割することになるかも知れませんが、データベースでは単一の巨大テーブルとして保存することができます。

要約すると、複数ユーザ、複雑なアドホッククエリ、大きなデータセットのパフォーマンスに関する対応の組合せによって、空間データベースをファイルベースのシステムから分離することができます。

2.2.3. PostGIS の歴史

2001年5月、Refractions Research は PostGIS の最初のバージョンをリリースしました。PostGIS 0.1 は、オブジェクト、インデックス、少数の関数がありました。データベースは保存と検索には適切ですが、解析には不向きだとの結果でした。

関数の数が増えるにつれ、組織化の原理の必要性が明らかになりました。Open Geospatial Consortium から出ている "Simple Features for SQL" (SFSQL) 仕様は、関数命名と要件に関するガイドラインとともに、この構造を提供しました。

PostGIS の単純な解析と空間結合への対応で Mapserver は、データベース内のデータの可視化機能を提供する最初の外部アプリケーションになりました。

次の数年間で PostGIS 関数の数は増えましたが、その能力は制限されたままでした。最も興味深い関数の多数 (例えば ST_Intersects(), ST_Buffer(), ST_Union()) は、コーディングが非常に難しいものでした。それらを最初から書くには何年もの仕事が必要となりました。

幸運なことに、二つ目のプロジェクトの「Geometry Engine, Open Source」あるいは GEOS が登場しました。GEOS ライブラリは、SFSQL 仕様を実装するために必要なアルゴリズムを提供します。GEOS をリンクすることで PostGIS は 0.8 までに、SFSQL の完全な対応ができるようになりました。

PostGIS データ容量が増加するにつれ、他の問題が表面化しました。ジオメトリ保存に使われる表現では比較的非効率です。ポイントや短いラインストリングのように小さいオブジェクトでは、表現のメタデータには300% のオーバヘッドがあります。効率性のため、表現をダイエットする必要がありました。メタデータヘッダと求めらえれる次元の収縮によって、オーバヘッドは非常に減収します。PostGIS 1.0 では、新しく、速く、軽い表現がデフォルトになりました。

PostGIS の最近のリリースでは、PostgreSQL コアシステム内の新機能対応だけでなく、機能追加と性能改善の追加を継続しています。

2.2.4. PostGIS を使用するのは誰ですか?

ケーススタディの完全なリストについては PostGIS case studies ページをご覧下さい。

2.2.4.1. フランス IGN (Institut Geographique National)

IGNはフランスの地図作成機関で、PostGIS を国の高解像度地形図 "BDUni" の保存に使用しています。BDUniには1億を超える地物があり、観測を検証し、データベースに新しい地図を毎日追加する 100人以上の現地作業員によって維持されています。IGNの設備は、データベーストランザクションシステムを使用して更新処理中の一貫性を確保し、また 温待機システム を使用してシステム障害が発生した場合でも稼働するようにしています。

2.2.4.2. RedFin

RedFin は実在する不動産会社で、不動産の探索や価格の見積もりを行うウェブベースのサービスを提供しています。この会社のシステムは元はMySQLベースで作られていましたが、PostgreSQLとPostGISへの移行で`効率と信頼性の利益が大きい <https://www.redfin.com/news/elephant_versus_dolphin_which_is_faster_which_is_smarter/>`_ ことが分かりました。

2.2.5. PostGISに対応したアプリケーションはどれですか?

PostGISは空間データベースとして広く使われ、PostGISを使った格納と検索に対応するサードパーティのプログラムも非常に増加しました。programs that support PostGIS には、オープンソースとプロプライエタリの両方、かつサーバとデスクトップの両方のソフトウェアの一覧があります。

次にPostGISを利用するソフトウェアの一覧を示します:

オープン/フリー

クローズ/プロプライエタリ/有料サービス

  • ロード/抽出

    • Shp2Pgsql

    • ogr2ogr

    • Dxf2PostGIS

    • GeoKettle

  • ウェブベース

    • Mapserver

    • GeoServer /geoNode

    • pg_tileserv

    • pg_featureserv

    • Deegree

    • Carto

    • QGIS Server

    • MapGuide Open Source (FDO使用)

  • デスクトップ

    • QGIS

    • OpenJUMP

    • GRASS

    • pgAdmin

    • DBeaver

    • GvSIG

    • SAGA

    • uDig

  • ロード/抽出

    • Safe FME Desktop Translator/Converter

    • Dbt

  • ウェブベース

    • Cadcorp GeognoSIS

    • ESRI ArcGIS Server / Online

  • Services / DbaaS

    • Aiven for PostgreSQL

    • Amazon RDS / Aurora for PostgreSQL

    • Carto

    • Crunchy Bridge

    • Microsoft Azure for PostgreSQL

    • Google Cloud SQL for PostgreSQL

  • デスクトップ

    • Cadcorp SIS

    • ESRI Desktop/Pro

    • GeoConcept

    • Global Mapper

    • Manifold

    • MapInfo

    • Microimages TNTmips GIS