新しい任意変数use_typemodをfalseにします。false);古い制約を基にした手法は現在も対応していますが、制約を基にしたジオメトリカラムで直接的にビューで使われている場合は、型修飾子のようには正しくgeometry_columnsに登録されません。次の例では、型修飾子を使ったカラム定義と、制約に基づくカラムの定義とを行っています。false);psqlで次を実行します。pois_ny;型修飾子と制約に基づくのとでは異なった定義になっているのが見えます。2160)geometry_columnsでは、両方とも正しく登録されています。POINTしかし、次のようにビューを作ろうとします。'vw_pois_ny_parks';型修飾子によるgeomのビューカラムは正しく登録されますが、制約に基づくものは正しく登録されません。GEOMETRYこれは、将来的にPostGISの版で変更されるかもしれませんが、今のところは、制約に基づくビューカラムを正しく登録させるには、次のようにします。(OGC)のOpenGIS仕様に準拠しています。(正確に言うとそう仮定します)。ポリゴンの外に穴があるようなものの面積を計算したり、単純でない境界線を持つポリゴンを作ったりするのは、意味がありません。OGS仕様に沿うと、単純なジオメトリとは、自己インタセクトや自己接触のような、異常な幾何点を持たないことです。[MULTI]LINESTRING))に適用します。([MULTI]POLYGON)に適用し、妥当なポリゴンを特徴づける位置指定子の集合を定義します。個々のジオメトリクラスには、単純性と妥当性をさらに詳細に述べる特定の条件があります。POINTは0次元ジオメトリオブジェクトとして常に単純です。(POINT)が同じでないなら単純です。この場合は線型環と呼ばれ、さらに言うと閉じていると思われます)なら単純です。(a)(b)(c)(d)(a)と(c)は単純なLINESTRINGです。(b)と(d)は単純ではありません。全ての要素が単純で、かつ任意の2要素のインタセクトが要素の境界であるPOINTでだけ発生する場合に限って単純です。(e)(f)(g)(e)と(f)は単純なMULTILINESTRINGです。(g)は単純ではありません。定義からPOLYGONは常に単純です。(外環と内環からなる)のうち二つがクロスしていないなら妥当です。(すなわち線上にない)。POLYGONはカットラインまたはスパイクを持たなくても良く、内環は外環の中に完全に含まれていなければなりません。(h)(i)(j)(k)(l)(m)(h)と(i)は妥当なPOLYGONです。(jからm)は単一のPOLYGONとしては表現できませんが、(j)と(m)は妥当なMULTIPOLYGONとして表現できます。MULTIPOLYGONは、全ての要素が妥当で、二つのポリゴン要素について内側がインタセクトしていない場合は妥当です。ポリゴン要素の任意の二つの境界は接触してもよいですが、有限な数のPOINTでなければなりません。(n)(o)(p)(n)と(o)は妥当でないMULTIPOLYGONです。GEOSライブラリを使って実装されている関数のほとんどは、ジオメトリがOpenGISシンプルフィーチャー仕様で定義されているように妥当であると仮定しています。ジオメトリが単純であるか、また妥当であるか、のチェックとしてST_IsSimple()とST_IsValid()が使えます。fデフォルトでは、PostGISはジオメトリ入力に関するこの妥当性チェックを適用しません。複雑なジオメトリの妥当性のチェックはCPU時間を多く必要とするためです。データソースが信用できない場合は、手動でこのチェックを強制するための制約を付けることができます。Intersection()がエラーを投げました!」というようなエラーメッセージに遭遇したなら、PostGISまたは使用しているライブラリの中のエラーを発見しました。PostGIS開発者に連絡するべきです。PostGIS関数が妥当である入力ジオメトリから妥当でないジオメトリが返る場合も同じです。厳格にOGCジオメトリに準拠すると、Z値やM値を持てません。ST_IsValid()は高次を考慮に入れません。AddGeometryColumn()を実行するとジオメトリの次元をチェックする制約が加わるので、そこで2を指定すれば十分です。Modelまたは略してDE-9IMを見てみましょう。...)は、求められる空間フィルタを適切に提供するには十分でないことが時々あります。道路網を表現する線型のデータセットがあるとします。ビジネスルールを無視しているかも知れませんが、点で交差するだけでなく線上で交差する道路区間を全て判別することがGIS解析者の仕事となるかも知れません。???では重要な空間フィルタとして十分ではありません。インタセクトより厳しい条件です)している場合のみtrueが返ります。([MULTI]POINTや[MULTI]LINESTRING等からなるGEOMETRYCOLLECTIONが帰ってくる場合にしっかり対応するため)、という2段階の方法で解くことはできます。エレガントかつ速い解法が本当に望ましいでしょう。二つ目の[理論的な]例として、GIS解析者が全ての湖の境界に線でインタセクトする波止場やドックの全ての位置を特定しようとするとします。ここで、波止場の一端だけ陸にあるとします。言いかえると、波止場が湖の中にあるが完全に中に入りきってはいなくて、湖と線でインタセクトして、波止場の一方の端が完全に湖に入っていて、かつもう一方の端点が境界線上にあります。解析者は空間述語の組み合わせで、非常に望まれるフィーチャーを引き出す必要があるかも知れません。Mode、略してDE-9IMを見てみましょう。SQLによると「二つのジオメトリの比較の基本的なアプローチは、二つのジオメトリの内部、境界、外部のインタセクションの比較と、『インタセクション行列』の要素に基づく2ジオメトリの関係の分類です」。(Boundary)ジオメトリの境界は一つ低い次元のジオメトリの集合です。0次元のPOINTの境界は空集合です。LINESTRINGの境界は二つの端点です。POLYGONの境界は外環と内環を形成する線です。(Interior)ジオメトリの内部は境界を取り去った際に残るジオメトリです。POINTの内部はPOINT自身です。LINESTRINGの内部は二つの端点の間の実際の点の集合です。POLYGONの内部はポリゴンの内側の範囲であるサーフェスです。(Exterior)ジオメトリの外部は、内部と境界を除いた全領域のサーフェスです。ジオメトリaがあり、aの内部、境界、外部をそれぞれI(a)、B(a)、E(a)とします。数学的な行列表現は次のようになります。)ここで、dim(a)はaの次元で、ST_Dimensionで規定されますが、{0,1,2,T,F,*}の値域を持ちます。何でも良い二つのオーバラップするポリゴンについて可視化すると、次のようになります。2左から右、上から下に読むと、次元行列は'212101212'と表現されます。一つ目の例である、2線が線上でインタセクトする場合の関係行列は'1*1***1**'となります。'1*1***1**');二つ目の例である、一部が湖の水涯線上にある波止場についての関係行列は'102101FF2'となります。'102101FF2');詳細情報ついては、次のページをご覧ください。ESRIシェープファイルローダを使う空間テーブルを作成したら、これでGISデータをデータベースにアップロードする準備ができたことになります。現在、PostGIS/PostgreSQLデータベースにデータをロードするには、SQLステートメントを使う、またはシェープファイルのローダ/ダンパを使う、二つの方法があります。SQLを使ってロードするデータをテキスト表現に変換できるなら、フォーマットされたSQLを使うのがデータをPostGISに入れる最も簡単な方法です。Oracleや他のSQLデータベースを使うように、SQL端末モニタにSQLの"INSERT"ステートメントで一杯になった大きなテキストファイルをパイプで送ることで、大量のデータをロードできます。(たとえばroads.sql)は次のようになるでしょう。Cres');COMMIT;データファイルは、次に示す"psql"というSQL端末モニタを使って、簡単にPostgreSQLにパイプで送ることができます。ESRIシェープファイルローダを使うshp2pgsqlデータローダは、ESRIシェープファイルをPostGIS/PostgreSQLデータベースに、ジオメトリまたはジオグラフィとして挿入するための適切なSQLに変換します。ローダには、次に示すコマンドラインフラグによって区別される、いくつかの操作モードがあります。コマンドラインローダのほとんどのオプションに対応するshp2pgsql-guiグラフィカルユーザインタフェースがあります。一度限りのロードしか行わずスクリプト化しない場合やPostGISに不慣れな方にとって便利になるかもしれません。これはpgAdminIIIのプラグインとして構築することもできます。相互に排他的なオプションです-c新しいテーブルの作成とシェープファイルからのデータの読み込みを行います。これがデフォルトモードです。-aシェープファイルからデータベーステーブルにデータを追加します。複数のファイルをロードするためにこのオプションを使う場合は、これらのファイルは同じ属性と同じデータ型を持つ必要があります。-dシェープファイルにあるデータを持つ新しいテーブルを作成する前にデータベーステーブルを削除します。-pテーブル作成のSQLコードを生成するだけで、実際のデータは追加しません。このモードは、テーブル作成とデータロードとを完全に分けたい場合に使用します。-?ヘルプ画面を表示します。-D出力データにPostgreSQLのダンプ書式を用います。-dと組み合わせて利用します。デフォルトの"insert"によるSQL書式よりも、大変早くロードできます。大きなデータセットではこちらを使用して下さい。[<FROM_SRID>:]<SRID>指定したSRIDでジオメトリデーブルの作成とデータの読み込みを行います。入力シェープファイルが使っているFROM_SRIDの指定が可能で、この場合は対象SRIDに投影変換を行います。FROM_SRIDは-Dと一緒には指定できません。(カラム、スキーマおよび属性)の大文字小文字を保持します。シェープファイルの属性は全て大文字であることに注意して下さい。-i全ての整数を標準の32ビット整数に強制します。DBFヘッダではそれが正当であったとしても、64ビットのbigintを生成しません。-IジオメトリカラムにGiSTインデックスを生成します。a_file_nameで、長いカラム名を10文字のDBFカラム名に対応付けるファイルを指定します。ファイルは、1以上の行を持ちます。各行は空白区切りで二つの名前を持ち、行頭行末に空白を入れません。DBFFIELD2-Sマルチ系ジオメトリの替りに単一ジオメトリを生成します。(たとえば単一の外環でなるMULTIPOLYGONや単一の頂点でなるMULTIPOINT)場合にのみ成功します。<次元>出力ジオメトリが特定の次元を持つよう強制します。4Dの文字列を使います。入力の次元が出力より小さい場合には、出力では0が入ります。入力の次元が大きい場合には、外されます。-w出力書式をWKBでなくWKTにします。精度が低下して、座標変動が発生しうることに注意が必要です。-eトランザクションを使わずに、ステートメントごとに実行するようにします。エラーの元となる不良なジオメトリがいくつか含んでいる時に、大半の良好なデータのロードが可能にするものです。ダンプ書式ではトランザクションを常に使うので、-Dフラグを指定している場合には使えません。(dbfファイル)のエンコーディングを指定します。全てのdbfの属性は指定されたエンコーディングからUTF8に変換されます。UTF8が含まれるようになり、バックエンドはUTF-8からデータベースが内部利用のために設定したエンコーディングに再変換できます。abort=強制終了)を選択します。-nDBFファイルのみインポートします。自動的にこのモードになり、DBFファイルのみロードします。このフラグは、完全なシェープファイル群を持っていて、属性データだけが欲しくてジオメトリが欲しくない時のみ使用します。(経度緯度データが必要です)。<tablespace>新しいテーブルのテーブル空間を指定します。-Xパラメータが使われない場合には、インデックスはデフォルトのテーブル空間を使用します。PostgreSQL文書には、テーブル空間を用いるべき時に関する良い文書があります。<tablespace>新しいテーブルのインデックスで使われるテーブル空間を指定します。主キーインデックスに適用され、-Iが合わせて使われている場合にはGiST空間インデックスにも適用されます。ローダを使って入力ファイルを生成してアップロードするセッション例は次の通りです。roads.sql変換とアップロードはUNIXのパイプを使うと一回で実行できます。ダンパを使うデータは、SQLまたはシェープファイルローダ/ダンパを使ってデータベースから抜き出すことができます。SQLに関する節において、空間テーブルでの比較とクエリを行うために用いることができる演算子のいくつかを議論します。SQLを使ってデータを検索するデータベースからデータを引き出す最も直接的な手段は、次のように、SQLのSELECTクエリを使って返ってくるレコードとカラムの数を減らし、結果のカラムを可読テキストファイルにダンプするやり方です。rows)しかし、返ってくる結果の数を削るために、なんらかの制限をかけることが重要となるときがあるでしょう。属性ベースの制限の場合、非空間テーブルで使う通常の文法と同じSQLを使うだけです。空間ベースの制限の場合、次の演算子が使用可能であり、便利です。ST_Intersectsこの関数は、二つのジオメトリが空間を共有しているかどうかをテストします。=この関数で、二つのジオメトリが幾何的に同一であるかを見ることができます。(これは同じとなります)。2.4より前では、これはジオメトリのボックスでの比較でした。次に、これらの演算子をクエリで使うことができます。SQLコマンドラインからジオメトリとボックスの指定を行うときは、明示的に文字列表現をジオメトリに変換しなければならないことに注意して下さい。312は架空の空間参照系番号で、ここでのデータに合致しています。243242)'::geometry;上のクエリは"ROADS_GEOM"テーブルから、その値と等価である単一のレコードを返します。道路がポリゴンで定義した面を通過するかどうかをチェックするには次のようにします。'SRID=312;POLYGON((...))');最も一般的な空間クエリは「フレームベース」のクエリでしょう。これは、表示するためのデータの価値のある「マップフレーム」を取得するために、データブラウザやウェブマッパのようなクライアントソフトウェアに使われます。"&&"演算子を使うとき、比較フィーチャーをBOX3DかGEOMETRYかに指定することができます。GEOMETRYを指定すると、それのバウンディングボックスが比較に使われます。次に示すクエリのように、フレームにBOX3Dオブジェクトを使います。312を使っていることに注意して下さい。(あるいはクエリによって定義されたもの)をシェープファイルに変換するものです。基本的な文法は次の通りです。<クエリ>コマンドラインオプションは次の通りです。<ファイル名>特定のファイル名に出力を書きこみます。<ホスト>接続先データベースのホスト名。<ポート>接続先データベースのポート。<パスワード>データベースに接続するためのパスワード。<ユーザ名>データベースに接続する際のユーザ名。<ジオメトリカラム>複数のジオメトリカラムを持つテーブルの場合の、シェープファイルの出力に使用するジオメトリカラム。-bバイナリカーソルを使います。これは、実行時間を短くしますが、テーブルの非ジオメトリ属性がテキストへのキャストを持っていない場合には、動作しません。gidフィールドを落としたり、カラム名をエスケープしてはいけません。識別名を10文字名に再割り当てします。ファイルの中身は、一つの空白で区切られ、前と後に空白が無い二つのシンボルの行からなります。SHORTER等となります。インデックスを使うインデックスは大きなデータセットを持つ空間データベースの利用を可能にするものです。インデックスなしでは、地物の検索でデータベースの全レコードを「シーケンシャルスキャン」する必要があります。インデックスをつけることで、データを検索木に組織化して、特定のレコードを発見するための検索をより早くすることができます。PostgreSQLは、B木、SP-GiST、GiSTの3種類のインデックスにデフォルトで対応しています。いった、一つの軸に沿ってソートできるデータに使用します。空間データは空間充填曲線、Z階数曲線またはヒルベルト曲線に沿ってソートされます。この表現は一般的な演算子の速度向上を許しません。「左側にあるもの」「上側にあるもの」など)、「オーバラップするもの」、「中にあるもの」に分割して、GISデータを含む幅広いデータ型で使えるようにしたものです。PostGISではGISデータにインデックスを付けるためにGiSTの上でR木インデックス実装を使用しています。Tree)」の意味で、インデックスの一般化された形式です。スペクトラルデータ等)の検索速度を向上させるために使います。(これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。GiSTインデックスをジオメトリカラムに追加するための文は次の通りです。);上の文では常に2次元インデックスを構築します。n次元インデックスをジオメトリ型で使うには、次の文でインデックスを生成できます。gist_geometry_ops_nd);空間インデックスの構築は、計算量を集中させて行われます。この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムではより遅いCONCURRENTLYを選択するかも知れません。);インデックス構築後に、時々PostgreSQLにテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。9.5で導入された一般性のあるインデックスの形式です。BRINは不可逆インデックスで、主に読み取り効率と書き込み効率とを妥協させるために使われます。主要な目標は、非常に大きなテーブルの取り扱いで、そのテーブルのために、テーブル内の物理的な位置との自然な相関があるカラムを一部に持ちます。(整数、配列等)における検索速度の向上のために使われます。(これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。GiSTインデックスは、サイズがデータベースに割り当てられているRAM容量を超えずに、ストレージサイズが十分であり、かつ書き込みワークロードのペナルティに余裕がある限りは、本当に高性能です。その他の場合にはBRINインデックスが他の選択肢として考えられます。BRINインデックスの原理は、テーブルブロックの集合の全ての行に含まれる全てのジオメトリを余すところなく取り込んだバウンディングボックスだけを格納することです。明らかに、このインデックス手法は、ブロックレンジの結果バウンディングボックスが相互に排他的になるように、データが物理的に並ぶ場合にだけ効率が良くなります。結果インデックスは本当に小さいのですが、多くの場合で、GiSTインデックスより効率が落ちます。BRINインデックスの構築はGiSTインデックスの構築より少ない資源集約で済みます。BRINインデックスがGiSTインデックスが求めるよりも十分の一以下であるのが本当に一般的です。BRINインデックスは、多数のテーブルブロックに対して一つのバウンディングボックスを格納するだけなので、この手の他のインデックスよりもディスク使用量が数千分の一程度で済むのが一般的です。レンジ内で要約するブロック数を選択できます。この数字を減らすと、インデックスは大きくなりますが、効率向上の助けになる可能性があります。BRINインデックスを「ジオメトリ」カラムに追加するための文は次の通りです。);上の文では常に2次元インデックスを構築します。3次元インデックスは次の文で生成できます。brin_geometry_inclusion_ops_3d);また、4次元演算子クラスを使う4次元インデックスを使うこともできます。brin_geometry_inclusion_ops_4d);上の書式では、デフォルトの数値やレンジ内ブロック数を使っていますが、値は128です。ブロック数を指定するには、レンジ内の要約をすることになります。次の文のようにして作ります。[数字]);また、BRINインデックスは、多数の行で一つのインデックス値を格納することを心に留めておいて下さい。テーブルに違う次元のジオメトリを格納する場合には、インデックスの効率が悪くなります。この効率欠落を回避するには、格納したジオメトリの次元数の最小値となる演算子クラスを選択します。「ジオグラフィ」型もまたBRINインデックスに対応しています。BRINインデックスを「ジオグラフィ」カラムに構築するための文は次の通りです。);上の書式では常に回転楕円対面上の地理空間オブジェクトの2次元インデックスを構築します。現在のところは「包括対応」だけをここで考えています。(「ジオメトリ」「ジオグラフィ」の両方)。&&&演算子は3次元ジオメトリで使えます。KNN検索に対応しません。SP-GiSTインデックスSP-GiSTは、「空間分割された一般探索木」を表します。(トライ木)のような分割探索木に対応するインデックスの総称的な形式です。このデータ構造の一般的な機能は、検索空間を反復して分割することですが、分割は等しいサイズである必要はありません。いった、様々な種類のデータを探索する速度の向上に使われます。GiSTインデックスのためのケースですので、空間オブジェクトを覆うバウンディングボックスを保存するという意味で、SP-GiSTインデックスは不可逆です。SP-GiSTインデックスは、GiSTインデックスの選択肢の一つとして考えることができます。能率試験によって、SP-GiSTインデックスは,、多数のオーバラップするオブジェクトがある「スパゲッティデータ」と呼ばれる状態のときに、特に有利であることが分かりました。一度GISデータテーブルが数千行を超えると、データの空間探索の速度向上にSP-GiSTインデックスを使うと良いかも知れません。「ジオメトリ」カラムにSP-GiSTインデックスを構築するための文は次の通りです。);上の文では、2次元インデックスを構築します。ジオメトリ型の3次元インデックスは、次のように、3次元演算子クラスを使用して生成します。spgist_geometry_ops_3d);空間インデックスの構築は、計算量を集中させて行われます。この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムでは、より遅いCONCURRENTLYを選択するかも知れません。);インデックス構築後に、時々PostgreSQLにテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。[(カラム名)];SP-GiSTインデックスは次の演算子を含むクエリの実行速度を向上させられます。