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

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

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

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は大きなジオメトリを表示しません。ジオメトリカラムがそうなっていないか最も良い方法は次の通りです。

-- 全てのジオメトリフィールドに値が入っている場合
-- レコードが返りません。
SELECT somefield FROM mytable WHERE geom IS NULL;

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

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

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

長い答: 「ジオグラフィ型をジオメトリ型にして使用すべき時 」と関数タイプマトリクスを参照して下さい。

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

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

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

CREATE TABLE gtest ( ID int4, NAME varchar(20) );
SELECT AddGeometryColumn('', 'gtest','geom',-1,'LINESTRING',2);

ジオメトリカラムの追加に失敗する場合は、もしかしたら PostGIS の関数とオブジェクトをデータベースにロードしていないのかも知れません。「インストール」を参照して下さい。

これで、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)', -1)
);

他の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 [indexname] ON [tablename] USING GIST ( [geometrycolumn] );

"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-Treeインデクスを使っていましたが、0.6版でPostgreSQLのR-Treeは完全に捨てて、R-Tree-over-GiSTスキームによる空間インデクスを提供しています。

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

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 84経度緯度に投影しています。このクエリはthe_geomが-1(空間参照系が定義されていない)でない場合のみ動作します。

SELECT ST_Transform(the_geom,4269) FROM geotable;

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

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

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

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

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