第4章 データ管理

Open Geospatial Consortium (OGC) は、地理空間データのモデルを提供するためにSimple Features Access (SFA) 標準を開発しました。これは、ジオメトリー (Geometry)の基本的な空間タイプを、空間解析処理実行のための操作や変換といった演算に沿って定義します。PostGIS は空間解析タスクを実現するために OGC ジオメトリーモデル値を PostgreSQL データ型のgeometry、geographyとして実装しています。

ジオメトリーは抽象的なタイプです。ジオメトリー値は複数ある具体的なサブタイプの一つに属します。サブタイプは様々な種類の様々な次元のジオメトリーの形状を表現するものです。これらには原子的なタイプであるポイント (Point)、ラインストリング (LineString)、リニアリング (LinearRing)、ポリゴン (Polygon)があります。また、コレクション (collection) (訳注: 「マルチ系」と書いている場合があります) タイプのマルチポイント (MultiPoint)、マルチラインストリング (MultiLineString)、マルチポリゴン (MultiPolygon)、ジオメトリーコレクション (GeometryCollection)があります。 Simple Features Access - Part 1: Common architecture v1.2.1では多面体サーフェス (PolyhedralSurface)、三角形 (Triangle)、TINが追加されています。

ジオメトリーは 2次元デカルト平面上の形状をモデル化しています。多面体サーフェス、三角形、TIN は 3次元空間内の形状を表現することもできます。形状のサイズと位置は座標によって指定されます。それぞれの座標は、平面上で位置を判定する X と Y の座標軸値を持っています。形状はポイントと線分から構築され、ポイントは単一の座標で定められ、線分は二つの座標値から定められます。

座標には Z 座標や M 座標が含まれることがあります。Z 座標はしばしば高さを示します。M 座標は時刻や距離と言った計測された値を持ちます。ジオメトリーに Z 値または M 値がある場合には、ジオメトリーの個々の点において値が設定されなければなりません。ジオメトリーが Z 値または M 値を持つ場合には、座標次元 は 3次元になります。Z 値と M 値の両方を持つ場合には、4次元になります。座標次元は少なくとも X 座標と Y 座標を持つので、少なくとも 2です。

ジオメトリー値は、そのジオメトリーが組み込まれている座標系を示す空間参照系に関連付けられます。空間参照系はジオメトリーの SRID 番号で識別されます。X 軸と Y 軸の単位は空間参照系によって決まります。平面参照系では伝統的に X 座標値と Y 座標値が東、北をそれぞれ示します。地理参照系では、経度と緯度を表現しています。SRID が 0の場合には、軸の単位が無い、無限の直交平面を表します。「空間参照系」を参照して下さい。

ジオメトリーの 次元 はジオメトリータイプの属性です。ポイントタイプの次元は 0、ライン系タイプの次元は 1、ポリゴン系タイプの次元は 2、立体系タイプの次元は 3です。コレクションの次元は含まれる要素の次元の最大値です。

ジオメトリー値はemptyになることがあります。空値とは、非マルチ系ジオメトリーの場合は頂点を持っていないという意味で、コレクションでは要素を持っていないという意味です。

ジオメトリー値の重要なプロパティは範囲 (extent)またはバウンディングボックス (bounding box)です。OGC モデルではエンベロープ (envelope)と呼ばれています。これは、ジオメトリーの座標を囲む 2次元または 3次元のボックスです。ジオメトリーの座標空間内の範囲を表現するための、また、二つのジオメトリーの相互関係をチェックするための、効率の良い方法です。

「次元拡張 9交差モデル」 に書かれている通りジオメトリーモデルによってトポロジー面での空間関係の評価が可能になります。これに対応するために、ジオメトリータイプごとに 内部、境界、外部 が定義されています。ジオメトリーはトポロジー的に閉じていて、常に境界を持っています。境界はジオメトリーの幾何次元数から 1引いた幾何次元になります。たとえば、POLYGON の境界はリング (LINESTRING) で、LINESTRING の境界は端点 (POINT) で、POINT の境界は空です。

OGC ジオメトリーモデルでは、ジオメトリータイプごとに妥当性規則を規定しています。これらの規則によってジオメトリー値が現実的な状況を表現することが保証されます (例えば、穴が外側リングのさらに外にあるポリゴンを生成できますが、ジオメトリーとしては意味をなさないものであり、不正となります)。PostGIS は、また不正なジオメトリー値を格納、処理できます。これにより、必要に応じてジオメトリーの検出、修正が可能です。「ジオメトリー検証」 を参照して下さい。

POINT (1 2)
POINT Z (1 2 3)
POINT ZM (1 2 3 4)

LINESTRING (1 2, 3 4, 5 6)

LINEARRING (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0)

POLYGON ((0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0), (1 1 0, 2 1 0, 2 2 0, 1 2 0, 1 1 0))

MULTIPOINT ( (0 0), (1 2) )

MULTILINESTRING ( (0 0, 1 1, 1 2), (2 3, 3 2, 5 4) )

MULTIPOLYGON (((1 5, 5 5, 5 1, 1 1, 1 5)), ((6 5, 9 1, 6 1, 6 5)))

GEOMETRYCOLLECTION ( POINT(2 3), LINESTRING(2 3, 3 4))

POLYHEDRALSURFACE Z (
((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

TRIANGLE ((0 0, 0 9, 9 0, 0 0))

TIN Z ( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

ISO/IEC 13249-3 SQL Multimedia - Spatial標準 (SQL/MM) は、OGC SFA を拡張して、曲線ジオメトリーを含むサブタイプを定義しています。SQL/MM タイプは XYM, XYZ, XYZM に対応します。

	SQL-MM 実装での全ての浮動小数点数の比較では、所定の丸め誤差があります。現在は1E-8です。

CIRCULARSTRING(0 0, 1 1, 1 0)

CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)

COMPOUNDCURVE( CIRCULARSTRING(0 0, 1 1, 1 0), (1 0, 0 1))

CURVEPOLYGON(
CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),
(1 1, 3 3, 3 1, 1 1) )

CURVEPOLYGON(
COMPOUNDCURVE( CIRCULARSTRING(0 0, 2 0, 2 1, 2 3, 4 3),
               (4 3, 4 5, 1 4, 0 0)),
CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )

MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

MULTISURFACE(
CURVEPOLYGON(
  CIRCULARSTRING( 0 0, 4 0, 4 4, 0 4, 0 0),
  (1 1, 3 3, 3 1, 1 1)),
((10 10, 14 12, 11 10, 10 10), (11 11, 11.5 11, 11 11.5, 11 11)))

OGC SFA 仕様では、ジオメトリー値を外部で使用するための表現として二つの標準書式が定義されています。Well-Known Text (WKT) と Well-Known Binary (WKB) です。WKT とWKB は両方ともそのオブジェクトを定義するタイプと座標に関する情報を含んでいます。

Well-Known Text (WKT) で空間データの標準的な文字表現が可能です。空間オブジェクトの WKT 表現の例を次に挙げます。

WKT の入出力は関数ST_AsTextとST_GeomFromTextによって提供されます。

text WKT = geometry;
geometry = ST_GeomFromText(text WKT, SRID);

例えば、SRID 312 で WKT から空間オブジェクトを生成、挿入する手続きは次の通りです:

INSERT INTO geotable ( geom, name )
VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

Well-Known Binary (WKB) は、空間データのバイナリデータ (バイト列) で、移植可能かつ正確な表現です。空間オブジェクトの WKB 表現を次に挙げます。

WKB の入出力は関数ST_AsBinaryとST_GeomFromWKBが提供されています。次のように使います。

bytea WKB = ST_AsBinary(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);

たとえば、WKB から空間オブジェクトの生成、挿入は次のようにします。

INSERT INTO geotable ( geom, name )
VALUES ( ST_GeomFromWKB('\x0101000000000000000000f03f000000000000f03f', 312), 'A Place');

OGC SFA 仕様は、まず 2次元ジオメトリーのみに対応しました。また、入出力表現にジオメトリの SRID は取り入れていまません。OGC SFA 仕様 1.2.1 (ISO 19125標準に準拠) では 3次元 (XYZ) と M 値 (XYM と XYZM) 座標に対応するようになりましたが、SIRD 値の取り込みは依然行われていません。

これらの制限のため、PostGIS では拡張書式である EWKB と EWKT を定義しました。3次元 (XYZ, XYM) と 4次元 (XYZN) 座標系に対応し、SRID 情報を取り込めるようにしました。すべてのジオメトリー情報を含めたので、PostGIS は EWKB を格納用書式 (DUMP ファイル等) として使えるようになりました。

PostGIS データオブジェクトの「カノニカルな形式」のために EWKB と EWKT を使います。入力では、バイナリデータのカノニカルな形式は EWKB、テキストデータについてはEWKB か EWKT が受け付けられます。これにより、HEXEWKB または EWKT のテキスト値から::geometryを使用してキャストを行い、ジオメトリー値が生成できるようになりました。出力では、バイナリのカノニカルな形式は EWKB で、テキストはHEXEWKB (HEX エンコードを施した EWKB) です。

たとえば、この手続きでは、EWKT テキスト値からのキャストでジオメトリーを生成して、HEXWKB のカノニカルな形式を使った出力を行います。

SELECT 'SRID=4;POINT(0 0)'::geometry;

geometry
----------------------------------------------------
01010000200400000000000000000000000000000000000000

PostGIS EWKT 出力は OGC WKT と次の通り相違点があります。

EWKT は、次のように OGC/ISO 書式で発生しうる過剰次元と不整合を回避しています。

	PostGIS の拡張書式は OGC 書式の上位互換であり、全ての妥当な OGC WKB/WKT は妥当なEWKB/EWKT でもあります。しかし、OGC が PostGIS の定義と衝突する方法で書式を拡張した場合には、将来的に書式を変更する可能性があります。ゆえに、この互換性に*頼るべきではありません*!

空間オブジェクトの EWKT テキスト表現の例:

これらの書式を使う入出力は次の関数を使うと有効です。

bytea EWKB = ST_AsEWKB(geometry);
text EWKT = geometry;
geometry = ST_GeomFromEWKB(bytea EWKB);
geometry = ST_GeomFromEWKT(text EWKT);

たとえば、EWKT を使って PostGIS の空間オブジェクトを作成し挿入するステートメントは次の通りです。

INSERT INTO geotable ( geom, name )
VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

ジオグラフィデータを格納するテーブルは、SQL ステートメントCREATE TABLEにgeography型のカラムを付けることで生成することができます。2次元ラインストリングを WGS84地理座標系 (SRID 4326) で保存するジオグラフィカラムを持つテーブルを生成する例を次に示します。

CREATE TABLE global_points (
  id SERIAL PRIMARY KEY,
  name VARCHAR(64),
  location geography(POINT, 4326)
);

二つの任意の型修飾子に対応するジオグラフィ型:

ジオグラフィカラムを持つテーブルの生成の例を次に挙げます。

SRID がデフォルトの 4326 (WGS84 経度/緯度) である 2次元ポイントジオグラフィを持つテーブルの生成:

CREATE TABLE ptgeogwgs(gid serial PRIMARY KEY, geog geography(POINT));

NAD83緯度/経度の 2次元ポイントジオグラフィを持つテーブルの生成:

CREATE TABLE ptgeognad83(gid serial PRIMARY KEY, geog geography(POINT, 4269));

SRID を 4326で明示した 3次元 (XYZ) ポイントジオグラフィを持つテーブルの生成:

CREATE TABLE ptzgeogwgs84(gid serial PRIMARY KEY, geog geography(POINTZ, 4326));

SRID がデフォルトの 4326である 2次元ラインストリングジオグラフィを持つテーブルの生成:

CREATE TABLE lgeog(gid serial PRIMARY KEY, geog geography(LINESTRING));

SRID がデ 4326 (NAD 1927 経度/緯度) である 2次元ポリゴンジオグラフィを持つテーブルの生成:

CREATE TABLE lgeognad27(gid serial PRIMARY KEY, geog geography(POLYGON, 4267));

ジオグラフィカラムはgeography_columnsシステムビューに登録されます。geography_columnsビューにクエリを出してテーブルを見るには、次の通りにします。

SELECT * FROM geography_columns;

空間インデックスはジオメトリーカラムと同じように機能します。PostGIS は、カラム型がジオグラフィであると通知したうえで、ジオメトリーに使う通常の平面用インデックスでなく、球面を基にした適切なインデックスを生成します。

CREATE INDEX global_points_gix ON global_points USING GIST ( location );

ジオメトリーと同じ方法でジオグラフィテーブルにデータを挿入できます。ジオメトリーデータは、SRID 4326の場合には、ジオグラフィ型に自動キャストされます。EWKT と EWKB書式はジオグラフィ値を指定するために使うことができます。

INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

spatial_ref_sysテーブルにある地理 (経度/緯度) 参照系は、ジオグラフィの SRID として指定することができます。非地理座標系を使うとエラーが発生します。

NAD83 経度/緯度 地理座標系値:

SELECT 'SRID=4269;POINT(-123 34)'::geography;

geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140

NAD27 経度/緯度 地理座標系値:

SELECT 'SRID=4267;POINT(-123 34)'::geography;

geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140

NAD83 UTM はメートル単位の投影座標系なので失敗します。

SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.

クエリと計測関数はメートル単位となります。そのため距離パラメータはメートル (面積の場合は平方メートル) 単位となります。

1000 km 範囲内の行を検索する:

SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

シアトルからロンドンへの (LINESTRING(-122.33 47.606, 0.0 51.5)) 大円航路を行く航空機がレイキャビク (POINT(-21.96 64.15)) にどれだけ近づくかを計算することで、ジオグラフィの力を見ことができます (航路の地図表示)。

ジオグラフィ型は、レイキャビクとシアトル－ロンドン間の大円航路との距離について、球面上で 122.235 km という本当の最短距離を計算します。

SELECT ST_Distance('LINESTRING(-122.33 47.606,0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);

st_distance
-----------------
 122235.23815667

ジオメトリー型では、平面の世界地図上で見て、レイキャビクとシアトル－ロンドン間の直線とのデカルト距離が計算され、意味がありません。計算結果の名目上の単位は「度」ですが、点間の本当の角度差に応じるものではなく、「度」と呼ぶこと自体が不正確です。

SELECT ST_Distance('LINESTRING(-122.33 47.606,0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);

st_distance
--------------------
 13.342271221453624

図

ジオグラフィ型によって、経度緯度座標でデータを格納できるようになりましたが、ジオグラフィで定義されている関数が、ジオメトリーより少ないのと、実行に CPU 時間がかかる、というところが犠牲になっています。

選択した型が、期待する領域から出ないことを、ジオメトリー型にして使用する条件とすべきです。使用するデータは地球全体か、大陸か、州か、自治体か?

ジオグラフィとジオメトリー間のサポート状況の比較については「PostGIS 関数対応マトリクス」をご覧下さい。ジオグラフィ関数の簡潔なリストと説明については「PostGIS ジオグラフィ対応関数」をご覧下さい。

単純なジオメトリーは、自己交差や自己接触といった異常な幾何学上のポイントを持たないジオメトリーです。

POINTは 0次元ジオメトリーオブジェクトとして常に単純です。

MULTIPOINTが単純になる条件は、任意の二つの座標 (POINT) が同じでないことです。

LINESTRINGは、同じポイントを二回通過しないものが単純です。単純なラインストリングの端点が同一の場合には、閉じているとされ、線形リングと呼ばれます。

線ジオメトリーを分類するには ST_IsSimple を使います。下に示すラベル付けした各結果は、関数が示された分類に合致すると判定したときだけ返されます。たとえば (c) は LINESTRING が単純かつ閉じているかの確認をします。

WITH cases(label, geom) AS (VALUES
  ('a', 'LINESTRING (10 190, 140 130, 70 80, 190 10)'::geometry),
  ('b', 'LINESTRING (10 190, 130 40, 170 160, 10 10)'::geometry),
  ('c', 'LINESTRING (90 190, 120 190, 130 140, 190 50, 70 10, 10 70, 10 150, 90 190)'::geometry),
  ('d', 'LINESTRING (90 190, 120 190, 50 60, 130 10, 190 50, 160 90, 10 150, 90 190)'::geometry)
)
SELECT
  (SELECT geom FROM cases WHERE label = 'a' AND ST_IsSimple(geom))
    AS "input_(a) simple",
  (SELECT geom FROM cases WHERE label = 'b' AND NOT ST_IsSimple(geom))
    AS "input_(b) not simple",
  (SELECT geom FROM cases
             WHERE label = 'c' AND ST_IsSimple(geom) AND ST_IsClosed(geom))
    AS "input_(c) simple, closed",
  (SELECT geom FROM cases WHERE label = 'd' AND NOT ST_IsSimple(geom))
    AS "input_(d) not simple";

-[ RECORD 1 ]----------
input_(a) simple         | LINESTRING(10 190,140 130,70 80,190 10)
input_(b) not simple     | LINESTRING(10 190,130 40,170 160,10 10)
input_(c) simple, closed | LINESTRING(90 190,120 190,130 140,190 50,70 10,10 70,10 150,90 190)
input_(d) not simple     | LINESTRING(90 190,120 190,50 60,130 10,190 50,160 90,10 150,90 190)

01020000000400000000000000000024400000000000C0674000000000008061400000000000406040000000000080514000000000000054400000000000C067400000000000002440 | 01020000000400000000000000000024400000000000C06740000000000040604000000000000044400000000000406540000000000000644000000000000024400000000000002440 | 01020000000800000000000000008056400000000000C067400000000000005E400000000000C06740000000000040604000000000008061400000000000C067400000000000004940000000000080514000000000000024400000000000002440000000000080514000000000000024400000000000C0624000000000008056400000000000C06740 | 01020000000800000000000000008056400000000000C067400000000000005E400000000000C0674000000000000049400000000000004E40000000000040604000000000000024400000000000C0674000000000000049400000000000006440000000000080564000000000000024400000000000C0624000000000008056400000000000C06740

図

MULTILINESTRINGは、要素が全て単純で、かつ、全ての要素同士のインタセクションが要素の境界上でのみ出現する場合には、単純です。

次の例では、三つの MULTILINESTRING に同じ分類を適用します。(f) では、要素のラインが共有している端点だけで繋がり、(g) では内部でクロスします。

WITH cases(label, geom) AS (VALUES
  ('e', 'MULTILINESTRING ((30 190, 60 60, 170 10), (100 190, 180 150, 160 70))'::geometry),
  ('f', 'MULTILINESTRING ((30 190, 60 60, 170 10), (30 190, 180 150, 160 70))'::geometry),
  ('g', 'MULTILINESTRING ((30 190, 60 60, 170 10), (100 190, 180 150, 80 10))'::geometry)
)
SELECT
  (SELECT geom FROM cases WHERE label = 'e' AND ST_IsSimple(geom))
    AS "input_(e) simple",
  (SELECT geom FROM cases WHERE label = 'f' AND ST_IsSimple(geom))
    AS "input_(f) simple",
  (SELECT geom FROM cases WHERE label = 'g' AND NOT ST_IsSimple(geom))
    AS "input_(g) not simple";

-[ RECORD 1 ]----------
input_(e) simple     | MULTILINESTRING((30 190,60 60,170 10),(100 190,180 150,160 70))
input_(f) simple     | MULTILINESTRING((30 190,60 60,170 10),(30 190,180 150,160 70))
input_(g) not simple | MULTILINESTRING((30 190,60 60,170 10),(100 190,180 150,80 10))

0105000000020000000102000000030000000000000000003E400000000000C067400000000000004E400000000000004E400000000000406540000000000000244001020000000300000000000000000059400000000000C0674000000000008066400000000000C0624000000000000064400000000000805140 | 0105000000020000000102000000030000000000000000003E400000000000C067400000000000004E400000000000004E40000000000040654000000000000024400102000000030000000000000000003E400000000000C0674000000000008066400000000000C0624000000000000064400000000000805140 | 0105000000020000000102000000030000000000000000003E400000000000C067400000000000004E400000000000004E400000000000406540000000000000244001020000000300000000000000000059400000000000C0674000000000008066400000000000C0624000000000000054400000000000002440

図

POLYGONは線形リングから形成されるので、妥当なポリゴンジオメトリは常に単純です。

一般的に PostGIS 関数は引数ジオメトリーの単純性を求めていません。単純性は主にジオメトリの妥当性を定義するための基礎として用いられます。空間データモデルによっては要件としていることもあります (たとえば、線形ネットワークはしばしばクロスを認めません)。マルチポイントと線形ジオメトリーはST_UnaryUnionを使って単純にできます。

ジオメトリーの妥当性は主に 2次元ジオメトリー (POLYGONとMULTIPOLYGON) に適用されます。妥当性はポリゴンジオメトリーが平面領域を明確にモデル化できる規則によって定義されます。

POLYGONは次の条件では妥当です。

ポリゴン境界リングの連続重複点があるとリングは単純でないと判定されません。SFS 曲線モデルでは、曲線は連続的にたどれる経路になっています。連続で同じ座標になることはトポロジー的に頂点が一つだけの場合と判別がつきません。そのため PostGIS は連続重複点を冗長な頂点として扱い、連続重複点があるだけでは不正と判別しないようにしています。

次の例では ST_IsValid を使って、妥当性規則を確認します。ラベルを付けたジオメトリーは、妥当性計算とラベルとが合っている場合にのみ返されます。

WITH cases(label, geom) AS (VALUES
  ('h', 'POLYGON ((10 140, 90 190, 130 170, 190 60, 160 10, 50 20, 10 140),
                 (50 100, 70 80, 110 100, 110 140, 50 100))'::geometry),
  ('i', 'POLYGON ((10 140, 90 190, 130 170, 190 60, 160 10, 50 20, 10 140),
                 (190 60, 140 40, 110 60, 120 90, 190 60))'::geometry)
)
SELECT
  (SELECT geom FROM cases WHERE label = 'h' AND ST_IsValid(geom))
    AS "input_(h) valid",
  (SELECT geom FROM cases WHERE label = 'i' AND ST_IsValid(geom))
    AS "input_(i) valid, tangent hole";

-[ RECORD 1 ]----------
input_(h) valid               | POLYGON((10 140,90 190,130 170,190 60,160 10,50 20,10 140),(50 100,70 80,110 100,110 140,50 100))
input_(i) valid, tangent hole | POLYGON((10 140,90 190,130 170,190 60,160 10,50 20,10 140),(190 60,140 40,110 60,120 90,190 60))

010300000002000000070000000000000000002440000000000080614000000000008056400000000000C06740000000000040604000000000004065400000000000C067400000000000004E400000000000006440000000000000244000000000000049400000000000003440000000000000244000000000008061400500000000000000000049400000000000005940000000000080514000000000000054400000000000805B4000000000000059400000000000805B40000000000080614000000000000049400000000000005940 | 010300000002000000070000000000000000002440000000000080614000000000008056400000000000C06740000000000040604000000000004065400000000000C067400000000000004E40000000000000644000000000000024400000000000004940000000000000344000000000000024400000000000806140050000000000000000C067400000000000004E40000000000080614000000000000044400000000000805B400000000000004E400000000000005E4000000000008056400000000000C067400000000000004E40

図

次の例の (j-m) は不正です。ジオメトリーはそれぞれ、内部での非接続、クロスするリング、ラインによる切断、外側リングの外にある穴です。評価理由は ST_IsValidReason で確認しています。(j) で内部非接続ポリゴンは、妥当な MULTIPOLYGON として表現できます。

WITH cases(label, geom, reason_pattern) AS (VALUES
  ('(j) disconnected interior',
   'POLYGON ((10 140, 90 190, 130 170, 190 60, 160 10, 50 20, 10 140),
             (130 170, 10 140, 50 120, 110 110, 130 170))'::geometry,
   'Interior is disconnected%'),
  ('(k) crossing rings',
   'POLYGON ((10 140, 90 190, 130 170, 190 60, 160 10, 50 20, 10 140),
             (90 189, 10 139, 80 110, 110 130, 90 189))'::geometry,
   'Self-intersection%'),
  ('(l) cut line',
   'POLYGON ((10 100, 60 140, 60 190, 60 140, 130 170,
              190 60, 160 10, 50 20, 10 100))'::geometry,
   'Ring Self-intersection%'),
  ('(m) hole outside shell',
   'POLYGON ((10 40, 10 100, 130 130, 190 80, 140 20, 50 10, 10 40),
             (81 143, 103 143, 112 162, 107 175, 89 183, 71 169, 81 143))'::geometry,
   'Hole lies outside shell%')
)
SELECT label, geom
FROM cases
WHERE NOT ST_IsValid(geom)
  AND ST_IsValidReason(geom) LIKE reason_pattern
ORDER BY label;

label          | geom
-------------------------+----------------------------------------------------------------------------------------------------------------------------------------
 (j) disconnected interior | POLYGON((10 140,90 190,130 170,190 60,160 10,50 20,10 140),(130 170,10 140,50 120,110 110,130 170))
 (k) crossing rings       | POLYGON((10 140,90 190,130 170,190 60,160 10,50 20,10 140),(90 189,10 139,80 110,110 130,90 189))
 (l) cut line             | POLYGON((10 100,60 140,60 190,60 140,130 170,190 60,160 10,50 20,10 100))
 (m) hole outside shell   | POLYGON((10 40,10 100,130 130,190 80,140 20,50 10,10 40),(81 143,103 143,112 162,107 175,89 183,71 169,81 143))

(j) disconnected interior | 010300000002000000070000000000000000002440000000000080614000000000008056400000000000C06740000000000040604000000000004065400000000000C067400000000000004E4000000000000064400000000000002440000000000000494000000000000034400000000000002440000000000080614005000000000000000040604000000000004065400000000000002440000000000080614000000000000049400000000000005E400000000000805B400000000000805B4000000000004060400000000000406540
(k) crossing rings | 010300000002000000070000000000000000002440000000000080614000000000008056400000000000C06740000000000040604000000000004065400000000000C067400000000000004E400000000000006440000000000000244000000000000049400000000000003440000000000000244000000000008061400500000000000000008056400000000000A067400000000000002440000000000060614000000000000054400000000000805B400000000000805B40000000000040604000000000008056400000000000A06740
(l) cut line | 01030000000100000009000000000000000000244000000000000059400000000000004E4000000000008061400000000000004E400000000000C067400000000000004E400000000000806140000000000040604000000000004065400000000000C067400000000000004E40000000000000644000000000000024400000000000004940000000000000344000000000000024400000000000005940
(m) hole outside shell | 010300000002000000070000000000000000002440000000000000444000000000000024400000000000005940000000000040604000000000004060400000000000C0674000000000000054400000000000806140000000000000344000000000000049400000000000002440000000000000244000000000000044400700000000000000004054400000000000E061400000000000C059400000000000E061400000000000005C4000000000004064400000000000C05A400000000000E0654000000000004056400000000000E066400000000000C05140000000000020654000000000004054400000000000E06140

図

MULTIPOLYGONは次の条件では妥当です。

次の例では MULTIPOLYGON 規則を確認します。(n) でポリゴンは一点だけで接触しています。(o) でエッジを共有しています。(p) では内部が重なっています。

WITH cases(label, geom, valid, reason_pattern) AS (VALUES
  ('(n) point touch',
   'MULTIPOLYGON (((10 40, 29 118, 100 75, 180 88, 140 30, 70 10, 10 40)),
                  ((50 170, 100 190, 160 180, 180 140, 180 90, 120 120,
                    30 120, 50 170)))'::geometry,
   true, NULL),
  ('(o) shared edge',
   'MULTIPOLYGON (((10 40, 30 120, 120 120, 180 88, 140 30, 70 10, 10 40)),
                  ((50 170, 100 190, 160 180, 180 140, 180 90, 120 120,
                    30 120, 50 170)))'::geometry,
   false, 'Self-intersection%'),
  ('(p) overlap',
   'MULTIPOLYGON (((10 40, 42 93, 130 150, 180 86, 140 30, 70 10, 10 40)),
                  ((50 170, 100 190, 138 182, 149 156, 146 137, 100 100,
                    58 140, 50 170)))'::geometry,
   false, 'Self-intersection%')
)
SELECT label, geom
FROM cases
WHERE ST_IsValid(geom) = valid
  AND (valid OR ST_IsValidReason(geom) LIKE reason_pattern)
ORDER BY label;

label       | geom
------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 (n) point touch  | MULTIPOLYGON(((10 40,29 118,100 75,180 88,140 30,70 10,10 40)),((50 170,100 190,160 180,180 140,180 90,120 120,30 120,50 170)))
 (o) shared edge  | MULTIPOLYGON(((10 40,30 120,120 120,180 88,140 30,70 10,10 40)),((50 170,100 190,160 180,180 140,180 90,120 120,30 120,50 170)))
 (p) overlap      | MULTIPOLYGON(((10 40,42 93,130 150,180 86,140 30,70 10,10 40)),((50 170,100 190,138 182,149 156,146 137,100 100,58 140,50 170)))

(n) point touch | 01060000000200000001030000000100000007000000000000000000244000000000000044400000000000003D400000000000805D4000000000000059400000000000C052400000000000806640000000000000564000000000008061400000000000003E400000000000805140000000000000244000000000000024400000000000004440010300000001000000080000000000000000004940000000000040654000000000000059400000000000C067400000000000006440000000000080664000000000008066400000000000806140000000000080664000000000008056400000000000005E400000000000005E400000000000003E400000000000005E4000000000000049400000000000406540
(o) shared edge | 01060000000200000001030000000100000007000000000000000000244000000000000044400000000000003E400000000000005E400000000000005E400000000000005E400000000000806640000000000000564000000000008061400000000000003E400000000000805140000000000000244000000000000024400000000000004440010300000001000000080000000000000000004940000000000040654000000000000059400000000000C067400000000000006440000000000080664000000000008066400000000000806140000000000080664000000000008056400000000000005E400000000000005E400000000000003E400000000000005E4000000000000049400000000000406540
(p) overlap | 01060000000200000001030000000100000007000000000000000000244000000000000044400000000000004540000000000040574000000000004060400000000000C062400000000000806640000000000080554000000000008061400000000000003E400000000000805140000000000000244000000000000024400000000000004440010300000001000000080000000000000000004940000000000040654000000000000059400000000000C0674000000000004061400000000000C066400000000000A06240000000000080634000000000004062400000000000206140000000000000594000000000000059400000000000004D40000000000080614000000000000049400000000000406540

図

これらの規則は妥当なポリゴンジオメトリーも単純であることも示しています。

線ジオメトリーについては、LINESTRINGが少なくとも二つのポイントを持ち、長さが 0でない (少なくとも二つの異なるポイントを持つことと同じ)、というのが唯一の妥当性規則です。単純でない (自己交差がある) ラインは妥当です。

SELECT
ST_IsValid('LINESTRING(0 0,1 1)') AS len_nonzero,
ST_IsValid('LINESTRING(0 0,0 0,0 0)') AS len_zero,
ST_IsValid('LINESTRING(10 10,150 150,180 50,20 130)') AS self_int;

len_nonzero | len_zero | self_int
-------------+----------+----------
 t           | f        | t

図

POINTとMULTIPOINTは妥当性規則を持っていません。

PostGIS は妥当なジオメトリーも不正なジオメトリーも、生成も格納もできます。このため、不正なジオメトリーを検出し、フラグを付け、訂正することができます。OGC 妥当性規則が求める規則 (長さが 0のラインストリングや逆穴を持つポリゴン等) よりも厳格であることもあります。

PostGIS が提供する関数の多くは、引数ジオメトリーが妥当であるとの仮定によっています。たとえば、ポリゴンの外部に穴があるポリゴンの面積を計算しても意味がありませんし、単純でない境界線からポリゴンを形成するのも意味がありません。妥当なジオメトリ入力を仮定することで、トポロジ的に正しいことを確認する必要がなくなるので、関数がより効率的に動作することができます (例外として、長さ 0のラインと反転したポリゴンは一般的に正しく取り扱われます)。また、ほとんどの PostGIS 関数は、入力ジオメトリーが妥当な場合には、妥当なジオメトリー出力を生成します。これにより、PostGIS 関数を安全に連鎖させられます。

PostGIS 関数を呼ぶときに予期しないエラーメッセージ ("GEOS Intersection() threw an error!"等) に遭遇する場合には、まず関数の引数が妥当かどうかを確認します。妥当でないなら、次に示す方法のいずれかによる、処理中のデータの妥当性の確認を検討して下さい。

	関数が妥当な入力でエラーを報告する場合には、PostGIS または使用しているライブラリの一つの中にエラーがあるのを発見することがありますが、その際は PostGIS プロジェクトに報告して下さい。PostGIS 関数が妥当な入力から不正なジオメトリーを返す場合も同様です。

ジオメトリーが妥当かをテストするにはST_IsValid関数を使います。次のようにします。

SELECT ST_IsValid('POLYGON ((20 180,180 180,180 20,20 20,20 180))');

t

図

ジオメトリーの不正性の性質と位置に関する情報はST_IsValidDetail関数で得られます。次のようにします。

SELECT valid, reason,location AS location
        FROM ST_IsValidDetail('POLYGON ((20 20,120 190,50 190,170 50,20 20))') AS t;

valid |      reason       |                  location
-------+-------------------+---------------------------------------------
 f     | Self-intersection | POINT(91.51162790697674 141.56976744186048)

f | Self-intersection | 0101000000E80BFA82BEE05640B923EE883BB26140

図

不正なジオメトリーを自動的に訂正することが望ましいような状況があります。その際はST_MakeValid関数を使います (ST_MakeValidは不正な入力を許す特別な関数です)。

複雑なジオメトリーの不正性テストには多大な CPU 時間を取ることになるため、デフォルトでは、ジオメトリーのロード時に PostGIS は妥当性の確認をしません。データソースが信用できない場合には、チェック制約を使って、テーブル上で妥当性を強制的に確認することができます。次のようにします。

ALTER TABLE mytable
ADD CONSTRAINT geometry_valid_check
  CHECK (ST_IsValid(geom));

PostGIS が使用するSPATIAL_REF_SYSテーブルは利用可能な空間参照系を定義する OGC 準拠のデータベーステーブルです。このテーブルは、数値で SRID を持ち、文字列で座標系の記述を持っています。

spatial_ref_sysの定義は次の通りです。

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

カラムは次の通りです。

投影変換で空間参照系の定義を使用する場合には、次の戦略を取ります。

PostGISspatial_ref_sysテーブルにはPROJ投影ライブラリで処理される最も一般的な空間参照系定義 3000件以上があります。しかし、そこに無い多くの座標系があります。空間参照系に関する必要な情報がある場合は、SRS 定義をテーブルに追加できます。PROJ に詳しいなら独自の空間参照系を定義することもできます。ほとんどの空間参照系は地域的なものであり、目的の範囲外で使用する場合は意味を持たない点に注意してください。

PostGIS のコアセットに入っていない空間参照系を探すための素晴らしい資料がhttp://spatialreference.org/にあります。

一般的に使われる空間参照系には 4326 - WGS 84 地理座標系、4269 - NAD 83 地理座標系 (訳注: 日本では使いません)、3395 - WGS 84 メルカトル図法、2163 - 米国ナショナルアトラス正積図法 (訳注: 日本では使いません)、WGS84 UTM 60個のゾーンがあります。UTM ゾーンは計測に最も適していますが、対応領域は経度 6度幅です。WGS84 経度緯度データから UTM ゾーンは least(floor((longitude + 180) / 6) + 1, 60) (訳注: 北欧の一部ではズレがあります) となり、EPSG コードは、 北半球では 32600 + zone となり、南半球では 32700 + zone となります。

米国の州では、州平面空間参照系 (メートルまたはフィート単位) を使用します。この空間参照系は州ごとに一つか二つ存在します。ほとんどのメートル単位のものはコアのセットに存在しますが、フィート単位の多数のものや ESRI が作成したものはspatialreference.orgからロードする必要があります。

地球外の座標系でさえも定義することができます。たとえばMars 2000です。この火星の座標系は非平面 (回転楕円体の度) ですが、geography型で、度でなくメートル単位で長さや近接測定値を取得することができます。

割当外の SRID と PROJ 定義を使って米国中央のランベルト正角円錐図法の独自座標系をロードする例を次に示します。

INSERT INTO spatial_ref_sys (srid, proj4text)
VALUES ( 990000,
  '+proj=lcc  +lon_0=-95 +lat_0=25 +lat_1=25 +lat_2=25 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs'
);

geometry型のカラムを付けたCREATE TABLE SQL ステートメントでジオメトリーデータを保存するテーブルを生成することができます。次の例では、BC-アルベルス座標系 (SRID 3005) の 2次元 (XY) ラインストリングを保存するジオメトリーカラムを持つテーブルを生成します。

CREATE TABLE roads (
  id SERIAL PRIMARY KEY,
  name VARCHAR(64),
  geom geometry(LINESTRING, 3005)
);

geometry型は、次の通り、二つの任意指定型修飾子に対応しています。

ジオグラフィカラムを持つテーブルの生成の例を次に挙げます。

デフォルト SRID であらゆる種類のジオメトリーを保持するテーブルの生成:

CREATE TABLE geoms(gid serial PRIMARY KEY, geom geometry);

2次元ポイントで SRID がデフォルトのテーブル作成:

CREATE TABLE pts(gid serial PRIMARY KEY, geom geometry(POINT));

3次元 (XYZ) ポイントで SRID が 3005のテーブル作成:

CREATE TABLE pts(gid serial PRIMARY KEY, geom geometry(POINTZ, 3005));

4次元 (XYZM) ラインストリングで SRID がデフォルトのテーブル作成:

CREATE TABLE lines(gid serial PRIMARY KEY, geom geometry(LINESTRINGZM));

2次元ポリゴンで SRID が 4276 (NAD 1927地理座標系) のテーブル作成:

CREATE TABLE polys(gid serial PRIMARY KEY, geom geometry(POLYGON, 4267));

一つのテーブルが一つ以上のジオメトリーカラムを持つことができます。テーブル生成時に指定するか、ALTER TABLE SQL ステートメントを使って追加するかで実現できます。次に 3次元ラインストリングを格納するカラムを追加する例を示します。

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ, 4326);

OGC Simple Features Specification for SQLは、ジオメトリーテーブル構造を記述するためのGEOMETRY_COLUMNSメタデータテーブルを定義しています。PostGIS ではgeometry_columnsは、データベースのシステムカタログテーブルから読み取るビューです。これによって、空間メタデータ情報が常に現在定義されているテーブルやビューと矛盾しなくなります。

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

カラムは次の通りです。

これが必要になる事例に、SQL ビューとバルクインサートの二つがあります。バルクインサートの場合には、カラムに制約を与えるか、ALTER TABLE を実行することで、geometry_columns テーブル内の登録を訂正することができます。ビューの場合には、CAST 演算を使用します。カラムが型修飾子に基づく場合には、生成処理によって正しく登録されるので、何も行う必要がありません。ジオメトリーに適用する空間関数を持たないビューも、基礎となるテーブルのジオメトリーカラムと同じように登録されます。

例えば、次のようなビューを作ったとします。

CREATE VIEW public.vwmytablemercator AS
SELECT gid, ST_Transform(geom, 3395) As geom, f_name
FROM public.mytable;

ジオメトリーカラムを正しく登録するには、ST_Transform の結果ジオメトリーに対してキャストします。

DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
    SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
    FROM public.mytable;

ジオメトリータイプが 2次元ポリゴンになると分かっているならキャストで指定できます。

DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
    SELECT gid, ST_Transform(geom, 3395)::geometry(Polygon, 3395) As geom, f_name
    FROM public.mytable;

バルクインサートで派生テーブルを生成する場合には、先にテーブルを生成します。

SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

新しいテーブル上での 2次元空間インデックスの生成。

CREATE INDEX idx_myschema_myspecialpois_geom_gist
ON myschema.my_special_pois USING gist(geom);

ポイントが 3次元または M 値を持つ場合には、n 次元インデックスがより適切になりえます。

CREATE INDEX my_special_pois_geom_gist_nd
ON my_special_pois USING gist(geom gist_geometry_ops_nd);

新しいテーブルのジオメトリーカラムを geometry_columns に手動登録します。これによって基礎となるテーブルの構造を変更して、カラムで型修飾子が使われるようになります。

SELECT Populate_Geometry_Columns('myschema.my_special_pois'::regclass);

子テーブル間で異なるジオメトリータイプや SRID を持つ継承テーブルのように、制約による定義を維持したい場合には、任意引数 use_typmod を FALSE にします。

SELECT Populate_Geometry_Columns('myschema.my_special_pois'::regclass, false);

Although the old-constraint based method is still supported, a constraint-based geometry column used directly in a view, will not register correctly in geometry_columns, as will a typmod one. In this example we define a column using typmod and another using constraints.

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT, 4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

psql で \d pois_ny を使うと異なる定義になることが分かります。一方は型修飾子方式で、もう一方は制約方式です。

\d pois_ny

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

geometry_columns では、両方とも正しく登録されています。

SELECT f_table_name, f_geometry_column, srid, type
FROM geometry_columns
WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

しかし、次のようにビューを作ろうとします。

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
    FROM geometry_columns
    WHERE f_table_name = 'vw_pois_ny_parks';

The typmod based geom view column registers correctly, but the constraint based one does not.

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

This may change in future versions of PostGIS, but for now to force the constraint-based view column to register correctly, you need to do this:

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
    FROM geometry_columns
    WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

空間データを文字表現 (WKT か WKB) に変換できたら、SQL を使うのが PostGIS にデータを持たせる最も簡単です。SQL ユーティリティのpsqlを使用して、SQL のINSERTステートメントのテキストファイルをロードすると、データをPostGIS/PostgreSQL に一括読み込みできます。

データアップロードファイル (たとえばroads.sql) は次のようになるでしょう。

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1, 'LINESTRING(191232 243118,191108 243242)', 'Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2, 'LINESTRING(189141 244158,189265 244817)', 'Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3, 'LINESTRING(192783 228138,192612 229814)', 'Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4, 'LINESTRING(189412 252431,189631 259122)', 'Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5, 'LINESTRING(190131 224148,190871 228134)', 'Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6, 'LINESTRING(198231 263418,198213 268322)', 'Dave Cres');
COMMIT;

SQL ファイルの PostgreSQL へのロードはpsqlを使います。次のようにします。

psql -d [database] -f roads.sql

shp2pgsqlデータローダは、ESRI シェープファイルを PostGIS/PostgreSQL データベースに、ジオメトリーまたはジオグラフィとして挿入するための適切な SQL に変換します。ローダには、次に示すコマンドラインフラグによって区別される、いくつかの操作モードがあります。

入力は、固めていないシェープファイルのパスでなければなりません。ローダーは .zip アーカイブを直接読めません。ロード前に .shp、.shx、.dbf ファイルを展開します。

グラフィカルユーザーインタフェースを持つshp2pgsql-guiもあります。コマンドラインローダのオプションのほとんどが使えます。これは、スクリプト化されていない 1回限りのロードの場合や、PostGIS 初心者がロードする場合に、簡単に使用できます。PgAdminIII のプラグインとすることもできます。

ローダを使って入力ファイルを生成してアップロードするセッション例は次の通りです。

shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable > roads.sql
psql -d roadsdb -f roads.sql

変換とアップロードは UNIX のパイプを使うと一回で実行できます。

shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

シェープファイルのディレクトリーをロードするのに、ローダーをファイルごとに実行して、ファイル名からテーブル名を導きます。Windows では次のようにします。 cmd.exe 上ではパーセント記号は一つで、バッチファイルでは二つです:

REM In a .bat file, use %%F. At an interactive cmd.exe prompt, use %F.
for %%F in ("C:\data\shapefiles\*.shp") do (
  shp2pgsql -d -D -s 4269 -I -W UTF-8 "%%~fF" "myschema.%%~nF" | psql -d roadsdb
)

全てのシェープファイルが同じ属性とデータ型を持っていて、これらを一つのテーブルに追加したいとき、最初のファイルを作り、残りのファイルは -a を使います。

データベース外へのデータ抽出の最も簡単な方法は、抽出するデータセットを定義し、SELECT問い合わせを使って、結果カラムを解析可能なテキストファイルにダンプすることです。

SELECT road_id,road_geom AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
      1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
      2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
      3 | LINESTRING(192783 228138,192612 229814) | Paul St
      4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
      5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
      6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
      7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

返されるレコードの数を減らすためにある種の制限が必要になる場合があります。属性ベースで制限をかける場合には、非空間テーブルで使うのと同じ SQL 文を使います。空間に制限をかけるには次の関数を使います。

次に、これらの演算子をクエリで使うことができます。SQL コマンドラインからジオメトリとボックスの指定を行うときは、明示的に文字列表現をジオメトリーに変換しなければならないことに注意して下さい。たとえば、次のようになります。ただし 312は架空の空間参照系番号で、ここでのデータに合致しています。

SELECT road_id, road_name
FROM roads
WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

上のクエリは"ROADS_GEOM"テーブルから、その値と等価である単一のレコードを返します。

道路がポリゴンで定義した面を通過するかどうかをチェックするには次のようにします。

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

最も一般的な空間クエリは「フレームベース」のクエリでしょう。これは、表示するためのデータの価値のある「マップフレーム」を取得するために、データブラウザやウェブマッパのようなクライアントソフトウェアに使われます。

"&&"演算子を使うとき、比較フィーチャーを BOX3D か GEOMETRY かに指定することができます。ただし、GEOMETRY を指定すると、それのバウンディングボックスが比較に使われます。

次に示すクエリのように、フレームに BOX3D オブジェクトを使います。

SELECT roads_geom AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

エンベロープの投影を指定するために SRID 312を使っていることに注意して下さい。

pgsql2shpテーブルダンパは、データベースに直接接続して、テーブル (あるいはクエリによって定義されたもの) をシェープファイルに変換するものです。基本的な文は次の通りです。

pgsql2shp [<options
>] <database
> [<schema
>.]<table>

pgsql2shp [<options
>] <database
> <query>

コマンドラインオプションは次の通りです。

GiST は「汎用検索木 (Generalized Search Tree)」の意味で、多次元データのインデックスの一般化された形式です。PostGIS は GiST 上で実装している R 木インデックスをを空間データのインデックスに使用しています。GiST は最も一般的に使われ、多目的なインデックス手法で、クエリ能率を非常に良くします。他の GiST の実装は、通常の B 木インデックスに従わない全ての種類の不規則なデータ構造 (整数配列, スペクトラルデータ等) の検索速度を向上させるために使います。詳細情報についてはPostgreSQL manualをご覧ください。

GIS データテーブルが数千行を超えたら、空間検索の速度向上のためインデックスを構築したくなるでしょう (これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。

GiST インデックスをジオメトリーカラムに追加するための文は次の通りです。

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield]);

上の文では常に 2次元インデックスを構築します。n 次元インデックスをジオメトリー型で使うには、次の文でインデックスを生成できます。

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムではより遅い CONCURRENTLY を選択するかも知れません。次のようにします。

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield]);

インデックス構築後に、時々 PostgreSQL にテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。

VACUUM ANALYZE [table_name] [(column_name)];

BRIN は"Block Range Index"の意味です。PostgreSQL が提供する汎用インデックスです。BRIN は不可逆インデックスですので、レコードが検索条件に合致するか確認する二次チェックが必要です (これは提供されているすべての空間インデックスと同じです)。BRIN は、インデックス生成が非常に高速で、インデックスサイズが非常に小さく、読込み効率がそこそこ良いものです。これの主目的は、巨大テーブルに対してテーブル内の物理位置と相関するカラムの上にインデックスを生成することです。BRIN は各種属性データ構造 (整数、配列など) の高速検索が可能です。詳細情報についてはPostgreSQL manualを参照してください。

空間テーブルが、ひとたび数千行を超えると、データの空間検索の速度向上にインデックスが必要と感じることになります。GiST インデックスは、サイズがデータベースで使える RAM 容量を超えず、インデックスのストレージサイズに余裕があり、書き込み時のインデックス更新コストにも余裕があるなら、非常に高いパフォーマンスを発揮します。そうでない場合には、非常に大きなテーブルにおいては、BRIN インデックスを代替に考えることができます。

BRIN インデックスは、連続するテーブルブロックの集合 (ブロック範囲と言います) の全てのジオメトリーを囲むバウンディングボックスを格納します。インデックスを使用した問い合わせを実行する時に、問い合わせ範囲とインタセクトするブロック範囲を見つけるためにスキャンします。これは、データが物理的に整列していて、ブロック範囲のバウンディングボックスのオーバラップが最小である (理想的には相互に排他的である) 場合に限って効率的です。結果インデックスは非常に小さいサイズですが、通常、読み込み効率は、同じデータにおける GiST インデックスより悪くなります。

BRIN インデックスの構築は、は GiST インデックスと比べて、CPU 集中を非常に減らします。BRIN インデックスは GiST インデックスよりも、同じデータに対して 10倍速く構築するのが普通です。BRIN インデックスはテーブルブロックの範囲ごとに一つのバウンディングボックスしか格納しないので、GiST インデックスと比べて、ディスクスペースを 1000倍少なくできます。

レンジ内で要約するブロック数を選択できます。この数字を減らすと、インデックスは大きくなりますが、効率向上の助けになる可能性があります。

BRIN を効果的にするには、テーブルデータをブロック範囲のオーバラップの量を最小にするような物理的オーダーで格納します。データが既に適切に並び替えられているかも知れません (たとえば、既に空間オーダーで並び替えられているデータセットを他のデータベースからロードする場合)。そうでない場合には、一つの空間キーによるデータの並べ替えで実現できます。一つの方法として、ジオメトリー値で並べ替えた新しいテーブルを生成することです (最近の PostGIS のバージョンで効果的なヒルベルト曲線オーダーが使われています)。

CREATE TABLE table_sorted AS
SELECT * FROM table  ORDER BY geom;

もしくは、データは、ジオハッシュを (一時的な) インデックスに使い、そのインデックスでクラスタリングを行うことによって適切に並べ替えることができます。

CREATE INDEX idx_temp_geohash ON table
    USING btree (ST_GeoHash(ST_Transform(geom, 4326 ), 20));
CLUSTER table USING idx_temp_geohash;

BRIN インデックスをジオメトリーカラムに追加するための文は次の通りです。

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geome_col]);

上の文で 2次元インデックスを構築します。3次元インデックスをビルドするには、この文を使います。

CREATE INDEX [indexname] ON [tablename]
USING BRIN ([geome_col] brin_geometry_inclusion_ops_3d);

また、4次元演算子クラスを使う 4次元インデックスを使うこともできます。

CREATE INDEX [indexname] ON [tablename]
USING BRIN ([geome_col] brin_geometry_inclusion_ops_4d);

上記のコマンドでは、範囲のブロック数はデフォルトの 128を使用しています。集計で範囲のブロック数を指定するには、この文を使います。

CREATE INDEX [indexname] ON [tablename]
USING BRIN ( [geome_col] ) WITH (pages_per_range = [number]); 

また、BRIN インデックスは、多数の行で一つのインデックス値を格納することを心に留めておいて下さい。テーブルに違う次元のジオメトリーを格納する場合には、インデックスの効率が悪くなります。この効率欠落を回避するには、格納したジオメトリーの次元数の最小値となる演算子クラスを選択します。

geography型も BRIN インデックスに対応しています。BRIN インデックスをジオグラフィカラムに構築するための文は次の通りです:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geog_col]);

上の文では常に回転楕円体面上の地理空間オブジェクトの 2次元インデックスを構築します。

現在のところは「包括対応」だけをここで考えています。これは、&&, ~, @の演算子だけが 2次元で使われることを意味します (ジオメトリーとジオグラフィの両方)。 &&&演算子は 3次元ジオメトリで使えます。しばらくは KNN 検索に対応しません。

BRIN と他のインデックスとの重要な違いは、データベースがインデックスを動的に保守しないことです。テーブルの空間データを変更すると、単純にインデックスの末尾に追加しています。このためインデックス探索の能率が時間とともに低下します。インデックスはVACUUMか空間関数brin_summarize_new_values(regclass)を実行することで更新できます。このため、BRIN は読み込み専用か、書き込みがほとんど発生しないよなデータでの利用では最も適切になりえます。詳細情報については、manualをご覧下さい。

空間データに BRIN を使用して集計するには:

SP-GiST は、「空間分割された一般探索木」を表します。四分木、k 次元木、基数木 (トライ木) のような分割探索木に対応するインデックスの総称的な形式です。このデータ構造の一般的な機能は、検索空間を反復して分割することですが、分割は等しいサイズである必要はありません。SP-GiST は、GIS インデックスだけでなく、電話回線のルーティングや、IP ルーティング、部分文字列検索等といった、様々な種類のデータを探索する速度の向上に使われます。詳細情報についてはPostgreSQL manualをご覧下さい。

GiST インデックスを利用しているので、空間オブジェクトを覆うバウンディングボックスを保存するという意味で、SP-GiST インデックスは不可逆です。SP-GiST インデックスは、GiST インデックスの代替と考えることができます。

一度 GIS データテーブルが数千行を超えると、データの空間探索の速度向上に SP-GiSTインデックスを使うと良いかも知れません。「ジオメトリー」カラムに SP-GiST インデックスを構築するための文は次の通りです。

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield]);

上の文では、2次元インデックスを構築します。ジオメトリー型の 3次元インデックスは、次のように、3次元演算子クラスを使用して生成します。

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムでは、より遅い CONCURRENTLY を選択するかも知れません。次のようにします。

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield]);

インデックス構築後に、時々 PostgreSQL にテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。

VACUUM ANALYZE [table_name] [(column_name)];

SP-GiST インデックスは次の演算子を含むクエリの実行速度を向上させられます。

現時点では kNN 探索に対応していません。

通常、インデックスは知らないうちにデータアクセスの速度を向上します。ひとたびインデックスを構築すれば、PostgreSQL クエリプランナは自動的にクエリの能率を向上させるために使うべきかどうかを決定します。しかし、プランナが既存のインデックスを選択せず、遅いシーケンシャルスキャンを使い続ける場合があります。

空間インデックスが使われていないのが分かった場合には、少しの行えることがあります。

詳細情報については PostgreSQL マニュアルの問い合わせ計画節をご覧下さい。