OpenGeoが手順ごとのチュートリアルガイドワークショップIntroduction to PostGISを出しています。OpenGeo Suiteでの作業の入門編だけでなく梱包されたデータもあります。PostGISの最善のチュートリアルかも知れません。

BostonGISにもPostGIS almost idiot's guide on getting startedがあります。Windowsユーザに、より軸足を置いています。

PostGIS 2.0で、多数の非推奨関数がPostGISコードから削除されました。これは、GeoServer, MapServer, QuantumGIS, OpenJump等のサードバーティツールに加えて、アプリケーションにも影響が出ます。これを解決する方法が二つあります。サードパーティアプリケーションの場合は、これらの問題の多くが解決されている最新版にアップグレードしてみることで対応できます。 ご自身のコードの場合は、削除された関数を使わないようにソースを変更することで対応できます。 削除された関数のほとんどは、ST_Unino, ST_Length等のエイリアスで、ST_を取ったものです。最後の手段としてlegacy.sqlの全体またはlegacy.sqlの必要な部分をインストールします。

legacy.sqlファイルはpostgis.sqlのインストール先と同じフォルダにあります。postgis.sqlとspatial_ref_sys.sqlをインストールした後、このファイルをインストールすると、削除した200余の関数を復帰させられます。

PostGIS 2では、デフォルトのジオメトリ演算子クラスがgist_geometry_opsからgist_geometry_ops_2dに変更され、gist_geometry_opsは完全に削除されました。PostGIS 2は3次元対応のためN次元空間インデクスを導入しました。古い名前は混乱させるものであり、誤称であると考えました。

古いアプリケーションには、処理の一部として、テーブルやインデクスを生成する際に、明示的に演算子クラス名を参照しているものがありました。デフォルトの2次元インデクスが欲しい場合には重要ではありません。エラーが内容に管理するために、インデクス生成を次に示す悪い例から良い例に変えて下さい。

悪い例

CREATE INDEX idx_my_table_geom ON my_table USING gist(geom gist_geometry_ops);

良い例

CREATE INDEX idx_my_table_geom ON my_table USING gist(geom);

演算子クラスを指定する必要が出るのは、3次元空間が求められる場合です。次のようにします。

CREATE INDEX idx_my_super3d_geom ON my_super3d USING gist(geom gist_geometry_ops_nd);

不幸にもgist_geometry_opsがハードコーディングされていて変更不可なコンパイルされたコードを突きつけられているなら、PostGIS 2.0.2以上に同梱されているlegacy_gist.sqlを使用して、古いクラスを生成することができます。しかしながら、この方法を使う場合は、後ほどインデクスを削除して、演算子クラスを指定せずに再生成させるべきです。将来再びアップデートする必要がある時に泣いてしまうことを抑制します。

PostgreSQL 9.0以上では、byteaデータのデフォルトのエンコーディングがhexに変更されました。古いJDBCドライバはエスケープ形式を仮定しています。古いJDBCドライバを使ったJavaアプリケーションや古いNpgsqlドライバを使った.Netアプリケーションといった、ST_AsBinaryの古い挙動を期待するアプリケーションが影響を受けます。再び動作させるには二つの方法があります。

JDBCドライバを最新のPostgreSQL 9.0版にアップグレードします。http://jdbc.postgresql.org/download.htmlからダウンロードできます。

.Netアプリケーションについては、Npgsql 2.0.11以上を使います。http://pgfoundry.org/frs/?group_id=1000140からダウンロードできます。また、Francisco Figueiredo's NpgSQL 2.0.11 released blog entryに説明があります。

PostgreSQLドライバのアップグレードが選択できないなら、デフォルトで古い挙動をするようにします。次のようにします。

ALTER DATABASE mypostgisdb SET bytea_output='escape';

pgAdminは大きなジオメトリを表示しません。ジオメトリカラムがそうなっていないかを確かめる最善の方法は次の通りです。

-- this should return no records if all your geom fields are filled in
SELECT somefield FROM mytable WHERE geom IS NULL;

-- ジオメトリがどれぐらい大きいかを調べるには
-- ジオメトリカラムの中でジオメトリごとに、それが持つポイントの数を
-- 尋ねるかたちのクエリを実行します
SELECT MAX(ST_NPoints(geom)) FROM sometable;

ポイント、ラインストリング、ポリゴン、マルチポイント、マルチラインストリング、マルチポリゴン、ジオメトリコレクションです。PostGIS 2.0以上では、基本ジオメトリタイプとしてTINと多面体サーフェスも格納できます。これらはOpen GIS Well Known Text形式(XYZ, XYM, XYZM拡張付き)で指定されます。現在サポートされているのは3つのデータ型です。計測に平面座標系を使う標準OGCジオメトリデータ型があります。また、地理座標系を使い、球面または回転楕円体面上の計算を行うジオグラフィデータ型があります。最新のPostGIS空間型群に追加されたのが、ラスタデータの格納と解析に使われるラスタ型です。ラスタ型単独で「よくある質問」を用意しています。詳細についてはChapter 10, PostGISラスタ よくある質問とChapter 9, ラスタ リファレンスをご覧ください。

短い答: ジオグラフィは長距離の測定をサポートする新しいデータ型ですが、計算速度は現在のところジオメトリの計算より遅いです。ジオグラフィを使う場合は、平面座標系についてあまり多く学習する必要がありません。行うことが距離や長さの計測に限定され、かつ世界中からのデータを持っている場合は、一般的にジオグラフィが最善です。ジオメトリは古いデータ型で、サポートする関数が多く、サードパーティからの多大なサポートが得られます。計算速度も早く、大きなジオメトリでは10倍違います。空間参照系に慣れているか、空間参照系 (SRID)が単一で済むような局所的なデータを扱っているか、あるいは、空間処理を多く行う必要がある場合には、ジオメトリが最善です。ご注意: 簡単に二つの型の相互変換を行ってそれぞれの利点を得ることができます。現在サポートされているもの、サポートされていないものについてはSection 14.11, “PostGIS Function Support Matrix”を参照して下さい。

長い答: Section 4.2.2, “ジオグラフィ型をジオメトリ型にして使用すべき時”とfunction type matrixとを参照して下さい。

その質問は相当深く複雑で、このセクションで十分に答えられません。Section 4.2.3, “ジオグラフィに関する高度なよくある質問”を参照して下さい。

まず、GISデータを保持するために"geometry"または"geogprahy"カラムを持つテーブルを作成します。ジオグラフィデータ型の格納は、ジオメトリデータ型とは若干異なります。ジオグラフィの格納についてはSection 4.2.1, “ジオグラフィ基礎”を参照して下さい。

ジオメトリについては、psqlでデータベースに接続して、次のSQLを試してみて下さい。

CREATE TABLE gtest ( gid serial primary key, name varchar(20)
        , geom geometry(LINESTRING) );

ジオメトリカラムの追加に失敗する場合は、もしかしたらPostGISの関数とオブジェクトをデータベースにロードしていないか、2.0より前の版のPostGISなのかも知れません。Section 2.4, “ソースからのコンパイルとインストール: 詳細”を参照して下さい。

これで、SQLのINSERTステートメントを使って、ジオメトリをテーブルに挿入することができます。GISオブジェクト自体は、OpenGISコンソーシアムの"well-known text"形式を使っています。

INSERT INTO gtest (ID, NAME, GEOM)
VALUES (
  1,
  'First Geometry',
  ST_GeomFromText('LINESTRING(2 3,4 5,6 5,7 8)')
);

他のGISオブジェクトの詳細についてはobject referenceをご覧ください。

テーブル内にあるGISデータを表示するには、次のようにします。

SELECT id, name, ST_AsText(geom) AS geom FROM gtest;

返り値は次のようなかんじになります。

id | name           | geom
----+----------------+-----------------------------
  1 | First Geometry | LINESTRING(2 3,4 5,6 5,7 8)
(1 row)

他のデータベースクエリを作るのと同じで、返り値、関数、テストのSQLの組み合わせです。

空間クエリでは、クエリを作成する際に心を平静に保つための重要な二つの問題があります。 一つは、使用することができる空間インデクスがあるか、です。もう一つは、多数のジオメトリを相手に計算量の多い計算を行っているか、です。

一般的に、フィーチャーのバウンディングボックスがインタセクト (交差)しているかをテストするインタセクト演算子 (&&)を使います。&&演算子が便利な理由は、速度向上のために空間インデクスが付けられているなら、&&演算子は空間インデクスを使うからです。これによって、クエリの速度はとてもとても速くなります。

また、検索結果をより狭めるために、Distance(), ST_Intersects(), ST_Contains(), ST_Within() などといった空間関数を使うことでしょう。ほとんどの空間クエリは、インデクスのテストと空間関数のテストを含みます。インデクスのテストで返ってくるタプルを、求める条件に合致するかもしれないタプルのみとして、タプルの数を制限します。それから、空間関数で確実な条件のテストを行います。

SELECT id, the_geom
FROM thetable
WHERE
  ST_Contains(the_geom,'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))');

大きなテーブルの速いクエリは、空間データベースのレゾンデートル (トランザクションサポートもそうですが)で、良いインデクスは重要です。

geometryカラムを持つテーブルでの空間インデクスの構築は、"CREATE INDEX"を使って、次のようにします。

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

"USING GIST"オプションによって、サーバにGiST (Generalized Search Tree)インデクスを作るよう指示が渡ります。

	GiSTインデクスは、不可逆であると仮定します。不可逆インデクスの構築には、代理オブジェクト (空間インデクスの場合はバウンディングボックス)を使います。

PostgreSQLのクエリプランナがインデクスを作るべきかについて合理的な決定を行うよう、十分な情報を確実に持てるようにすべきです。そのために、ジオメトリテーブル上で"gather statistics"を実行しなければなりません。

PostgreSQL 8.0.x以上では、VACUUM ANALYZEコマンドを実行するだけです。

PostgreSQL 7.4.x以下では、SELECT UPDATE_GEOMETRY_STATS()を実行します。

PostGISの、かつての版では、PostgreSQLのR木インデクスを使っていましたが、0.6版でPostgreSQLのR木は完全に捨てて、R-Tree-over-GiSTスキームによる空間インデクスを提供しています。

私たちの試験では、R木とGiSTの検索速度は同程度であることが示されています。PostgreSQLのR木には、GISフィーチャーで使うためには好ましくない二つの制限があります (これらの制限は現在のPostgreSQLネイティブのR木実装についてであって、R木一般の話ではありません)。

OpenGIS関数を使いたくないのでしたら、使う必要はありません。単純にジオメトリカラムをCREATEステートメントで定義する古いやり方で作成して下さい。全てのジオメトリはSRIDが-1になり、OpenGISメタデータテーブルは適切に書き込まれません。これによって、ほとんどのPostGISベースのアプリケーションでは失敗します。一般的にはAddGeometryColumn()を用いることをお勧めします。

MapServerはgeometry_columnsメタデータを使うアプリケーションのひとつです。踏み込んでいえば、MpaServerはジオメトリカラムのSRIDを使って、正しい地図投影へのフィーチャーの自動投影変換を行います。

データベースを最も効果的に使うには、半径検索とバウンディングボックス検索を組み合わせた半径検索を行うのが最も良いです。バウンディングボックス検索で空間インデクスを使用するので、半径検索が適用されるサブセットへのアクセスが早くなります。

ST_DWithin(geometry, geometry, distance)関数は、インデクス付きの距離検索を実行する手軽な方法です。この関数は、距離半径を十分に含む大きさの検索矩形を作成して、 インデクス付きの結果サブセットに対して確実な距離検索を行います。

たとえば、POINT(1000 1000)から100メートル内の全てのオブジェクトを見つけるためには、次のクエリで動作します。

SELECT * FROM geotable
WHERE ST_DWithin(geocolumn, 'POINT(1000 1000)', 100.0);

投影変換を行うには、変換元と変換先双方の座標系がSPATIAL_REF_SYSテーブルに定義されていて、 かつ投影変換されるジオメトリがそのSRIDを持っている必要があります。これが行われていると、投影変換は求める変換先SRIDを参照するのと同じぐらい簡単です。次のクエリは、ジオメトリをNAD 83経度緯度に投影しています。このクエリはthe_geomが-1 (空間参照系が定義されていない)でない場合のみ動作します。

SELECT ST_Transform(the_geom,4269) FROM geotable;

pgAdminまたは大きなテキストを表示しないその他のツールを使用しているのかも知れません。 ジオメトリが十分に大きい場合、ツールには空として表示されます。本当にWKTで見たり出力したりしなければならない場合は、PSQLを使用して下さい。

-- 本当に空のジオメトリの数を検索します
                                SELECT count(gid) FROM geotable WHERE the_geom IS NULL;

二つの場合がよくあります。一つは、ジオメトリが不正な場合です。ST_IsValidで確認できます。もう一つは、ST_AsTextで数字を切り捨てていて、表示されている分より後にたくさんの小数が付いている場合です。

ほぼ確実に違います。 例として、Linux上で動作するOracleを考えてみます。 LinuxはGPLでOracleは違いますが、Linuxで動作するOracleはGPLで配布しなければならないでしょうか?違います。あなたのソフトウェアはPostgreSQL/PostGISデータベースを好きなだけ使うことができ、ライセンスは好きなようにできます。

PostGISソースコードに変更を加えて、変更したPostGISを配布したときだけは例外です。この場合、変更したPostGISのコードを共有しなければなりません (PostGIS上で動作するアプリケーションのコードではありません)。この限られた場合でも、ソースコードはバイナリの配布相手にだけ配布します。GPLはソースコードの公開までは求めておらず、バイナリを配布した相手との共有を求めています。