PostGIS 1.3.6 マニュアル

概要

PostGISは、オブジェクトRDBであるPostgreSQLの拡張で、GIS (地理情報システム)オブジェクトを格納することができます。PostGISは、GiSTベースのR木空間インデックスをサポートし、GISオブジェクトの解析および処理を行う機能を持ちます。

本マニュアルは、 1.3.6版のマニュアルです。


目次

1. 導入
1.1. 貢献者
1.2. 追加情報
2. インストール
2.1. 必要なもの
2.2. PostGISをソースからコンパイルおよびインストールする
2.2.1. 組み込みテンプレートからPostGIS空間データベースを生成する
2.2.2. アップグレード
2.2.3. 共通の問題
2.3. JDBC
2.4. ローダ/ダンパ
3. よくある質問
4. PostGISを使う
4.1. GISオブジェクト
4.1.1. OpenGIS WKBとWKT
4.1.2. PostGIS EWKB, EWKTと標準形式
4.1.3. SQL-MM第3部
4.2. OpenGIS標準を使う
4.2.1. SPATIAL_REF_SYSテーブル
4.2.2. GEOMETRY_COLUMNSテーブル
4.2.3. 空間テーブルを作る
4.2.4. ジオメトリのOpenGIS準拠を確実にする
4.3. GISデータのロード
4.3.1. SQLを使う
4.3.2. ローダを使う
4.4. GISデータを検索する
4.4.1. SQLを使う
4.4.2. ダンパを使う
4.5. インデックスを構築する
4.5.1. GiSTインデックス
4.5.2. インデックスを使う
4.6. 複雑なクエリ
4.6.1. インデックスの利点を使う
4.6.2. 空間SQLの例
4.7. MapServerを使う
4.7.1. 基本的な使い方
4.7.2. よくある質問
4.7.3. 踏み込んだ使用法
4.7.4. 例
4.8. Javaクライアント (JDBC)
4.9. Cクライアント (libpq)
4.9.1. テキストカーソル
4.9.2. バイナリカーソル
5. 性能向上に関する技法
5.1. 大きなジオメトリを持つ小さなテーブル
5.1.1. 問題の説明
5.1.2. 応急処置
5.2. ジオメトリインデックスでCLUSTERを実行する
5.3. 次元変換の回避
6. PostGISリファレンス
6.1. OpenGIS関数
6.1.1. 管理関数
6.1.2. 空間関係関数
6.1.3. ジオメトリ処理関数
6.1.4. ジオメトリアクセサ
6.1.5. ジオメトリ コンストラクタ
6.2. PostGIS独自拡張
6.2.1. 管理関数
6.2.2. 演算子
6.2.3. 計測関数
6.2.4. ジオメトリ出力
6.2.5. ジオメトリ コンストラクタ
6.2.6. ジオメトリエディタ
6.2.7. 線型参照
6.2.8. その他の関数
6.2.9. Long Transactions support
6.3. SQL-MM関数
6.4. ArcSDE関数
7. 問題を報告する
7.1. ソフトウェアのバグを報告する
7.2. 文書の問題を報告する
A. 付録
A.1. リリースノート
A.1.1. リリース 1.3.6
A.1.2. リリース 1.3.5
A.1.3. リリース 1.3.4
A.1.4. リリース 1.3.3
A.1.5. リリース 1.3.2
A.1.6. リリース 1.3.1
A.1.7. リリース 1.3.0
A.1.8. リリース 1.2.1
A.1.9. リリース 1.2.0
A.1.10. リリース 1.1.6
A.1.11. リリース 1.1.5
A.1.12. リリース 1.1.4
A.1.13. リリース 1.1.3
A.1.14. リリース 1.1.2
A.1.15. リリース 1.1.1
A.1.16. リリース 1.1.0
A.1.17. リリース 1.0.6
A.1.18. リリース 1.0.5
A.1.19. リリース 1.0.4
A.1.20. リリース 1.0.3
A.1.21. リリース 1.0.2
A.1.22. リリース 1.0.1
A.1.23. リリース 1.0.0
A.1.24. リリース 1.0.0RC6
A.1.25. リリース 1.0.0RC5
A.1.26. リリース 1.0.0RC4
A.1.27. リリース 1.0.0RC3
A.1.28. リリース 1.0.0RC2
A.1.29. リリース 1.0.0RC1

第1章 導入

PostGISは Refractions Research Incが空間データベース技術研究プロジェクトとして開発しました。Refractionsはカナダ・ブリティッシュコロンビア州・ビクトリアにある、データインテグレーションとカスタムソフトウェア開発に特化した、GISとデータベースのコンサルティング会社です。私たちは完全なOpenGISサポート、高度なトポロジ構成(カバレッジ、サーフェス、ネットワーク)、GISデータの表示と編集をするためのデスクトップユーザインタフェースツール、ウェブベースのアクセスツールを持つ、重要なGIS機能性の範囲をサポートするPostGISを、サポートおよび開発する予定です。

1.1. 貢献者

Mark Cave-Ayland

バグフィクスとメインテナンス活動、PostgreSQLのリリースとの調整、Windowsのビルド、新しいGEOS機能の統合および新しい関数の強化に関する調整。

Paul Ramsey

リリース管理者。総合的な指示だが、しばしば実際のコーディングに手を染める。

Mark Leslie

コア関数のメンテナンスと開発の進行。

Kevin Neufeld

文書、Hudson automatedのビルド、PostGISニュースグループでの高度なユーザサポート。

Sandro Santilli

誤り訂正および新しいGEOS機能のメンテナンスならびに統合

Chris Hodgson

総合的な開発

Dave Blasby

PostGISのオリジナル開発者。サーバサイドオブジェクト、インデックスバインディング、 サーバサイドの解析関数を書きました。

Jeff Lounsbury

シェープファイルのローダ/ダンパのオリジナル開発者

他の貢献者

ABC順で: Alex Bodnaru, Alex Mayrhofer, Barbara Phillipot, Ben Jubb, Bernhard Reiter, Bruce Rindahl, Bruno Wolff III, Carl Anderson, Charlie Savage, Dane Springmeyer, David Skea, David Techer, Eduin Carrillo, IIDA Tetsushi, Geographic Data BC, Gerald Fenoy, Gino Lucrezi, Klaus Foerster, Kris Jurka, Mark Sondheim, Markus Schaber, Michael Fuhr, Nikita Shulga, Norman Vine, Olivier Courtin, Ralph Mason, Regina Obe, Steffen Macke, Stephen Frost.

重要なサポートライブラリ

GEOSはジオメトリ操作ライブラリで、 Martin Davisがアルゴリズムを作成し、Mateusz Loskot、Paul Ramseらで動作するようにし、メンテナンスとサポートの進行を行っています。

Proj4は地図投影ライブラリで、 Gerald EvendenとFrank Warmerdamによって作成とメンテナンスがされています。

1.2. 追加情報

第2章 インストール

2.1. 必要なもの

PostGISのビルドと利用のために、次のものが必要です。

  • PostgreSQLの完全なインストール (サーバヘッダを含む)。PostgreSQLはhttp://www.postgresql.orgにあります。7.2版以上が必要です。

  • GNU Cコンパイラ (gcc)。ANSI Cコンパイラの中には、PostGISをコンパイルできるものもありますが、gccでコンパイルするのが最も問題が少ないと見ています。

  • GNU Make (gmakeまたはmake)。多くのシステムで、GNU makeがデフォルトのmakeになっています。make -vを実行して版を確認して下さい。他版のmakeでは、PostGISのMakefileを完全に処理しきれないかもしれません。

  • (推奨) 投影変換ライブラリ Proj4。Proj4ライブラリはPostGISで座標投影変換をサポートするために使われます。Proj4はhttp://www.remotesensing.org/projからダウンロードできます。

  • (推奨) ジオメトリライブラリ GEOS。GEOSライブラリは、PostGISでジオメトリのチェック (ST_Touches(), ST_Contains(), ST_Intersects())および操作(ST_Buffer(), ST_Union(), ST_Difference()) を提供するために使用します。 GEOSはhttp://geos.refractions.net (訳注: 現在はhttps://trac.osgeo.org/geos/)からダウンロードできます。

2.2. PostGISをソースからコンパイルおよびインストールする

PostGISモジュールは、PostgreSQLバックエンドサーバの拡張です。PostGIS 1.3.6をコンパイルするためにPostgreSQLサーバのヘッダの完全なアクセスが必要です。PostgreSQLのソースコードはhttp://www.postgresql.orgにあります。

PostGIS 1.3.6は、PostgreSQL 7.2.0以上で構築できます。それ以前のPostgreSQLには対応しません

  1. PostGISサーバモジュールをコンパイルする前に、PostgreSQLをコンパイル、インストールする必要があります。

    注記

    GEOS機能の使用を予定しているなら、PostgreSQLを標準C++ライブラリに、明示的にリンクする必要があることもあります。

    LDFLAGS=-lstdc++ ./configure [コンフィギュアオプション]

    これは、古い開発ツールとインチキC++例外との対話のための応急処置です。怪しい問題 (望んでいないのにバックエンドが閉じたりそれに近い挙動を起こす)を経験したなら、このトリックを試してみて下さい。もちろん、これを行うにはPostgreSQLをはじめからコンパイルし直す必要があります。

  2. PostGISソースコードのアーカイブはhttp://postgis.refractions.net/download/postgis-1.3.6.tar.gzから取得できます。このアーカイブを解凍します。

    # gzip -d -c postgis-1.3.6.tar.gz | tar xvf -
  3. postgis-1.3.6ディレクトリに移動して、次を実行します。

    # ./configure
    • 投影変換対応が必要なら、Proj4ライブラリをインストールしておく必要があります。./cofigureでProj4が発見できないなら、--with-proj=PATHスイッチを使って、Proj4をインストールしたディレクトリを指定してみて下さい。

    • GEOS機能を使いたい場合は、GEOSライブラリをインストールしておく必要があります。Geos 3.0.3以上を使用した方がいいです。ST_SimplifyPreserveTopologyといった関数で求められます。./cofigureでGEOSが発見できないなら、--with-geos=PATHで、geos-configプログラムへのフルパスを指定してみて下さい。

  4. コンパイルとインストールのコマンドを実行します。

    # make # make install

    pg_configで示される情報を使って全てのファイルがインストールされます。

    • ライブラリは[pkglibdir]/lib/contribにインストールされます。

    • lwpostgis.sqlといったサポートファイルは[prefix]/share/contribにインストールされます。

    • ローダ/ダンパのバイナリは[bindir]/にインストルされます。

  5. 上に挙げたprojが発見できないか4.5以下を使っている場合は、次を実行してインストールして下さい。

    wget http://download.osgeo.org/proj/proj-4.6.0.tar.gz
    tar xvzf proj-4.6.0.tar.gz
    cd proj-4.6.0
    ./configure && make clean && make
    make install
    ldconfig
    cd ..
  6. 上に挙げたgeosが発見できないか3.0以下を使っている場合は、次を実行してインストールして下さい。

    wget http://download.osgeo.org/geos/geos-3.0.3.tar.bz2
    tar xvjf geos-3.0.3.tar.bz2
    cd geos-3.0.3
    ./configure && make clean && make
    make install
    ldconfig
    cd ..
  7. PostGISにはPL/pgSQL手続き型言語の拡張が必要です。lwpostgis.sqlファイルをロードする前に、まずPL/pgSQLを有効にする必要があります。createlangコマンドを使うべきです。なんらかの理由で手動で行いたい場合にはPostgreSQLプログラマガイドに詳細があります。

    # createlang plpgsql [データベース名]
  8. そして、lwpostgis.sql定義ファイルをロードして、PostGISオブジェクトと関数定義をデータベースにロードします。

    psql -d [データベース名] -f rtpostgis.sql

    PostGISサーバ拡張はこれでロードされて、使えるようになります。

  9. 完全なEPSG座標系定義IDのセットについては、spatial_ref_sys.sql定義ファイルをロードして、SPATIAL_REF_SYSを生成して下さい。

    # psql -d [データベース名] -f spatial_ref_sys.sql
  10. PostGISが持つ関数に関する助けとなる記述が必要なら、 postgis_comments.sqlファイルをインストールして下さい。

    # psql -d [データベース名] -f postgis_comments.sql

2.2.1. 組み込みテンプレートからPostGIS空間データベースを生成する

PostGISのディストリビューション (特にPostGIS >= 1.1.5のWin32インストーラ)の中には、template_postgisというテンプレートにPostGIS関数をロードしていることがあります。PostgreSQLにtemplate_postgisデータベースが存在するなら、ユーザやアプリケーションは、空間データベースの生成をコマンドひとつで済ませられます。この2種類のやり方のどちらを使うににしても、データベースユーザは、新しいデータベースを作成する権限を与えられている必要があります。

シェルからの実行は次の通りです。

# createdb -T template_postgis my_spatial_db

SQLからの実行は次の通りです。

postgres=# CREATE DATABASE my_spatial_db TEMPLATE=template_postgis

2.2.2. アップグレード

既存の空間データベースのアップグレードは、新しいPostGISオブジェクト定義の置き換えや導入を必要とするとき、慎重を要することがあります。

不幸なことに、定義の全てが実行中のデータベース内で簡単には置き換えられるわけではないので、ダンプ/リロードが最善策となることがあります。

PostGISには、マイナーバージョンアップやバグフィクスリリースの場合に使うソフトアップグレードと、メジャーアップグレードで使うハードアップグレードが用意されています。

PostGISをアップグレードしようとする前にデータのバックアップを取ることは、常に価値のあるものです。pg_dumpで-Fcフラグを使うと、ハードアップグレードでダンプを常にリストアすることができます。

2.2.2.1. ソフトアップグレード

ソフトアップグレードは、lwpostgis_upgrade.sqlスクリプトを空間データベース上で実行することで行われます。

$ psql -f lwpostgis_upgrade.sql -d [データベース名]

ソフトアップグレードが実行できなかった場合は、スクリプトが中止されて、ハードアップグレードを実行する必要がある旨警告されますが、ソフトアップグレードを最初に実行するのをためらってはなりません。

注記

lwpostgis_upgrade.sqlファイルが見つからない場合は、1.1版より前の版のものを使っているかも知れません。この場合、次のコマンドで手動で生成する必要があります。

$ utils/postgis_proc_upgrade.pl lwpostgis.sql > lwpostgis_upgrade.sql

2.2.2.2. ハードアップグレード

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

この目的のために、PostGISは、pg_dump -Fcコマンドによるダンプを格納するためのユーティリティスクリプトを提供しています。これは試験的なもので、出力をファイルにリダイレクトすることで問題がある場合の解決の助けになります。手続きは次の通りです。

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

$ pg_dump -Fc olddb > olddb.dump

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

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

全ての格納したダンプオブジェクトが本当にダンプから格納されたか、lwpostgis.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=> drop spatial_ref_sys; 
DROP 
newdb=> \i spatial_ref_sys.sql

2.2.3. 共通の問題

インストールやアップグレードが思うようにいかない時にチェックすることがいくつかあります。

  1. PostGISディストリビューションをPostgreSQLソースツリーの下のcontribディレクトリに解凍するのが最も簡単です。 しかし、これが何らかの理由で展開できないなら、環境変数PGSQL_SRCにPostgreSQLソースディレクトリのパスを指定します。これで、PostGISのコンパイルができますが、make installはできないので、PostGISライブラリと実行ファイルを適切な位置に自前で複写することになります。

  2. PostgreSQL 7.2以降をインストールしているか、実行中のPostgreSQLと同じ版のPostgreSQLソースを使ってコンパイルしているか、をチェックします。(Linuxの)ディストリビューションによって既にPostgreSQLがインストールされている時や、PostgreSQLを以前にインストールして忘れた場合に、混乱が発生することがあります。PostGISは、PostgreSQL 7.2以上でのみ動作し、 それより前の版を使うと、おかしな、予想外のエラーメッセージが表示されます。 実行中のPostgreSQLの版をチェックするには、psqlを使ってデータベースを接続して、次のクエリを実行します。

    SELECT version();

    RPMベースのディストリビューションを実行している場合、プリインストールされたパッケージが存在するかのチェックは、rpmコマンドを使います。rpm -qa | grep postgresqlでチェックできます。

また、Makefile.configの先頭に行った必要な変更を全てチェックして下さい。このチェックは次の通りです。

  1. 投影変換をできるようにしたいなら、Proj4ライブラリをインストールして、Makefile.config内の、USE_PROJの値を1に設定し、PROJ_DIRをインストール先プリフィクスにします。

  2. GEOS関数を使いたい場合は、 GEOSライブラリをインストールし、Makefile.config内の、USE_GEOSを1に設定し、GEOS_DIRをインストール先プリフィクスにします。

2.3. JDBC

JDBC拡張によって、JavaオブジェクトがPostGISの内部型に対応できるようになります。このオブジェクトを使って、PostGISデータベースに問い合わせを出して、PostGISにあるGISデータの描画や計算を行うJavaクライアントを作成することができます。

  1. PostGISディストリビューションのjdbcサブディレクトリに移動します。

  2. antコマンドを実行します。postgis.jarファイルをJavaライブラリを保存しているところに複製します。

JDBC拡張のビルド実行中は現在のCLASSPATHに、PostgreSQL JDBCドライバがあるようにしておく必要があります。PostgreSQL JDBCドライバがCLASSPATHに無い場合には、個別にJDBCドライバのJARのありかを伝えます。次のようにします。

# ant -Dclasspath=/path/to/postgresql-jdbc.jar

PostgreSQL JDBCドライバはhttp://jdbc.postgresql.orgからダウンロードできます。

2.4. ローダ/ダンパ

データのローダとダンパは、PostGISのビルドの一部として、自動的にビルド、インストールされます。手動でビルド、インストールするには、次を実行します。

# cd postgis-1.3.6/loader 
# make 
# make install

ローダはshp2pgsqlと呼ばれ、ESRIシェープファイルをPostGIS/PostgreSQLにロードするのに適したSQLに変換します。ダンパはpgsql2shpと呼ばれ、PostGISのテーブル (またはクエリ)からESRIシェープファイルに変換します。より詳しいドキュメントをご覧になるには、オンラインヘルプとマニュアルページをご覧ください。

第3章 よくある質問

3.1. どの種類のジオメトリオブジェクトを格納できますか?
3.2. GISオブジェクトをデータベースに挿入するにはどうしますか?
3.3. 空間クエリを作成するにはどうするのですか?
3.4. 大きなテーブルでの空間クエリの速度向上はどうするのですか?
3.5. なぜPostgreSQLのR木インデックス機能を持たないのですか?
3.6. なぜ AddGeometryColumn()関数と他のOpsnGIS関数を使うべきなのですか?
3.7. 半径内にあるオブジェクトを全て検索する最善の方法は何ですか?
3.8. クエリの一部として投影変換を実現するにはどうしますか?

3.1.

どの種類のジオメトリオブジェクトを格納できますか?

ポイント、ライン、ポリゴン、マルチポイント、マルチライン、マルチポリゴン、ジオメトリコレクションを格納できます。これらは Open GIS Well Known Text Formatで規定されています (XYZ,XYM,XYZM拡張付き)。

3.2.

GISオブジェクトをデータベースに挿入するにはどうしますか?

まず、GISデータを保持するためにジオメトリ型のカラムをテーブルに作成する必要があります。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', 
  GeomFromText('LINESTRING(2 3,4 5,6 5,7 8)', -1)
);

GISオブジェクトの詳細については、オブジェクトリファレンスをご覧下さい。

テーブルの中にあるGISデータを閲覧するには、次のようにします。

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

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

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

3.3.

空間クエリを作成するにはどうするのですか?

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

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

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

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

SELECT id, the_geom 
FROM thetable 
WHERE 
  the_geom && 'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))' 
AND
  _ST_Contains(the_geom,'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))');

3.4.

大きなテーブルでの空間クエリの速度向上はどうするのですか?

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

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()を実行します。

3.5.

なぜPostgreSQLのR木インデックス機能を持たないのですか?

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

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

  • PostgreSQLのR木インデックスは、8K以上のサイズのフィーチャーは扱えません。GiSTインデックスはフィーチャー自体の代わりにバウンディングボックスを用いる「不可逆」トリックを使っているので扱うことができます。

  • PostgreSQLのR木インデックスは「NULLセーフ」ではなく、NULLジオメトリを含むジオメトリカラムではインデックス作成に失敗します。

3.6.

なぜ AddGeometryColumn()関数と他のOpsnGIS関数を使うべきなのですか?

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

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

3.7.

半径内にあるオブジェクトを全て検索する最善の方法は何ですか?

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

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

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

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

3.8.

クエリの一部として投影変換を実現するにはどうしますか?

投影変換を行うには、変換元と変換先双方の座標系がSPATIAL_REF_SYSテーブルに定義されていて、かつ投影変換されるジオメトリがそのSRIDを持っている必要があります。これが行われていると、投影変換は求める変換先SRIDを参照するのと同じぐらい簡単です。

SELECT ST_Transform(the_geom,4269) FROM geotable;

第4章 PostGISを使う

4.1. GISオブジェクト

PostGISでサポートされるGISオブジェクトは、OpenGISコンソーシアム (OGC)で定義されている「シンプルフィーチャー」のスーパーセットです。0.9版からは、PostGISはOGCの「SQL用シンプルフィーチャー」仕様で規定されたオブジェクトと関数の全てに対応しています。

PostGISは標準から拡張して 3DZ, 3DM, 4D 座標 (訳注: それぞれXYZ, XYM, XYZM)をサポートしています。

4.1.1. OpenGIS WKBとWKT

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

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

  • POINT(0 0)

  • LINESTRING(0 0,1 1,1 2)

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

  • MULTIPOINT(0 0,1 2)

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

  • MULTIPOLYGON(((0 0,4 0,4 4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 -2,-2 -2,-2 -1,-1 -1)))

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

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

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

bytea WKB = asBinary(geometry); 
text WKT = asText(geometry); 
geometry = GeomFromWKB(bytea WKB, SRID); 
geometry = GeometryFromText(text WKT, SRID);

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

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

4.1.2. PostGIS EWKB, EWKTと標準形式

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

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

PostGIS EWKB/EWKT では 3dm, 3dz, 4d座標の対応が追加され、SRID情報が埋め込まれます。

拡張された空間オブジェクトのテキスト表現 (EWKT)の例は、次の通りです。

  • POINT(0 0 0) -- XYZ

  • SRID=32632;POINT(0 0) -- XY with SRID

  • POINTM(0 0 0) -- XYM

  • POINT(0 0 0 0) -- XYZM

  • SRID=4326;MULTIPOINTM(0 0 0,1 2 1) -- SRID付きXYM

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

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

  • MULTIPOLYGON(((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)),((-1 -1 0,-1 -2 0,-2 -2 0,-2 -1 0,-1 -1 0)))

  • GEOMETRYCOLLECTIONM(POINTM(2 3 9), LINESTRINGM(2 3 4, 3 4 5))

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

bytea EWKB = asEWKB(geometry); 
text EWKT = asEWKT(geometry); 
geometry = GeomFromEWKB(bytea EWKB); 
geometry = GeomFromEWKT(text EWKT);

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

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

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

- 出力
  - バイナリ: EWKB 
    ascii: HEXEWKB (EWKBのHEX表現) 
- 入力 
  - バイナリ: EWKB 
    ascii: HEXEWKB|EWKT  

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

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

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

4.1.3. SQL-MM第3部

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

SQL-MMの定義では、3DM、3DZと4Dの座標を含みますが、SRID情報の埋め込みはできません。

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

  • CIRCULARSTRING(0 0, 1 1, 1 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))

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

注記

現在、PostGISは曲線ポリゴンでの複合曲線に対応していません。

注記

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

4.2. OpenGIS標準を使う

OpenGISの「SQL用シンプルフィーチャー仕様」では、標準GISオブジェクト型とこれらを操作するために必要な関数、メタデータテーブルのセットが定義されています。メタデータが一貫性を維持していることを保証するために、空間カラムの生成、消去といった操作はOpenGISで定義されている空間プロシージャを通して実行されます。

OpenGISメタデータテーブルにはSPATIAL_REF_SYSGEOMETRY_COLUMNSの二つがあります。SPATIAL_REF_SYSテーブルは空間データベースで用いられる座標系の、数字によるIDと文字による説明を持っています。

4.2.1. SPATIAL_REF_SYSテーブル

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のカラムは次の通りです。

SRID

一意に定められた整数値で、データベースで空間参照系 (SRS)を識別するものです。

AUTH_NAME

その参照系の引用元である標準の名前です。たとえば「EPSG」は妥当なAUTH_NAMEです。

AUTH_SRID

AUTH_NAMEで引用される団体によって定義された空間参照系のIDです。EPSGの場合、EPSG投影コードが入ります。

SRTEXT

空間参照系のWell-Knownテキスト表現です。たとえば、WKT SRSの表現は、次のようになります。

PROJCS["NAD83 / UTM Zone 10N",
  GEOGCS["NAD83",
    DATUM["North_American_Datum_1983", 
      SPHEROID["GRS 1980",6378137,298.257222101] 
    ],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433] 
  ],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["latitude_of_origin",0],
  PARAMETER["central_meridian",-123],
  PARAMETER["scale_factor",0.9996],
  PARAMETER["false_easting",500000],
  PARAMETER["false_northing",0], 
  UNIT["metre",1] 
]

EPSG投影コードと対応するWKT表現の一覧についてはhttp://www.opengis.org/techno/interop/EPSG2WKT.TXTをご覧下さい。WKTの一般的な議論については、OpenGISの「座標変換サービス実装仕様」http://www.opengis.org/techno/specs.htmをご覧下さい。欧州石油調査グループ (European Petroleum Survey Group, EPSG)と EPSG空間参照系のデータベースに関する情報は、http://epsg.orgをご覧下さい。

PROJ4TEXT

PostGISは座標変換機能を提供するためにProj4ライブラリを用いています。 PROJ4TEXTカラムには、特定のSRIDを示すProj4座標定義文字列が入ります。たとえば次のようになります。

+proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=m

詳細情報については、Proj4ウェブサイhttp://www.remotesensing.org/projをご覧下さい。spatial_ref_sys.sqlは、全てのEPSG投影のためのSRTEXTPROJ4TEXTを持っています。

4.2.2. GEOMETRY_COLUMNSテーブル

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 
)

カラムは次のとおりです。

F_TABLE_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME

ジオメトリカラムを含むフィーチャーテーブルの完全修飾名。"catalog"および"schema"の語はOracle風であることに注意して下さい。"catalog"に類似するものはPostgreSQLになく、カラムは空白にされます。"schema"についてはPostgreSQLスキーマ名が使われています (publicがデフォルトです)。

F_GEOMETRY_COLUMN

フィーチャーテーブル内のジオメトリカラムの名前。

COORD_DIMENSION

そのカラムの空間の次元 (2, 3 または 4)。

SRID

このテーブルの座標ジオメトリのために使われる空間参照系のID。SPATIAL_REF_SYSへの外部キーになっています。

TYPE

空間オブジェクトの型。空間カラムを単一型に制限するには、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTIONのうちのいずれかを、また、XYMで使う場合には、LINESTRINGM、POLYGONM、MULTIPOINTM、MULTILINESTRINGM、MULTIPOLYGONM、GEOMETRYCOLLECTIONMのうちのいずれかを使います。複数の型が混合するコレクションの場合は"GEOMETRY"を型とすることができます。

注記

この属性は (おそらく)OpenGIS仕様に入っていませんが、型の同一性を保証するために必要です。

4.2.3. 空間テーブルを作る

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

  • 通常の非空間テーブルを生成します。

    たとえば、次のようにします。CREATE TABLE ROADS_GEOM ( ID int4, NAME varchar(25) )

  • OpenGISの"AddGeometryColumn"関数によって空間カラムをテーブルに追加します。

    文法は次の通りです。

    AddGeometryColumn(
      <schema_name>,
      <table_name>,
      <column_name>,
      <srid>,
      <type>,
      <dimension>
    )

    現在のスキーマを使う場合には次のようにします。

    AddGeometryColumn(
      <table_name>,
      <column_name>, 
      <srid>, 
      <type>,
      <dimension>
    )

    例1: SELECT AddGeometryColumn('public', 'roads_geom', 'geom', 423, 'LINESTRING', 2)

    例2: SELECT AddGeometryColumn( 'roads_geom', 'geom', 423, 'LINESTRING', 2)

次はテーブルを作成して空間カラムを作る例です (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 );

もうひとつ、ジェネリックな「ジオメトリ」型とSRID不明を示す-1を使った例を挙げます。

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

4.2.4. ジオメトリのOpenGIS準拠を確実にする

GEOSライブラリで実装される関数のほとんどが、ジオメトリがOpenGIS単純フィーチャー仕様の定義から見て妥当であることが仮定されています。ジオメトリの妥当性のチェックには、IsValid()関数を使います。例を次に示します。

gisdb=# select isvalid('LINESTRING(0 0, 1 1)'), 
        isvalid('LINESTRING(0 0,0 0)'); 

 isvalid | isvalid
---------+--------- 
       t |       f

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

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

妥当なジオメトリでPostGIS関数を呼んだ時に、"GEOS Intersection() threw an error!"または"JTS Intersection() threw an error!"のような、変なエラー・メッセージに遭遇するなら、たぶんPostGISか使用ライブラリでエラーが発生しています。PostGIS開発者と連絡をとるべきです。PostGIS関数が妥当な入力から無効なジオメトリーを返すならば、同じことがいえます。

注記

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

4.3. GISデータのロード

空間テーブルを作成したら、これでGISデータをデータベースにアップロードする準備ができたことになります。現在、PostGIS/PostgreSQLデータベースにデータをロードするには、SQLステートメントを使う、またはシェープファイルのローダ/ダンパを使う、二つの方法があります。

4.3.1. SQLを使う

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

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

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

データファイルは、次に示す"psql"というSQL端末モニタを使って、簡単にPostgreSQLにパイプで送ることができます。

psql -d [データベース名] -f roads.sql

4.3.2. ローダを使う

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

-d

シェープファイルにあるデータを持つ新しいテーブルを作成する前にデータベーステーブルを削除します。

-a

シェープファイルからデータベーステーブルにデータを追加します。複数のファイルをロードするためにこのオプションを使う場合は、これらのファイルは同じ属性と同じデータ型を持つ必要があります。

-c

新しいテーブルの作成とシェープファイルからのデータの読み込みを行います。これがデフォルトモードです

-p

テーブル作成のSQLコードを生成するだけで、実際のデータは追加しません。このモードは、テーブル作成とデータロードとを完全に分けたい場合に使用します。

-D

出力データにPostgreSQLの"dump"書式を用います。このモードは-a, -cと-dが含まれます。デフォルトの"insert"によるSQL書式よりも、とても早くロードできます。大きなデータセットではこちらを使用して下さい。

-s <SRID>

指定したSRIDでジオメトリデーブルの作成とデータの読み込みを行います。

-k

識別子 (カラム、スキーマおよび属性)の大文字小文字を保持します。シェープファイルの属性は全て大文字であることに注意して下さい。

-i

全ての整数を標準の32ビット整数に強制します。DBFヘッダではそれが正当であったとしても、64ビットのbigintを生成しません。

-I

ジオメトリカラムにGiSTインデックスを生成します。

-w

古い版 (0.x版)のPostGISのためにWKT書式を出力します。このオプションを使うと、座標変動が発生したり、M値が削除されることに注意して下さい。

-W <エンコーディング>

入力データ (dbfファイル)のエンコーディングを指定します。全てのdbfの属性は指定されたエンコーディングからUTF8に変換されます。SQL出力結果には SET CLIENT_ENCODING to UTF8が含まれるようになり、バックエンドはUTF-8からデータベースが内部利用のために設定したエンコーディングに再変換できます。

-a, -c, -dおよび-pは互いに排他的であることに注意して下さい。

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

# shp2pgsql shaperoads myschema.roadstable > roads.sql 
# psql -d roadsdb -f roads.sql

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

# shp2pgsql shaperoads myschema.roadstable | psql -d roadsdb

4.4. GISデータを検索する

データは、SQLまたはシェープファイルローダ/ダンパを使ってデータベースから抜き出すことができます。SQLに関する節において、空間テーブルでの比較とクエリを行うために用いることができる演算子のいくつかを議論します。

4.4.1. SQLを使う

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

db=# SELECT road_id, 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を使うだけです。空間ベースの制限の場合、次の演算子が使用可能であり、便利です。

&&

この演算子で、一つのジオメトリのバウンディングボックスが他のバウンディングボックスとインタセクトするかを問い合わせることができます。

~=

この演算子で、二つのジオメトリが幾何的に同一であるかを見ることができます。 たとえば、'POLYGON((0 0,1 1,1 0,0 0))' は 'POLYGON((0 0,1 1,1 0,0 0))' と同じかを見ることができます (これは同じとなります)。

=

この演算子は他より若干素朴なもので、二つのジオメトリのバウンディングボックスが同じかを見るだけです。

次に、これらの演算子をクエリで使うことができます。SQLコマンドラインからジオメトリとボックスの特定を行うときは、"GeomFromText()"関数で、明示的に文字列表現をジオメトリに変換しなければならないことに注意して下さい。たとえば、次のようになります。

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

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

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

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

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

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

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

ここで、BOX3Dの投影を指定するためにSRIDを使っていることに注意して下さい。SRIDを-1に設定しているのは、SRIDを指定しないということを示しています。

4.4.2. ダンパを使う

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

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

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

-f <ファイル名>

特定のファイル名に出力を書きこみます。

-h <ホスト>

接続先データベースのホスト名。

-p <ポート>

接続先データベースのポート。

-P <パスワード>

データベースに接続するためのパスワード。

-u <ユーザ名>

データベースに接続する際のユーザ名。

-g <ジオメトリカラム>

複数のジオメトリカラムを持つテーブルの場合の、シェープファイルの出力に使用するジオメトリカラム。

-b

バイナリカーソルを使います。これは、実行時間を短くしますが、テーブルの非ジオメトリ属性がテキストへのキャストを持っていない場合には、動作しません。

-r

Rawモード。gidフィールドを落としたり、カラム名をエスケープしてはいけません。

-d

後方互換: 古い (1.0.0より前)のPostGISデータベースからダンプする際に3次元のシェープファイルを出力します (デフォルトでは2次元になります)。 PostGIS 1.0.0以上では、次元は完全に反映されます。

4.5. インデックスを構築する

インデックスは大きなデータセットを持つ空間データベースの利用を可能にするものです。インデックスなしでは、フィーチャーの検索でデータベースの全レコードを「シーケンシャルスキャン」する必要があります。インデックスをつけることで、データを検索木に組織化して、特定のレコードを発見するための検索をより早くすることができます。 PostgreSQLは、B木、R木、GiSTの3種類のインデックスをデフォルトでサポートしています。

  • B木は、数字、文字、日付といった、一つの軸に沿ってソートできるデータに使用します。 GISデータは合理的に一つの軸に沿ったソートはできません ((0,0)と(0,1)と(1,0)で大きいのはどれでしょう?)ので、B木インデックスは、ここでは使えません。

  • R木はデータを長方形に分割して、さらにその長方形を小さい長方形に分割していったものです。R木はいくつかの空間データベースでGISデータのインデックスに使われますが、PostgreSQLのR木実装は、GiST実装ほどにロバストではありません。

  • GiST (Generalized Search Trees)インデックスはデータを「一方へのもの」 (訳注: 「左側にあるもの」「上側にあるもの」など)、「オーバラップするもの」、「中にあるもの」に分割して、GISデータを含む幅広いデータ型で使えるようにしたものです。PostGISではGISデータにインデックスを付けるためにGiSTの上でR木インデックス実装を使用しています。

4.5.1. GiSTインデックス

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

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

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

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

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

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

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

4.5.2. インデックスを使う

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

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

  • まず、クエリプランナにインデックス使用まわりの判断に利用するためのより良い情報を提供するために、値の数量と分散に関する統計情報が収集されたかを確認してください。PostgreSQL 7.4以前では、update_geometry_stats([テーブル名], [カラム名]) (分散計算)とVACUUM ANALYZE [テーブル名] [カラム名] (値の数量の計算)とを実行します。PostgreSQL 8.0については、VACUUM ANALYZEを実行することで同じ動作になります。常に定期的なデータベースへのvacuumを実行すべきです。多くのPostgreSQLのデータベースエージェントは、閑散時のcronジョブとして定期的にVACUUMを実行します。

  • vacuumが働かないなら、SET ENABLE_SEQSCAN=OFFコマンドで、プランナにインデックス情報を強制的に使わせることができます。このコマンドは控え目に実行すべきで、かつ、空間インデックスがあるクエリ上でのみ使うべきです。一般的に言うと、通常のB木インデックスを使うべき時に関してあなたが知っていることよりも、プランナはより良く知っています。クエリを実行したら、ENABLE_SEQSCAN設定を戻して、他のクエリでは通常通りプランナを使用することを考えるべきです。

    注記

    0.6版では、ENABLE_SEQSCANでプランナにインデックスを強制的に使わせることは重要ではありません。

  • もし、順に走査する際のコストとインデックスを使う際のコストとを比較してプランナが間違っていることに気付いたら、postgresql.confでrandom_page_costの値を減らしてみるか、"SET random_page_cost=#"を使ってみてください。このパラメータのデフォルト値は4ですが、それを1か2にしてみて下さい。値を減らすことで、プランナがよりインデックススキャンを行う傾向になります。

4.6. 複雑なクエリ

空間データベース機能のレゾンデートルは、通常はデスクトップGISに求める機能を、データベース内部のクエリで実現することです。PostGISを効果的に使用するには、どの空間機能が有効かを知り、また、良い性能を提供する所に適切にインデックスがあることが保証されていることが求められます。

4.6.1. インデックスの利点を使う

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

SELECT the_geom 
FROM geom_table 
WHERE ST_Distance(the_geom, 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, GeomFromText('POINT(100000 200000)', -1)) < 100

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

挙動の変更

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

4.6.2. 空間SQLの例

本節の例では、線型の道、ポリゴンの自治体境界、の二つのテーブルを使います。テーブルの定義をしまします。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)
4.6.2.1. 道路の総延長はkm表記でいくらになるでしょう?
4.6.2.2. プリンスジョージ市の大きさはha表記でいくらになるでしょう?
4.6.2.3. 県内で最も大きな面積となる自治体はどこでしょう?
4.6.2.4. 各自治体内に含まれる道路の総延長はいくらでしょう?
4.6.2.5. プリンスジョージ市内の全ての道路からなるテーブルを作る
4.6.2.6. ビクトリア州の「ダグラス通り」の長さはkm表記でいくらになるでしょう?
4.6.2.7. 穴を持つ自治体ポリゴンのうち最も大きいのはどれでしょう?

4.6.2.1.

道路の総延長はkm表記でいくらになるでしょう?

この問題は、次のようなとても単純なSQLで答を得ることができます。

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

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

4.6.2.2.

プリンスジョージ市の大きさはha表記でいくらになるでしょう?

このクエリでは、属性条件 (municipality name, 自治体名)に空間計算 (面積)を併用しています。

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

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

4.6.2.3.

県内で最も大きな面積となる自治体はどこでしょう?

このクエリは、空間計測をクエリ条件に持ってきています。この問題へのアプローチの方法はいくつかありますが、最も効率的なのは次の通りです。

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)

このクエリの答を出すためには、全てのポリゴンの面積を求める必要があることに注意して下さい。このクエリを多く実行する場合、性能向上のためにテーブルにareaカラムを追加して、別のインデックスを追加することができるようにするのは、意義のあることです。結果を距離について降順に並べ替え、PostgreSQLの"LIMIT"コマンドを用いることで、max()のような集約関数を使わずに、簡単に最も大きい値を得ることができます。

4.6.2.4.

各自治体内に含まれる道路の総延長はいくらでしょう?

これは、二つのテーブルからデータを持ち込んで (結合して)いるので「空間結合」の例です。しかし、結合の条件として共通キーの上で接続するという普通のリレーションのやり方でなく空間インタラクション条件 (「含む」)を使っています。

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

このクエリは、テーブル内の全ての道路の合計を最終結果 (この例での話ですが約250Kmの道です)にまとめられるので、少し時間がかかります。より小さいオーバレイ (数百の道路で数千のレコード)の場合、応答はもっと早くなりえます。

4.6.2.5.

プリンスジョージ市内の全ての道路からなるテーブルを作る

これは「オーバレイ」の例です。つまり、二つのテーブルを取得して、空間的に切り取られた結果からなる新しいテーブルを出力します。上で示した「空間結合」と違い、このクエリは実際に新しいジオメトリを生成します。生成されたオーバレイはターボのかかった空間結合みたいなもので、より確かな解析作業に便利です。

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 ST_Intersects(r.the_geom, m.the_geom)
  AND m.name = 'PRINCE GEORGE';

4.6.2.6.

ビクトリア州の「ダグラス通り」の長さはkm表記でいくらになるでしょう?

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

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

4.6.2.7.

穴を持つ自治体ポリゴンのうち最も大きいのはどれでしょう?

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)

4.7. MapServerを使う

Minnesota MapServerはOpenGIS Web Mapping Server仕様を満たすウェブマッピングサーバです。

4.7.1. 基本的な使い方

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

MapServerでPostGISを使うには、次のものが必要です。

  • PostGIS 0.6以上

  • MapServer 3.5以上

MapServerは、他のPostgreSQLクライアントのように、libpqを使ってPostGIS/PostgreSQLデータにアクセスします。これは、システムがPostgreSQLクライアントライブラリであるlibpqを持っている限りは、PostGISサーバへのネットワークアクセスを持つあらゆる機械にMapServerをインストールできるということを示しています。

  1. "--with-postgis"と好きなconfigureオプションを付けてMpaserverのコンパイルとインストールを行います。

  2. MapServerのmapファイルの中に、PostGISレイヤを追加します。たとえば次のようになります。

    LAYER 
      CONNECTIONTYPE postgis 
      NAME "widehighways" 
      # Connect to a remote spatial database
      CONNECTION "user=dbuser dbname=gisdatabase host=bigserver"
      # Get the lines from the 'geom' column of the 'roads' table 
      DATA "geom from roads" 
      STATUS ON
      TYPE LINE 
      # Of the lines in the extents, only render the wide highways 
      FILTER "type = 'highway' and numlanes >= 4" 
      CLASS 
        # Make the superhighways brighter and 2 pixels wide
        EXPRESSION ([numlanes] >= 6) 
        STYLE
          COLOR 255 22 22 
          WIDTH 2 
        END
      END 
      CLASS 
        # All the rest are darker and only 1 pixel wide 
        EXPRESSION ([numlanes] < 6) 
        STYLE
          COLOR 205 92 82
        END
      END 
    END

    上の例におけるPostGIS特有のディレクティブは次の通りです。

    CONNECTIONTYPE

    PostGISレイヤでは常に"postgis"とします。

    CONNECTION

    データベース接続は「接続文字列」によって制御されます。接続文字列は、次に示すような標準的なキーと値からなります(<>内はデフォルト値)。

    user=<ユーザ名> password=<パスワード> dbname=<ユーザ名> hostname=<サーバ> port=<5432>

    空の接続文字列も妥当とされますし、あらゆるキーと値のペアは省略できます。接続するためには一般的にはdbnameとusernameとが最少で与えるものとなります。

    DATA

    このパラメータの形式は "<カラム名> from <テーブル名>"となります。ここで、カラム名は地図に描画したい空間カラムを指します。

    FILTER

    フィルタは、妥当なSQL文字列でなければなりません。この文字列は、通常はSQLクエリにおける"WHERE"に続く論理式に対応します。たとえば、6レーン以上の道路だけを描画する場合には、"num_lanes >= 6"というフィルタを使います。

  3. 空間データベースにおいては、空間 (GiST)インデックスを、マップに描かれるレイヤ全てに構築していることを保証して下さい。

    CREATE INDEX [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム] );
  4. MapServerを使ってレイヤにクエリを発行する場合は、「oidインデックス」も必要です (訳注: PostgreSQL 8.1以降は、oidはデフォルトでは追加されなくなりました。替わりにSERIAL型フィールドを生成して使うべきです。テーブル生成時に"WITH OID"を付けるとoid付きテーブルが生成されます)。

    MapServerからは、クエリを実行するときに、それぞれの空間レコードを識別する一意な識別子が求められ、MapServerのPostGISモジュールはPostgreSQLのoid値を一意な識別子に使います。これの副作用はクエリ内のレコードのランダムアクセスを早く行うのにoidインデックスが必要となることです。

    「oidインデックス」を構築するには、次のようなSQLを実行します。

    CREATE INDEX [インデックス名] ON [テーブル名] ( oid );

4.7.2. よくある質問

4.7.2.1. EXPRESSIONをマップファイルで使う時に、値がテーブルにあるのを確認しているのに条件がtrueになりません。
4.7.2.2. シェープファイルで使っているFILTERが、同じデータを持つPostGISテーブルでは動作しません。
4.7.2.3. PostGISレイヤの描画がシェープファイルより遅くなりますが、これが普通なのでしょうか?
4.7.2.4. PostGISレイヤはちゃんと描けましたが、クエリが本当に遅いです。何が問題なのですか?

4.7.2.1.

EXPRESSIONをマップファイルで使う時に、値がテーブルにあるのを確認しているのに条件がtrueになりません。

EXPRESIONで使うフィールド名は、シェープファイルと違ってPostGISの場合小文字になります。

EXPRESSION ([numlanes] >= 6)

4.7.2.2.

シェープファイルで使っているFILTERが、同じデータを持つPostGISテーブルでは動作しません。

シェープファイルと違い、PostGISレイヤのフィルタはSQL構文を使います (PostGISコネクタがMapServerでレイヤを描画するために生成するSQLステートメントに追加されます)。

FILTER "type = 'highway' and numlanes >= 4"

4.7.2.3.

PostGISレイヤの描画がシェープファイルより遅くなりますが、これが普通なのでしょうか?

一般的に、PostGISレイヤは同等のシェープファイルレイヤより10%遅いと考えて下さい。 データベースとMapServerとの間で発生するデータベース接続、データの変換と転送によってオーバヘッドが増えるためです。

重大な描画性能の問題があるようでしたら、テーブルにある空間インデックスを構築していないというのがありそうです。

postgis# CREATE INDEX geotable_gix ON geotable USING GIST ( geocolumn ); 
postgis# SELECT update_geometry_stats(); -- PostgreSQL 8.0より後 
postgis# VACUUM ANALYZE; -- PostgreSQL 8.0以前

4.7.2.4.

PostGISレイヤはちゃんと描けましたが、クエリが本当に遅いです。何が問題なのですか?

クエリを早くするには、空間テーブルに一意なキーを持たせ、そのキーにインデックスを持たせなければなりません。

DATA行のUSING UNIQUE節で、MapServerで使用する一意なキーをどれにするか指定することができます。

DATA "the_geom FROM geotable USING UNIQUE gid"

テーブルに明示的に一意なカラムが無い場合は、PostgreSQLの行"oid"を用いて一意なカラムを「模造する」ことができます。"oid"は、宣言していないなら、デフォルトの一意なカラムです。ですから、クエリ速度を強化するには、空間テーブルのoid値にインデックスを構築することです (訳注: PostgreSQL 8.1以降は、oidはデフォルトでは追加されなくなりました)。

postgis# CREATE INDEX geotable_oid_idx ON geotable (oid);

4.7.3. 踏み込んだ使用法

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 oid USING SRID=-1"
USING UNIQUE <uniqueid>

MapServerは、マップクエリを実行する際、行識別のために、それぞれの行に一意な識別子を求めます。 通常なら、oidを一意な識別子として使えますが、ビューや副問い合わせでは、自動的にoidを持つことができません。MapServerのクエリ機能を使いたいなら、一意性のあるカラムをビューまたは副問い合わせに追加する必要があり、USING UNIQUE宣言を付ける必要があります。たとえば、この目的のための主キー値のテーブルでのカラム名や、結果セットで一意性が保障されたカラムを明示的にSELECTに入れることができます。

マップクエリを実行する場合には、USINGステートメントは単純なDATAステートメントに対しても便利なものになります。マップクエリの速度性能向上のために、クエリ実行可能なレイヤで使われるテーブルのoidカラムにインデックスを追加することを、前に推奨しました。しかしながら、USINGを使うと、MapServerがテーブルのプライマリキーをマップクエリの識別子に使うことができ、インデックスを追加する必要はもうありません。

注記

「マップクエリ」はマップ上でクリックして、その場所におけるフィーチャーに関する情報を問い合わせる動作です。「マップクエリ」とDATA定義におけるSQLクエリと混同しないで下さい。

USING SRID=<srid>

PostGISは、MapServerに正しいデータを返すために、ジオメトリがどの空間参照系を使っているかを知る必要があります。通常は、この情報はPostGISデータベースの"geometry_columns"テーブルから得ることができます。しかし、副問い合わせやビューのような一時テーブルでは、この方法は不可能です。そこで、 USING SRID=オプションを使って、正しいSRIDがDATA定義で使われるように指定します。

警告

MapserverのPostGISレイヤのパーサは、かなり原始的で、大文字小文字を区別するところが2,3あります。全てのSQLキーワードと全てのUSING節が大文字であることを保証し、USING UNIQUE節がUSING SRID節より前に来るようにして下さい。

4.7.4. 例

簡単な例から始めて、ステップアップしていきましょう。次の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 
    COLOR 0 0 0 
  END 
END

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

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

LAYER 
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" 
  DATA "the_geom FROM roads"
  MINSCALE 100000 
  STATUS ON 
  TYPE LINE 
  FILTER "road_type = 'highway'" 
  CLASS 
    COLOR 0 0 0 
  END 
END 
LAYER 
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  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  
    COLOR 0 0 0 
  END 
END

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

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

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

LAYER 
  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を使用する方法も示しています。

4.8. Javaクライアント (JDBC)

Javaクライアントは、直接的にテキスト表現として、またはPostGISに同梱されているJDBC拡張オブジェクトを使用して、PostgreSQLデータベース内にある、PostGISの"geometry"オブジェクトにアクセスできます。JDBC拡張オブジェクトを使うためには、"postgis.jar"ファイルを、JDBCドライバパッケージの"postgresql.jar"とともに、 CLASSPATHに置く必要があります。

import java.sql.*; 
import java.util.*; 
import java.lang.*; 
import org.postgis.*; 

public class JavaGIS { 

public static void main(String[] args) { 

  java.sql.Connection conn; 

  try { 
    /* 
    * JDBCドライバをロードして接続を確立します
    */
    Class.forName("org.postgresql.Driver"); 
    String url = "jdbc:postgresql://localhost:5432/database"; 
    conn = DriverManager.getConnection(url, "postgres", ""); 
    /* 
    * ジオメトリ型を接続に追加します
    * ご注意 : addDateType()を呼ぶ前に
    *   接続をpgsql特有の接続実装にキャストしなければなりません
    */
    ((org.postgresql.Connection)conn).addDataType("geometry","org.postgis.PGgeometry")
;
    ((org.postgresql.Connection)conn).addDataType("box3d","org.postgis.PGbox3d");
    /* 
    * Create a statement and execute a select query. 
    */ 
    Statement s = conn.createStatement(); 
    ResultSet r = s.executeQuery("select AsText(geom) as geom,id from geomtable"); 
    while( r.next() ) { 
      /* 
      * ジオメトリをオブジェクトとして取得して、geometry型にキャストします
      * オブジェクトを印字します
      */ 
      PGgeometry geom = (PGgeometry)r.getObject(1); 
      int id = r.getInt(2); 
      System.out.println("Row " + id + ":");
      System.out.println(geom.toString()); 
    } 
    s.close(); 
    conn.close(); 
  } 
catch( Exception e ) { 
  e.printStackTrace(); 
  } 
} 
}

"PGeometry"オブジェクトは、Point、LineString、Polygon、MultiPoint、MultiLineString、MultiPolygonの各型に依存する、特定のトポロジカルジオメトリオブジェクト ("Geometory"抽象クラスの子クラス)を持つラッパオブジェクトです。

PGgeometry geom = (PGgeometry)r.getObject(1); 
if( geom.getType() = Geometry.POLYGON ) { 
  Polygon pl = (Polygon)geom.getGeometry(); 
  for( int r = 0; r < pl.numRings(); r++) { 
    LinearRing rng = pl.getRing(r); 
    System.out.println("Ring: " + r); 
    for( int p = 0; p < rng.numPoints(); p++ ) { 
      Point pt = rng.getPoint(p); 
      System.out.println("Point: " + p);
      System.out.println(pt.toString()); 
    } 
  } 
}

幾何オブジェクトのさまざまなデータアクセサ関数に関する参照情報については、拡張オブジェクトのJavaDocをご覧下さい。

4.9. Cクライアント (libpq)

...

4.9.1. テキストカーソル

...

4.9.2. バイナリカーソル

...

第5章 性能向上に関する技法

5.1. 大きなジオメトリを持つ小さなテーブル

5.1.1. 問題の説明

現版の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)をご覧下さい。

5.1.2. 応急処置

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 = Envelope(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クエリを実行するかでも対応できます。

5.2. ジオメトリインデックスでCLUSTERを実行する

読み込むことがほとんどで、かつほとんどのクエリでひとつのインデックスを使うようなテーブルのために、PostgreSQLはCLUSTERコマンドを提供しています。このコマンドは、全てのデータ行を、インデックス基準にあわせて物理的に再整理するので、二つの性能の利点を生みます。一つは、インデックスの範囲走査のために、データテーブルのシーク回数が劇的に減少することです。もう一つは、いくつかの小さなインデックス間隔に集中する場合には、データ行が分布するデータページがより少なくなるので、より効率的なキャッシュを持つことです (この点で、PostgreSQLマニュアルのCLUSTERコマンドのドキュメントを読むように仕向けられていると感じて下さい)。

しかし、GiSTインデックスは単純にNULL値を無視するため現在のところPostGISのGiSTインデックスのクラスタリングはできず、次のようなエラーメッセージを得ます。

lwgeom=# CLUSTER my_geom_index ON my_table;
ERROR: cannot cluster when index access method does not handle null values
(エラー: インデックスアクセスメソッドがNULL値を扱わない場合クラスタ化できません)
HINT: You may be able to work around this by marking column "the_geom" NOT NULL.
(ヒント: 列"the_geom"をNOT NULLとすることで、これを回避できるかもしれません)

ヒントメッセージにある通り、テーブルに"not null"制限を追加することで、この欠陥にとりあえず対応できます。例を示します。

lwgeom=# ALTER TABLE my_table ALTER COLUMN the_geom SET not null; 
ALTER TABLE

もちろん、ジオメトリカラムで実際にNULL値が必要な場合、この対応はできません。さらには、制限を追加するには上の方法を使わなければならず、"ALTER TABLE blubb ADD CHECK (geometry is not null);"のようなCHECK制限は使えません。

5.3. 次元変換の回避

ときどき、テーブルで3次元、4次元のデータを持つのに、常にOpenGIS準拠のasText()またはasBinary()関数を使ってアクセスして 2次元ジオメトリを出力させるようなことが起きます。 内部でforce_2d()関数を呼んでいるために発生しますが、 これは、大きなジオメトリでは重大なオーバヘッドを誘引することになります。 このオーバヘッドを回避するには、一度追加された次元を前もって落とし、かつこれを永続化するのが適当かも知れません。

UPDATE mytable SET the_geom = force_2d(the_geom); 
VACUUM FULL ANALYZE mytable;

AddGeometryColumn()を使ってジオメトリカラムを追加した場合、ジオメトリの次元に関する制限があることに注意してください。この制限を迂回するには、制限の削除が必要になります。geometry_columnsテーブル内のエントリを更新して、その後で制限を再作成することを忘れないで下さい。

大きなテーブルの場合、WHERE節、およびプライマリキー若しくは他の適切な基準によってテーブルの一部へのUPDATEを制限させて、UPDATEの実行の間に単に"VACUUM;"と実行することで、UPDATEをより小さい塊に分割するのが賢いやり方かもしれません。これにより、テンポラリディスクスペースが劇的に減少します。さらに、次元混合のジオメトリを持つ場合、"WHERE dimension(the_geom)>2"によってUPDATEを制限することで、2次元で書かれているジオメトリの再書き込みをスキップさせることができます。

第6章 PostGISリファレンス

ここで示す関数はPostGISユーザが必要とすると思われる関数です。この他に、一般的なユーザが使わないPostGISオブジェクトに対して求められるサポート関数があります。

注記

PostGISは、既存の名前付け方針からSQL-MM中心の方針への切り替えを開始しています。結果として、ユーザが知っていて愛用している関数の多くが標準空間型 (ST)プレフィクスを使うように名前変更されました。 以前の関数はまだ有効ですが、更新された等価な関数があるものについては、この文書の一覧から外しています。これらの関数は、将来のリリースでは非推奨になります。

6.1. OpenGIS関数

6.1.1. 管理関数

AddGeometryColumn(varchar, varchar, varchar, integer, varchar, integer)

構文: AddGeometryColumn(<スキーマ名>, <テーブル名>, <カラム名>, <srid>, <タイプ>, <次元>). 存在する属性テーブル (訳注:ジオメトリカラムが存在しない意と思われますが、ジオメトリカラムが既に存在していても追加できます)」にジオメトリカラムを追加します。スキーマ名は、テーブルスキーマの名前です (プリスキーマ版PostgreSQLの場合は使われません)。 sridは、SPATIAL_REF_SYSテーブルに登録されている整数値でなければなりません。 型は、'POLGYON', 'MULTILINESTRING' などのように、常に大文字の文字列で、ジオメトリ型に対応していなければなりません。

DropGeometryColumn(varchar, varchar, varchar)

構文: DropGeometryColumn(<スキーマ名>, <テーブル名>, <カラム名>). ジオメトリカラムを空間テーブルから削除します。 スキーマ名はgeometry_columnsテーブル内にある、そのテーブル名を持つ行のf_schema_nameフィールドと一致しなければならないことに注意して下さい。

Probe_Geometry_Columns()

PostGISジオメトリ制約 (訳注: カラム型がジオメトリ型でSRID制約とgeometrytype制約を持つカラム)を持つテーブルの全てをスキャンして、まだgeometry_columnsテーブルに存在しない場合には、geometry_columnsに追加します。また、挿入数、既存数または廃止カラム数の統計を与えます。

ST_SetSRID(geometry, integer)

ジオメトリのSRIDを特定の整数値に設定します。クエリのためのバウンディングボックスを生成する際に使います。

6.1.2. 空間関係関数

ST_Distance(geometry, geometry)

投影された単位での二つのジオメトリの間のデカルト距離を返します。インデクスは使いません。

ST_DWithin(geometry, geometry, float)

ジオメトリ間の距離が指定した距離以内ならtrueを返します。インデクスがあるならインデクスを使います。

ST_Equals(geometry, geometry)

ジオメトリが「空間的に等価」であるなら1 (TRUE)を返します。'='より「良い」回答が得られます。equals('LINESTRING(0 0, 10 10)','LINESTRING(0 0, 5 5, 10 10)')は、trueになります。

GEOSモジュールによって実現しています。

OGC SPEC s2.1.1.2

ST_Disjoint(geometry, geometry)

ジオメトリが「空間的にインタセクトしている (訳注:共通領域を持つ)」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 //s2.1.13.3 - a.Relate(b, 'FF*FF****')

ST_Intersects(geometry, geometry)

ジオメトリが「空間的にインタセクトしている (訳注:共通領域を持つ)」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数には、自動的に、ジオメトリに付けられたインデックスを使ったバウンディングボックス比較を含みます。インデックスの使用を避けたいなら、_ST_Intersectsを使います。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 //s2.1.13.3 - Intersects(g1, g2 ) --> Not (Disjoint(g1, g2 ))

ST_Touches(geometry, geometry)

ジオメトリが「空間的に接触している」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数には、自動的に、ジオメトリに付けられたインデックスを使ったバウンディングボックス比較を含みます。インデックスの使用を避けたいなら、_ST_Touchesを使います

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3- a.Touches(b) -> (I(a) intersection I(b) = {empty set} ) and (a intersection b) not empty

ST_Crosses(geometry, geometry)

ジオメトリが「空間的にクロスしている (訳注:共通領域を持ち、かつ共通領域の次元が引数ジオメトリの最大次元-1」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数には、自動的に、ジオメトリに付けられたインデックスを使ったバウンディングボックス比較を含みます。インデックスの使用を避けたいなら、_ST_Crossesを使います

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3 - a.Relate(b, 'T*T******')

ST_Within(geometry A, geometry B)

ジオメトリAがジオメトリB「の中に空間的にいる」なら1 (TRUE)を返します。Aは完全にBの内部にいなければなりません。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数の呼び出しによって、ジオメトリで使用可能なインデックスを使用したバウンディングボックスの比較が自動的に行われます。インデックスの使用を避けるには_ST_Withinを使います。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3 - a.Relate(b, 'T*F**F***')

ST_Overlaps(geometry, geometry)

ジオメトリが「空間的にオーバラップしている」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数の呼び出しによって、ジオメトリで使用可能なインデクスを使用したバウンディングボックスの比較が自動的に行われます。インデクスの使用を避けるには_ST_Overlapsを使います。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3

ST_Contains(geometry A, geometry B)

ジオメトリAがジオメトリBを「空間的に含んでいる」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

この関数の呼び出しによって、ジオメトリで使用可能なインデクスを使用したバウンディングボックスの比較が自動的に行われます。インデクスの使用を避けるには、_ST_Containsを使います。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3 - within(geometry B, geometry A)と同じ

ST_Covers(geometry A, geometry B)

ジオメトリBにジオメトリAの外となるポイントが無い場合には、1 (TRUE)を返します。

この関数の必要性についてはhttp://lin-ear-th-inking.blogspot.com/2007/06/subtleties-of-ogc-covers-spatial.htmlを参照して下さい。

この関数の呼び出しによって、ジオメトリで使用可能なインデックスを使用したバウンディングボックスの比較が自動的に行われます。インデックスの使用を避けるには、_ST_Coversを使います。

ST_CoveredBy(geometry A, geometry B)

ジオメトリAにジオメトリBの外となるポイントが無い場合には、1 (TRUE)を返します。

この関数の必要性についてはhttp://lin-ear-th-inking.blogspot.com/2007/06/subtleties-of-ogc-covers-spatial.htmlを参照して下さい。

ST_Intersects(geometry, geometry)

ジオメトリが「空間的にインタセクトしている (訳注:共通領域を持つ)」なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3 - NOT disjoint(geometry, geometry)

ST_Relate(geometry, geometry, intersectionPatternMatrix)

このジオメトリが空間的に、もう一つのジオメトリに関連しているなら1 (TRUE)を返します。 この関連は、intersectionPatternMatrix行列の値によって指定された、 二つのジオメトリの内部、境界、外部の交差要素を見ることで決定されます。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

ご注意: これは論理値を返して整数を返さないのが「許される」版です。

OGC SPEC s2.1.1.2 // s2.1.13.3

ST_Relate(geometry, geometry)

DE-9IM (次元拡張された9要素行列)を返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

OGC仕様にはありませんが実装しました。s2.1.13.2をご覧下さい。

6.1.3. ジオメトリ処理関数

ST_Centroid(geometry)

ジオメトリの重心をポイントとして返します。

GEOSモジュールによって実現されている (コンパイル時に指定されます)なら、より正確に計算できます。

ST_Area(geometry)

ジオメトリがポリゴンかマルチポリゴンならジオメトリの面積を返します。

ST_Length(geometry)

ジオメトリの、組み込まれている空間参照系での曲線長を返します。

これはlength2d()の別名です。

OGC SPEC 2.1.5.1

ST_PointOnSurface(geometry)

表面にあることが保障された点を返します。

GEOSモジュールによって実現しています。

OGC SPEC 3.2.14.2 and 3.2.18.2 -

ST_Boundary(geometry)

ジオメトリの組み合わせ境界の閉包を返します (訳注: ラインストリングは端点、ポリゴンはエッジ、複合オブジェクトは境界のうち奇数番)。組み合わせ境界はOGC仕様の3.12.3.2節に記述されています。結果として出てくる境界は、OGC SPEC 3.12.2で議論されているように、ジオメトリプリミティブを使って表現できます。

GEOSモジュールによって実現しています。

OGC SPEC s2.1.1.1

ST_Buffer(geometry, double, [integer])

ジオメトリからの距離が指定した距離未満となる全てのポイントを示すジオメトリを返します。オプションの第3引数では、4分の1にした円を近似するために使われる弦の数を設定します (デフォルトは8です)。

GEOSモジュールで実現しています。

OGC SPEC s2.1.1.3

ST_ConvexHull(geometry)

凸包(convex hull)は与えられた集合の全てのジオメトリを含む最小の閉じたジオメトリです (訳注: 板に何本も釘を刺して外側から輪ゴムをかけた様子を想像して下さい。釘がジオメトリを示し、輪ゴムを境界とした作られる図形が凸包です)。

通常は、マルチ系ジオメトリとジオメトリコレクションで使われます。この関数は集計関数ではありませんが、ポイントの集合の凸包を得るために、ST_ConvexHull(ST_Collect(somepointfield))のようにST_Collectと併用して使います。この併用は、次のように、観測したポイントの集合をもとに影響を受ける領域を決定するためにしばしば使われます。

SELECT d.disease_type, ST_ConvexHull(ST_Collect(d.the_geom)) As the_geom 
        FROM disease_obs As d 
        GROUP BY d.disease_type

GEOSモジュールによって実現しています。

OGC SPEC s2.1.1.3

ST_Intersection(geometry, geometry)

ジオメトリのインタセクションとなる点集合を表現するジオメトリを返します。

言い換えると、ジオメトリAとジオメトリBとで共有されている部分のことです。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

OGC SPEC s2.1.1.3

ST_Shift_Longitude(geometry)

ジオメトリの全ての地物の全てのポイント/頂点を読み、経度値が0より小さい場合には360を足します。結果は、180度を中心にした地図に描画される、経度が0-360の区間にあるデータです。

1.3.4より前ではMULTIPOINTでは動作しない誤りがありました。1.3.4以上ではMULTIPOINTでも動作します。

ST_SymDifference(geometry A, geometry B)

AとBの、インタセクトしていない部分を表現するジオメトリを返します。対称と呼ばれるのは、ST_SymDifference(A,B) = ST_SymDifference(B,A) となるからです。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

OGC SPEC s2.1.1.3

ST_Difference(geometry A, geometry B)

ジオメトリBにインタセクトしないジオメトリAの部分を表現するジオメトリを返します。

GEOSモジュールによって実現しています。

ジオメトリコレクションを引数として呼ばないでください。

OGC SPEC s2.1.1.3

ST_Union(geometry, geometry)

ジオメトリの結合の点集合を表現するジオメトリを返します。

GEOSモジュールで実現しています。

ジオメトリコレクションを引数として呼んではなりません。

ご注意: この関数は以前は、"Union"から名称変更してGeomUnion()と呼ばれていました。UNIONはSQLの予約語であるためです。

OGC SPEC s2.1.1.3

ST_Union(geometry set)

与えられた集合の全てのジオメトリを結合したポイント集合を示すジオメトリを返します。

GEOSモジュールで実現しています。

ジオメトリコレクションを引数集合で呼んではなりません。

OGC仕様では明示的に定義されていません。

ST_MemUnion(geometry set)

上と同じですが、メモリフレンドリ (少ないメモリ使用で長い処理時間)です。

6.1.4. ジオメトリアクセサ

ST_AsText(geometry)

ジオメトリのWell-Known Text表現を返します。たとえばPOLYGON(0 0,0 1,1 1,1 0,0 0)などです。

OGC SPEC s2.1.1.1

ST_AsBinary(geometry)

ジオメトリをOGC"Well-Known Binary"表現で返します。データベースが動いているサーバのエンディアンを使います。これは文字列表現に変換せずにデータをデータベースから引き出すバイナリカーソルに有用です。

OGC SPEC s2.1.1.1 - asBinary(<geometry>,'XDR') and asBinary(<geometry>,'NDR')も参照して下さい

ST_SRID(geometry)

ジオメトリの空間参照系SRIDを整数で返します。

OGC SPEC s2.1.1.1

ST_Dimension(geometry)

このジオメトリオブジェクトの固有の次元です。 ジオメトリオブジェクトは座標の次元以下である必要があります。OGC SPEC s2.1.1.1 - 0ならポイント、1ならライン、2ならポリゴン、ジオメトリコレクションの場合は要素ごとの次元の最大値です。

select dimension('GEOMETRYCOLLECTION(LINESTRING(1 1,0 0),POINT(0 0)'); 
dimension 
----------- 
1
ST_Envelope(geometry)

ジオメトリーのバウンディングボックスを表している有効なジオメトリ(POINT、LINESTRINGまたはPOLYGON)を返します。縮退した場合(垂直線、点)は、POLYGONより低い次元のジオメトリを返します。

OGC SPEC s2.1.1.1 -このジオメトリの最小のバウンディングボックスをジオメトリとして返します。ポリゴンはバウンディングボックスの頂点((MINX, MINY), (MAXX, MINY), (MAXX, MAXY), (MINX, MAXY), (MINX, MINY))で定義されます。

ご注意: PostGISはZmin/Zmax座標も同様に加えます。

ST_IsEmpty(geometry)

ジオメトリが空ジオメトリなら1 (TRUE)を返します。 TRUEなら、このジオメトリは空のポイント集合を示すジオメトリ、すなわちGEOMETRYCOLLECTION(EMPTY)です。

OGC SPEC s2.1.1.1

ST_IsSimple(geometry)

Returns 1 (TRUE) if this Geometry has no anomalous geometric points, such as self intersection or self tangency.

GEOSモジュールによって実現しています。

OGC SPEC s2.1.1.1

ST_IsClosed(geometry)

開始点と終了点とが同じになっているジオメトリならTRUEを返します。

ST_IsRing(geometry)

この曲線が閉じていて( StartPoint( ) = EndPoint( ) )、この曲線が単純 (2回以上同一点を通過しない)なら1 (TRUE)を返します。

GEOSモジュールによって実現しています。

OGC spec 2.1.5.1

ST_NumGeometries(geometry)

ジオメトリがGEOMETRYCOLLECTION (または MULTI系)の場合はジオメトリ数を返し、そうでないならNULLを返します。

ST_GeometryN(geometry,int)

ジオメトリがGEOMETRYCOLLECTION, MULTIPOINT, MULTILINESTRINGまたはMULTIPOLYGONの場合はN番目のジオメトリを返します。それ以外の場合はNULLを返します。

注記

OGC仕様のため0.8.0版からインデクスを1始まりにしています。これより前の版では0始まりになっています。

ST_NumPoints(geometry)

ジオメトリの最初のラインストリングのポイント数を返します。ジオメトリにラインストリングが無い場合はNULLを返します。

ST_PointN(geometry,integer)

ジオメトリの最初のラインストリングにおける、N番目のポイントを返します。ジオメトリにラインストリングが無い場合はNULLを返します。

注記

OGC仕様のため0.8.0版からインデクスを1始まりにしています。これより前の版では0始まりになっています。

ST_ExteriorRing(geometry)

ポリゴンの外環を返します。ジオメトリがポリゴンでない場合はNULLを返します。

ST_NumInteriorRings(geometry)

ジオメトリの最初のポリゴンの内環数を返します。ジオメトリにポリゴンが無い場合はNULLを返します。

ST_NumInteriorRing(geometry)

NumInteriorRings(geometry)の別名です。OpenGIS仕様では、関数の名前付けについてあいまいであるため、両方のスペリングの関数を提供しています。

ST_InteriorRingN(geometry,integer)

ポリゴンのN番目の内環を返します。ジオメトリがポリゴンでないか、N番が範囲外である場合はNULLを返します。

注記

OGC仕様のため0.8.0版からインデクスを1始まりにしています。これより前の版では0始まりになっています。

ST_EndPoint(geometry)

ラインストリングの最後のポイントをポイントで返します。

ST_StartPoint(geometry)

ラインストリングの最初のポイントをポイントで返します。

GeometryType(geometry)

ジオメトリタイプを文字列で返します。たとえば'LINESTRING', 'POLYGON', 'MULTIPOINT'等です。

OGC SPEC s2.1.1.1 - このジオメトリインスタンスがメンバーになっているジオメトリのインスタンス化可能な派生タイプの名前を返します。インスタンス化可能な派生タイプの名前は、文字列として返されます。

注記

この関数は、'POINTM'等が返るので、ジオメトリがM値を持っているかどうかも示します。

ST_GeometryType(geometry)

ジオメトリタイプを文字列で返します。たとえば、'Linestring', 'Polygon' 等です。この関数は、GeometryType(geometry)と異なり、ジオメトリが計測された (訳注:「M座標を持つ」という意味)かどうかを示さず、また、返される文字列の大文字小文字の差があります。

ST_X(geometry)

ポイントのX座標値を返します。引数はポイントでなければなりません。

ST_Y(geometry)

ポイントのY座標値を返します。引数はポイントでなければなりません。

ST_Z(geometry)

ポイントのZ座標値を返し、Z座標が無い場合はNULLを返します。引数はポイントでなければなりません。

ST_M(geometry)

ポイントのM座標値を返し、M座標が無い場合はNULLを返します。引数はポイントでなければなりません。

注記

これは (いまだに)OGC仕様に入っていませんが、ポイント座標抽出関数のリストを完全にするために挙げています。

6.1.5. ジオメトリ コンストラクタ

ST_GeomFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

ST_PointFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがポイントでない場合はエラーを投げます。

ST_LineFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

ST_LinestringFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

仕様適合のためです。

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

ST_PolyFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがポリゴンでない場合はエラーを投げます。

ST_PolygonFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

仕様適合のためです。

WKTがポリゴンでない場合はエラーを投げます。

ST_MPointFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがマルチポイントでない場合はエラーを投げます。

ST_MLineFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがマルチラインストリングでない場合はエラーを投げます。

ST_MPolyFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがマルチポリゴンでない場合はエラーを投げます。

ST_GeomCollFromText(text,[<srid>])

ジオメトリをWKTから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKTがジオメトリコレクションでない場合はエラーを投げます。

ST_GeomFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

ST_GeometryFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

ST_PointFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがポイントでない場合はエラーを投げます。

ST_LineFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがラインストリングでない場合はエラーを投げます。

ST_LinestringFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

仕様適合のためです。

WKBがラインストリングでない場合はエラーを投げます。

ST_PolyFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがポリゴンでない場合はエラーを投げます。

ST_PolygonFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

仕様適合のためです。

WKBがポリゴンでない場合はエラーを投げます。

ST_MPointFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがマルチポイントでない場合はエラーを投げます。

ST_MLineFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがマルチラインストリングでない場合はエラーを投げます。

ST_MPolyFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがマルチポリゴンでない場合はエラーを投げます。

ST_GeomCollFromWKB(bytea,[<srid>])

ジオメトリをWKBから作成し、SRIDを与えます。SRIDが与えられない場合は-1をデフォルトで与えます。

OGC SPEC 3.2.6.2 - 任意引数SRIDは仕様適合のためです。

WKBがジオメトリコレクションでない場合はエラーを投げます。

ST_BdPolyFromText(text WKT, integer SRID)

マルチラインストリングのテキスト表現で示された、任意の閉じたラインストリングのコレクションで作られたポリゴンを生成します。

WKTがマルチラインストリングでないならエラーを投げます。出力がマルチポリゴンならエラーを投げるので、その場合はBdMPolyFromTextを使うか、PostGIS独自のアプローチのBuildArea()をご覧下さい。

OGC SFSQL 1.1 - 3.2.6.2

Availability: 1.1.0 - GEOS 2.1.0以上が必要です。

ST_BdMPolyFromText(text WKT, integer SRID)

マルチラインストリングのテキスト表現で示された、任意の閉じたラインストリングのコレクションで作られたマルチポリゴンを生成します。

WKTがマルチラインストリングでないならエラーを投げます。結果が本当に一つだけのポリゴンであったとしても、マルチポリゴンで出力します。一つだけのポリゴンが返ってくるのが確実でしたら、BdPolyFromTextを使うか、PostGIS独自のアプローチであるBuildArea()をご覧下さい。

OGC SFSQL 1.1 - 3.2.6.2

Availability: 1.1.0 - GEOS 2.1.0以上が必要です。

6.2. PostGIS独自拡張

6.2.1. 管理関数

DropGeometryTable([<スキーマ名>], <テーブル名>)

テーブルとgeometry_columnsからの参照を削除します。 ご注意: スキーマ対応版PostgreSQLでは、スキーマが与えられない場合はcurrent_schema()を使います。

UpdateGeometrySRID([<schema_name>], <table_name>, <column_name>, <srid>)

ジオメトリカラムにある全てのフィーチャーのSRIDを更新し、SRIDに関するジオメトリ制限とgeometry_columnsのSRIDを更新します。ご注意: スキーマ対応版PostgreSQLでは、スキーマが与えられない場合はcurrent_schema()を使います。

update_geometry_stats([<table_name>, <column_name>])

クエリプランナが使う、空間テーブルの統計情報を更新します。統計情報収集処理を完全にするためにはには"VACUUM ANALYZE [テーブル名] [カラム名]"も実行する必要があります。ご注意: PostgreSQL 8.0からは統計情報の収集は"VACUUM ANALYZE"で自動的に行われます。

postgis_version()

PostGISの版番号とコンパイルオプションを返します。

注記

1.1.0版より前では、これはプロシージャだったので、不正確な情報が返る可能性があります (不完全なデータベースアップグレードを行った場合)。

postgis_lib_version()

PostGISライブラリの版を返します。

Availability: 0.9.0

postgis_lib_build_date()

PostGISライブラリをビルドした日を返します。

Availability: 1.0.0RC1

postgis_script_build_date()

PostGISスクリプトをビルドした日を返します。

Availability: 1.0.0RC1

postgis_scripts_installed()

このデータベースにインストールしたPostGISスクリプトの版を返します。

注記

この関数の出力とpostgis_scripts_released()の出力が一致しない場合、既存データベースの完全なアップグレードに失敗しているかも知れません。詳細については、アップグレードの節をご覧下さい。

Availability: 0.9.0

postgis_scripts_released()

インストールされたPostGISライブラリからリリースされたlwpostgis.sqlスクリプトの版番号を返します。

注記

1.1.0からは、この関数はpostgis_lib_version()と同じ値を返します。後方互換のために維持されます。

Availability: 0.9.0

postgis_geos_version()

GEOSライブラリの版を返します。GEOS対応が有効でないならNULLを返します。

Availability: 0.9.0

postgis_jts_version()

JTSライブラリの版番号を返します。JTS対応が有効でないならNULLを返します。

Availability: 1.1.0

postgis_proj_version()

PROJ4ライブラリの版を返します。PROJ4対応が有効でないならNULLを返します。

Availability: 0.9.0

postgis_uses_stats()

STATSの使用が可能になっているならTRUEを返し、そうでないならFALSEを返します。

Availability: 0.9.0

postgis_full_version()

完全なPostGISの版情報とコンフィギュレーション情報を報告します。

Availability: 0.9.0

6.2.2. 演算子

A = B

"="演算子は、AのバウンダリボックスがBのバウンダリボックスが同じならTRUEを返します。

注記

この演算子は、多くの混乱を引き起こします。ジオメトリA=ジオメトリBの比較を実行すると、バウンダリボックスが同じならジオメトリが明らかに異なっていてもtrueを返します。本当に同等であるかをチェックするには、ST_OrderingEqualsまたはST_Equalsを使用して下さい。

A &< B

"&<"演算子は、AのバウンディングボックスがBのバウンディングボックスとオーバラップしているか左側にある場合にTRUEを返します。

A &> B

"&>"演算子は、AのバウンディングボックスがBのバウンディングボックスとオーバラップしているか右側にある場合にTRUEを返します。

A << B

"<<"演算子は、Aのバウンディングボックスが厳密にBのバウンディングボックスの左側にある場合にTRUEを返します。

A >> B

"> >" 演算子は、a の境界ボックスが B の境界ボックスの右側に厳密にある場合に true を返します。

A &<| B

"&<|"演算子は、AのバウンディングボックスがBのバウンディングボックスとオーバラップしているか下にある場合にTRUEを返します。

A |&> B

"|&>"演算子は、AのバウンディングボックスがBのバウンディングボックスとオーバラップしているか上にある場合にTRUEを返します。

A <<| B

"<<|"演算子は、Aのバウンディングボックスが厳密にBのバウンディングボックスの下にある場合にTRUEを返します。

A |>> B

"|>>"演算子は、Aのバウンディングボックスが厳密にBのバウンディングボックスの上にある場合にTRUEを返します。

A ~= B

"~="演算子は、「同じ形のもの」演算子です。二つのジオメトリが実際に幾何学的に等価であるかどうかを見ます。AとBが頂点ごとに見て同じフィーチャーの場合にTRUEを返します。

A @ B

"@"演算子は、Aのバウンディングボックスが完全にBのバウンディングボックスに含まれる場合にTRUEを返します。

A ~ B

"~"演算子は、Aのバウンディングボックスが完全にBのバウンディングボックスを含む場合にTRUEを返します。

A && B

"&&"演算子は、オーバラップ演算子です。AのバウンディングボックスがBのバウンディングボックスをオーバラップする場合にTRUEを返します。

6.2.3. 計測関数

ST_Area(geometry)

ジオメトリがポリゴンかマルチポリゴンならジオメトリの面積を返します。

ST_distance_sphere(point, point)

緯度経度で示された二点の直線距離をメートルで返します。半径6370986メートルの球体とします。distance_spheroid()より早いですが、精度は落ちます。ポイントについてのみ実装しています。

ST_distance_spheroid(point, point, spheroid)

指定した楕円体を使って、緯度経度で示された2点の直線距離をメートルで返します。length_spheroid()にある楕円体の説明をご覧下さい。現在は、ポイントについてのみ実装しています。

ST_length2d(geometry)

ラインストリングまたはマルチラインストリングの場合に、ジオメトリの2次元の長さを返します。

ST_length3d(geometry)

ラインストリングまたはマルチラインストリングの場合に、ジオメトリの3次元の長さを返します。

ST_length_spheroid(geometry,spheroid)

回転楕円体上の長さを計算します。この関数は、ジオメトリの座標が経度/緯度であって、投影変換を行わずに長さを求めたい場合に使います。回転楕円体は別々のデータベースタイプで、次のように構成されています。

SPHEROID[<名称>,<長軸半径>,<扁平率の逆数>]

例:

SPHEROID["GRS_1980",6378137,298.257222101]

計算例は次のようになるでしょう。

SELECT length_spheroid( geometry_column,
              'SPHEROID["GRS_1980",6378137,298.257222101]' )
              FROM geometry_table;

ST_length3d_spheroid(geometry,spheroid)

ジオメトリの楕円体上の長さを、標高を考慮して計算します。この関数は、鉛直変動によって加えられる距離を計算するために鉛直座標 (楕円体の軸と同じ単位です)を使うことを除くと、ちょうどlength_spheroidに似ています。

ST_distance(geometry, geometry)

二つのジオメトリ間の最短距離を返します。

ST_max_distance(linestring,linestring)

二つのラインストリング間の最長距離を返します。

ST_perimeter(geometry)

POLYGONまたはMULTIPOLYGONジオメトリの場合に、2次元周囲長を返します。

ST_perimeter2d(geometry)

POLYGONまたはMULTIPOLYGONジオメトリの場合に、2次元周囲長を返します。

ST_perimeter3d(geometry)

POLYGONまたはMULTIPOLYGONジオメトリの場合には、3次元周囲長を返します。

ST_azimuth(geometry, geometry)

与えられたポイントからなる線分の方位をラジアンで返します。二点が同位置にある場合はNULLを返します。

Availability: 1.1.0

6.2.4. ジオメトリ出力

ST_AsBinary(geometry,{'NDR'|'XDR'})

リトルエンディアン(NDR)またはビッグエンディアン(XDR)を使ったOGC "Well-known-binary"表現をbytea型で返します。この関数は、データをデータベース外に文字列表現を使わずに持ち出すバイナリカーソルで有用です。

ST_AsEWKT(geometry)

ジオメトリのEWKT表現をTEXT型で返します。

ST_AsEWKB(geometry, {'NDR'|'XDR'})

リトルエンディアン (NDR)またはビッグエンディアン (XDR)を使ったEWKB表現をbytea型で返します。

ST_AsHEXEWKB(geometry, {'NDR'|'XDR'})

ジオメトリのHEXEWKB表現を (文字列として)返します。リトルエンディアン (NDR)またはビッグエンディアン (XDR)のどちらかのエンコーディングを使います。

ST_AsSVG(geometry, [rel], [precision])

ジオメトリをSVGパスデータで返します。第2引数に1を指定すると、相対移動によるパスデータ実装を返します。デフォルト (または0指定)では、絶対移動を使います。第3引数は、出力の十進数の最大桁数を減らすために使います (デフォルトは15です)。'rel'が0のときはポイントはcx/cyに、'rel'が1のときはx/yに、それぞれ出力します。マルチポイントはコンマ (",")で区切られ、ジオメトリコレクションはセミコロン (";")で区切られます。

ST_AsGML([version], geometry, [precision])

ジオメトリをGMLエレメントで返します。version引数は、指定する場合は2または3にすることができます。version引数を指定しない場合は、デフォルトを2と仮定します。第3引数は、出力の最大有効桁数を減らすために使います (デフォルトは15です)。

ST_AsKML([version], geometry, [precision])

ジオメトリをKMLエレメントを返します。第2引数は、出力の最大有効桁数を減らすために使います (デフォルトは15です)。versionのデフォルトは2です。

注記

PostGISがProj対応でコンパイルされている必要があります。PostGIS_Full_Version()を使ってProj対応でコンパイルされているか確認して下さい。

ST_AsGeoJson([version], geometry, [precision], [options])

ジオメトリをGeoJsonエレメントで返します (GeoJson specifications 1.0参照)。2次元および3次元のジオメトリの両方ともサポートされています。GeoJsonはSFS 1.1ジオメトリタイプのみサポートされています (たとえば曲線はサポートされていません)。

version引数は、指定する場合には常に1でなければなりません。

第3引数は、出力の最大有効桁数を減らすために使われることがあります (デフォルトは15です)。

最後の"options"引数は、GeoJSON出力にBBoxまたはCRSを追加するために使われます。次のようにします。

  • 0: オプションなし (デフォルト値)

  • 1: GeoJson CRS

  • 2: GeoJson Bbox

  • 3: GeoJson Bbox および CRS の両方

GeoJson CRSパターンは、spatial_ref_sysテーブルからauth_name:auth_sridという形式で生成されます (例えば "EPSG:4326")。

Availability: 1.3.4

6.2.5. ジオメトリ コンストラクタ

ST_GeomFromEWKT(text)

EWKBからジオメトリを生成します。

ST_GeomFromEWKB(bytea)

EWKBからジオメトリを生成します。

ST_MakePoint(<x>, <y>, [<z>], [<m>])

2次元、3次元、4次元のポイントジオメトリを生成します。

ST_MakePointM(<x>, <y>, <m>)

XYMのポイントジオメトリを生成します。

ST_MakeBox2D(<LL>, <UR>)

与えられたポイントジオメトリから定義されるBOX2Dを生成します。

ST_MakeBox3D(<LLB>, <URT>)

与えられた3次元ポイントジオメトリから定義されるBOX3Dを生成します。

ST_MakeLine(geometry set)

ポイントジオメトリの集合からラインストリングをひとつ生成します。この集計関数に渡す前に、副問い合わせでポイントを並べ替えると良いかも知れません。

ST_MakeLine(geometry, geometry)

与えられた二つのポイントからラインストリングを生成します。

ST_LineFromMultiPoint(multipoint)

マルチポイントジオメトリからラインストリングを生成します。

ST_MakePolygon(linestring, [linestring[]])

与えられた外周、穴の配列で形作られるポリゴンを生成します。ジオメトリ配列はAccumを使って生成します。 入力ジオメトリは閉じたラインストリングである必要があります (IsClosedGeometryTypeを参照して下さい)。

ST_BuildArea(geometry)

与えられたジオメトリの構成する線によって形成される面ジオメトリを生成します。返り値は、入力に応じて、ポリゴンまたはマルチポリゴンになります。入力がポリゴンを形成できない場合はNULLを返します。

標準OGCインタフェースを持つ関数へのラッパーであるBdPolyFromTextBdMPolyFromTextを参照してください。

Availability: 1.1.0 - GEOS 2.1.0以上が必要です。

ST_Polygonize(geometry set)

集約関数。ジオメトリの集合のラインから形成されうるポリゴンを含むジオメトリコレクションを生成します。

Availability: 1.0.0RC1 - GEOS 2.1.0が必要です。

ST_Collect(geometry set)

ジオメトリの集合からジオメトリコレクションまたはマルチ系オブジェクトを返します。collect()関数はPostgreSQLの用語で言うところの「集計関数」です。これは、sum()やmean()関数と同じようにデータの複数行を扱うということを意味します。たとえば、"SELECT COLLECT(GEOM) FROM GEOMTABLE GROUP BY ATTRCOLUMN"は、ATTRCOLUMNの値ごとに分かれたジオメトリコレクションを返します。

ST_CollectとST_Unionはしばしば交換して使うことができます。ST_Collectはバウンダリを消そうとしないので一般的にST_Unionよりも桁違いに早く動きます。ST_Collectは、単に、シングルジオメトリをマルチ系ジオメトリに巻き込み、マルチ系ジオメトリまたはジオメトリ型混在の集合をジオメトリコレクションに巻き込む、ということを行っているだけです。不幸なことに、GISツールはジオメトリコレクションを十分にサポートしていません。マルチ系ジオメトリを集める時にST_Collectがジオメトリコレクションを返すのを防ぐために、次に示すように、ST_Dumpでマルチ系ジオメトリをシングル系ジオメトリに展開したうえで再グループ化するというトリックを使うことができます。

Thread ref: http://postgis.refractions.net/pipermail/postgis-users/2008-June/020331.html
SELECT stusps, 
           ST_Multi(ST_Collect(f.the_geom)) as singlegeom  
         FROM (SELECT stusps, (ST_Dump(the_geom)).geom As the_geom 
                                FROM
                                somestatetable ) As f
GROUP BY stusps
                          
ST_Collect(geometry, geometry)

二つの入力ジオメトリをまとめたジオメトリを返します。出力タイプはMULTI系またはGEOMETRYCOLLECTIONです。

ST_Dump(geometry)

これは集合を返す関数 (SRF=set-returning function)です。ジオメトリ (geom)と整数配列 (path)で作られるgeometry_dump行を返します。入力ジオメトリが単純型 (POINT,LINESTRING,POLYGON)の場合は、単一の行で返り、pathには空配列、geomには入力ジオメトリが入ります。入力ジオメトリがジオメトリコレクションまたはMULTI系の場合は、要素ごとの行で返り、pathはコレクション内の要素位置を表します。

ST_Dumpはジオメトリを展開するのに使えます。新しい行を作る点では、GROUP BYの逆です。たとえば、MULTIPOLYGONをPOLYGONに展開するために使われます。

SELECT sometable.*, (ST_Dump(the_geom)).geom As the_geom 
         FROM somestatetable
                          

Availability: PostGIS 1.0.0RC1 PostgreSQL 7.3以上が必要です。

ST_DumpRings(geometry)

この関数は、集合を返す関数 (set-returning function=SRF)です。ジオメトリ (geom)と整数配列 (path)からなるgeometry_dump行の集合を返します。入力ジオメトリがシンプルタイプ (ポイント、ラインストリング、ポリゴン)の場合、pathが空で、geomが入力ジオメトリであるレコード1行が返ります。入力ジオメトリがコレクションまたはマルチ系の場合、コレクションの要素ごとにレコードが返り、この行については、pathはコレクション内の要素位置が入ります。

Availability: PostGIS 1.1.3 PostgreSQL 7.3以上が必要です。

6.2.6. ジオメトリエディタ

ST_AddBBOX(geometry)

ジオメトリにバウンディングボックスを追加します。これにより、バウンディングボックスに基づく検索が早くなりますが、ジオメトリのサイズが大きくなります。

ST_DropBBOX(geometry)

ジオメトリからバウンディングボックスのキャッシュを削除します。この関数は、ジオメトリのサイズを減らしますが、バウンディングボックスを用いたクエリを遅くします。

ST_AddPoint(linestring, point, [<position>])

ポイントを、ラインストリングの<pos>番目 (0はじまり)のポイントの前に追加します。第3引数を省略するか-1を設定すると、末尾に追加します。

ST_RemovePoint(linestring, offset)

ラインストリングからポイントを削除します。offsetの値は0はじまりです。

Availability: 1.1.0

ST_SetPoint(linestring, N, point)

ラインストリングのN番目 (0はじまり)の点を引数のポイントに置き換えます。

Availability: 1.1.0

ST_Force_collection(geometry)

ジオメトリをジオメトリコレクションに変換します。これはWKB表現を単純化するのに便利です。

ST_Force_2d(geometry)

ジオメトリを「2次元モード」に強制させます。全ての出力表現はXY座標値のみを持つことになります。OGC準拠の出力 (OGCは2次元ジオメトリのみ策定しています)に強制するために使われます。

ST_Force_3dz(geometry), ST_Force_3d(geometry)

ジオメトリをXYZモードに強制します。

ST_Force_3dm(geometry)

ジオメトリをXYMモードに強制します。

ST_Force_4d(geometry)

ジオメトリをXYZMモードに強制します。

ST_Multi(geometry)

マルチ系ジオメトリを返します。ジオメトリが既にマルチ系なら変更せずに返します。

ST_Transform(geometry,integer)

新しいジオメトリを整数値で参照されるSRIDに座標変換します。変換先SRIDはSPATIAL_REF_SYSテーブルに存在するものでなければなりません。

注記

PostGISがProj対応でコンパイルされている必要があります。PostGIS_Full_Version()を使ってProj対応でコンパイルされているか確認して下さい。

ST_Affine(geometry, float8, float8, float8, float8, float8, float8, float8, float8, float8, float8, float8, float8)

ジオメトリに対して3次元アフィン変換をかけます。次の関数を実行したとします。

Affine(geom, a, b, c, d, e, f, g, h, i, xoff, yoff, zoff) 

これは、次のような変換行列を示します。

/ a  b  c  xoff \ 
| d  e  f  yoff | 
| g  h  i  zoff | 
\ 0  0  0     1 /

頂点は、次のように変換されます。

x' = a*x + b*y + c*z + xoff 
y' = d*x + e*y + f*z + yoff 
z' = g*x + h*y + i*z + zoff

これ以降の全ての移動、拡大関数はこのようなアフィン変換で表現されます。

Availability: 1.1.2.

ST_Affine(geometry, float8, float8, float8, float8, float8, float8)

ジオメトリに2次元アフィン変換をかけます。次の関数を実行したとします。

Affine(geom, a, b, d, e, xoff, yoff)

これは、次のような変換行列を示します。

/  a  b  0  xoff  \       /  a  b  xoff  \ 
|  d  e  0  yoff  | rsp.  |  d  e  yoff  | 
|  0  0  1     0  |       \  0  0     1  / 
\  0  0  0     1  /

頂点は、次のように変換されます。

x' = a*x + b*y + xoff 
y' = d*x + e*y + yoff 
z' = z 

この関数は3次元アフィン変換を特殊化したものです。

Availability: 1.1.2.

ST_Translate(geometry, float8, float8, float8)

引数の数値をオフセットとして、ジオメトリを新しい位置に変換するものです。すなわちtranslate(geom,X,Y,Z)となります。

ST_Scale(geometry, float8, float8, float8)

ジオメトリを引数で指定された軸に対する乗数により新しいサイズに拡大縮小します。すなわちscale(geom,Xfactor,Yfactor,Zfactor)となります。

Availability: 1.1.0

ST_RotateZ(geometry, float8), ST_RotateX(geometry, float8), ST_RotateY(geometry, float8)

ジオメトリをZ, XまたはY軸を中心に、与えられたラジアン角度分回転させます。右手系に従います。

Availability: 1.1.2.

ST_TransScale(geometry, float8, float8, float8, float8)

まず前の二つのfloatを使ってジオメトリを移動させ、後の二つのfloatを使って拡大縮小を行います。これは2次元のみです。transscale(geom, X, Y, XFactor, YFactor)を呼んだ場合、内部ではaffine(geom, XFactor, 0, 0, 0, YFactor, 0, 0, 0, 1, X*XFactor, Y*YFactor, 0)を呼びます。

Availability: 1.1.0.

ST_Reverse(geometry)

ジオメトリの頂点の並びを逆順にして返します。

ST_ForceRHR(geometry)

コレクションのポリゴンを右回りに従わせます。

ST_Simplify(geometry, tolerance)

引数のジオメトリをDouglas-Peukerアルゴリズムを使って「単純化した」ものを返します。(マルチ)ラインと(マルチ)ポリゴンでないと実際には動作しませんが、安全にあらゆる種類のジオメトリを引数にできます。単純化はオブジェクトごとに実行されるものですから、ジオメトリコレクションをこの関数に送ることもできます。返されるジオメトリが単純性を失う可能性もあることにご注意ください(IsSimpleを参照して下さい)。

ST_SimplifyPreserveTopology(geometry, tolerance)

Douglas-Peukerを使って「単純化した」ものを返します。無効な派生ジオメトリ (特にポリゴン)の生成を避けます。

ST_SnapToGrid(geometry, originX, originY, sizeX, sizeY), ST_SnapToGrid(geometry, sizeX, sizeY), ST_SnapToGrid(geometry, size)

引数のジオメトリの全てのポイントを、定義された原点とセルサイズを持つグリッド上にスナップします。同じセルに落ちた、連続するポイントを削除します。引数ジオメトリのジオメトリタイプを定義できないポイントしか残らなかった場合は、NULLを返します。コレクション内で崩壊したジオメトリはそこから削除されます。

注記

返されるジオメトリは単純性を失う可能性があります (IsSimpleを参照して下さい)。

注記

1.1.0版より前では、この関数は常に2次元ジオメトリを返しました。1.1.0版からは、返されるジオメトリの次元数は、入力値のうちで手のつけられていない最大の次元と同じになります。全てのグリッドの次元を定義するには、第2引数にジオメトリを取る形式を使って下さい。

Availability: 1.0.0RC1

ST_SnapToGrid(geometry, geometry, sizeX, sizeY, sizeZ, sizeM)

引数ジオメトリの全てのポイントを原点 (第2引数で、これはポイントでなければなりません)とセルサイズで定義されたグリッドにスナップします。スナップを行いたくない次元があれば、その次元のサイズを0にして下さい。

Availability: 1.1.0

ST_Segmentize(geometry, maxlength)

与えられた距離を超えるセグメントを持たないように変更されたジオメトリを返します。差し込まれたポイントはZとM値を (必要なら)持ち、値は0に設定されます。距離計算は2次元でのみ行います。

ST_LineMerge(geometry)

引数ジオメトリを構成する線をまとめ合わせることで形成されるラインストリング (またはその集合)を返します。

Availability: 1.1.0 - GEOS 2.1.0以上が必要です。

6.2.7. 線型参照

ST_line_interpolate_point(linestring, location)

線に沿った内挿点を返します。第1引数はLINESTRINGでなければなりません。第2引数は、float8型で0から1の区間にある数でなければならず、返り値ポイントが置かれる位置ラインストリングの2次元線長の合計に対する割合です。

ポイントに最も近い線を計算するにはline_locate_point()を参照して下さい。

注記

1.1.1から、この関数はM軸やZ軸の内挿点も (存在するなら)計算するようになりました。それより前の版では0.0となります。

Availability: 0.8.2

ST_line_substring(linestring, start, end)

次元長に対する割合で示された開始位置と終了位置で切り取られた部分ラインストリングを返します。第2引数と第3引数は、float8で0から1の区間です。

'start'と'end'が同じ値を持つ場合は、この関数はline_interpolate_point()と等価です。

ポイントに最も近い線を計算するにはline_locate_point()を参照して下さい。

注記

1.1.1から、この関数はM軸やZ軸の内挿点も (存在するなら)計算するようになりました。それより前の版では不定値となります。

Availability: 1.1.0

ST_line_locate_point(LineString, Point)

引数で示されたポイントに最も近いラインストリング上の点の、2次元長の合計に対する割合を、0から1までの値で返します。

ポイント(line_interpolate_point)またはラインストリング(line_substring)を抽出するために、この関数から返された位置を使うことができます。

Availability: 1.1.0

ST_locate_along_measure(geometry, float8)

M値に一致する要素からなる、ジオメトリコレクションから派生した型の値を返します。ポリゴン要素には対応しません。

意味は ISO/IEC CD 13249-3:200x(E) - Text for Continuation CD Editing Meeting で決められています。

Availability: 1.1.0

ST_locate_between_measures(geometry, float8, float8)

指定したM値の範囲内にある要素からなる、派生ジオメトリコレクション値を返します。ポリゴン要素には対応していません。

意味は ISO/IEC CD 13249-3:200x(E) - Text for Continuation CD Editing Meeting で決められています。

Availability: 1.1.0

6.2.8. その他の関数

ST_Summary(geometry)

ジオメトリについての要約文を返します。

ST_box2d(geometry)

ジオメトリの最大範囲を表すBOX2Dを返します。

ST_box3d(geometry)

ジオメトリの最大範囲を表すBOX3Dを返します。

ST_extent(geometry set)

extent()関数はPostgreSQL用語で言うところの「集計関数」です。これは、sum()やmean()と同じ方法でデータリストの操作を行うことを意味します。たとえば、"SELECT EXTENT(GEOM) FROM GEOMTABLE"は、テーブル内の全てのフィーチャーの最大範囲を示すBOX3Dを返します。同様に、"SELECT EXTENT(GEOM) FROM GEOMTABLE GROUP BY CATEGORY"は、カテゴリごとの範囲を返します。

ST_zmflag(geometry)

ジオメトリのZM (次元の意味)フラグをsmall intで返します。値は、0=2次元, 1=M-三次元, 2=Z-3次元, 3=4次元です。

ST_HasBBOX(geometry)

このジオメトリのバウンディングボックスがキャッシュされている場合はTRUEを返し、それ以外の場合はFALSEを返します。キャッシュ制御にはaddBBOX()dropBBOX()を使います。

ST_ndims(geometry)

ジオメトリの座標次元をsmall intで返します。値は2, 3, 4のいずれかです。

ST_nrings(geometry)

ジオメトリがポリゴンまたはマルチポリゴンの場合、リング数を返します。

ST_npoints(geometry)

ジオメトリのポイント (頂点)数を返します。

ST_isvalid(geometry)

ジオメトリが妥当な場合にはTRUEを返します。

ST_expand(geometry, float)

入力ジオメトリのバウンディングボックスから、第2引数で指定される量によって、全ての方向に拡大させたバウンディングボックスを返します。 クエリにインデックスフィルタを追加するdistance()クエリにとても便利です。

ST_estimated_extent([schema], table, geocolumn)

与えられた空間テーブルの「見積もられた」範囲を返します。ジオメトリカラムの統計情報から見積もります。指定されていない場合は現在のスキーマが使われます。

PostgreSQL 8.0.0以上では、統計情報はVACUUM ANALYZEで集められ、結果の範囲は実際の約95%です。

PostgreSQL 8.0.0より前では、統計情報はupdate_geometry_stats()で集められ、範囲は確実です。

ST_find_srid(varchar,varchar,varchar)

この関数の書式はfind_srid(a_db_schema, a_table, a_column)です。GEOMETRY_COLUMNSで検索して、指定したカラムのSRID整数値を返します。ジオメトリカラムがAddGeometryColumn()関数で確実に追加していない場合には、確実には動作しません (訳注: GEOMETRY_COLUMNSビューで確実な登録が確認できていれば良いです)。

ST_mem_size(geometry)

ジオメトリが取る容量 (バイト単位)を返します。

ST_point_inside_circle(geometry, float, float, float)

この関数の書式はpoint_inside_circle(<geometry>,<circle_center_x>,<circle_center_y>,<radius>)です。ジオメトリがポイントで、かつ指定した円内にある場合はTRUEを返し、それ以外はFALSEを返します。

ST_XMin(box3d) ST_YMin(box3d) ST_ZMin(box3d)

バウンディングボックスの、それぞれX,Y,Z軸の最小値を返します。

ST_XMax(box3d) ST_YMax(box3d) ST_ZMax(box3d)

バウンディングボックスの、それぞれX,Y,Z軸の最大値を返します。

ST_Accum(geometry set)

集約関数です。ジオメトリの配列を生成します。

6.2.9. Long Transactions support

This module and associated pl/pgsql functions have been implemented to provide long locking support required by Web Feature Service specification.

注記

Users must use serializable transaction level otherwise locking mechanism would break.

EnableLongTransactions()

Enable long transaction support. This function creates the required metadata tables, needs to be called once before using the other functions in this section. Calling it twice is harmless.

Availability: 1.1.3

DisableLongTransactions()

Disable long transaction support. This function removes the long transaction support metadata tables, and drops all triggers attached to lock-checked tables.

Availability: 1.1.3

CheckAuth([<schema>], <table>, <rowid_col>)

Check updates and deletes of rows in given table for being authorized. Identify rows using <rowid_col> column.

Availability: 1.1.3

LockRow([<schema>], <table>, <rowid>, <authid>, [<expires>])

Set lock/authorization for specific row in table <authid> is a text value, <expires> is a timestamp defaulting to now()+1hour. Returns 1 if lock has been assigned, 0 otherwise (already locked by other auth)

Availability: 1.1.3

UnlockRows(<authid>)

Remove all locks held by specified authorization id. Returns the number of locks released.

Availability: 1.1.3

AddAuth(<authid>)

Add an authorization token to be used in current transaction.

Availability: 1.1.3

6.3. SQL-MM関数

ここでは、SQL-MMで定義されている、PostGISで現在サポートしている関数を示します。これらの関数の実装はArcSDE実装に続くもので、このため、仕様とずれているものがあります。これらのずれについては注意書きを付けていくものとします。

1.2.0版では、これらの関数はPostGIS関数のラッパーとして実装されています。結果、曲線ジオメトリの完全なサポートは多くの関数にとって適切な位置づけにないかも知れません。

注記

SQL-MMでは、全てのジオメトリコンストラクタのSRIDのデフォルトは0と定義されていますが、PostGISでは-1としています。

ST_Area

ST_SurfaceまたはST_MultiSurface値の面積計測を返します。

SQL-MM 3: 8.1.2, 9.5.3

ST_AsBinary

ST_Geometry値のWell-Known Binary表現を返します。

SQL-MM 3: 5.1.37

ST_AsText

ST_Geometry値のWell-Known Text表現を返します。

SQL-MM 3: 5.1.25

ST_Boundary

ST_Geometry値の境界を返します。

SQL-MM 3: 5.1.14

ST_Buffer

ST_Geometry値のバッファを返します。

SQL-MM 3: 5.1.17

ST_Centroid

ST_SurfaceまたはST_MultiSurface値の数学的重心を返します。

SQL-MM 3: 8.1.4, 9.5.5

ST_Contains

ST_Geometry値が空間的にもうひとつのST_Geometry値を含むかを見ます。

SQL-MM 3: 5.1.31

ST_ConvexHull

凸包 (convex hull)は与えられた集合の全てのジオメトリを含む最小の閉じたジオメトリです。

通常は、マルチ系ジオメトリとジオメトリコレクションで使われます。この関数は集計関数ではありませんが、ポイントの集合の凸包を得るために、ST_ConvexHull(ST_Collect(somepointfield))のようにST_Collectと併用して使います。この併用は、次のように、観測したポイントの集合をもとに影響を受ける領域を決定するためにしばしば使われます。

SQL-MM 3: 5.1.16

ST_CoordDim

ST_Geometry値の座標次元を返します。

SQL-MM 3: 5.1.3

ST_Crosses

ST_Geometry値が空間的にもうひとつのST_Geometry値とクロスするかを見ます。

SQL-MM 3: 5.1.29

ST_Difference

ふたつのST_Geometry値の差となるポイント集合を示すST_Geometry値を返します。

SQL-MM 3: 5.1.20

ST_Dimension

ST_Geometry値の次元を返します。

SQL-MM 3: 5.1.2

ST_Disjoint

ST_Geometry値の次元を返します。

SQL-MM 3: 5.1.26

ST_Distance

二つのジオメトリの距離を返します。

SQL-MM 3: 5.1.23

ST_EndPoint

ST_Curve値の最後のST_Point値を返します。

SQL-MM 3: 7.1.4

ST_Envelope

ST_Geometryのバウンディング長方形を返します。

SQL-MM 3: 5.1.15

ST_Equals

ST_Geometry値がもうひとつのST_Geometry値と空間的に等価であるかを見ます。

SQL-MM 3: 5.1.24

ST_ExteriorRing

ST_Surfaceの外環を返します。

SQL-MM 3: 8.2.3, 8.3.3

ST_GeometryN

ST_GeomCollectionから指定されたST_Geometry値を返します。

SQL-MM 3: 9.1.5

ST_GeometryType

ST_Geometry値のジオメトリ型を返します。

SQL-MM 3: 5.1.4

ST_GeomFromText

指定したST_Geometry値を返します。

SQL-MM 3: 5.1.40

ST_GeomFromWKB

指定したST_Geometry値を返します。

SQL-MM 3: 5.1.41

ST_InteriorRingN

ST_Surface値の指定した内環を返します。

SQL-MM 3: 8.2.6, 8.3.5

ST_Intersection

二つのST_Geometry値のインタセクトしたポイントの集合を表現するST_Geometry値を返します。

言い換えると、ジオメトリAとジオメトリBとで共有されている部分のことです。

SQL-MM 3: 5.1.18

ST_Intersects

ST_Geometry値がもう一つのST_Geometry値と空間的にインタセクトするかを見ます。

SQL-MM 3: 5.1.27

ST_IsClosed

ST_CurveまたはST_MultiCurve値が閉じているかを見ます。

注記

SQL-MMでは、ST_IsClosed(NULL)の返り値は0になると定義されていますが、PostGISではNULLを返します。

SQL-MM 3: 7.1.5, 9.3.3

ST_IsEmpty

ST_Geometry値が空集合に相当するかを見ます。

注記

SQL-MMでは、ST_IsEmpty(NULL)は0を返しますが、PostGISではNULLを返します。

SQL-MM 3: 5.1.7

ST_IsRing

ST_Curve値が環になっているかを見ます。

注記

SQL-MMでは、ST_IsRing(NULL)の返り値は0になると定義されていますが、PostGISではNULLを返します。

SQL-MM 3: 7.1.6

ST_IsSimple

ST_Geometry値が、自己交差や自己接触をするといった、変則的なポイントを持たないかを見ます。

注記

SQL-MMでは、ST_IsSimple(NULL)は0を返しますが、PostGISではNULLを返します。

SQL-MM 3: 5.1.8

ST_IsValid

ST_Geometry値が整形されているかを見ます。

注記

SQL-MMでは、ST_IsValid(NULL)は0を返しますが、PostGISではNULLを返します。

SQL-MMでは、ST_IsValid(NULL)の返り値は1になると定義されています

SQL-MM 3: 5.1.9

ST_Length

ST_CurveまたはST_MultiCurve値の計測された長さを返します。

SQL-MM 3: 7.1.2, 9.3.4

ST_LineFromText

指定したST_LineString値を返します。

SQL-MM 3: 7.2.8

ST_LineFromWKB

指定したST_LineString値を返します。

SQL-MM 3: 7.2.9

ST_MLineFromText

指定したST_MultiLineString値を返します。

SQL-MM 3: 9.4.4

ST_MLineFromWKB

指定したST_MultiLineString値を返します。

SQL-MM 3: 9.4.5

ST_MPointFromText

指定したST_MultiPoint値を返します。

SQL-MM 3: 9.2.4

ST_MPointFromWKB

指定したST_MultiPoint値を返します。

SQL-MM 3: 9.2.5

ST_MPolyFromText

指定したST_MultiPolygon値を返します。

SQL-MM 3: 9.6.4

ST_MPolyFromWKB

指定したST_MultiPolygon値を返します。

SQL-MM 3: 9.6.5

ST_NumGeometries

指定したST_GeomCollectionを返します。

SQL-MM 3: 9.1.4

ST_NumInteriorRing

ST_Surfaceの内環数を返します。

SQL-MM 3: 8.2.5

ST_NumPoints

ST_LineStringまたはST_CircularStringのポイント数を返します。

SQL-MM 3: 7.2.4

ST_OrderingEquals

二つのジオメトリを比較して、二つのジオメトリが等価で、かつ座標が同じ並び順ならt (TRUE)を返し、そうでないならf (FALSE)を返します。

注記

この関数は、SQL-MM仕様ではなくArcSDE SQL仕様に従って実装しています。http://edndoc.esri.com/arcsde/9.1/sql_api/sqlapi3.htm#ST_OrderingEqualsをご覧ください。

SQL-MM 3: 5.1.43

ST_Overlaps

ST_Geometry値がもうひとつのST_Geometry値に空間的にオーバラップしているかを見ます。

SQL-MM 3: 5.1.32

ST_Perimeter

ST_SurfaceまたはST_MultiSurface値の境界の計測された長さを返します。

SQL-MM 3: 8.1.3, 9.5.4

ST_Point

指定した座標値からST_Pointを返します。

SQL-MM 3: 6.1.2

ST_PointFromText

指定したST_Point値を返します。

SQL-MM 3: 6.1.8

ST_PointFromWKB

指定したST_Point値を返します。

SQL-MM 3: 6.1.9

ST_PointN

ST_LineStringまたはST_CircularStringの中にある、指定したST_Point値を返します。

SQL-MM 3: 7.2.5, 7.3.5

ST_PointOnSurface

ST_SurfaceまたはST_MultiSurface値と空間的に共通領域を持つことを保証されたST_Pointを返します。

SQL-MM 3: 8.1.5, 9.5.6

ST_PolyFromText

指定したST_Polygon値を返します。

SQL-MM 3: 8.3.6

ST_PolyFromWKB

指定したST_Polygon値を返します。

SQL-MM 3: 8.3.7

ST_Polygon

指定したラインストリングとSRIDからST_Polygon値を返します。

SQL-MM 3: 8.3.2

ST_Relate

ST_Geometry値がもうひとつのST_Geomaetry値に空間的に関連があるかを見ます。

SQL-MM 3: 5.1.25

ST_SRID

ST_Geometry値の空間参照系識別子を返します。

SQL-MM 3: 5.1.5

ST_StartPoint

ST_Curve値の最初のポイントをST_Point値で返します。

SQL-MM 3: 7.1.3

ST_SymDifference

二つのST_Geometryの対称差をポイント集合で表現したST_Geometry値を返します。

SQL-MM 3: 5.1.21

ST_Touches

ST_Geometry値がもうひとつのST_Geometry値に空間的に接触しているかを見ます。

SQL-MM 3: 5.1.28

ST_Transform

指定した空間参照系に変換したST_Geometry値を返します。

SQL-MM 3: 5.1.6

ST_Union

二つのST_Geometry値の結合のポイント集合を表すST_Geomety値を返します。

SQL-MM 3: 5.1.19

ST_Within

ST_Geometry値が、空間的にもう一つのST_Geometry値の中にあるかを見ます。

SQL-MM 3: 5.1.30

ST_WKBToSQL

Well-Known Binary表現で与えられたST_Geometry値を返します。

SQL-MM 3: 5.1.36

ST_WKTToSQL

Well-Known Text表現で与えられたST_Geometry値を返します。

SQL-MM 3: 5.1.34

ST_X

ST_Point値のX値を返します。

SQL-MM 3: 6.1.3

ST_Y

ST_Point値のY値を返します。

SQL-MM 3: 6.1.4

6.4. ArcSDE関数

ArcSDEスタイルのインタフェースへの対応を良くするために関数が追加されています。

SE_EnvelopesIntersect

二つのジオメトリのエンベロープが共通部分を持つ場合はt (TRUE)を、そうでない場合はf (FALSE)を返します。

SE_Is3d

ジオメトリ値がZ値を持っているかを見ます。

SE_IsMeasured

ジオメトリ値がM値を持っているかを見ます。

SE_LocateAlong

指定したM値に一致する要素からなる、ジオメトリコレクションから派生した型の値を返します。

SE_LocateBetween

指定したM値の範囲と一致した要素からなる、ジオメトリコレクションから派生した型の値を返します。

SE_M

ST_Point値のM値を返します。

SE_Z

ST_Point値のZ値を返します。

第7章 問題を報告する

7.1. ソフトウェアのバグを報告する

効率的なバグの報告はPostGISの開発を助ける本質的な方法です。最も効率的なバグ報告は、PostGIS開発者がそれを再現できるようにすることで、それの引き金となったスクリプトと検出された環境に沿った全ての情報を含んでいるのが理想です。SELECT postgis_full_version()[PostGIS]とSELECT version()[PostgreSQL]とを実行することで十分に良い情報を得ることができます。

最新版を使っていない場合にはrelease changelogをまず見て、既にバグフィクスされていないかを探すのは価値のあることです。

PostGIS bug trackerを使うと、レポートが捨てられず、それの対応プロセスが通知されることを保証します。新しいバグを報告する前にデータベースに問い合わせて、既知のバグかどうかを見て下さい。既知のものでしたら、それに関して持っているあらゆる新しい情報を追加して下さい。

新しいレポートを記入する前にSimon TathamさんのHow to Report Bugs Effectivelyに関するページを読むと良いでしょう。

7.2. 文書の問題を報告する

文書は、ソフトウェアの機能と挙動を正確に反映するべきものです。正確でない場合は、ソフトウェアのバグがあるか、または文書に誤り若しくは不十分な箇所があることが考えられます。

文書の問題もPostGIS bug trackerに報告することができます。

訂正が小さいものなら、バグトラッカの新しい問題の中に、文書内の位置を特定して記述して下さい。

変更が大きい場合は、Subversion パッチが確実に好まれます。Unix上で次の4ステップの処理を行います (既にSubversionをインストールしていると仮定します)。

  1. PostGISのSubversionトランクをチェックアウトします。Unixでは次のように入力します。

    svn checkout http://svn.refractions.net/postgis/trunk/

    これで./trunkディレクトリに格納されます。

  2. お使いのテキストエディタで文書に変更を加えます。Unixでは、たとえば次のようにします。

    vi trunk/doc/postgis.xml

    文書はHTMLでなくSGMLで書かれていますので、慣れていないなら、残りの文書の例にならって下さい。

  3. 文書のマスタコピーからパッチファイルを作成します。Unixでは次のように入力します。

    svn diff trunk/doc/postgis.xml > doc.patch

  4. バグトラッカ内の新しい問題にパッチが取り付けられます。

付録A 付録

A.1. リリースノート

A.1.1. リリース 1.3.6

リリース日: 2009/05/04

このリリースでは、PostgreSQL 8.4への対応、シェープファイルへの出力時のprjファイル出力とが追加され、曲線タイプに関する小さな誤り訂正がなされています。

A.1.2. リリース 1.3.5

リリース日: 2008/12/15

このリリースでは、shp2gpsqlの誤り訂正、SVGとKMLへの対応の強化、ST_SimplifyPreserveTopology関数の追加、GEOSの版に注意を払ったビルド、厳格かつ稀な失敗ケースの訂正が行われました。

A.1.3. リリース 1.3.4

リリース日: 2008/11/24

このリリースでは、GeoJSON出力とPostgreSQL 8.4でのビルドへの対応、文書品質と出力の美しさの改善、関数レベルのSQL文書を追加し、空間述語の性能改善 (ポリゴン内のポイントのテスト)が行われました。

誤り訂正として、多数の関数で曲線ラインストリングの処理で異常終了する問題、メモリリーク、線形参照が頂点上での計測で失敗する問題等の排除が挙げられます。詳細についてはNEWSファイルをご覧下さい。

A.1.4. リリース 1.3.3

リリース日: 2008/04/12

このリリースでは、shp2gpsqlの誤り訂正、SVGとKMLへの対応の強化、ST_SimplifyPreserveTopology関数の追加、GEOSの版に注意を払ったビルド、厳格かつ稀な失敗ケースの訂正が行われました。

A.1.5. リリース 1.3.2

リリース日: 2007/12/01

このリリースでは、ST_EndPoint()とST_Envelope()の誤り訂正、JDBCビルドとOS/Xへの対応の改善、GML3出力を含むST_AsGML()でのGML出力の対応の改善が行われました。

A.1.6. リリース 1.3.1

リリース日: 2007/08/13

このリリースでは、以前のリリースでの見落としていた、版番号、文書、タグ等に関する問題の訂正が行われました。

A.1.7. リリース 1.3.0

リリース日: 2007/08/09

このリリースでは、空間関係関数の性能改善、新しい空間関係関数の追加、関数名のSQL-MMへの変換 (空間型 (Spatial Type)前置辞 (SP)を使います)が行われました。

A.1.7.1. 機能追加

JDBC: Hibernate Dialectの追加 (Norman Barkerさんに感謝)

空間関係関数ST_CoversとST_CoveredByの追加。こららの関数の説明と根拠はhttp://lin-ear-th-inking.blogspot.com/2007/06/subtleties-of-ogc-covers-spatial.htmlにあります。

空間関係関数ST_DWithinの追加。

A.1.7.2. 性能強化

ST_Contains, ST_Intersects, ST_WithinとST_Disjoint用のキャッシュとインデックスを用いたポリゴン内ポイントの簡略版の追加。

空間関係関数のインラインインデックス対応の追加 (ST_Disjointを除く)

A.1.7.3. 他の変更

ジオメトリアクセサと処理関数における曲線ジオメトリ対応の拡張

空間型 (ST)前置辞を使用するSQL-MM命名規則への移動の開始。

PostgreSQL 8.3への最初の対応

A.1.8. リリース 1.2.1

リリース日: 2007/01/11

このリリースでは、PostgreSQL 8.2対応の誤り訂正と若干の性能改善が行われています。

A.1.8.1. 変更

Within()のポリゴン内ポイントの短縮動作の訂正。

PostgreSQL 8.2のインデックスに対するNULL処理の訂正。

RPM specファイルの更新。

Transform()で処理を行わなくて良い場合の短縮版を追加。

JDBC: 多次元ジオメトリに対するJTS処理の訂正 (Thomas Martiさんのヒントと部分的なパッチに感謝)。さらに、Javadocがコンパイルされ同梱されるようになりました。GCJ使用時のCLASSPATH問題が訂正されました。pgjdbc 8.2互換性への対応の訂正、JDK 1.3以前の対応欠落の訂正が行われました。

A.1.9. リリース 1.2.0

リリース日: 2006/12/08

このリリースでは、SQL-MM定義の曲線ジオメトリのシリアライズ/デシリアライズ能力に沿ったタイプ定義と、性能改善が行われました。

A.1.9.1. 変更

シリアライズ/デシリアライズの曲線ジオメトリタイプへの対応を追加

性能改善のためにContains()とWithin()にポリゴン内ポイントの短縮版を追加してました。

A.1.10. リリース 1.1.6

リリース日: 2006/11/02

これは誤り訂正のリリースです。特に64ビット機におけるGEOSインタフェースの重大なエラーを訂正しています。SRSパラメータの更新と投影変換の改善 (Z軸を取る)が行われました。アップグレードが必要です

A.1.10.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.10.2. 誤り訂正

64ビット機で壊れていたCAPIの訂正

ローダ/ダンパ: 回帰テストと使用法出力の訂正

JDBCにおけるsetSRID()の誤り訂正。Thomas Martiさんに感謝。

A.1.10.3. Other changes

投影変換でのZ軸の使用

spatial_ref_sys.sqlをEPSG 6.11.1に更新

全体のためのバージョン変数を単一で使うためVersion.config基盤を単純化

ローダ/ダンパの使用法メッセージにVersion.configを含むようにしました

手作りで脆いJDBCのバージョンパーサをPropertiesに置き換え

A.1.11. リリース 1.1.5

リリース日: 2006/10/13

誤り訂正版です。Win32での重大なセグメンテーション違反を含みます。アップグレードは推奨されます

A.1.11.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.11.2. 誤り訂正

PostgreSQL 8.2用でコンパイルした際に発生する、Win32上のpgsql2shpでセグメンテーション違反を引き起こすMingWのリンクの誤りの訂正

JavaのGeometry.equals()メソッドでNULLポインタ例外が発生する問題を訂正

GPL要求「変更の好まれる形式」の配布を満たすようEJB3Spatial.odtを追加

JDBC JTSコードから用いられていない同期を削除。

shp2pgsql/pgsql2shpのREADMEファイルが非常に古くなっていたのを、マニュアルページにマージして更新。

JDBCの版のタグが"1.1.4"なのに"1.1.3"になっていた問題を訂正。

A.1.11.3. 新機能

非マルチ系ジオメトリのための-Sオプションをshp2pgsqlに追加

A.1.12. リリース 1.1.4

リリース日: 2006/09/27

Javaインタフェースでのいくつかの改善を含む誤り訂正版です。アップグレードは推奨されます

A.1.12.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.12.2. 誤り訂正

PostgreSQL 8.2対応で訂正

collect()関数の入力のSRIDを捨てる問題を訂正

MakeBox2dとMakeBox3dでSRID合致確認を追加

GEOS 3.0.0が通るよう回帰テストの訂正

pgsql2shp同時実行の改善。

A.1.12.3. Javaの変更

SRID処理への新しいJTS開発者の姿勢を反映したJTS対応の再作業。コードの単純化とGNU Trove依存のビルドの削除。

"Geodetix s.r.l. Company"からの寄付によるEJB2対応の追加

Norman Barker <nbarker@ittvis.com>さんの寄付によるEJB3チュートリアル/例の追加

Javaディレクトリ編成の若干の再編

A.1.13. リリース 1.1.3

リリース日: 2006/06/30

誤り訂正リリースです。新しい関数 (特にロングトランザクション対応)とポータビリティ強化を含みます。アップグレードは推奨されます

A.1.13.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.13.2. 誤り訂正/修正

distance(ポリゴン, ポリゴン)で誤った結果となる誤り訂正

pgsql2shpの成功時の終了ステータスの誤り訂正。

shp2gpsqlにおけるマルチラインWKTの処理の誤り訂正

affine()でバウンディングボックス更新がある場合に失敗する誤り訂正

WKTパーサ: EMPTY要素を持つマルチ系ジオメトリの構築の禁止(GEOMETRYCOLLECTIONは対応)。

A.1.13.3. 新機能

ロングトランザクション対応の新規追加。

DumpRings()関数の新規追加。

AsHEXEWKB(geom, XDR|NDR)関数の新規追加。

A.1.13.4. JDBC変更

回帰テストの改善: マルチポイントとXY以外の座標値

JDBCコードの小規模な訂正

全てのフィールドを今後非公開にする準備として適切なアクセサ関数の追加。

A.1.13.5. Other changes

ローダ/ダンパに対応する新しい回帰テスト。

コンフィギュアスイッチ--with-proj-libdirと--with-geos-libdirの追加

Tru64のビルドへの対応。

文書生成のためにJadeを使用。

pgsql2shpを求める以上のライブラリにリンクしないようにしました。

PostgreSQL 8.2への最初の対応。

A.1.14. リリース 1.1.2

リリース日: 2006/03/30

誤り訂正リリースで、新しい関数とポータビリティ強化を含みます。アップグレードは推奨されます

A.1.14.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.14.2. 誤り訂正

SnapToGrid()内の出力バウンディングボックスの計算の誤り訂正

EnforceRHR()の誤り訂正

JDBC2のJTSコード内のSRID処理の訂正

64ビット対応の訂正

A.1.14.3. 新機能

回帰試験をPostGISのインストール*前に*実行できるようになりました

新しいafiine()行列変形関数

新しいrotate{,X,Y,Z}()関数

古い翻訳とaffine()を内部で使用している拡大縮小関数

pgsql 8.0.0以上に対するビルドで、estimated_extent()内にアクセス制御を埋め込みました

A.1.14.4. Other changes

./configureスクリプトをよりポータブルにしました

./run_testスクリプトを、デフォルトの振る舞いがより健全になるよう変更しました。

A.1.15. リリース 1.1.1

リリース日: 2006/01/23

重要な誤り訂正リリースです。アップグレードを強くお勧めします。前の版では、postgis_restore.plにハードアップグレードを阻害する誤りがあります。また、GEOS 2.2以上のコネクタで、ジオメトリコレクションのオブジェクトがトポロジ演算子で使われるのを阻害される誤りがあります。

A.1.15.1. アップグレード

1.0.3以上からアップグレードする場合には、soft upgradeの手続きを行います。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.15.2. 誤り訂正

postgis_restore.plで早すぎるexitがある誤り訂正

GEOS-CAPIコネクタのジオメトリコレクションの処理に関する誤り訂正

Solaris 2.7とMingWへの対応を改善

line_locate_point()の誤り訂正

PostgreSQLのパスの処理を訂正

line_substring()の誤り訂正

回帰テストで局所化されたクラスタへの対応を追加

A.1.15.3. 新機能

line_substring()でZ値とM値の補間を新規追加

line_interpolate_point()でZ値とM値の補間を新規追加

OpenGISのあいまいさのためNumInteriorRing()の別名を追加

A.1.16. リリース 1.1.0

リリース日: 2005/12/21

多数の改善と新規追加が行われたマイナーリリースです。最も注意して頂きたいのは、ビルド手続きが非常に単純化したこと、transform()の速度が大幅に改善したこと、GEOSとの接続の安定化 (CAPI対応)、多数の新規関数、トポロジ対応の草案、です。

PostGISをインストールする前にGEOS-2.2.xにアップグレードすることを強くお勧めします。これによって、将来のGEOSのアップグレードでPostGISライブラリの再構築が必要になることが無くなることが保証されます。

A.1.16.1. 貢献者

このリリースには、Mark Cave Aylandさんからのproj4オブジェクトのキャッシュ機能のコードが含まれています。Markus Schaberさんは、JDBC2コードの多数の改善点を追加しました。Alex Bodnaruさんは、PostgreSQLソース依存の除去を助け、Debianのspecファイルを提供しました。Michael Fuhrさんは、Solarisアーキテクチャの新しい点をテストしました。David TecherさんとGerald Fenoyさんは、GEOS C言語APIコネクタの試験を助けました。Hartmut Tschaunerは、azimuth()関数のコードを提供しました。Devrim GUNDUZさんは、RPMのspecファイルを提供しました。Carl Andersonさんは、新しい面構築関数の作成を助けました。より多くの貢献者情報についてはcreditsをご覧下さい。

A.1.16.2. アップグレード

1.0.3以降から更新する場合には、ダンプ/リロードは不要です。全ての存在するデータベースで、新しいlwpostgis_upgrade.sqlスクリプトが単純に取り込まれます。詳細情報についてはソフトアップグレードの章をご覧下さい。

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.16.3. 新しい関数

translate()が使用する関数scale()とtransscale()

line_substring()

line_locate_point()

M(point)

LineMerge(geometry)

shift_longitude(geometry)

azimuth(geometry)

locate_along_measure(geometry, float8)

locate_between_measures(geometry, float8, float8)

ポイントによるオフセットを行うSnapToGrid (4次元まで対応)

BuildArea(any_geometry)

OGC BdPolyFromText(linestring_wkt, srid)

OGC BdMPolyFromText(linestring_wkt, srid)

RemovePoint(linestring, offset)

ReplacePoint(linestring, offset, point)

A.1.16.4. 誤り訂正

polygonize()のメモリリークの誤り訂正

キャスト関数lwgeom_as_anytypeの誤り訂正

psotgis_version()の出力のUSE_GEOS, USE_PROJ , USE_STATS要素を常にライブラリの状態に合わせるよう誤り訂正

A.1.16.5. 関数の内容の変更

SnapToGridにおける高次元値を破棄しなくなりました

Z()関数を、Z値を持たない場合にNULLを返すよう変更

A.1.16.6. 速度改善

transform()関数の大幅な高速化、proj4オブジェクトのキャッシュ機能

AddGeometryColumns()とupdate_geometry_stats()からのfix_geometry_columns()の自動呼出しの削除

A.1.16.7. JDBC2での作業

Mkaefileの改善

JTS対応の改善

回帰テストシステムの改善

ジオメトリコレクションの基本的な整合性検査メソッド

(HEX)(E)wkbへの対応

HexWKB / EWKT の切り替えのための自動検出機能DriverWrapper

古いJDKリリースのValueSetterで発生するコンパイルの誤り訂正。

EWKTコンストラクタを"SRID=4711;"といった表現を受け取れるよう誤り訂正

予備的な読み込み専用のJava2Dのジオメトリへの対応

A.1.16.8. 他の新しいこと

PostgreSQLソース依存を除去した完全なautoconfを用いたコンフィギュレーション

GEOS C-API対応 (2.2.0以上)

トポロジモデリングの最初の対応

DebianとRPMのspecファイル

lwpostgis_upgrade.sqlスクリプトの追加

A.1.16.9. Other changes

JTS対応の改善

DBFとSQLの間における整数と文字列の属性の対応付けの厳格化

回帰テスト群の範囲拡大と見やすさ改善

古いjdbcコードはこの版で削除

postgis_proc_upgrade.plの直接の使用を廃止

スクリプトの版とリリースの版とを合わせました

A.1.17. リリース 1.0.6

リリース日: 2005/12/06

若干の誤り訂正と改善があります

A.1.17.1. アップグレード

1.0.3以降から更新する場合には、ダンプ/リロードは不要です

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.17.2. 誤り訂正

コレクションのデシリアライザでpalloc(0)を呼ぶ誤り訂正 (--enable-cassertがある場合のみ)

バウンディングボックスキャッシュ処理の誤り訂正

geom_accum(NULL, NULL)のセグメンテーション違反の誤り訂正

addPoint()のセグメンテーション違反の誤り訂正

lwcollection_clone()の短時間メモリ確保の訂正

segmentize()の誤り訂正

SnapToGrid出力の固定バウンディングボックスの計算

A.1.17.3. 改善

PostgreSQL 8.2への最初の対応

GEOSオプションでSRID整合性検査が無かったのを追加

A.1.18. リリース 1.0.5

リリース日: 2005/11/25

ライブラリにおけるメモリのアラインメントの訂正、ローダのUTF8属性値の処理におけるセグメンテーション違反の訂正、若干の改善と整理を行っています。

注記

shp2pgsqlのコードを以前の版からUNIX標準に適合する (成功時に0を返す)ように変更

A.1.18.1. アップグレード

1.0.3以降から更新する場合には、ダンプ/リロードは不要です

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.18.2. ライブラリの変更

メモリのアラインメントの訂正

アナライザにおける少量のNULL値の計算の訂正

低水準関数getPoint4d_p()の小さな誤り訂正。

シリアライズ関数の速度向上

force_3dm(), force_3dz() およびorce_4d()における誤り訂正

A.1.18.3. ローダの変更

shp2pgsqlの終了ステータスに関する誤り訂正

ローダの後方互換に関する誤りを訂正 (NULLシェープファイルのロード)

DBFの数値の属性値について最後にドットが付く場合の処理の誤りを訂正

shp2pgsql (utf8エンコーディング)でのセグメンテーション違反が出る誤りを訂正

A.1.18.4. Other changes

スキーマ対応のpostgis_proc_upgrade.pl、PostgreSQL 7.2以上に対応

マニュアルに「問題を報告する 」の章を追加

A.1.19. リリース 1.0.4

リリース日: 2005/09/09

重大な誤り訂正と若干の改善があります。特に、大きな地理空間テーブルでのGiSTインデックスの構築で起こるメモリリークを訂正しています。

A.1.19.1. アップグレード

1.0.3から更新する場合には、ダンプ/リロードは不要です

1.0.0RC6から1.0.2までのリリースからアップグレードする場合には、リリース 1.0.3にあるアップグレードをご覧ください。

1.0.0RC6より前のリリースからのアップグレードは、ハードアップグレードが必要です。

A.1.19.2. 誤り訂正

GiSTインデックスのメモリリーク

proj4のtransform()処理でのセグメンテーション違反の誤り訂正

spatial_ref_sysのproj4の誤り訂正 (+projが無かった)

ローダ: 文字列関数の使用の訂正、NULLオブジェクトチェックの改定、MULTILINESTRING入力でのセグメンテーション違反になる誤りの訂正。

MakeLineの次元処理に関する誤り訂正

translate()で出力バウンディングボックスが壊れることに関する誤り訂正

A.1.19.3. 改善

文書の改善

選択度推測器の堅牢性向上

distance()の少しの速度向上

小規模な整理

GiSTインデックスの整理

BOX3Dパーサでより緩い構文を受け付けるようにしました

A.1.20. リリース 1.0.3

リリース日: 2005/08/08

いくつかの誤り訂正 - 格納されているジオメトリの正しさに厳しい影響を与えるものを含みます - および若干の改善。

A.1.20.1. アップグレード

バウンディングボックスの計算ルーティンの誤りのため、データベースにキャッシュされているバウンディングボックスが正しくない可能性があり、アップグレード手続きでは特別な注意が必要となりました。

ハードアップグレード手続き (ダンプ/リロード)によって、全てのバウンディングボックス (ダンプ内にない)の再計算が強制的に行われます。これは、1.0.0RC6より前のリリースからのアップグレードには必要です

1.0.0RC6以上からアップグレードする場合には、このリリースには、ジオメトリのバウンディングボックスの再計算と、その結果として発生する変更を伝播させる全ての処理を強制するPerlスクリプト(utils/rebuild_bbox_caches.pl)を持っています。インストール後にこのスクリプトを実行します (引数無しで走らせるとヘルプが出ます)。もしくは、utils/postgis_proc_upgrade.pを実行して、PostGISのプロシージャと関数を更新します (ソフトアップグレードを参照して下さい)。

A.1.20.2. 誤り訂正

lwgeomの2次元バンディングボックス計算の厳しい誤り訂正

ローダのWKT (-w)ポイント処理の誤り訂正

64ビット機のダンパの誤り訂正

ユーザ定義クエリの処理を行うダンパの誤り訂正

create_undef.plスクリプトの誤り訂正

A.1.20.3. 改善

カノニカル入力関数の少しの能率改善

ローダの小規模な整理

ローダの多バイト文字によるフィールド名への対応

postgis_restore.plスクリプトの改善

ユーティリティスクリプトrebuild_bbox_caches.plの再構築

A.1.21. リリース 1.0.2

リリース日: 2005/07/04

若干の誤り訂正と改善があります

A.1.21.1. アップグレード

1.0.0RC6から更新する場合には、ダンプ/リロードは不要です

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.21.2. 誤り訂正

B木オプションの誤り許容

pg_errorでのメモリリーク

R木インデックスの訂正

ビルドスクリプトの整理 (CFLAGSとCXXFLAGSの混在の回避)

A.1.21.3. 改善

ローダにおける新しいインデックス生成機能 (-lスイッチ)

PostgreSQL 8.1devへの最初の対応

A.1.22. リリース 1.0.1

リリース日: 2005/05/24

若干の誤り訂正といくつかの改善があります。

A.1.22.1. アップグレード

1.0.0RC6から更新する場合には、ダンプ/リロードは不要です

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.22.2. ライブラリの変更

length_spheroid()の3次元計算の誤り訂正

JOIN選択推定器の誤り訂正

A.1.22.3. 他の変更追加

shp2pgsqlのエスケープ関数の誤り訂正

複数スキーマで同時発生するPostGISに対するより良い対応

文書の訂正

jdbc2: コンパイル時に"-target 1.2 -source 1.2"をデフォルトとするよう変更

pgsql2shpの-kスイッチの追加

postgis_restore.plの独自のcreatedへの対応

pgsql2shp属性名の一意性強制の誤り訂正

NTF (Paris)の投影定義の誤り訂正

postgis_restore.plの整理

A.1.23. リリース 1.0.0

リリース日: 2005/04/19

最後の1.0.0リリースです。若干の誤り訂正、ローダのいくつかの改良 (古いPostGISへの対応が特筆すべき点)、文書の追加がありました。

A.1.23.1. アップグレード

1.0.0RC6から更新する場合には、ダンプ/リロードは不要です

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.23.2. ライブラリの変更

transform()が不規則なメモリアドレスを解放する問題を訂正

force_3dm()のメモリ確保が必要より小さい問題を訂正

JOIN選択度見積もりの誤り (デフォルト値、メモリリーク、行カウント、SD)訂正

A.1.23.3. 他の変更追加

shp2pgsqlがタブまたはシングルクォートで始まる値を読み飛ばす誤りを訂正

マニュアルへのローダ/ダンパの追加

古い (HWGEOM)PostGISに対応するshp2gsql

shp2pgsqlのフラグに -p (prepare)を追加

マニュアルにOGC互換の強制に関する新章追加

JTSライブラリに対応する新しいautoconf

推測器のテストの誤り訂正 (LWGEOMとスキーマの構文解析への対応)

A.1.24. リリース 1.0.0RC6

リリース日: 2005/03/30

1.0.0の6番目のリリース候補、若干の誤り訂正と整理を行っています。

A.1.24.1. アップグレード

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.24.2. ライブラリの変更

multi()の誤り訂正

noop時にmulti()からの早い復帰

A.1.24.3. スクリプトの変更

{x,y}{min,max}(box2d)関数の削除

A.1.24.4. Other changes

postgis_restore.plスクリプトの誤り訂正

64ビット対応のダンパの誤り訂正

A.1.25. リリース 1.0.0RC5

リリース日: 2005/03/25

1.0.0の5番目のリリース候補、若干の誤り訂正と改善があります

A.1.25.1. アップグレード

1.0.0RC4から更新する場合には、ダンプ/リロードは不要です

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.25.2. ライブラリの変更

box3d計算の問題 (セグメンテーションフォールト)の訂正 (ほかにもあります)

estimated_extent()でのセグメンテーションフォールトの訂正

A.1.25.3. Other changes

ビルドスクリプトとユーティリティの若干の改良

性能向上に関する技法の文章の追加

A.1.26. リリース 1.0.0RC4

リリース日: 2005/03/18

1.0.0の4番目のリリース候補、誤り訂正と若干の改善があります

A.1.26.1. アップグレード

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.26.2. ライブラリの変更

geom_accum()のセグメンテーションフォールトの誤り訂正

64ビットアーキテクチャ対応の誤り訂正

コレクションを引数に取るbox3d計算関数の誤りの訂正

副問い合わせの選択度推定への対応

force_collectionからの早い復帰

SnapToGrid()の一貫性検査の訂正

Box2d出力精度を15桁に後退

A.1.26.3. スクリプトの変更

distance_sphere()の追加

get_proj4_from_sridの実装をSQLからPL/pgSQLに変更

A.1.26.4. Other changes

ローダとダンパのMULTOLINEシェープの処理の問題を訂正

ローダでポリゴンの最初の穴を読み飛ばす誤りを訂正

jdbc2: コードの整理、Makefileの改善

FLEX変数とYACC変数がpgsqlのMakefile.globalが取り込まれた*後*で、pgsqlの*空白を除いた*ものが空文字列と評価された場合に限って設定される

既に作成されていたパーサの追加

ビルドスクリプトの改良

Version.configの改善を中心とした版処理の改善

postgis_restore.plの改善

A.1.27. リリース 1.0.0RC3

リリース日: 2005/02/24

1.0.0の3番目のリリース候補、多数の誤り訂正と改善があります。

A.1.27.1. アップグレード

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.27.2. ライブラリの変更

transform()でSRIDが消える問題を訂正、エラー処理を改善。

メモリアラインメントのハンドリングに関する誤り訂正

force_collection()で単純な (単一)ジオメトリ型でMapServerの接続が切れる問題を訂正。

GeometryFromText()でbboxキャッシュを追加しない誤り訂正。

box2d出力の精度低下。

pgsqlで異常終了する問題を避けるため、DEBUGマクロにPGIS_の前置辞を付加

GEOS2POSTGISコンバータのリークを訂正

pallocで確保したクエリコンテキストのメモリを早く開放することによるメモリ使用の削減

A.1.27.3. スクリプトの変更

PostgreSQL 7.2のインデックスのバインディングを訂正しました。

PG72での動作と、1テーブルに複数カラムの場合への対応のため、probe_geometry_columns()の誤り訂正

boolからtextへのキャストの更新

動作効率改善のため、いくつかの関数をSTABLEからIMMUTABLEに変更

A.1.27.4. JDBC変更

jdbc2: 小さなパッチ、box2d/box3dの試験、文書とライセンスの改定

jdbc2: pgjdbc 8.0の型の自動登録の誤り訂正とテストケース作成

jdbc2: 古いjdkリリースでの構築を有効にするためためにjdk1.4使用箇所の削除

jdbc2: pg72jdbc2.jarに対するビルドへの対応の追加

jdbc2: Makefileの更新と無駄の除去

jdbc2: JTSジオメトリクラス対応のベータ版を追加

jdbc2: 古いPostGISサーバに対して失敗するのが判明しているテストをスキップするようにしました。

jdbc2: EWKTのM値を持つジオメトリの処理の訂正

A.1.27.5. Other changes

性能向上に関する技法の新章追加

ドキュメント更新: pgsql72に必要なもの、lwpostgis.sql

autoconfの若干の変更

BUILDDATE抽出の移植可能範囲を広げました

spatial_ref_sys.sqlを訂正してvacuumが全体のデータベースに及ぶのを避けるようにしました。

spatial_ref_sys: NTF (Paris)を0.xで配布していたものに合うよう変更。

A.1.28. リリース 1.0.0RC2

リリース日: 2005/01/26

1.0.0の第2リリース候補版。誤り訂正と若干の改善。

A.1.28.1. アップグレード

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.28.2. ライブラリの変更

ポイント配列からのbox3d計算に関する誤り訂正

distance_spheroid定義に関する誤り訂正

bboxキャッシュ更新がtransform()無かったことに関する誤り訂正

新しいJDBCドライバ (jdbc2)

後方互換のためのGEOMETRYCOLLECTION(EMPTY)書式への対応

バイナリ出力の高速化

OGC WKB/WKTコンストラクタの厳格化

A.1.28.3. スクリプトの変更

lwpostgis.sql内でのSTABLE, IMMUTABLE, STRICTの訂正

OGC WKB/WKTコンストラクタの厳格化

A.1.28.4. Other changes

ローダ (i18n、非i18nの両方)の高速化と堅牢化

最初のautoconfスクリプト

A.1.29. リリース 1.0.0RC1

リリース日: 2005/01/13

最初のPostGISメジャーリリース候補版。格納領域の低減とインデックス使用クエリの高速化のためのPostGIS型の内部格納の再設計。

A.1.29.1. アップグレード

前のリリースからアップグレードするにはダンプ/リロードが必要です。詳細についてはアップグレードをご覧下さい。

A.1.29.2. 変更

標準形式入力パースの高速化。

標準形式出力の可逆化。

PostgreSQL 7.3以上でのEWKBの標準形式バイナリ入出力対応。

4次元座標以上の対応、可逆shapefile->postgis->shapefile変換。

新関数: UpdateGeometrySRID(), AsGML(), SnapToGrid(), ForceRHR(), estimated_extent(), accum().

垂直方向位置インデックス演算子。

JOIN選択関数。

ジオメトリコンストラクタとエディタの強化。

PostGISエクステンションAPI。

ローダのUTF-8対応。