PostGISは、オブジェクトRDBであるPostgreSQLの拡張で、GIS (地理情報システム)オブジェクトを格納することができます。PostGISは、GiSTベースのR木空間インデクスをサポートし、GISオブジェクトの解析および処理を行う機能を持ちます。
本マニュアルは、3.0.0版のマニュアルです。
この作品はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。好きなようにこの材料を使うことができますが、PostGIS Project のクレジット提示を求めます。また可能な限りhttp://postgis.netへのリンクを求めます。
PostGISは、PostgreSQLリレーショナルデータベースに空間拡張を施すものです。Refractions Research Incが、空間データベース技術の研究プロジェクトとして開発しました。Refractionsはカナダ・ブリティッシュコロンビア州・ビクトリアにある、データインテグレーションとカスタムソフトウェア開発に特化した、GISとデータベースのコンサルティング会社です。
PostGISはOSGeo財団のプロジェクトです。PostGISは、多数のFOSS4G開発者と、PostGISの機能と多彩さから大きな利益を得る世界中の企業によって継続的に改善され、資金を得ています。
PostGISプロジェクトの開発グループは、PostGISが、OpenGISとSQL/MM空間標準の領域における重要なGIS機能、高度なトポロジ構築 (カバレッジ、サーフェス、ネットワーク)、GISデータの表示と編集を行うデスクトップユーザインタフェースツール、およびウェブベースのアクセスツールのためのデータソースに、より良く対応するよう、サポートと機能強化を行う予定です。
PostGISプロジェクト運営委員会 (PostGIS Project Steering Committee, PSC)は、総合的な指示、リリースサイクル、ドキュメンテーション、支援活動に関する調整を行っています。また、委員会は、全体的なユーザサポート、PostGISコミュニティからのパッチの受け付けと適用、 開発者のコミットのアクセス、新しい委員、APIの重要な変更といった、PostGISを含む雑多な問題に関する投票を行っています。
Buildbotのメンテナンス、Windows版と試験版のビルド、ドキュメンテーション、PostgreSQLとの調整、PostGISニュースグループの一般的なユーザサポート、X3D対応、Tiger Geocoder機能、関数管理、新機能と大きなコード変更のスモークテスト。
ラスタ開発、GDALとの統合、ラスタローダ、ユーザサポート、一般的なバグフィクス、様々なOS (Slackware, Mac, Windows他)での試験。
PostGISプロジェクトの副創始者。総合的なバグフィクス、ジオグラフィ機能、ジオグラフィとジオメトリのインデクス機能 (2次元,、3次元、n次元インデクスとあらゆる空間インデクス)、ジオメトリ内部構造、PointCloud (開発中)、GEOS機能の統合とGEOSリリースとの調整、PostgreSQLのリリースとの調整、ローダ/ダンパ、シェープファイルGUIローダ。
誤り修正とメンテナンス、gitミラーの管理、新しいGEOS機能のメンテナンス、GEOSリリースとの調整、トポロジ機能、ラスタフレームワークと低水準API関数。
ラスタ開発、GDALドライバ機能、ローダ。
距離関数の強化 (3次元距離、関係関数を含む)と追加、Tiny WKB出力書式(TWKB, 開発中)と一般的なユーザサポート。
ジオメトリクラスタリング関数の追加、他のジオメトリアルゴリズムの強化、GEOSの強化、および全体のユーザ対応
XML (KML, GML)/GeoJSON入出力関数と3次元サポートとバグフィクス。
GEOS enhancements and documentation
MapBox Vector Tile関数とGeoBuf関数、Gogsの試験とGitLabの実験。
PostGISのCMakeサポート。オリジナルのPython版ラスタローダ低水準ラスタAPI関数の以前の開発。
誤り修正
インデクス改善、誤り修正とジオメトリ/ジオグラフィ関数の改善、GitHub担当、Travis Botのメンテナンス。
ラスタ全体のアーキテクチャ、プロトタイピング、プログラミング支援。
誤り修正とメンテナンスの調整、空間インデクスの選択とバインディング、ローダ/ダンパ、シェープファイルGUIローダ、新機能の統合と強化。
以前のPSCメンバ。一般的な開発、サイトとBuildbotのメンテナンス、OSGeoインキュベーション管理。
以前のPSCメンバ。文書と文書補助ツール、Buildbotのメンテナンス、PostGISニュースグループでの高度なユーザサポート、PostGISメンテナンス機能の強化。
PostGISのオリジナルの開発/副創始者。サーバサイドのオブジェクト、インデクスのバインディングや多数のサーバサイドの解析機能を記述。
シェープファイルのローダ/ダンパのオリジナルの開発者。現在のPostGISプロジェクトオーナーの代表。
中核機能の、継続的なメンテナンスと開発。曲線機能の強化。シェープファイルGUIローダ。
ラスタ開発 (ほとんど地図代数解析関数)。
Alex Bodnaru | Gerald Fenoy | Maxime Guillaud |
Alex Mayrhofer | Gino Lucrezi | Maxime van Noppen |
Andrea Peri | Greg Troxel | Michael Fuhr |
Andreas Forř Tollefsen | Guillaume Lelarge | Mike Toews |
Andreas Neumann | Haribabu Kommi | Nathan Wagner |
Anne Ghisla | Havard Tveite | Nathaniel Clay |
Antoine Bajolet | IIDA Tetsushi | Nikita Shulga |
Artur Zakirov | Ingvild Nystuen | Norman Vine |
Barbara Phillipot | Jackie Leng | Patricia Tozer |
Ben Jubb | James Marca | Rafal Magda |
Bernhard Reiter | Jason Smith | Ralph Mason |
Björn Esser | Jeff Adams | Rémi Cura |
Brian Hamlin | Jonne Savolainen | Richard Greenwood |
Bruce Rindahl | Jose Carlos Martinez Llari | Roger Crew |
Bruno Wolff III | Jörg Habenicht | Ron Mayer |
Bryce L. Nordgren | Julien Rouhaud | Sebastiaan Couwenberg |
Carl Anderson | Kashif Rasul | Sergey Fedoseev |
Charlie Savage | Klaus Foerster | Shinichi Sugiyama |
Christoph Berg | Kris Jurka | Shoaib Burq |
Christoph Moench-Tegeder | Laurenz Albe | Silvio Grosso |
Dane Springmeyer | Lars Roessiger | Steffen Macke |
Dave Fuhry | Leo Hsu | Stepan Kuzmin |
David Zwarg | Loic Dachary | Stephen Frost |
David Zwarg | Luca S. Percich | Talha Rizwan |
David Zwarg | Maria Arias de Reyna | Tom Glancy |
Dmitry Vasilyev | Marc Ducobu | Tom van Tilburg |
Eduin Carrillo | Mark Sondheim | Vincent Mora |
Eugene Antimirov | Markus Schaber | Vincent Picavet |
Even Rouault | Markus Wanner | Volf Tomáš |
Frank Warmerdam | Matt Amos | |
George Silva | Matthias Bay |
PostGISプロジェクトへの開発時間、ホスティング、直接的な金銭提供の貢献を行った企業です。
クラウドファンディングキャンペーンは、PostGIS開発チームが走らせているキャンペーンです。欲しくて仕方ない機能に資金を与えて、多数の人々にサービスを提供できるようにするためのものです。それぞれのキャンペーンでは、特定の機能または機能の集合に焦点があてられます。それぞれのスポンサーは、必要な資金提供のうち少しだけを提供し、十分な人/組織の寄付で、たくさんの助けになる作業に支払う基金を持ちます。他の多くの人が寄付に協力してくれそうな機能に関するアイデアがありましたら、PostGIS newsgroupに、その考えを投稿して下さい。一緒に実現できます。
PostGIS 2.0.0はこの戦略を実施する最初のリリースです。PledgeBankを使い、2件のキャンペーンが成功しました。
postgistopology - 10以上のスポンサーがTopoGeometry機能の構築と2.0.0でのトポロジ対応強化とのために、それぞれ250米ドルを寄付しました。
postgis64windows - 20のスポンサーが, Windows上でのPostGIS 64ビット版に必要な作業のために、それぞれ100米ドルを寄付しました。64ビット用PostGIS 2.0.1ができ、PostgreSQLスタックビルダで使用可能なリリースを予定している最終版ができました。
The GEOS geometry operations library
地理空間データ抽出ライブラリGDALはFrank Warmerdamらによります。PostGIS 2.0.0で導入されたラスタ機能で、非常によく使われています。 同じように、PostGISサポートに関するGDALの必要な改善でGDALプロジェクトに貢献しています。
The PROJ cartographic projection library
最後ですがおろそかにできないのがPostgreSQL DBMSです。PostGISはこの巨人の肩に乗っています。PostGISの速度と柔軟性はPostgreSQLが提供する拡張性、偉大なクエリプランナ、GiSTインデクス、多数のSQL機能がないと成り立ちません。
本章では、PostGISのインストールに必要な手順について説明します。
全ての依存がパスに入っているとする場合、次のようにコンパイルします。
tar xvfz postgis-3.0.0.tar.gz cd postgis-3.0.0 ./configure make make install
PostGISをインストールした後は、利用したいデータベース個々内で利用可能にする必要があります。
![]() | |
Using the extension enable process is preferred and more user-friendly. To spatially enable your database: |
psql -d yourdatabase -c "CREATE EXTENSION postgis;" psql -d yourdatabase -c "CREATE EXTENSION postgis_topology;" -- SFCGAL対応でビルドした場合は次を実行 -- psql -d yourdatabase -c "CREATE EXTENSION postgis_sfcgal;" -- Tigerジオコーダをインストールしたい場合は次の二つを実行 -- psql -d yourdatabase -c "CREATE EXTENSION fuzzystrmatch" psql -d yourdatabase -c "CREATE EXTENSION postgis_tiger_geocoder;" -- PCRE付きでインストールした場合は -- 住所標準化エクステンションも持つべきです psql -d yourdatabase -c "CREATE EXTENSION address_standardizer;"
インストールされて有効になっているEXTENSIONのクエリやEXTENSIONのアップグレード、EXTENSIONを使わずにインストールした場合のEXTENSIONへの切り替えに関する詳細情報については、Section 2.5.3, “PostGISエクステンションのビルドとデプロイ”を参照して下さい。
なんらかの理由で、ラスタ機能なしでコンパイルするか古いやり方でインストールする場合には、より長く、より苦痛を伴いますが、やり方はあります。
インストールされた.sqlファイルは全てPostgreSQLがインストールされているフォルダ内のshare/contrib/postgis-3.0の中にあります。
createdb yourdatabase createlang plpgsql yourdatabase psql -d yourdatabase -f postgis.sql psql -d yourdatabase -f postgis_comments.sql psql -d yourdatabase -f spatial_ref_sys.sql psql -d yourdatabase -f topology.sql psql -d yourdatabase -f topology_comments.sql -- raster (GDAL)付きでコンパイルした場合のみ psql -d yourdatabase -f rtpostgis.sql psql -d yourdatabase -f raster_comments.sql -- SFCGAL対応でビルドした場合 -- psql -d yourdatabase -f sfcgal.sql psql -d yourdatabase -f sfcgal_comments.sql
If you enabled raster support you may want to read below how to properly configure it.
PostGIS 2.1.3では、データベース外ラスタと全てのラスタドライバは、デフォルトでは無効になっています。これらを有効にするには、サーバ上で、環境変数POSTGIS_GDAL_ENABLED_DRIVERS
とPOSTGIS_ENABLE_OUTDB_RASTERS
を設定します。PostGIS 2.2では、Section 8.2, “PostGIS GUC (Grand Unified Custom)変数”に従って設定する、クロスプラットフォームな手法があります。
データベース外ラスタを有効にするには次のようにします。
POSTGIS_ENABLE_OUTDB_RASTERS=1
他の値を入れたり、値を入れない場合には、データベース外ラスタは無効になります。
インストールしたGDALのドライバを有効にするには、次の環境変数を設定します。
POSTGIS_GDAL_ENABLED_DRIVERS=ENABLE_ALL
一部のドライバのみ有効にしたい場合には、環境変数を次のように設定します。
POSTGIS_GDAL_ENABLED_DRIVERS="GTiff PNG JPEG GIF XYZ"
![]() | |
Windows上の場合は、ドライバリストに引用符をつけないで下さい。 |
環境変数の設定はOSによって変わります。UbuntuやDebian上でapt-postgresqlからインストールしたPostgreSQLの場合には、/etc/postgresql/
を編集するのが好まれます。なお、10はPostgreSQLの版を指し、mainはクラスタを示します。10
/main
/environment
Windowsでサービスとして実行している場合には、システム変数で設定します。Windows 7では、コンピュータを右クリックしてプロパティをクリックするか、エクスプローラの検索バーにコントロール パネル\すべてのコントロール パネル項目\システム
を指定します。システムの詳細設定 -> 詳細設定 -> 環境変数を順にクリックして、新しいシステム環境変数を追加します。
環境変数を設定した後は、設定を反映させるために、PostgreSQLサービスの再起動が必要です。
PostGISのビルドと利用のために、次のものが必要です。
必須
PostgreSQL 9.5以上。PostgreSQLの完全なインストール (サーバヘッダを含む)が必要です。PostgreSQLは http://www.postgresql.org/にあります。
完全なPosgreSQL/PostGIS対応表とPostGIS/GEOS対応表についてはhttp://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGISをご覧ください。
GNU Cコンパイラ (gcc
)。ANSI Cコンパイラの中には、PostGISをコンパイルできるものもありますが、gcc
でコンパイルするのが最も問題が少ないと見ています。
GNU Make (gmake
またはmake
)。多くのシステムで、GNU makeがデフォルトのmakeになっています。make -v
を実行して版を確認して下さい。他版のmake
では、PostGISのMakefile
を完全に処理しきれないかもしれません。
投影変換ライブラリ Proj4 の 4.9.0版以上。地理座標系の改善の利点を得るには、Proj4 4.9以上が必要です。Proj4ライブラリは、PostGISの座標系投影変換機能に使われます。Proj4は、http://trac.osgeo.org/proj/からダウンロードできます。
投影変換ライブラリ Proj4 の 4.9.0版以上。地理座標系の改善の利点を得るには、Proj4 4.9以上が必要です。Proj4ライブラリは、PostGISの座標系投影変換機能に使われます。Proj4は、http://trac.osgeo.org/proj/からダウンロードできます。
LibXML2の2.5.x以上。LibXML2は現在取り込み関数 (ST_GeomFromGMLとST_GeomFromKML)で使っています。LibXML2はhttp://xmlsoft.org/downloads.htmlからダウンロード可能です。
JSON-C 0.9以上。JSON-Cは現在、ST_GeomFromGeoJsonによるGeoJSONの取り込みに使われます。JSON-Cはhttps://github.com/json-c/json-c/releases/からダウンロード可能です。
GDAL 1.8以上 (古い版では一部機能が働かなかったり挙動が異なるので1.9以上を強く推奨します)。ラスタ機能に必要で、CREATE EXTENSION postgis
でのインストールに必要となります。このため、PostgreSQL 9.1以上での使用では非常に推奨されますhttp://trac.osgeo.org/gdal/wiki/DownloadSource/からダウンロード可能です。
このパラメータは現在のところ壊れていて、PostgreSQLのインストール先にしかインストールされません。このバグのトラックについてはhttp://trac.osgeo.org/postgis/ticket/635をご覧ください。
オプション
ドライバを有効にするにはSection 2.1, “簡略版”を参照してください。
GTK (GTK+2.0, 2.8+が必要)。シェープファイルのローダであるshp2pgsql-guiのコンパイル用です。http://www.gtk.org/にあります。
SFCGAL 1.1版以上。追加的な2次元や3次元の高度な解析関数をPostGISで使うために使用するものです。Section 8.10, “SFCGAL関数”をご覧下さい。また、GEOSを使う2次元関数のうちいくつか (たとえばST_IntersectionやST_Area)は、GEOSでなくSFCGALを使用することができます。PostgreSQLコンフィギュレーション変数postgis.backend
によって、SFCGALがインストールされている場合にはエンドユーザがバックエンドを制御することができます (デフォルトではGEOS)。SFCGAL 1.2は少なくともCGAL 4.3とBoost 1.54 (http://oslandia.github.io/SFCGAL/installation.htmlをご覧下さい)が必要ですのでご注意下さい。https://github.com/Oslandia/SFCGALにあります。
Chapter 12, 住所標準化をビルドするには、PCRE http://www.pcre.org (Unix系システムには通常はインストール済みです)も必要です。parseaddress-stcities.h
内のエンコードしたデータを再構築したい場合には、Perl CPANのRegex::Assemble
パッケージのみ必要です。Chapter 12, 住所標準化は、PCREライブラリを検出するか、コンフィギュレーションで適切に--with-pcre-dir=/path/to/pcre
を指定すると、自動的にビルドされます。
ST_AsMVTを有効にするには、protobuf-cライブラリ (実行時)とprotoc-cコンパイラ (ビルド時)が必要です。protobuf-cの正しい最小版を確認するには、pkg-configが必要です。protobuf-cをご覧下さい。
CUnit (CUnit
)。レグレッションテストに必要です。http://cunit.sourceforge.net/にあります。
DocBook (xsltproc
)。文書のビルドに必要です。http://www.docbook.org/にあります。
DBLatex (dblatex
)。文書をPDFでビルドするのに必要です。http://dblatex.sourcforge.net/にあります。
ImageMagick (convert
)。文書で使う画像を生成するのに必要です。http://www.imagemagick.org/にあります。
ダウンロードサイトhttp://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzからソースのアーカイブを入手します。
wget http://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gz tar -xvzf postgis-3.0.0.tar.gz
これで、カレントディレクトリの下にpostgis-3.0.0
ができます。
もしくはsvnレポジトリhttp://svn.osgeo.org/postgis/trunk/からチェックアウトします。
svn checkout http://svn.osgeo.org/postgis/trunk/ postgis-3.0.0
新しく作られたpostgis-3.0.0
ディレクトトリに移動して、インストールを続けます。
![]() | |
多くのOSで、ビルドされたPostgreSQL/PostGISパッケージがあります。多くの場合、コンパイルが必要なのは、最もひどい最先端の版が欲しい場合やパッケージメンテナンスを行う人ぐらいです。 本節では、一般的なコンパイル手順を示します。Windows用や他のOS用等にコンパイルするなら、PostGIS User contributed compile guidesやPostGIS Dev Wikiで、より詳細な助けが見つかるかも知れません。 多くのOS用のビルド済みパッケージの一覧はPostGIS Pre-built Packagesにあります。 Windowsユーザの場合は、スタックビルダか、PostGIS Windows download siteから安定版を得ることができます。また、週に1回か2回、刺激的なことがあれば随時ビルドを行っているvery bleeding-edge windows experimental buildsもあります。これらはPostGISの進行中のリリースでの試験に使用します。 |
PostGISモジュールは、PostgreSQLバックエンドサーバの拡張です。PostGIS 3.0.0では、コンパイルのために、完全なPostgreSQLサーバヘッダが必要です。PostgreSQL 3.0.0以上でビルドできます。古い版のPostgreSQLはサポートされません。
PostgreSQLをインストールしていないならPostgreSQLインストールガイドを参照して下さい。http://www.postgresql.org/にあります。
![]() | |
GEOS機能を有効にするために、PostgreSQLをインストール時に明示的に標準C++ライブラリに対する明示的なリンクが必要になる場合があります。 LDFLAGS=-lstdc++ ./configure [コンフィギュアオプション] これは、古い開発ツールとインチキC++例外との対話のための応急処置です。怪しい問題 (望んでいないのにバックエンドが閉じたりそれに近い挙動を起こす)を経験したなら、このトリックを試してみて下さい。もちろん、これを行うにはPostgreSQLをはじめからコンパイルし直す必要があります。 |
次のステップでは、PostGISソースのコンフィギュレーションとコンパイルに概要を記述します。これらは、Linuxユーザ用に書いてありますので、WindowsやMacでは動作しません。
ほとんどのLinuxのインストールと同様に、最初のステップでは、ソースコードのビルドに使われるMakefileを生成します。これは、シェルスクリプトが行います。
./configure
パラメータを付けない場合には、このコマンドは自動で、PostGISのソースコードのビルドを行うのに必要なコンポーネントやライブラリをシステム上で探します。./configureとするのが一般的な使い方ですが、標準的でない位置に必要なライブラリやプログラムを置いてある場合のために、いくつかのパラメータを受け付けます。
次のリストで、共通して使われるパラメータを示します。 完全なリストについては、--helpまたは--help=shortパラメータを使って下さい。
Starting with PostGIS 3.0, the library files generated by default will no longer have the minor version as part of the file name. This means all PostGIS 3 libs will end in postgis-3
. This was done to make pg_upgrade easier, with downside that you can only install one version PostGIS 3 series in your server. To get the old behavior of file including the minor version: e.g. postgis-3.0
add this switch to your configure statement.
PostGISライブラリとSQLスクリプトのインストール先を指定します。デフォルトでは、検出されたPostgreSQLのインストール先と同じになります。
![]() | |
このパラメータは現在のところ壊れていて、PostgreSQLのインストール先にしかインストールされません。このバグのトラックについてはhttp://trac.osgeo.org/postgis/ticket/635をご覧ください。 |
PostgreSQLは、PostGISなどの拡張に対してPostgreSQLのインストール先ディレクトリを伝えるpg_configというユーティリティを持っています。PostGISの対象とする特定のPostgreSQLのインストール先を手動で指定する場合に、このパラメータ(--with-pgconfig=/path/to/pg_config)を使います。
必須ライブラリであるGDALは、ラスタ機能に必要な機能を提供します。GDALには、インストール先ディレクトリをインストールスクリプトに伝えるgdal-configがあります。PostGISのビルドに使う特定のGDALを手動で指定する場合に、このパラメータ (--with-gdalconfig=/path/to/gdal-config)を使います。
必須のジオメトリライブラリであるGEOSには、ソフトウェアのインストール時にGEOSのインストール先ディレクトリを伝えるgeos-configというユーティリティがあります。PostGISのビルドに使う特定のGEOSを手動で指定する場合に、このパラメータ (--with-geosconfig=/path/to/geos-config)を使います。
LibXMLはGeomFromKML/GML処理を行うのに必須のライブラリです。通常はlibxmlをインストールしているなら発見されますが、発見できない場合や特定の版を使用したい場合は、xml2-config
を指定してインストールスクリプトにLibXMLのインストール先ディレクトリを伝えます。PostGISのビルドに使う特定のLibXMLを手動で指定する場合に、このパラメータ (
>--with-xml2config=/path/to/xml2-config)を使います。
Proj4はPostGISに必須の投影変換ライブラリです。PostGISのビルドに使う特定のProj4のディレクトリを手動で指定する場合は、このパラメータ (--with-projdir=/path/to/projdir)を使います。
iconvのインストール先ディレクトリを指定します。
JSON-Cは、MITライセンスのJSONライブラリで、PostGISのST_GeomFromJSONに必須です。PostGISのビルドに使う特定のJSON-Cを手動で指定する場合に、このパラメータ (--with-jsondir=/path/to/jsondir)を使います。
PCREは、BSDライセンスのPerl互換正規表現ライブラリです。住所標準化エクステンションに必須です。PostGISのビルド対象としている特定のPCREを手動で指定する場合に、このパラメータ (--with-pcredir=/path/to/pcredir)を使います。
データインポートGUI (GTK+2.0が必要)をコンパイルします。このパラメータによって、shp2pgsql-guiという、shp2pgsqlのグラフィカルユーザインタフェースが作成されます。
ラスタ機能をインストールします。
トポロジ対応を無くしてコンパイルします。トポロジに必要なロジックは全てpostgis-3.0.0ライブラリ内に作られるので、関連ライブラリはありません。
デフォルトでは、gettextの検出とこれを用いたコンパイルを試みますが、ローダ破損を引き起こす非互換性問題のもとで実行する場合には、このコマンドで無効にできます。これを使ったコンフィギュレーションによって解決する問題の例はhttp://trac.osgeo.org/postgis/ticket/748にあります。ご注意: これを切ることで多くの機能がなくなるわけではありません。まだ文書化されていなくて試験段階であるGUIローダにおける内部のヘルプ/ラベル機能に使われています。
デフォルトでは、このスイッチなしではSFCGAL対応でインストールされません。PATH
は、sfcgal-configへのパスを指定することができる追加的な引数です。
When building with MVT support, Postgis will use Wagyu to clip and validate MVT polygons. Wagyu is the fastest alternative and guarantees producing correct values for this specific case, but it requires a C++-11 compiler. With this optional argument you can disable using this library; GEOS will be used instead.
![]() | |
PostGISをSVNレポジトリから得る場合には、はじめに次のスクリプトを実行します。 ./autogen.sh このスクリプトによってconfigureスクリプトが生成されます。これはPostGISのインストールに関するカスタマイズに使われます。 PostGISをアーカイブファイルで入手する場合には、configureが既に生成されているので./autogen.shは不要です。 |
Makefileが生成されたら、PostGISのビルドは、次のコマンドを実行するだけです。
make
出力の最後の行に"PostGIS was built successfully. Ready to install.
"と出れば終わりです。
PostGIS 1.4.0版からは、全ての関数に文書から生成されるコメントが付きます。これらのコメントを後からインストールするには、次のコマンドを実行しますが、docbookが必要です。アーカイブファイルからインストールする場合は、postgis_comments.sql, raster_comments.sql, topology_comments.sqlは、docフォルダにあるので、コメントを作成する必要はありません。コメントはCREATE EXTENSIONによるインストールの一部として取り込まれます。
make comments
PostGIS 2.0で導入されました。早見表に、または学習中の方のハンドアウトに適しているHTMLチートシートを生成します。xsltprocが必要で、topology_cheatsheet.html
, tiger_geocoder_cheatsheet.html
, raster_cheatsheet.html
, postgis_cheatsheet.html
の4ファイルが生成されます。
HTMLとPDFのビルド済みのものはPostGIS / PostgreSQL Study Guidesにあります。
make cheatsheets
PostgreSQL 9.1以上を使用している場合は、PostGISエクステンションが自動的にビルド、インストールされます。
ソースレポジトリからビルドしている場合は、関数の記述を最初にビルドする必要があります。これらは、docbookがインストールされている時にビルドされます。手動でインストールするには次のようにします。
make comments
アーカイブファイルからのビルドの場合は、ビルド済みのものがあるので、コメントのビルドは必須ではありません。
PostgreSQL 9.1を対象にビルドしている場合は、extensionsは自動的にmake install処理の一部としてビルドするべきです。必要ならextensionsフォルダからビルドできますし、他のサーバで必要ならファイルの複製ができます。
cd extensions cd postgis make clean make export PGUSER=postgres #overwrite psql variables make check #to test before install make install # to test extensions make check RUNTESTFLAGS=--extension
![]() | |
|
エクステンションファイルは、OSに関係なく、常に同じ版のPostGISと同じです。PostGISバイナリを既にインストールしている限りは、エクステンションファイルをあるOSから別のものに複写して大丈夫です。
開発用と異なる別のサーバでエクステンションを手動でインストールしたい場合は、サーバにない時に必要となる通常のPostGISのバイナリだけでなく、次のファイルをextensionsフォルダからPostgreSQLインストール先のPostgreSQL / share / extension
フォルダに複写します。
指定されていない場合のインストールするエクステンションの版等の情報を示す制御ファイpostgis.control, postgis_topology.control
。
エクステンションごとの/sqlフォルダにあるファイル全て。extensions/postgis/sql/*.sql
, extensions/postgis_topology/sql/*.sql
はPostgreSQL share/extensionフォルダの最上位に複写する必要があることに注意して下さい。
以上を実行すると、PgAdmin -> extensionでpostgis
, postgis_topology
が有効なエクステンションとして見えます。
psqlを使う場合は、次のクエリを実行してエクステンションがインストールされていることを確認できます。
SELECT name, default_version,installed_version FROM pg_available_extensions WHERE name LIKE 'postgis%' or name LIKE 'address%'; name | default_version | installed_version ------------------------------+-----------------+------------------- address_standardizer | 3.0.0 | 3.0.0 address_standardizer_data_us | 3.0.0 | 3.0.0 postgis | 3.0.0 | 3.0.0 postgis_sfcgal | 3.0.0 | postgis_tiger_geocoder | 3.0.0 | 3.0.0 postgis_topology | 3.0.0 | (6 rows)
クエリを行ったデータベースにエクステンションがインストールされている場合は、installed_version
カラムに記載が見えます。レコードが返ってこない場合は、PostGIS EXTENSIONがインストールされていないことになります。PgAdmin III 1.14以上では、データベースブラウザツリーのextensions
セクションで提供されていて、右クリックでアップグレードまたアンインストールできます。
有効なエクステンションがある場合、pgAdminエクステンションインタフェースまたは次のSQLの実行によって、選択したデータベースにPostGISエクステンションをインストールできます。
CREATE EXTENSION postgis; CREATE EXTENSION postgis_sfcgal; CREATE EXTENSION fuzzystrmatch; -- postgis_tiger_geocoderに必要 -- postgis_tiger_geocoderで使用されるか単独で使われます CREATE EXTENSION address_standardizer; CREATE EXTENSION address_standardizer_data_us; CREATE EXTENSION postgis_tiger_geocoder; CREATE EXTENSION postgis_topology;
psqlでは、どの版が、どのスキーマにインストールされているかを見ることができます。
\connect mygisdb \x \dx postgis*
List of installed extensions -[ RECORD 1 ]------------------------------------------------- - Name | postgis Version | 3.0.0 Schema | public Description | PostGIS geometry, geography, and raster spat.. -[ RECORD 2 ]------------------------------------------------- - Name | postgis_tiger_geocoder Version | 3.0.0 Schema | tiger Description | PostGIS tiger geocoder and reverse geocoder -[ RECORD 3 ]------------------------------------------------- - Name | postgis_topology Version | 3.0.0 Schema | topology Description | PostGIS topology spatial types and functions
![]() | |
エクステンションのテーブル |
この素晴らしいエクステンション機能を使わずに3.0.0をインストールした場合でもエクステンションベースに変更することができます。まずpostgis_upgrade_22_minor.sql
,raster_upgrade_22_minor.sql
,topology_upgrade_22_minor.sql
のアップグレードスクリプトを実行して最新版にアップグレードします
CREATE EXTENSION postgis FROM unpackaged; CREATE EXTENSION postgis_topology FROM unpackaged; CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;
PostGISのテストを行うには、次のコマンドを実行します。
make check
このコマンドで、実際のPostgreSQLデータベースに対して生成したライブラリを使用した、様々なチェックとレグレッションテストを行います。
![]() | |
PostgreSQL, GEOS または Proj4 を標準の位置にインストールしていない場合には、環境変数LD_LIBRARY_PATHに、ライブラリの位置を追加する必要があるかも知れません。 |
![]() | |
現在のところmake checkは、チェックを行う際に 環境変数 |
成功した場合は、テストの出力は次のようなかんじになります。
CUnit - A unit testing framework for C - Version 2.1-2 http://cunit.sourceforge.net/ Suite: computational_geometry Test: test_lw_segment_side ...passed Test: test_lw_segment_intersects ...passed Test: test_lwline_crossing_short_lines ...passed Test: test_lwline_crossing_long_lines ...passed Test: test_lwline_crossing_bugs ...passed Test: test_lwpoint_set_ordinate ...passed Test: test_lwpoint_get_ordinate ...passed Test: test_point_interpolate ...passed Test: test_lwline_clip ...passed Test: test_lwline_clip_big ...passed Test: test_lwmline_clip ...passed Test: test_geohash_point ...passed Test: test_geohash_precision ...passed Test: test_geohash ...passed Test: test_geohash_point_as_int ...passed Test: test_isclosed ...passed Test: test_lwgeom_simplify ...passed Suite: buildarea Test: buildarea1 ...passed Test: buildarea2 ...passed Test: buildarea3 ...passed Test: buildarea4 ...passed Test: buildarea4b ...passed Test: buildarea5 ...passed Test: buildarea6 ...passed Test: buildarea7 ...passed Suite: geometry_clean Test: test_lwgeom_make_valid ...passed Suite: clip_by_rectangle Test: test_lwgeom_clip_by_rect ...passed Suite: force_sfs Test: test_sfs_11 ...passed Test: test_sfs_12 ...passed Test: test_sqlmm ...passed Suite: geodetic Test: test_sphere_direction ...passed Test: test_sphere_project ...passed Test: test_lwgeom_area_sphere ...passed Test: test_signum ...passed Test: test_gbox_from_spherical_coordinates ...passed Test: test_gserialized_get_gbox_geocentric ...passed Test: test_clairaut ...passed Test: test_edge_intersection ...passed Test: test_edge_intersects ...passed Test: test_edge_distance_to_point ...passed Test: test_edge_distance_to_edge ...passed Test: test_lwgeom_distance_sphere ...passed Test: test_lwgeom_check_geodetic ...passed Test: test_gserialized_from_lwgeom ...passed Test: test_spheroid_distance ...passed Test: test_spheroid_area ...passed Test: test_lwpoly_covers_point2d ...passed Test: test_gbox_utils ...passed Test: test_vector_angle ...passed Test: test_vector_rotate ...passed Test: test_lwgeom_segmentize_sphere ...passed Test: test_ptarray_contains_point_sphere ...passed Test: test_ptarray_contains_point_sphere_iowa ...passed Suite: GEOS Test: test_geos_noop ...passed Test: test_geos_subdivide ...passed Test: test_geos_linemerge ...passed Suite: Clustering Test: basic_test ...passed Test: nonsequential_test ...passed Test: basic_distance_test ...passed Test: single_input_test ...passed Test: empty_inputs_test ...passed Suite: Clustering Union-Find Test: test_unionfind_create ...passed Test: test_unionfind_union ...passed Test: test_unionfind_ordered_by_cluster ...passed Suite: homogenize Test: test_coll_point ...passed Test: test_coll_line ...passed Test: test_coll_poly ...passed Test: test_coll_coll ...passed Test: test_geom ...passed Test: test_coll_curve ...passed Suite: encoded_polyline_input Test: in_encoded_polyline_test_geoms ...passed Test: in_encoded_polyline_test_precision ...passed Suite: geojson_input Test: in_geojson_test_srid ...passed Test: in_geojson_test_bbox ...passed Test: in_geojson_test_geoms ...passed Suite: twkb_input Test: test_twkb_in_point ...passed Test: test_twkb_in_linestring ...passed Test: test_twkb_in_polygon ...passed Test: test_twkb_in_multipoint ...passed Test: test_twkb_in_multilinestring ...passed Test: test_twkb_in_multipolygon ...passed Test: test_twkb_in_collection ...passed Test: test_twkb_in_precision ...passed Suite: serialization/deserialization Test: test_typmod_macros ...passed Test: test_flags_macros ...passed Test: test_serialized_srid ...passed Test: test_gserialized_from_lwgeom_size ...passed Test: test_gbox_serialized_size ...passed Test: test_lwgeom_from_gserialized ...passed Test: test_lwgeom_count_vertices ...passed Test: test_on_gser_lwgeom_count_vertices ...passed Test: test_geometry_type_from_string ...passed Test: test_lwcollection_extract ...passed Test: test_lwgeom_free ...passed Test: test_lwgeom_flip_coordinates ...passed Test: test_f2d ...passed Test: test_lwgeom_clone ...passed Test: test_lwgeom_force_clockwise ...passed Test: test_lwgeom_calculate_gbox ...passed Test: test_lwgeom_is_empty ...passed Test: test_lwgeom_same ...passed Test: test_lwline_from_lwmpoint ...passed Test: test_lwgeom_as_curve ...passed Test: test_lwgeom_scale ...passed Test: test_gserialized_is_empty ...passed Test: test_gbox_same_2d ...passed Suite: measures Test: test_mindistance2d_tolerance ...passed Test: test_rect_tree_contains_point ...passed Test: test_rect_tree_intersects_tree ...passed Test: test_lwgeom_segmentize2d ...passed Test: test_lwgeom_locate_along ...passed Test: test_lw_dist2d_pt_arc ...passed Test: test_lw_dist2d_seg_arc ...passed Test: test_lw_dist2d_arc_arc ...passed Test: test_lw_arc_length ...passed Test: test_lw_dist2d_pt_ptarrayarc ...passed Test: test_lw_dist2d_ptarray_ptarrayarc ...passed Test: test_lwgeom_tcpa ...passed Test: test_lwgeom_is_trajectory ...passed Suite: effectivearea Test: do_test_lwgeom_effectivearea_lines ...passed Test: do_test_lwgeom_effectivearea_polys ...passed Suite: miscellaneous Test: test_misc_force_2d ...passed Test: test_misc_simplify ...passed Test: test_misc_count_vertices ...passed Test: test_misc_area ...passed Test: test_misc_wkb ...passed Test: test_grid ...passed Suite: noding Test: test_lwgeom_node ...passed Suite: encoded_polyline_output Test: out_encoded_polyline_test_geoms ...passed Test: out_encoded_polyline_test_srid ...passed Test: out_encoded_polyline_test_precision ...passed Suite: geojson_output Test: out_geojson_test_precision ...passed Test: out_geojson_test_dims ...passed Test: out_geojson_test_srid ...passed Test: out_geojson_test_bbox ...passed Test: out_geojson_test_geoms ...passed Suite: gml_output Test: out_gml_test_precision ...passed Test: out_gml_test_srid ...passed Test: out_gml_test_dims ...passed Test: out_gml_test_geodetic ...passed Test: out_gml_test_geoms ...passed Test: out_gml_test_geoms_prefix ...passed Test: out_gml_test_geoms_nodims ...passed Test: out_gml2_extent ...passed Test: out_gml3_extent ...passed Suite: kml_output Test: out_kml_test_precision ...passed Test: out_kml_test_dims ...passed Test: out_kml_test_geoms ...passed Test: out_kml_test_prefix ...passed Suite: svg_output Test: out_svg_test_precision ...passed Test: out_svg_test_dims ...passed Test: out_svg_test_relative ...passed Test: out_svg_test_geoms ...passed Test: out_svg_test_srid ...passed Suite: x3d_output Test: out_x3d3_test_precision ...passed Test: out_x3d3_test_geoms ...passed Test: out_x3d3_test_option ...passed Suite: ptarray Test: test_ptarray_append_point ...passed Test: test_ptarray_append_ptarray ...passed Test: test_ptarray_locate_point ...passed Test: test_ptarray_isccw ...passed Test: test_ptarray_signed_area ...passed Test: test_ptarray_unstroke ...passed Test: test_ptarray_insert_point ...passed Test: test_ptarray_contains_point ...passed Test: test_ptarrayarc_contains_point ...passed Test: test_ptarray_scale ...passed Suite: printing Test: test_lwprint_default_format ...passed Test: test_lwprint_format_orders ...passed Test: test_lwprint_optional_format ...passed Test: test_lwprint_oddball_formats ...passed Test: test_lwprint_bad_formats ...passed Suite: SFCGAL Test: test_sfcgal_noop ...passed Suite: split Test: test_lwline_split_by_point_to ...passed Test: test_lwgeom_split ...passed Suite: stringbuffer Test: test_stringbuffer_append ...passed Test: test_stringbuffer_aprintf ...passed Suite: surface Test: triangle_parse ...passed Test: tin_parse ...passed Test: polyhedralsurface_parse ...passed Test: surface_dimension ...passed Suite: Internal Spatial Trees Test: test_tree_circ_create ...passed Test: test_tree_circ_pip ...passed Test: test_tree_circ_pip2 ...passed Test: test_tree_circ_distance ...passed Test: test_tree_circ_distance_threshold ...passed Suite: triangulate Test: test_lwgeom_delaunay_triangulation ...passed Suite: twkb_output Test: test_twkb_out_point ...passed Test: test_twkb_out_linestring ...passed Test: test_twkb_out_polygon ...passed Test: test_twkb_out_multipoint ...passed Test: test_twkb_out_multilinestring ...passed Test: test_twkb_out_multipolygon ...passed Test: test_twkb_out_collection ...passed Test: test_twkb_out_idlist ...passed Suite: varint Test: test_zigzag ...passed Test: test_varint ...passed Test: test_varint_roundtrip ...passed Suite: wkb_input Test: test_wkb_in_point ...passed Test: test_wkb_in_linestring ...passed Test: test_wkb_in_polygon ...passed Test: test_wkb_in_multipoint ...passed Test: test_wkb_in_multilinestring ...passed Test: test_wkb_in_multipolygon ...passed Test: test_wkb_in_collection ...passed Test: test_wkb_in_circularstring ...passed Test: test_wkb_in_compoundcurve ...passed Test: test_wkb_in_curvpolygon ...passed Test: test_wkb_in_multicurve ...passed Test: test_wkb_in_multisurface ...passed Test: test_wkb_in_malformed ...passed Suite: wkb_output Test: test_wkb_out_point ...passed Test: test_wkb_out_linestring ...passed Test: test_wkb_out_polygon ...passed Test: test_wkb_out_multipoint ...passed Test: test_wkb_out_multilinestring ...passed Test: test_wkb_out_multipolygon ...passed Test: test_wkb_out_collection ...passed Test: test_wkb_out_circularstring ...passed Test: test_wkb_out_compoundcurve ...passed Test: test_wkb_out_curvpolygon ...passed Test: test_wkb_out_multicurve ...passed Test: test_wkb_out_multisurface ...passed Test: test_wkb_out_polyhedralsurface ...passed Suite: wkt_input Test: test_wkt_in_point ...passed Test: test_wkt_in_linestring ...passed Test: test_wkt_in_polygon ...passed Test: test_wkt_in_multipoint ...passed Test: test_wkt_in_multilinestring ...passed Test: test_wkt_in_multipolygon ...passed Test: test_wkt_in_collection ...passed Test: test_wkt_in_circularstring ...passed Test: test_wkt_in_compoundcurve ...passed Test: test_wkt_in_curvpolygon ...passed Test: test_wkt_in_multicurve ...passed Test: test_wkt_in_multisurface ...passed Test: test_wkt_in_tin ...passed Test: test_wkt_in_polyhedralsurface ...passed Test: test_wkt_in_errlocation ...passed Suite: wkt_output Test: test_wkt_out_point ...passed Test: test_wkt_out_linestring ...passed Test: test_wkt_out_polygon ...passed Test: test_wkt_out_multipoint ...passed Test: test_wkt_out_multilinestring ...passed Test: test_wkt_out_multipolygon ...passed Test: test_wkt_out_collection ...passed Test: test_wkt_out_circularstring ...passed Test: test_wkt_out_compoundcurve ...passed Test: test_wkt_out_curvpolygon ...passed Test: test_wkt_out_multicurve ...passed Test: test_wkt_out_multisurface ...passed Run Summary: Type Total Ran Passed Failed Inactive suites 38 38 n/a 0 0 tests 251 251 251 0 0 asserts 2468 2468 2468 0 n/a Elapsed time = 0.298 seconds Creating database 'postgis_reg' Loading PostGIS into 'postgis_reg' /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/postgis.sql /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/postgis_comments.sql Loading SFCGAL into 'postgis_reg' /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/sfcgal.sql /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/sfcgal_comments.sql PostgreSQL 9.4.4, compiled by Visual C++ build 1800, 32-bit Postgis 2.2.0dev - r13980 - 2015-08-23 06:13:07 scripts 2.2.0dev r13980 GEOS: 3.5.0-CAPI-1.9.0 r4088 PROJ: Rel. 4.9.1, 04 March 2015 SFCGAL: 1.1.0 Running tests loader/Point .............. ok loader/PointM .............. ok loader/PointZ .............. ok loader/MultiPoint .............. ok loader/MultiPointM .............. ok loader/MultiPointZ .............. ok loader/Arc .............. ok loader/ArcM .............. ok loader/ArcZ .............. ok loader/Polygon .............. ok loader/PolygonM .............. ok loader/PolygonZ .............. ok loader/TSTPolygon ......... ok loader/TSIPolygon ......... ok loader/TSTIPolygon ......... ok loader/PointWithSchema ..... ok loader/NoTransPoint ......... ok loader/NotReallyMultiPoint ......... ok loader/MultiToSinglePoint ......... ok loader/ReprojectPts ........ ok loader/ReprojectPtsGeog ........ ok loader/Latin1 .... ok loader/Latin1-implicit .... ok loader/mfile .... ok dumper/literalsrid ....... ok dumper/realtable ....... ok affine .. ok bestsrid .. ok binary .. ok boundary .. ok cluster .. ok concave_hull .. ok ctors .. ok dump .. ok dumppoints .. ok empty .. ok forcecurve .. ok geography .. ok in_geohash .. ok in_gml .. ok in_kml .. ok in_encodedpolyline .. ok iscollection .. ok legacy .. ok long_xact .. ok lwgeom_regress .. ok measures .. ok operators .. ok out_geometry .. ok out_geography .. ok polygonize .. ok polyhedralsurface .. ok postgis_type_name .. ok regress .. ok regress_bdpoly .. ok regress_index .. ok regress_index_nulls .. ok regress_management .. ok regress_selectivity .. ok regress_lrs .. ok regress_ogc .. ok regress_ogc_cover .. ok regress_ogc_prep .. ok regress_proj .. ok relate .. ok remove_repeated_points .. ok removepoint .. ok setpoint .. ok simplify .. ok simplifyvw .. ok size .. ok snaptogrid .. ok split .. ok sql-mm-serialize .. ok sql-mm-circularstring .. ok sql-mm-compoundcurve .. ok sql-mm-curvepoly .. ok sql-mm-general .. ok sql-mm-multicurve .. ok sql-mm-multisurface .. ok swapordinates .. ok summary .. ok temporal .. ok tickets .. ok twkb .. ok typmod .. ok wkb .. ok wkt .. ok wmsservers .. ok knn .. ok hausdorff .. ok regress_buffer_params .. ok offsetcurve .. ok relatematch .. ok isvaliddetail .. ok sharedpaths .. ok snap .. ok node .. ok unaryunion .. ok clean .. ok relate_bnr .. ok delaunaytriangles .. ok clipbybox2d .. ok subdivide .. ok in_geojson .. ok regress_sfcgal .. ok sfcgal/empty .. ok sfcgal/geography .. ok sfcgal/legacy .. ok sfcgal/measures .. ok sfcgal/regress_ogc_prep .. ok sfcgal/regress_ogc .. ok sfcgal/regress .. ok sfcgal/tickets .. ok sfcgal/concave_hull .. ok sfcgal/wmsservers .. ok sfcgal/approximatemedialaxis .. ok uninstall . /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/uninstall_sfcgal.sql /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/uninstall_postgis.sql . ok (4336) Run tests: 118 Failed: 0 -- if you built --with-gui, you should see this too CUnit - A unit testing framework for C - Version 2.1-2 http://cunit.sourceforge.net/ Suite: Shapefile Loader File shp2pgsql Test Test: test_ShpLoaderCreate() ...passed Test: test_ShpLoaderDestroy() ...passed Suite: Shapefile Loader File pgsql2shp Test Test: test_ShpDumperCreate() ...passed Test: test_ShpDumperDestroy() ...passed Run Summary: Type Total Ran Passed Failed Inactive suites 2 2 n/a 0 0 tests 4 4 4 0 0 asserts 4 4 4 0 n/a
postgis_tiger_geocoder
とaddress_standardizer
は、現在は、標準的なPostgreSQLインストールチェックにのみ対応しています。これらをテストするには、次のようにします。ご注意: PostGISコードフォルダのルートでmake installを既に行っている場合には、make installは重要ではありません。
address_standardizer用:
cd extensions/address_standardizer make install make installcheck
出力は次のようなかんじになります。
============== dropping database "contrib_regression" ============== DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test test-init-extensions ... ok test test-parseaddress ... ok test test-standardize_address_1 ... ok test test-standardize_address_2 ... ok ===================== All 4 tests passed. =====================
Tiger Geocodeを使う場合には、使用するPostgreSQLインスタンス内にPostGISとfuzzystrmatchのエクステンションが必要です。PostGISをaddress_standardizer機能付きでビルドした場合は、address_standardizerのテストも行います。
cd extensions/postgis_tiger_geocoder make install make installcheck
出力は次のようなかんじになります。
============== dropping database "contrib_regression" ============== DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== installing fuzzystrmatch ============== CREATE EXTENSION ============== installing postgis ============== CREATE EXTENSION ============== installing postgis_tiger_geocoder ============== CREATE EXTENSION ============== installing address_standardizer ============== CREATE EXTENSION ============== running regression test queries ============== test test-normalize_address ... ok test test-pagc_normalize_address ... ok ===================== All 2 tests passed. =====================
PostGISをインストールするには、次のコマンドを実行します。
make install
これにより、PostGISのインストールファイルが、--prefixパラメータで指定した、適切なサブディレクトリに複写されます。次に特筆すべきサブディレクトリを示します。
ローダとダンパのバイナリのインストール先は[prefix]/bin
です。
postgis.sql
などのSQLファイルのインストール先は[prefix]/share/contrib
です。
PostGISライブラリのインストール先は[prefix]/lib
です。
先にmake commentsを実行してpostgis_comments.sql
, raster_comments.sql
を生成していた場合は、次のコマンドを実行すると、これらのSQLファイルがインストールされます。
make comments-install
![]() | |
|
PostgreSQL 9.1以上を使っていて、extensions/postgisモジュールをコンパイルとインストールを行っている場合は、新しい方法で空間データベースを生成できます。
createdb [データベース名]
PostGISエクステンションの中核によって、ジオメトリ、ジオグラフィ、ラスタ、spatial_ref_sysおよび全ての関数とコメントがインストールされます。次のコマンドを実行するだけです。
CREATE EXTENSION postgis;
psql -d [データベース名] -c "CREATE EXTENSION postgis;"
トポロジは別のエクステンションとして用意されています。次のコマンドでインストールします。
psql -d [データベース名] -c "CREATE EXTENSION postgis;"
トポロジは別のエクステンションとして用意されています。次のコマンドでインストールします。
psql -d [データベース名] -c "CREATE EXTENSION postgis_topology;"
以前の版の古いバックアップを新しいデータベースにリストアする予定の場合には、次を実行します。
psql -d [データベース名] -f legacy.sql
![]() | |
レガシー関数が必要なら、PostGISのマイナーバージョンのアップグレードならいつでも、legacy.sqlスクリプトの再インストールが必要です。例えば、2.4.3から2.5.0にアップグレードした場合には、2.5.0のlegacy.sqlの再インストールが必要です。関数の中にライブラリへの参照を作るものがあり、ライブラリ名にマイナー版番号を含むためです。 |
リストアとクリーンアップを行った後で非推奨関数を消すためにuninstall_legacy.sql
を実行できます。
![]() | |
This is generally only needed if you cannot or don't want to get PostGIS installed in the PostgreSQL extension directory (for example during testing, development or in a restricted environment). |
PostGISデータベースを作る最初のステップは、単純なPostgreSQLデータベースの作成です。
createdb [データベース名]
多くのPostGIS関数は、PL/pgSQL手続き言語で書かれています。次のステップは、PL/pgSQL言語を新たに作成したデータベースで有効にすることです。次のコマンドを実行します。PostgreSQL 8.4以上では、通常は既にインストールされています。
createlang plpgsql [データベース名]
次に、PostGISオブジェクトと関数定義をデータベースにロードします。定義ファイルpostgis.sql
(コンフィギュレーション段階で指定した[prefix]/share/contrib
にあります)をロードします。
psql -d [データベース名] -f postgis.sql
完全なEPSG座標系定義IDセットについては、spatial_ref_sys.sql
定義ファイルをロードしてspatial_ref_sys
テーブルを生成して下さい。これによりジオメトリ関数ST_Transform()が実行できるようになります。
psql -d [データベース名] -f spatial_ref_sys.sql
PostGISが持つ関数についての助けとなるコメントを求めるなら、postgis_comments.sql
を、データベースにロードします。コメントは、psqlターミナルウィンドウで単に\dd [function_name]とすれば見ることができます。ロードは次のようにします。
psql -d [データベース名] -f postgis_comments.sql
ラスタ機能をインストールします。
psql -d [データベース名] -f rtpostgis.sql
ラスタ機能のコメントをインストールします。ラスタ関数ごとの簡易説明が提供されます。psqlまたはpgAdmin等の関数コメントを表示できるPostgreSQLツールで使えます。
psql -d [データベース名] -f raster_comments.sql
トポロジ機能をインストールします。
psql -d [データベース名] -f topology/topology.sql
トポロジ機能のコメントをインストールします。トポロジ関数/型ごとの簡易説明が提供されます。psqlまたはpgAdmin等の関数コメントを表示できるPostgreSQLツールで使えます。
psql -d [データベース名] -f topology/topology_comments.sql
以前の版の古いバックアップを新しいデータベースにリストアする予定の場合には、次を実行します。
psql -d [データベース名] -f legacy.sql
![]() | |
テーブルを回復し、MapServerやGeoServerのようなアプリケーションで動作させるのに必要な最低限をインストールするには |
リストアとクリーンアップを行った後で非推奨関数を消すためにuninstall_legacy.sql
を実行できます。
address_standardizer
エクステンションは、別途ダウンロードする必要がある別パッケージとしていました。PostGIS 2.2からは同梱されています。address_standardizeの追加情報、できること、および、コンフィギュレーション方法については、Chapter 12, 住所標準化をご覧下さい。
標準化エクステンションは、Normalize_Addressの後継で、PostGISに入っているTigerジオコーダエクステンションに使うことができます。この場合の使い方についてはSection 2.9.3, “TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用”を参照して下さい。また、ユーザ自身がつくるジオコーダの要素として使用したり、住所の比較を簡単にするために住所を標準化するために使うことができます。
住所標準化エクステンションはPCREに依存しています。PCREは多くのUNIX系システムにインストールされていますが、http://www.pcre.orgから最新版をダウンロードできます。Section 2.5.1, “コンフィギュレーション”の際にPCREを発見すると、住所標準化エクステンションが自動的にビルドされます。使用したいPCREのインストールが独自なものである場合は、configureに--with-pcredir=/path/to/pcre
を渡します。/path/to/pcre
は、PCREのincludeとlibのあるルートフォルダです。
Windowsでは、PostGIS 2.1以上に住所標準化エクステンションが同梱されているので、コンパイルを行わずに、すぐにCREATE EXTENSION
に行くことができます。
インストールしたら、対象データベースに接続して次のSQLが実行できます。
CREATE EXTENSION address_standardizer;
次のテストでは、rules, gaz, lexテーブルは必要ありません。
SELECT num, street, city, state, zip FROM parse_address('1 Devonshire Place PH301, Boston, MA 02109');
出力は次のようになります。
num | street | city | state | zip -----+------------------------+--------+-------+------- 1 | Devonshire Place PH301 | Boston | MA | 02109
PerlのRegex::Assembleは、ソースツリーの一部がこれで作られていますが、住所標準化エクステンションではもはや不要です。ただし、usps-st-city-orig.txt
またはusps-st-city-orig.txt usps-st-city-adds.tx
を編集する必要がある場合は、parseaddress-stcities.h
のリビルドでRegex:Assembleが必要です。
cpan Regexp::Assemble
Ubuntu / Degianの場合には、次のようにしなければならないかも知れません。
sudo perl -MCPAN -e "install Regexp::Assemble"
Tigerジオコーダのような拡張機能はPostGISディストリビューションに同梱されていません。Tigerジオコーダエクステンションが無かったり、インストールしているものより新しい版のものが欲しい場合には、Windows Unreleased Versions節でPostgreSQLの版に合ったパッケージにあるshare/extension/postgis_tiger_geocoder.*
ファイルを使います。これらのパッケージはWindows用ですが、postgis_tige_geocoderエクステンションファイルは、SQLとPL/pgSQLだけですので、他のOSでも動作します。
PostgreSQL 9.1以上とPostGIS 2.1.0を使用している場合は、Tigerジオコーダのインストールで、新しいエクステンションモデルの利点を得ることができます。次のようにします。
まず、通常の方法で、PostGIS 2.1.0のバイナリを取得するか、コンパイルしてインストールします。これにより重要なエクステンションファイルとTigerジオコーダのファイルがインストールされます。
psql、pgAdminまたは他のツールでデータベースに接続して、次のSQLコマンドを実行します。既にPostGISを持っているデータベースにインストールする場合は、一つ目の手順は不要です。fuzzystrmatch
エクステンションが既にインストールされている場合は、二つ目の手順は不要です。
CREATE EXTENSION postgis; CREATE EXTENSION fuzzystrmatch; CREATE EXTENSION postgis_tiger_geocoder; -- 規則を基にした住所標準化 (pagc_normalize_address)を使いたい場合の任意実行 CREATE EXTENSION address_standardizer;
既にpostgis_tiger_geocoderエクステンションをインストールしていて、最新版に更新するだけの場合には、次を実行します。
ALTER EXTENSION postgis UPDATE; ALTER EXTENSION postgis_tiger_geocoder UPDATE;
独自のエントリを生成した場合や、tiger.loader_platform
とtiger.loader_variables
に変更を加えた場合には、これらをアップデートしなければならないことがあります。
正しくインストールされたかを確認するために、インストール対象データベース内で次のSQLを実行します。
SELECT na.address, na.streetname,na.streettypeabbrev, na.zip FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
出力は次のようになります。
address | streetname | streettypeabbrev | zip ---------+------------+------------------+------- 1 | Devonshire | Pl | 02109
tiger.loader_platform
テーブルの、実行ファイルやサーバのパスを持つ新しいレコードを生成します。
sh
コンベンションのあとにdebbieというプロファイルを生成する例として、次のコマンドを実行します。
INSERT INTO tiger.loader_platform(os, declare_sect, pgbin, wget, unzip_command, psql, path_sep, loader, environ_set_command, county_process_command) SELECT 'debbie', declare_sect, pgbin, wget, unzip_command, psql, path_sep, loader, environ_set_command, county_process_command FROM tiger.loader_platform WHERE os = 'sh';
それから、declare_sectカラム内のパスを編集して、Debbieのpg, unzip, shp2pgsql, psql他のパス位置に適応するようにします。
loader_platform
テーブルを編集しない場合は、一般的なアイテムの位置を持っているので、スクリプトが生成された後で、スクリプトを編集しなければなりません。
PostGIS 2.4.1からは、ZTCA5
(Zip Code 5 digit Tabulation Area)のロード手順が変更され、有効になった時にLoader_Generate_Nation_Scriptの一部として現在のZCTA5データをロードするようになりました。デフォルトでは切られています。ロードにかなりの時間 (20から60分)が取られ、かなりのディスクスペースを占有するのに、そんなに頻繁には使わないためです。
有効にするには、次のようにします。
UPDATE tiger.loader_lookuptables SET load = true WHERE table_name = 'zcta510';
境界のフィルタが追加され、ちょうど境界内のZIPに制限された場合に、Geocode関数は、ZCTA5が存在するなら使います。Reverse_Geocode関数は、返された住所にZIPコードが無い場合に (しばしば高速道路での逆ジオコーディングで発生します)、これを使います。
サーバまたはローカル (サーバへのネットワーク接続が早い場合)のルートにgisdata
というフォルダを作成します。このフォルダはTigerファイルがダウンロードされ、処理される場所です。サーバのルートにフォルダを作ると不幸になる場合や、単に他のフォルダに移したい場合には、tiger.loader_variables
テーブルのstaging_fold
フィールドを編集します。
gisdata
フォルダ内にtempというフォルダを作成します。もしくは、staging_fold
で示されたフォルダを作成します。ローダがダウンロードしたTigerデータを展開する場所です。
そして、SQL関数Loader_Generate_Nation_Scriptを実行して、独自のプロファイルの名前を使うか確認し、.shまたは.batファイルにスクリプトを複写します。たとえば、新しいプロファイルで国のロードを行う場合には、次のようにします。
psql -c "SELECT Loader_Generate_Nation_Script('debbie')" -d geocoder -tA > /gisdata/nation_script_load.sh
生成された国データをロードするコマンドラインスクリプトを実行します。
cd /gisdata sh nation_script_load.sh
国スクリプトを実行した後、tiger_data
スキーマに三つのテーブルが作られ、データが格納されています。次のクエリをpsqlかpgAdminから実行して、確認します。
SELECT count(*) FROM tiger_data.county_all;
count ------- 3233 (1 row)
SELECT count(*) FROM tiger_data.state_all;
count ------- 56 (1 row)
デフォルトではbg
, tract
, tabblock
に対応するテーブルはロードされません。ジオコーダはこれらのテーブルを使いませんが、一般に、人口統計に使います。州データのロードの一部としてロードするには、次の手続きを実行して有効にします。
UPDATE tiger.loader_lookuptables SET load = true WHERE load = false AND lookup_name IN('tract', 'bg', 'tabblock');
もしくは、Loader_Generate_Census_Scriptを使って州のデータをロードした後に、これらのテーブルだけをロードできます。
データをロードしたい州ごとに、Loader_Generate_Scriptで州スクリプトを作ります。
![]() | |
国データのロードを完了する前に*州スクリプトを作ってはなりません*。州スクリプトは国スクリプトでロードされる国リストを利用するためです。 |
psql -c "SELECT Loader_Generate_Script(ARRAY['MA'], 'debbie')" -d geocoder -tA > /gisdata/ma_load.sh
生成されたコマンドラインスクリプトを実行します。
cd /gisdata sh ma_load.sh
全てのデータのロードが完了するか中断ポイントに達した後に、全てのtigerテーブルに対してanalyzeを実行して、(継承されたものも含めて)状態を更新するのは良いことです。
SELECT install_missing_indexes(); vacuum analyze verbose tiger.addr; vacuum analyze verbose tiger.edges; vacuum analyze verbose tiger.faces; vacuum analyze verbose tiger.featnames; vacuum analyze verbose tiger.place; vacuum analyze verbose tiger.cousub; vacuum analyze verbose tiger.county; vacuum analyze verbose tiger.state; vacuum analyze verbose tiger.zip_lookup_base; vacuum analyze verbose tiger.zip_state; vacuum analyze verbose tiger.zip_state_loc;
エクステンションモデルを使わずにTigerジオコーダをインストールしている場合に、次のようにして、エクステンションモデルに変換できます。
Section 2.9.5, “Tigerジオコーダのアップグレード”の指示に従って非エクステンションモデルのアップグレードを行います。
psqlまたはpgAdminでデータベースに接続して、次のコマンドを実行します。
CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;
まず、上述の手順でPostGISをインストールします。
extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzをダウンロードします。
tar xvfz postgis-3.0.0.tar.gz
cd postgis-3.0.0/extras/tiger_geocoder
tiger_loader_2015.sql
(違う年のものをロードしたくないならば最新のローダファイル)をあなたの実行サーバ等のパスに編集します。もしくはloader_platform
がインストールされた後に一度これを更新します。このファイルもloader_platform
も編集しない場合には、一般的なアイテムの位置を持っているだけなので、Loader_Generate_Nation_ScriptとLoader_Generate_Scriptを実行した後に、生成されたスクリプトを編集しなければなりません。
初めてTigerジオコーダをインストールする場合は、Windowsではcreate_geocode.bat
を、またLinux/Unix/Mac OSXではcreate_geocode.sh
を、使用するPostgreSQLにとって独自の設定に変更したうえで、コマンドラインから対応するスクリプトを実行します。
データベースにtiger
スキーマがあることを確認します。もし無い場合は、次の行を参考に、コマンドを実行します。
ALTER DATABASE geocoder SET search_path=public, tiger;
住所正規化機能は、トリッキーな住所を除いて、大体データなしで動作します。テストを実行して次のように見えることを確認して下さい。
SELECT pprint_addy(normalize_address('202 East Fremont Street, Las Vegas, Nevada 89101')) As pretty_address; pretty_address --------------------------------------- 202 E Fremont St, Las Vegas, NV 89101
皆さんが問題と思われるの多くのことのひとつに、ジオコーディング前の準備に住所を正規化する関数Normalize_Addressがあります。住所正規化は万全と言うにはほど遠く、パッチをあてようとすると膨大な資源を費やします。よって、より良い住所標準化エンジンを持つ他のプロジェクトに統合しました。この新しい住所標準化を使うには、Section 2.8, “PAGC住所標準化ツールのインストールと使用”で記述するようにエクステンションをコンパイルし、使用するデータベースにインストールします。
このエクステンションをpostgis_tiger_geocoder
をインストールしているデータベースにインストールすると、Pagc_Normalize_Address文字列のストリート住所を与えると、道路後置辞、前置辞、標準タイプ、番地、ストリート名等を複数フィールドに分解して持つnorm_addy
複合型を返します。この関数は、tiger_geocoder同梱のルックアップテーブルだけを使います (Tigerデータは不要です)。住所標準化エクステンションが必要です。を、Normalize_Addressの代わりに使うことができます。このエクステンションはTigerジオコーダからは見えないので、国際的な住所といった他のデータソースでも使えます。Tigerジオコーダエクステンションは、その版の規則テーブル (tiger.pagc_rules
), gaz table (tiger.pagc_gaz
), lexテーブル (tiger.pagc_lex
)を同梱しています。これらは、必要に応じて標準化の改善のために追加や更新ができます。
データロードの説明の詳細はextras/tiger_geocoder/tiger_2011/README
にあります。これは一般的な手順を示しています。
ロードプロセスによって、米センサスウェブサイトから個々の国ファイル、リクエストされた州のデータをダウンロードし、ファイルを展開し、個別の州をそれぞれの州テーブルの集合にロードします。各州のテーブルは、tiger
スキーマで定義されたテーブルを継承しているので、これらのテーブルに対して全てのデータにアクセスするためのクエリを出すことができますし、州の再読み込みが必要となったり、州が必要ない場合には、Drop_State_Tables_Generate_Scriptで、いつでも州テーブルの集合を削除するクエリを出すことができます。
データのロードを可能にするためには次のツールが必要です。
センサスウェブサイトから取得するZIPファイルを展開するツール。
Unix系システムでは、unzip
実行ファイルです。通常は、ほとんどのUnix系プラットフォームで既にインストールされています。
Windowsでは7-zipです。http://www.7-zip.org/からダウンロードできる無償の圧縮解答ツールです。
shp2pgsql
コマンド。PostGISインストール時にデフォルトでインストールされます。
wget
コマンド。通常はほとんどのUnix/Linuxシステムにインストールされている、ウェブ取得ツールです。
Windows用については、コンパイル済みのバイナリをhttp://gnuwin32.sourceforge.net/packages/wget.htmから取得できます。
tiger_2010からアップグレードする場合には、最初にDrop_Nation_Tables_Generate_Scriptを生成、実行する必要があります。州データをロードする前に、Loader_Generate_Nation_Scriptで国データをロードする必要があります。これによって、環境に合ったローダスクリプトが生成されます。Loader_Generate_Nation_Scriptは、一度の操作で、(2010からの)アップグレードと、新しいインストールが行われます。
州データをロードするには、Loader_Generate_Scriptを参照して、手持ちのプラットフォームで動作する、求める州データをロードするデータロードスクリプトを生成します。州データはひとつずつダウンロードできることに注意して下さい。一度に必要な州の全てについてデータをロードする必要はありません。必要なだけダウンロードできます。
求める州データをロードした後は、Install_Missing_Indexesに示すように、
SELECT install_missing_indexes();
を実行するようにして下さい。
行うべきことができたかをテストするために、Geocodeを使用する州の中の住所についてジオコーダを実行してみます。
2.0以上に含まれるTigerジオコーダがインストールされている場合には、どうしても必要な訂正があるときは、いつでも臨時のアーカイブファイルからでも機能のアップグレードができます。 これは、エクステンションでインストールされていないTigerジオコーダで動作します。
extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzをダウンロードします。
tar xvfz postgis-3.0.0.tar.gz
cd postgis-3.0.0/extras/tiger_geocoder/tiger_2011
Windowsの場合はupgrade_geocoder.bat
スクリプト、Linux/Unix/MacOS Xの場合はupgrade_geocoder.sh
スクリプトの位置を特定します。 PostGISデータベースの資格情報を持つように編集します。
2010または2011からアップグレードする場合には、確実にローダスクリプトのコメントアウトを消すと、2012データのロードのための最新のスクリプトを得ます。
対応するスクリプトをコマンドラインから実行します。
次に、全ての国テーブルを削除し、新しい国テーブルをロードします。Drop_Nation_Tables_Generate_Scriptに詳細がある通り、このSQLステートメントを使った削除スクリプトを生成します。
SELECT drop_nation_tables_generate_script();
生成した削除SQLステートメントを実行します。
Loader_Generate_Nation_Scriptに詳細がある通り、このSELECTステートメントを使った削除スクリプトを生成します。
Windows向け
SELECT loader_generate_nation_script('windows');
Unix/Linux向け
SELECT loader_generate_nation_script('sh');
生成したスクリプトの実行方法に関する説明は、Section 2.9.4, “Tigerデータのロード”を参照して下さい。これは一度だけ実行する必要があります。
![]() | |
2010/2011州テーブルを混在させることができ、それぞれの州について個別にアップグレードできます。2011にアップグレードする前に、まず、Drop_State_Tables_Generate_Scriptを使って、2010州テーブルを削除します。 |
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
既存の空間データベースのアップグレードは、新しいPostGISオブジェクト定義の置き換えや導入を必要とするとき、慎重を要することがあります。
不幸なことに、定義の全てが実行中のデータベース内で簡単には置き換えられるわけではないので、ダンプ/リロードが最善策となることがあります。
PostGISには、マイナーバージョンアップやバグフィクスリリースの場合に使うソフトアップグレードと、メジャーアップグレードで使うハードアップグレードが用意されています。
PostGISをアップグレードしようとする前にデータのバックアップを取ることは、常に価値のあるものです。pg_dumpで -Fc フラグを使うと、ハードアップグレードによってダンプを常にリストアすることができます。
エクステンションを使ってインストールした場合は、エクステンションモデルでアップグレードしなければなりません。 古いSQLスクリプトを使ってインストールした場合は、SQLスクリプトでアップグレードすべきです。適切な方を参照して下さい。
PostGISをエクステンションを使わずにインストールした人向けです。エクステンションを使っていてこの方法を使うと、次のようなメッセージが現れます。
can't drop ... because postgis extension depends on it
NOTE: if you are moving from PostGIS 1.* to PostGIS 2.* or from PostGIS 2.* prior to r7409, you cannot use this procedure but would rather need to do a HARD UPGRADE.
After compiling and installing (make install) you should find a set of *_upgrade.sql
files in the installation folders. You can list them all with:
ls `pg_config --sharedir`/contrib/postgis-3.0.0/*_upgrade.sql
Load them all in turn, starting from postgis_upgrade.sql
.
psql -f postgis_upgrade.sql -d [データベース名]
ラスタ機能とトポロジ機能についても同じ手続きです。それぞれrtpostgis_upgrade*.sql
とtopology_upgrade*.sql
とになります。次のようにします。
psql -f rtpostgis_upgrade.sql -d [データベース名]
psql -f topology_upgrade.sql -d [データベース名]
psql -f postgis_upgrade.sql -d [データベース名]
![]() | |
アップグレードのための特定の版の |
???関数の"procs need upgrade"というメッセージで、この種のアップグレードを実行する必要性についての情報が得られます。
エクステンションを使ってPostGISをインストールした場合には、エクステンションを使ってアップグレードする必要があります。エクステンションを使ったマイナーアップグレードはかなり楽です。
ALTER EXTENSION postgis UPDATE TO "3.0.0"; ALTER EXTENSION postgis_topology UPDATE TO "3.0.0";
次のようなエラー通知が表示されることがあります。
No migration path defined for ... to 3.0.0
この場合は、データベースをバックアップして、Section 2.6, “エクステンションを使った空間データベースの生成”に記述されているように新しいデータベースを生成し、バックアップを新しいデータベースにリストアしなければなりません。
次のようなメッセージを得ることがあります。
Version "3.0.0" of extension "postgis" is already installed
この場合は、全てアップデートされていて、安全に無視できます。SVN版から次版(新しい版番号を得ていないもの)にアップグレードしようとしない限り、"next"を版文字列に追加できます。ただし、次回に"next"を削除する必要があります。
ALTER EXTENSION postgis UPDATE TO "3.0.0next"; ALTER EXTENSION postgis_topology UPDATE TO "3.0.0next";
![]() | |
PostGISをバージョン指定なしにインストールした場合には、 しばしばリストアの前のPostGIS EXTENSIONの再インストールをとばすことができます。 バックアップは |
![]() | |
If you are upgrading PostGIS extension from a version prior to 3.0.0 you'll end up with an unpackaged PostGIS Raster support. You can repackage the raster support using: CREATE EXTENSION postgis_raster FROM unpackaged; And then, if you don't need it, drop it with: DROP EXTENSION postgis_raster;
|
ハードアップグレードとは、PostGISで利用可能なデータの完全なダンプ/リロードを意味します。PostGISオブジェクトの内部格納状態が変更される場合や、ソフトアップグレードができない場合に、ハードアップグレードが必要です。付録のリリースノートに、版ごとについて、ダンプ/リロード (ハードアップグレード)の要否を記載しています。
ダンプ/リロード作業はpostgis_restore.plスクリプトが補助します。このスクリプトは、PostGIS (古いものを含む)に属する定義を全て飛ばすように注意します。また、重複シンボルエラーや非推奨オブジェクトを持越すことなく、スキーマとデータをPostGISをインストールしたデータベースにリストアできます 。
Windows用に関する追加情報はWindows Hard upgradeにあります。
手続きは次の通りです。
アップグレードしたデータベース (olddb
と呼ぶことにしましょう)の「カスタム書式」のダンプを、バイナリBLOBデータを含めたダンプを指定して (-b)、verboseモード (-v)で生成します。ユーザはデータベースのオーナーになることができ、PostgreSQLのスーパーユーザである必要はありません。
pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/olddb.backup" olddb
新しいデータベースにPostGISを、PostGISが無い状態からインストールします。このデータベースをnewdb
と呼ぶことにします。この作業に関する説明についてはSection 2.7, “空間データベースをエクステンションを使わずに生成する”とSection 2.6, “エクステンションを使った空間データベースの生成”とを参照して下さい。
ダンプにあるspatial_ref_sysは、リストアされますが、既にあるspatial_ref_sysを上書きしません。リストア対象のデータベースに公式データセットの訂正が確実に伝わるようにするためです。標準のエントリを上書きしたい場合は、newdbを生成する際にspaltial_ref_sys.sqlファイルをロードしないだけです。
データベースが本当に古く、ビューや関数に、長く非推奨になっている関数があるような場合には、関数やビューを使えるようにするlegacy.sqlをロードする必要があるでしょう。ただし、本当に必要な場合に限ります。可能なら、ビューや関数をダンプせずにアップグレードすることを検討して下さい。非推奨関数は、uninstall_legacy.sql
で後から削除することができます。
バックアップを新しいnewdb
データベースにリストアするには、postgis_restore.plを使います。psqlが予期せぬエラーを標準エラー出力に出すことがあります。これらのログを保存しておいて下さい。
perl utils/postgis_restore.pl "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2 > errors.txt
エラーは次の場合に起こりえます。
ビューまたは関数の中に非推奨のPostGISオブジェクトを使っているものがある場合。これの訂正には、リストア前にlegacy.sql
スクリプトのロードを試してみることができます。非推奨オブジェクトをまだ持っている版のPostGISにリストアして、コードを作り替えた後に再び移動させることもできます。 legacy.sql
を利用する場合は、非推奨関数を使うのをやめたコードに訂正して、uninstall_legacy.sql
をロードするのを忘れないでください。
ダンプファイル内のspatial_ref_sysにあるカスタムレコードが不正なSRIDになっていることがあります。妥当なSRID値は0より大きく999000より小さくなります。999000から999999の間は内部利用のための予約領域ですが、999999より大きい値は一切使用できません。全ての不正なSRIDを持つ独自レコードは、予約領域に移動しても保持されます。しかし、spatial_ref_sysテーブルから、値が保持されるように設定されているチェック制約が外れます。場合によっては (複数の不正なSRIDが同じ予約領域のSRID値に変換されるとき)、主キーも外れます。
In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see UpdateGeometrySRID), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with:
ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid > 0 AND srid < 999000 );
ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid));
If you are upgrading an old database containing french IGN cartography, you will have probably SRIDs out of range and you will see, when importing your database, issues like this :
WARNING: SRID 310642222 converted to 999175 (in reserved zone)
In this case, you can try following steps : first throw out completely the IGN from the sql which is resulting from postgis_restore.pl. So, after having run :
perl utils/postgis_restore.pl "/somepath/olddb.backup" > olddb.sql
run this command :
grep -v IGNF olddb.sql > olddb-without-IGN.sql
Create then your newdb, activate the required Postgis extensions, and insert properly the french system IGN with : this script After these operations, import your data :
psql -h localhost -p 5432 -U postgres -d newdb -f olddb-without-IGN.sql 2> errors.txt
インストールやアップグレードが思うようにいかない時にチェックすることがいくつかあります。
PostgreSQL 9.5以上をインストールしているか、実行中のPostgreSQLと同じ版のソースでコンパイルしているか、をチェックします。(Linuxの)ディストリビューションによって既にPostgreSQLがインストールされている時や、 PostgreSQLを以前にインストールして忘れた場合に、 混乱が発生することがあります。PostGISはPostgreSQL 9.5以上で動作します。古い版のものを使った場合には、おかしな予想外のエラーメッセージが表示されます。実行中のPostgreSQLの版をチェックするには、psqlを使ってデータベースを接続して、次のクエリを実行して下さい。
SELECT version();
RPMベースのディストリビューションを実行している場合、 プリインストールされたパッケージが存在するかのチェックは、rpm コマンドを使ってrpm -qa | grep postgresqlでチェックできます。
アップグレードに失敗する場合、既にPostGISがインストールされているデータベースにリストアしているか確認して下さい。
SELECT postgis_full_version();
また、コンフィギュアが正しくPostgreSQL、Proj4ライブラリ、GEOSライブラリのインストール先を検出したかチェックして下さい。
コンフィギュアからの出力でpostgis_config.h
ファイルが作られます。POSTGIS_PGSQL_VERSION
、POSTGIS_PROJ_VERSION
およびPOSTGIS_GEOS_VERSION
変数が正しくセットされたかをチェックして下さい。
データのローダとダンパは、PostGISのビルドの一部として、自動的にビルド、インストールされます。手動でビルド、インストールするには、次を実行します。
# cd postgis-3.0.0/loader # make # make install
ローダはshp2pgsql
と呼ばれ、ESRIシェープファイルをPostGIS/PostgreSQLにロードするのに適したSQLに変換します。ダンパはpgsql2shp
と呼ばれ、PostGISのテーブル(またはクエリ)からESRIシェープファイルに変換します。より詳しいドキュメントをご覧になるには、オンラインヘルプとマニュアルページをご覧ください。
3.1. | PostGISでの作業に関するチュートリアル、ガイド、ワークショップはどこにありますか? | |||
OpenGeoが手順ごとのチュートリアルガイドワークショップIntroduction to PostGISを出しています。OpenGeo Suiteでの作業の入門編だけでなく梱包されたデータもあります。PostGISの最善のチュートリアルかも知れません。 BostonGISにもPostGIS almost idiot's guide on getting startedがあります。Windowsユーザに、より軸足を置いています。 | ||||
3.2. | PostGIS 1.5で動作していたアプリケーションやデスクトップツールがPostGIS 2.0では動作しなくなりました。解消するにはどうすればよいでしょうか? | |||
PostGIS 2.0で、多数の非推奨関数がPostGISコードから削除されました。これは、GeoServer, MapServer, QuantumGIS, OpenJump等のサードバーティツールに加えて、アプリケーションにも影響が出ます。これを解決する方法が二つあります。サードパーティアプリケーションの場合は、これらの問題の多くが解決されている最新版にアップグレードしてみることで対応できます。 ご自身のコードの場合は、削除された関数を使わないようにソースを変更することで対応できます。 削除された関数のほとんどは、ST_Unino, ST_Length等のエイリアスで、ST_を取ったものです。最後の手段として | ||||
3.3. | osm2pgsqlを使ってOpenStreetMapデータをロードするときに、failed: ERROR: operator class "gist_geometry_ops" does not exist for access method "gist"というエラーが発生しました。PostGIS 1.5では正しく動作していました。 | |||
PostGIS 2では、デフォルトのジオメトリ演算子クラスがgist_geometry_opsからgist_geometry_ops_2dに変更され、gist_geometry_opsは完全に削除されました。PostGIS 2は3次元対応のためN次元空間インデクスを導入しました。古い名前は混乱させるものであり、誤称であると考えました。 古いアプリケーションには、処理の一部として、テーブルやインデクスを生成する際に、明示的に演算子クラス名を参照しているものがありました。デフォルトの2次元インデクスが欲しい場合には重要ではありません。エラーが内容に管理するために、インデクス生成を次に示す悪い例から良い例に変えて下さい。 悪い例 CREATE INDEX idx_my_table_geom ON my_table USING gist(geom gist_geometry_ops); 良い例 CREATE INDEX idx_my_table_geom ON my_table USING gist(geom); 演算子クラスを指定する必要が出るのは、3次元空間が求められる場合です。次のようにします。 CREATE INDEX idx_my_super3d_geom ON my_super3d USING gist(geom gist_geometry_ops_nd); 不幸にもgist_geometry_opsがハードコーディングされていて変更不可なコンパイルされたコードを突きつけられているなら、PostGIS 2.0.2以上に同梱されている | ||||
3.4. | PostgreSQL 9.0を使っていますが、OpenJump、Safe FME等のツールでジオメトリの読み取りや表示ができなくなってしまいましたが? | |||
PostgreSQL 9.0以上では、byteaデータのデフォルトのエンコーディングがhexに変更されました。古いJDBCドライバはエスケープ形式を仮定しています。古いJDBCドライバを使ったJavaアプリケーションや古いNpgsqlドライバを使った.Netアプリケーションといった、ST_AsBinaryの古い挙動を期待するアプリケーションが影響を受けます。再び動作させるには二つの方法があります。 JDBCドライバを最新のPostgreSQL 9.0版にアップグレードします。http://jdbc.postgresql.org/download.htmlからダウンロードできます。 .Netアプリケーションについては、Npgsql 2.0.11以上を使います。http://pgfoundry.org/frs/?group_id=1000140からダウンロードできます。また、Francisco Figueiredo's NpgSQL 2.0.11 released blog entryに説明があります。 PostgreSQLドライバのアップグレードが選択できないなら、デフォルトで古い挙動をするようにします。次のようにします。 ALTER DATABASE mypostgisdb SET bytea_output='escape'; | ||||
3.5. | pgAdminを使ってジオメトリカラムを表示しようとしたら空っぽでした。何か方法はありませんか? | |||
pgAdminは大きなジオメトリを表示しません。ジオメトリカラムがそうなっていないかを確かめる最善の方法は次の通りです。 -- 全てのgeomカラムに値が入っている場合にはレコードが返りません SELECT somefield FROM mytable WHERE geom IS NULL; -- ジオメトリがどれぐらい大きいかを調べるには -- ジオメトリカラムの中でジオメトリごとに、それが持つポイントの数を -- 尋ねるかたちのクエリを実行します SELECT MAX(ST_NPoints(geom)) FROM sometable; | ||||
3.6. | どの種類のジオメトリオブジェクトを格納できますか? | |||
ポイント、ラインストリング、ポリゴン、マルチポイント、マルチラインストリング、マルチポリゴン、ジオメトリコレクションです。PostGIS 2.0以上では、基本ジオメトリタイプとしてTINと多面体サーフェスも格納できます。これらはOpen GIS Well Known Text形式(XYZ, XYM, XYZM拡張付き)で指定されます。現在サポートされているのは3つのデータ型です。計測に平面座標系を使う標準OGCジオメトリデータ型があります。また、地理座標系を使い、球面または回転楕円体面上の計算を行うジオグラフィデータ型があります。最新のPostGIS空間型群に追加されたのが、ラスタデータの格納と解析に使われるラスタ型です。ラスタ型単独で「よくある質問」を用意しています。詳細についてはChapter 10, PostGISラスタ よくある質問とChapter 9, ラスタ リファレンスをご覧ください。 | ||||
3.7. | たいへん混乱しました。ジオメトリとジオグラフィのどちらを使うべきでしょうか? | |||
短い答: ジオグラフィは長距離の測定をサポートする新しいデータ型ですが、計算速度は現在のところジオメトリの計算より遅いです。ジオグラフィを使う場合は、平面座標系についてあまり多く学習する必要がありません。行うことが距離や長さの計測に限定され、かつ世界中からのデータを持っている場合は、一般的にジオグラフィが最善です。ジオメトリは古いデータ型で、サポートする関数が多く、サードパーティからの多大なサポートが得られます。計算速度も早く、大きなジオメトリでは10倍違います。空間参照系に慣れているか、空間参照系 (SRID)が単一で済むような局所的なデータを扱っているか、あるいは、空間処理を多く行う必要がある場合には、ジオメトリが最善です。ご注意: 簡単に二つの型の相互変換を行ってそれぞれの利点を得ることができます。現在サポートされているもの、サポートされていないものについてはSection 14.11, “PostGIS Function Support Matrix”を参照して下さい。 長い答: Section 4.2.2, “ジオグラフィ型をジオメトリ型にして使用すべき時”とfunction type matrixとを参照して下さい。 | ||||
3.8. | もっとジオグラフィについて聞きたいです。 たとえば、ジオグラフィカラムにデータを入れて合理的な答えが得られる領域範囲はどれぐらいでしょうか、とか。極、全データが半球上になければならないのでしょうか(SQL Server 2008はそう)、速度等の制限はあるのでしょうか、とか。 | |||
その質問は相当深く複雑で、このセクションで十分に答えられません。Section 4.2.3, “ジオグラフィに関する高度なよくある質問”を参照して下さい。 | ||||
3.9. | GISオブジェクトをデータベースに挿入するにはどうしますか? | |||
まず、GISデータを保持するために"geometry"または"geogprahy"カラムを持つテーブルを作成します。ジオグラフィデータ型の格納は、ジオメトリデータ型とは若干異なります。ジオグラフィの格納についてはSection 4.2.1, “ジオグラフィ基礎”を参照して下さい。 ジオメトリについては、psqlでデータベースに接続して、次のSQLを試してみて下さい。 CREATE TABLE gtest (id serial primary key, name varchar(20), geom geometry(LINESTRING)); ジオメトリカラムの追加に失敗する場合は、もしかしたらPostGISの関数とオブジェクトをデータベースにロードしていないか、2.0より前の版のPostGISなのかも知れません。Section 2.5, “ソースからのコンパイルとインストール: 詳細”を参照して下さい。 これで、SQLのINSERTステートメントを使って、ジオメトリをテーブルに挿入することができます。GISオブジェクト自体は、OpenGISコンソーシアムの"well-known text"形式を使っています。 INSERT INTO gtest (ID, NAME, GEOM) VALUES ( 1, 'First Geometry', ST_GeomFromText('LINESTRING(2 3,4 5,6 5,7 8)') ); 他のGISオブジェクトの詳細についてはobject referenceをご覧ください。 テーブル内にあるGISデータを表示するには、次のようにします。 SELECT id, name, ST_AsText(geom) AS geom FROM gtest; 返り値は次のようなかんじになります。 id | name | geom ----+----------------+----------------------------- 1 | First Geometry | LINESTRING(2 3,4 5,6 5,7 8) (1 row) | ||||
3.10. | 空間クエリを作成するにはどうするのですか? | |||
他のデータベースクエリを作るのと同じで、返り値、関数、テストのSQLの組み合わせです。 空間クエリでは、クエリを作成する際に心を平静に保つための重要な二つの問題があります。 一つは、使用することができる空間インデクスがあるか、です。もう一つは、多数のジオメトリを相手に計算量の多い計算を行っているか、です。 一般的に、フィーチャーのバウンディングボックスがインタセクト (交差)しているかをテストするインタセクト演算子 (&&)を使います。&&演算子が便利な理由は、速度向上のために空間インデクスが付けられているなら、&&演算子は空間インデクスを使うからです。これによって、クエリの速度はとてもとても速くなります。 また、検索結果をより狭めるために、Distance(), ST_Intersects(), ST_Contains(), ST_Within() などといった空間関数を使うことでしょう。ほとんどの空間クエリは、インデクスのテストと空間関数のテストを含みます。インデクスのテストで返ってくるタプルを、求める条件に合致するかもしれないタプルのみとして、タプルの数を制限します。それから、空間関数で確実な条件のテストを行います。 SELECT id, the_geom FROM thetable WHERE ST_Contains(the_geom,'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))'); | ||||
3.11. | 大きなテーブルでの空間クエリの速度向上はどうするのですか? | |||
大きなテーブルの速いクエリは、空間データベースのレゾンデートル (トランザクションサポートもそうですが)で、良いインデクスは重要です。
CREATE INDEX [インデクス名] ON [テーブル名] USING GIST ( [ジオメトリカラム] ); "USING GIST"オプションによって、サーバにGiST (Generalized Search Tree)インデクスを作るよう指示が渡ります。
PostgreSQLのクエリプランナがインデクスを作るべきかについて合理的な決定を行うよう、十分な情報を確実に持てるようにすべきです。そのために、ジオメトリテーブル上で"gather statistics"を実行しなければなりません。 PostgreSQL 8.0.x以上では、VACUUM ANALYZEコマンドを実行するだけです。 PostgreSQL 7.4.x以下では、SELECT UPDATE_GEOMETRY_STATS()を実行します。 | ||||
3.12. | なぜPostgreSQLのR木インデクス機能を持たないのですか? | |||
PostGISの、かつての版では、PostgreSQLのR木インデクスを使っていましたが、0.6版でPostgreSQLのR木は完全に捨てて、R-Tree-over-GiSTスキームによる空間インデクスを提供しています。 私たちの試験では、R木とGiSTの検索速度は同程度であることが示されています。PostgreSQLのR木には、GISフィーチャーで使うためには好ましくない二つの制限があります (これらの制限は現在のPostgreSQLネイティブのR木実装についてであって、R木一般の話ではありません)。
| ||||
3.13. | なぜ | |||
OpenGIS関数を使いたくないのでしたら、使う必要はありません。単純にジオメトリカラムをCREATEステートメントで定義する古いやり方で作成して下さい。全てのジオメトリはSRIDが-1になり、OpenGISメタデータテーブルは適切に書き込まれません。これによって、ほとんどのPostGISベースのアプリケーションでは失敗します。一般的には MapServerは | ||||
3.14. | 半径内にあるオブジェクトを全て検索する最善の方法は何ですか? | |||
データベースを最も効果的に使うには、半径検索とバウンディングボックス検索を組み合わせた半径検索を行うのが最も良いです。バウンディングボックス検索で空間インデクスを使用するので、半径検索が適用されるサブセットへのアクセスが早くなります。
たとえば、POINT(1000 1000)から100メートル内の全てのオブジェクトを見つけるためには、次のクエリで動作します。 SELECT * FROM geotable WHERE ST_DWithin(geocolumn, 'POINT(1000 1000)', 100.0); | ||||
3.15. | クエリの一部として投影変換を実現するにはどうしますか? | |||
投影変換を行うには、変換元と変換先双方の座標系がSPATIAL_REF_SYSテーブルに定義されていて、 かつ投影変換されるジオメトリがそのSRIDを持っている必要があります。これが行われていると、投影変換は求める変換先SRIDを参照するのと同じぐらい簡単です。次のクエリは、ジオメトリをNAD 83経度緯度に投影しています。このクエリはthe_geomが-1 (空間参照系が定義されていない)でない場合のみ動作します。 SELECT ST_Transform(the_geom,4269) FROM geotable; | ||||
3.16. | ST_AsEWKTとST_AsTextとを、かなり大きいジオメトリで実行すると、空のフィールドが返りました。どうしたら良いですか? | |||
pgAdminまたは大きなテキストを表示しないその他のツールを使用しているのかも知れません。 ジオメトリが十分に大きい場合、ツールには空として表示されます。本当にWKTで見たり出力したりしなければならない場合は、PSQLを使用して下さい。 -- 本当に空のジオメトリの数を検索します SELECT count(gid) FROM geotable WHERE the_geom IS NULL; | ||||
3.17. | ST_Intersectsを使うと、二つのジオメトリがインタセクトしているのが分かっているのに、インタセクトしていないと言います。どうしたら良いですか? | |||
二つの場合がよくあります。一つは、ジオメトリが不正な場合です。???で確認できます。もう一つは、ST_AsTextで数字を切り捨てていて、表示されている分より後にたくさんの小数が付いている場合です。 | ||||
3.18. | PostGISを用いたソフトウェアをリリースしています。PostGISのようにGPLライセンスを使う必要があるのでしょうか?PostGISを使うとコードを全て公開しなければならないのでしょうか? | |||
ほぼ確実に違います。 例として、Linux上で動作するOracleを考えてみます。 LinuxはGPLでOracleは違いますが、Linuxで動作するOracleはGPLで配布しなければならないでしょうか?違います。あなたのソフトウェアはPostgreSQL/PostGISデータベースを好きなだけ使うことができ、ライセンスは好きなようにできます。 PostGISソースコードに変更を加えて、変更したPostGISを配布したときだけは例外です。この場合、変更したPostGISのコードを共有しなければなりません (PostGIS上で動作するアプリケーションのコードではありません)。この限られた場合でも、ソースコードはバイナリの配布相手にだけ配布します。GPLはソースコードの公開までは求めておらず、バイナリを配布した相手との共有を求めています。 CGALを使った関数とともにPostGISを使ってでも、このことに違いはありません。CGALのライセンスの一つにGPLがありますが、PostGISの全てが既にGPLですので、CGALによってPostGISの元々のライセンスよりも厳しくなることはありません。 |
PostGISでサポートされるGISオブジェクトは、OpenGIS Consortium (OGC)が定義する"Simple Features" のスーパーセットです。 PostGISはOGCの"Simple Features for SQL"仕様で定められた全てのオブジェクトと関数に対応しています。
PostGISは標準から拡張して 3DZ, 3DM, 4次元 (訳注: それぞれXYZ, XYM, XYZM)座標に対応しています。
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はデータベースへの挿入のために空間オブジェクトが生成される時に求められます。
これらの書式の入出力は次のインタフェースを用いて実現できます。
バイト配列 WKB = ST_AsBinary(geometry); テキスト WKT = ST_AsText(geometry); ジオメトリ = ST_GeomFromWKB (bytea WKB、SRID); ジオメトリ = ST_GeometryFromText (テキスト WKT、SRID);
たとえば、OGC空間オブジェクトを生成して挿入する妥当なINSERTステートメントは次の通りです。
INSERT INTO geotable ( the_geom, the_name ) VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');
OGC書式は2次元ジオメトリしかサポートされておらず、また、入出力の表現においてSRIDは*決して*埋め込まれません。
PostGIS拡張書式は現在のところOGC書式のスーパーセットとなっています (全ての妥当なWKB/WKTは妥当なEWKB/EWKTです)。しかし、特にもしOGCがPostGIS拡張と矛盾する新しい書式を出すことがあるなら、これは将来変更されるかも知れません。ゆえにこの機能に頼るべきではありません。
PostGIS EWKB/EWKT では 3DM, 3DZ, 4D の座標サポートが追加され、SRID情報が埋め込まれます。
拡張された空間オブジェクトのテキスト表現 (EWKT)の例は、次の通りです。
POINT(0 0 0) -- XYZ
SRID=32632;POINT(0 0) -- SRID付きXY
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) )
MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4) )
POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )
TRIANGLE ((0 0, 0 9, 9 0, 0 0))
TIN( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )
これらの書式の変換は次のインタフェースを用いて実現できます。
バイト配列 EWKB = ST_AsEWKB(geometry); テキスト EWKT = ST_AsEWKT(geometry); ジオメトリ = ST_GeomFromEWKB(bytea EWKB); ジオメトリ = ST_GeomFromEWKT(text EWKT);
たとえば、PostGISの空間オブジェクトを作成し挿入する妥当なINSERTステートメントは次の通りです。
INSERT INTO geotable ( the_geom, the_name ) VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )
PostgreSQLの「標準的な形式」は単純なクエリ (全く関数呼び出しが無い)で得る表現であり、単純なINSERT, UPDATE, COPYで受け付けられることが保障されるものです。PostGISの"geometory"型の場合は次の通りです。
- 出力 - バイナリ: EWKB ascii: HEXEWKB (EWKBのHEX表現) - 入力 - バイナリ: EWKB ascii: HEXEWKB|EWKT
たとえば、次のステートメントは、標準的なASCII文字列による入出力の処理でEWKTを読み、HEXEWKBを返すものです。
=# SELECT 'SRID=4;POINT(0 0)'::geometry; geometry ---------------------------------------------------- 01010000200400000000000000000000000000000000000000 (1 row)
SQLマルチメディア・アプリケーション空間仕様は、円弧補完曲線を定義したSQL仕様の拡張です。
SQL-MMの定義では、3DM、3DZと4Dの座標を含みますが、SRID情報の埋め込みはできません。
Well-Known Text拡張はまだ完全にはサポートされていません。単純な曲線ジオメトリの例を次に示します。
CIRCULARSTRING(0 0, 1 1, 1 0)
CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)
CIRCULARSTRINGは基本的な曲線型で、線型のLINESTRINGに似ています。一つの辺で、始点、終点 (一つめと三つめ)と弧上の任意の点、の3点が必要です。例外として、始点と終点が同じとなる閉曲線があります。閉曲線では二つ目の点が弧の中心、すなわち円の反対側にならなければなりません。弧の連結では、LINESTRINGと同じように、前の弧の最後の点が次の弧の最初の点となります。よって、妥当なCIRCULARSTRINGは1以上の奇数になります。
COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))
複合曲線は、曲線 (円弧)セグメントと線型セグメントの両方を持つ、単一の連続した曲線です。 よって、要素が的確である必要があることに加え、各要素 (最終要素は除く)の終点は次の要素の始点と同じになる必要があります。
CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1, 1 1))
曲線ポリゴンの中に複合ポリゴンがある例は次の通りです。 CURVEPOLYGON(COMPOUNDCURVE(CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),(4 3, 4 5, 1 4, 0 0)), CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )
CURVEPOLYGONは外環と0以上の内環とを持つ点でPOLYGONと似ています。 異なる点は、環に曲線ストリング、線型ストリング、複合ストリングのいずれも取れる点です。
PostGIS 1.4から、PostGISで曲線ポリゴンで複合曲線をサポートするようになりました。
MULTICURVE((0 0, 5 5),CIRCULARSTRING(4 0, 4 4, 8 4))
MULTICURVEは曲線のコレクションで、線型ストリング、曲線ストリング、複合ストリングを取れます。
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)))
サーフェスのコレクションです。(線型)ポリゴンか曲線ポリゴンを取れます。
![]() | |
SQL-MM実装での全ての浮動小数点数の比較では、所定の丸め誤差があります。現在は1E-8です。 |
ジオグラフィ型は、「地理」座標 (しばしば「測地」座標、"lat/lon"、"lon/lat"、緯度経度, 経度緯度などとも呼ばれます)上で表現された空間フィーチャーのネイティブサポートするためのものです。地理座標は角度の単位 (度)で表現される球面座標です。
PostGISジオメトリ型の基礎は平面です。平面上の二点間の最短コースは直線になります。よって、ジオメトリ上の計算 (面積、距離、長さ、インタセクション等)は、デカルト座標と線型ベクトルを使用することができます。
PostGISのジオグラフィ型の基礎は球面です。球面上での二点間の最短距離は大圏の弧です。よって、ジオグラフィ上の計算 (面積、距離、長さ、インタセクション等)は、球面上で計算しなければならず、複雑な計算が必要となります。より正確な計測のためには、世界の実際の回転楕円体の形を考慮に入れなければならず、非常に複雑です。
基礎となる数学が大変に複雑なので、ジオグラフィ型用に定義された関数は、ジオメトリ型よりも少ないです。時間とともに、新しいアルゴリズムが追加されて、ジオグラフィ型の能力は拡大していくでしょう。
geography
と呼ばれるデータ型を使用します。GEOS関数はgeography
型に対応していません。回避策として、ジオメトリとジオグラフィの型変換を行うことができます。
PostGIS 2.2より前は、ジオグラフィ型はWGS84経度緯度 (SRID:4326)だけに対応していました。PostGIS 2.2以降は、spatial_ref_sys
で定義されている経度緯度ベースの空間参照系の全てが使えます。geography type is not limited to earthの記述にある通り、独自の回転楕円体の空間参照系を追加することもできます。
どの空間参照系を使用しても、計測関数 (ST_Distance, ST_Length, ST_Perimeter, ST_Area)の返り値の単位と、???の入力の単位はメートルです。
ジオグラフィ型はPostgreSQLのtypmod定義書式を使います。ジオグラフィカラムを持つテーブルに1ステップで追加できます。標準OGC書式は曲線を除いてサポートします。
ジオグラフィ型はシンプルフィーチャーの最も簡単なもののみサポートします。標準的なジオメトリ型データで、SRIDが4326の場合は、ジオグラフィに自動でキャストされます。またデータ挿入においてEWKTとEWKBの取り決めを使うこともできます。
POINT: SRID指定なしでの2次元ポイントジオグラフィのテーブル生成は次の通りです。デフォルトは4326 WGS84経度緯度となります。
CREATE TABLE ptgeogwgs(gid serial PRIMARY KEY, geog geography(POINT) );
POINT: NAD83経度緯度での2次元ポイントジオグラフィのテーブル生成は次の通りです。
CREATE TABLE ptgeognad83(gid serial PRIMARY KEY, geog geography(POINT,4269) );
Z値を持ち、明示的にSRIDを指定したポイントのテーブル生成は次の通りです。
CREATE TABLE ptzgeogwgs84(gid serial PRIMARY KEY, geog geography(POINTZ,4326) );
LINESTRING
CREATE TABLE lgeog(gid serial PRIMARY KEY, geog geography(LINESTRING) );
POLYGON
-- ポリゴン NAD 1927経度緯度 CREATE TABLE lgeognad27(gid serial PRIMARY KEY, geog geography(POLYGON,4267) );
MULTIPOINT
MULTILINESTRING
MULTIPOLYGON
GEOMETRYCOLLECTION
ジオグラフィ型のフィールドはgeography_columns
システムビューに登録されます。
"geography_columns"ビューをチェックして、テーブルが一覧にあるか見て下さい。
CREATE TABLEの文法でジオグラフィカラムを持つテーブルを新規に生成できます。
CREATE TABLE global_points ( id SERIAL PRIMARY KEY, name VARCHAR(64), location GEOGRAPHY(POINT,4326) );
locationカラムはジオグラフィ型で、二つの任意修飾子に対応していることにご注意ください。一つは、そのカラムで使用できる形状と次元を限定する型修飾子です。もう一つは、座標参照IDを特定の数に限定するSRID修飾子です。
型修飾子として受け付ける値は、POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGONです。型修飾子は、Z, M, ZMの後置子を付けることで次元制限にも対応します。たとえば、'LINESTRINGM'という型修飾子で、三つ目の次元をMとする3次元のラインストリングのみ受け付けることになります。同じように'POINTZM'で、4次元データを期待します。
SRIDを指定していない場合には、SRIDは4326 WGS84経度緯度が使われ、全ての計算はWGS 84を使って行われます。
テーブルを作ったら、次のようにしてGEOGRAPHY_COLUMNSを見ることができます。
-- メタデータビューの中身を見る SELECT * FROM geography_columns;
ジオメトリカラムを使うのと同じようにテーブルへのデータの挿入ができます。
-- testテーブルにデータを追加する INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)'); INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)'); INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');
ジオメトリと同じ操作でインデックスを作成します。PostGISは、カラム型がジオグラフィであるかを見て、ジオメトリで使われる平面用インデックスの代わりに球面ベースのインデックスを作成します。
-- testテーブルに球面インデックスを作成 CREATE INDEX global_points_gix ON global_points USING GIST ( location );
クエリと計測関数はメートル単位となります。そのため距離パラメータはメートル (面積の場合は平方メートル)単位となります。
-- 距離クエリの表示。ロンドンは1000km範囲外です SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);
ジオグラフィの威力については、シアトルからロンドンまで (LINESTRING(-122.33 47.606, 0.0 51.5))の飛行機がレイキャビク (POINT(-21.96 64.15))に最も近くなるときの距離を求めてみると分かります。
-- ジオグラフィを使った距離計算 (122.2km) SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);
-- ジオメトリを使った計算 (13.3 "度") SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);
異なる経度緯度座標系を試します。spatial_ref_sys
テーブルで挙げられている経度緯度の空間参照系なら全て可能です。
-- NAD83経度緯度 SELECT 'SRID=4269;POINT(-123 34)'::geography; geography ---------------------------------------------------- 0101000020AD1000000000000000C05EC00000000000004140 (1 row)
-- NAD27経度緯度 SELECT 'SRID=4267;POINT(-123 34)'::geography; geography ---------------------------------------------------- 0101000020AB1000000000000000C05EC00000000000004140 (1 row)
-- メートル単位のNAD83 UTM、メートル単位の投影法ですのでエラーが出ます SELECT 'SRID=26910;POINT(-123 34)'::geography; ERROR: Only lon/lat coordinate systems are supported in geography. LINE 1: SELECT 'SRID=26910;POINT(-123 34)'::geography;
ジオグラフィ型は、レイキャビクとシアトル-ロンドン間の飛行機の大圏コースとの間の、球面上での本当に最も近い距離を計算します。
大圏コースマップ ジオメトリ型は、平面の世界地図上にプロットされたレイキャビクとシアトル-ロンドン間の直線とのデカルト距離という意味のない値を出します。結果の名目上の単位は「度」ですが、点間の本当の角度差にあっていませんので、「度」と言うこと自体不正確です。
ジオグラフィ型によって、経度緯度座標でデータを格納できるようになりましたが、ジオグラフィで定義されている関数が、ジオメトリより少ないのと、実行にCPU時間がかかる、というところが犠牲になっています。
選択した型が、期待する領域から出ないことを、ジオメトリ型にして使用する条件とすべきです。使用するデータは地球全体か、大陸か、州か、自治体か?
データが小さいエリア内におさまるなら、適切な投影を選択してジオメトリを使うのが、効率面でも機能面でも最も良い方法です。
データが地球全体か大陸なら、ジオグラフィで投影法の細かい問題を気にせずにシステムを構築できるでしょう。経度/緯度のデータを保存して、ジオグラフィで定義された関数使います。
投影法を理解していなくて、学習したくもなくて、かつ、ジオグラフィで使える関数が限られていることを受け入れるのなら、ジオグラフィを使った方が簡単です。単純にデータを経度/緯度でロードして、そこから進めて下さい。
ジオグラフィとジオメトリ間のサポート状況の比較についてはSection 14.11, “PostGIS Function Support Matrix”をご覧下さい。ジオグラフィ関数の簡潔なリストと説明についてはSection 14.4, “PostGIS Geography Support Functions”をご覧下さい。
4.2.3.1. | 球または回転楕円体のどちらで計算するのでしょうか? |
デフォルトでは、全ての距離と面積の計算は回転楕円体で行います。局所的なエリアでの計算結果と良好な投影を施した平面での結果と比較して下さい。大きなエリアの場合は、回転楕円体計算は、投影平面上でのどの計算よりも精度が高くなります。 全てのジオグラフィ関数には、最後の真偽パラメータを'FALSE'にすると球面を使った計算を行うというオプションがあります。これは、特にジオメトリが非常に単純である場合に計算を速くするためのものです。 | |
4.2.3.2. | 日付変更線や極に関してはどうなっていますか? |
全ての計算に日付変更線や極の概念がありません。座標は球 (経度/緯度)であるので、日付変更線とクロスする形状は、計算の観点からは、他のものと変わりありません。 | |
4.2.3.3. | 処理できる最も長い弧はどうなりますか? |
大圏の弧を2点の「補完線」として使用しています。任意の2点は、実際には2方向につながっていて、どちらの方向に行くかに依存します。PostGISの全てのコードは、大圏コースの2コースのうち*短い*方でつながっていると仮定しています。結果として、180度以上の弧を持つ形状は正しくモデル化されません。 | |
4.2.3.4. | なぜヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか? |
ポリゴンがとんでもなく大きいからです。二つの理由から、大きなエリアは悪いです。一つは、バウンダリボックスが大きいため、どのようなクエリを走らせても、インデックスがフィーチャーを引っ張ってくる傾向にあるためです。もう一つは、頂点数が巨大で、テスト (距離、包含)関数では、少なくとも1回、通常はN (Nは、もう一方のフィーチャーの頂点数)回、頂点を横断しなければならないためです。 ジオメトリでは、大きなポリゴンを持っているけれども小さな範囲のクエリを実行する時、ジオメトリデータ情報を小片に「非正規化」します。これにより、インデックスが効果的にオブジェクトの一部を問い合わせるようになり、またクエリが常にオブジェクト全体を引っ張りこむようなことがないようになります。ST_Subdivideを参照して下さい。ヨーロッパ全体を一つのポリゴンに*格納できる*からといって、*そうすべき*だというわけではありません。 |
OpenGISの「SQL用シンプルフィーチャー仕様」では、標準GISオブジェクト型とこれらを操作するために必要な関数、メタデータテーブルのセットが定義されています。メタデータが一貫性を維持していることを保証するために、空間カラムの生成、消去といった操作はOpenGISで定義されている空間プロシージャを通して実行されます。
OpenGISメタデータテーブルにはSPATIAL_REF_SYS
とGEOMETRY_COLUMNS
の二つがあります。SPATIAL_REF_SYS
テーブルは空間データベースで用いられる座標系の、数字によるIDと文字による説明を持っています。
spatial_ref_sysテーブルは、PostGISに含まれるもので、3000以上の空間参照系と、座標変換/投影変換を行うのに必要な詳細情報との一覧を持つ、OGC準拠のデータベーステーブルです。
PostGISのspatial_ref_sysテーブルには、projライブラリで使われる3000以上の一般に使われる空間参照系定義がありますが、全てを持っているわけではなく、proj4の構築に慣れているならカスタム投影を定義することができます。ほとんどの空間参照系は地域限定のもので、想定されている範囲の外で使うと意味が無いことに注意して下さい。
PostGISのコアセットに入っていない空間参照系を探すための素晴らしい資料がhttp://spatialreference.org/にあります。
よく共通的に使われる空間参照系は次の通りです (訳注: 日本では状況が異なります)。4326 - WGS 84 経度緯度、4269 - NAD 83 経度緯度、3395 - WGS 84 メルカトル図法、2163 - 米国ナショナルアトラス正積図法、NAD83とWGS84のUTM空間参照系 - UTMゾーンは計測に最も理想的なものの一つですが6度 (訳注: 経度)の領域しかカバーしません。
まざまな米国の州の平面空間参照系 (メートルまたはフィート単位) - 通常は州ごとに一つか二つあります。メートル単位のもののほとんどがPostGISのコアセットに入っていますが、多数のフィート単位のものやESRIが作ったものについてはspatialreference.orgから取得して下さい。
対象領域がどのUTMゾーンになるかを決めるには、utmzone PostGIS plpgsql helper functionを参照して下さい。
SPATIAL_REF_SYS
テーブル定義は次の通りです。
CREATE TABLE spatial_ref_sys ( srid INTEGER NOT NULL PRIMARY KEY, auth_name VARCHAR(256), auth_srid INTEGER, srtext VARCHAR(2048), proj4text VARCHAR(2048) )
SPATIAL_REF_SYS
のカラムは次の通りです。
一意に定められた整数値で、データベースで空間参照系 (SRS)を識別するものです。
その参照系の引用元である標準の名前です。たとえば「EPSG」は妥当なAUTH_NAME
です。
AUTH_NAME
で引用される団体によって定義された空間参照系のIDです。EPSGの場合、EPSG投影コードが入ります。
空間参照系の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.opengeospatial.org/をご覧下さい。WKTの一般的な議論については、OpenGISのhttp://www.opengeospatial.org/standardsにある「座標変換サービス実装仕様」をご覧下さい。欧州石油調査グループ(European Petroleum Survey Group, EPSG)とEPSG空間参照系のデータベースに関する情報は、http://www.epsg.org/をご覧下さい。
PostGISは座標変換機能を提供するためにProj4ライブラリを用いています。 PROJ4TEXT
カラムには、特定のSRIDを示すProj4座標定義文字列が入ります。たとえば次のようになります。
+proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=m
詳細情報については、Proj4ウェブサイトhttp://trac.osgeo.org/proj/をご覧下さい。spatial_ref_sys.sql
は、全てのEPSG投影法のためのSRTEXT
とPROJ4TEXT
とを持っています。
GEOMETRY_COLUMNS
は、データベースのシステムカタログから読み取るビューです。構造は次の通りです。
\d geometry_columns
View "public.geometry_columns" Column | Type | Modifiers -------------------+------------------------+----------- f_table_catalog | character varying(256) | f_table_schema | character varying(256) | f_table_name | character varying(256) | f_geometry_column | character varying(256) | coord_dimension | integer | srid | integer | type | character varying(30) |
カラムの意味は次の通りです。
ジオメトリカラムを持つフィーチャーテーブルの完全修飾名。"catalog"および"schema"の語はOracle風であることに注意して下さい。"catalog"に類似するものはPostgreSQLになく、このカラムは空白にされます。"schema"についてはPostgreSQLスキーマ名が使われています (public
がデフォルトです)。
フィーチャーテーブル内のジオメトリカラムの名前。
そのカラムの空間の次元 (2, 3 または 4)。
このテーブルの座標ジオメトリのために使われる空間参照系のID。SPATIAL_REF_SYS
への外部キーになっています。
空間オブジェクトの型。空間カラムを単一型に制限するには、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTIONのうちのいずれかを、また、XYMで使う場合には、LINESTRINGM、POLYGONM、MULTIPOINTM、MULTILINESTRINGM、MULTIPOLYGONM、GEOMETRYCOLLECTIONMのうちのいずれかを使います。複数の型が混合するコレクションの場合は"GEOMETRY"を型とすることができます。
![]() | |
この属性は (おそらく)OpenGIS仕様に入っていませんが、型の同一性を保証するために必要です。 |
空間データを持つテーブルの生成は、1段階でできます。2次元ラインストリングでWGS84経度緯度のジオメトリカラムを持つroadsテーブルの生成の例を次に示します。
CREATE TABLE ROADS (ID serial, ROAD_NAME text, geom geometry(LINESTRING,4326) );
次の、3次元ラインストリングを追加する例で示す通り、標準的なALTER TABLEコマンドを使ってカラムを追加できます。
ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);
これが必要になる事例に、SQLビューとバルクインサートの二つがあります。バルクインサートの場合には、カラムに制約を与えるか、ALTER TABLEを実行することで、geometry_columnsテーブル内の登録を訂正することができます。ビューの場合には、CAST演算を使用します。カラムが型修飾子に基づく場合には、生成処理によって正しく登録されるので、何も行う必要がありません。ジオメトリに適用する空間関数を持たないビューも、基礎となるテーブルのジオメトリカラムと同じように登録されます。
-- 次のようなビューがあるとします CREATE VIEW public.vwmytablemercator AS SELECT gid, ST_Transform(geom, 3395) As geom, f_name FROM public.mytable; -- 正しく登録するには、 -- ジオメトリをキャストします。 -- DROP VIEW public.vwmytablemercator; CREATE VIEW public.vwmytablemercator AS SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name FROM public.mytable; -- ジオメトリタイプが確実に2次元ポリゴンだと知っているなら -- 次のようにできます。 DROP VIEW public.vwmytablemercator; CREATE VIEW public.vwmytablemercator AS SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name FROM public.mytable;
-- 次のように、バルクインサートで派生テーブルを生成したとしましょう SELECT poi.gid, poi.geom, citybounds.city_name INTO myschema.my_special_pois FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom); -- 新しいテーブルに2次元インデックスを作ります CREATE INDEX idx_myschema_myspecialpois_geom_gist ON myschema.my_special_pois USING gist(geom); -- ポイントが3次元ポイントであったり、XYMポイントであったりした場合には、 -- 次のように、2次元インデックスでなくN次元インデックスを作ることになるかも -- 知れません。 CREATE INDEX my_special_pois_geom_gist_nd ON my_special_pois USING gist(geom gist_geometry_ops_nd); -- 新しいテーブルのジオメトリカラムをgeometry_columnsに手動登録するには、 -- 次のようにします。 -- カラムを型修飾子ベースにするために、基礎となるテーブル構造も変更することに -- 注意して下さい。 SELECT populate_geometry_columns('myschema.my_special_pois'::regclass); -- PostGIS 2.0を使っていて、何らかの理由で古い制約をもとにした定義を行う -- (派生テーブルが同じタイプやSRIDを持たないといった場合)ことが必要な場合には、 -- 新しい任意変数use_typemodをfalseにします。 SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false);
古い制約を基にした手法は現在も対応していますが、制約を基にしたジオメトリカラムで直接的にビューで使われている場合は、型修飾子のようには正しくgeometry_columnsに登録されません。次の例では、型修飾子を使ったカラム定義と、制約に基づくカラムの定義とを行っています。
CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326)); SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);
psqlで次を実行します。
\d pois_ny;
型修飾子と制約に基づくのとでは異なった定義になっているのが見えます。
Table "public.pois_ny" Column | Type | Modifiers -----------+-----------------------+------------------------------------------------------ gid | integer | not null default nextval('pois_ny_gid_seq'::regclass) poi_name | text | cat | character varying(20) | geom | geometry(Point,4326) | geom_2160 | geometry | Indexes: "pois_ny_pkey" PRIMARY KEY, btree (gid) Check constraints: "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2) "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text OR geom_2160 IS NULL) "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)
geometry_columnsでは、両方とも正しく登録されています。
SELECT f_table_name, f_geometry_column, srid, type FROM geometry_columns WHERE f_table_name = 'pois_ny';
f_table_name | f_geometry_column | srid | type -------------+-------------------+------+------- pois_ny | geom | 4326 | POINT pois_ny | geom_2160 | 2160 | POINT
しかし、次のようにビューを作ろうとします。
CREATE VIEW vw_pois_ny_parks AS SELECT * FROM pois_ny WHERE cat='park'; SELECT f_table_name, f_geometry_column, srid, type FROM geometry_columns WHERE f_table_name = 'vw_pois_ny_parks';
型修飾子によるgeomのビューカラムは正しく登録されますが、制約に基づくものは正しく登録されません。
f_table_name | f_geometry_column | srid | type ------------------+-------------------+------+---------- vw_pois_ny_parks | geom | 4326 | POINT vw_pois_ny_parks | geom_2160 | 0 | GEOMETRY
これは、将来的にPostGISの版で変更されるかもしれませんが、今のところは、制約に基づくビューカラムを正しく登録させるには、次のようにします。
DROP VIEW vw_pois_ny_parks; CREATE VIEW vw_pois_ny_parks AS SELECT gid, poi_name, cat, geom, geom_2160::geometry(POINT,2160) As geom_2160 FROM pois_ny WHERE cat = 'park'; SELECT f_table_name, f_geometry_column, srid, type FROM geometry_columns WHERE f_table_name = 'vw_pois_ny_parks';
f_table_name | f_geometry_column | srid | type ------------------+-------------------+------+------- vw_pois_ny_parks | geom | 4326 | POINT vw_pois_ny_parks | geom_2160 | 2160 | POINT
PostGISはOpen Geospatial Consortium (OGC)のOpenGIS仕様に準拠しています。多くのPostGISメソッドは、操作対象のジオメトリが単純かつ妥当であることが求められます (正確に言うとそう仮定します)。たとえば、ポリゴンの外に穴があるようなものの面積を計算したり、単純でない境界線を持つポリゴンを作ったりするのは、意味がありません。
OGS仕様に沿うと、単純なジオメトリとは、自己インタセクトや自己接触のような、異常な幾何点を持たないことです。主に0次元または1次元のジオメトリ ([MULTI]POINT, [MULTI]LINESTRING
))に適用します。 他方、ジオメトリの妥当性は、主に2次元ジオメトリ ([MULTI]POLYGON
)に適用し、妥当なポリゴンを特徴づける位置指定子の集合を定義します。個々のジオメトリクラスには、単純性と妥当性をさらに詳細に述べる特定の条件があります。
POINT
は0次元ジオメトリオブジェクトとして常に単純です。
MULTIPOINT
は、二つの座標値 (POINT
)が同じでないなら単純です。
LINESTRING
は、2度同じPOINT
を通らない (終点は除きます。この場合は線型環と呼ばれ、さらに言うと閉じていると思われます)なら単純です。
![]() (a) | ![]() (b) |
![]() (c) | ![]() (d) |
(a)と(c)は単純な |
MULTILINESTRING
は、 全ての要素が単純で、かつ任意の2要素のインタセクトが要素の境界であるPOINT
でだけ発生する場合に限って単純です。
![]() (e) | ![]() (f) | ![]() (g) |
(e)と(f)は単純な |
定義からPOLYGON
は常に単純です。バウンダリ内の環 (外環と内環からなる)のうち二つがクロスしていないなら妥当です。POLYGON
の境界は、POINT
とインタセクトするかも知れませんが、接点にしかなりません (すなわち線上にない)。POLYGON
はカットラインまたはスパイクを持たなくても良く、内環は外環の中に完全に含まれていなければなりません。
![]() (h) | ![]() (i) | ![]() (j) |
![]() (k) | ![]() (l) | ![]() (m) |
(h)と(i)は妥当な |
MULTIPOLYGON
は、全ての要素が妥当で、二つのポリゴン要素について内側がインタセクトしていない場合は妥当です。ポリゴン要素の任意の二つの境界は接触してもよいですが、有限な数のPOINT
でなければなりません。
![]() (n) | ![]() (o) | ![]() (p) |
(n)と(o)は妥当でない |
GEOSライブラリを使って実装されている関数のほとんどは、ジオメトリがOpenGISシンプルフィーチャー仕様で定義されているように妥当であると仮定しています。ジオメトリが単純であるか、また妥当であるか、のチェックとしてST_IsSimple()とST_IsValid()が使えます。
-- 一般的に、線フィーチャーの妥当性のチェックは -- 常にTRUEを返すので意味がありません -- しかし、この例では、PostGISがOGCのIsValidの定義を拡張して -- *一意な頂点*が2より少ないラインストリングについてFALSEを -- 返すようにしています gisdb=# SELECT ST_IsValid('LINESTRING(0 0, 1 1)'), ST_IsValid('LINESTRING(0 0, 0 0, 0 0)'); st_isvalid | st_isvalid ------------+----------- t | f
デフォルトでは、PostGISはジオメトリ入力に関するこの妥当性チェックを適用しません。複雑なジオメトリの妥当性のチェックはCPU時間を多く必要とするためです。データソースが信用できない場合は、手動でこのチェックを強制するための制約を付けることができます。
ALTER TABLE mytable ADD CONSTRAINT geometry_valid_check CHECK (ST_IsValid(the_geom));
妥当な入力ジオメトリでPostGIS関数を呼んだのに「GEOS Intersection()がエラーを投げました!」というようなエラーメッセージに遭遇したなら、PostGISまたは使用しているライブラリの中のエラーを発見しました。PostGIS開発者に連絡するべきです。PostGIS関数が妥当である入力ジオメトリから妥当でないジオメトリが返る場合も同じです。
![]() | |
厳格にOGCジオメトリに準拠すると、Z値やM値を持てません。ST_IsValid()は高次を考慮に入れません。AddGeometryColumn()を実行するとジオメトリの次元をチェックする制約が加わるので、そこで2を指定すれば十分です。 |
代表的な空間述語 (???, ???, ???, ???, ...)は、求められる空間フィルタを適切に提供するには十分でないことが時々あります。
![]() たとえば、道路網を表現する線型のデータセットがあるとします。ビジネスルールを無視しているかも知れませんが、点で交差するだけでなく線上で交差する道路区間を全て判別することがGIS解析者の仕事となるかも知れません。この場合、 ???では重要な空間フィルタとして十分ではありません。線型のフィーチャーでは、点でクロス (訳注: インタセクトより厳しい条件です)している場合のみ 空間的にインタセクトしている (???)と判別された二つの区間の組み合わせについて、実際のインタセクト (ST_Intersection)を取り、 インタセクトのST_GeometryTypeが'' よりエレガントかつ速い解法が本当に望ましいでしょう。 |
![]() 二つ目の[理論的な]例として、GIS解析者が全ての湖の境界に線でインタセクトする波止場やドックの全ての位置を特定しようとするとします。ここで、波止場の一端だけ陸にあるとします。言いかえると、波止場が湖の中にあるが完全に中に入りきってはいなくて、湖と線でインタセクトして、波止場の一方の端が完全に湖に入っていて、かつもう一方の端点が境界線上にあります。解析者は空間述語の組み合わせで、非常に望まれるフィーチャーを引き出す必要があるかも知れません。
|
ここで、Dimensionally Extended 9 Intersection Mode、略してDE-9IMを見てみましょう。
OpenGIS Simple Features Implementation Specification for SQLによると「二つのジオメトリの比較の基本的なアプローチは、二つのジオメトリの内部、境界、外部のインタセクションの比較と、『インタセクション行列』の要素に基づく2ジオメトリの関係の分類です」。
ジオメトリの境界は一つ低い次元のジオメトリの集合です。0次元のPOINT
の境界は空集合です。LINESTRING
の境界は二つの端点です。 POLYGON
の境界は外環と内環を形成する線です。
ジオメトリの内部は境界を取り去った際に残るジオメトリです。POINT
の内部はPOINT
自身です。LINESTRING
の内部は二つの端点の間の実際の点の集合です。POLYGON
の内部はポリゴンの内側の範囲であるサーフェスです。
ジオメトリの外部は、内部と境界を除いた全領域のサーフェスです。
ジオメトリaがあり、aの内部、境界、外部をそれぞれI(a)、B(a)、E(a)とします。数学的な行列表現は次のようになります。
内部 (Interior) | 境界 (Boundary) | 外部 (Exterior) | |
---|---|---|---|
内部 (Interior) | dim( I(a) ∩ I(b) ) | dim( I(a) ∩ B(b) ) | dim( I(a) ∩ E(b) ) |
境界 (Boundary) | dim( B(a) ∩ I(b) ) | dim( B(a) ∩ B(b) ) | dim( B(a) ∩ E(b) ) |
外部 (Exterior) | dim( E(a) ∩ I(b) ) | dim( E(a) ∩ B(b) ) | dim( E(a) ∩ E(b) ) |
ここで、dim(a)はaの次元で、ST_Dimensionで規定されますが、{0,1,2,T,F,*}の値域を持ちます。
0
=> 点
1
=> 線
2
=> 面
T
=> {0,1,2}
F
=> 空集合
*
=> 何でも良い
二つのオーバラップするポリゴンについて可視化すると、次のようになります。
| ||||||||||||||||||
|
|
左から右、上から下に読むと、次元行列は'212101212'と表現されます。
一つ目の例である、2線が線上でインタセクトする場合の関係行列は'1*1***1**'となります。
-- 線上でクロスする道路区間の判別 SELECT a.id FROM roads a, roads b WHERE a.id != b.id AND a.geom && b.geom AND ST_Relate(a.geom, b.geom, '1*1***1**');
二つ目の例である、一部が湖の水涯線上にある波止場についての関係行列は'102101FF2'となります。
-- 一部が湖の水涯線上にある波止場の判別 SELECT a.lake_id, b.wharf_id FROM lakes a, wharfs b WHERE a.geom && b.geom AND ST_Relate(a.geom, b.geom, '102101FF2');
詳細情報ついては、次のページをご覧ください。
OpenGIS Simple Features Implementation Specification for SQL (1.1版, 2.1.13.2節)
Hui XiongさんによるEncyclopedia of GIS
空間テーブルを作成したら、これでGISデータをデータベースにアップロードする準備ができたことになります。現在、PostGIS/PostgreSQLデータベースにデータをロードするには、SQLステートメントを使う、またはシェープファイルのローダ/ダンパを使う、二つの方法があります。
データをテキスト表現に変換できるなら、フォーマットされたSQLを使うのがデータをPostGISに入れる最も簡単な方法です。Oracleや他のSQLデータベースを使うように、SQL端末モニタにSQLの"INSERT"ステートメントで一杯になった大きなテキストファイルをパイプで送ることで、大量のデータをロードできます。
データアップロードファイル (たとえばroads.sql
)は次のようになるでしょう。
BEGIN; INSERT INTO roads (road_id, roads_geom, road_name) VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd'); INSERT INTO roads (road_id, roads_geom, road_name) VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd'); INSERT INTO roads (road_id, roads_geom, road_name) VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St'); INSERT INTO roads (road_id, roads_geom, road_name) VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave'); INSERT INTO roads (road_id, roads_geom, road_name) VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce'); INSERT INTO roads (road_id, roads_geom, road_name) VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres'); COMMIT;
データファイルは、次に示す"psql"というSQL端末モニタを使って、簡単にPostgreSQLにパイプで送ることができます。
psql -d [データベース名] -f roads.sql
shp2pgsql
データローダは、ESRIシェープファイルをPostGIS/PostgreSQLデータベースに、ジオメトリまたはジオグラフィとして挿入するための適切なSQLに変換します。ローダには、次に示すコマンドラインフラグによって区別される、いくつかの操作モードがあります。
また、コマンドラインローダのほとんどのオプションに対応するshp2pgsql-gui
グラフィカルユーザインタフェースがあります。一度限りのロードしか行わずスクリプト化しない場合やPostGISに不慣れな方にとって便利になるかもしれません。これはpgAdminIIIのプラグインとして構築することもできます。
新しいテーブルの作成とシェープファイルからのデータの読み込みを行います。これがデフォルトモードです。
シェープファイルからデータベーステーブルにデータを追加します。複数のファイルをロードするためにこのオプションを使う場合は、これらのファイルは同じ属性と同じデータ型を持つ必要があります。
シェープファイルにあるデータを持つ新しいテーブルを作成する前にデータベーステーブルを削除します。
テーブル作成のSQLコードを生成するだけで、実際のデータは追加しません。このモードは、テーブル作成とデータロードとを完全に分けたい場合に使用します。
ヘルプ画面を表示します。
出力データにPostgreSQLのダンプ書式を用います。このモードは-a, -c, -dと組み合わせて利用します。デフォルトの"insert"によるSQL書式よりも、大変早くロードできます。大きなデータセットではこちらを使用して下さい。
指定したSRIDでジオメトリデーブルの作成とデータの読み込みを行います。 入力シェープファイルが使っているFROM_SRIDの指定が可能で、この場合は対象SRIDに投影変換を行います。FROM_SRIDは-Dと一緒には指定できません。
識別子 (カラム、スキーマおよび属性)の大文字小文字を保持します。シェープファイルの属性は全て大文字であることに注意して下さい。
全ての整数を標準の32ビット整数に強制します。DBFヘッダではそれが正当であったとしても、64ビットのbigintを生成しません。
ジオメトリカラムにGiSTインデックスを生成します。
-m a_file_name
で、長いカラム名を10文字のDBFカラム名に対応付けるファイルを指定します。ファイルは、1以上の行を持ちます。各行は空白区切りで二つの名前を持ち、行頭行末に空白を入れません。例を次に示します。
COLUMNNAME DBFFIELD1 AVERYLONGCOLUMNNAME DBFFIELD2
マルチ系ジオメトリの替りに単一ジオメトリを生成します。全てのジオメトリが実際に単一である (たとえば単一の外環でなるMULTIPOLYGONや単一の頂点でなるMULTIPOINT)場合にのみ成功します。
出力ジオメトリが特定の次元を持つよう強制します。次元は、2D, 3DZ, 3DM, 4Dの文字列を使います。
入力の次元が出力より小さい場合には、出力では0が入ります。入力の次元が大きい場合には、外されます。
出力書式をWKBでなくWKTにします。精度が低下して、座標変動が発生しうることに注意が必要です。
トランザクションを使わずに、ステートメントごとに実行するようにします。エラーの元となる不良なジオメトリがいくつか含んでいる時に、大半の良好なデータのロードが可能にするものです。ダンプ書式ではトランザクションを常に使うので、-Dフラグを指定している場合には使えません。
入力データ (dbfファイル)のエンコーディングを指定します。全てのdbfの属性は指定されたエンコーディングからUTF8に変換されます。SQL出力結果には SET CLIENT_ENCODING to UTF8
が含まれるようになり、バックエンドはUTF-8からデータベースが内部利用のために設定したエンコーディングに再変換できます。
NULLジオメトリ操作方針(insert*=挿入, skip=スキップ, abort=強制終了)を選択します。
DBFファイルのみインポートします。対応するシェープファイルを持っていない場合、 自動的にこのモードになり、DBFファイルのみロードします。 このフラグは、完全なシェープファイル群を持っていて、属性データだけが欲しくてジオメトリが欲しくない時のみ使用します。
ジオメトリ型のかわりに、ジオグラフィ型で、WGS84経度緯度 (SRID=4326)を使用します (経度緯度データが必要です)。
新しいテーブルのテーブル空間を指定します。 -Xパラメータが使われない場合には、インデックスはデフォルトのテーブル空間を使用します。PostgreSQL文書には、テーブル空間を用いるべき時に関する良い文書があります。
新しいテーブルのインデックスで使われるテーブル空間を指定します。 主キーインデックスに適用され、-Iが合わせて使われている場合にはGiST空間インデックスにも適用されます。
ローダを使って入力ファイルを生成してアップロードするセッション例は次の通りです。
# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable > roads.sql # psql -d roadsdb -f roads.sql
変換とアップロードはUNIXのパイプを使うと一回で実行できます。
# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb
データは、SQLまたはシェープファイルローダ/ダンパを使ってデータベースから抜き出すことができます。SQLに関する節において、空間テーブルでの比較とクエリを行うために用いることができる演算子のいくつかを議論します。
データベースからデータを引き出す最も直接的な手段は、次のように、SQLのSELECTクエリを使って返ってくるレコードとカラムの数を減らし、結果のカラムを可読テキストファイルにダンプするやり方です。
db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads; road_id | geom | road_name --------+-----------------------------------------+----------- 1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd 2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd 3 | LINESTRING(192783 228138,192612 229814) | Paul St 4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave 5 | LINESTRING(190131 224148,190871 228134) | Phil Tce 6 | LINESTRING(198231 263418,198213 268322) | Dave Cres 7 | LINESTRING(218421 284121,224123 241231) | Chris Way (6 rows)
しかし、返ってくる結果の数を削るために、なんらかの制限をかけることが重要となるときがあるでしょう。属性ベースの制限の場合、非空間テーブルで使う通常の文法と同じSQLを使うだけです。空間ベースの制限の場合、次の演算子が使用可能であり、便利です。
この関数は、二つのジオメトリが空間を共有しているかどうかをテストします。
この関数で、二つのジオメトリが幾何的に同一であるかを見ることができます。たとえば、'POLYGON((0 0,1 1,1 0,0 0))' は 'POLYGON((0 0,1 1,1 0,0 0))' と同じかを見ることができます (これは同じとなります)。
ご注意: PostGIS 2.4より前では、これはジオメトリのボックスでの比較でした。
次に、これらの演算子をクエリで使うことができます。SQLコマンドラインからジオメトリとボックスの指定を行うときは、明示的に文字列表現をジオメトリに変換しなければならないことに注意して下さい。たとえば、次のようになります。ただし312は架空の空間参照系番号で、ここでのデータに合致しています。
SELECT road_id, road_name FROM roads WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;
上のクエリは"ROADS_GEOM"テーブルから、その値と等価である単一のレコードを返します。
道路がポリゴンで定義した面を通過するかどうかをチェックするには次のようにします。
SELECT road_id, road_name FROM roads WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');
最も一般的な空間クエリは「フレームベース」のクエリでしょう。これは、表示するためのデータの価値のある「マップフレーム」を取得するために、データブラウザやウェブマッパのようなクライアントソフトウェアに使われます。
"&&"演算子を使うとき、比較フィーチャーをBOX3DかGEOMETRYかに指定することができます。ただし、GEOMETRYを指定すると、それのバウンディングボックスが比較に使われます。
次に示すクエリのように、フレームにBOX3Dオブジェクトを使います。
SELECT ST_AsText(roads_geom) AS geom FROM roads WHERE roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);
エンベロープの投影を指定するためにSRID 312を使っていることに注意して下さい。
pgsql2shp
テーブルダンパは、データベースに直接接続して、テーブル (あるいはクエリによって定義されたもの)をシェープファイルに変換するものです。基本的な文法は次の通りです。
pgsql2shp [<オプション>] <database> [<スキーマ>.]<table>
pgsql2shp [<オプション>] <データベース> <クエリ>
コマンドラインオプションは次の通りです。
特定のファイル名に出力を書きこみます。
接続先データベースのホスト名。
接続先データベースのポート。
データベースに接続するためのパスワード。
データベースに接続する際のユーザ名。
複数のジオメトリカラムを持つテーブルの場合の、シェープファイルの出力に使用するジオメトリカラム。
バイナリカーソルを使います。これは、実行時間を短くしますが、テーブルの非ジオメトリ属性がテキストへのキャストを持っていない場合には、動作しません。
Rawモード。gid
フィールドを落としたり、カラム名をエスケープしてはいけません。
ファイル名
識別名を10文字名に再割り当てします。 ファイルの中身は、一つの空白で区切られ、前と後に空白が無い二つのシンボルの行からなります。VERYLONGSYMBOL SHORTONE ANOTHERVERYLONGSYMBOL SHORTER等となります。
インデックスは大きなデータセットを持つ空間データベースの利用を可能にするものです。インデックスなしでは、地物の検索でデータベースの全レコードを「シーケンシャルスキャン」する必要があります。インデックスをつけることで、データを検索木に組織化して、特定のレコードを発見するための検索をより早くすることができます。 PostgreSQLは、B木、SP-GiST、GiSTの3種類のインデックスにデフォルトで対応しています。
B木は、数字、文字、日付といった、一つの軸に沿ってソートできるデータに使用します。 空間データは空間充填曲線、Z階数曲線またはヒルベルト曲線に沿ってソートされます。しかし、この表現は一般的な演算子の速度向上を許しません。
GiST (Generalized Search Trees)インデックスはデータを「一方へのもの」 (訳注: 「左側にあるもの」「上側にあるもの」など)、「オーバラップするもの」、「中にあるもの」に分割して、GISデータを含む幅広いデータ型で使えるようにしたものです。PostGISではGISデータにインデックスを付けるためにGiSTの上でR木インデックス実装を使用しています。
GiSTは「汎用的な検索木 (Generalized Search Tree)」の意味で、インデックスの一般化された形式です。GISインデックスに加えて、GiSTは通常のB木インデックスに従わない全ての種類の不規則なデータ構造 (整数配列, スペクトラルデータ等)の検索速度を向上させるために使います。
ひとたびGISデータテーブルが数千行を超えたら、空間検索の速度向上のためインデックスを構築したくなるでしょう (これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。
GiSTインデックスをジオメトリカラムに追加するための文は次の通りです。
CREATE INDEX [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム名] );
上の文では常に2次元インデックスを構築します。n次元インデックスをジオメトリ型で使うには、次の文でインデックスを生成できます。
CREATE INDEX [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム名] gist_geometry_ops_nd);
空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムではより遅いCONCURRENTLYを選択するかも知れません。次のようにします。
CREATE INDEX CONCURRENTLY [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム名] );
インデックス構築後に、時々PostgreSQLにテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。
VACUUM ANALYZE [テーブル名] [(カラム名)];
BRINは"Block Range Index"のことで、PostgreSQL 9.5で導入された一般性のあるインデックスの形式です。BRINは不可逆インデックスで、主に読み取り効率と書き込み効率とを妥協させるために使われます。主要な目標は、非常に大きなテーブルの取り扱いで、そのテーブルのために、テーブル内の物理的な位置との自然な相関があるカラムを一部に持ちます。GISインデックスだけでなく、BRINは規則的だったりそうでない多種多様なデータ構造 (整数、配列等)における検索速度の向上のために使われます。
ひとたびGISデータテーブルが数千行を超えたら、空間検索の速度向上のためインデックスを構築したくなるでしょう (これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。GiSTインデックスは、サイズがデータベースに割り当てられているRAM容量を超えずに、ストレージサイズが十分であり、かつ書き込みワークロードのペナルティに余裕がある限りは、本当に高性能です。その他の場合にはBRINインデックスが他の選択肢として考えられます。
BRINインデックスの原理は、テーブルブロックの集合の全ての行に含まれる全てのジオメトリを余すところなく取り込んだバウンディングボックスだけを格納することです。明らかに、このインデックス手法は、ブロックレンジの結果バウンディングボックスが相互に排他的になるように、データが物理的に並ぶ場合にだけ効率が良くなります。結果インデックスは本当に小さいのですが、多くの場合で、GiSTインデックスより効率が落ちます。
BRINインデックスの構築はGiSTインデックスの構築より少ない資源集約で済みます。BRINインデックスがGiSTインデックスが求めるよりも十分の一以下であるのが本当に一般的です。BRINインデックスは、多数のテーブルブロックに対して一つのバウンディングボックスを格納するだけなので、この手の他のインデックスよりもディスク使用量が数千分の一程度で済むのが一般的です。
レンジ内で要約するブロック数を選択できます。この数字を減らすと、インデックスは大きくなりますが、効率向上の助けになる可能性があります。
BRINインデックスを「ジオメトリ」カラムに追加するための文は次の通りです。
CREATE INDEX [インデックス名] ON [テーブル名] USING BRIN ( [ジオメトリカラム名] );
上の文では常に2次元インデックスを構築します。3次元インデックスは次の文で生成できます。
CREATE INDEX [インデックス名] ON [テーブル名] USING BRIN ( [ジオメトリカラム名] brin_geometry_inclusion_ops_3d);
また、4次元演算子クラスを使う4次元インデックスを使うこともできます。
CREATE INDEX [インデックス名] ON [テーブル名] USING BRIN ( [ジオメトリカラム名] brin_geometry_inclusion_ops_4d);
上の書式では、デフォルトの数値やレンジ内ブロック数を使っていますが、値は128です。ブロック数を指定するには、レンジ内の要約をすることになります。次の文のようにして作ります。
CREATE INDEX [インデックス名] ON [テーブル名] USING BRIN ( [ジオメトリカラム名] ) WITH (pages_per_range = [数字]);
また、BRINインデックスは、多数の行で一つのインデックス値を格納することを心に留めておいて下さい。テーブルに違う次元のジオメトリを格納する場合には、インデックスの効率が悪くなります。この効率欠落を回避するには、格納したジオメトリの次元数の最小値となる演算子クラスを選択します。
「ジオグラフィ」型もまたBRINインデックスに対応しています。BRINインデックスを「ジオグラフィ」カラムに構築するための文は次の通りです。
CREATE INDEX [インデックス名] ON [テーブル名] USING BRIN ( [ジオグラフィカラム名] );
上の書式では常に回転楕円対面上の地理空間オブジェクトの2次元インデックスを構築します。
現在のところは「包括対応」だけをここで考えています。これは、&&
、~
と@
演算子だけが2次元の場合に使われることを意味します (「ジオメトリ」「ジオグラフィ」の両方)。&&&
演算子は3次元ジオメトリで使えます。しばらくはKNN検索に対応しません。
SP-GiSTは、「空間分割された一般探索木」を表します。四分木、k次元木、基数木 (トライ木)のような分割探索木に対応するインデックスの総称的な形式です。このデータ構造の一般的な機能は、検索空間を反復して分割することですが、分割は等しいサイズである必要はありません。SP-GiSTは、GISインデックスだけでなく、電話回線のルーティングや、IPルーティング、部分文字列検索等といった、様々な種類のデータを探索する速度の向上に使われます。
GiSTインデックスのためのケースですので、空間オブジェクトを覆うバウンディングボックスを保存するという意味で、SP-GiSTインデックスは不可逆です。SP-GiSTインデックスは、GiSTインデックスの選択肢の一つとして考えることができます。能率試験によって、SP-GiSTインデックスは,、多数のオーバラップするオブジェクトがある「スパゲッティデータ」と呼ばれる状態のときに、特に有利であることが分かりました。
一度GISデータテーブルが数千行を超えると、データの空間探索の速度向上にSP-GiSTインデックスを使うと良いかも知れません。「ジオメトリ」カラムにSP-GiSTインデックスを構築するための文は次の通りです。
CREATE INDEX [インデックス名] ON [テーブル名] USING SPGIST ( [ジオメトリカラム] );
上の文では、2次元インデックスを構築します。ジオメトリ型の3次元インデックスは、次のように、3次元演算子クラスを使用して生成します。
CREATE INDEX [インデックス名] ON [テーブル名] USING SPGIST ([ジオメトリカラム] spgist_geometry_ops_3d);
空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムでは、より遅いCONCURRENTLYを選択するかも知れません。次のようにします。
CREATE INDEX CONCURRENTLY [インデックス名] ON [テーブル名] USING SPGIST ( [ジオメトリカラム] );
インデックス構築後に、時々PostgreSQLにテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。
VACUUM ANALYZE [テーブル名] [(カラム名)];
SP-GiSTインデックスは次の演算子を含むクエリの実行速度を向上させられます。
2次元インデックスについては <<, &<, &>, >>, <<|, &<|, |&>, |>>, &&, @>, <@, and ~= 。
3次元インデックスについては &/&, ~==, @>>, and <<@ 。
現時点ではkNN探索に対応していません。
通常、インデックスは見えないところでデータアクセスの速度向上を行います。すなわち、ひとたびインデックスが構築されたら、クエリプランナは透過的に、クエリプランの速度を向上させるためにインデックス情報を使うべき時を判断します。残念なことに、PostgreSQLクエリプランナは、GiSTインデックスの使用について十分に最適化できず、時々、検索で空間インデックスを使用すべきなのに、テーブル全体を順に走査することがあります。
空間インデックスが使用されていない (または属性インデックスがその問題のために使用されていない)場合、次の二つのことができます。
まず、クエリプランを読んで、クエリが実際に必要な計算をしようとしているか確認します。JOIN条件を忘れていたり、間違ったテーブルに付けていたりすることで、暴走することがあり、予期せずに何度もテーブル全体を得ることになります。クエリプランを取得するには、クエリの前にEXPLAINキーワードを追加します。
次に、テーブル内の値の数量と分布に関する統計情報を収集するとともに、クエリプランナにインデックス使用にかかる意思決定のための、より良い情報を与えるようにします。VACUUM ANALYZEは両方を計算します。
データベースに対する定期的なvacuumは常に実行するべきです。多くのPostgreSQLデータベースエージェントは、閑散時のcronジョブとして定期的にVACUUMを実行します。
vacuumが働かないなら、set enable_seqscan to off;コマンドで、一時的にプランナに対してインデックス情報の使用を強制することができます。この方法で、プランナがインデックスを使用するプランを生成できるかどうか確認できます。このコマンドはデバッグにのみ使用すべきです。一般的に言うと、プランナはあなたよりインデックスを使うべき時を知っています。クエリを実行したら、ENABLE_SEQSCAN
設定を戻して、他のクエリでは通常通りプランナを使用します。
もし、set enable_seqscan to off;がクエリの実行に役立っているなら、お使いのPostgreSQLはハードウェアにあわせた調整をしていないようです。順に走査する際のコストとインデックスを使う際のコストとを比較してプランナが間違っていることに気付いたら、postgresql.confでrandom_page_cost
の値を減らしてみるか、set random_page_cost to 1.1;を使ってみてください。このパラメータのデフォルト値は4ですが、それを1 (SSDの場合)または2 (高速磁気ディスクの場合)にして下さい。値を減らすことで、プランナがよりインデックススキャンを行う傾向になります。
set enable_seqscan to off;がクエリの役に立たない場合には、PostgreSQLがまだ解決できない構文を使ってしまっているのかもしれません。インラインSELECTのサブクエリが一つの例です。プランナが最適化できるように書き直す必要があります。LATERAL JOINと呼びます。
空間データベース機能のレゾンデートルは、通常はデスクトップGISに求める機能を、データベース内部のクエリで実現してすることです。PostGISを効果的に使用するには、どの空間関数が有効かを知り、また、良好なパフォーマンスを提供する所に適切にインデックスがあることが保証されていることが求められます。なお、本例ではSRID 312を使っていますが、これは純粋に例として出しているだけです。spatial_ref_sysテーブルにあり、データの投影法に合致している、本当のSRIDを使ってください。空間参照系を持たないデータについては、なぜ持っていないのか、持つべきなのかも知れないのか、をじっくり*考えてください*。 たとえば分子内部や火星旅行の到達位置といった、定義された空間参照系を持たない場合には、単にSRIDを無視するか、一つ作成してspatial_ref_sys
テーブルに追加して下さい。
分子の内部構造や開発前の遊園地の間取り図といった、空間参照系を持たないものを扱うためだったら、問題ありません。ただし、遊園地の位置が決まっている場合だと、遊園地が既存構造の上に入り込まないようにするためだけでも、その位置に適切な平面座標系を使うようにします。
核戦争時に人類を輸送するための火星遠征を計画し、火星居住用の地図を作成する場合であったとしても、Mars 2000といった地球以外の座標系を作成し、spatial_ref_sys
に挿入して使うことができます。この火星座標系は非平面 (回転楕円体面の度)ですが、ジオグラフィ型で長さや、計測近似値を、度単位でなくメートル単位で得ることができます。
クエリを作成するとき、&&のようなバウンディングボックスを基準とした演算子によってのみGiST空間インデックスの利点が出てくることだけは覚えておくことが重要です。ST_Distance()
のような関数では演算の最適化を行うためにインデックスを使うことができません。たとえば、次のクエリでは、大きなテーブルでは本当に遅くなります。
SELECT the_geom FROM geom_table WHERE ST_Distance(the_geom, 'SRID=312;POINT(100000 200000)') < 100
このクエリは、geom_tableにおける (100000, 200000)の点から距離が100単位以内にある全てのジオメトリを選択します。このクエリは、テーブル内にあるそれぞれの点と指定した点との距離を計算する、すなわち、それぞれの行で一つのST_Distance()
計算を行うため、遅くなります。1ステップでインデックスを利用するST_DWithin関数を使って、求められる距離計算の量を減らすことで回避できます。次のようにします。
SELECT the_geom FROM geom_table WHERE ST_DWithin(the_geom, 'SRID=312;POINT(100000 200000)', 100)
このクエリは、同じジオメトリを選択しますが、より効果的な方法で行われます。the_geomにGiSTインデックスがあると仮定すると、クエリプランナはST_Distance()
関数の結果を計算する前にインデックスを使って行を減らせると認識します。 &&演算子で使われるST_MakeEnvelope
ジオメトリは、元のポイントに中央寄せした200単位の正方形です。これは「クエリボックス」です。&&演算子は、結果セットを「クエリボックス」にオーバラップするバウンディングボックスを持つジオメトリだけに素早く減らすためにインデックスを使います。「クエリボックス」がジオメトリテーブル全体の範囲より十分に小さいと仮定すると、行われなければならない距離計算の量は劇的に減少します。
本節の例では、線型の道、ポリゴンの自治体境界、の二つのテーブルを使います。テーブルの定義をしまします。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)
raster2pgsql
ラスタローダを使ってPostGISラスタを既存のラスタファイルからロードするのは、最もよく行われます。
raster2pgsql
は、GDALがサポートするラスタ書式をPostGISラスタテーブルにロードするのに適切なSQLにするバイナリファイルです。ラスタのオーバビューの生成だけでなく、ラスタファイルのフォルダのロードも可能です。
raster2pgsqlは、ほとんどの場合、PostGISの一部としてコンパイルされます (GDALライブラリをコンパイルしている場合)が、バイナリファイルによってサポートされるラスタタイプは、GDALでコンパイルされたのと同じです。raster2pgsqlがサポートするラスタタイプの一覧を得るには、-G
スイッチを使います。この一覧は、インストールした PostGIS が提供するST_GDALDriversと同じになるはずです。
![]() | |
このツールの古い版では、Pythonスクリプトでした。実行ファイルに置き換えられています。Pythonスクリプトが必要な場合は、 GDAL PostGIS Raster Driver Usageに、Pythonの例があります。raster2pgsqlのPythonスクリプトは、今後のPostGIS rasterでは動作しないかも知れませんし、サポートされませんので、ご注意ください。 |
![]() | |
同じアラインメントを持つラスタの集合から特定の要素のオーバビューを生成する時、オーバビューが同じアラインメントを持たないことがあります。オーバビューが同じアラインメントを持たない例についてはhttp://trac.osgeo.org/postgis/ticket/1764をご覧下さい。 |
使用例:
raster2pgsqlraster_options_go_here
raster_file
someschema
.sometable
> out.sql
ヘルプを表示します。引数を全く指定しない場合にも表示されます。
サポートされているラスタ書式を印字します。
新しいテーブルを生成し、ラスタを入れます。これがデフォルトモードです。
既存のテーブルにラスタを追加します。
テーブルを削除し、新しいテーブルを生成し、ラスタを入れます。
準備モード、テーブルを作るだけです。
SRIDやピクセルサイズ等のラスタ制約を適用して、raster_columns
ビューで適切な登録ができるようにします。
制約の最大範囲を無効にします。-Cフラグが使われている場合のみ適用されます。
正規ブロック制約 (空間的に一意で網羅タイル)を適用します。-Cフラグが使用されている場合のみ適用されます。
出力ラスタを指定されたSRIDにします。 指定しないか0を指定した場合、ラスタのメタデータに対して、適切なSRIDを決定するためのチェックを行います。
ラスタから抽出するバンドのインデクス (1始まり)。1より多いバンドを抽出するには、コンマ(,)で区切ります。指定しない場合、全てのバンドが抽出されます。
行毎に挿入するラスタを切断します。TILE_SIZE
は、「幅x高さ」で表現しますが、"auto"を指定すると、最初のラスタを使って適切なタイルサイズが計算され、全てのラスタに適用されます。
全てのタイルが同じ幅と高さを持つことを保証するために、右端、下端のタイルに詰め物を施します。
ファイルシステム (データベース外)ラスタとして、ラスタを登録します。
データベースには、ラスタのメタデータとラスタのファイルパスのみ格納されます (ピクセルは格納されません)。
OVERVIEW_FACTOR
ラスタのオーバビューを生成します。一つより多い係数を用いる場合は、コンマ (,) で区切ります。オーバビューのテーブル名はo_overview factor
_table
となります。overview factor
にはオーバビュー係数が入り、table
には基底テーブル名が入ります。生成されるオーバビューはデータベースに格納され、-Rは無視されます。生成されたSQLファイルは元データのテーブルとオーバビューテーブルの両方を含むことに注意して下さい。
NODATA
NODATA値を持たないバンドで使用するNODATA値を設定します。
出力先ラスタカラムの名前を指定します。デフォルトは'rast'です。
ファイル名でカラムを追加します。
ファイル名カラムの名前を指定します。-Fを暗に含みます。
PostgreSQL識別子に引用符を付けます。
ラスタカラムにGiSTインデクスを生成します。
ラスタテーブルにvacuum analyzeを行います。
バンドごとのNODATA値のチェックを省略します。
tablespace
生成されるテーブルのテーブルスペースを指定します。-Xフラグを併用しない場合には、インデクス (主キーを含む)はデフォルトのテーブルスペースを使用することにご注意ください。
tablespace
テーブルの新しいインデクスに使うテーブル空間を指定します。主キーに適用され、-Iフラグがある場合においては空間インデクスにも適用されます。
INSERTステートメントでなくCOPYステートメントを使います。
ステートメント毎に実行して、トランザクションを使用しないようにします。
生成されるラスタのバイナリ出力のエンディアンを制御します。XDR (訳注: ビッグエンディアン)の場合は0を、NDR (訳注:リトルエンディアン)の場合は1を、それぞれ指定します。デフォルトは1です。現時点ではNDR出力のみサポートします。
version
出力書式の版を指定します。デフォルトは0です。現時点では0のみサポートします。
ローダを用いて入力ファイルを100x100のタイルで生成して、データベースにアップロードする例は、次の通りです。
![]() | |
|
raster2pgsql -s 4326 -I -C -M *.tif -F -t 100x100 public.demelevation > elev.sql psql -d gisdb -f elev.sql
変換とアップロードはUNIXのパイプを使うと一回で実行できます。
raster2pgsql -s 4326 -I -C -M *.tif -F -t 100x100 public.demelevation | psql -d gisdb
マサチューセッツ州平面のメートル単位の空中写真タイルをaerial
という名前のスキーマにロードします。 元の画像と2, 4レベルのオーバビューのテーブルとを生成します。 データ格納にCOPYを使用し (データベースに仲介ファイルなくまっすぐ入ります)、-eでトランザクションを指定しないようにします (待たずにテーブルのデータを見たい場合には良いです)。ラスタを128x128ピクセルのタイルに分解してラスタ制約を適用します。INSERTモードでなくCOPYモードを使用します。-Fで、カラム名をタイル切り出し元ファイルのファイル名にします。
raster2pgsql -I -C -e -Y -F -s 26986 -t 128x128 -l 2,4 bostonaerials2008/*.jpg aerials.boston | psql -U postgres -d gisdb -h localhost -p 5432
-- サポートされているラスタタイプの一覧: raster2pgsql -G
-Gコマンドの出力は次のようになります。
Available GDAL raster formats: Virtual Raster GeoTIFF National Imagery Transmission Format Raster Product Format TOC format ECRG TOC format Erdas Imagine Images (.img) CEOS SAR Image CEOS Image JAXA PALSAR Product Reader (Level 1.1/1.5) Ground-based SAR Applications Testbed File Format (.gff) ELAS Arc/Info Binary Grid Arc/Info ASCII Grid GRASS ASCII Grid SDTS Raster DTED Elevation Raster Portable Network Graphics JPEG JFIF In Memory Raster Japanese DEM (.mem) Graphics Interchange Format (.gif) Graphics Interchange Format (.gif) Envisat Image Format Maptech BSB Nautical Charts X11 PixMap Format MS Windows Device Independent Bitmap SPOT DIMAP AirSAR Polarimetric Image RadarSat 2 XML Product PCIDSK Database File PCRaster Raster File ILWIS Raster Map SGI Image File Format 1.0 SRTMHGT File Format Leveller heightfield Terragen heightfield USGS Astrogeology ISIS cube (Version 3) USGS Astrogeology ISIS cube (Version 2) NASA Planetary Data System EarthWatch .TIL ERMapper .ers Labelled NOAA Polar Orbiter Level 1b Data Set FIT Image GRIdded Binary (.grb) Raster Matrix Format EUMETSAT Archive native (.nat) Idrisi Raster A.1 Intergraph Raster Golden Software ASCII Grid (.grd) Golden Software Binary Grid (.grd) Golden Software 7 Binary Grid (.grd) COSAR Annotated Binary Matrix (TerraSAR-X) TerraSAR-X Product DRDC COASP SAR Processor Raster R Object Data Store Portable Pixmap Format (netpbm) USGS DOQ (Old Style) USGS DOQ (New Style) ENVI .hdr Labelled ESRI .hdr Labelled Generic Binary (.hdr Labelled) PCI .aux Labelled Vexcel MFF Raster Vexcel MFF2 (HKV) Raster Fuji BAS Scanner Image GSC Geogrid EOSAT FAST Format VTP .bt (Binary Terrain) 1.3 Format Erdas .LAN/.GIS Convair PolGASP Image Data and Analysis NLAPS Data Format Erdas Imagine Raw DIPEx FARSITE v.4 Landscape File (.lcp) NOAA Vertical Datum .GTX NADCON .los/.las Datum Grid Shift NTv2 Datum Grid Shift ACE2 Snow Data Assimilation System Swedish Grid RIK (.rik) USGS Optional ASCII DEM (and CDED) GeoSoft Grid Exchange Format Northwood Numeric Grid Format .grd/.tab Northwood Classified Grid Format .grc/.tab ARC Digitized Raster Graphics Standard Raster Product (ASRP/USRP) Magellan topo (.blx) SAGA GIS Binary Grid (.sdat) Kml Super Overlay ASCII Gridded XYZ HF2/HFZ heightfield raster OziExplorer Image File USGS LULC Composite Theme Grid Arc/Info Export E00 GRID ZMap Plus Grid NOAA NGS Geoid Height Grids
データベース内でラスタやラスタテーブルを生成したい場合が多くあります。これを行うための関数が多数あります。一般的な手順は次の通りです。
新しいラスタ行を保持するためのラスタカラムを持つテーブルを生成します。次を実行します。
CREATE TABLE myrasters(rid serial primary key, rast raster);
この目標で助けとなる関数は多数あります。他のラスタの派生でないラスタを生成する場合、ST_MakeEmptyRasterとST_AddBandを順次実行して作業を開始します。
ジオメトリからラスタを生成することもできます。ST_AsRasterを使います。ST_UnionやST_MapAlgebraFctや、地図解析関数群等といった、他の関数を組み合わせる場合もあります。
既存テーブルから新しいラスタテーブルを生成するための多数の選択肢があります。たとえば、ST_Transformを使って、既存テーブルから異なる投影法のラスタテーブルを生成します。
はじめにテーブルにデータを入れたら、ラスタカラムに空間インデクスを生成したくなるでしょう。次のようにします。
CREATE INDEX myrasters_rast_st_convexhull_idx ON myrasters USING gist( ST_ConvexHull(rast) );
ST_ConvexHullを使用していることに注意して下さい。多くのラスタ演算子はラスタの凸包を元にしています。
![]() | |
2.0より前の PostGIS ラスタは、エンベロープを基本にして、凸包ではありませんでした。空間インデクスを適切に働かせるには、エンベロープを基本にしたインデクスを削除して、凸包を元にしたインデクスに置き換えます。 |
AddRasterConstraintsを用いてラスタ制約を適用します。
PostGISが生成する、二つのラスタカタログのビューがあります。両方ともラスタテーブルの制約の中に埋め込まれる情報を用いています。結果として、カタログビューは、テーブル内のラスタデータに制約が働くため、常にラスタデータとの矛盾がありません。
raster_columns
ラスタタイプのデータベースにおける全てのラスタテーブルカラムのカタログです。
raster_overviews
データベース内の、より詳細なテーブルのためのオーバビューを提供するラスタテーブルのカラム全てのカタログです。この種のテーブルは、ロード時に-l
を指定した時に生成されます。
raster_columns
は、ラスタタイプのデータベースにおける全てのラスタテーブルカラムのカタログです。テーブルの制約を使ったビューなので、他のデータベースのバックアップからラスタテーブルをリストアしたとしても、情報は常に矛盾がありません。raster_columns
カタログには次のカラムがあります。
ローダを使わずにテーブルを生成したり、ロード時に-C
フラグを忘れたりした場合には、事後にAddRasterConstraintsで制約を強制でき、raster_columns
カタログは、ラスタタイルの共通の情報を登録します。
r_table_catalog
テーブルが存在するデータベースです。これは常に現在のデータベースを読みます。
r_table_schema
ラスタテーブルが属するデータベーススキーマです。
r_table_name
ラスタテーブルです。
r_raster_column
ラスタタイプであるr_table_name
テーブルのカラムです。PostGISには、一つのテーブルに複数のラスタカラムを持つことを妨げません。異なるラスタカラムを持つラスタテーブルが、ラスタカラム毎に複数回出現するテーブルを持つことができます。
srid
ラスタの空間参照系識別番号です。Section 4.3.1, “SPATIAL_REF_SYSテーブルと空間参照系”にあるエントリであるべきです。
scale_x
地理空間座標とピクセルの間の拡大縮小係数です。これは、ラスタカラムのすべてのタイルが同じscale_x
を持ち、制約が適用されている場合のみ出現します。詳細情報についてはST_ScaleXを参照してください。
scale_y
地理空間座標とピクセルの間の拡大縮小係数です。これは、ラスタカラムのすべてのタイルが同じscale_y
を持ち、制約が適用されている場合のみ出現します。詳細情報についてはST_ScaleYを参照してください。
blocksize_x
ラスタタイルごとの幅 (横方向のピクセル数)です。詳細情報についてはST_Widthを参照してください。
blocksize_y
ラスタタイルごとの高さ (縦方向のピクセル数)です。詳細情報についてはST_Heightを参照してください。
same_alignment
全てのラスタタイルが同じアラインメントを持っているかを示す真偽値です。詳細情報についてはST_SameAlignmentを参照してください。
regular_blocking
ラスタカラムが空間的に一意かつカバレッジタイルの制約を持つなら、TRUEとなります。その他の場合はFALSEになります。。
num_bands
ラスタ集合のタイルごとのバンド数。 ST_NumBands
pixel_types
バンドごとのピクセルタイプを定義する配列です。この配列の要素数はバンド数と同じです。pixel_typesは、ST_BandPixelTypeで定義されるピクセルタイプの一つを取ります。
nodata_values
バンド毎のnodata_value
を示す倍精度浮動小数点数の配列です。バンド数と同じ配列数となります。これらの値は、バンド毎のほとんどの処理で無視されるべきピクセル値の定義です。これはST_BandNoDataValueで得られる情報と似ています。
out_db
ラスタバンドデータがデータベース外で維持されているかを示す真偽値の配列です。この配列の添え字はバンド番号と同じです。
extent
ラスタ集合における全てのラスタ行の範囲です。集合の範囲を変更するデータを別途ロードする予定である場合、ロード前にDropRasterConstraints関数を実行して、ロード後にAddRasterConstraintsで制約を再適用します。
spatial_index
空間インデクスを持っているかどうかを示す真偽値です。
raster_overviews
は、オーバビューで使われるラスタテーブルカラムに関する情報のカタログで、オーバビューを用いる際に知っておくと便利な情報も持ちます。オーバビューテーブルはraster_columns
とraster_overviews
の両方のカタログに入れられます。オーバビューもラスタの一つであるのは確かですが、より高い解像度テーブルの解像度を落としたカリカチュアになるという特殊な目的を満たすためでもあるからです。ラスタをロードする際に-l
スイッチを使うと、オーバビューが主ラスタテーブルと一緒に生成されます。もしくは、AddOverviewConstraintsを使うと手動で生成できます。
オーバビューテーブルには、他のラスタテーブルと同じ制約と、オーバビュー特有の制約となる追加情報があります。
![]() | |
|
オーバビューの主たる理由は次の二つです。
ズームアウトした際の地図表示を早くするために、元のテーブルの低解像度表現が一般的に使われます。
レコード数が少なく、ピクセル毎の適用範囲が広いため、高解像度の元テーブルより計算が一般的に早くなります。計算は高解像度テーブルより精度は落ちますが、大まかな計算には十分でありえます。
raster_overviews
カタログには、次の情報のカラムがあります。
o_table_catalog
オーバビューテーブルが存在するデータベースです。常に現在のデータベースを読みます。
o_table_schema
オーバビューラスタテーブルが属するデータベーススキーマです。
o_table_name
ラスタオーバビューテーブル名です。
o_raster_column
オーバビューテーブル内のラスタカラムです。
r_table_catalog
このオーバビューの元となるラスタテーブルのデータベースです。常に現在のデータベースを読みます。
r_table_schema
このオーバビューの元となるラスタテーブルが属するデータベーススキーマです。
r_table_name
このオーバビューの元となるラスタテーブルです。
r_raster_column
このオーバビューの元となるラスタカラムです。
overview_factor
- オーバビューテーブルのピラミッドレベルです。高い数字ほど解像度が低くなります。raster2pgsqlは、画像のフォルダを渡された場合は、分割して、イメージファイルのオーバビューの計算とロードを行います。レベル1は元ファイルと同じです。レベル2は、元ファイルの4分の1になります。たとえば、5000x5000ピクセルの画像ファイルのフォルダがあるとして、125x125に分ける場合、画像ファイルごとに(5000*5000)/(125*125) = 1600行のレコードを持ち、o_2
テーブル (レベル2)はceiling(1600/Power(2,2)) = 400行、o_3
(レベル3)ではceiling(1600/Power(2,3) ) = 200行のレコードを持ちます。ピクセルがタイルサイズで割り切れない場合、スクラップタイル (完全には値が入っていない)が得られます。raster2pgsqlによって生成される個々のオーバビュータイルは、元となるラスタと同じピクセル数を持ち、個々のピクセルの表現範囲 (オリジナルの Power(2,overview_factor)ピクセル分)が低い解像度になっている点に注意して下さい。
PostGISラスタには、対応イメージ書式のラスタをレンダリングするSQL関数があり、レンダリングを行うための多数の選択肢があります。たとえば、Rendering PostGIS Raster graphics with LibreOffice Base Reportsで例を挙げている通り、OpenOffice/LibreOfficeを使うことができます。さらに、ここで示すように、幅広い言語で使うことができます。
本節では、PHPのPostgreSQLドライバとST_AsGDALRaster等の関数を使って、HTML imgタグに埋め込むことができるPHPリクエストストリームにラスタの1、2、3バンドを出力する方法を示します。
サンプルクエリでは、 指定したWGS84バウンディングボックスにインタセクトするタイルを取って、 ST_Unionでインタセクトしたタイルを結合して全てのバンドを返し、ST_Transformでユーザ指定投影法に変換し、ST_AsPNGを使ってPNGで結果を出力するためのラスタ関数群全体をまとめる方法を示します。
次で示すスクリプトは、
http://mywebserver/test_raster.php?srid=2249
で、マサチューセッツ州平面 (フィート単位)のラスタ画像を取得するものです。
<?php /** test_raster.phpのコンテンツ **/ $conn_str ='dbname=mydb host=localhost port=5432 user=myuser password=mypwd'; $dbconn = pg_connect($conn_str); header('Content-Type: image/png'); /** 特定の投影法が要求された場合にはそれを使い、それ以外ではメートル単位マサチューセッツ州平面を使います **/ if (!empty( $_REQUEST['srid'] ) && is_numeric( $_REQUEST['srid']) ){ $input_srid = intval($_REQUEST['srid']); } else { $input_srid = 26986; } /** set bytea_outputは、PostgreSQL 9.0以上で必要になるかも知れませんが、8.4では不要です **/ $sql = "set bytea_output='escape'; SELECT ST_AsPNG(ST_Transform( ST_AddBand(ST_Union(rast,1), ARRAY[ST_Union(rast,2),ST_Union(rast,3)]) ,$input_srid) ) As new_rast FROM aerials.boston WHERE ST_Intersects(rast, ST_Transform(ST_MakeEnvelope(-71.1217, 42.227, -71.1210, 42.218,4326),26986) )"; $result = pg_query($sql); $row = pg_fetch_row($result); pg_free_result($result); if ($row === false) return; echo pg_unescape_bytea($row[0]); ?>
本節では、Npgsql PostgreSQL .NETドライバとST_AsGDALRaster等の関数を使って、HTML imgタグに埋め込むことができるように、ラスタの1、2、3バンドを出力する方法を示します。
この例ではNpgsql .NET PostgreSQLドライバが必要です。最新版はhttp://npgsql.projects.postgresql.org/にあります。最新版をダウンロードして、ASP.NET の binフォルダに入れるだけでうまくいきます。
サンプルクエリでは、 指定したWGS84バウンディングボックスにインタセクトするタイルを取って、 ST_Unionでインタセクトしたタイルを結合して全てのバンドを返し、ST_Transformでユーザ指定投影法に変換し、ST_AsPNGを使ってPNGで結果を出力するためのラスタ関数群全体をまとめる方法を示します。
この例はC#で実装している点を除いてはSection 5.3.1, “ST_AsPNG を他の関数とあわせて使った PHP 出力例”と同じです。
次で示すスクリプトは、
http://mywebserver/TestRaster.ashx?srid=2249
で、マサチューセッツ州平面 (フィート単位)のラスタ画像を取得します。
-- web.config 接続文字列部 -- <connectionStrings> <add name="DSN" connectionString="server=localhost;database=mydb;Port=5432;User Id=myuser;password=mypwd"/> </connectionStrings >
// TestRaster.ashxのコード <%@ WebHandler Language="C#" Class="TestRaster" %> using System; using System.Data; using System.Web; using Npgsql; public class TestRaster : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType = "image/png"; context.Response.BinaryWrite(GetResults(context)); } public bool IsReusable { get { return false; } } public byte[] GetResults(HttpContext context) { byte[] result = null; NpgsqlCommand command; string sql = null; int input_srid = 26986; try { using (NpgsqlConnection conn = new NpgsqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["DSN"].ConnectionString)) { conn.Open(); if (context.Request["srid"] != null) { input_srid = Convert.ToInt32(context.Request["srid"]); } sql = @"SELECT ST_AsPNG( ST_Transform( ST_AddBand( ST_Union(rast,1), ARRAY[ST_Union(rast,2),ST_Union(rast,3)]) ,:input_srid) ) As new_rast FROM aerials.boston WHERE ST_Intersects(rast, ST_Transform(ST_MakeEnvelope(-71.1217, 42.227, -71.1210, 42.218,4326),26986) )"; command = new NpgsqlCommand(sql, conn); command.Parameters.Add(new NpgsqlParameter("input_srid", input_srid)); result = (byte[]) command.ExecuteScalar(); conn.Close(); } } catch (Exception ex) { result = null; context.Response.Write(ex.Message.Trim()); } return result; } }
これは、一つの画像を返すクエリを取り、指定したファイルに出力する、簡単なJavaコンソールアプリケーションです。
最新のPostgreSQL JDBCドライバはhttp://jdbc.postgresql.org/download.htmlからダウンロードできます。
あとで示すコードをコンパイルします。コマンドは次の通りです。
set env CLASSPATH .:..\postgresql-9.0-801.jdbc4.jar javac SaveQueryImage.java jar cfm SaveQueryImage.jar Manifest.txt *.class
次のようにコマンドラインから呼び出します。
java -jar SaveQueryImage.jar "SELECT ST_AsPNG(ST_AsRaster(ST_Buffer(ST_Point(1,5),10, 'quad_segs=2'),150, 150, '8BUI',100));" "test.png"
-- Manifest.txt -- Class-Path: postgresql-9.0-801.jdbc4.jar Main-Class: SaveQueryImage
// SaveQueryImage.javaのコード import java.sql.Connection; import java.sql.SQLException; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.io.*; public class SaveQueryImage { public static void main(String[] argv) { System.out.println("Checking if Driver is registered with DriverManager."); try { //java.sql.DriverManager.registerDriver (new org.postgresql.Driver()); Class.forName("org.postgresql.Driver"); } catch (ClassNotFoundException cnfe) { System.out.println("Couldn't find the driver!"); cnfe.printStackTrace(); System.exit(1); } Connection conn = null; try { conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/mydb","myuser", "mypwd"); conn.setAutoCommit(false); PreparedStatement sGetImg = conn.prepareStatement(argv[0]); ResultSet rs = sGetImg.executeQuery(); FileOutputStream fout; try { rs.next(); /** Output to file name requested by user **/ fout = new FileOutputStream(new File(argv[1]) ); fout.write(rs.getBytes(1)); fout.close(); } catch(Exception e) { System.out.println("Can't create file"); e.printStackTrace(); } rs.close(); sGetImg.close(); conn.close(); } catch (SQLException se) { System.out.println("Couldn't connect: print out a stack trace and exit."); se.printStackTrace(); System.exit(1); } } }
これは、サーバディレクトリ内でレコードごとにファイルを生成するPythonストアド関数です。plpythonが必要です。plpythonuとplpython3uの両方が正しく動作します。
CREATE OR REPLACE FUNCTION write_file (param_bytes bytea, param_filepath text) RETURNS text AS $$ f = open(param_filepath, 'wb+') f.write(param_bytes) return param_filepath $$ LANGUAGE plpythonu;
-- 5つの画像をPostgreSQLサーバに可変サイズで描きます。 -- PostgreSQLデーモンのアカウントにフォルダへの書き込み権限が必要ですので -- ご注意ください。 -- 生成されたファイル名をエコーバックします。 SELECT write_file(ST_AsPNG( ST_AsRaster(ST_Buffer(ST_Point(1,5),j*5, 'quad_segs=2'),150*j, 150*j, '8BUI',100)), 'C:/temp/slices'|| j || '.png') FROM generate_series(1,5) As j; write_file --------------------- C:/temp/slices1.png C:/temp/slices2.png C:/temp/slices3.png C:/temp/slices4.png C:/temp/slices5.png
PSQLから組み込み機能を用いてバイナリを出力するのは簡単ではありません。ここで紹介する方法は、レガシーなラージオブジェクトをサポートするPostgreSQL上に乗っかる、ちょっとしたハックです。まずは、psqlを起動して、データベースに接続します。
この方法はPythonの場合と違い、ローカル機にファイルが生成されます
SELECT oid, lowrite(lo_open(oid, 131072), png) As num_bytes FROM ( VALUES (lo_create(0), ST_AsPNG( (SELECT rast FROM aerials.boston WHERE rid=1) ) ) ) As v(oid,png); -- 次のような出力が得られます -- oid | num_bytes ---------+----------- 2630819 | 74860 -- 続いて、oidを書き留めて、'C:/temp/aerial_smap.png'を -- ローカルのコンピュータ上のファイルパスに置き換えたうえで、 -- 次を実行します。 \lo_export 2630819 'C:/temp/aerial_samp.png' -- db上のラージオブジェクトストレージからファイルを削除します SELECT lo_unlink(2630819);
Minnesota MapServerはOpenGIS Web Mapping Server仕様を満たすウェブマッピングサーバです。
MapServerのウェブサイトはhttp://mapserver.org/です。
The OpenGIS Web Map Specificationはhttp://www.opengeospatial.org/standards/wmsにあります。
MapServerでPostGISを使うには、MapServerのコンフィギュレーション方法についての知識が必要ですが、この文書の範囲外です。この節では、PostGIS特有の問題とコンフィギュレーション詳細について記載します。
PostGISをMapServerで使うには、次のものが必要です。
PostGIS 0.6以上
MapServer 3.5以上
MapServerは、他のクライアントのように、libpq
インタフェースを使って、PostGIS/PostgreSQLデータにアクセスします。よってMapServerはPostGISサーバにアクセスするネットワークを持つ計算機にインストールでき、PostGISをデータソースとして使用することができます。システム間の接続は速いほど良いです。
"--with-postgis"と好きなconfigureオプションを付けてMpaServerのコンパイルとインストールを行います。
Mapserverのmapファイルの中に、PostGISレイヤを追加します。たとえば次のようになります。
LAYER CONNECTIONTYPE postgis NAME "widehighways" # リモートの空間データベースに接続します CONNECTION "user=dbuser dbname=gisdatabase host=bigserver" PROCESSING "CLOSE_CONNECTION=DEFER" # 'roads'テーブルの'geom'カラムからラインを取得します DATA "geom from roads using srid=4326 using unique gid" STATUS ON TYPE LINE # 範囲内のラインである広い高速道路のみ描画します FILTER "type = 'highway' and numlanes >= 4" CLASS # 非常に広い高速道路はより明るい色かつ2ピクセル幅にします EXPRESSION ([numlanes] >= 6) STYLE COLOR 255 22 22 WIDTH 2 END END CLASS # 残りは、暗い色かつ1ピクセル幅です EXPRESSION ([numlanes] < 6) STYLE COLOR 205 92 82 END END END
上の例におけるPostGIS特有のディレクティブは次の通りです。
PostGISレイヤでは常に"postgis"とします。
データベース接続は「接続文字列」によって制御されます。接続文字列は、次に示すような標準的なキーと値からなります(<>内はデフォルト値)。
user=<ユーザ名> password=<パスワード> dbname=<ユーザ名> hostname=<サーバ> port=<5432>
空の接続文字列も妥当とされますし、あらゆるキーと値のペアは省略できます。接続するためには一般的にはdbnameとusernameとが最少で与えるものとなります。
このパラメータの形式は "<カラム名> from <テーブル名> using srid=<SRID> using unique <主キー>"となります。ここで、カラム名は地図に描画したい空間カラムを指し、SRIDはそのカラムで使われるSRIDで、主キーはそのテーブルの主キー (またはインデックスを伴う一意の値を持つカラム)です。
"using srid"と"using unique"節は省略できます。MapServerは可能なら自動的に正しい値を判断しますが、地図を描画するサーバ上で余分なクエリを若干実行するコストがかかります。
接続を閉じずに複数のレイヤで再利用する場合にCLOSE_CONNECTION=DEFERとします。速度が改善します。詳細な説明についてはMapServer PostGIS Performance Tipsを参照して下さい。
フィルタは、妥当なSQL文字列でなければなりません。この文字列は、通常はSQLクエリにおける"WHERE"に続く論理式に対応します。たとえば、6レーン以上の道路だけを描画する場合には、"num_lanes >= 6"というフィルタを使います。
空間データベースにおいては、空間 (GiST)インデックスを、マップに描かれるレイヤ全てに構築していることを保証して下さい。
CREATE INDEX [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム] );
MapServerを使用するレイヤのクエリを実行する場合には、"using unique"節もDATAステートメントに追加しなければなりません。
MapServerでは、クエリ実行の際には、それぞれの空間レコードを識別するための一意な識別子が必要です。MapServerのPostGISモジュールは、一意な識別子を提供するために、ユーザ指定の一意な値を使います。テーブルの主キーを使うのが最も良い方法です。
USING
疑似SQL節を使ってMapServerがより複雑なクエリの結果を理解できるようにするための情報を追加します。より詳しく言うと、ビューまたは副問い合わせが元テーブル (DATA
定義で"FROM"の右にあるもの)として使われる時、MapServerが自動的に一意な識別子がそれぞれの行にあるか、また、SRIDがテーブルにあるかを判別するのは困難です。USING
節によって、MapServerがこれらの情報を得ることができます。例を次に挙げます。
DATA "geom FROM ( SELECT table1.geom AS geom, table1.gid AS gid, table2.data AS data FROM table1 LEFT JOIN table2 ON table1.id = table2.id ) AS new_table USING UNIQUE gid USING SRID=4326"
MapServerは、マップクエリを実行する際、行識別のために、それぞれの行に一意な識別子を求めます。通常ならシステムテーブルから主キーを識別しますが、ビューや副問い合わせでは、一意性のあるカラムを自動的に知ることができません。MapServerのクエリ機能を使いたいなら、一意性のあるカラムをビューまたは副問い合わせに追加する必要があり、USING UNIQUE
宣言を付ける必要があります。たとえば、この目的のための主キー値のテーブルでのカラム名や、結果セットで一意性が保障されたカラムを明示的にSELECTに入れることができます。
![]() | |
「マップクエリ」はマップ上でクリックして、その場所におけるフィーチャーに関する情報を問い合わせる動作です。「マップクエリ」と |
PostGISは、MapServerに正しいデータを返すために、ジオメトリがどの空間参照系を使っているかを知る必要があります。通常は、この情報はPostGISデータベースの"geometry_columns"テーブルから得ることができます。しかし、副問い合わせやビューのような一時テーブルでは、この方法は不可能です。そこで、 USING SRID=
オプションを使って、正しいSRIDがDATA
定義で使われるように指定します。
簡単な例から始めて、ステップアップしていきましょう。次のMapServerレイヤ定義を考えて下さい。
LAYER CONNECTIONTYPE postgis NAME "roads" CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" DATA "geom from roads" STATUS ON TYPE LINE CLASS STYLE COLOR 0 0 0 END END END
このレイヤは"roads"テーブルにある道路ジオメトリの全部を黒線で表示するものです。
では、少なくとも1:100000にズームするまでは高速道路だけを表示したい、としましょう。次の二つのレイヤで、その効果が実現できます。
LAYER CONNECTIONTYPE postgis CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" PROCESSING "CLOSE_CONNECTION=DEFER" DATA "geom from roads" MINSCALE 100000 STATUS ON TYPE LINE FILTER "road_type = 'highway'" CLASS COLOR 0 0 0 END END LAYER CONNECTIONTYPE postgis CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" PROCESSING "CLOSE_CONNECTION=DEFER" DATA "geom from roads" MAXSCALE 100000 STATUS ON TYPE LINE CLASSITEM road_type CLASS EXPRESSION "highway" STYLE WIDTH 2 COLOR 255 0 0 END END CLASS STYLE COLOR 0 0 0 END END END
一つ目のレイヤはスケールが1:100000以上であるときに使われ、道路タイプが"highway"である道路のみ黒線で表示されます。FILTER
オプションによって、道路タイプが"highway"の場合のみ表示することになります。
二つ目のレイヤはスケールが1:100000未満である時に使われ、"highway"は赤い二重細線で表示され、他の道路は黒線で表示されます。
さて、MapServerの機能を使うだけで、二つのおもしろいことを実行しました。しかし、DATA
のSQLステートメントは、単純なままです。道路名が (どういう理由かは知りませんが)他のテーブルに収められていて、それのデータを取得するためにテーブルを連結して、道路のラベルを取る必要がある、とします。
LAYER CONNECTIONTYPE postgis CONNECTION "user=theuser password=thepass dbname=thedb host=theserver" DATA "geom FROM (SELECT roads.gid AS gid, roads.geom AS 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 gid USING SRID=4326" 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を使用する方法も示しています。
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.PGConnection)conn).addDataType("geometry",Class.forName("org.postgis.PGgeometry")); ((org.postgresql.PGConnection)conn).addDataType("box3d",Class.forName("org.postgis.PGbox3d")); /* * ステートメントの生成とSELECTクエリの実行を行います。 */ Statement s = conn.createStatement(); ResultSet r = s.executeQuery("select geom,id from geomtable"); while( r.next() ) { /* * ジオメトリをオブジェクトとして検索してジオメトリ型にキャストします。 * オブジェクトを印字します */ 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をご覧下さい。
現版のPostgreSQL (9.6を含む)では、TOASTテーブルに従うクエリオプティマイザの弱さに苦しみます。 TOASTテーブルは、(長いテキスト、イメージ、多数の頂点を持つ複合ジオメトリといった)通常のデータページに適合しない、(データサイズという意味では)巨大な値を納めるための「拡張部屋」の一種です。詳細情報は the PostgreSQL Documentation for TOASTをご覧ください。
(高解像度で全てのヨーロッパの国の境界を含むテーブルのような)大きなジオメトリがあるうえ、行がそう多くないテーブルを持つようになると、この問題が出てきます。テーブル自体は小さいのですが、多くのTOASTスペースを使います。例として、テーブル自体は概ね80行で3データページしか使わなくてもTOASTテーブルで8225ページを使うとします。
ここで、ジオメトリ演算子の&&を使って、ほとんどマッチしないようなバウンダリボックスを検索するクエリを出してみます。クエリオプティマイザにはテーブルは3ページ80行しかないように見えます。オプティマイザは、小さなテーブルを順に走査する方がインデクスを使うよりも早いと見積もります。そして、GiSTインデクスは無視すると決めます。通常なら、この見積もりは正しいです。しかし、この場合は&&演算子が全てのジオメトリをディスクから呼び出してバウンディングボックスと比較しなければならなくなり、ゆえに、全てのTOASTページもまた呼び出す必要があります。
この問題に苦しむかどうかを見るには、PostgreSQLの"EXPLAIN ANALYZE"コマンドを使います。詳細情報と技術情報については、PostgreSQL性能メーリングリストのスレッドhttp://archives.postgresql.org/pgsql-performance/2005-02/msg00030.phpをご覧下さい。
また、PostGISの新しいスレッドhttps://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.htmlもご覧下さい。
PostgreSQLコミュニティでは、TOASTを意識したクエリ見積もりを作ることで、この問題を解決しようとしています。今のところは、二つの応急処置があります。
一つは、クエリプランナにインデクスの使用を強制することです。クエリを発行する前に"SET enable_seqscan TO off;"をサーバに送信します。これは基本的にクエリプランナに対して可能な限り順に走査することを避けるよう強制します。そのためGiSTインデクスを通常使うようになります。しかし、このフラグは接続するたびに設定しなければならず、他のケースにおいてはクエリプランナに誤った見積もりをさせることになるので、 "SET enable_seqscan TO on;"をクエリの後に送信すべきです。
もう一つは、順に走査することをクエリプランナが考える程度に早くすることです。これは、バウンダリボックスの「キャッシュ」を行う追加カラムを作成し、このカラムにマッチさせるようにすることで達成することができます。ここでの例では次のようになります。
SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2'); UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(the_geom));
そして、次のように、&&演算子をgeom_columnに対して行っていたものをbboxに変更します。
SELECT geom_column FROM mytable WHERE bbox && ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);
もちろん、mytableの行を変更または追加したら、bboxを「同期」するようにしなければなりません。最もすっきりした方法はトリガです。もしくは、アプリケーションを変更してbboxカラムの現状を保持するか、テーブル更新後にいつもUPDATEクエリを実行するかでも対応できます。
読み込むことがほとんどで、かつほとんどのクエリでひとつのインデクスを使うようなテーブルのために、PostgreSQLは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制限は使えません。
ときどき、テーブルで3次元、4次元のデータを持つのに、常にOpenGIS準拠のST_AsText()またはST_AsBinary()関数を使ってアクセスして 2次元ジオメトリを出力させるようなことが起きます。内部でST_Force_2d()関数を呼んでいるために発生しますが、これは、大きなジオメトリでは重大なオーバヘッドを誘引することになります。このオーバヘッドを回避するには、一度追加された次元を前もって落とし、かつこれを永続化するのが適当かも知れません。
UPDATE mytable SET the_geom = ST_Force2D(the_geom); VACUUM FULL ANALYZE mytable;
AddGeometryColumn()を使ってジオメトリカラムを追加した場合、ジオメトリの次元に関する制限があることに注意してください。この制限を迂回するには、制限の削除が必要になります。geometry_columnsテーブル内のエントリを更新して、その後で制限を再作成することを忘れないで下さい。
大きなテーブルの場合、WHERE節、およびプライマリキー若しくは他の適切な基準によってテーブルの一部へのUPDATEを制限させて、UPDATEの実行の間に単に"VACUUM;"と実行することで、UPDATEをより小さい塊に分割するのが賢いやり方かもしれません。これにより、テンポラリディスクスペースが劇的に減少します。さらに、次元混合のジオメトリを持つ場合、"WHERE dimension(the_geom)>2"によってUPDATEを制限することで、2次元で書かれているジオメトリの再書き込みをスキップさせることができます。
PostGISの調整はPostgreSQLの作業量の調整と非常に似ています。ジオメトリとラスタは重く、メモリ関連の最適化は他のPostgreSQLクエリと比べて影響が大きい点だけは留意して下さい。
PostgreSQLの最適化に関する一般的な詳細は、Tuning your PostgreSQL Serverをご覧ください。
PostgreSQL 9.4以上では、ALTER SYSTEM..
を使うことで、postgresql.confやpostgresql.auto.confを触ることなくサーバレベルで設定できます。
ALTER SYSTEM SET work_mem = '256MB'; -- 起動時設定でない設定を強制します。新規接続に影響を与えます。 SELECT pg_reload_conf(); -- 現在の設定値を表示 -- 全ての設定を見るにはSHOW ALLを使います SHOW work_mem;
この設定に追加して、PostGISには、Section 8.2, “PostGIS GUC (Grand Unified Custom)変数”で示している、いくつかの独特の設定があります。
これらの設定はpostgresql.conf内にあります。
デフォルト: partition
一般的にテーブルのパーティショニングに使われます。デフォルトとして"partition"に設定されています。継承階層内にあり、プランナにペナルティ以外を払わないなら、クエリプランナにテーブルの制約条件の解析だけを行わせるので、PostgreSQL 8.4以上ではこれが理想的です。
デフォルト: PostgreSQL 9.6では128MB以下
利用可能なRAMの25%から40%を設定します。Windowsでは高く設定することができないかも知れません。
max_worker_processes これは、PostgreSQL 9.4以上で有効です。PostgreSQL 9.6以上では、パラレルクエリ処理に使うプロセス数の最大値の制御で、さらに重要なものとなっています。
デフォルト: 8
システムが対応できるバックグラウンドプロセスの最大値を設定します。このパラメータはサーバ起動時のみ設定できます。
work_mem (並べ替えや複雑なクエリに使われるメモリ)
デフォルト: 1-4MB
大きなデータベースの場合や、複雑なクエリの場合、RAMが多い場合は値を大きくするように調整します。
同時接続ユーザ数が多い場合や、RAMが少ない場合には値を小さくするように調整します。
たくさんのRAMを持ち、少数の開発者しかいない場合は次のようにします。
SET work_mem TO '256MB';
maintenance_work_mem (VACUUM, CREATE INDEX等で使われるメモリ)
デフォルト: 16-64MB
一般的には低すぎます - メモリスワップの間、入出力が拘束され、オブジェクトがロックされます。
たくさんのRAMを持つ本番サーバでは32MBから1GBが推奨ですが、同時接続ユーザ数に依存します。たくさんのRAMを持ち、少数の開発者しかいない場合は次のようにします。
SET maintenance_work_mem TO '1GB';
max_parallel_workers_per_gather
max_parallel_workers_per_gather PostgreSQL 9.6以上で有効です。また、パラレルクエリに対応しているPostGIS 2.3以上でのみ影響が出ます。0より大きい値にすると、ST_Intersects
等の関係関数が複数のプロセスを使えるようになり、2倍以上高速になります。多数のプロセッサを予備に持っているなら、この値を、持っているプロセッサ数にあわせるべきです。また、max_worker_processes
を少なくともこの値より大きくするようにして下さい。
デフォルト: 0
単一のGather
ノードが開始できるワーカの最大数を設定します。並列ワーカは、max_worker_processes
で確立されたプロセスのプールから取得されます。要求したワーカ数は、実際には実行可能になっていない場合があることに注意して下さい。これが発生する場合には、想定より少ないワーカでプランが実行され、非効率になります。これの値を0 (デフォルト値)にすると、パラレルクエリ実行が無効になります。
ここで示す関数はPostGISユーザが必要とすると思われる関数です。この他に、一般的なユーザが使わないPostGISオブジェクトに対して求められるサポート関数があります。
![]() | |
PostGISは、既存の名前付け方針からSQL-MM中心の方針への切り替えを開始しています。結果として、ユーザが知っていて愛用している関数の多くが標準空間型 (ST) プレフィクスを使うように名前変更されました。以前の関数はまだ有効ですが、更新された等価な関数があるものについては、この文書の一覧から外しています (訳注: 非推奨関数はPostGIS 2.0では基本的に外れています)。これらの関数は非推奨であり、将来のリリースでは削除されますので、*使わないでください*。 |
本節では、PostGISによってインストールされるPostgreSQLデータ型を挙げます。特にユーザ定義関数をデザインする際に大変重要なキャストの挙動を記載しています。
Each data type describes its type casting behaviour. A type cast converts values of one data type into another type. PostgreSQL allows defining casting behavior for custom types, along with the functions used to convert type values. Casts can have automatic behaviour, which allows automatic conversion of a function argument to a type supported by the function.
Some casts have explicit behaviour, which means the cast must be specified using the syntax CAST(myval As sometype)
or myval::sometype
. Explicit casting avoids the issue of ambiguous casts, which can occur when using an overloaded function which does not support a given type. For example, a function may accept a box2d or a box3d, but not a geometry. Since geometry has an automatic cast to both box types, this produces an "ambiguous function" error. To prevent the error use an explicit cast to the desired box type.
All data types can be cast to text
, so this does not need to be specified explicitly.
box2d — xmin, ymin, zmin, xmax, ymax, zmaxで作られるボックス。しばしばジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。
box3d — xmin, ymin, zmin, xmax, ymax, zmaxで作られるボックス。しばしばジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。
geometry_dump — A composite type used to describe the parts of complex geometry.
geometry_dump
is a composite data type containing the fields:
geom
- a references to a component geometry
path[]
- a 1-dimensional integer array that defines the navigation path within the dumped geometry to the geom
component. The path array starts at 1 (e.g. path[1]
is the first element.)
It is used by the ST_Dump*
family of functions as an output type to explode a complex geometry into its constituent parts.
postgis.backend — GEOSとSFCGALで重複する関数を提供するバックエンドです。GEOSまたはSFCGALを選択します。デフォルトはGEOSです。
このGUCはSFCGALサポートでPostGISをコンパイルした場合にのみ適切なものとなります。デフォルトでは、geos
バックエンドはGEOSとSFCGALが同じ名前の関数を持つ関数で使われます。この変数によって、SFCGALをリクエストを提供するバックエンドにすることができます。
Availability: 2.1.0
postgis.gdal_datapath — GDALのGDAL_DATAオプションの値を設定するためのコンフィギュレーションオプションです。設定しない場合には、GDAL_DATA環境変数が使われます。
GDALのGDAL_DATAオプションの値の設定に使うPostgreSQL GUC変数です。postgis.gdal_datapath
値は完全にGDALのデータファイルへの物理的なパスになるべきものです。
コンフィギュレーションオプションは、GDALのデータファイルパスがハードコーディングされていないWindowsプラットフォームのためにほとんど使われます。このオプションは、GDALのデータファイルがGDALの期待されているパスに無いときに設定します。
![]() | |
このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。 |
Availability: 2.2.0
![]() | |
GDAL_DATAに関する追加情報報は、GDALのConfiguration Optionsにあります。 |
postgis.gdal_enabled_drivers — PostGIS環境でGDALドライバを有効にするコンフィギュレーションオプションです。GDALコンフィギュレーション変数GDAL_SKIPに影響を与えます。
PostGIS環境でGDALドライバを有効にするコンフィギュレーションオプションです。GDALコンフィギュレーション変数GDAL_SKIPに影響を与えます。このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。
postgis.gdal_enabled_drivers
の初期値は、PostgreSQL開始プロセスに渡される、有効とするドライバの一覧からなる環境変数POSTGIS_GDAL_ENABLED_DRIVERS
によって設定されます。
有効にするGDALドライバは、ドライバの短縮名またはコードで指定します。ドライバの短縮名またはコードはGDAL Raster Formatsにあります。複数のドライバを指定するには、ドライバの間に一つの空白を置きます。
![]() | |
|
![]() | |
標準的なPostGISのインストールでは、 |
![]() | |
GDAL_SKIPに関する追加情報は、GDALのConfiguration Optionsにあります。 |
Availability: 2.2.0
postgis.gdal_enabled_drivers
の設定とリセット。
データベースへの新規接続にバックエンドを設定します。
ALTER DATABASE mygisdb SET postgis.gdal_enabled_drivers TO 'GTiff PNG JPEG';
サーバへの全ての新規接続のための、有効なドライバのデフォルトを設定します。スーパーユーザ権限とPostgreSQL 9.4以上が必要です。データベース、セッション、ユーザ設定によって上書きされます。
ALTER SYSTEM SET postgis.gdal_enabled_drivers TO 'GTiff PNG JPEG'; SELECT pg_reload_conf();
SET postgis.gdal_enabled_drivers TO 'GTiff PNG JPEG'; SET postgis.gdal_enabled_drivers = default;
全てのGDALドライバを有効にします。
SET postgis.gdal_enabled_drivers = 'ENABLE_ALL';
全てのGDALドライバを無効にします。
SET postgis.gdal_enabled_drivers = 'DISABLE_ALL';
postgis.enable_outdb_rasters — データベース外ラスタのバンドにアクセスできるようにする、真偽型のコンフィギュレーションオプション。
データベース外ラスタのバンドにアクセスできるようにする、真偽型のコンフィギュレーションオプションです。このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。
postgis.enable_outdb_rasters
の初期値は、環境変数POSTGIS_ENABLE_OUTDB_RASTERS
が0でない値で、PostgreSQL開始プロセスに渡されることでで設定されます。
![]() | |
|
![]() | |
標準的なPostGISのインストールでは、 |
Availability: 2.2.0
AddGeometryColumn — ジオメトリカラムを空間テーブルから除去します。
text AddGeometryColumn(
varchar table_name, varchar column_name, integer srid, varchar type, integer dimension, boolean use_typmod=true)
;
text AddGeometryColumn(
varchar schema_name, varchar table_name, varchar column_name, integer srid, varchar type, integer dimension, boolean use_typmod=true)
;
text AddGeometryColumn(
varchar catalog_name, varchar schema_name, varchar table_name, varchar column_name, integer srid, varchar type, integer dimension, boolean use_typmod=true)
;
ジオメトリカラムを既存の属性テーブルに追加します。schema_name
はスキーマ名です。srid
はSPATIAL_REF_SYSテーブルのエントリを参照する整数でなければなりません。type
は'POLYGON'や'MULTILINESTRING'といった、ジオメトリタイプを示す文字でなければなりません。指定したスキーマが存在しない (または現在のsearch_pathからは見えない)場合、または指定したSRID、ジオメトリタイプもしくは次元が不正である場合はエラーが投げられます。
![]() | |
Changed: 2.0.0 geometry_columnsがシステムカタログを読むビューになったため、geometry_columnsを更新しないようになりました。デフォルトでは制約を生成せず、PostgreSQLの型修飾子を使います。この関数によるWGS 84のPOINTカラムの構築と Changed: 2.0.0 制約を使う必要がある場合には、 |
![]() | |
Changed: 2.0.0 ビューについては、geometry_columnsへの手動登録はできなくなりました。しかし、typmodテーブルジオメトリに対して構築されていて、かつラッパ関数が無いビューは、親テーブルカラムのtypmodの挙動を継承するので、正しく登録されます。他のジオメトリを出力するジオメトリ関数を使うビューについては、ビューのジオメトリカラムが正しく登録されるようにするため、typmodジオメトリへのキャストが必要です。Section 4.3.4, “手動でジオメトリカラムをgeometry_columnsに登録する”を参照して下さい。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
Enhanced: 2.0.0 use_typmod引数が導入されました。デフォルトでは制約を基にしたものでなくtypmodジオメトリカラムが生成されます。
-- データを保持するスキーマの生成 CREATE SCHEMA my_schema; -- 新しい単純なPostgreSQLテーブルの生成 CREATE TABLE my_schema.my_spatial_table (id serial); -- "id"カラムのみを持つ単純なテーブルの説明 postgis=# \d my_schema.my_spatial_table Table "my_schema.my_spatial_table" Column | Type | Modifiers --------+---------+------------------------------------------------------------------------- id | integer | not null default nextval('my_schema.my_spatial_table_id_seq'::regclass) -- テーブルにジオメトリカラムを追加\ SELECT AddGeometryColumn ('my_schema','my_spatial_table','geom',4326,'POINT',2); -- 制約を基にした古い方法でPOINTカラムを追加 SELECT AddGeometryColumn ('my_schema','my_spatial_table','geom_c',4326,'POINT',2, false); -- 制約を基にした古い方法でCURVEPOLYGONカラムを追加 SELECT AddGeometryColumn ('my_schema','my_spatial_table','geomcp_c',4326,'CURVEPOLYGON',2, false); -- 再度説明を表示し、新しいジオメトリカラムの追加を明らかにする \d my_schema.my_spatial_table addgeometrycolumn ------------------------------------------------------------------------- my_schema.my_spatial_table.geomcp_c SRID:4326 TYPE:CURVEPOLYGON DIMS:2 (1 row) Table "my_schema.my_spatial_table" Column | Type | Modifiers ----------+----------------------+------------------------------------------------------------------------- id | integer | not null default nextval('my_schema.my_spatial_table_id_seq'::regclass) geom | geometry(Point,4326) | geom_c | geometry | geomcp_c | geometry | Check constraints: "enforce_dims_geom_c" CHECK (st_ndims(geom_c) = 2) "enforce_dims_geomcp_c" CHECK (st_ndims(geomcp_c) = 2) "enforce_geotype_geom_c" CHECK (geometrytype(geom_c) = 'POINT'::text OR geom_c IS NULL) "enforce_geotype_geomcp_c" CHECK (geometrytype(geomcp_c) = 'CURVEPOLYGON'::text OR geomcp_c IS NULL) "enforce_srid_geom_c" CHECK (st_srid(geom_c) = 4326) "enforce_srid_geomcp_c" CHECK (st_srid(geomcp_c) = 4326) -- geometry_columnsビューにも新しいカラムが登録されています -- SELECT f_geometry_column As col_name, type, srid, coord_dimension As ndims FROM geometry_columns WHERE f_table_name = 'my_spatial_table' AND f_table_schema = 'my_schema'; col_name | type | srid | ndims ----------+--------------+------+------- geom | Point | 4326 | 2 geom_c | Point | 4326 | 2 geomcp_c | CurvePolygon | 4326 | 2
DropGeometryColumn — ジオメトリカラムを空間テーブルから除去します。
text DropGeometryColumn(
varchar table_name, varchar column_name)
;
text DropGeometryColumn(
varchar schema_name, varchar table_name, varchar column_name)
;
text DropGeometryColumn(
varchar catalog_name, varchar schema_name, varchar table_name, varchar column_name)
;
ジオメトリカラムを空間テーブルから除去します。schema_nameはgeometry_columnsテーブルの該当行のf_table_schemaフィールドと一致しなければならないことにご注意ください。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
![]() | |
Changed: 2.0.0 この関数は後方互換のためのものです。geometry_columnsは現在はシステムカタログに対するビューですので、他のテーブルのカラムと同じように |
SELECT DropGeometryColumn ('my_schema','my_spatial_table','geom'); ---- 結果出力 ---- dropgeometrycolumn ------------------------------------------------------ my_schema.my_spatial_table.geom effectively removed. -- PostGIS 2.0以上では標準的なALTER TABLEと上の例とは等価です -- 両方ともgeometry_columnsの登録を抹消します ALTER TABLE my_schema.my_spatial_table DROP column geom;
DropGeometryTable — テーブルとgeometry_columnsの当該テーブルへの参照の全てを削除します。
boolean DropGeometryTable(
varchar table_name)
;
boolean DropGeometryTable(
varchar schema_name, varchar table_name)
;
boolean DropGeometryTable(
varchar catalog_name, varchar schema_name, varchar table_name)
;
テーブルとgeometry_columnsの当該テーブルへの参照の全てを削除します。スキーマ対応版PostgreSQLではスキーマが与えられない場合はcurrent_schema()を使います。
![]() | |
Changed: 2.0.0で この関数は後方互換のためのものです。geometry_columnsは現在はシステムカタログに対するビューですので、他のテーブルのカラムと同じように |
Find_SRID — Returns the SRID defined for a geometry column.
text Populate_Geometry_Columns(
boolean use_typmod=true)
;
int Populate_Geometry_Columns(
oid relation_oid, boolean use_typmod=true)
;
Returns the integer SRID of the specified geometry column by searching through the GEOMETRY_COLUMNS table. If the geometry column has not been properly added (e.g. with the AddGeometryColumn function), this function will not work.
Populate_Geometry_Columns — Ensures geometry columns are defined with type modifiers or have appropriate spatial constraints.
text Populate_Geometry_Columns(
boolean use_typmod=true)
;
int Populate_Geometry_Columns(
oid relation_oid, boolean use_typmod=true)
;
ジオメトリカラムが型修飾子で定義されるか、適切な制約を持つことを確実にします。ジオメトリカラムがgeometry_columns
に正しく登録されることを確実にします。デフォルトでは、型修飾子によらないジオメトリカラムを型修飾子によるジオメトリカラムに変換します。以前の挙動にするにはuse_typmod=false
とします。
後方互換のためと、それぞれの子テーブルが異なるジオメトリタイプを持つテーブル継承といった空間テーブルにとって必要があるためとの二つの理由から、古いCHECK制約の挙動がなお有効になっています。古い挙動が必要な場合には、新しいオプション引数でuse_typmod=false
を渡す必要があります。これが実行されると、型修飾子なしのジオメトリカラムが生成され、三つの制約が定義されます。特に、これは、テーブルに属するすべてのジオメトリカラムが少なくとも三つの制約を持つことを意味します。
enforce_dims_the_geom
- あらゆるジオメトリが同じ次元を持つことを確実にします (ST_NDimsをご覧下さい)
enforce_geotype_the_geom
- あらゆるジオメトリが同じ型を持つことを確実にします (GeometryTypeをご覧下さい)
enforce_srid_the_geom
- あらゆるジオメトリが同じ投影法になることを確実にします (???をご覧下さい)
テーブルにoid
がある場合には、この関数はテーブルのジオメトリカラム全てについて、SRIDと次元とジオメトリタイプを判定して、必要に応じて制約を追加しようとします。 成功した場合には、geometry_columns
に適切な行が追加され、その他の場合には、例外が捕まえられ、問題を記述したエラーが通知されます。
ビューのoid
がある場合、テーブルの場合と同じで、SIRDと次元とジオメトリタイプを判定して、適切なエントリをgeometry_columns
テーブルに挿入しますが、制約の追加はされません。
パラメタの無い形式は、geometry_columns
の行を削除したうえで、全ての空間テーブルと空間ビューについて再挿入し、適切な空間制約をテーブルに追加する、パラメタ付きの形式の単純なラッパです。パラメタが無い形式は、検出したジオメトリカラムの数の要約とgeometry_columns
に挿入された行の数とを返します。パラメタ付きの形式は単純にgeometry_columns
に挿入された行の数を返します。
Availability: 1.4.0
Changed: 2.0.0 デフォルトでは、ジオメトリタイプの制限について、制約を確認する代わりに型修飾子を使います。新しいuse_typmod
をFALSEに設定して使うことで、制約確認を使用することができます。
Enhanced: 2.0.0 use_typmod
任意引数が導入されました。カラムが型修飾子で生成されるか制約チェックで作られるかの制御ができます。
CREATE TABLE public.myspatial_table(gid serial, geom geometry); INSERT INTO myspatial_table(geom) VALUES(ST_GeomFromText('LINESTRING(1 2, 3 4)',4326) ); -- 型修飾子を使います -- 動作するにはデータが存在していなければなりません SELECT Populate_Geometry_Columns('public.myspatial_table'::regclass); populate_geometry_columns -------------------------- 1 \d myspatial_table Table "public.myspatial_table" Column | Type | Modifiers --------+---------------------------+--------------------------------------------------------------- gid | integer | not null default nextval('myspatial_table_gid_seq'::regclass) geom | geometry(LineString,4326) |
-- カラムが型修飾子でないか、既に制約が存在している場合には制約を使います -- 動作するにはデータが存在していなければなりません CREATE TABLE public.myspatial_table_cs(gid serial, geom geometry); INSERT INTO myspatial_table_cs(geom) VALUES(ST_GeomFromText('LINESTRING(1 2, 3 4)',4326) ); SELECT Populate_Geometry_Columns('public.myspatial_table_cs'::regclass, false); populate_geometry_columns -------------------------- 1 \d myspatial_table_cs Table "public.myspatial_table_cs" Column | Type | Modifiers --------+----------+------------------------------------------------------------------ gid | integer | not null default nextval('myspatial_table_cs_gid_seq'::regclass) geom | geometry | Check constraints: "enforce_dims_geom" CHECK (st_ndims(geom) = 2) "enforce_geotype_geom" CHECK (geometrytype(geom) = 'LINESTRING'::text OR geom IS NULL) "enforce_srid_geom" CHECK (st_srid(geom) = 4326)
UpdateGeometrySRID — Updates the SRID of all features in a geometry column, and the table metadata.
text UpdateGeometrySRID(
varchar table_name, varchar column_name, integer srid)
;
text UpdateGeometrySRID(
varchar schema_name, varchar table_name, varchar column_name, integer srid)
;
text UpdateGeometrySRID(
varchar catalog_name, varchar schema_name, varchar table_name, varchar column_name, integer srid)
;
ジオメトリカラムの全てのフィーチャーのSRID、geometry_columnsメタデータとSRIDテーブル制約を更新します。スキーマ対応版pgsqlでは、スキーマが提供されていない場合には、この関数はcurrent_schema()を使うことにご注意下さい。
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
Insert geometries into roads table with a SRID set already using EWKT format:
COPY roads (geom) FROM STDIN; SRID=4326;LINESTRING(0 0, 10 10) SRID=4326;LINESTRING(10 10, 15 0) \.
この関数は、以前のSRIDに関係なく、道路テーブルのSRIDを4326に変更します。
SELECT UpdateGeometrySRID('roads','geom',4326);
上述の例と、このDDL手続き (訳注: DDLはData Definition Languageの略で、データ構造の操作を行う言語を指し、この場合は CREATE TABLEやALTER TABLE等が該当します)とは同じです。
ALTER TABLE roads ALTER COLUMN geom TYPE geometry(MULTILINESTRING, 4326) USING ST_SetSRID(geom,4326);
ロードデータの変換座標系が誤りである (またはunknownになっている)けれどもWebメルカトルに一度の処理で変換したい場合、DDLで実行可能ですが、PostGIS管理関数では一度の処理ですむ等価なものはありません。
ALTER TABLE roads ALTER COLUMN geom TYPE geometry(MULTILINESTRING, 3857) USING ST_Transform(ST_SetSRID(geom,4326),3857) ;
ST_GeomCollFromText — Creates a GeometryCollection or Multi* geometry from a set of geometries.
geometry ST_GeomFromGeoJSON(
text geomjson)
;
geometry ST_GeomFromGeoJSON(
json geomjson)
;
geometry ST_GeomFromGeoJSON(
jsonb geomjson)
;
Collects geometries into a geometry collection. The result is either a Multi* or a GeometryCollection, depending on whether the input geometries have the same or different types (homogeneous or heterogeneous). The input geometries are left unchanged within the collection.
Variant 1: accepts two input geometries
Variant 2: accepts an array of geometries
Variant 3: aggregate function accepting a rowset of geometries.
![]() | |
If any of the input geometries are collections (Multi* or GeometryCollection) ST_Collect returns a GeometryCollection (since that is the only type which can contain nested collections). To prevent this, use ST_Dump in a subquery to expand the input collections to their atomic elements (see example below). |
![]() | |
ST_Collect and ST_Union appear similar, but in fact operate quite differently. ST_Collect aggregates geometries into a collection without changing them in any way. ST_Union geometrically merges geometries where they overlap, and splits linestrings at intersections. It may return single geometries when it dissolves boundaries. |
Availability: 1.4.0 - ST_MakeLine(geomarray)が導入されました。ST_MakeLine集約関数はより多くのポイントをより早く扱うための強化が施されています。
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
Collect 2D points.
SELECT ST_AsText( ST_Collect( ST_GeomFromText('POINT(1 2)'), ST_GeomFromText('POINT(-2 3)') )); st_astext ---------- MULTIPOINT(1 2,-2 3)
Collect 3D points.
SELECT ST_AsEWKT( ST_Collect( ST_GeomFromEWKT('POINT(1 2 3)'), ST_GeomFromEWKT('POINT(1 2 4)') ) ); st_asewkt ------------------------- MULTIPOINT(1 2 3,1 2 4)
Collect curves.
SELECT ST_AsText( ST_Collect( 'CIRCULARSTRING(220268 150415,220227 150505,220227 150406)', 'CIRCULARSTRING(220227 150406,2220227 150407,220227 150406)')); st_astext ------------------------------------------------------------------------------------ MULTICURVE(CIRCULARSTRING(220268 150415,220227 150505,220227 150406), CIRCULARSTRING(220227 150406,2220227 150407,220227 150406))
Using an array constructor for a subquery.
SELECT ST_Collect( ARRAY( SELECT the_geom FROM sometable ) );
Using an array constructor for values.
SELECT ST_AsText( ST_Collect( ARRAY[ ST_GeomFromText('LINESTRING(1 2, 3 4)'), ST_GeomFromText('LINESTRING(3 4, 4 5)') ] )) As wktcollect; --wkt collect -- MULTILINESTRING((1 2,3 4),(3 4,4 5))
ST_LineFromMultiPoint — マルチポイントジオメトリからラインストリングを生成します。
geometry ST_LineFromMultiPoint(
geometry aMultiPoint)
;
マルチポイントジオメトリからラインストリングを生成します。
X, Y, Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。
This function supports 3d and will not drop the z-index.
ST_MakeEnvelope — 与えられた最小値と最大値から長方形ポリゴンを生成します。入力値はSRIDで指定された空間参照系でなければなりません。
geometry ST_MakeEnvelope(
double precision xmin, double precision ymin, double precision xmax, double precision ymax, integer srid=unknown)
;
与えられた最小値と最大値から長方形ポリゴンを生成します。入力値はSRIDで指定された空間参照系でなければなりません。SRIDが指定されない場合には、不明な空間参照系と仮定します。
Availability: 1.5
Enhanced: 2.0 SRID指定なしでエンベロープを指定できるようになりました。
ST_MakeLine — ポイント、マルチポイント、ラインジオメトリからラインストリングを生成します。
geometry ST_MakeLine(
geometry set geoms)
;
geometry ST_MakeLine(
geometry geom1, geometry geom2)
;
geometry ST_MakeLine(
geometry[] geoms_array)
;
Creates a LineString containing the points of Point, MultiPoint, or LineString geometries. Other geometry types cause an error.
Variant 1: accepts two input geometries
Variant 2: accepts an array of geometries
Variant 3: aggregate function accepting a rowset of geometries. To ensure the order of the input geometries use ORDER BY
in the function call, or a subquery with an ORDER BY
clause.
Repeated nodes at the beginning of input LineStrings are collapsed to a single point. Repeated points in Point and MultiPoint inputs are not collapsed. ST_RemoveRepeatedPoints can be used to collapse repeated points from the output LineString.
This function supports 3d and will not drop the z-index.
Availability: 2.3.0 - マルチポイントの入力要素に対応するようになりました。
Availability: 2.0.0 - ラインストリング入力要素が導入されました。
Availability: 1.4.0 - ST_MakeLine(geomarray)が導入されました。ST_MakeLine集約関数はより多くのポイントをより早く扱うための強化が施されています。
Create a line composed of two points.
SELECT ST_AsText( ST_MakeLine(ST_MakePoint(1,2), ST_MakePoint(3,4)) ); st_astext --------------------- LINESTRING(1 2,3 4)
与えられた二つの3次元ポイントジオメトリから定義されるBOX3Dを生成します。
SELECT ST_AsEWKT( ST_MakeLine(ST_MakePoint(1,2,3), ST_MakePoint(3,4,5) )); st_asewkt ------------------------- LINESTRING(1 2 3,3 4 5)
ポイント、マルチポイント、ラインジオメトリからラインストリングを生成します。
select ST_AsText( ST_MakeLine( 'LINESTRING(0 0, 1 1)', 'LINESTRING(2 2, 3 3)' ) ); st_astext ----------------------------- LINESTRING(0 0,1 1,2 2,3 3)
Create a line from an array formed by a subquery with ordering.
SELECT ST_MakeLine( ARRAY( SELECT ST_Centroid(the_geom) FROM visit_locations ORDER BY visit_time) );
Create a 3D line from an array of 3D points
SELECT ST_MakeLine(ARRAY(SELECT ST_Centroid(the_geom) FROM visit_locations ORDER BY visit_time)); -- 三つの3次元ポイントから3次元ラインを生成 SELECT ST_AsEWKT(ST_MakeLine(ARRAY[ST_MakePoint(1,2,3), ST_MakePoint(3,4,5), ST_MakePoint(6,6,6)])); st_asewkt ------------------------- LINESTRING(1 2 3,3 4 5,6 6 6)
この例では、GPS位置の順列を取り、ジオメトリフィールドがGPSポイントからなるラインストリングで行程順になるよう、行程ごとに一つのレコードを生成します。
Using aggregate ORDER BY
provides a correctly-ordered linestring.
SELECT gps.track_id, ST_MakeLine(gps.geom ORDER BY gps_time) As geom FROM gps_points As gps GROUP BY track_id;
Prior to PostgreSQL 9, ordering in a subquery can be used. However, sometimes the query plan may not respect the order of the subquery.
-- PostgreSQL 9.0より前の版 - これは普通に動きますが、 -- プランナが副問い合わせの並び順を尊重しない選択を発生させることがあります。 SELECT gps.gps_track, ST_MakeLine(gps.the_geom) As newgeom FROM (SELECT gps_track, gps_time, the_geom FROM gps_points ORDER BY gps_track, gps_time) As gps GROUP BY gps.gps_track;
ST_MakePoint — 2次元、XYZの3次元または4次元のポイントジオメトリを生成します。
geometry ST_Point(
float x_lon, float y_lat)
;
geometry ST_MakePointM(
float x, float y, float m)
;
geometry ST_MakePoint(
double precision x, double precision y, double precision z, double precision m)
;
2次元、XYZの3次元または4次元のポイントジオメトリを生成します。
X, Y, Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。
2次元、XYZの3次元、4次元 (M値を持つジオメトリ)のポイントジオメトリを生成します。ST_MakePoint
はOGC準拠ではありませんが、一般的に???や???より速く、高精度です。また、WKTでなく生の座標値を持っている場合は扱いやすいです。
![]() | |
For geodetic coordinates, |
This function supports 3d and will not drop the z-index.
-- SRID不明のポイントを返します SELECT ST_MakePoint(-71.1043443253471, 42.3150676015829); -- WGS 84経度緯度とするポイントを返します。 SELECT ST_SetSRID(ST_MakePoint(-71.1043443253471, 42.3150676015829),4326); -- 3次元ポイント (たとえば標高を持つ)を返します SELECT ST_MakePoint(1, 2,1.5); -- ポイントのZ値を得ます SELECT ST_Z(ST_MakePoint(1, 2,1.5)); result ------- 1.5
ST_MakePointM — X, Y, M座標を持つポイントジオメトリを生成します。
geometry ST_MakePointM(
float x, float y, float m)
;
X, Y, M座標を持つポイントジオメトリを生成します。
X, Y, Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。
![]() | |
For geodetic coordinates, |
Create point with unknown SRID.
SELECT ST_AsEWKT( ST_MakePointM(-71.1043443253471, 42.3150676015829, 10) ); st_asewkt ----------------------------------------------- POINTM(-71.1043443253471 42.3150676015829 10)
X, Y, M座標を持つポイントジオメトリを生成します。
SELECT ST_AsEWKT( ST_SetSRID( ST_MakePointM(-71.104, 42.315, 10), 4326)); st_asewkt --------------------------------------------------------- SRID=4326;POINTM(-71.104 42.315 10)
Get measure of created point.
SELECT ST_M( ST_MakePointM(-71.104, 42.315, 10) ); result ------- 10
ST_MakePolygon — Creates a Polygon from a shell and optional list of holes.
geometry ST_MakePolygon(
geometry linestring)
;
geometry ST_MakePolygon(
geometry outerlinestring, geometry[] interiorlinestrings)
;
与えられた外環で形成されるポリゴンを生成します。入力ジオメトリは閉じたラインストリングでなければなりません。
Variant 1: Accepts one shell LineString.
Variant 2: Accepts a shell LineString and an array of inner (hole) LineStrings. A geometry array can be constructed using the PostgreSQL array_agg(), ARRAY[] or ARRAY() constructs.
![]() | |
この関数はマルチラインストリングを受け付けません。ST_LineMergeまたはST_Dumpでラインストリングを生成して下さい。 |
This function supports 3d and will not drop the z-index.
エンコード化ポリラインからラインストリングを生成します。
SELECT ST_MLineFromText('MULTILINESTRING((1 2, 3 4), (4 5, 6 7))');
Create a Polygon from an open LineString, using ST_StartPoint and ST_AddPoint to close it.
SELECT ST_MakePolygon( ST_AddPoint(foo.open_line, ST_StartPoint(foo.open_line)) ) FROM ( SELECT ST_GeomFromText('LINESTRING(75 29,77 29,77 29, 75 29)') As open_line) As foo;
エンコード化ポリラインからラインストリングを生成します。
SELECT ST_AsEWKT( ST_MakePolygon( 'LINESTRING(75.15 29.53 1,77 29 1,77.6 29.5 1, 75.15 29.53 1)')); st_asewkt ----------- POLYGON((75.15 29.53 1,77 29 1,77.6 29.5 1,75.15 29.53 1))
Create a Polygon from a LineString with measures
SELECT ST_AsEWKT( ST_MakePolygon( 'LINESTRINGM(75.15 29.53 1,77 29 1,77.6 29.5 2, 75.15 29.53 2)' )); st_asewkt ---------- POLYGONM((75.15 29.53 1,77 29 1,77.6 29.5 2,75.15 29.53 2))
蟻の穴を持つドーナツの生成です。
SELECT ST_MakePolygon( ST_ExteriorRing(ST_Buffer(foo.line,10)), ARRAY[ST_Translate(foo.line,1,1), ST_ExteriorRing(ST_Buffer(ST_MakePoint(20,20),1)) ] ) FROM (SELECT ST_ExteriorRing(ST_Buffer(ST_MakePoint(10,10),10,10)) As line ) As foo;
県ポリゴン/マルチポリゴンと水涯線から、湖を表現する穴を持つ県の境界を構築します。PostGISのST_Accumを使う例です。
![]() | |
NULL配列をST_MakePolygonに渡すとNULLを返すのでCASEを使います。 |
SELECT p.gid, p.province_name, CASE WHEN array_agg(w.the_geom) IS NULL THEN p.the_geom ELSE ST_MakePolygon( ST_LineMerge(ST_Boundary(p.the_geom)), array_agg(w.the_geom)) END FROM provinces p LEFT JOIN waterlines w ON (ST_Within(w.the_geom, p.the_geom) AND ST_IsClosed(w.the_geom)) GROUP BY p.gid, p.province_name, p.the_geom;
Another technique is to utilize a correlated subquery and the ARRAY() constructor that converts a row set to an array.
SELECT p.gid, p.province_name, CASE WHEN ST_Accum(w.the_geom) IS NULL THEN p.the_geom ELSE ST_MakePolygon(ST_LineMerge(ST_Boundary(p.the_geom)), ST_Accum(w.the_geom)) END FROM provinces p LEFT JOIN waterlines w ON (ST_Within(w.the_geom, p.the_geom) AND ST_IsClosed(w.the_geom)) GROUP BY p.gid, p.province_name, p.the_geom; -- 上と同じ例ですが、相関副問い合わせと行集合を -- 配列に変換するPostgreSQL組み込み関数ARRAY()を使っています。 SELECT p.gid, p.province_name, CASE WHEN EXISTS(SELECT w.the_geom FROM waterlines w WHERE ST_Within(w.the_geom, p.the_geom) AND ST_IsClosed(w.the_geom)) THEN ST_MakePolygon(ST_LineMerge(ST_Boundary(p.the_geom)), ARRAY(SELECT w.the_geom FROM waterlines w WHERE ST_Within(w.the_geom, p.the_geom) AND ST_IsClosed(w.the_geom))) ELSE p.the_geom END As the_geom FROM provinces p;
ST_Point — 与えられた座標値のST_Pointを返します。ST_MakePointのOGC別名です。
geometry ST_Point(
float x_lon, float y_lat)
;
与えられた座標値のST_Pointを返します。XとYを取るST_MakePointのMM対応の別名です。
![]() | |
For geodetic coordinates, |
This method implements the SQL/MM specification. SQL-MM 3: 6.1.2
SELECT CAST(ST_SetSRID(ST_Point(-71.1043443253471, 42.3150676015829),4326) As geography);
PostgreSQL also provides the ::
short-hand for casting
SELECT CAST(ST_SetSRID(ST_Point(-71.1043443253471, 42.3150676015829),4326) As geography);
If the point coordinates are not in a geodetic coordinate system (such as WGS84), then they must be reprojected before casting to a geography. In this example a point in Pennsylvania State Plane feet (SRID 2273) is projected to WGS84 (SRID 4326).
SELECT CAST(ST_SetSRID(ST_Point(-71.1043443253471, 42.3150676015829),4326) As geography);
ST_Polygon — Creates a Polygon from a LineString with a specified SRID.
geometry ST_Polygon(
geometry aLineString, integer srid)
;
Returns a polygon built from the given LineString and sets the spatial reference system from the srid
.
ST_Polygon is similar to ST_MakePolygon Variant 1 with the addition of setting the SRID.
, ST_MakePoint, ???
![]() | |
この関数はマルチラインストリングを受け付けません。ST_LineMergeまたはST_Dumpでラインストリングを生成して下さい。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 8.3.2
This function supports 3d and will not drop the z-index.
Create a 2D polygon.
SELECT ST_AsText( ST_Polygon('LINESTRING(75 29, 77 29, 77 29, 75 29)'::geometry, 4326) ); -- result -- POLYGON((75 29, 77 29, 77 29, 75 29))
Create a 3D polygon.
SELECT ST_AsEWKT( ST_Polygon( ST_GeomFromEWKT('LINESTRING(75 29 1, 77 29 2, 77 29 3, 75 29 1)'), 4326) ); -- result -- SRID=4326;POLYGON((75 29 1, 77 29 2, 77 29 3, 75 29 1))
ST_MakeEnvelope — Creates a rectangular Polygon in Web Mercator (SRID:3857) using the XYZ tile system.
geometry ST_MakePoint(
double precision x, double precision y, double precision z, double precision m)
;
Creates a rectangular Polygon in Web Mercator (SRID:3857) using the XYZ tile system. By default, the bounds are the in EPSG:3857 using the standard range of the Web Mercator system (-20037508.342789, 20037508.342789). The optional bounds parameter can be used to generate envelopes for any tiling scheme: provide a geometry that has the SRID and extent of the initial "zoom level zero" square within which the tile system is to be inscribed.
Availability: 2.1.0
SELECT ST_AsText( ST_TileEnvelope(2, 1, 1) ); st_astext ------------------------------ POLYGON((-10018754.1713945 0,-10018754.1713945 10018754.1713945,0 10018754.1713945,0 0,-10018754.1713945 0)) SELECT ST_AsText( ST_TileEnvelope(3, 1, 1, ST_MakeEnvelope(-180, -90, 180, 90, 4326) ) ); st_astext ------------------------------------------------------ POLYGON((-135 45,-135 67.5,-90 67.5,-90 45,-135 45))
ST_Geometry値の座標次元を返します。
ST_Geometry値の座標次元を返します。
geometry_dump
rows for the components of a geometry.geometry_dump
rows for the points in a geometry.geometry_dump
rows for the exterior and interior rings of a Polygon.LINESTRING
の始点と終点が一致する場合にTRUE
を返します。多面体サーフェスの場合は閉じているかどうか (ボリュームであるかどうか)を返します。 ST_Geometry値の座標次元を返します。
ジオメトリについての要約文を返します。
GeometryType — ST_Geometry値のジオメトリ型を返します。
text GeometryType(
geometry geomA)
;
ジオメトリ型を'LINESTRING', 'POLYGON', 'MULTIPOINT'などの文字列で返します。
OGC SPEC s2.1.1.1 - このジオメトリインスタンスがメンバーになっているジオメトリのインスタンス化可能な派生タイプの名前を返します。インスタンス化可能な派生タイプの名前は、文字列として返されます。
![]() | |
この関数は、'POINTM'等が返るので、ジオメトリがM値を持っているかどうかも示します。 |
Enhanced: 2.0.0 多面体サーフェス対応、三角対応、TIN対応が導入されました。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method supports Circular Strings and Curves
This function supports 3d and will not drop the z-index.
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
SELECT GeometryType(ST_GeomFromText('LINESTRING(77.29 29.07,77.42 29.26,77.27 29.31,77.29 29.07)')); geometrytype -------------- LINESTRING
SELECT ST_GeometryType(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')); -- 結果 -- POLYHEDRALSURFACE
SELECT GeometryType(geom) as result FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; result -------- TIN
ST_Boundary — ジオメトリの組み合わせ境界の閉包を返します。
geometry ST_Boundary(
geometry geomA)
;
ジオメトリの組み合わせ境界の閉包を返します (訳注: ラインストリングは端点、ポリゴンはエッジ、複合オブジェクトは境界のうち奇数番)。組み合わせ境界はOGC仕様の3.12.3.2節に記述されています。結果として出てくる境界は、OGC SPEC 3.12.2で議論されているように、ジオメトリプリミティブを使って表現できます。
GEOSモジュールによって実現しています。
![]() | |
2.0.0より前の版では、この関数は |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. OGC SPEC s2.1.1.1
This method implements the SQL/MM specification. SQL-MM 3: 5.1.14
This function supports 3d and will not drop the z-index.
Enhanced: 2.1.0で三角対応が導入されました。
![]() 境界ポイントを重ねたラインストリング
SELECT ST_Boundary(geom) FROM (SELECT 'LINESTRING(100 150,50 60, 70 80, 160 170)'::geometry As geom) As f;
-- ST_AsText 出力 MULTIPOINT(100 150,160 170)
| ![]() 境界マルチラインストリングを重ねたポリゴンの穴
SELECT ST_Boundary(geom) FROM (SELECT 'POLYGON (( 10 130, 50 190, 110 190, 140 150, 150 80, 100 10, 20 40, 10 130 ), ( 70 40, 100 50, 120 80, 80 110, 50 90, 70 40 ))'::geometry As geom) As f;
-- ST_AsText 出力 -- MULTILINESTRING((10 130,50 190,110 190,140 150,150 80,100 10,20 40,10 130), (70 40,100 50,120 80,80 110,50 90,70 40))
|
SELECT ST_AsText(ST_Boundary(ST_GeomFromText('LINESTRING(1 1,0 0, -1 1)'))); st_astext ----------- MULTIPOINT(1 1,-1 1) SELECT ST_AsText(ST_Boundary(ST_GeomFromText('POLYGON((1 1,0 0, -1 1, 1 1))'))); st_astext ---------- LINESTRING(1 1,0 0,-1 1,1 1) -- 3次元ポリゴンを使用 SELECT ST_AsEWKT(ST_Boundary(ST_GeomFromEWKT('POLYGON((1 1 1,0 0 1, -1 1 1, 1 1 1))'))); st_asewkt ----------------------------------- LINESTRING(1 1 1,0 0 1,-1 1 1,1 1 1) -- 3次元マルチラインストリングを使用 SELECT ST_AsEWKT(ST_Boundary(ST_GeomFromEWKT('MULTILINESTRING((1 1 1,0 0 0.5, -1 1 1),(1 1 0.5,0 0 0.5, -1 1 0.5, 1 1 0.5) )'))); st_asewkt ---------- MULTIPOINT(-1 1 1,1 1 0.75)
ST_CoordDim —
ST_Geometry値の座標次元を返します。
integer ST_CoordDim(
geometry geomA)
;
ST_Geometry値の座標次元を返します。
この関数はST_NDimsのMM対応の別名です。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 5.1.3
This method supports Circular Strings and Curves
This function supports 3d and will not drop the z-index.
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
ST_Dimension —
ST_Geometry値の座標次元を返します。
integer ST_Dimension(
geometry g)
;
ジオメトリの固有次元を返します。ジオメトリは座標次元以下でなければなりません。OGC SPEC s2.1.1.1 - 0ならPOINT
、1ならLINESTRING
、2ならPOLYGON
で、GEOMETRYCOLLECTION
の場合は要素ごとの次元の最大値です。不明なジオメトリ (空ジオメトリ)の場合はNULLが返ります。
This method implements the SQL/MM specification. SQL-MM 3: 5.1.2
Enhanced: 2.0.0 多面体サーフェス対応とTIN対応が導入されました。空ジオメトリを与えた場合に例外を投げなくなりました。
![]() | |
2.0.0より前では、空ジオメトリを与えると例外を投げていました。 |
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
ST_Dump — Returns a set of geometry_dump
rows for the components of a geometry.
geometry ST_Envelope(
geometry g1)
;
This is a set-returning function (SRF). It returns a set of geometry_dump rows, formed by a geometry (geom) and an array of integers (path). When the input geometry is a simple type (POINT,LINESTRING,POLYGON) a single record will be returned with an empty path array and the input geometry as geom. When the input geometry is a collection or multi it will return a record for each of the collection components, and the path will express the position of the component inside the collection.
ST_Dump is useful for expanding geometries. It is the reverse of a GROUP BY in that it creates new rows. For example it can be use to expand MULTIPOLYGONS into POLYGONS.
Enhanced: 2.0.0 多面体サーフェス対応、三角対応、TIN対応が導入されました。
Availability: PostGIS 1.0.0RC1. Requires PostgreSQL 7.3 or higher.
![]() | |
1.3.4より前では、曲線を含むジオメトリで使用すると、この関数はクラッシュします。これは1.3.4以上で訂正されています。 |
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
This function supports 3d and will not drop the z-index.
SELECT sometable.field1, sometable.field1, (ST_Dump(sometable.the_geom)).geom AS the_geom FROM sometable; -- Break a compound curve into its constituent linestrings and circularstrings SELECT ST_AsEWKT(a.geom), ST_HasArc(a.geom) FROM ( SELECT (ST_Dump(p_geom)).geom AS geom FROM (SELECT ST_GeomFromEWKT('COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))') AS p_geom) AS b ) AS a; st_asewkt | st_hasarc -----------------------------+---------- CIRCULARSTRING(0 0,1 1,1 0) | t LINESTRING(1 0,0 1) | f (2 rows)
-- 多面体サーフェスの例 -- 多面体サーフェスをフェイスに分解します。 SELECT ST_AsEWKT(ST_GeometryN(p_geom,3)) As geom_ewkt FROM (SELECT ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )') AS p_geom ) AS a; geom_ewkt ------------------------------------------ POLYGON((0 0 0,1 0 0,1 0 1,0 0 1,0 0 0))
-- TIN -- SELECT ST_AsEWKT(ST_GeometryN(geom,2)) as wkt FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; -- 結果-- wkt ------------------------------------- TRIANGLE((0 0 0,0 1 0,1 1 0,0 0 0))
ST_NumPoints — Returns a set of geometry_dump
rows for the points in a geometry.
geometry ST_Points(
geometry geom )
;
This set-returning function (SRF) returns a set of geometry_dump
rows formed by a geometry (geom
) and an array of integers (path
).
The geom
component of geometry_dump
are all the POINT
s that make up the supplied geometry
The path
component of geometry_dump
(an integer[]
) is an index reference enumerating the POINT
s of the supplied geometry. For example, if a LINESTRING
is supplied, a path of {i}
is returned where i
is the nth
coordinate in the LINESTRING
. If a POLYGON
is supplied, a path of {i,j}
is returned where i
is the ring number (1 is outer; inner rings follow) and j
enumerates the POINT
s (again 1-based index).
Enhanced: 2.1.0 Faster speed. Reimplemented as native-C.
Enhanced: 2.0.0 多面体サーフェス対応、三角対応、TIN対応が導入されました。
Availability: 1.2.2
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
This function supports 3d and will not drop the z-index.
SELECT edge_id, (dp).path[1] As index, ST_AsText((dp).geom) As wktnode FROM (SELECT 1 As edge_id , ST_DumpPoints(ST_GeomFromText('LINESTRING(1 2, 3 4, 10 10)')) AS dp UNION ALL SELECT 2 As edge_id , ST_DumpPoints(ST_GeomFromText('LINESTRING(3 5, 5 6, 9 10)')) AS dp ) As foo; edge_id | index | wktnode ---------+-------+-------------- 1 | 1 | POINT(1 2) 1 | 2 | POINT(3 4) 1 | 3 | POINT(10 10) 2 | 1 | POINT(3 5) 2 | 2 | POINT(5 6) 2 | 3 | POINT(9 10)
SELECT path, ST_AsText(geom) FROM ( SELECT (ST_DumpPoints(g.geom)).* FROM (SELECT 'GEOMETRYCOLLECTION( POINT ( 0 1 ), LINESTRING ( 0 3, 3 4 ), POLYGON (( 2 0, 2 3, 0 2, 2 0 )), POLYGON (( 3 0, 3 3, 6 3, 6 0, 3 0 ), ( 5 1, 4 2, 5 2, 5 1 )), MULTIPOLYGON ( (( 0 5, 0 8, 4 8, 4 5, 0 5 ), ( 1 6, 3 6, 2 7, 1 6 )), (( 5 4, 5 8, 6 7, 5 4 )) ) )'::geometry AS geom ) AS g ) j; path | st_astext -----------+------------ {1,1} | POINT(0 1) {2,1} | POINT(0 3) {2,2} | POINT(3 4) {3,1,1} | POINT(2 0) {3,1,2} | POINT(2 3) {3,1,3} | POINT(0 2) {3,1,4} | POINT(2 0) {4,1,1} | POINT(3 0) {4,1,2} | POINT(3 3) {4,1,3} | POINT(6 3) {4,1,4} | POINT(6 0) {4,1,5} | POINT(3 0) {4,2,1} | POINT(5 1) {4,2,2} | POINT(4 2) {4,2,3} | POINT(5 2) {4,2,4} | POINT(5 1) {5,1,1,1} | POINT(0 5) {5,1,1,2} | POINT(0 8) {5,1,1,3} | POINT(4 8) {5,1,1,4} | POINT(4 5) {5,1,1,5} | POINT(0 5) {5,1,2,1} | POINT(1 6) {5,1,2,2} | POINT(3 6) {5,1,2,3} | POINT(2 7) {5,1,2,4} | POINT(1 6) {5,2,1,1} | POINT(5 4) {5,2,1,2} | POINT(5 8) {5,2,1,3} | POINT(6 7) {5,2,1,4} | POINT(5 4) (29 rows)
-- Polyhedral surface cube -- SELECT (g.gdump).path, ST_AsEWKT((g.gdump).geom) as wkt FROM (SELECT ST_DumpPoints(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )') ) AS gdump ) AS g; -- result -- path | wkt ---------+-------------- {1,1,1} | POINT(0 0 0) {1,1,2} | POINT(0 0 1) {1,1,3} | POINT(0 1 1) {1,1,4} | POINT(0 1 0) {1,1,5} | POINT(0 0 0) {2,1,1} | POINT(0 0 0) {2,1,2} | POINT(0 1 0) {2,1,3} | POINT(1 1 0) {2,1,4} | POINT(1 0 0) {2,1,5} | POINT(0 0 0) {3,1,1} | POINT(0 0 0) {3,1,2} | POINT(1 0 0) {3,1,3} | POINT(1 0 1) {3,1,4} | POINT(0 0 1) {3,1,5} | POINT(0 0 0) {4,1,1} | POINT(1 1 0) {4,1,2} | POINT(1 1 1) {4,1,3} | POINT(1 0 1) {4,1,4} | POINT(1 0 0) {4,1,5} | POINT(1 1 0) {5,1,1} | POINT(0 1 0) {5,1,2} | POINT(0 1 1) {5,1,3} | POINT(1 1 1) {5,1,4} | POINT(1 1 0) {5,1,5} | POINT(0 1 0) {6,1,1} | POINT(0 0 1) {6,1,2} | POINT(1 0 1) {6,1,3} | POINT(1 1 1) {6,1,4} | POINT(0 1 1) {6,1,5} | POINT(0 0 1) (30 rows)
-- TIN -- SELECT ST_AsEWKT(ST_GeometryN(geom,2)) as wkt FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; -- 結果-- wkt ------------------------------------- TRIANGLE((0 0 0,0 1 0,1 1 0,0 0 0))
-- TIN -- SELECT ST_AsEWKT(ST_GeometryN(geom,2)) as wkt FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; -- 結果-- wkt ------------------------------------- TRIANGLE((0 0 0,0 1 0,1 1 0,0 0 0))
ST_NRings — Returns a set of geometry_dump
rows for the exterior and interior rings of a Polygon.
geometry ST_ExteriorRing(
geometry a_polygon)
;
This is a set-returning function (SRF). It returns a set of geometry_dump
rows, defined as an integer[]
and a geometry
, aliased "path" and "geom" respectively. The "path" field holds the polygon ring index containing a single integer: 0 for the shell,
>0 for holes. The "geom" field contains the corresponding ring as a polygon.
Availability: PostGIS 1.1.3. Requires PostgreSQL 7.3 or higher.
![]() | |
この関数はマルチポリゴンでは動作しません。マルチポリゴンに対してはST_Dumpを併用して下さい。 |
This function supports 3d and will not drop the z-index.
SELECT sometable.field1, sometable.field1, (ST_DumpRings(sometable.the_geom)).geom As the_geom FROM sometableOfpolys; SELECT ST_AsEWKT(geom) As the_geom, path FROM ST_DumpRings( ST_GeomFromEWKT('POLYGON((-8149064 5133092 1,-8149064 5132986 1,-8148996 5132839 1,-8148972 5132767 1,-8148958 5132508 1,-8148941 5132466 1,-8148924 5132394 1, -8148903 5132210 1,-8148930 5131967 1,-8148992 5131978 1,-8149237 5132093 1,-8149404 5132211 1,-8149647 5132310 1,-8149757 5132394 1, -8150305 5132788 1,-8149064 5133092 1), (-8149362 5132394 1,-8149446 5132501 1,-8149548 5132597 1,-8149695 5132675 1,-8149362 5132394 1))') ) as foo; path | the_geom ---------------------------------------------------------------------------------------------------------------- {0} | POLYGON((-8149064 5133092 1,-8149064 5132986 1,-8148996 5132839 1,-8148972 5132767 1,-8148958 5132508 1, | -8148941 5132466 1,-8148924 5132394 1, | -8148903 5132210 1,-8148930 5131967 1, | -8148992 5131978 1,-8149237 5132093 1, | -8149404 5132211 1,-8149647 5132310 1,-8149757 5132394 1,-8150305 5132788 1,-8149064 5133092 1)) {1} | POLYGON((-8149362 5132394 1,-8149446 5132501 1, | -8149548 5132597 1,-8149695 5132675 1,-8149362 5132394 1))
ST_EndPoint — ST_LineStringまたはST_CircularStringのポイント数を返します。
geometry ST_Points(
geometry geom )
;
LINESTRING
の最後のポイントをPOINT
で返します。パラメタがLINESTRING
でない場合はNULL
を返します。
This method implements the SQL/MM specification. SQL-MM 3: 7.1.4
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
![]() | |
Changed: 2.0.0では単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。古い挙動は記載されていませんでしたが、LINESTRINGとして格納されているデータを持っていると思われる人々は2.0でNULLが返って来ることを経験することでしょう。 |
postgis=# SELECT ST_AsText(ST_EndPoint('LINESTRING(1 1, 2 2, 3 3)'::geometry)); st_astext ------------ POINT(3 3) (1 row) postgis=# SELECT ST_EndPoint('POINT(1 1)'::geometry) IS NULL AS is_null; is_null ---------- t (1 row) -- 3次元の最後のポイント SELECT ST_AsEWKT(ST_EndPoint('LINESTRING(1 1 2, 1 2 3, 0 0 5)')); st_asewkt -------------- POINT(0 0 5) (1 row)
ST_Envelope — ジオメトリの浮動小数点数 (float8)バウンディングボックスを表現するジオメトリを返します。
geometry ST_Envelope(
geometry g1)
;
ジオメトリのfloat8数の最小バウンディングボックスをジオメトリとして返します。バウンディングボックスの角で定義されたポリゴンで、 ((MINX
, MINY
), (MINX
, MAXY
), (MAXX
, MAXY
), (MAXX
, MINY
), (MINX
, MINY
))となります。可能ならZMIN
/ZMAX
座標が追加されます。
縮退する場合 (縦のライン、ポイント)はPOLYGON
より低い次元のジオメトリ、すなわちPOINT
またはLINESTRING
を返します。
Availability: 1.5.0 挙動が変更され出力がfloat4からfloat8になりました。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. s2.1.1.1
This method implements the SQL/MM specification. SQL-MM 3: 5.1.15
SELECT ST_AsText(ST_Envelope('POINT(1 3)'::geometry)); st_astext ------------ POINT(1 3) (1 row) SELECT ST_AsText(ST_Envelope('LINESTRING(0 0, 1 3)'::geometry)); st_astext -------------------------------- POLYGON((0 0,0 3,1 3,1 0,0 0)) (1 row) SELECT ST_AsText(ST_Envelope('POLYGON((0 0, 0 1, 1.0000001 1, 1.0000001 0, 0 0))'::geometry)); st_astext -------------------------------------------------------------- POLYGON((0 0,0 1,1.00000011920929 1,1.00000011920929 0,0 0)) (1 row) SELECT ST_AsText(ST_Envelope('POLYGON((0 0, 0 1, 1.0000000001 1, 1.0000000001 0, 0 0))'::geometry)); st_astext -------------------------------------------------------------- POLYGON((0 0,0 1,1.00000011920929 1,1.00000011920929 0,0 0)) (1 row) SELECT Box3D(geom), Box2D(geom), ST_AsText(ST_Envelope(geom)) As envelopewkt FROM (SELECT 'POLYGON((0 0, 0 1000012333334.34545678, 1.0000001 1, 1.0000001 0, 0 0))'::geometry As geom) As foo;
ポイントとラインストリングの最小バウンディングボックス
SELECT ST_AsText(ST_Envelope( ST_Collect( ST_GeomFromText('LINESTRING(55 75,125 150)'), ST_Point(20, 80)) )) As wktenv; wktenv ----------- POLYGON((20 75,20 150,125 150,125 75,20 75))
ST_BoundingDiagonal — 与えられたジオメトリのバウンディングボックスの対角線を返します。
geometry ST_BoundingDiagonal(
geometry geom, boolean fits=false)
;
与えられたジオメトリのバウンディングボックスの対角線をラインストリングで返します。入力ジオメトリが空の場合には、対角線も空になります。その他の場合には、最小値のポイントを始点とし、最大値のポイントを終点とする、二つのポイントからなるラインストリングになります。
返されるラインストリングは常に、入力ジオメトリのSRIDと次元 (ZとMがあること)を維持します。
fits
パラメータは、最良適合が必要かどうかを指定するものです。FALSEの場合には、幾分大きめなバウンディングボックスの対角線を受け付けることができます (多数の頂点からなるジオメトリの取得が早くなります)。いずれにしても返された対角線のバウンディングボックスは常に入力ジオメトリを含みます。
![]() | |
縮退した (入力の頂点が一つ)場合、返されるラインストリングはトポロジ的に不正です (内部が無い)。返り値を意味的な不正にはしません。 |
Availability: 2.2.0
This function supports 3d and will not drop the z-index.
This function supports M coordinates.
ST_ExteriorRing — ポリゴンジオメトリの内環の数を返します。
geometry ST_ExteriorRing(
geometry a_polygon)
;
POLYGON
の外環を表現するラインストリングを返します。ジオメトリがポリゴンでない場合はNULLを返します。
![]() | |
POLYGONタイプでのみ動作します。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. 2.1.5.1
This method implements the SQL/MM specification. SQL-MM 3: 8.2.3, 8.3.3
This function supports 3d and will not drop the z-index.
-- ポリゴンのテーブルを持っているとします SELECT gid, ST_ExteriorRing(the_geom) AS ering FROM sometable; -- マルチポリゴンのテーブルを持っていて、 -- それぞれのポリゴンの外環からなるマルチラインストリングを返させたいとします。 SELECT gid, ST_Collect(ST_ExteriorRing(the_geom)) AS erings FROM (SELECT gid, (ST_Dump(the_geom)).geom As the_geom FROM sometable) As foo GROUP BY gid; --3次元の例 SELECT ST_AsEWKT( ST_ExteriorRing( ST_GeomFromEWKT('POLYGON((0 0 1, 1 1 1, 1 2 1, 1 1 1, 0 0 1))') ) ); st_asewkt --------- LINESTRING(0 0 1,1 1 1,1 2 1,1 1 1,0 0 1)
ST_GeometryN — ST_Geometry値のジオメトリ型を返します。
geometry ST_GeometryN(
geometry geomA, integer n)
;
GEOMETRYCOLLECTION, (MULTI)POINT, (MULTI)LINESTRING, MULTICURVE, (MULTI)POLYGON, POLYHEDRALSURFACEの場合には、1始まりでN番目のジオメトリを返します。それ以外の場合にはNULLを返します。
![]() | |
OGC仕様のため0.8.0版からインデクスを1始まりにしています。これより前の版では0始まりになっています。 |
![]() | |
一つのジオメトリから全てのジオメトリを抽出したい場合は、ST_Dumpを使う方が効果的ですし、単一ジオメトリにも対応しています。 |
Enhanced: 2.0.0 多面体サーフェス対応、三角対応、TIN対応が導入されました。
Changed: 2.0.0 以前の版では非マルチのジオメトリではNULLが返りました。ST_GeometryN(..,1)の場合にはジオメトリを返すよう変更されました。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 9.1.5
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
-- 3次元マルチポイントから部分集合を抽出 SELECT n, ST_AsEWKT(ST_GeometryN(the_geom, n)) As geomewkt FROM ( VALUES (ST_GeomFromEWKT('MULTIPOINT(1 2 7, 3 4 7, 5 6 7, 8 9 10)') ), ( ST_GeomFromEWKT('MULTICURVE(CIRCULARSTRING(2.5 2.5,4.5 2.5, 3.5 3.5), (10 11, 12 11))') ) )As foo(the_geom) CROSS JOIN generate_series(1,100) n WHERE n <= ST_NumGeometries(the_geom); n | geomewkt ---+----------------------------------------- 1 | POINT(1 2 7) 2 | POINT(3 4 7) 3 | POINT(5 6 7) 4 | POINT(8 9 10) 1 | CIRCULARSTRING(2.5 2.5,4.5 2.5,3.5 3.5) 2 | LINESTRING(10 11,12 11) -- 全てのジオメトリを抽出(idを付けたい場合に便利です) SELECT gid, n, ST_GeometryN(the_geom, n) FROM sometable CROSS JOIN generate_series(1,100) n WHERE n <= ST_NumGeometries(the_geom);
-- 多面体サーフェスの例 -- 多面体サーフェスをフェイスに分解します。 SELECT ST_AsEWKT(ST_GeometryN(p_geom,3)) As geom_ewkt FROM (SELECT ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )') AS p_geom ) AS a; geom_ewkt ------------------------------------------ POLYGON((0 0 0,1 0 0,1 0 1,0 0 1,0 0 0))
-- TIN -- SELECT ST_AsEWKT(ST_GeometryN(geom,2)) as wkt FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; -- 結果-- wkt ------------------------------------- TRIANGLE((0 0 0,0 1 0,1 1 0,0 0 0))
ST_GeometryType — ST_Geometry値のジオメトリ型を返します。
text ST_GeometryType(
geometry g1)
;
ジオメトリ型を'ST_Linestring', 'ST_Polygon', 'ST_MultiPolygon'等の文字列で返します。この関数はGeometryType(geometry)とは異なり、先頭に'ST'が付き、M値を持っているかを示しません。
Enhanced: 2.0.0 多面体サーフェス対応が導入されました。
This method implements the SQL/MM specification. SQL-MM 3: 5.1.4
This function supports 3d and will not drop the z-index.
This function supports Polyhedral surfaces.
SELECT ST_GeometryType(ST_GeomFromText('LINESTRING(77.29 29.07,77.42 29.26,77.27 29.31,77.29 29.07)')); -- 結果 ST_LineString
SELECT ST_GeometryType(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')); --結果 -- ST_PolyhedralSurface
SELECT ST_GeometryType(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')); --結果 -- ST_PolyhedralSurface
SELECT ST_GeometryType(geom) as result FROM (SELECT ST_GeomFromEWKT('TIN ((( 0 0 0, 0 0 1, 0 1 0, 0 0 0 )), (( 0 0 0, 0 1 0, 1 1 0, 0 0 0 )) )') AS geom ) AS g; result -------- ST_Tin
ST_HasArc — Tests if a geometry contains a circular arc
boolean ST_IsEmpty(
geometry geomA)
;
ジオメトリが、空のジオメトリコレクション、ポリゴン、ポイント等の場合に、trueを返します。
Availability: 1.2.2
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
ST_InteriorRingN — ポリゴンジオメトリの内環の数を返します。
geometry ST_InteriorRingN(
geometry a_polygon, integer n)
;
ポリゴンのN番目の内環となるラインストリングを返します。ジオメトリがポリゴンでないかNが範囲外の場合はNULLを返します。1始まりです。
![]() | |
この関数はマルチポリゴンでは動作しません。マルチポリゴンに対してはST_Dumpを併用して下さい。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 8.2.6, 8.3.5
This function supports 3d and will not drop the z-index.
ST_IsPolygonCCW — 全ての外環が反時計回りで、全ての内環が時計回りならTRUEを返します。
boolean ST_IsPolygonCCW (
geometry geom )
;
入力ジオメトリの全てのポリゴン要素の外環については反時計回りで、全ての内環については時計回りである場合には、TRUEを返します。
ジオメトリがポリゴン要素を持っていない場合にはTRUEを返します。
![]() | |
閉じたラインストリングはポリゴン要素とみなされません。単一の閉じたラインストリングを渡すと、右回り左回りにかかわらずTRUEが得られます。 |
![]() | |
ポリゴン要素の内環が逆回りになっていない (すなわち外環と同じ方向で回る内環が1個以上ある)場合には、ST_IsPolygonCWとST_IsPolygonCCW の両方ともにFALSEを返します。 |
Availability: 2.2.0
This function supports 3d and will not drop the z-index.
This function supports M coordinates.
ST_IsPolygonCW — 入力ジオメトリの全てのポリゴン要素の外環については時計回りで、全ての内環については反時計回りである場合には、TRUEを返します。
boolean ST_IsPolygonCW (
geometry geom )
;
入力ジオメトリの全てのポリゴン要素の外環については時計回りで、全ての内環については反時計回りである場合には、TRUEを返します。
ジオメトリがポリゴン要素を持っていない場合にはTRUEを返します。
![]() | |
閉じたラインストリングはポリゴン要素とみなされません。単一の閉じたラインストリングを渡すと、右回り左回りにかかわらずTRUEが得られます。 |
![]() | |
ポリゴン要素の内環が逆回りになっていない (すなわち外環と同じ方向で回る内環が1個以上ある)場合には、ST_IsPolygonCWとST_IsPolygonCCW の両方ともにFALSEを返します。 |
Availability: 2.2.0
This function supports 3d and will not drop the z-index.
This function supports M coordinates.
ST_IsClosed — LINESTRING
の始点と終点が一致する場合にTRUE
を返します。多面体サーフェスの場合は閉じているかどうか (ボリュームであるかどうか)を返します。
boolean ST_IsClosed(
geometry g)
;
LINESTRING
の始点と終点が一致する場合にTRUE
を返します。多面体サーフェスの場合は面であるか (開いているか)、またはボリュームであるか (閉じているか)を返します。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 7.1.5, 9.3.3
![]() | |
SQL-MMでは |
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
Enhanced: 2.0.0 多面体サーフェス対応が導入されました。
This function supports Polyhedral surfaces.
postgis=# SELECT ST_IsClosed('LINESTRING(0 0, 1 1)'::geometry); st_isclosed ------------- f (1 row) postgis=# SELECT ST_IsClosed('LINESTRING(0 0, 0 1, 1 1, 0 0)'::geometry); st_isclosed ------------- t (1 row) postgis=# SELECT ST_IsClosed('MULTILINESTRING((0 0, 0 1, 1 1, 0 0),(0 0, 1 1))'::geometry); st_isclosed ------------- f (1 row) postgis=# SELECT ST_IsClosed('POINT(0 0)'::geometry); st_isclosed ------------- t (1 row) postgis=# SELECT ST_IsClosed('MULTIPOINT((0 0), (1 1))'::geometry); st_isclosed ------------- t (1 row)
-- 立方体 -- SELECT ST_IsClosed(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')); st_isclosed ------------- t -- 立方体のようなものだけれども側面が一つ無いもの-- SELECT ST_IsClosed(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)) )')); st_isclosed ------------- f
ST_IsCollection — ジオメトリが、空のジオメトリコレクション、ポリゴン、ポイント等の場合に、trueを返します。
boolean ST_IsCollection(
geometry g)
;
引数が次のいずれかの場合にはTRUE
を返します。
ジオメトリコレクション
マルチポイント、マルチポリゴン、マルチラインストリング、マルチ曲線、マルチサーフェス
複合曲線
![]() | |
この関数はジオメトリのタイプを解析します。これは、空のコレクションである場合、または一つのエレメントを持つコレクションである場合には |
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
postgis=# SELECT ST_IsCollection('LINESTRING(0 0, 1 1)'::geometry); st_iscollection ------------- f (1 row) postgis=# SELECT ST_IsCollection('MULTIPOINT EMPTY'::geometry); st_iscollection ------------- t (1 row) postgis=# SELECT ST_IsCollection('MULTIPOINT((0 0))'::geometry); st_iscollection ------------- t (1 row) postgis=# SELECT ST_IsCollection('MULTIPOINT((0 0), (42 42))'::geometry); st_iscollection ------------- t (1 row) postgis=# SELECT ST_IsCollection('GEOMETRYCOLLECTION(POINT(0 0))'::geometry); st_iscollection ------------- t (1 row)
ST_IsEmpty — Tests if a geometry is empty.
boolean ST_IsEmpty(
geometry geomA)
;
ジオメトリが空ジオメトリの場合にtrueを返します。 trueの場合には、このジオメトリは、空のジオメトリコレクション、ポリゴン、ポイント等です。
![]() | |
SQL-MMでは、ST_IsEmpty(NULL)は0を返しますが、PostGISではNULLを返します。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. s2.1.1.1
This method implements the SQL/MM specification. SQL-MM 3: 5.1.7
This method supports Circular Strings and Curves
![]() | |
Changed: 2.0.0 以前の版のPostGISではST_GeomFromText('GEOMETRYCOLLECTION(EMPTY)')を許しました。PostGIS 2.0.0では、SQL/MM標準により準拠させるため、これは不正となります。 |
SELECT ST_IsEmpty(ST_GeomFromText('GEOMETRYCOLLECTION EMPTY')); st_isempty ------------ t (1 row) SELECT ST_IsEmpty(ST_GeomFromText('POLYGON EMPTY')); st_isempty ------------ t (1 row) SELECT ST_IsEmpty(ST_GeomFromText('POLYGON((1 2, 3 4, 5 6, 1 2))')); st_isempty ------------ f (1 row) SELECT ST_IsEmpty(ST_GeomFromText('POLYGON((1 2, 3 4, 5 6, 1 2))')) = false; ?column? ---------- t (1 row) SELECT ST_IsEmpty(ST_GeomFromText('CIRCULARSTRING EMPTY')); st_isempty ------------ t (1 row)
ST_IsRing — Tests if a LineString is closed and simple.
boolean ST_IsRing(
geometry g)
;
LINESTRING
がST_IsClosed (ST_StartPoint(
g
)~=
ST_Endpoint(
)で、かつST_IsSimple (自己インタセクションが無い)場合にg
)TRUE
を返します。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. 2.1.5.1
This method implements the SQL/MM specification. SQL-MM 3: 7.1.6
![]() | |
SQL-MMでは、 |
SELECT ST_IsRing(the_geom), ST_IsClosed(the_geom), ST_IsSimple(the_geom) FROM (SELECT 'LINESTRING(0 0, 0 1, 1 1, 1 0, 0 0)'::geometry AS the_geom) AS foo; st_isring | st_isclosed | st_issimple -----------+-------------+------------- t | t | t (1 row) SELECT ST_IsRing(the_geom), ST_IsClosed(the_geom), ST_IsSimple(the_geom) FROM (SELECT 'LINESTRING(0 0, 0 1, 1 0, 1 1, 0 0)'::geometry AS the_geom) AS foo; st_isring | st_isclosed | st_issimple -----------+-------------+------------- f | t | f (1 row)
ST_IsSimple — ジオメトリが自己インタセクションや自己接触のような異常な幾何学ポイントを持っていない場合にTRUEを返します。
boolean ST_IsSimple(
geometry geomA)
;
ジオメトリが自己インタセクションや自己接触のような異常な幾何学ポイントを持っていない場合にTRUEを返します。OGCのジオメトリ単純性と妥当性の定義に関する詳細情報については「ジオメトリのOpenGIS準拠を確実にする」をご覧ください。
![]() | |
SQL-MMでは、ST_IsSimple(NULL)は0を返しますが、PostGISではNULLを返します。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1. s2.1.1.1
This method implements the SQL/MM specification. SQL-MM 3: 5.1.8
This function supports 3d and will not drop the z-index.
ST_M — Returns the M coordinate of a Point.
float ST_M(
geometry a_point)
;
ポイントのM座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。
![]() | |
これは (いまだに)OGC仕様に入っていませんが、ポイント座標抽出関数のリストを完全にするために挙げています。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification.
This function supports 3d and will not drop the z-index.
ST_MemSize — ST_Geometry値のジオメトリ型を返します。
integer ST_NRings(
geometry geomA)
;
ST_Geometry値のジオメトリ型を返します。
This complements the PostgreSQL built-in database object functions pg_column_size, pg_size_pretty, pg_relation_size, pg_total_relation_size.
![]() | |
pg_relation_size which gives the byte size of a table may return byte size lower than ST_MemSize. This is because pg_relation_size does not add toasted table contribution and large geometries are stored in TOAST tables. pg_total_relation_size - includes, the table, the toasted tables, and the indexes. pg_column_size returns how much space a geometry would take in a column considering compression, so may be lower than ST_MemSize |
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
Changed: 2.2.0 name changed to ST_MemSize to follow naming convention. In prior versions this function was called ST_Mem_Size, old name deprecated though still available.
--Return how much byte space Boston takes up in our Mass data set SELECT pg_size_pretty(SUM(ST_MemSize(the_geom))) as totgeomsum, pg_size_pretty(SUM(CASE WHEN town = 'BOSTON' THEN ST_MemSize(the_geom) ELSE 0 END)) As bossum, CAST(SUM(CASE WHEN town = 'BOSTON' THEN ST_MemSize(the_geom) ELSE 0 END)*1.00 / SUM(ST_MemSize(the_geom))*100 As numeric(10,2)) As perbos FROM towns; totgeomsum bossum perbos ---------- ------ ------ 1522 kB 30 kB 1.99 SELECT ST_MemSize(ST_GeomFromText('CIRCULARSTRING(220268 150415,220227 150505,220227 150406)')); --- 73 --What percentage of our table is taken up by just the geometry SELECT pg_total_relation_size('public.neighborhoods') As fulltable_size, sum(ST_MemSize(the_geom)) As geomsize, sum(ST_MemSize(the_geom))*1.00/pg_total_relation_size('public.neighborhoods')*100 As pergeom FROM neighborhoods; fulltable_size geomsize pergeom ------------------------------------------------ 262144 96238 36.71188354492187500000
ST_NDims —
ST_Geometry値の座標次元を返します。
integer ST_NDims(
geometry g1)
;
ジオメトリの座標次元返します。PostGISでは、2 - (X,Y), 3 - (X,Y,Z), (X,Y,M), 4 - (X,Y,Z,M)に対応しています。
This function supports 3d and will not drop the z-index.
ST_NPoints — ジオメトリのポイント (頂点)数を返します。
integer ST_NPoints(
geometry g1)
;
ジオメトリのポイントの数を返します。全てのジオメトリに対して動作します。
Enhanced: 2.0.0 多面体サーフェス対応が導入されました。
![]() | |
1.3.4より前では、曲線を含むジオメトリで使用すると、この関数はクラッシュします。これは1.3.4以上で訂正されています。 |
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
ST_NRings — ポリゴンジオメトリの内環の数を返します。
integer ST_NRings(
geometry geomA)
;
ジオメトリがポリゴンまたはマルチポリゴンの場合、リング数を返します。NumInteriorRingsと違い、外環も数えます。
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
ST_NumGeometries — ジオメトリのポイントの数を返します。全てのジオメトリに対して動作します。
integer ST_NumGeometries(
geometry geom)
;
ジオメトリの数を返します。ジオメトリがジオメトリコレクションまたはマルチ系の場合は、ジオメトリの数を返し、単一のジオメトリの場合は1を返し、それ以外の場合はNULLを返します。
Enhanced: 2.0.0 多面体サーフェス対応、三角対応、TIN対応が導入されました。
Changed: 2.0.0 前の版では、ジオメトリがコレクション/マルチ系でない場合にはNULLを返しました。2.0.0以上では、POLYGON, LINESTRING, POINTといった単一ジオメトリについては1を返します。
This method implements the SQL/MM specification. SQL-MM 3: 9.1.4
This function supports 3d and will not drop the z-index.
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
-- 以前の版ではNULLが返りました -- 2.0.0から1が返ります SELECT ST_NumGeometries(ST_GeomFromText('LINESTRING(77.29 29.07,77.42 29.26,77.27 29.31,77.29 29.07)')); -- 結果 1 -- ジオメトリコレクションの例 -- - マルチ系はコレクションで一つのジオメトリと数えます。 SELECT ST_NumGeometries(ST_GeomFromEWKT('GEOMETRYCOLLECTION(MULTIPOINT(-2 3 , -2 2), LINESTRING(5 5 ,10 10), POLYGON((-7 4.2,-7.1 5,-7.1 4.3,-7 4.2)))')); -- 結果 3
ST_NumInteriorRings — ポリゴンジオメトリの内環の数を返します。
integer ST_NumInteriorRings(
geometry a_polygon)
;
ポリゴンジオメトリの内環の数を返します。ジオメトリがポリゴンでない場合には、NULLを返します。
This method implements the SQL/MM specification. SQL-MM 3: 8.2.5
Changed: 2.0.0 - 以前の版では、MULTIPOLYGONを渡して最初のPOLYGONの内環の数を返すことができました。
-- 通常のポリゴンの場合 SELECT gid, field1, field2, ST_NumInteriorRings(the_geom) AS numholes FROM sometable; -- マルチポリゴンの内環の総数を知りたい場合 SELECT gid, field1, field2, SUM(ST_NumInteriorRings(the_geom)) AS numholes FROM (SELECT gid, field1, field2, (ST_Dump(the_geom)).geom As the_geom FROM sometable) As foo GROUP BY gid, field1,field2;
ST_NumInteriorRing — ジオメトリ内のポリゴンの内環の数を返します。ST_NumInteriorRingsと同義です。
integer ST_NumInteriorRing(
geometry a_polygon)
;
ST_NumPatches — 多面体サーフェスのフェイス数を返します。多面体でないジオメトリの場合にはNULLを返します。
integer ST_NumPatches(
geometry g1)
;
多面体サーフェスのフェイス数を返します。多面体でないジオメトリの場合にはNULLを返します。ST_NumGeometriesの別名で、MMの名前付けに対応するためのものです。MM規約を気にしない場合はST_NumGeometriesの方が速いです。
Availability: 2.0.0
This function supports 3d and will not drop the z-index.
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: ?
This function supports Polyhedral surfaces.
SELECT ST_NumPatches(ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')); -- 結果 -- 6
ST_NumPoints — ST_LineStringまたはST_CircularStringのポイント数を返します。
integer ST_NumPoints(
geometry g1)
;
ST_LineStringまたはST_CircularStringのポイント数を返します。1.4より前は仕様通りにラインストリングにのみ対応していました。1.4以上ではラインストリングだけでなく頂点数を返すST_NPointsの別名です。多目的で多数のジオメトリタイプで動作するST_NPointsを使うことを考えて下さい。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 7.2.4
ST_PatchN — ST_Geometry値のジオメトリ型を返します。
geometry ST_PatchN(
geometry geomA, integer n)
;
>ジオメトリがPOLYHEDRALSURFACEかPOLYHEDRALSURFACEMの場合には、1始まりでN番目のジオメトリ (フェイス)を返します。それ以外の場合には、NULLを返します。多面体サーフェスを引数にとるST_GeometryNと同じ答えが返ります。ST_GeometryNの方が速いです。
![]() | |
インデクスは1始まりです。 |
![]() | |
一つのジオメトリから全てのジオメトリを抽出したい場合は、ST_Dumpを使う方が効率的です。 |
Availability: 2.0.0
This method implements the SQL/MM specification. SQL-MM 3: ?
This function supports 3d and will not drop the z-index.
This function supports Polyhedral surfaces.
-- 多面体サーフェスの2番目のフェイスを抽出 SELECT ST_AsEWKT(ST_PatchN(geom, 2)) As geomewkt FROM ( VALUES (ST_GeomFromEWKT('POLYHEDRALSURFACE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )')) ) As foo(geom); geomewkt ---+----------------------------------------- POLYGON((0 0 0,0 1 0,1 1 0,1 0 0,0 0 0))
ST_PointN — ST_LineStringまたはST_CircularStringのポイント数を返します。
geometry ST_PointN(
geometry a_linestring, integer n)
;
ラインストリングまたは曲線ストリングのN番目の点を返します。負数はラインストリングの終端から逆方向に遡って数えます。-1は終端を指します。ジオメトリにラインストリングが無い場合には、NULLを返します。
![]() | |
OGC仕様のため0.8.0版からインデックスを1始まりにしています。これより前の版では0はじまりになっています。後方インデックス (負数インデックス)はOGC仕様ではありません。 |
![]() | |
マルチラインストリングからN番目のポイントを得たい場合には、ST_Dumpを併用して下さい。 |
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 7.2.5, 7.3.5
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
![]() | |
Changed: 2.0.0 単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。 Changed: 2.3.0 : 負数インデックスが有効になりました (-1は終端を指します) |
-- LINESTRINGから全てのPOINTを抽出 SELECT ST_AsText( ST_PointN( column1, generate_series(1, ST_NPoints(column1)) )) FROM ( VALUES ('LINESTRING(0 0, 1 1, 2 2)'::geometry) ) AS foo; st_astext ------------ POINT(0 0) POINT(1 1) POINT(2 2) (3 rows) -- CIRCULARSTRINGの例 SELECT ST_AsText(ST_PointN(ST_GeomFromText('CIRCULARSTRING(1 2, 3 2, 1 2)'),2)); st_astext ---------- POINT(3 2) SELECT st_astext(f) FROM ST_GeometryFromtext('LINESTRING(0 0 0, 1 1 1, 2 2 2)') as g ,ST_PointN(g, -2) AS f -- 1 based index st_astext ---------- "POINT Z (1 1 1)"
ST_Points — ジオメトリの全ての座標値からなるマルチポイントを返します。
geometry ST_Points(
geometry geom )
;
ジオメトリの全ての座標値からなるマルチポイントを返します。入力ジオメトリの重複ポイントを削除せず、環ジオメトリの開始点と終了点も削除しません (この挙動を望まない場合にはST_RemoveRepeatedPointsを使って消します)。
M値とZ値は、存在する場合には保存されます。
This method supports Circular Strings and Curves
This function supports 3d and will not drop the z-index.
Availability: 2.3.0
ST_StartPoint — Returns the first point of a LineString.
geometry ST_StartPoint(
geometry geomA)
;
LINESTRING
またはCIRCULARLINESTRING
ジオメトリの、最初のポイントをPOINT
で返します。入力パラメータがLINESTRING
でもCIRCULARLINESTRING
でもない場合には、NULL
を返します。
This method implements the SQL/MM specification. SQL-MM 3: 7.1.3
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
![]() | |
Changed: 2.0.0では単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。古い挙動は記載されていませんでしたが、LINESTRINGとして格納されているデータを持っていると思われる人々は2.0でNULLが返って来ることを経験することでしょう。 |
SELECT ST_AsText(ST_StartPoint('LINESTRING(0 1, 0 2)'::geometry)); st_astext ------------ POINT(0 1) (1 row) SELECT ST_StartPoint('POINT(0 1)'::geometry) IS NULL AS is_null; is_null ---------- t (1 row) -- 3次元ライン -- SELECT ST_AsEWKT(ST_StartPoint('LINESTRING(0 1 1, 0 2 2)'::geometry)); st_asewkt ------------ POINT(0 1 1) (1 row) -- 曲線ストリング -- SELECT ST_AsText(ST_StartPoint('CIRCULARSTRING(5 2,-3 1.999999, -2 1, -4 2, 5 2)'::geometry)); st_astext ------------ POINT(5 2)
ST_Summary —
ジオメトリについての要約文を返します。
text ST_Summary(
geometry g)
;
text ST_Summary(
geography g)
;
ジオメトリについての要約文を返します。
ジオメトリ型の後の角括弧で示されたフラグには次の意味があります。
M: M軸を持ちます
Z: Z軸を持ちます
B: バウンディングボックスを持ちます
G: 測地座標系 (ジオグラフィ)です
S: 空間参照系を持ちます
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports Triangles and Triangulated Irregular Network Surfaces (TIN).
Availability: 1.2.2
Enhanced: 2.0.0でジオグラフィ対応が追加されました。
Enhanced: 2.1.0 空間参照系を持つかを示すSフラグが追加されました。
Enhanced: 2.2.0 TINと曲線の対応が追加されました。
=# SELECT ST_Summary(ST_GeomFromText('LINESTRING(0 0, 1 1)')) as geom, ST_Summary(ST_GeogFromText('POLYGON((0 0, 1 1, 1 2, 1 1, 0 0))')) geog; geom | geog -----------------------------+-------------------------- LineString[B] with 2 points | Polygon[BGS] with 1 rings | ring 0 has 5 points : (1 row) =# SELECT ST_Summary(ST_GeogFromText('LINESTRING(0 0 1, 1 1 1)')) As geog_line, ST_Summary(ST_GeomFromText('SRID=4326;POLYGON((0 0 1, 1 1 2, 1 2 3, 1 1 1, 0 0 1))')) As geom_poly; ; geog_line | geom_poly -------------------------------- +-------------------------- LineString[ZBGS] with 2 points | Polygon[ZBS] with 1 rings : ring 0 has 5 points : (1 row)
ST_X — Returns the X coordinate of a Point.
float ST_X(
geometry a_point)
;
ポイントのX座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。
This method implements the SQL/MM specification. SQL-MM 3: 6.1.3
This function supports 3d and will not drop the z-index.
ST_Y — Returns the Y coordinate of a Point.
float ST_Y(
geometry a_point)
;
ポイントのY座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。
This method implements the OpenGIS Simple Features
Implementation Specification for SQL 1.1.
This method implements the SQL/MM specification. SQL-MM 3: 6.1.4
This function supports 3d and will not drop the z-index.
ST_Z — Returns the Z coordinate of a Point.
float ST_Z(
geometry a_point)
;
ST_Zmflag — ST_Geometry値の座標次元を返します。
smallint ST_Zmflag(
geometry geomA)
;
ST_Geometry値の座標次元を返します。
Values are: 0 = 2D, 1 = 3D-M, 2 = 3D-Z, 3 = 4D.
This function supports 3d and will not drop the z-index.
This method supports Circular Strings and Curves
SELECT ST_Zmflag(ST_GeomFromEWKT('LINESTRING(1 2, 3 4)')); st_zmflag ----------- 0 SELECT ST_Zmflag(ST_GeomFromEWKT('LINESTRINGM(1 2 3, 3 4 3)')); st_zmflag ----------- 1 SELECT ST_Zmflag(ST_GeomFromEWKT('CIRCULARSTRING(1 2 3, 3 4 3, 5 6 3)')); st_zmflag ----------- 2 SELECT ST_Zmflag(ST_GeomFromEWKT('POINT(1 2 3 4)')); st_zmflag ----------- 3
ST_AddPoint — ラインストリングにポイントを追加します。
geometry ST_AddPoint(
geometry linestring, geometry point)
;
geometry ST_AddPoint(
geometry linestring, geometry point, integer position)
;
ラインストリングに対して指定した<position> (0はじまり)の前にポイントを追加します。第3引数に-1を指定すると末尾に追加できます。
Availability: 1.1.0
This function supports 3d and will not drop the z-index.
-- テーブル内の全てのラインストリングのうち閉じていないものについて、 -- 最初のポイントを末尾に追加することで、 -- 全てのラインストリングが閉じていることを保証します UPDATE sometable SET the_geom = ST_AddPoint(the_geom, ST_StartPoint(the_geom)) FROM sometable WHERE ST_IsClosed(the_geom) = false; --Adding point to a 3-d line SELECT ST_AsEWKT(ST_AddPoint(ST_GeomFromEWKT('LINESTRING(0 0 1, 1 1 1)'), ST_MakePoint(1, 2, 3))); --result st_asewkt ---------- LINESTRING(0 0 1,1 1 1,1 2 3)
ST_CollectionExtract — (マルチ)ジオメトリを与えると、指定したタイプの要素でのみ構成される (マルチ)ジオメトリを返します。
geometry ST_CollectionExtract(
geometry collection, integer type)
;
(マルチ)ジオメトリを与えると、指定したタイプの要素でのみ構成される (マルチ)ジオメトリを返します。指定したタイプでないジオメトリ要素は無視されます。正しいタイプのジオメトリ要素が無い場合はEMPTYジオメトリが返ります。ポイント、ラインストリング、ポリゴンのみをサポートします。番号は、1==ポイント, 2==ラインストリング, 3==ポリゴンです。
Availability: 1.5.0
![]() | |
1.5.3より前では、この関数は、非コクレションの入力については手を付けずに問題のないタイプで返しました。1.5.3では、適合しない単一ジオメトリについてはNULLを返しました。2.0.0では、適合するジオメトリが無い場合は常にEMPTYを返すようになりました。 |
![]() | |
3 == POLYGONを指定すると、エッジが共有されていたとしてもマルチポリゴンが返ります。この関数をST_Splitの結果への適用の多くの場合に不正なマルチポリゴンとなります。 |
-- 定数: 1 == ポイント, 2 == ラインストリング, 3 == ポリゴン SELECT ST_AsText(ST_CollectionExtract(ST_GeomFromText('GEOMETRYCOLLECTION(GEOMETRYCOLLECTION(POINT(0 0)))'),1)); st_astext --------------- MULTIPOINT(0 0) (1 row) SELECT ST_AsText(ST_CollectionExtract(ST_GeomFromText('GEOMETRYCOLLECTION(GEOMETRYCOLLECTION(LINESTRING(0 0, 1 1)),LINESTRING(2 2, 3 3))'),2)); st_astext --------------- MULTILINESTRING((0 0, 1 1), (2 2, 3 3)) (1 row)
ST_CollectionHomogenize — ジオメトリコレクションを与えると、「最も単純な」表現を返します。
geometry ST_CollectionHomogenize(
geometry collection)
;
ジオメトリコレクションを与えると、「最も単純な」表現を返します。非マルチなタイプは非マルチのタイプを返します。同質なコレクションは適切なマルチ系タイプを返します。
![]() | |
3 == POLYGONを指定すると、エッジが共有されていたとしてもマルチポリゴンが返ります。この関数をST_Splitの結果への適用の多くの場合に不正なマルチポリゴンとなります。 |
Availability: 2.0.0
ST_Force2D — ジオメトリを2次元モードに強制します。
geometry ST_Force2D(
geometry geomA)
;
ジオメトリを「2次元モード」に強制させます。全ての出力表現はXY座標値のみを持つことになります。OGC準拠の出力 (OGCは2次元ジオメトリのみ策定しています)に強制するために使われます。
Enhanced: 2.0.0 多面体サーフェス対応が導入されました。
Changed: 2.1.0 2.0.xの間はST_Force_2Dと呼ばれていました。
This method supports Circular Strings and Curves
This function supports Polyhedral surfaces.
This function supports 3d and will not drop the z-index.
SELECT ST_AsEWKT(ST_Force2D(ST_GeomFromEWKT('CIRCULARSTRING(1 1 2, 2 3 2, 4 5 2, 6 7 2, 5 6 2)'))); st_asewkt ------------------------------------- CIRCULARSTRING(1 1,2 3,4 5,6 7,5 6) SELECT ST_AsEWKT(ST_Force2D('POLYGON((0 0 2,0 5 2,5 0 2,0 0 2),(1 1 2,3 1 2,1 3 2,1 1 2))')); st_asewkt ---------------------------------------------- POLYGON((0 0,0 5,5 0,0 0),(1 1,3 1,1 3,1 1))
ST_Force3D — ジオメトリをXYZモードに強制します。これはST_Force3DZの別名です。
geometry ST_Force3D(
geometry geomA)
;
ジオメトリをXYZモードに強制します。これはST_Force_3DZの別名です。ジオメトリがZ値を持っていない場合は0のZ値を追加します。
Enhanced: 2.0.0 多面体サーフェス対応が導入されました。
Changed: 2.1.0 2.0.xの間はST_Force_3Dと呼ばれていました。
This function supports Polyhedral surfaces.
This method supports Circular Strings and Curves
This function supports 3d and will not drop the z-index.
-- 既に3次元ジオメトリになっている場合は何も起きません SELECT ST_AsEWKT(ST_Force3D(ST_GeomFromEWKT('CIRCULARSTRING(1 1 2, 2 3 2, 4 5 2, 6 7 2, 5 6 2)'))); st_asewkt ----------------------------------------------- CIRCULARSTRING(1 1 2,2 3 2,4 5 2,6 7 2,5 6 2) SELECT ST_AsEWKT(ST_Force3D('POLYGON((0 0,0 5,5 0,0 0),(1 1,3 1,1 3,1 1))')); st_asewkt -------------------------------------------------------------- POLYGON((0 0 0,0 5 0,5 0 0,0 0 0),(1 1 0,3 1 0,1 3 0,1 1 0))