PostGIS 1.5.1 マニュアル 日本語訳

ほとんどのLinuxのインストールと同様に，最初のステップでは，ソースコードのビルドに使われる Makefile を生成します．これは，シェルスクリプトで行います．

./configure

パラメータを付けない場合は，このコマンドは自動で，PostGISのソースコードのビルドを行うのに必要なコンポーネントやライブラリを，システム上で探します． ./configure とするのが一般的な使い方ですが，標準的でない位置に必要なライブラリやプログラムを置いてある場合のために，いくつかのパラメータを受け付けます．

次のリストで，共通して使われるパラメータを示します． 完全なリストについては， --help または --help=short パラメータを使って下さい．

	PostGISを SVN レポジトリを得た場合は，本当は最初に次のスクリプトを実行します． ./autogen.sh このスクリプトは，PostGISのインストールのカスタマイズを行うための configure スクリプトを生成するものです． PostGISをtarballから得た場合は， configure が既に生成されているので ./autogen.sh を実行する必要はありません．

Makefileが生成されたら，PostGISのビルドは，次のコマンドを実行するだけです．

make

出力の最後の行が "PostGIS was built successfully. Ready to install." と出れば終わりです．

PostGIS 1.4.0版からは，全ての関数に文書から生成されるコメントが付きます． これらのコメントを後ほどインストールするには，次のコマンドを実行しますが，docbookが必要です． postgis_comments.sql が docフォルダに tar.gz でパッケージ化されます． tarballからインストールする場合は，postgis_comments.sql が docフォルダに入っているので，コメントを生成する必要はありません．

make comments

PostGISのテストを行うには，次のコマンドを実行します．

make check

このコマンドは，実際のPostgreSQLデータベースに対して生成したライブラリを使用した，様々なチェックとレグレッションテストを行います．

	PostgreSQL, GEOS または Proj4 を標準の位置にインストールしていない場合には， 環境変数 LD_LIBRARY_PATH に，ライブラリの位置を追加する必要があるかも知れません．

	現在のところ make check は，チェックを行う際に 環境変数 PATH と PGPORT によっています． コンフィギュレーションパラメータ --with-pgconfig を使って特定した PostgreSQL ではありません． PATHを編集して，コンフィギュレーションの際に検出したPostgreSQLと一致するようにして下さい． もしくは，間もなく襲ってくる頭痛の準備をしておいて下さい． このバグのトラックについては http://trac.osgeo.org/postgis/ticket/186 をご覧ください．

成功したら，テストの出力は次のようなかんじになります．

     CUnit - A Unit testing framework for C - Version 2.1-0
	 http://cunit.sourceforge.net/


Suite: PostGIS Computational Geometry Suite
  Test: test_lw_segment_side() ... passed
  Test: test_lw_segment_intersects() ... passed
  Test: test_lwline_crossing_short_lines() ... passed
  Test: test_lwline_crossing_long_lines() ... passed
  Test: test_lwpoint_set_ordinate() ... passed
  Test: test_lwpoint_get_ordinate() ... passed
  Test: test_lwpoint_interpolate() ... passed
  Test: test_lwline_clip() ... passed
  Test: test_lwline_clip_big() ... passed
  Test: test_lwmline_clip() ... passed
  Test: test_geohash_point() ... passed
  Test: test_geohash_precision() ... passed
  Test: test_geohash() ... passed
Suite: PostGIS Measures Suite
  Test: test_mindistance2d_recursive_tolerance() ... passed

--Run Summary: Type      Total     Ran  Passed  Failed
			   suites        2       2     n/a       0
			   tests        14      14      14       0
			   asserts      84      84      84       0


Creating spatial db postgis_reg
TMPDIR is /tmp/pgis_reg_15328

 PostgreSQL 8.3.7 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
 Postgis 1.4.0SVN - 2009-05-25 20:21:55
   GEOS: 3.1.0-CAPI-1.5.0
   PROJ: Rel. 4.6.1, 21 August 2008

Running tests

 loader/Point.............. ok
 loader/PointM.............. ok
 loader/PointZ.............. ok
 loader/MultiPoint.............. ok
 loader/MultiPointM.............. ok
 loader/MultiPointZ.............. ok
 loader/Arc.............. ok
 loader/ArcM.............. ok
 loader/ArcZ.......... ok
 loader/Polygon.............. ok
 loader/PolygonM.............. ok
 loader/PolygonZ.............. ok
 regress. ok
 regress_index. ok
 regress_index_nulls. ok
 lwgeom_regress. ok
 regress_lrs. ok
 removepoint. ok
 setpoint. ok
 simplify. ok
 snaptogrid. ok
 affine. ok
 wkt. ok
 measures. ok
 long_xact. ok
 ctors. ok
 sql-mm-serialize. ok
 sql-mm-circularstring. ok
 sql-mm-compoundcurve. ok
 sql-mm-curvepoly. ok
 sql-mm-general. ok
 sql-mm-multicurve. ok
 sql-mm-multisurface. ok
 geojson. ok
 gml. ok
 svg. ok
 kml. ok
 regress_ogc. ok
 regress_bdpoly. ok
 regress_proj. ok
 regress_ogc_cover. ok
 regress_ogc_prep. ok

Run tests: 42
Failed: 0

PostGISをインストールするには，次のコマンドを実行します．

make install

これにより，PostGISのインストールファイルが，--prefix パラメータで指定した，適切なサブディレクトリに複写されます．次に特筆すべきサブディレクトリを示します．

先に make comments を実行していた場合は，次のコマンドを実行すると，SQLファイルのインストール先に postgis_comments.sql がインストールされます．

make comments-install

	postgis_comments.sql は，xsltproc の外部依存ができたので，通常のビルド，インストールから切り離されました．

コンパイル後に postgis_upgrade*.sql を探して下さい． PostGISの版にあったものをインストールします． たとえば，PostGIS 1.3 から 1.5 に上げるには postgis_upgrade_13_to_15.sql を使います．

$ psql -f postgis_upgrade_13_to_15.sql -d your_spatial_database

ソフトアップグレードができなかった場合に，スクリプトは強制終了されて，ハードアップグレードが必要であると警告されますので，先にソフトアップグレードを実行することをためらってはなりません．

	postgis_upgrade*.sql ファイルが見つからない場合は，1.1版より前の版のものを使っているかも知れません．この場合，次のコマンドで手動で生成する必要があります． $ utils/postgis_proc_upgrade.pl postgis.sql > postgis_upgrade.sql

ハードアップグレードは，PostGISデータベースの完全なダンプ/リロードを意味します． PostGISオブジェクトの内部ストレージが変更されていたり， ソフトアップグレードができない場合には，ハードアップグレードが必要です． 付録の Release Notes に，それぞれの版でアップグレードする際にダンプ/リロード(ハードアップグレード)が必要かの報告があります．

PostGISは，pg_dump -Fc コマンドで生成されたダンプのリストアを行うユーティリティスクリプトを提供しています． 実験版ですが，このスクリプトの出力をファイルにリダイレクトすると，問題のある場合に助けになります． 手続きは次の通りです．

アップグレードしたいデータベース("olddb"と呼ぶことにしましょう)のダンプを「カスタム書式」で作成します．

$ pg_dump -Fc olddb > olddb.dump

PostGISのアップグレードを行うダンプを，新しいデータベースにリストアします． 新しいデータベースは存在している必要はありません． postgis_restore は，ダンプファイル名の後にcreatedbパラメータを指定すると，これを受けつけます． たとえば，データベースでデフォルトでない文字コードを使っているとしても，このスクリプトを使うことができます． 新しいデータベースは newdb と呼ぶことにして，このデータベースの文字コードをUNICODEにするなら，次のようになります．

$ sh utils/postgis_restore.pl postgis.sql newdb olddb.dump -E=UNICODE > restore.log

全てのリストアしたダンプオブジェクトが本当にリストアされ， postgis.sqlで定義されたオブジェクトと矛盾しないことをチェックします．

$ grep ^KEEPING restore.log | less

PostgreSQL < 8.0 から >= 8.0 にアップグレードした際は， geometry_columns テーブルにあって，もはや必要でない attrelid, varattnum, stats の各カラムを削除したくなるかも知れません． 保持していても困りません． *本当に必要な時に削除すると困ります*!

$ psql newdb -c "ALTER TABLE geometry_columns DROP attrelid"
$ psql newdb -c "ALTER TABLE geometry_columns DROP varattnum"
$ psql newdb -c "ALTER TABLE geometry_columns DROP stats"

spatial_ref_sys テーブルは，独自の追加が保持されることを保障するために，ダンプからリストアされます． しかし，ディストリビュートされた spatial_ref_sys テーブルは，変更を含んでいますので， エントリをバックアップし，テーブルを削除して，新しい spatial_ref_sys テーブルを入れるべきです． 独自の追加を作っているのでしたら， テーブルをアップグレードする前にバックアップを取る方法を知っていると仮定します． 新しいものとの入れ替えは，このように実行します．

$ psql newdb
newdb=> truncate spatial_ref_sys;
TRUNCATE
newdb=> \i spatial_ref_sys.sql

OpenGIS仕様は空間オブジェクトの表現について二つの標準を定義しています．Well-Knownテキスト(WKT)形式とWell- Knownバイナリ(WKB)形式です． WKTもWKBも，オブジェクトの型とオブジェクトを形成する座標に関する情報を持っています．

フィーチャーの空間オブジェクトのテキスト表現(WKT)の例は，次の通りです．

OpenGIS仕様では，空間オブジェクトの内部保存フォーマットが空間参照システム識別子(Spatial Referencing System IDentifier, SRID)を含むことも求められます． SRIDはデータベースへの挿入のために空間オブジェクトが生成される時に求められます．

これらの書式の入出力は次のインタフェースを用いて実現できます．

bytea WKB = ST_AsBinary(geometry);
text WKT = ST_AsText(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);
geometry = ST_GeometryFromText(text WKT, SRID);

たとえば，OGC空間オブジェクトを生成して挿入する妥当なINSERTステートメントは次の通りです．

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

OGC書式は2次元ジオメトリしかサポートされておらず，また，入出力の表現においてSRID群は*決して*埋め込まれません．

PostGIS拡張書式は現在のところOGC書式のスーパーセットとなっています (全ての妥当なWKB/WKTは妥当なEWKB/EWKTです)．しかし，特にもしOGCがPostGIS拡張と矛盾する新しい書式を出すことがあるなら，これは将来変更されるかも知れません．ゆえにこの機能に頼るべきではありません．

PostGIS EWKB/EWKT では 3dm, 3dz, 4d の座標サポートが追加され，SRID情報が埋め込まれます．

フィーチャーの拡張空間オブジェクトのテキスト表現(EKWT)の例は次の通りです．

これらの書式の入出力は次のインタフェースを用いて実現できます．

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

たとえば，PostGISの空間オブジェクトを作成し挿入する妥当なINSERTステートメントは次の通りです．

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

PostgreSQLの「標準的な形式」は単純なクエリ(全く関数呼び出しが無い)で表現でできていて，INSERT, UPDATE, COPYで受け付けられることが保障されるものです．PostGISの"geometory"型は次の通りです．

- Output
  - binary: EWKB
	ascii: HEXEWKB (EWKB in hex form)
- Input
  - binary: EWKB
	ascii: HEXEWKB|EWKT

たとえば，このステートメントは，標準的なASCII文字列による入出力の処理でEWKTを読み，HEXEWKBを返すものです．

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

geometry
----------------------------------------------------
01010000200400000000000000000000000000000000000000
(1 row)

SQLマルチメディア・アプリケーション空間仕様は，円弧補完曲線を定義したSQL仕様の拡張です．

SQL-MMの定義では，3dm，3dzと4dの座標を含みますが，SRID情報の埋め込みはできません．

WKT拡張はまだ完全にはサポートされていません．単純な曲線ジオメトリの例を次に示します．

	PostGIS 1.4より前では，曲線ポリゴンで複合曲線をサポートしていませんでしたが， PostGIS 1.4以降は曲線ポリゴンでの複合曲線の使用をサポートするようになりました．

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

ジオグラフィ型は簡単なフィーチャーの最も簡単なもののみサポートします．標準的なジオメトリ型データで，SRIDが4326の場合は，ジオグラフィに自動でキャストされます．またEWKTとEWKBの取り決めを使うこともできます．

新しいジオグラフィカラムはgeometry_columnsに登録されてません．システムカタログを見るgeomgraphy_columnsという新しいビューに登録されるので，AddGeom... といった関数を使わずに，自動管理されます．

"geography_columns"ビューをチェックして，テーブルがリストされているか見て下さい．

CREATE TABLEでジオグラフィカラムを持つテーブルを作ることができます． ジオメトリと違って，AddGeometryColumns()でメタデータにカラム情報を登録する処理を別に行う必要がなくなりました．

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

locationカラムはGEOGRAPHY型で，二つのオプション修飾子をサポートすることにご注意ください． ひとつは，そのカラムで使用できる形状と次元を限定する型修飾子です．もうひとつは，座標参照IDを特定の数に限定するSRID修飾子です．

型修飾子で許される値は POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON です．この修飾子ではZ, M, ZM の拡張子によって次元を限定します．たとえば，'LINESTRINGM'という値では，3次元で，第3次元が計測値(measure)となります．同じように見て 'POINTZM' は，4次元となります．

SRID修飾子には，現在は4326(WGS84)の許されるという制限があります．SRIDを指定したくない場合は 0 (未定義の回転楕円体) を使います．この場合の全ての計算は，WGS84とします．

将来的には，他のSRIDによって，WGS84以外の回転楕円体に関する計算ができるようにします．

テーブルを作ったら，次のようにしてGEOGRAPHY_COLUMNSを見ることができます．

-- See the contents of the metadata view
SELECT * FROM geography_columns;

ジオメトリカラムを使うのと同じようにテーブルへのデータの挿入ができます．

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', ST_GeographyFromText('SRID=4326;POINT(-110 30)') );
INSERT INTO global_points (name, location) VALUES ('Forest', ST_GeographyFromText('SRID=4326;POINT(-109 29)') );
INSERT INTO global_points (name, location) VALUES ('London', ST_GeographyFromText('SRID=4326;POINT(0 49)') );

ジオメトリカラムと同じ操作でインデクスを作成します． PostGISは，カラム型がGEOGRAPHYであるかを見て，GEOMETRYで使われる平面用インデクスの代わりに球面ベースのインデクスを作成します．

-- Index the test table with a spherical index
  CREATE INDEX global_points_gix ON global_points USING GIST ( location );

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

-- Show a distance query and note, London is outside the 1000km tolerance
  SELECT name FROM global_points WHERE ST_DWithin(location, ST_GeographyFromText('SRID=4326;POINT(-110 29)'), 1000000);

GEOGRAPHYの威力については，シアトルからロンドンまで(LINESTRING(-122.33 47.606, 0.0 51.5))の飛行機がレイキャビク(POINT(-21.96 64.15))に最も近くなるときの距離を求めてみると分かります．

-- Distance calculation using GEOGRAPHY (122.2km)
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)':: geography);

-- Distance calculation using GEOMETRY (13.3 "degrees")
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)':: geometry);

GEOGRAPHY型は，レイキャビクとシアトル-ロンドン間の飛行機の大圏コースとの間の，球面上での本当に最も近い距離を計算します．

大圏コースマップ GEOMETRY型は，平面の世界地図上にプロットされたレイキャビクとシアトル-ロンドン間の直線とのデカルト距離という意味のない値を出します．結果の名目上の単位は「度」ですが，点間の本当の角度差にあっていませんので，「度」と言うこと自体不正確です．

GEOGRAPHY型によって，経度緯度座標でデータを格納できるようになりましたが， GEOGRAPHYで定義されている関数が，GEOMETRYより少ないのと，実行にCPU時間がかかる，というところが犠牲になっています．

選択した型が，期待する領域から出ないことを条件とすべきです． 使用するデータは地球全体か，大陸か，州か，自治体か?

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

spatial_ref_sysテーブルは，PostGISに含まれるもので，3000以上の空間参照系を持つ，OGC準拠のデータベーステーブルで，さらに言うと，空間参照系間の変換や投影変換に使われます．

PostGISのspatial_ref_sysテーブルには，projライブラリで使われる3000以上の一般に使われる空間参照系定義がありますが，全てを持っているわけではなく，proj4の構築に慣れているならカスタム投影を定義することができます．ほとんどの空間参照系は地域限定のもので，想定されている範囲の外で使うと意味が無いことにご留意ください．

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

よく共通的に使われる空間参照系は次の通りです． 4326 - WGS 84 経度緯度, 4269 - NAD 83 経度緯度, 3395 - WGS 84 メルカトル図法, 2163 - 米国ナショナルアトラス正積図法, NAD83, WGS84 UTM の空間参照系 - UTMゾーンは計測に最も理想的なもののひとつですが6度(訳注: 経度を指します)の領域しかカバーしません．

さまざまな米国の州の平面空間参照系(メートルまたはフィート単位) - 通常は州ごとに一つか二つあります．メートル単位のもののほとんどがPostGISのコアセットに入っていますが，多数のフィート単位のものやESRIが作ったものについては spatialreference.org から取得して下さい．

対象領域がどのUTMゾーンになるかを決めるには， utmzone PostGIS plpgsql helper function を参照して下さい．

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)
)

SPATIAL_REF_SYSのカラムは次の通りです．

GEOMETRY_COLUMNSテーブルは，次のように定義されています．

CREATE TABLE geometry_columns (
  f_table_catalog    VARRCHAR(256) NOT NULL,
  f_table_schema     VARCHAR(256) NOT NULL,
  f_table_nam        VARCHAR(256) NOT NULL,
  f_geometry_column  VARCHAR(256) NOT NULL,
  coord_dimension    INTEGER NOT NULL,
  srid               INTEGER NOT NULL,
  type               VARCHAR(30) NOT NULL
)

カラムについては次の通りです．

空間データを持つテーブルを生成するには，次の通り二段階で行います．

次はテーブルを作成して空間カラムを作る例です(128というSRIDがあると仮定します)．

CREATE TABLE parks (
  park_id    INTEGER,
  park_name  VARCHAR,
  park_date  DATE,
  park_type  VARCHAR
);
SELECT AddGeometryColumn('parks', 'park_geom', 128, 'MULTIPOLYGON', 2 );

もうひとつ，ジェネリックな"geometry"型とSRID不明を示す-1を使った例を挙げます．

CREATE TABLE roads (
  road_id INTEGER,
  road_name VARCHAR
);
SELECT AddGeometryColumn( 'roads', 'roads_geom', -1, 'GEOMETRY', 3 );

AddGeometryColumn()アプローチは，ジオメトリカラムを作成して，新しいカラムをgeometry_columnsテーブルに登録します． ソフトウェアでgeometry_columnsを使う場合には，クエリに必要なジオメトリカラムを全てこのテーブルに登録する必要があります． ジオメトリカラムをgeometry_columnsに登録したいけれどもAddGeometryColumnが使えないというケースとしては， SQLビューである場合と，巨大なデータ挿入の場合です． これらの場合はカラムをgeometry_columnsテーブルに手動で登録する必要があります．次に簡単な登録スクリプトを示します．

--次のように作ったビューがあるとしましょう
CREATE VIEW  public.vwmytablemercator AS
	SELECT gid, ST_Transform(the_geom,3395) As the_geom, f_name
	FROM public.mytable;

--このビューをgeometry_columnsに登録するには次のようにします．
INSERT INTO geometry_columns(f_table_catalog, f_table_schema, f_table_name, f_geometry_column, coord_dimension, srid, "type")
SELECT '', 'public', 'vwmytablemercator', 'the_geom', ST_CoordDim(the_geom), ST_SRID(the_geom), GeometryType(the_geom)
FROM public.vwmytablemercator LIMIT 1;


		

--巨大なデータ挿入によって派生テーブルを作ったとしましょう
SELECT poi.gid, poi.the_geom, citybounds.city_name
INTO myschema.myspecialpois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.the_geom, poi.the_geom);

--新しいデーブルにインデクスを作ります
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.myspecialpois USING gist(the_geom);

--手動でこの新しいテーブルのジオメトリカラムをgeometry_columnsに登録するには，ビューの時と同じようにします．
INSERT INTO geometry_columns(f_table_catalog, f_table_schema, f_table_name, f_geometry_column, coord_dimension, srid, "type")
SELECT '', 'myschema', 'myspecialpois', 'the_geom', ST_CoordDim(the_geom), ST_SRID(the_geom), GeometryType(the_geom)
FROM public.myschema.myspecialpois LIMIT 1;



		

PostGISはOpen Geospatial Consortium (OGC)のOpenGIS使用に準拠しています． このように，多くのPostGISメソッドは 操作するジオメトリが単純かつ妥当である必要がある(正確に言うとそう過程します)． たとえば，ポリゴンの外に穴があるようなものの面積を計算したり，単純でない境界線を持つポリゴンを作ったりするのは，意味がありません．

OGS仕様に沿うと，単純なジオメトリとは，自己インタセクトや自己接触があるような，異常な幾何点を持たないことです．主に0次元または1次元のジオメトリ([MULTI]POINT, [MULTI]LINESTRING)に適用します． 他方，ジオメトリの妥当性は，主に2次元ジオメトリ([MULTI]POLYGON))に適用し，妥当なポリゴンを特徴づける位置指定子の集合を定義します．個々のジオメトリクラスには，単純性と妥当性をさらに詳細に述べる特定の条件があります．

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

MULTIPOINTは，二つの座標値(POINT)が同じでないなら単純です．

LINESTRINGは2度同じPOINTを通らない(終点は除きます．この場合は線型環と呼ばれ，さらに閉じていると思われます)なら単純です．

(a)	(b)
(c)	(d)

(a)と(c)は単純なLINESTRINGで，(b)と(d)は単純ではありません．

MULTILINESTRINGは， 全ての要素が単純で，かつ任意の2要素のインタセクトが要素の境界であるPOINTでだけ発生する場合に限って， 単純です．

(e)

(f)

(g)

(e)と(f)は単純なMULTILINESTRINGで，(g)は単純ではありません．

定義からPOLYGONは常に単純です． バウンダリ内の環(外環と内環からなる)のうち二つがクロスしていないなら妥当です． POLYGONの境界は，POINTとインタセクトするかも知れませんが，接点にしかなりません(すなわち線上にない)． POLYGONは切られた線またはスパイク(訳注: ポリゴンから「スパイク」のように出た線)をもたなくても良く，内環は外環の中に完全に含まれていなければなりません．

(h)	(i)	(j)
(k)	(l)	(m)

(h)と(i)は妥当なPOLYGONです．(j-m)は単一のPOLYGONとしては表現できません．(j)と(m)は妥当なMULTIPOLYGONとして表現できません．

MULTIPOLYGONは，全ての要素が妥当で，ポリゴン要素のうち二つについて内環がインタセクトしていない場合のみ妥当です． ポリゴン要素の任意の二つの境界が接触してもよいですが，POINTの数は有限です．

(n)

(o)

(n)と(o)は妥当なMULTIPOLYGONです．

GEOSライブラリに実装されている関数のほとんどは，ジオメトリがOpenGIS Simple Feature Specificationで定義されているように妥当であると仮定しています．ジオメトリが単純であるか，また妥当であるか，のチェックとしてST_IsSimple()とST_IsValid()が使えます．

-- 一般的に，線型のフィーチャーの妥当性のチェックは，
-- 常にTRUEを返すので意味がありません．
-- しかし，この例では，PostGISは，線型の環(開始点と終了点が同じ)が
-- 二つ以下のバーテックからなる場合はFALSEを返すように
-- OGCのIsValidの定義を拡張しています．
gisdb=# SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)'),
   ST_IsValid('LINESTRING(0 0, 0 0)');

 st_isvalid | st_isvalid
------------+-----------
      t     |     f

デフォルトでは，PostGISはジオメトリ入力に関するこの妥当性チェックを適用しません． 複雑なジオメトリの妥当性のチェックはCPU時間を多く必要とするためです． データソースが信用できない場合は，手動でこのチェックを強制するための制限を付けることができます．

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

妥当な入力ジオメトリでPostGIS関数を呼んだのに "GEOS Intersection()がエラーを投げました!" や "JTS Intersection()がエラーを投げました!" というようなメッセージに遭遇したら，それはたぶん，PostGISまたは使用しているライブラリの中のエラーを発見しました． PostGIS開発者にコンタクトを取るべきです． PostGIS関数が妥当である入力ジオメトリから妥当でないジオメトリが返る場合も同じです．

	厳格にOGCジオメトリに準拠すると，Z値やM値を持てません． ST_IsValid()は高次を考慮に入れません． AddGeometryColumn()を実行するとジオメトリの次元をチェックする制約が加わるので，2をそこで指定することで十分です．

代表的な空間述語(ST_Contains, ST_Crosses, ST_Intersects, ST_Touches, ...)は， 求める空間フィルタを十分に提供しきれないことがあります．

たとえば，道路網を表現する線型のデータセットがあるとします．ビジネスルールを無視しているかも知れませんが，点でクロスするだけでなく線上でクロスする道路区間を全て判別することがGIS解析者の仕事となるかも知れません．この場合，ST_Crossesでは重要な空間フィルタとして十分ではありません．線型のフィーチャーでは，点でクロスしている場合のみtrueが返ります． 空間的にインタセクトしている(ST_Intersects)と判別された二つの区間の組み合わせについての実際のインタセクト(ST_Intersection)を取り， インタセクトのST_GeometryTypeが'LINESTRING'であるかを見る ([MULTI]POINT, [MULTI]LINESTRING等からなるGEOMETRYCOLLECTIONが返ってくる場合にしっかり対処します)，とい2段階の方法で解くことはできます． よりエレガントかつ速い解法が本当に望ましいでしょう．

二つ目の[理論的な]例として，GIS解析者が全ての湖の境界に線でインタセクトする波止場やドックの全ての位置を特定しようとするとします．ここで，波止場の一端だけ陸にあるとします．言いかえると，波止場が湖の中にあるが完全に中に入りきってはいなくて，湖と線でインタセクトして，波止場の一方の端が完全に湖に入っていて，かつもう一方の端点が境界線上にあります．解析者は空間述語の組み合わせでフィーチャーの後で探索対象を引き出さなくてはならないかも知れません． ST_Contains(lake, wharf) = TRUE ST_ContainsProperly(lake, wharf) = FALSE ST_GeometryType(ST_Intersection(wharf, lake)) = 'LINESTRING' ST_NumGeometries(ST_Multi(ST_Intersection(ST_Boundary(wharf), ST_Boundary(lake)))) = 1 ... (複雑なので以下略)

ここで，Dimensionally Extended 9 Intersection Modelまたは略してDE-9IMを見てみましょう．

4.3.6.1. 理論

OpenGIS Simple Features Implementation Specification for SQLによると「二つのジオメトリの比較の基本的なアプローチは，二つのジオメトリの内部，境界，外部のインタセクションの比較と，『インタセクション行列』の要素に基づく2ジオメトリの関係の分類です」．

境界(Boundary)

ジオメトリの境界はひとつ低い次元のジオメトリの集合です．0次元のPOINTの境界は空集合です．LINESTRINGの境界は二つの端点です．POLYGONの境界は外環と内環を形成する線です．

内部(Interior)

ジオメトリの内部は境界を取り去った際に残るジオメトリです． POINTの内部はPOINTそのものです．LINESTRINGの内部は二つの端点の間の実際の点です．POLYGONの内部はポリゴンの内側の範囲です．

外部(Exterior)

ジオメトリの外部は，内部と境界を除いた全領域です．

ジオメトリaがあり，aの内部，境界，外部をそれぞれI(a), B(a), E(a)とします．数学的な行列表現は次のようになります．

	内部	境界	外部
内部	dim( I(a) ∩ I(b) )	dim( I(a) ∩ B(b) )	dim( I(a) ∩ E(b) )
境界	dim( B(a) ∩ I(b) )	dim( B(a) ∩ B(b) )	dim( B(a) ∩ E(b) )
外部	dim( E(a) ∩ I(b) )	dim( E(a) ∩ B(b) )	dim( E(a) ∩ E(b) )

ここでdim(a)はaの次元で，ST_Dimensionで規定されますが，{0,1,2,T,F,*}の値域を持ちます．

• 0 => ポイント

• 1 => ライン

• 2 => 領域

• T => {0,1,2}

• F => 空集合

• * => 何でも良い

可視化すると，二つのオーバラップするポリゴンについては，次のようになります．

	内部 境界 外部 内部 dim(...) = 2 dim(...) = 1 dim(...) = 2 境界 dim(...) = 1 dim(...) = 0 dim(...) = 1 外部 dim(...) = 2 dim(...) = 1 dim(...) = 2

左から右，上から下に読むと，次元行列は'212101212'と表現されます．

一つ目の例である線上での2線のインタセクトは，関係行列で'1*1***1**'となります．

-- 線上でクロスする道路区間の判別
SELECT a.id
FROM roads a, roads b
WHERE a.id != b.id 
AND a.geom && b.geom
AND ST_Relate(a.geom, b.geom, '1*1***1**');

二つ目の例である一部が湖の水涯線上にある波止場は，関係行列で'102101FF2'となります．

-- 一部が湖の水涯線上にある波止場の判別
SELECT a.lake_id, b.wharf_id
FROM lakes a, wharfs b
WHERE a.geom && b.geom
AND ST_Relate(a.geom, b.geom, '102101FF2');

これ以上の情報ついては，次のページをご覧ください．

• OpenGIS Simple Features Implementation Specification for SQL (version 1.1, section 2.1.13.2)

• Dimensionally Extended Nine-Intersection Model (DE-9IM) by Christian Strobl

• Encyclopedia of GIS By Hui Xiong

データをテキスト表現に変換できるなら，フォーマットされたSQLを使うのがデータをPostGISに入れる最も簡単な方法です．Oracleや他のSQLデータベースを使うように，SQL端末モニタにSQLの"INSERT"ステートメントで一杯になった大きなテキストファイルをパイプで送ることで，大量のデータをロードできます．

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

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

データファイルは，次に示す"psql"というSQL端末モニタを使って，簡単にPostgreSQLにパイプで送られます．

psql -d [database] -f roads.sql

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

さらに，コマンドラインローダのほとんどのオプションに対応するshp2pgsql-guiグラフィカルユーザインタフェースがあります．一度限りでスクリプト化しないロードを行う場合や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

データベースからデータを引き出す最もストレートな手段は，次のように，SQLのSELECTクエリを使ってカラムを可読なテキストファイルとして出力することです．

db=# SELECT road_id, ST_AsText(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コマンドラインからジオメトリとボックスの特定を行うときは， "GeomFromText()"関数で，明示的に文字列表現をジオメトリに変換しなければならないことに注意して下さい．たとえば，次のようになります．

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom ~= ST_GeomFromText('LINESTRING(191232 243118,191108 243242)',-1);

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

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

SELECT road_id, road_name
FROM roads
WHERE roads_geom && ST_GeomFromText('POLYGON((...))',-1);

上のクエリでは，比較するためにポリゴンのバウンディングボックスを用いています．

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

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && SetSRID('BOX3D(191232 243117,191232 243119)'::box3d,-1);

ここで，BOX3Dの投影を指定していることに注意して下さい． SRIDを-1に設定しているのは，SRIDを指定しないということを示しています．

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

pgsql2shp [<オプション>] <データベース名> [<スキーマ名>.]<テーブル名>

pgsql2shp [<オプション>] <データベース名> <クエリ>

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

GiSTは「汎用的な検索木(Generalized Search Tree)」の意味で，インデックスの一般化された形式です．GISインデクスに加えて，GiSTは通常のB-Treeインデクスに従わない全ての種類の不規則なデータ構造(整数配列, スペクトラルデータ など)の検索速度を向上させるために使います．

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

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

CREATE INDEX [インデクス名] ON [テーブル名] USING GIST ( [ジオメトリカラム名] ); 

空間インデクスの構築は，計算量を集中させて行われます．100万行のテーブルで，300MHzのSolaris機ではGiSTインデクスの構築に概ね1時間かかりました．インデクスを構築したあとは，クエリプランの最適化に使うため，次のようにPostgreSQLにテーブル統計情報の収集をさせることが重要です．

VACUUM ANALYZE [テーブル名] [カラム名];
-- 次のクエリはPostgreSQL 7.4以前でのみ必要です
SELECT UPDATE_GEOMETRY_STATS([table_name], [column_name]);

GiSTインデクスはPostgreSQLのR-Treeインデクスより二つの利点を持っています．まず，GiSTインデクスは「NULLセーフ」，すなわちnull値を含むインデクスカラムで利用できることです．次に，GiSTインデクスはGISオブジェクトがPostgreSQLで8Kのページサイズを超えるサイズを扱う際に重要な「不可逆」の概念を持っていることです．不可逆にすることによって，PostgreSQLは，インデクスにおけるオブジェクトの「重要な」部分，GISオブジェクトの場合にはバウンディングボックスになりますが，これのみを納めることができます． R-Treeインデクスで8Kを超えるGISオブジェクトのインデクスを構築しようとすると，失敗します．

通常，インデクスは見えないところでデータアクセスの速度向上を行います．すなわち，ひとたびインデクスが構築されたら，クエリプランナは透過的に，クエリプランの速度を向上させるためにインデクス情報を使うべき時を判断します．残念なことに，PostgreSQLクエリプランナは，GiSTインデクスの使用について十分に最適化できず，時々，検索で空間インデクスを使用すべきなのに，テーブルを順に走査することがあります．

空間インデクスが使用されていない(または属性インデクスがその問題のために使用されていない)場合，次の二つのことができます．

クエリを作成するとき，&&のようなバウンディングボックスを基準とした演算子によってのみGiST空間インデクスの利点が出てくることだけは覚えておくことが重要です． distance()のような関数では演算の最適化を行うためにインデクスを使うことができません．たとえば，次のクエリでは，大きなテーブルでは本当に遅くなります．

SELECT the_geom
FROM geom_table
WHERE ST_Distance(the_geom, ST_GeomFromText('POINT(100000 200000)', -1)) < 100

このクエリは，geom_tableにおける (100000, 200000) の点から距離が100単位以内にある全てのジオメトリを選択します．これは，テーブル内にあるそれぞれの点と指定した点との距離を計算する，すなわち，それぞれの行でひとつのST_Distance()計算を行うため，遅くなるのです．これは，&&演算子を使うと，求められる距離計算の量を減らすことで回避できます．次のようにします．

SELECT the_geom
FROM geom_table
WHERE the_geom && 'BOX3D(90900 190900, 100100 200100)'::box3d
  AND
ST_Distance(the_geom, ST_GeomFromText('POINT(100000 200000)', -1)) < 100

このクエリは，同じジオメトリを選択しますが，より効果的な方法で行われます．the_geomにGiSTインデクスがあると仮定すると，クエリプランナはdistance()関数の結果を計算する前にインデクスを使って行を減らせると認識します． &&演算子で使われているBOX3Dジオメトリは，原点を中心とした一辺 200単位の正方形です． これは「クエリボックス」です．&&演算子は 結果セットを「クエリボックス」にオーバラップするバウンディングボックスを持つジオメトリだけに素早く減らすためにインデクスを使います．「クエリボックス」がジオメトリテーブル全体の範囲より十分に小さいと仮定すると，行われなければならない距離計算の量は劇的に減少します．

	ふるまいの変更
	PostGIS 1.3.0では，ST_DisjointとST_Relateの注目すべき例外がありますが，ほとんどのジオメトリ関係関数は暗黙的なバウンディングボックスオーバラップ演算子を含んでいます．

本節の例では，線形の道，ポリゴンの自治体境界，の二つのテーブルを使います．テーブルの定義は，bc_roadsについては次の通りです．

Column      | Type              | Description
------------+-------------------+-------------------
gid         | integer           | Unique ID
name        | character varying | Road Name
the_geom    | geometry          | Location Geometry (Linestring)

bc_municipalityの定義は次の通りです．

Column     | Type              | Description
-----------+-------------------+-------------------
gid        | integer           | Unique ID
code       | integer           | Unique ID
name       | character varying | City / Town Name
the_geom   | geometry          | Location Geometry (Polygon)

SELECT sum(ST_Length(the_geom))/1000 AS km_roads FROM bc_roads;

km_roads
------------------
70842.1243039643
(1 row)

SELECT
  ST_Area(the_geom)/10000 AS hectares
FROM bc_municipality
WHERE name = 'PRINCE GEORGE';

hectares
------------------
32657.9103824927
(1 row)

SELECT
  name,
  ST_Area(the_geom)/10000 AS hectares
FROM
  bc_municipality
ORDER BY hectares DESC
LIMIT 1;

name           | hectares
---------------+-----------------
TUMBLER RIDGE  | 155020.02556131
(1 row)

SELECT
  m.name,
  sum(ST_Length(r.the_geom))/1000 as roads_km
FROM
  bc_roads AS r,
  bc_municipality AS m
WHERE
  ST_Contains(m.the_geom,r.the_geom)
GROUP BY m.name
ORDER BY roads_km;

name                        | roads_km
----------------------------+------------------
SURREY                      | 1539.47553551242
VANCOUVER                   | 1450.33093486576
LANGLEY DISTRICT            | 833.793392535662
BURNABY                     | 773.769091404338
PRINCE GEORGE               | 694.37554369147
...

CREATE TABLE pg_roads as
SELECT
  ST_Intersection(r.the_geom, m.the_geom) AS intersection_geom,
  ST_Length(r.the_geom) AS rd_orig_length,
  r.*
FROM
  bc_roads AS r,
  bc_municipality AS m
WHERE  m.name = 'PRINCE GEORGE' AND ST_Intersects(r.the_geom, m.the_geom);

SELECT
  sum(ST_Length(r.the_geom))/1000 AS kilometers
FROM
  bc_roads r,
  bc_municipality m
WHERE  r.name = 'Douglas St' AND m.name = 'VICTORIA'
	AND ST_Contains(m.the_geom, r.the_geom) ;

kilometers
------------------
4.89151904172838
(1 row)

SELECT gid, name, ST_Area(the_geom) AS area
FROM bc_municipality
WHERE ST_NRings(the_geom) > 1
ORDER BY area DESC LIMIT 1;

gid  | name         | area
-----+--------------+------------------
12   | SPALLUMCHEEN | 257374619.430216
(1 row)

MapServerでPostGISを使うには，MapServerのコンフィギュレーション方法について必要ですが，この文書の範囲外です．この節では，PostGIS特有の問題とコンフィギュレーション詳細をカバーします．

PostGISをMapServerで使うには，次のことが必要です．

MapServerは，他のPostgreSQLクライアントのように，libpqインタフェースを使って，PostGIS/PostgreSQLデータにアクセスします．よってMapServerはPostGISサーバにアクセスするネットワークを持つ計算機にインストールでき，PostGISをデータソースとして使用することができます．システム間の接続は速いほど良いです．

USING疑似SQL節を使ってMapServerがより複雑なクエリの結果を理解できるようにするための情報を追加します．より詳しく言うと，ビューまたは副問い合わせが元テーブル(DATA定義で"FROM"の右にあるもの)として使われる時， MapServerが自動的に一意な識別子がそれぞれの行にあるか，また，SRIDがテーブルにあるかを判別するのは困難です． USING節によって，MapServerがこれらの情報を得ることができます．例を次に挙げます．

DATA "the_geom FROM (
  SELECT 
    table1.the_geom AS the_geom, 
    table1.oid AS oid, 
    table2.data AS data 
  FROM table1 
  LEFT JOIN table2 
  ON table1.id = table2.id
) AS new_table USING UNIQUE gid USING SRID=-1"

簡単な例から始めて，ステップアップしていきましょう．次のMapServerレイヤ定義を考えて下さい．

LAYER 
  CONNECTIONTYPE postgis 
  NAME "roads"
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" 
  DATA "the_geom from roads" 
  STATUS ON 
  TYPE LINE 
  CLASS 
    STYLE
      COLOR 0 0 0 
    END
  END 
END

このレイヤは"roads"テーブルにある道路ジオメトリの全部を黒線で表示するものです．

では，少なくとも1:100000にズームするまでは高速道路だけを表示したい，と言ってみましょう．次の二つのレイヤで，その効果が実現できます．

LAYER 
  CONNECTIONTYPE postgis 
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" 
  PROCESSING "CLOSE_CONNECTION=DEFER"
  DATA "the_geom from roads"
  MINSCALE 100000 
  STATUS ON 
  TYPE LINE 
  FILTER "road_type = 'highway'" 
  CLASS 
    COLOR 0 0 0 
  END 
END 
LAYER 
  CONNECTIONTYPE postgis 
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  PROCESSING "CLOSE_CONNECTION=DEFER"
  DATA "the_geom from roads" 
  MAXSCALE 100000 
  STATUS ON 
  TYPE LINE
  CLASSITEM road_type 
  CLASS 
    EXPRESSION "highway" 
    STYLE
      WIDTH 2 
      COLOR 255 0 0  
    END
  END 
  CLASS  
    STYLE
      COLOR 0 0 0 
    END
  END 
END

一つ目のレイヤはスケールが1:100000以上であるときに使われ，道路タイプが"highway"である道路のみ黒線で表示されます．FILTERオプションによって，道路タイプが"highway"の場合のみ表示することになります．

二つ目のレイヤはスケールが1:100000未満である時に使われ，"highway"は赤い二重細線で表示され，他の道路は黒線で表示されます．

さて，Mapserverの機能を使うだけで，二つのおもしろいことを実行しました．しかし，DATAのSQLステートメントは，単純なままです．道路名が(どういう理由かは知りませんが)他のテーブルに収められていて，それのデータを取得するためにテーブルを接続して，道路のラベルを取る必要がある，とします．

LAYER 
  CONNECTIONTYPE postgis
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" 
  DATA "the_geom FROM (SELECT roads.oid AS oid, roads.the_geom AS the_geom, 
        road_names.name as name FROM roads LEFT JOIN road_names ON 
        roads.road_name_id = road_names.road_name_id) 
        AS named_roads USING UNIQUE oid USING SRID=-1" 
  MAXSCALE 20000 
  STATUS ON 
  TYPE ANNOTATION 
  LABELITEM name
  CLASS 
    LABEL 
      ANGLE auto 
      SIZE 8 
      COLOR 0 192 0 
      TYPE truetype 
      FONT arial
    END
  END 
END

このANNOTAIONレイヤでは，縮尺が1:20000以下のときに，全ての道路に緑色のラベルを表示します．また，この例は，DATA定義で，SQLのJOINを使用する方法も示しています．

...

...

現版のPostgreSQL(8.0を含む)では，TOASTテーブルに従うクエリオプティマイザの弱さに苦しみます． TOASTテーブルは，(長いテキスト，イメージ，多数の頂点を持つ複合ジオメトリといった)通常のデータページに適合しない，(データサイズという意味では)巨大な値を納めるための「拡張部屋」の一種です．詳細情報は http://www.postgresql.org/docs/8.0/static/storage-toast.html をご覧ください．

高解像度で全てのヨーロッパの国の境界を含むテーブルのような)大きなジオメトリがあるうえ，行がそう多くないテーブルを持つようになると，この問題が出てきます．テーブル自体は小さいのですが，多くのTOASTスペースを使います．例として，テーブル自体は概ね80行で3データページしか使わなくてもTOASTテーブルで8225ページを使うとします．

ここで，ジオメトリ演算子の&&を使って，ほとんどマッチしないようなバウンダリボックスを検索するクエリを出してみます．クエリオプティマイザにはテーブルは3ページ80行しかないように見えます．オプティマイザは，小さなテーブルを順に走査する方がインデクスを使うよりも早いと見積もります．そして，GiSTインデクスは無視すると決めます．通常なら，この見積もりは正しいです．しかし，この場合は &&演算子が全てのジオメトリをディスクから呼び出しでバウンディングボックスと比較しなければならなくなり，ゆえに，全てのTOASTページもまた呼び出す必要があります．

このバグに苦しむかどうかを見るには，PostgreSQLの"EXPLAIN ANALYZE"コマンドを使います．詳しい情報と技術に関する詳細については，postgres performance mailing list のスレッド ( http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php ) をご覧下さい．

PostgreSQLコミュニティでは，TOASTを意識したクエリ見積もりを作ることで，この問題を解決しようとしています．今のところは，二つの応急処置があります．

一つ目は，クエリプランナにインデクスの使用を強制することです．クエリを発行する前に"SET enable_seqscan TO off;"をサーバに送信します．これは基本的にクエリプランナに対して可能な限り順に走査することを避けるよう強制します．そのためGiSTインデクスを通常使うようになります．しかし，このフラグは接続するたびに設定しなければならず，他のケースにおいてはクエリプランナに誤った見積もりをさせることになるので， "SET enable_seqscan TO on;"をクエリの後に送信すべきです．

二つ目は，順に走査することをクエリプランナが考える程度に早くすることです．これは，バウンダリボックスの「キャッシュ」を行う追加カラムを作成し，このカラムにマッチさせるようにすることで達成することができます．ここでの例では次のようになります．

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2'); 
UPDATE mytable SET bbox = ST_Envelope(ST_Force_2d(the_geom));

そして，次のように，&&演算子をgeom_columnに対して行っていたものをbboxに変更します．

SELECT geom_column 
FROM mytable 
WHERE bbox && ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);

もちろん，mytableの行を変更または追加したら， bboxを「同期」するようにしなければなりません．最もすっきりした方法はトリガです．アプリケーションを変更してbboxカラムの現状を保持するか，テーブル更新後にいつもUPDATEクエリを実行するかでも対応できます．

これらの設定はpostgresql.conf内にあります．

checkpoint_segment_size (この設定は新しいバージョンのPostgreSQLでは非推奨)は，checkpoint や WAL ではじまる多数の設定に入れ替えられました．

constraint_exclusion

shared_buffers

work_mem (ソート処理や複雑なクエリに使われるメモリ)

maintenance_work_mem (VACUUM, CREATE INDEX 等で使用)