PostGIS 3.1.0 マニュアル

PostGIS開発グループ

概要

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

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

この作品はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。好きなようにこの材料を使うことができますが、PostGIS Project のクレジット提示を求めます。また可能な限りhttp://postgis.netへのリンクを求めます。


目次
1. 導入
1.1. プロジェクト運営委員会
1.2. 現在の中核貢献者
1.3. 過去の中核貢献者
1.4. 他の貢献者
2. PostGISインストール
2.1. 簡略版
2.2. ソースからのコンパイルとインストール
2.2.1. ソースの取得
2.2.2. インストール要件
2.2.3. ビルドコンフィギュレーション
2.2.4. ビルド
2.2.5. PostGISエクステンションのビルドとデプロイ
2.2.6. テスト
2.2.7. インストール
2.3. PAGC住所標準化ツールのインストールと使用
2.3.1. Regex::Assembleのインストール
2.4. Tigerジオコーダのインストールとアップグレードとデータロード
2.4.1. TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用
2.4.2. TigerジオコーダをPostGISデータベースで有効にする: エクステンション不使用
2.4.3. TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用
2.4.4. Tigerデータのロード
2.4.5. Tigerジオコーダのアップグレード
2.5. 共通の問題
3. PostGIS管理
3.1. パフォーマンスチューニング
3.1.1. 起動時
3.1.2. 実行時
3.2. ラスタ機能の設定
3.3. 空間テーブルの作成
3.3.1. エクステンションを使って空間データベースを有効にする
3.3.2. エクステンションを使わずに空間データベースを有効にする (非推奨)
3.3.3. 空間データベースをテンプレートから生成する
3.4. 空間データベースのアップグレード
3.4.1. ソフトアップグレード
3.4.2. ハードアップグレード
4. PostGISの使用
4.1. データ管理
4.1.1. GISオブジェクト
4.1.2. PostGISジオグラフィ型
4.1.3. 空間メタデータテーブル
4.1.4. ジオメトリ検証
4.1.5. 空間データのロード
4.1.6. 空間データの抽出
4.1.7. 空間インデックスを構築する
4.2. 空間クエリ
4.2.1. 空間関係の決定
4.2.2. インデックスの利点を使う
4.2.3. 空間SQLの例
4.3. 性能向上に関する技法
4.3.1. 大きなジオメトリを持つ小さなテーブル
4.3.2. ジオメトリインデクスでCLUSTERを実行する
4.3.3. 次元変換の回避
4.4. アプリケーションのビルド
4.4.1. MapServerを使う
4.4.2. Javaクライアント (JDBC)
4.4.3. Cクライアント (libpq)
4.5. ラスタデータの管理、クエリ、アプリケーション
4.5.1. ラスタのロードと生成
4.5.2. ラスタカタログ
4.5.3. PostGISラスタを使ったカスタムアプリケーションの構築
4.6. トポロジ
4.6.1. トポロジ型
4.6.2. トポロジドメイン
4.6.3. トポロジ管理とTopoGeometry管理
4.6.4. トポロジ統計管理
4.6.5. トポロジコンストラクタ
4.6.6. トポロジエディタ
4.6.7. トポロジアクセサ
4.6.8. トポロジ処理
4.6.9. TopoGeometryコンストラクタ
4.6.10. TopoGeometryエディタ
4.6.11. TopoGeometryアクセサ
4.6.12. TopoGeometry出力
4.6.13. トポロジ空間関係関数
4.7. 住所標準化
4.7.1. パーサの動作
4.7.2. 住所標準化の型
4.7.3. 住所標準化テーブル
4.7.4. 住所標準化関数
4.8. PostGIS追加機能
4.8.1. Tigerジオコーダ
5. PostGISリファレンス
5.1. PostGIS Geometry/Geography/Box データ型
5.2. テーブル管理関数
5.3. ジオメトリ コンストラクタ
5.4. ジオメトリアクセサ
5.5. ジオメトリエディタ
5.6. ジオメトリ検証
5.7. 空間参照系関数
5.8. ジオメトリ入力
5.8.1. Well-Known Text (WKT)
5.8.2. Well-Known Binary (WKB)
5.8.3. その他の書式
5.9. ジオメトリ出力
5.9.1. Well-Known Text (WKT)
5.9.2. Well-Known Binary (WKB)
5.9.3. その他の書式
5.10. 演算子
5.10.1. バウンディングボックス演算子
5.10.2. 距離演算子
5.11. 空間関係関数
5.11.1. トポロジ関係関数
5.11.2. 距離関係関数
5.12. 計測関数
5.13. 重ね合わせ関数
5.14. ジオメトリ処理関数
5.15. アフィン変換
5.16. クラスタリング関数
5.17. バウンディングボックス関数
5.18. 線型参照
5.19. トラジェクトリ関数
5.20. SFCGAL関数
5.21. ロングトランザクション機能
5.22. バージョン関数
5.23. Grand Unified Custom変数 (GUC)
5.24. トラブルシューティング関数
6. ラスタ リファレンス
6.1. ラスタサポートデータ型
6.2. ラスタ管理
6.3. ラスタコンストラクタ
6.4. ラスタアクセサ
6.5. ラスタバンドアクセサ
6.6. ラスタピクセルアクセサとセッター
6.7. ラスタエディタ
6.8. ラスタバンドエディタ
6.9. ラスタバンド統計情報と解析
6.10. ラスタ入力
6.11. 出力
6.12. ラスタ処理: 地図代数
6.13. 組み込み地図代数コールバック関数
6.14. ラスタ処理: DEM (標高)
6.15. ラスタ処理: ラスタからジオメトリ
6.16. ラスタ演算子
6.17. ラスタとラスタバンドの空間関係関数
6.18. ラスタに関する技法
6.18.1. データベース外ラスタ
7. PostGIS よくある質問
8. PostGISラスタ よくある質問
9. PostGIS関数索引
9.1. PostGIS集約関数
9.2. PostGISウィンドウ関数
9.3. PostGIS SQL-MM準拠関数
9.4. PostGISジオグラフィ対応関数
9.5. PostGISラスタ機能関数
9.6. PostGISジオメトリ/ジオグラフィ/ラスタのダンプ関数
9.7. PostGISボックス関数
9.8. 3次元対応PostGIS関数
9.9. PostGIS曲線ジオメトリ対応関数
9.10. PostGIS多面体サーフェス対応関数
9.11. PostGIS関数対応マトリクス
9.12. 新規作成/機能強化/変更されたPostGIS関数
9.12.1. PostGIS 3.1で新規作成/機能強化された関数
9.12.2. PostGIS 3.0で新規作成/機能強化された関数
9.12.3. PostGIS 2.5で新規作成/機能強化された関数
9.12.4. PostGIS 2.4で新規作成/機能強化された関数
9.12.5. PostGIS 2.3で新規作成/機能強化された関数
9.12.6. PostGIS 2.2で新規作成/機能強化された関数
9.12.7. PostGIS 2.2で大幅に変更された関数
9.12.8. PostGIS 2.1で新規作成/機能強化された関数
9.12.9. PostGIS 2.1で大幅に変更された関数
9.12.10. PostGIS 2.0で新規作成/機能強化/変更された関数
9.12.11. PostGIS 2.0で変更された関数
9.12.12. PostGIS 1.5で新規作成/機能強化/変更された関数
9.12.13. PostGIS 1.4で新規作成/機能強化/変更された関数
9.12.14. PostGIS 1.3で新規作成された関数
10. 問題を報告する
10.1. ソフトウェアのバグを報告する
10.2. 文書の問題を報告する
A. 付録
A.1. リリース 3.1.0beta1
A.2. リリース 3.1.0alpha3
A.3. リリース 3.1.0alpha2
A.4. リリース 3.1.0alpha1
A.5. リリース 3.0.0
A.6. リリース 3.0.0rc2
A.7. リリース 3.0.0rc1
A.8. リリース 3.0.0beta1
A.9. リリース 3.0.0alpha4
A.10. リリース 3.0.0alpha3
A.11. リリース 3.0.0alpha2
A.12. リリース 3.0.0alpha1
A.13. リリース 2.5.0
A.14. リリース 2.4.5
A.15. リリース 2.4.4
A.16. リリース 2.4.3
A.17. リリース 2.4.2
A.18. リリース 2.4.1
A.19. リリース 2.4.0
A.20. リリース 2.3.3
A.21. リリース 2.3.2
A.22. リリース 2.3.1
A.23. リリース 2.3.0
A.24. リリース 2.2.2
A.25. リリース 2.2.1
A.26. リリース 2.2.0
A.27. リリース 2.1.8
A.28. リリース 2.1.7
A.29. リリース 2.1.6
A.30. リリース 2.1.5
A.31. リリース 2.1.4
A.32. リリース 2.1.3
A.33. リリース 2.1.2
A.34. リリース 2.1.1
A.35. リリース 2.1.0
A.36. リリース 2.0.5
A.37. リリース 2.0.4
A.38. リリース 2.0.3
A.39. リリース 2.0.2
A.40. リリース 2.0.1
A.41. リリース 2.0.0
A.42. リリース 1.5.4
A.43. リリース 1.5.3
A.44. リリース 1.5.2
A.45. リリース 1.5.1
A.46. リリース 1.5.0
A.47. リリース 1.4.0
A.48. リリース 1.3.6
A.49. リリース 1.3.5
A.50. リリース 1.3.4
A.51. リリース 1.3.3
A.52. リリース 1.3.2
A.53. リリース 1.3.1
A.54. リリース 1.3.0
A.55. リリース 1.2.1
A.56. リリース 1.2.0
A.57. リリース 1.1.6
A.58. リリース 1.1.5
A.59. リリース 1.1.4
A.60. リリース 1.1.3
A.61. リリース 1.1.2
A.62. リリース 1.1.1
A.63. リリース 1.1.0
A.64. リリース 1.0.6
A.65. リリース 1.0.5
A.66. リリース 1.0.4
A.67. リリース 1.0.3
A.68. リリース 1.0.2
A.69. リリース 1.0.1
A.70. リリース 1.0.0
A.71. リリース 1.0.0RC6
A.72. リリース 1.0.0RC5
A.73. リリース 1.0.0RC4
A.74. リリース 1.0.0RC3
A.75. リリース 1.0.0RC2
A.76. リリース 1.0.0RC1

第1章 導入

PostGISは、PostgreSQLリレーショナルデータベースの空間拡張です。Refractions Research Incが、空間データベース技術の研究プロジェクトとして作成しました。Refractionsはカナダ・ブリティッシュコロンビア州・ビクトリアにある、データインテグレーションとカスタムソフトウェア開発に特化した、GISとデータベースのコンサルティング会社です。

PostGISは、現在ではOSGeo財団のプロジェクトです。多数のFOSS4G開発者とPostGISの機能と多彩さから大きな利益を得る世界中の企業が、PostGISの開発と資金提供を行っています。

PostGISプロジェクトの開発グループは、PostGISが、OpenGISとSQL/MM空間標準の領域における重要なGIS機能、高度なトポロジ構築 (カバレッジ、サーフェス、ネットワーク)、GISデータの表示と編集を行うデスクトップユーザインタフェースツール、およびウェブベースのアクセスツールのためのデータソースに、より良く対応するよう、サポートと機能強化を行う予定です。

1.1. プロジェクト運営委員会

PostGISプロジェクト運営委員会 (PostGIS Project Steering Committee, PSC)は、総合的な指示、リリースサイクル、ドキュメンテーション、支援活動に関する調整を行っています。また、委員会は、全体的なユーザサポート、PostGISコミュニティからのパッチの受け付けと適用、 開発者のコミットのアクセス、新しい委員、APIの重要な変更といった、PostGISを含む雑多な問題に関する投票を行っています。

Raúl Marín Rodríguez

MVT機能、誤り修正、パフォーマンスと安定性の向上、GitHubキュレーション、PostGISとPostgreSQLのリリースの調整

Regina Obe

Buildbotのメンテナンス、Windows版と試験版のビルド、ドキュメンテーション、PostgreSQLとの調整、X3D対応、Tiger Geocoder機能、関数管理。

Bborie Park

ラスタ開発、GDALとの統合、ラスタローダ、ユーザサポート、一般的なバグフィクス、様々なOS (Slackware, Mac, Windows他)での試験。

Darafei Praliaskouski

インデックス改善、誤り修正とジオメトリ/ジオグラフィ関数の改善、SFCGAL、ラスタ、GitHubキュレーション、Travis Botのメンテナンス。

Paul Ramsey (委員長)

PostGISプロジェクトの副創始者。総合的なバグフィクス、ジオグラフィ機能、ジオグラフィとジオメトリのインデックス機能 (2次元,、3次元、n次元インデクスとあらゆる空間インデクス)、ジオメトリ内部構造、GEOS機能の統合とGEOSリリースとの調整、PostgreSQLのリリースとの調整、ローダ/ダンパ、シェープファイルGUIローダ。

Sandro Santilli

誤り修正とメンテナンス、ビルドボットのメンテナンス、gitミラーの管理、関数管理、GEOSの新機能の統合、GEOSリリースとの調整、トポロジ機能、ラスタフレームワークと低水準API関数。

1.2. 現在の中核貢献者

Jorge Arévalo

ラスタ開発、GDALドライバ機能、ローダ。

Nicklas Avén

距離関数の強化 (3次元距離、関係関数を含む)と追加、Tiny WKB出力書式(TWKB)と一般的なユーザサポート。

Dan Baston

ジオメトリクラスタリング関数の追加、他のジオメトリアルゴリズムの強化、GEOSの強化、および全体のユーザ対応

Olivier Courtin

XML (KML, GML)/GeoJSON入出力関数と3次元対応と誤り修正。

Martin Davis

GEOS機能強化と文書

Björn Harrtell

MapBox Vector Tile関数とGeoBuf関数、Gogsの試験とGitLabの実験。

Mateusz Loskot

CMakeのPostGISへの対応、Python版のオリジナルのラスタローダと低級ラスタAPI関数の構築。

Pierre Racine

ラスタ全体のアーキテクチャ、プロトタイピング、プログラミング支援。

1.3. 過去の中核貢献者

Mark Cave-Ayland

以前のPSCメンバ。誤り修正とメンテナンスの活動、空間インデックス選択性とバインディング、ローダ/ダンパ、およびシェープファイルGUIローダの調整、新機能の統合と強化。

Chris Hodgson

以前のPSCメンバ。一般的な開発、サイトとBuildbotのメンテナンス、OSGeoインキュベーション管理。

Kevin Neufeld

以前のPSCメンバ。文書と文書補助ツール、Buildbotのメンテナンス、PostGISニュースグループでの高度なユーザサポート、PostGISメンテナンス機能の強化。

Dave Blasby

PostGISのオリジナルの開発/副創始者。サーバサイドのオブジェクト、インデクスのバインディングや多数のサーバサイドの解析機能を記述。

Jeff Lounsbury

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

Mark Leslie

中核機能の、継続的なメンテナンスと開発。曲線機能の強化。シェープファイルGUIローダ。

David Zwarg

ラスタ開発 (ほとんど地図代数解析関数)。

1.4. 他の貢献者

個人

Alex BodnaruGerald FenoyMaxime Guillaud
Alex MayrhoferGino LucreziMaxime van Noppen
Andrea PeriGreg TroxelMichael Fuhr
Andreas Forř TollefsenGuillaume LelargeMike Toews
Andreas NeumannHaribabu KommiNathan Wagner
Anne GhislaHavard TveiteNathaniel Clay
Antoine BajoletIIDA TetsushiNikita Shulga
Artur ZakirovIngvild NystuenNorman Vine
Barbara PhillipotJackie LengPatricia Tozer
Ben JubbJames MarcaRafal Magda
Bernhard ReiterJason SmithRalph Mason
Björn EsserJeff AdamsRémi Cura
Brian HamlinJonne SavolainenRichard Greenwood
Bruce RindahlJose Carlos Martinez LlariRoger Crew
Bruno Wolff IIIJörg HabenichtRon Mayer
Bryce L. NordgrenJulien RouhaudSebastiaan Couwenberg
Carl AndersonKashif RasulSergey Fedoseev
Charlie SavageKlaus FoersterShinichi Sugiyama
Christoph BergKris JurkaShoaib Burq
Christoph Moench-TegederLaurenz AlbeSilvio Grosso
Dane SpringmeyerLars RoessigerSteffen Macke
Dave FuhryLeo HsuStepan Kuzmin
David GarnierLoic DacharyStephen Frost
David SkeaLuca S. PercichTalha Rizwan
David TecherMaria Arias de ReynaTom Glancy
Dmitry VasilyevMarc DucobuTom van Tilburg
Eduin CarrilloMark SondheimVincent Mora
Eugene AntimirovMarkus SchaberVincent Picavet
Even RouaultMarkus WannerVolf Tomáš
Frank WarmerdamMatt Amos 
George SilvaMatthias Bay 

企業

これらは、PostGISプロジェクトに開発者の時間、ホスティング、または直接の資金提供のいずれかの貢献をした企業です。アルファベット順:

クラウドファンディングキャンペーン

クラウドファンディングキャンペーンは、PostGIS開発チームが走らせているキャンペーンです。欲しくて仕方ない機能に資金を与えて、多数の人々にサービスを提供できるようにするためのものです。それぞれのキャンペーンでは、特定の機能または機能の集合に焦点があてられます。それぞれのスポンサーは、必要な資金提供のうち少しだけを提供し、十分な人/組織の寄付で、たくさんの助けになる作業に支払う基金を持ちます。他の多くの人が寄付に協力してくれそうな機能に関するアイデアがありましたら、PostGIS newsgroupに、その考えを投稿して下さい。一緒に実現できます。

PostGIS 2.0.0はこの戦略を実施する最初のリリースです。PledgeBankを使い、2件のキャンペーンが成功しました。

postgistopology - 10以上のスポンサーがTopoGeometry機能の構築と2.0.0でのトポロジ対応強化とのために、それぞれ250米ドルを寄付しました。

postgis64windows - 20のスポンサーが、Windows上でのPostGIS 64ビット版に必要な作業のために、それぞれ100米ドルを寄付しました。

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

ジオメトリ演算ライブラリGEOS

地理空間データ抽象化ライブラリGDALは、PostGIS 2で導入されたラスタ機能の多くに使われています。また、GDALのPostGIS対応に必要な改善はGDALプロジェクトに貢献しています。

地図投影ライブラリPROJ

最後ですがおろそかにできないのがPostgreSQLです。PostGISはこの巨人に立っています。PostGISの速度と柔軟性は、PostgreSQLが提供する拡張性、優れたクエリプランナ、GiSTインデックス、多数のSQL機能があって初めて成り立ちます。

第2章 PostGISインストール

本章では、PostGISのインストールに必要な手順について説明します。

2.1. 簡略版

全ての依存がパスに入っているとする場合、次のようにコンパイルします。

tar xvfz postgis-3.1.0.tar.gz
cd postgis-3.1.0
./configure
make
make install

PostGISがインストールされたら、使用したい個々のデータベースで有効にする (「空間テーブルの作成」)かアップグレード (「空間データベースのアップグレード」)する必要があります。

2.2. ソースからのコンパイルとインストール

[注記]

多くのOSで、ビルドされたPostgreSQL/PostGISパッケージがあります。多くの場合、コンパイルが必要なのは、最もひどい最先端の版が欲しい場合やパッケージメンテナンスを行う人ぐらいです。

本節では、一般的なコンパイル手順を示します。Windows用や他のOS用等にコンパイルするなら、PostGIS User contributed compile guidesPostGIS 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.1.0では、コンパイルのために、完全なPostgreSQLサーバヘッダが必要です。PostgreSQL 3.1.0以上でビルドできます。古い版のPostgreSQLはサポートされません

PostgreSQLをインストールしていないならPostgreSQLインストールガイドを参照して下さい。http://www.postgresql.org/にあります。

[注記]

GEOS機能を有効にするために、PostgreSQLをインストール時に明示的に標準C++ライブラリに対する明示的なリンクが必要になる場合があります。

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

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

次のステップでは、PostGISソースのコンフィギュレーションとコンパイルに概要を記述します。これらは、Linuxユーザ用に書いてありますので、WindowsやMacでは動作しません。

2.2.1. ソースの取得

ダウンロードサイトhttp://download.osgeo.org/postgis/source/postgis-3.1.0.tar.gzからソースのアーカイブを入手します。

wget http://download.osgeo.org/postgis/source/postgis-3.1.0.tar.gz
tar -xvzf postgis-3.1.0.tar.gz

これで、カレントディレクトリの下にpostgis-3.1.0ができます。

もしくは、 git レポジトリの https://git.osgeo.org/gitea/postgis/postgis/ からソースをチェックアウトします。

git clone https://git.osgeo.org/gitea/postgis/postgis.git postgis

新しく作られたpostgisディレクトトリに移動して、インストールを続けます。

2.2.2. インストール要件

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

必須

  • PostgreSQL 9.6以上。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以上が必要です。Proj4ライブラリは、PostGISの座標系投影変換機能に使われます。Proj4は、http://trac.osgeo.org/proj/からダウンロードできます。

  • ジオメトリライブラリGEOS、3.6版以降が必要ですが、新しい関数と機能の最大限に活用するためには3.9以上をお勧めします。GEOSは http://trac.osgeo.org/geos/ からダウンロード可能です。

  • 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 2以上が必要ですが、3以上の方が良いです。ラスタ機能に必要です。http://trac.osgeo.org/gdal/wiki/DownloadSource/からダウンロード可能です。

  • PostgreSQL+JITでコンパイルする場合には、LLVM 6版以上が必要です。https://trac.osgeo.org/postgis/ticket/4125を参照して下さい。

オプション

  • GDAL (擬似的任意)ラスタが必要ない場合に限り不要です。「ラスタ機能の設定」の説明に従って使用したいドライバを有効にしてください。

  • GTK (GTK+2.0, 2.8+が必要)。シェープファイルのローダであるshp2pgsql-guiのコンパイル用です。http://www.gtk.org/にあります。

  • SFCGAL 1.1版以上。追加的な2次元や3次元の高度な解析関数をPostGISで使うために使用するものです。「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にあります。

  • 「住所標準化」をビルドするには、PCRE http://www.pcre.org (Unix系システムには通常はインストール済みです)も必要です。parseaddress-stcities.h内のエンコードしたデータを再構築したい場合には、Perl CPANのRegex::Assembleパッケージのみ必要です。「住所標準化」は、PCREライブラリを検出するか、コンフィギュレーションで適切に--with-pcre-dir=/path/to/pcreを指定すると、自動的にビルドされます。

  • ST_AsMVTを有効にするにはprotobuf-cライブラリ (使用時)とprotoc-cコンパイラ (ビルド時)が必要です。さらに、protobuf-cの正しい最小バージョンを確認するためにpkg-configが必要です。protobuf-cをご参照下さい。デフォルトでは、PostGISはMVTポリゴンの評価を速く行うためにWagyuを使いますが、C++11コンパイラが必要です。CXXFLAGSを使い、PostgreSQLのインストールと同じコンパイラを使います。これを無効にし、GEOSを代わりに使うには、コンフィギュア時に--without-wagyuを付けます。

  • 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/にあります。

2.2.3. ビルドコンフィギュレーション

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

./configure

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

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

--with-library-minor-version

PostGIS 3.0以降では、デフォルトではライブラリファイルのファイル名にマイナーバージョンが入らなくなりました。PostGIS 3のライブラリはpostgis-3で終わります。pg_upgradeを簡単にするために実施された変更ですが、サーバにPostGIS 3シリーズは一つのマイナーバージョンのものだけしかインストールできません。postgis-3.0といったようにマイナーバージョンをファイル名に含む古い振る舞いにしたいなら、コンフィギュレーション実行の際に次のスイッチを追加します。

--prefix=PREFIX

これは、PostGISローダの実行ファイルと共有ライブラリがインストールされる位置です。デフォルトでは、この位置は、検出されたPostgreSQLのインストール先と同じです。

[注意]

このパラメータは現在のところ壊れていて、PostgreSQLのインストール先にしかインストールされません。このバグのトラックについてはhttp://trac.osgeo.org/postgis/ticket/635をご覧ください。

--with-pgconfig=FILE

PostgreSQLは、PostGISなどの拡張に対してPostgreSQLのインストール先ディレクトリを伝えるpg_configというユーティリティを持っています。PostGISの対象とする特定のPostgreSQLのインストール先を手動で指定する場合に、このパラメータ(--with-pgconfig=/path/to/pg_config)を使います。

--with-gdalconfig=FILE

必須ライブラリであるGDALは、ラスタ機能に必要な機能を提供します。GDALには、インストール先ディレクトリをインストールスクリプトに伝えるgdal-configがあります。PostGISのビルドに使う特定のGDALを手動で指定する場合に、このパラメータ (--with-gdalconfig=/path/to/gdal-config)を使います。

--with-geosconfig=FILE

必須のジオメトリライブラリであるGEOSには、ソフトウェアのインストール時にGEOSのインストール先ディレクトリを伝えるgeos-configというユーティリティがあります。PostGISのビルドに使う特定のGEOSを手動で指定する場合に、このパラメータ (--with-geosconfig=/path/to/geos-config)を使います。

--with-xml2config=FILE

LibXMLはGeomFromKML/GML処理を行うのに必須のライブラリです。通常はlibxmlをインストールしているなら発見されますが、発見できない場合や特定の版を使用したい場合は、xml2-configを指定してインストールスクリプトにLibXMLのインストール先ディレクトリを伝えます。PostGISのビルドに使う特定のLibXMLを手動で指定する場合に、このパラメータ ( >--with-xml2config=/path/to/xml2-config)を使います。

--with-projdir=DIR

Proj4はPostGISに必須の投影変換ライブラリです。PostGISのビルドに使う特定のProj4のディレクトリを手動で指定する場合は、このパラメータ (--with-projdir=/path/to/projdir)を使います。

--with-libiconv=DIR

iconvのインストール先ディレクトリを指定します。

--with-jsondir=DIR

JSON-Cは、MITライセンスのJSONライブラリで、PostGISのST_GeomFromJSONに必須です。PostGISのビルドに使う特定のJSON-Cを手動で指定する場合に、このパラメータ (--with-jsondir=/path/to/jsondir)を使います。

--with-pcredir=DIR

PCREは、BSDライセンスのPerl互換正規表現ライブラリです。住所標準化エクステンションに必須です。PostGISのビルド対象としている特定のPCREを手動で指定する場合に、このパラメータ (--with-pcredir=/path/to/pcredir)を使います。

--with-gui

データインポートGUI (GTK+2.0が必要)をコンパイルします。このパラメータによって、shp2pgsql-guiという、shp2pgsqlのグラフィカルユーザインタフェースが作成されます。

--without-raster

ラスタ機能なしでコンパイルします。

--without-topology

トポロジ対応を無くしてコンパイルします。トポロジに必要なロジックは全てpostgis-3.1.0ライブラリ内に作られるので、関連ライブラリはありません。

--with-gettext=no

デフォルトでは、gettextの検出とこれを用いたコンパイルを試みますが、ローダ破損を引き起こす非互換性問題のもとで実行する場合には、このコマンドで無効にできます。これを使ったコンフィギュレーションによって解決する問題の例はhttp://trac.osgeo.org/postgis/ticket/748にあります。ご注意: これを切ることで多くの機能がなくなるわけではありません。まだ文書化されていなくて試験段階であるGUIローダにおける内部のヘルプ/ラベル機能に使われています。

--with-sfcgal=PATH

デフォルトでは、このスイッチなしではSFCGAL対応でインストールされません。PATHは、sfcgal-configへのパスを指定することができる追加的な引数です。

--without-wagyu

MVT機能をビルドする時には、PostGISは、MVTポリゴンを抜き出したり評価したりするためにWagyuを使います。Wagyuは最も速い選択肢であり、また、この特殊な状況下にあっては、正しい値の生成が保証されます。ただし、C++11コンパイラが必要です。この任意引数で、このライブラリの使用を無効にし、代わりにGEOSを使うようにすることができます。

--without-phony-revision

Gitレポジトリの現在のHEADに一致するように、postgis_revision.hの更新を無効にします。

[注記]

コードレポジトリからPostGISを取得した場合には、最初のステップとしてスクリプトを実行します。

./autogen.sh

このスクリプトによってconfigureスクリプトが生成されます。これはPostGISのインストールに関するカスタマイズに使われます。

PostGISをアーカイブファイルで入手する場合には、configureが既に生成されているので./autogen.shは不要です。

2.2.4. ビルド

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

2.2.5. PostGISエクステンションのビルドとデプロイ

PostgreSQL 9.1以上を使用している場合は、PostGISエクステンションが自動的にビルド、インストールされます。

ソースレポジトリからビルドしている場合は、関数の記述を最初にビルドする必要があります。これらは、docbookがインストールされている時にビルドされます。手動でインストールするには次のようにします。

make comments

アーカイブファイルからのビルドの場合は、ビルド済みのものがあるので、コメントのビルドは必須ではありません。

エクステンションはmake installの過程の一部として自動的にビルドされるはずです。必要ならエクステンションフォルダからビルドすることもできますし、他のサーバに必要ならファイルを複製することもできます。

cd extensions
cd postgis
make clean
make
export PGUSER=postgres #overwrite psql variables
make check #to test before install
make install
# エクステンションのテスト
make check RUNTESTFLAGS=--extension
[注記]

make checkは、テスト実行のためにpsqlを使用し、psql環境変数を使用します。一般的なpsql環境変数で上書きすると便利なのがPGUSER,PGPORT, PGHOSTです。環境変数を参照して下さい。

エクステンションのファイルは、PostGISとPostgreSQLの同じバージョンでは、OSに関わらず、常に同じです。サーバにPostGISのバイナリがインストールされている限り、あるOSから他の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.1.0         | 3.1.0
 address_standardizer_data_us | 3.1.0         | 3.1.0
 postgis                      | 3.1.0         | 3.1.0
 postgis_raster               | 3.1.0         | 3.1.0
 postgis_sfcgal               | 3.1.0         |
 postgis_tiger_geocoder       | 3.1.0         | 3.1.0
 postgis_topology             | 3.1.0         |
(6 rows)

クエリを行ったデータベースにエクステンションがインストールされている場合は、installed_versionカラムに記載が見えます。レコードが返ってこない場合は、PostGIS EXTENSIONがインストールされていないことになります。PgAdmin III 1.14以上では、データベースブラウザツリーのextensionsセクションで提供されていて、右クリックでアップグレードまたアンインストールできます。

有効なエクステンションがある場合、pgAdminエクステンションインタフェースまたは次のSQLの実行によって、選択したデータベースにPostGISエクステンションをインストールできます。

CREATE EXTENSION postgis;
CREATE EXTENSION postgis_raster;
CREATE EXTENSION postgis_sfcgal;
 --postgis_tiger_geocoderに必要です
CREATE EXTENSION fuzzystrmatch;
-- 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.1.0
Schema      | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
Name        | postgis_raster
Version     | 3.0.0dev
Schema      | public
Description | PostGIS raster types and functions
-[ RECORD 3 ]-------------------------------------------------
Name        | postgis_tiger_geocoder
Version     | 3.1.0
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name        | postgis_topology
Version     | 3.1.0
Schema      | topology
Description | PostGIS topology spatial types and functions
[警告]

エクステンションのテーブルspatial_ref_sys, layer, topologyは、明示的にバックアップできません。それぞれのpostgisまたはpostgis_topologyエクステンションがバックアップされる時のみバックアップできます。これは、データベース全体のバックアップの時のみ行われます。PostGIS 2.0.1の時点では、データベースがバックアップされる際に、PostGISでパッケージ化されていないsridレコードのみバックアップされます。パッケージに入っているsridの変更は巡回せず、変更はそこにあるものと期待されます。PostGIS 2.0.1の時点では、データベースがバックアップされるときにPostGISに入っていないsridのレコードだけがバックアップされます。PostGISに入っていて後に変更されたsridの変更については巡回しません。問題が見られたら、チケットを発行して下さい。エクステンションテーブルの構造はCREATE EXTENSIONで生成されるので、バックアップを行いません。エクステンションの与えられた版と同じものであると仮定されます。この挙動は現在のPostgreSQL エクステンションモデルに組み込まれているため、これについては何もできません。

素晴らしいエクステンション機構を使わずに3.1.0をインストールした場合には、それぞれのエクステンションが持つ関数をパッケージするためのコマンドを実行して、エクステンションに基づくように変更できます。

CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_raster FROM unpackaged;
CREATE EXTENSION postgis_topology FROM unpackaged;
CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;

2.2.6. テスト

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

make check

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

[注記]

コンフィギュレーションを行ったPostGISが標準の場所に無いPostgreSQL、GEOSまたはProj4を使う場合には、これらのライブラリの位置をLD_LIBRARY_PATH環境変数に追加する必要があるかも知れません。

[注意]

現在のところmake checkは、チェックを行う際に 環境変数PATHPGPORTによっています。コンフィギュレーションパラメータ--with-pgconfigを使って特定したPostgreSQLではありません。PATHを編集して、コンフィギュレーションの際に検出したPostgreSQLと一致するようにして下さい。もしくは、間もなく襲ってくる頭痛の準備をしておいて下さい。

成功した場合は、テストの出力は次のようなかんじになります。

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


Suite: algorithm
  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_interpolate_points ...passed
  Test: test_lwline_interpolate_point_3d ...passed
  Test: test_lwline_clip ...passed
  Test: test_lwpoly_clip ...passed
  Test: test_lwtriangle_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
  Test: test_lw_arc_center ...passed
  Test: test_point_density ...passed
  Test: test_kmeans ...passed
  Test: test_median_handles_3d_correctly ...passed
  Test: test_median_robustness ...passed
  Test: test_lwpoly_construct_circle ...passed
  Test: test_trim_bits ...passed
  Test: test_lwgeom_remove_repeated_points ...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 ...DEBUG1: lwgeom_clip_by_rect: GEOS Error: IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or 
>= 4
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_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
  Test: test_gbox_to_string_truncated ...passed
Suite: geos
  Test: test_geos_noop ...passed
  Test: test_geos_subdivide ...passed
  Test: test_geos_linemerge ...passed
  Test: test_geos_offsetcurve ...passed
  Test: test_geos_offsetcurve_crash ...passed
  Test: test_geos_makevalid ...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
  Test: multipoint_test ...passed
  Test: dbscan_test ...passed
  Test: dbscan_test_3612a ...passed
  Test: dbscan_test_3612b ...passed
  Test: dbscan_test_3612c ...passed
Suite: clustering_unionfind
  Test: test_unionfind_create ...passed
  Test: test_unionfind_union ...passed
  Test: test_unionfind_ordered_by_cluster ...passed
  Test: test_unionfind_path_compression ...passed
  Test: test_unionfind_collapse_cluster_ids ...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: iterator
  Test: test_point_count ...passed
  Test: test_ordering ...passed
  Test: test_modification ...passed
  Test: test_mixed_rw_access ...passed
  Test: test_cannot_modify_read_only ...passed
  Test: test_no_memory_leaked_when_iterator_is_partially_used ...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 ...NOTICE: SRID value -3005 converted to the officially unknown SRID value 0
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_swap_ordinates ...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_gserialized_peek_gbox_p_no_box_when_empty ...passed
  Test: test_gserialized_peek_gbox_p_gets_correct_box ...passed
  Test: test_gserialized_peek_gbox_p_fails_for_unsupported_cases ...passed
  Test: test_gbox_same_2d ...passed
  Test: test_signum_macro ...passed
Suite: lwstroke
  Test: test_lwcurve_linearize ...passed
  Test: test_unstroke ...passed
Suite: measures
  Test: test_mindistance2d_tolerance ...passed
  Test: test_mindistance3d_tolerance ...NOTICE: One or both of the geometries is missing z-value. The unknown z-value will be regarded as "any value"
NOTICE: One or both of the geometries is missing z-value. The unknown z-value will be regarded as "any value"
passed
  Test: test_rect_tree_contains_point ...passed
  Test: test_rect_tree_intersects_tree ...passed
  Test: test_lwgeom_segmentize2d ...NOTICE: ptarray.c:448 - ptarray_segmentize2d: Too many segments required (1.000000e+101)
NOTICE: liblwgeom code interrupted
NOTICE: liblwgeom code interrupted
NOTICE: liblwgeom code interrupted
NOTICE: liblwgeom code interrupted
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 ...NOTICE: Geometry is not a LINESTRING
NOTICE: Line does not have M dimension
NOTICE: Measure of vertex 1 (1) not bigger than measure of vertex 0 (1)
NOTICE: Measure of vertex 1 (0) not bigger than measure of vertex 0 (1)
NOTICE: Measure of vertex 2 (2) not bigger than measure of vertex 1 (3)
passed
  Test: test_rect_tree_distance_tree ...passed
Suite: effectivearea
  Test: do_test_lwgeom_effectivearea_lines ...passed
  Test: do_test_lwgeom_effectivearea_polys ...passed
Suite: chaikin
  Test: do_test_chaikin_lines ...passed
  Test: do_test_chaikin_polygons ...passed
Suite: filterm
  Test: do_test_filterm_single_geometries ...passed
  Test: do_test_filterm_collections ...passed
Suite: minimum_bounding_circle
  Test: basic_test ...passed
  Test: test_empty ...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
  Test: test_grid_in_place ...passed
  Test: test_clone ...passed
  Test: test_lwmpoint_from_lwgeom ...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_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: 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
  Test: test_lwgeom_voronoi_diagram ...passed
  Test: test_lwgeom_voronoi_diagram_expected_empty ...passed
  Test: test_lwgeom_voronoi_diagram_custom_envelope ...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
  Test: test_wkt_double ...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
Suite: wrapx
  Test: test_lwgeom_wrapx ...passed

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     44     44    n/a      0        0
               tests    300    300    300      0        0
             asserts   4215   4215   4215      0      n/a
Elapsed time =    0.229 seconds

PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit
  Postgis 3.0.0dev - r17081 - 2018-11-28 18:50:02
  scripts 3.0.0dev r17081
  GEOS: 3.7.0-CAPI-1.11.0 673b9939
  PROJ: Rel. 5.2.0, September 15th, 2018

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
 chaikin .. ok
 filterm .. ok
 cluster .. ok
 concave_hull .. ok
 concave_hull_hard .. ok
 ctors .. ok
 curvetoline .. ok
 dump .. ok
 dumppoints .. ok
 empty .. ok
 estimatedextent .. ok
 forcecurve .. ok
 geography .. ok
 geometric_median .. 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
 minimum_bounding_circle .. ok
 normalize .. ok
 operators .. ok
 orientation .. ok
 out_geometry .. ok
 out_geography .. ok
 polygonize .. ok
 polyhedralsurface .. ok
 postgis_type_name .. ok
 quantize_coordinates .. ok
 regress .. ok
 regress_bdpoly .. ok
 regress_gist_index_nd .. 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
 reverse .. 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_recheck .. ok
 temporal_knn .. ok
 hausdorff .. ok
 regress_buffer_params .. ok
 frechet .. 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
 voronoi .. ok
 minimum_clearance .. ok
 oriented_envelope .. ok
 in_geojson .. ok
 regress_brin_index .. ok
 regress_brin_index_3d .. ok
 regress_brin_index_geography .. ok
 regress_spgist_index_2d .. ok
 regress_spgist_index_3d .. ok
 regress_spgist_index_nd .. ok
 mvt .. ok
 geobuf .. ok
 mvt_jsonb .. ok
 uninstall .. ok (4643)

Run tests: 134
Failed: 0


-- if you build with SFCGAL

PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit
  Postgis 3.0.0dev - r17081 - 2018-11-28 18:50:02
  scripts 3.0.0dev r17081
  GEOS: 3.7.0-CAPI-1.11.0 673b9939
  PROJ: Rel. 5.2.0, September 15th, 2018
  SFCGAL: 1.3.2

Running tests

 regress_sfcgal .. ok
 empty .. ok
 geography .. ok
 legacy .. ok
 measures .. ok
 regress_ogc_prep .. ok
 regress_ogc .. ok
 regress .. ok
 tickets .. ok
 concave_hull .. ok
 wmsservers .. ok
 approximatemedialaxis .. ok
 uninstall .. ok (4643)

Run tests: 13
Failed: 0

-- if you built with raster support



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


Suite: pixtype
  Test: test_pixtype_size ...passed
  Test: test_pixtype_alignment ...passed
  Test: test_pixtype_name ...passed
  Test: test_pixtype_index_from_name ...passed
  Test: test_pixtype_get_min_value ...passed
  Test: test_pixtype_compare_clamped_values ...passed
Suite: raster_basics
  Test: test_raster_new ...passed
  Test: test_raster_empty ...passed
  Test: test_raster_metadata ...passed
  Test: test_raster_clone ...passed
  Test: test_raster_from_band ...passed
  Test: test_raster_replace_band ...passed
Suite: band_basics
  Test: test_band_metadata ...passed
  Test: test_band_pixtype_1BB ...passed
  Test: test_band_pixtype_2BUI ...passed
  Test: test_band_pixtype_4BUI ...passed
  Test: test_band_pixtype_8BUI ...passed
  Test: test_band_pixtype_8BSI ...passed
  Test: test_band_pixtype_16BUI ...passed
  Test: test_band_pixtype_16BSI ...passed
  Test: test_band_pixtype_32BUI ...passed
  Test: test_band_pixtype_32BSI ...passed
  Test: test_band_pixtype_32BF ...passed
  Test: test_band_pixtype_64BF ...passed
  Test: test_band_get_pixel_line ...WARNING: Limiting returning number values to 1
WARNING: Attempting to get pixel values with out of range raster coordinates: (5, 5)
passed
  Test: test_band_new_offline_from_path ...passed
Suite: raster_wkb
  Test: test_raster_wkb ...SRID value -1 converted to the officially unknown SRID value 0
SRID value -1 converted to the officially unknown SRID value 0
SRID value -1 converted to the officially unknown SRID value 0
SRID value -1 converted to the officially unknown SRID value 0
SRID value -1 converted to the officially unknown SRID value 0
SRID value -1 converted to the officially unknown SRID value 0
passed
Suite: gdal
  Test: test_gdal_configured ...passed
  Test: test_gdal_drivers ...passed
  Test: test_gdal_rasterize ...passed
  Test: test_gdal_polygonize ...passed
  Test: test_raster_to_gdal ...Warning 6: PNG driver doesn't support data type Float64. Only eight bit (Byte) and sixteen bit (UInt16) bands supported. Defaulting to Byte

passed
  Test: test_gdal_to_raster ...passed
  Test: test_gdal_warp ...passed
Suite: raster_geometry
  Test: test_raster_envelope ...passed
  Test: test_raster_envelope_geom ...passed
  Test: test_raster_convex_hull ...passed
  Test: test_raster_surface ...INFO: Ring Self-intersection at or near point 2 -2
INFO: Ring Self-intersection at or near point 3 -3
passed
  Test: test_raster_perimeter ...passed
  Test: test_raster_pixel_as_polygon ...passed
Suite: raster_misc
  Test: test_raster_cell_to_geopoint ...passed
  Test: test_raster_geopoint_to_cell ...passed
  Test: test_raster_from_two_rasters ...passed
  Test: test_raster_compute_skewed_raster ...passed
Suite: band_stats
  Test: test_band_stats ...passed
  Test: test_band_value_count ...passed
Suite: band_misc
  Test: test_band_get_nearest_pixel ...passed
  Test: test_band_get_pixel_of_value ...passed
  Test: test_pixel_set_to_array ...passed
Suite: mapalgebra
  Test: test_raster_iterator ...passed
  Test: test_band_reclass ...passed
  Test: test_raster_colormap ...passed
Suite: spatial_relationship
  Test: test_raster_geos_overlaps ...passed
  Test: test_raster_geos_touches ...passed
  Test: test_raster_geos_contains ...passed
  Test: test_raster_geos_contains_properly ...passed
  Test: test_raster_geos_covers ...passed
  Test: test_raster_geos_covered_by ...passed
  Test: test_raster_within_distance ...passed
  Test: test_raster_fully_within_distance ...passed
  Test: test_raster_intersects ...passed
  Test: test_raster_same_alignment ...passed
Suite: misc
  Test: test_rgb_to_hsv ...passed
  Test: test_hsv_to_rgb ...passed
  Test: test_util_gdal_open ...passed

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     12     12    n/a      0        0
               tests     65     65     65      0        0
             asserts  45896  45896  45896      0      n/a

Elapsed time =    0.499 seconds

Loading Raster into 'postgis_reg'
PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit
  Postgis 3.0.0dev - r17081 - 2018-11-28 18:50:02
  scripts 3.0.0dev r17081
  raster scripts 3.0.0dev r17081
  GEOS: 3.7.0-CAPI-1.11.0 673b9939
  PROJ: Rel. 5.2.0, September 15th, 2018
  GDAL: GDAL 2.3.1, released 2018/06/22

Running tests

 check_gdal .. ok
 load_outdb ... ok
 check_raster_columns .. ok
 check_raster_overviews .. ok
 rt_io .. ok
 rt_bytea .. ok
 rt_wkb .. ok
 box3d .. ok
 rt_addband .. ok
 rt_band .. ok
 rt_tile .. ok
 rt_dimensions .. ok
 rt_scale .. ok
 rt_pixelsize .. ok
 rt_upperleft .. ok
 rt_rotation .. ok
 rt_georeference .. ok
 rt_set_properties .. ok
 rt_isempty .. ok
 rt_hasnoband .. ok
 rt_metadata .. ok
 rt_rastertoworldcoord .. ok
 rt_worldtorastercoord .. ok
 rt_convexhull .. ok
 rt_envelope .. ok
 rt_band_properties .. ok
 rt_set_band_properties .. ok
 rt_pixelaspolygons .. ok
 rt_pixelaspoints .. ok
 rt_pixelascentroids .. ok
 rt_setvalues_array .. ok
 rt_summarystats .. ok
 rt_count .. ok
 rt_histogram .. ok
 rt_quantile .. ok
 rt_valuecount .. ok
 rt_valuepercent .. ok
 rt_bandmetadata .. ok
 rt_pixelvalue .. ok
 rt_neighborhood .. ok
 rt_nearestvalue .. ok
 rt_pixelofvalue .. ok
 rt_polygon .. ok
 rt_setbandpath .. ok
 rt_utility .. ok
 rt_fromgdalraster .. ok
 rt_asgdalraster .. ok
 rt_astiff .. ok
 rt_asjpeg .. ok
 rt_aspng .. ok
 rt_reclass .. ok
 rt_gdalwarp .. ok
 rt_asraster .. ok
 rt_dumpvalues .. ok
 rt_makeemptycoverage .. ok
 rt_createoverview .. ok
 rt_mapalgebraexpr .. ok
 rt_mapalgebrafct .. ok
 rt_mapalgebraexpr_2raster .. ok
 rt_mapalgebrafct_2raster .. ok
 rt_mapalgebrafctngb .. ok
 rt_mapalgebrafctngb_userfunc .. ok
 rt_intersection .. ok
 rt_clip .. ok
 rt_mapalgebra .. ok
 rt_mapalgebra_expr .. ok
 rt_mapalgebra_mask .. ok
 rt_union .. ok
 rt_invdistweight4ma .. ok
 rt_4ma .. ok
 rt_setvalues_geomval .. ok
 rt_elevation_functions .. ok
 rt_colormap .. ok
 rt_grayscale .. ok
 rt_gist_relationships .. ok
 rt_intersects .. ok
 rt_samealignment .. ok
 rt_geos_relationships .. ok
 rt_iscoveragetile .. ok
 bug_test_car5 .. ok
 permitted_gdal_drivers .. ok
 tickets .. ok
 loader/Basic .. ok
 loader/Projected ... ok
 loader/BasicCopy .. ok
 loader/BasicFilename .. ok
 loader/BasicOutDB .. ok
 loader/Tiled10x10 .. ok
 loader/Tiled10x10Copy .. ok
 loader/Tiled8x8 .. ok
 clean .. ok
 uninstall .. ok (4643)

Run tests: 101
Failed: 0

-- topology regress
PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit
  Postgis 3.0.0dev - r17081 - 2018-11-28 18:50:02
  scripts 3.0.0dev r17081
  GEOS: 3.7.0-CAPI-1.11.0 673b9939
  PROJ: Rel. 5.2.0, September 15th, 2018

Running tests

 regress/legacy_validate .. ok
 regress/legacy_predicate .. ok
 regress/legacy_invalid .. ok
 regress/sqlmm .. ok
 regress/legacy_query .. ok
 regress/addnode .. ok
 regress/addedge .. ok
 regress/addface .. ok
 regress/addface2.5d .. ok
 regress/addtopogeometrycolumn .. ok
 regress/polygonize .. ok
 regress/st_addisoedge .. ok
 regress/st_addisonode .. ok
 regress/st_addedgemodface .. ok
 regress/st_addedgenewfaces .. ok
 regress/st_changeedgegeom .. ok
 regress/st_createtopogeo .. ok
 regress/st_getfacegeometry .. ok
 regress/st_getfaceedges .. ok
 regress/st_modedgeheal .. ok
 regress/st_modedgesplit .. ok
 regress/st_newedgeheal .. ok
 regress/st_newedgessplit .. ok
 regress/st_remedgenewface .. ok
 regress/st_remedgemodface .. ok
 regress/st_simplify .. ok
 regress/topoelement .. ok
 regress/topoelementarray_agg .. ok
 regress/topogeo_addlinestring .. ok
 regress/topogeo_addpoint .. ok
 regress/topogeo_addpolygon .. ok
 regress/topogeom_edit .. ok
 regress/topogeometry_type .. ok
 regress/topojson .. ok
 regress/topologysummary .. ok
 regress/topo2.5d .. ok
 regress/totopogeom .. ok
 regress/droptopology .. ok
 regress/droptopogeometrycolumn .. ok
 regress/copytopology .. ok
 regress/createtopogeom .. ok
 regress/createtopology .. ok
 regress/gml .. ok
 regress/getnodebypoint .. ok
 regress/getedgebypoint .. ok
 regress/getfacebypoint .. ok
 regress/getringedges .. ok
 regress/gettopogeomelements .. ok
 regress/layertrigger .. ok
 regress/validatetopology .. ok
 uninstall .. ok (4643)

Run tests: 51
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_geocoderaddress_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.
=====================

2.2.7. インストール

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

[注記]

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

2.3. PAGC住所標準化ツールのインストールと使用

address_standardizerエクステンションは、別途ダウンロードする必要がある別パッケージとしていました。PostGIS 2.2からは同梱されています。address_standardizeの追加情報、できること、および、コンフィギュレーション方法については、「住所標準化」をご覧下さい。

標準化エクステンションは、Normalize_Addressの後継で、PostGISに入っているTigerジオコーダエクステンションに使うことができます。この場合の使い方については「TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用」を参照して下さい。また、ユーザ自身がつくるジオコーダの要素として使用したり、住所の比較を簡単にするために住所を標準化するために使うことができます。

住所標準化エクステンションはPCREに依存しています。PCREは多くのUNIX系システムにインストールされていますが、http://www.pcre.orgから最新版をダウンロードできます。「ビルドコンフィギュレーション」の際に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

2.3.1. Regex::Assembleのインストール

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"

2.4. Tigerジオコーダのインストールとアップグレードとデータロード

Tigerジオコーダのような拡張機能はPostGISディストリビューションに同梱されていません。Tigerジオコーダエクステンションが無かったり、インストールしているものより新しい版のものが欲しい場合には、Windows Unreleased Versions節でPostgreSQLの版に合ったパッケージにあるshare/extension/postgis_tiger_geocoder.*ファイルを使います。これらのパッケージはWindows用ですが、postgis_tige_geocoderエクステンションファイルは、SQLとPL/pgSQLだけですので、他のOSでも動作します。

2.4.1. TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用

PostgreSQL 9.1以上とPostGIS 2.1.0を使用している場合は、Tigerジオコーダのインストールで、新しいエクステンションモデルの利点を得ることができます。次のようにします。

  1. まず、通常の方法で、PostGIS 2.1.0のバイナリを取得するか、コンパイルしてインストールします。これにより重要なエクステンションファイルとTigerジオコーダのファイルがインストールされます。

  2. 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_platformtiger.loader_variablesに変更を加えた場合には、これらをアップデートしなければならないことがあります。

  3. 正しくインストールされたかを確認するために、インストール対象データベース内で次の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
  4. 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テーブルを編集しない場合は、一般的なアイテムの位置を持っているので、スクリプトが生成された後で、スクリプトを編集しなければなりません。

  5. 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コードが無い場合に (しばしば高速道路での逆ジオコーディングで発生します)、これを使います。

  6. サーバまたはローカル (サーバへのネットワーク接続が早い場合)のルートにgisdataというフォルダを作成します。このフォルダはTigerファイルがダウンロードされ、処理される場所です。サーバのルートにフォルダを作ると不幸になる場合や、単に他のフォルダに移したい場合には、tiger.loader_variablesテーブルのstaging_foldフィールドを編集します。

  7. gisdataフォルダ内にtempというフォルダを作成します。もしくは、staging_foldで示されたフォルダを作成します。ローダがダウンロードしたTigerデータを展開する場所です。

  8. そして、SQL関数Loader_Generate_Nation_Scriptを実行して、独自のプロファイルの名前を使うか確認し、.shまたは.batファイルにスクリプトを複写します。たとえば、新しいプロファイルで国のロードを行う場合には、次のようにします。

    psql -c "SELECT Loader_Generate_Nation_Script('debbie')" -d geocoder -tA 
    > /gisdata/nation_script_load.sh
  9. 生成された国データをロードするコマンドラインスクリプトを実行します。

    cd /gisdata
    sh nation_script_load.sh
  10. 国スクリプトを実行した後、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)
    
  11. デフォルトではbg, tract, tabblockに対応するテーブルはロードされません。ジオコーダはこれらのテーブルを使いませんが、一般に、人口統計に使います。州データのロードの一部としてロードするには、次の手続きを実行して有効にします。

    UPDATE tiger.loader_lookuptables SET load = true WHERE load = false AND lookup_name IN('tract', 'bg', 'tabblock');

    もしくは、Loader_Generate_Census_Scriptを使って州のデータをロードした後に、これらのテーブルだけをロードできます。

  12. データをロードしたい州ごとに、Loader_Generate_Scriptで州スクリプトを作ります。

    [警告]

    国データのロードを完了する前に*州スクリプトを作ってはなりません*。州スクリプトは国スクリプトでロードされる国リストを利用するためです。

  13. psql -c "SELECT Loader_Generate_Script(ARRAY['MA'], 'debbie')" -d geocoder -tA 
    > /gisdata/ma_load.sh
  14. 生成されたコマンドラインスクリプトを実行します。

    cd /gisdata
    sh ma_load.sh
  15. 全てのデータのロードが完了するか中断ポイントに達した後に、全ての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;

2.4.1.1. Tigerジオコーダ通常インストールのエクステンションモデルへの変換

エクステンションモデルを使わずにTigerジオコーダをインストールしている場合に、次のようにして、エクステンションモデルに変換できます。

  1. 「Tigerジオコーダのアップグレード」の指示に従って非エクステンションモデルのアップグレードを行います。

  2. psqlまたはpgAdminでデータベースに接続して、次のコマンドを実行します。

    CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;

2.4.2. TigerジオコーダをPostGISデータベースで有効にする: エクステンション不使用

まず、上述の手順でPostGISをインストールします。

extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.1.0.tar.gzをダウンロードします。

tar xvfz postgis-3.1.0.tar.gz

cd postgis-3.1.0/extras/tiger_geocoder

tiger_loader_2015.sql (違う年のものをロードしたくないならば最新のローダファイル)をあなたの実行サーバ等のパスに編集します。もしくはloader_platformがインストールされた後に一度これを更新します。このファイルもloader_platformも編集しない場合には、一般的なアイテムの位置を持っているだけなので、Loader_Generate_Nation_ScriptLoader_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
                        

2.4.3. TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用

皆さんが問題と思われるの多くのことのひとつに、ジオコーディング前の準備に住所を正規化する関数Normalize_Addressがあります。住所正規化は万全と言うにはほど遠く、パッチをあてようとすると膨大な資源を費やします。よって、より良い住所標準化エンジンを持つ他のプロジェクトに統合しました。この新しい住所標準化を使うには、「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)を同梱しています。これらは、必要に応じて標準化の改善のために追加や更新ができます。

2.4.4. Tigerデータのロード

データロードの説明の詳細は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.4.5. Tigerジオコーダのアップグレード

2.0以上に含まれるTigerジオコーダがインストールされている場合には、どうしても必要な訂正があるときは、いつでも臨時のアーカイブファイルからでも機能のアップグレードができます。 これは、エクステンションでインストールされていないTigerジオコーダで動作します。

extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.1.0.tar.gzをダウンロードします。

tar xvfz postgis-3.1.0.tar.gz

cd postgis-3.1.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');

生成したスクリプトの実行方法に関する説明は、「Tigerデータのロード」を参照して下さい。これは一度だけ実行する必要があります。

[注記]

2010/2011州テーブルを混在させることができ、それぞれの州について個別にアップグレードできます。2011にアップグレードする前に、まず、Drop_State_Tables_Generate_Scriptを使って、2010州テーブルを削除します。

2.5. 共通の問題

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

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

    SELECT version();

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

  2. アップグレードに失敗する場合、既にPostGISがインストールされているデータベースにリストアしているか確認して下さい。

    SELECT postgis_full_version();

また、コンフィギュアが正しくPostgreSQL、Proj4ライブラリ、GEOSライブラリのインストール先を検出したかチェックして下さい。

  1. コンフィギュアからの出力でpostgis_config.hファイルが作られます。POSTGIS_PGSQL_VERSIONPOSTGIS_PROJ_VERSIONおよびPOSTGIS_GEOS_VERSION変数が正しくセットされたかをチェックして下さい。

第3章 PostGIS管理

3.1. パフォーマンスチューニング

PostGISの調整はPostgreSQLの作業量の調整と非常に似ています。ジオメトリとラスタは重く、メモリ関連の最適化は他のPostgreSQLクエリと比べて影響が大きい点だけは留意して下さい。

PostgreSQLの最適化に関する一般的な詳細は、Tuning your PostgreSQL Serverをご覧ください。

PostgreSQL 9.4以上では、ALTER SYSTEMを使うことで、postgresql.confpostgresql.auto.confを触ることなくサーバレベルで設定できます。

ALTER SYSTEM SET work_mem = '256MB';
-- 起動時設定でない設定を強制します。新規接続に影響を与えます。
SELECT pg_reload_conf();
-- 現在の設定値を表示
-- 全ての設定を見るにはSHOW ALLを使います
SHOW work_mem;

PostgreSQLの設定に加えて、PostGISには「Grand Unified Custom変数 (GUC)」で挙げる独自設定があります。

3.1.1. 起動時

次に示す設定はpostgresql.confにあります。

constraint_exclusion

  • デフォルト: partition

  • 一般的にテーブルのパーティショニングに使われます。デフォルトとして"partition"に設定されています。継承階層内にあり、プランナにペナルティ以外を払わないなら、クエリプランナにテーブルの制約条件の解析だけを行わせるので、PostgreSQL 8.4以上ではこれが理想的です。

shared_buffers

  • デフォルト: PostgreSQL 9.6では128MB以下

  • 利用可能なRAMの25%から40%を設定します。Windowsでは高く設定することができないかも知れません。

max_worker_processes これは、PostgreSQL 9.4以上で有効です。PostgreSQL 9.6以上では、パラレルクエリ処理に使うプロセス数の最大値の制御で、さらに重要なものとなっています。

  • デフォルト: 8

  • システムが対応できるバックグラウンドプロセスの最大値を設定します。このパラメータはサーバ起動時のみ設定できます。

3.1.2. 実行時

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

この設定はPostgreSQL 9.6以上で使用でき、並列クエリに対応しているPostGIS 2.3以上に影響は限られます。0より大きい値に設定すると、ST_Intersectsといった関係関数を含むクエリで、複数プロセッサが使われるようにできます。その時、2倍を超える速度が出る可能性があります。予備のプロセッサが多数ある場合には、この値をプロセッサ数に変更するべきです。また、max_worker_processesをこの値と同じにするようにします。

  • デフォルト: 0

  • 単一のGatherノードが開始できるワーカの最大数を設定します。並列ワーカは、max_worker_processesで確立されたプロセスのプールから取得されます。要求したワーカ数は、実際には実行可能になっていない場合があることに注意して下さい。これが発生する場合には、想定より少ないワーカでプランが実行され、非効率になります。これの値を0 (デフォルト値)にすると、パラレルクエリ実行が無効になります。

3.2. ラスタ機能の設定

ラスタ機能を有効にしたら、下に示す確実な設定方法を読んだ方がいいです。

PostGIS 2.1.3以降では、データベース外ラスタと全てのラスタドライバは、デフォルトでは無効になっています。これらを有効にするには、サーバ上で、環境変数POSTGIS_GDAL_ENABLED_DRIVERSPOSTGIS_ENABLE_OUTDB_RASTERSを設定します。PostGIS 2.2では、「Grand Unified Custom変数 (GUC)」に従って設定する、クロスプラットフォームな手法があります。

データベース外ラスタを有効にするには次のようにします。

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/main/environmentを編集するのが好ましい方法です。 ここで、10はPostgreSQLのバージョンを指し、mainはクラスタを指します。

Windowsでサービスとして実行している場合には、システム変数で設定します。Windows 7では、コンピュータを右クリックしてプロパティをクリックするか、エクスプローラの検索バーにコントロール パネル\すべてのコントロール パネル項目\システムを指定します。システムの詳細設定 -> 詳細設定 -> 環境変数を順にクリックして、新しいシステム環境変数を追加します。

環境変数を設定した後は、設定を反映させるために、PostgreSQLサービスの再起動が必要です。

3.3. 空間テーブルの作成

3.3.1. エクステンションを使って空間データベースを有効にする

PostgreSQL 9.1以上を使っていて、エクステンションのPostGISモジュールをコンパイル、インストールしている場合には、エクステンションというメカニズムを使用して、データベースを空間データベースに切り替えることができます。

中核となるPostGISエクステンションには、ジオメトリ、ジオグラフィ、spatial_ref_sysおよび全ての関数とコメントが含まれています。ラスタとトポロジは別のエクステンションになっています。

空間データベースにしたいデータベース上で次のSQLを実行します。

CREATE EXTENSION IF NOT EXISTS plpgsql;
      CREATE EXTENSION postgis;
      CREATE EXTENSION postgis_raster; -- OPTIONAL
      CREATE EXTENSION postgis_topology; -- OPTIONAL

3.3.2. エクステンションを使わずに空間データベースを有効にする (非推奨)

[注記]

これは、通常はPostgreSQLのエクステンションのディレクトリ内にPostGISをインストールできないか、したくない場合 (たとえばテスト中や開発中、または制限のある環境内)にのみ必要となります。

ビルドの際に指定した[prefix]/share/contrib内にある様々なSQLファイルをロードしてPostGISオブジェクトと関数の定義をデータベースに追加します。

中核のPostGISオブジェクト (ジオメトリ型とジオグラフィ型、これらに対応する関数)はpostgis.sqlスクリプトにあります。ラスタオブジェクトはrtpostgis.sqlスクリプトにあります。トポロジオブジェクトはtopology.sqlスクリプトにあります。

完全なEPSG座標系定義IDセットについては、spatial_ref_sys.sql定義ファイルをロードしてspatial_ref_sysテーブルを生成して下さい。これによりジオメトリ関数ST_Transform()が実行できるようになります。

PostGIS関数にコメントを追加したい場合には、postgis_comments.sqlスクリプト内のコメントが見つかると思います。コメントはpsqlのターミナルウィンドウから単に\dd [関数名]と打ち込むだけで見ることができます。

ターミナルで次のシェルコマンドを実行します。

DB=[データベース名]
    SCRIPTSDIR=`pg_config --sharedir`/contrib/postgis-3.1/

    # Core objects
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/spatial_ref_sys.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis_comments.sql # OPTIONAL

    # Raster support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/rtpostgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/raster_comments.sql # OPTIONAL

    # Topology support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/topology.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/topology_comments.sql # OPTIONAL

3.3.3. 空間データベースをテンプレートから生成する

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

3.4. 空間データベースのアップグレード

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

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

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

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

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

エクステンションを使ってインストールした場合は、エクステンションモデルでアップグレードしなければなりません。 古いSQLスクリプトを使ってインストールした場合は、SQLスクリプトでアップグレードすべきです。適切な方を参照して下さい。

3.4.1.1. 9.1より前またはエクステンションを使わないソフトアップグレード

PostGISをエクステンションを使わずにインストールした人向けです。エクステンションを使っていてこの方法を使うと、次のようなメッセージが現れます。

can't drop ... because postgis extension depends on it

ご注意: PostGIS 1.*またはr7429以前のPostGIS 2.*へ移行する場合には、この手続きを使うことができませんが、HARD UPGRADEを実行する必要があります。

コンパイルとインストール (make install)の実行後に、インストール先フォルダ内にある*_upgrade.sqlのファイルの集合を見つけておくべきです。次のコマンドで一覧を得られます。

ls `pg_config --sharedir`/contrib/postgis-3.1.0/*_upgrade.sql

postgis_upgrade.sqlから順番に全てをロードします。

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

同じ手続きをラスタ、トポロジ、SFCGALエクステンションに適用します。それぞれのファイル名はrtpostgis_upgrade.sql, topology_upgrade.sql, sfcgal_upgrade.sqlになります。次のように実行します。

psql -f rtpostgis_upgrade.sql -d [データベース名]
psql -f topology_upgrade.sql -d [データベース名]
psql -f sfcgal_upgrade.sql -d [データベース名]
[注記]

求める版へのアップグレードに使う特定のpostgis_upgrade.sqlが発見できない場合には、ソフトアップグレードを実行するにはあまりに前の版を使っています。ハードアップグレードが必要です。

PostGIS_Full_Version関数の"procs need upgrade"というメッセージで、この種のアップグレードを実行する必要性についての情報が得られます。

3.4.1.2. 9.1以上でエクステンションを使ったソフトアップグレード

エクステンションを使ってPostGISをインストールした場合には、エクステンションを使ってアップグレードする必要があります。エクステンションを使ったマイナーアップグレードはかなり楽です。

ALTER EXTENSION postgis UPDATE TO "3.1.0";
ALTER EXTENSION postgis_topology UPDATE TO "3.1.0";

次のようなエラー通知が表示されることがあります。

No migration path defined for ... to 3.1.0

この場合は、データベースをバックアップして、「エクステンションを使って空間データベースを有効にする」に記述されているように新しいデータベースを生成し、バックアップを新しいデータベースにリストアしなければなりません。

次のようなメッセージを得ることがあります。

Version "3.1.0" of extension "postgis" is already installed

この場合は、全てアップデートされていて、安全に無視できます。SVN版から次版 (新しい版番号を得ていないもの)にアップグレードしようとしない限り、"next"を版文字列に追加できます。ただし、次回に"next"を削除する必要があります。

ALTER EXTENSION postgis UPDATE TO "3.1.0next";
ALTER EXTENSION postgis_topology UPDATE TO "3.1.0next";
[注記]

PostGISをバージョン指定なしにインストールした場合には、 しばしばリストアの前のPostGIS EXTENSIONの再インストールをとばすことができます。 バックアップはCREATE EXTENSION postgisだけで、リストアの間に最新版になります。

[注記]

PostGISエクステンションを3.0.0以前からアップグレードする場合には、PostGISラスタ機能はパッケージ化されずに終わります。ラスタ機能の再パッケージは次のコマンドでできます。

    CREATE EXTENSION postgis_raster FROM unpackaged;
    

その後、不要なら削除します。次のようにします。

DROP EXTENSION postgis_raster;
    

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

ハードアップグレードとは、PostGISで利用可能なデータの完全なダンプ/リロードを意味します。PostGISオブジェクトの内部格納状態が変更される場合や、ソフトアップグレードができない場合に、ハードアップグレードが必要です。付録のリリースノートに、版ごとについて、ダンプ/リロード (ハードアップグレード)の要否を記載しています。

ダンプ/リロード作業はpostgis_restore.plスクリプトが補助します。このスクリプトは、PostGIS (古いものを含む)に属する定義を全て飛ばすように注意します。また、重複シンボルエラーや非推奨オブジェクトを持越すことなく、スキーマとデータをPostGISをインストールしたデータベースにリストアできます 。

Windows用に関する追加情報はWindows Hard upgradeにあります。

手続きは次の通りです。

  1. アップグレードしたデータベース (olddbと呼ぶことにしましょう)の「カスタム書式」のダンプを、バイナリBLOBデータを含めたダンプを指定して (-b)、verboseモード (-v)で生成します。ユーザはデータベースのオーナーになることができ、PostgreSQLのスーパーユーザである必要はありません。

    pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/olddb.backup" olddb
  2. 新しいデータベースにPostGISを、PostGISが無い状態からインストールします。このデータベースをnewdbと呼ぶことにします。この作業に関する説明については「エクステンションを使わずに空間データベースを有効にする (非推奨)」「エクステンションを使って空間データベースを有効にする」とを参照して下さい。

    ダンプにあるspatial_ref_sysは、リストアされますが、既にあるspatial_ref_sysを上書きしません。リストア対象のデータベースに公式データセットの訂正が確実に伝わるようにするためです。標準のエントリを上書きしたい場合は、newdbを生成する際にspaltial_ref_sys.sqlファイルをロードしないだけです。

    データベースが本当に古く、ビューや関数に、長く非推奨になっている関数があるような場合には、関数やビューを使えるようにするlegacy.sqlをロードする必要があるでしょう。ただし、本当に必要な場合に限ります。可能なら、ビューや関数をダンプせずにアップグレードすることを検討して下さい。非推奨関数は、uninstall_legacy.sqlで後から削除することができます。

  3. バックアップを新しいnewdbデータベースにリストアするには、postgis_restore.plを使います。psqlが予期せぬエラーを標準エラー出力に出すことがあります。これらのログを保存しておいて下さい。

    perl utils/postgis_restore.pl "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2
    > errors.txt

エラーは次の場合に起こりえます。

  1. ビューまたは関数の中に非推奨のPostGISオブジェクトを使っているものがある場合。これの訂正には、リストア前にlegacy.sqlスクリプトのロードを試してみることができます。非推奨オブジェクトをまだ持っている版のPostGISにリストアして、コードを作り替えた後に再び移動させることもできます。 legacy.sqlを利用する場合は、非推奨関数を使うのをやめたコードに訂正して、uninstall_legacy.sqlをロードするのを忘れないでください。

  2. ダンプファイル内のspatial_ref_sysにあるカスタムレコードが不正なSRIDになっていることがあります。妥当なSRID値は0より大きく999000より小さくなります。999000から999999の間は内部利用のための予約領域ですが、999999より大きい値は一切使用できません。全ての不正なSRIDを持つ独自レコードは、予約領域に移動しても保持されます。しかし、spatial_ref_sysテーブルから、値が保持されるように設定されているチェック制約が外れます。場合によっては (複数の不正なSRIDが同じ予約領域のSRID値に変換されるとき)、主キーも外れます。

    これを修正するために、独自のSRSを妥当な値 (910000..910999の範囲)のSRIDに複写し、全てのテーブルを新しいSRIDに変更 (UpdateGeometrySRID)し、spatial_ref_sysから不正なエントリを削除します。そして、次のようにチェック制約を再構築します。

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

    フランスIGN地図を含む古いデータベースをアップグレードする場合には、おそらくSRIDが範囲外になり、データベースのインポート時に次のような問題に遭遇します。

     WARNING: SRID 310642222 converted to 999175 (in reserved zone)

    この場合には、次のステップを試すことができます。最初にpostgis_restore.plから出たIGNをSQLから完全に破棄します。そのために次のコマンドを実行します。

    perl utils/postgis_restore.pl "/somepath/olddb.backup" 
    > olddb.sql

    さらに、次のコマンドを実行します。

    grep -v IGNF olddb.sql 
    > olddb-without-IGN.sql

    その後、新しいデータベースを生成し、必要なPostGISエクステンションを有効化して、このスクリプトで確実にフランスIGNの系を挿入します。これらの処理の後、次のようにデータのインポートを行います。

    psql -h localhost -p 5432 -U postgres -d newdb -f olddb-without-IGN.sql  2
    > errors.txt

第4章 PostGISの使用

目次
4.1. データ管理
4.1.1. GISオブジェクト
4.1.2. PostGISジオグラフィ型
4.1.3. 空間メタデータテーブル
4.1.4. ジオメトリ検証
4.1.5. 空間データのロード
4.1.6. 空間データの抽出
4.1.7. 空間インデックスを構築する
4.2. 空間クエリ
4.2.1. 空間関係の決定
4.2.2. インデックスの利点を使う
4.2.3. 空間SQLの例
4.3. 性能向上に関する技法
4.3.1. 大きなジオメトリを持つ小さなテーブル
4.3.2. ジオメトリインデクスでCLUSTERを実行する
4.3.3. 次元変換の回避
4.4. アプリケーションのビルド
4.4.1. MapServerを使う
4.4.2. Javaクライアント (JDBC)
4.4.3. Cクライアント (libpq)
4.5. ラスタデータの管理、クエリ、アプリケーション
4.5.1. ラスタのロードと生成
4.5.2. ラスタカタログ
4.5.3. PostGISラスタを使ったカスタムアプリケーションの構築
4.6. トポロジ
4.6.1. トポロジ型
4.6.2. トポロジドメイン
4.6.3. トポロジ管理とTopoGeometry管理
4.6.4. トポロジ統計管理
4.6.5. トポロジコンストラクタ
4.6.6. トポロジエディタ
4.6.7. トポロジアクセサ
4.6.8. トポロジ処理
4.6.9. TopoGeometryコンストラクタ
4.6.10. TopoGeometryエディタ
4.6.11. TopoGeometryアクセサ
4.6.12. TopoGeometry出力
4.6.13. トポロジ空間関係関数
4.7. 住所標準化
4.7.1. パーサの動作
4.7.2. 住所標準化の型
4.7.3. 住所標準化テーブル
4.7.4. 住所標準化関数
4.8. PostGIS追加機能
4.8.1. Tigerジオコーダ

4.1. データ管理

4.1.1. GISオブジェクト

PostGISでサポートされるGISオブジェクトは、OpenGIS Consortium (OGC)が定義する"Simple Features"標準のスーパーセットです。 PostGISはOGCの"Simple Features for SQL" (SFS)仕様で定められた全てのオブジェクトと関数に対応しています。

PostGISは標準から拡張してSRIDの組み込みに対応しています。

4.1.1.1. OpenGIS WKBとWKT

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

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

  • POINT(0 0)

  • POINT Z (0 0 0)

  • POINT ZM (0 0 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))

  • MULTIPOINT Z ((0 0 0),(1 2 3))

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

4.1.1.2. PostGIS EWKB, EWKTと標準形式

最初のOpenGIS使用 (1.2.0より前)は2次元ジオメトリしかサポートされておらず、また、入出力の表現においてSRIDは*決して*埋め込まれません。

最後のOpenGIS 1.2.1仕様ではZ,M修飾子を指定するXYM座標とXYZ座標に対応していますが、入出力表現に、関連するSRIDが含まれていません。

PostGIS EWKB/EWKT では 3DM, 3DZ, 4D の座標サポートが追加され、SRID情報が埋め込まれます。しかしながら、EWKB/EWKT出力には次のような相違点があります。

  • XYZジオメトリの場合、Z修飾子は削除されます。

    OpenGIS: POINT Z (1 2 3)

    EWKB/EWKT: POINT(1 2 3)

  • XYMジオメトリはM修飾子を保持します。

    OpenGIS: POINT M (1 2 3)

    EWKB/EWKT: POINTM(1 2 3)

  • XYZMジオメトリではZM修飾子が削除されます。

    OpenGIS: POINT ZM (1 2 3 4)

    EWKB/EWKT: POINT(1 2 3 4)

こうすることで、EWKB/EWKTは次元を過度に指定することや、次に示すようなISOが認める潜在的エラーの種別全体を回避しています。

  • POINT ZM (1 1)

  • POINT ZM (1 1 1)

  • POINT (1 1 1 1)

[注意]

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

拡張された空間オブジェクトのテキスト表現 (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)

4.1.1.3. SQL-MM第3部

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です。

4.1.2. PostGISジオグラフィ型

ジオグラフィ型は、「地理」座標 (しばしば「測地」座標、"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)の返り値の単位と、ST_DWithinの入力の単位はメートルです。

ジオグラフィ型はPostgreSQLのtypmod定義書式を使います。ジオグラフィカラムを持つテーブルに1ステップで追加できます。標準OGC書式は曲線を除いてサポートします。

4.1.2.1. ジオグラフィ基礎

ジオグラフィ型はシンプルフィーチャーの最も簡単なもののみサポートします。標準的なジオメトリ型データで、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;

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

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

4.1.2.2. ジオグラフィ型をジオメトリ型にして使用すべき時

ジオグラフィ型によって、経度緯度座標でデータを格納できるようになりましたが、ジオグラフィで定義されている関数が、ジオメトリより少ないのと、実行にCPU時間がかかる、というところが犠牲になっています。

選択した型が、期待する領域から出ないことを、ジオメトリ型にして使用する条件とすべきです。使用するデータは地球全体か、大陸か、州か、自治体か?

  • データが小さいエリア内におさまるなら、適切な投影を選択してジオメトリを使うのが、効率面でも機能面でも最も良い方法です。

  • データが地球全体か大陸なら、ジオグラフィで投影法の細かい問題を気にせずにシステムを構築できるでしょう。経度/緯度のデータを保存して、ジオグラフィで定義された関数使います。

  • 投影法を理解していなくて、学習したくもなくて、かつ、ジオグラフィで使える関数が限られていることを受け入れるのなら、ジオグラフィを使った方が簡単です。単純にデータを経度/緯度でロードして、そこから進めて下さい。

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

4.1.2.3. ジオグラフィに関する高度なよくある質問

4.1.2.3.1. 球または回転楕円体のどちらで計算するのでしょうか?
4.1.2.3.2. 日付変更線や極に関してはどうなっていますか?
4.1.2.3.3. 処理できる最も長い弧はどうなりますか?
4.1.2.3.4. なぜヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか?

4.1.2.3.1.

球または回転楕円体のどちらで計算するのでしょうか?

デフォルトでは、全ての距離と面積の計算は回転楕円体で行います。局所的なエリアでの計算結果と良好な投影を施した平面での結果と比較して下さい。大きなエリアの場合は、回転楕円体計算は、投影平面上でのどの計算よりも精度が高くなります。

全てのジオグラフィ関数には、最後の真偽パラメータを'FALSE'にすると球面を使った計算を行うというオプションがあります。これは、特にジオメトリが非常に単純である場合に計算を速くするためのものです。

4.1.2.3.2.

日付変更線や極に関してはどうなっていますか?

全ての計算に日付変更線や極の概念がありません。座標は球 (経度/緯度)であるので、日付変更線とクロスする形状は、計算の観点からは、他のものと変わりありません。

4.1.2.3.3.

処理できる最も長い弧はどうなりますか?

大圏の弧を2点の「補完線」として使用しています。任意の2点は、実際には2方向につながっていて、どちらの方向に行くかに依存します。PostGISの全てのコードは、大圏コースの2コースのうち*短い*方でつながっていると仮定しています。結果として、180度以上の弧を持つ形状は正しくモデル化されません。

4.1.2.3.4.

なぜヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか?

ポリゴンがとんでもなく大きいからです。二つの理由から、大きなエリアは悪いです。一つは、バウンダリボックスが大きいため、どのようなクエリを走らせても、インデックスがフィーチャーを引っ張ってくる傾向にあるためです。もう一つは、頂点数が巨大で、テスト (距離、包含)関数では、少なくとも1回、通常はN (Nは、もう一方のフィーチャーの頂点数)回、頂点を横断しなければならないためです。

ジオメトリでは、大きなポリゴンを持っているけれども小さな範囲のクエリを実行する時、ジオメトリデータ情報を小片に「非正規化」します。これにより、インデックスが効果的にオブジェクトの一部を問い合わせるようになり、またクエリが常にオブジェクト全体を引っ張りこむようなことがないようになります。ST_Subdivideを参照して下さい。ヨーロッパ全体を一つのポリゴンに*格納できる*からといって、*そうすべき*だというわけではありません。

4.1.3. 空間メタデータテーブル

OpenGIS "Simple Features Specification for SQL"では、ジオメトリと座標系のテーブル構造を記述するメタデータテーブルが定義されています。このメタデータの一貫性を保つために、空間カラムの生成と削除といった操作が、OpenGISが定義する特別な手続きを通して実行されます。

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

4.1.3.1. SPATIAL_REF_SYSテーブルと空間参照系

PostGISで使用されるSPATIAL_REF_SYSは、OGC準拠のデータベーステーブルで3000件の空間参照系 (spatial reference systems)と、空間参照系間を変換 (投影変換)するのに必要な詳細の一覧を持っています。

PostGISのSPATIAL_REF_SYSテーブルには、PROJ投影ライブラリで処理される最も一般的な空間参照系の定義が3000件以上存在します。しかし、このテーブルに含まれていない多くの座標系があります。PROJに精通している場合には、独自の空間参照系を定義できます。ほとんどの空間参照系は地域的なものであり、範囲外で使用する場合は意味を持たない点に注意してください。

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

一般的に使用される空間参照系には4326 - WGS 84経度緯度4269 - NAD 83 経度緯度3395 - WGS 84 メルカトル2163 - 米国ナショナルアトラス正積図法、60個のWGS84 UTMゾーンがあります。UTMゾーンは計測に最適ですが、6度 (訳注: 経度)の領域のみをカバーします (対象地域に使用するUTMゾーンを決定するにはutmzone PostGIS plpgsql helper functionを参照してください)。

米国の州では、州平面空間参照系 (メートルまたはフィート単位)を使用します。この空間参照系は州ごとに一つか二つ存在します。ほとんどのメートル単位のものはコアのセットに存在しますが、フィート単位の多数のものやESRIが作成したものはspatialreference.orgからロードする必要があります。

地球外の座標系でさえも定義することができます。たとえばMars 2000です。この火星の座標系は非平面 (回転楕円体の度)ですが、geography型で、度でなくメートル単位で長さや近接測定値を取得することができます。

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

カラムは次の通りです。

SRID

データベース内のSpatial Reference System (SRS, 空間参照系)で一意に識別される整数コードです。

AUTH_NAME

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

AUTH_SRID

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

SRTEXT

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

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

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

PROJ4TEXT

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

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

詳細情報についてはPROJウェブサイトをご覧下さい。spatial_ref_sys.sqlファイルには、全てのEPSG投影について、SRTEXTPROJ4TEXTの定義があります。

4.1.3.2. GEOMETRY_COLUMNSビュー

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

カラムは次の通りです。

F_TABLE_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME

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

F_GEOMETRY_COLUMN

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

COORD_DIMENSION

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

SRID

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

TYPE

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

[注記]

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

4.1.3.3. 空間テーブルを作る

空間データを持つテーブルの生成は、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);

4.1.3.4. 手動でジオメトリカラムをgeometry_columnsに登録する

これが必要になる事例に、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

4.1.4. ジオメトリ検証

PostGISはOpen Geospatial Consortium (OGC)のOpenGIS仕様に準拠しています。多くのPostGISメソッドは、操作対象のジオメトリが単純かつ妥当であることが求められます (正確に言うとそう仮定します)。たとえば、ポリゴンの外に穴があるようなものの面積を計算したり、単純でない境界線を持つポリゴンを作ったりするのは、意味がありません。

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

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

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

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

(a)

(b)

(c)

(d)

(a)(c)は単純なLINESTRINGです。(b)(d)は単純ではありません。

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

(e)

(f)

(g)

(e)(f)は単純なMULTILINESTRINGです。(g)は単純ではありません。

定義からPOLYGONは常に単純です。バウンダリ内の環 (外環と内環からなる)のうち二つがクロスしていないなら妥当です。POLYGONの境界は、POINTとインタセクトするかも知れませんが、接点にしかなりません (すなわち線上にない)。POLYGONはカットラインまたはスパイクを持たなくても良く、内環は外環の中に完全に含まれていなければなりません。

(h)

(i)

(j)

(k)

(l)

(m)

(h)(i)は妥当なPOLYGONです。(jからm)は単一のPOLYGONとしては表現できませんが、(j)(m)は妥当なMULTIPOLYGONとして表現できます。

MULTIPOLYGONは、全ての要素が妥当で、二つのポリゴン要素について内側がインタセクトしていない場合は妥当です。ポリゴン要素の任意の二つの境界は接触してもよいですが、有限な数のPOINTでなければなりません。

(n)

(o)

(p)

(n)(o)は妥当でないMULTIPOLYGONです。(p)は妥当です。

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を指定すれば十分です。

4.1.5. 空間データのロード

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

4.1.5.1. SQLを使ってロードする

空間データを文字表現 (WKTかWKB)に変換できたら、SQLを使うのがPostGISにデータを持たせる最も簡単です。SQLユーティリティのpsqlを使用して、SQLのINSERTステートメントのテキストファイルをロードすると、データをPostGIS/PostgreSQLに一括読み込みできます。

データアップロードファイル (たとえば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;

SQLファイルのPostgreSQLへのロードはpsqlを使います。次のようにします。

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

4.1.5.2. シェープファイルローダを使う

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

グラフィカルユーザインタフェースを持つshp2pgsql-guiもあります。コマンドラインローダのオプションのほとんどが使えます。これは、スクリプト化されていない1回限りのロードの場合や、PostGIS初心者がロードする場合に、簡単に使用できます。PgAdminIIIのプラグインとすることもできます。

(c|a|d|p) 相互に排他的なオプションです

-c

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

-a

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

-d

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

-p

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

-?

ヘルプ画面を表示します。

-D

出力データにPostgreSQLのダンプ書式を用います。このモードは-a, -c, -dと組み合わせて利用します。デフォルトの"insert"によるSQL書式よりも、大変早くロードできます。大きなデータセットではこちらを使用して下さい。

-s [<FROM_SRID>:]<SRID>

指定したSRIDを持つジオメトリテーブルの生成や追加を行います。FROM_SRIDが与えられた場合には、入力シェープファイルに、これを使います 。この場合には、ジオメトリは変更先SRIDに投影変換します。

-k

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

-i

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

-I

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

-m

-m a_file_nameで、長いカラム名を10文字のDBFカラム名に対応付けるファイルを指定します。ファイルは、1以上の行を持ちます。各行は空白区切りで二つの名前を持ち、行頭行末に空白を入れません。例を次に示します。

COLUMNNAME DBFFIELD1
AVERYLONGCOLUMNNAME DBFFIELD2

-S

マルチ系ジオメトリの替りに単一ジオメトリを生成します。全てのジオメトリが実際に単一である (たとえば単一の外環でなるMULTIPOLYGONや単一の頂点でなるMULTIPOINT)場合にのみ成功します。

-t <次元>

出力ジオメトリが特定の次元を持つよう強制します。次元は、2D, 3DZ, 3DM, 4Dの文字列を使います。

入力の次元が出力より小さい場合には、出力では0が入ります。入力の次元が大きい場合には、外されます。

-w

出力書式をWKBでなくWKTにします。精度が低下して、座標変動が発生しうることに注意が必要です。

-e

トランザクションを使わずに、ステートメントごとに実行するようにします。エラーの元となる不良なジオメトリがいくつか含んでいる時に、大半の良好なデータのロードが可能にするものです。ダンプ書式ではトランザクションを常に使うので、-Dフラグを指定している場合には使えません。

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

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

-N <方針>

NULLジオメトリ操作方針(insert*=挿入, skip=スキップ, abort=強制終了)を選択します。

-n

DBFファイルのみインポートします。対応するシェープファイルを持っていない場合、 自動的にこのモードになり、DBFファイルのみロードします。 このフラグは、完全なシェープファイル群を持っていて、属性データだけが欲しくてジオメトリが欲しくない時のみ使用します。

-G

ジオメトリ型のかわりに、ジオグラフィ型で、WGS84経度緯度 (SRID=4326)を使用します (経度緯度データが必要です)。

-T <tablespace>

新しいテーブルのテーブル空間を指定します。 -Xパラメータが使われない場合には、インデックスはデフォルトのテーブル空間を使用します。PostgreSQL文書には、テーブル空間を用いるべき時に関する良い文書があります。

-X <tablespace>

新しいテーブルのインデックスで使われるテーブル空間を指定します。 主キーインデックスに適用され、-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

4.1.6. 空間データの抽出

空間データはSQLかシェープファイルダンパを使うと抽出できます。SQLの節では空間テーブルで比較とクエリに使用できる関数を示します。

4.1.6.1. 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文を使います。空間に制限をかけるには次の関数を使います。

ST_Intersects

この関数は、二つのジオメトリが空間を共有しているかどうかをテストします。

=

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

次に、これらの演算子をクエリで使うことができます。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を使っていることに注意して下さい。

4.1.6.2. ダンパを使う

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

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

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

-f <ファイル名>

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

-h <ホスト>

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

-p <ポート>

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

-P <パスワード>

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

-u <ユーザ名>

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

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

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

-b

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

-r

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

-m ファイル名

識別名を10文字名に再割り当てします。 ファイルの中身は、一つの空白で区切られ、前と後に空白が無い二つのシンボルの行からなります。VERYLONGSYMBOL SHORTONE ANOTHERVERYLONGSYMBOL SHORTER等となります。

4.1.7. 空間インデックスを構築する

インデックスによって巨大データセットの空間データベースの使用が可能となります。インデックス無しでは、地物の検索を行う際に、データベースの全てのレコードに対するシーケンシャルスキャンが必要となります。インデックスによって、データからレコード探索のために早く移動できる構造を構築するので、検索速度が向上します。

一般に属性データ使われるB木インデックスによる方法は、空間データにはあまり使いやすくはありません。1次元のデータの格納と問い合わせにしか対応していないためです。ジオメトリのように2以上の次元を持つデータには、データの次元の全ての範囲に対応するインデックス手法が必要です (B木と明示的な範囲検索を使って、いわゆるXYデータのインデックスを生成することが可能です)。空間データ処理におけるPostgreSQLの主な利点は、高次元データで有効に動作する数種類のインデックス、すなわちGiST、BRIN、SP-GiSTを提供していることです。

  • GiST (Generalized Search Tree)インデックスは、データを「一方にあるもの」「オーバラップするもの」「内部にあるもの」に分解するもので、GISデータを含む幅広い範囲で使えます。PostGISはGiSTインデックス空間データをR木インデックス実装のベースにています。GiSTは最も一般的に使われ、多目的なインデックス手法で、非常に良好な問い合わせ効率を提供しています。

  • BRIN (Block Range Index)インデックスは、空間範囲を集計することで動作します。探索は範囲のスキャンを通して行われます。BRINは一部の種類 (空間的にソートされ、更新がほぼ無いか全く無い)のデータだけに適切です。しかし、インデックス生成時間は非所に早く、インデックスサイズは非常に小さくなります。

  • SP-GiST (Space-Partitioned Generalized Search Tree)は4分木、kd木、基数木 (トライ木)のような部分木探索に対応する一般的なインデックス手法です。

詳細情報についてはPostGIS WorkshopPostgreSQL documentationを参照して下さい。

4.1.7.1. GiSTインデックス

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 [テーブル名] [(カラム名)];

4.1.7.2. BRINインデックス

BRINは"Block Range Index"の略です。PostgreSQL 9.5で導入された汎用index methodです。BRINは不可逆インデックス手法であり、レコードが与えた検索条件に合致することを確認する二番目のチェックが必要であることを意味しています (全ての空間インデックスで言えます)。非常に速いインデックス作成、非常に小さいインデックスサイズで、合理的な読み込み効率を持ちます。主目的は、非常に大きいテーブルのテーブル内の物理位置と関係があるカラムにインデックスを作ることに対応するためです。空間インデックスに加えて、BRINは様々な種類の属性データ構造 (整数、配列等)で速度向上させることができます。

空間テーブルが、ひとたび数千行を超えると、データの空間検索の速度向上にインデックスが必要と感じることになります。GiSTインデックスは、サイズがデータベースで使えるRAM容量を超えず、インデックスのストレージサイズに余裕があり、書き込み時のインデックス更新コストにも余裕があるなら、非常に高いパフォーマンスを発揮します。そうでない場合には、非常に大きなテーブルにおいては、BRINインデックスを代替に考えることができます。

BRINインデックスは、連続するテーブルブロックの集合 (ブロック範囲と言います)の全てのジオメトリを囲むバウンディングボックスを格納します。インデックスを使用した問い合わせを実行する時に、問い合わせ範囲とインタセクトするブロック範囲を見つけるためにスキャンします。これは、データが物理的に整列していて、ブロック範囲のバウンディングボックスのオーバラップが最小である (理想的には相互に排他的である)場合に限って効率的です。結果インデックスは非常に小さいサイズですが、通常、読み込み効率は、同じデータにおけるGiSTインデックスより悪くなります。

BRINインデックスの構築は、はGiSTインデックスと比べて、CPU集中を非常に減らします。BRINインデックスはGiSTインデックスよりも、同じデータに対して10倍速く構築するのが普通です。BRINインデックスはテーブルブロックの範囲ごとに一つのバウンディングボックスしか格納しないので、GiSTインデックスと比べて、ディスクスペースを1000倍少なくできます。

レンジ内で要約するブロック数を選択できます。この数字を減らすと、インデックスは大きくなりますが、効率向上の助けになる可能性があります。

BRINを効果的にするには、テーブルデータをブロック範囲のオーバラップの量を最小にするような物理的オーダーで格納します。データが既に適切に並び替えられているかも知れません (たとえば、既に空間オーダーで並び替えられているデータセットを他のデータベースからロードする場合)。そうでない場合には、一つの空間キーによるデータの並べ替えで実現できます。一つの方法として、ジオメトリ値で並べ替えた新しいテーブルを生成することです (最近のPostGISのバージョンで効果的なヒルベルト曲線オーダーが使われています)。

CREATE TABLE table_sorted AS
   SELECT * FROM table  ORDER BY geom;

もしくは、データは、ジオハッシュを (一時的な)インデックスに使い、そのインデックスでクラスタリングを行うことによって適切に並べ替えることができます。

CREATE INDEX idx_temp_geohash ON table
    USING btree (ST_GeoHash( ST_Transform( geom, 4326 ), 20));
CLUSTER table USING idx_temp_geohash;

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検索に対応しません。

BRINと他のインデックスとの重要な違いは、データベースがインデックスを動的に保守しないことです。テーブルの空間データを変更すると、単純にインデックスの末尾に追加しています。このためインデックス探索の能率が時間とともに低下します。インデックスはVACUUMか空間関数brin_summarize_new_values(regclass)を実行することで更新できます。このため、BRINは読み込み専用か、書き込みがほとんど発生しないよなデータでの利用では最も適切になりえます。詳細情報については、manualをご覧下さい。

空間データにBRINを使用して集計するには:

  • インデックス構築時間は非常に速く、インデックスサイズは非常に小さいです。

  • インデックスのクエリ時間はGiSTより遅いですが、十分許容できます。

  • テーブルデータを空間順序で並べ替える必要があります。

  • 手動でインデックスの保守をする必要があります。

  • 巨大なテーブルであって、オーバラップが少ないか無く (ポイントなど)、かつ静的か頻繁には変更しないようなものに、最も適しています。

4.1.7.3. SP-GiSTインデックス

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探索に対応していません。

4.1.7.4. インデックスを使う

通常、インデックスは見えないところでデータアクセスの速度向上を行います。すなわち、ひとたびインデックスが構築されたら、クエリプランナは自動的に、クエリプランの速度を向上させるためにインデックス情報を使うべき時を判断します。残念なことに、クエリプランナは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プランナがまだ最適化できないSQL構成なのかも知れません。プランナが処理できるようにクエリを再記述できるかもしれません。例えば、インラインSELECTを持つ副問い合わせがあると、効果的なプランを作らないことがあり、LATERAL JOINを使うように書き換えることができます。

4.2. 空間クエリ

空間データベースのレゾンデートルは、通常はデスクトップGISの機能が必要なクエリをデータベース内で実行することです。PostGISを使うには、使用可能な空間関数は何かを知り、またクエリ内でどう使うかを知って、適切なインデックスで能率を向上させることが求められます。

4.2.1. 空間関係の決定

空間関係は、二つのジオメトリについて、一方がもう一方にどのような相互関係ちなっているかを示すものです。ジオメトリのクエリにおける基本的な機能です。

4.2.1.1. Dimensionally Extended 9-Intersection Model

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

点集合トポロジ理論では、2次元空間に埋め込まれたジオメトリの中にあるポイントは、次に示す三つの集合に分類されます。

境界 (Boundary)

ジオメトリの境界は、一次元低いジオメトリです。POINTでは、次元が0になり、境界は空集合です。LINESTRINGの境界は二つの端点です。POLYGONの境界は、外環と内環の線です。

内部 (Interior)

ジオメトリの内部は、ジオメトリの境界以外のポイントです。POINTでは、内部はポイント自体です。LINESTRINGの内部は端点の間のポイントの集合です。POLYGONの内部は、ポリゴン内部の面です。

外部 (Exterior)

ジオメトリの外部はジオメトリが組み込まれた空間の残りです。言い換えると、ジオメトリの内部にも境界にもない点の全てです。これは2次元の閉じていない面になります。

Dimensionally Extended 9-Intersection Model (DE-9IM)は、二つのジオメトリの空間関係を九つの交差の次元を指定することで記述します。交差次元は3×3の交差行列で正式に表現することができます。

ジオメトリgに対する内部境界外部I(g)B(g)E(g)と表記します。また、dim(s)sの集合を{0,1,2,F}の値で示すます。

  • 0 => 点

  • 1 => 線

  • 2 => 面

  • F => 空集合

この表記法を使うと、二つのジオメトリabの交差行列は次の通りです。

 内部 (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) )

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

 

 内部 (Interior)境界 (Boundary)外部 (Exterior)
内部 (Interior)

dim( I(a) ∩ I(b) ) = 2

dim( I(a) ∩ B(b) = 1

dim( I(a) ∩ E(b) ) = 2

境界 (Boundary)

dim( B(a) ∩ I(b) ) = 1

dim( B(a) ∩ B(b) ) = 0

dim( B(a) ∩ E(b) ) = 1

外部 (Exterior)

dim( E(a) ∩ I(b) ) = 2

dim( E(a) ∩ B(b) ) = 1

dim( E(a) ∩ E(b) = 2

左から右に、上から下に読みます。交差行列の文字列表現は'212101212'です。

詳細情報については次をご覧下さい。

4.2.1.2. 名前付き空間関係

共通の空間関係を簡単に決定できるように、PGC SFSは名前付き空間関係述語の集合を定義しています。PostGISではST_ContainsST_CrossesST_DisjointST_EqualsST_IntersectsST_OverlapsST_TouchesST_Withinが提供されています。非標準の空間関係述語ST_CoversST_CoveredByST_ContainsProperlyも定義されています。

空間述語は通常SQLのWHERE節やJOIN節内で条件に使用されます。名前付き空間述語は、インデックスが有効なら自動的に空間インデックスを使うので、バウンディングボックス演算子&&を使う必要はありません。例えば次のようになります。

SELECT city.name, state.name, city.geom
FROM city JOIN state ON ST_Intersects(city.geom, state.geom);

詳細や図についてはPostGIS Workshopをご覧下さい。

4.2.1.3. 一般的な空間関係

名前付き空間関係が求める空間フィルタ条件を与えるのに不十分となる場合があります。

例えば、道路ネットワークを表現する線データセットを考えてみます。点でなく線で交差する全ての道路の辺を識別しなければならないことがあります (ビジネスルールの検証のためならありえます)。この場合、ST_Crossesでは、点で交差する場合しかtrueを返さないので、必要な空間フィルタになりません。

2ステップ解決法を示します。まず、空間的にインタセクトしている同路線の二本を抜き出し (ST_Intersects)、実際にインタセクトしている部分を計算 (ST_Intersection)します。次いで、インタセクトしている部分のST_GeometryTypeLINESTRING' かどうかを確認します ([MULTI]POINT[MULTI]LINESTRING等のGEOMETRYCOLLECTIONを返す場合に適切に処理します)。

明らかに、より単純でより速い解法が望ましいです。

二つ目の例では、湖の境界とインタセクトし、かつ終端が岸に上がっている波止場を見つけます。言い換えると、波止場が湖に含まれるが完全には含まれず、湖の境界線とインタセクトして、波止場の終端が確実に湖内または境界にある場合を指します。空間述語を併用すると求める地物を見つけることができます。

この要件は完全なDE-9IM交差行列の計算で満たすことができます。PostGISは、これを行うST_Relate関数を提供しています。次のようにします。

SELECT ST_Relate( 'LINESTRING (1 1, 5 5)',
                  'POLYGON ((3 3, 3 7, 7 7, 7 3, 3 3))' );
st_relate
-----------
1010F0212

特定の空間関係をテストするには、交差行列パターンを使います。これは、追加シンボル{T,*}で拡張された行列表現です。

  • T => インタセクションの次元は空ではないという意味です。すなわち{0,1,2}のいずれかです。

  • * => 何でも良い

交差行列パターンを使って、特定の空間関係の評価がより簡潔な方法で可能です。交差行列パターンのテストにST_RelateST_RelateMatchを使うことができます。上に挙げた一つ目の例では、二つのラインがライン内部でインタセクトする交差行列パターンは'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');

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

空間条件を使うクエリを構築する時、空間インデックスが存在する場合 (「空間インデックスを構築する」を参照して下さい)には、空間インデックスを使うようにすることが重要です。これを行うには、WHERE節やON節内でインデックスに対応する空間演算子や空間関数を使わなければなりません。空間演算子はバウンディングボックスを使った演算を行い (最も多く使われるのが&&です)、距離演算子は最近傍クエリを使います (最も使われるのが<->です)。インデックスに対応する関数には、ほとんどの名前付き述語 (ST_Intersects等)と、ほとんどの距離述語 (ST_DWithin等)が含まれます。

ST_Distanceのような関数は、演算最適化にインデックスを使いません。例えば、次のクエリは、大きいテーブルでは非常に遅くなります。

SELECT the_geom
FROM geom_table
WHERE ST_Distance(the_geom, 'SRID=312;POINT(100000 200000)') < 100

このクエリはgeom_tableテーブル内の、(100000, 200000)のポイントから100単位内にある全てのジオメトリを選択します。テーブル内の個々のポイントと指定したポイントとの距離を計算しているため、非常に遅くなります。すなわち、1回のST_Distance()の計算で、テーブルの全ての行について計算することになります。

インデックス対応関数であるST_DWithinを使用すると処理対象行の数を減らすことができます。

SELECT the_geom
FROM geom_table
WHERE ST_DWithin(the_geom, 'SRID=312;POINT(100000 200000)', 100)

このクエリは、同じジオメトリを選択しますが、より効率的な方法を取ります。 ST_DWithin()が内部で&&演算子をクエリジオメトリのバウンディングボックスを拡大したボックスで使うことによって可能となります。the_geom上に空間インデックスが存在するなら、クエリプランナは距離計算の前に対象行数を減らすためにインデックスを使えることを認識します。空間インデックスによって、バウンディングボックスが拡張された範囲とオーバラップするジオメトリだけを検索して、そのため、求めようとする距離内にあるかも知れないジオメトリを検索することができます。その後で、結果集合内のレコードを含めるかどうかを確認するための実際の距離計算が行われます。

4.2.3. 空間SQLの例

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

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

bc_municipalityテーブルの定義については次の通りです。

Column     | Type              | Description
-----------+-------------------+-------------------
gid        | integer           | Unique ID
code       | integer           | Unique ID
name       | character varying | City / Town Name
the_geom   | geometry          | Location Geometry (Polygon)
4.2.3.1. 道路の総延長はkm表記でいくらになるでしょう?
4.2.3.2. プリンスジョージ市の大きさはha表記でいくらになるでしょう?
4.2.3.3. 県内で最も大きな面積となる自治体はどこでしょう?
4.2.3.4. 各自治体内に含まれる道路の総延長はいくらでしょう?
4.2.3.5. プリンスジョージ市内の全ての道路からなるテーブルを作る
4.2.3.6. ビクトリア州の「ダグラス通り」の長さはkm表記でいくらになるでしょう?
4.2.3.7. 穴を持つ自治体ポリゴンのうち最も大きいのはどれでしょう?

4.2.3.1.

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

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

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

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

4.2.3.2.

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

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

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

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

4.2.3.3.

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

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

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

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

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

4.2.3.4.

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

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

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

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

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

4.2.3.5.

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

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

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

4.2.3.6.

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

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

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

4.2.3.7.

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

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

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

4.3. 性能向上に関する技法

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

4.3.1.1. 問題の説明

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

4.3.1.2. 応急処置

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

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

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

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = 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クエリを実行するかでも対応できます。

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

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

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

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

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

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

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

4.3.3. 次元変換の回避

ときどき、テーブルで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次元で書かれているジオメトリの再書き込みをスキップさせることができます。

4.4. アプリケーションのビルド

4.4.1. MapServerを使う

Minnesota MapServer は、OpenGIS Web Map Service仕様に準拠したインターネットWebマッピングサーバです。

4.4.1.1. 基本的な使い方

PostGISとMapServerとを併用するには、MapServerの設定方法を知る必要がありますが、本文書の範囲外です。本節では、PostGIS独特の問題と設定詳細について説明します。

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

  • PostGIS 0.6以上

  • MapServer 3.5以上

MapServerは、他のPostgreSQLクライアントと同じくPostGIS/PostgreSQLデータにアクセスします。アクセスにはlibpqインタフェースを使います。つまり、MapServerは、PostGISサーバにアクセスするあらゆるネットワークに繋がっている計算機にインストールすることができ、PostGISをデータソースとして利用できます。システム間の接続が速いほど良くなります。

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

  2. 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特有のディレクティブは次の通りです。

    CONNECTIONTYPE

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

    CONNECTION

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

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

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

    DATA

    このパラメータの形式は "<カラム名> from <テーブル名> using srid=<SRID> using unique <主キー>"となります。ここで、カラム名は地図に描画したい空間カラムを指し、SRIDはそのカラムで使われるSRIDで、主キーはそのテーブルの主キー (またはインデックスを伴う一意の値を持つカラム)です。

    "using srid"と"using unique"節は省略できます。MapServerは可能なら自動的に正しい値を判断しますが、地図を描画するサーバ上で余分なクエリを若干実行するコストがかかります。

    PROCESSING

    接続を閉じずに複数のレイヤで再利用する場合にCLOSE_CONNECTION=DEFERとします。速度が改善します。詳細な説明についてはMapServer PostGIS Performance Tipsを参照して下さい。

    FILTER

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

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

    CREATE INDEX [インデックス名] ON [テーブル名] USING GIST ( [ジオメトリカラム] );
  4. MapServerを使用するレイヤのクエリを実行する場合には、"using unique"節もDATAステートメントに追加しなければなりません。

    MapServerでは、クエリ実行の際には、それぞれの空間レコードを識別するための一意な識別子が必要です。MapServerのPostGISモジュールは、一意な識別子を提供するために、ユーザ指定の一意な値を使います。テーブルの主キーを使うのが最も良い方法です。

4.4.1.2. よくある質問

4.4.1.2.1. EXPRESSIONをマップファイルで使う時に、値がテーブルにあるのを確認しているのに条件がtrueになりません。
4.4.1.2.2. シェープファイルに使用している FILTER が、同じデータを持つPostGISテーブルでは動作しません。
4.4.1.2.3. PostGISレイヤは、シェープファイルレイヤよりもはるかに遅く描画しますが、これは正常ですか?
4.4.1.2.4. PostGISレイヤはちゃんと描けましたが、クエリが本当に遅いです。何が問題なのですか?
4.4.1.2.5. ジオグラフィカラム (PostGIS 1.5で機能追加)をMapServerのレイヤのソースとして使用できますか?

4.4.1.2.1.

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

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

EXPRESSION ([numlanes] >= 6)

4.4.1.2.2.

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

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

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

4.4.1.2.3.

PostGISレイヤは、シェープファイルレイヤよりもはるかに遅く描画しますが、これは正常ですか?

一般に、与えられた地図に描画する地物が多いほど、PostGISはシェープファイルより遅くなる可能性が高くなります。相対的に地物が少ない (100個台)地図では、PostGISの方が速くなることがしばしばあります。地物が少多い (1000個台)地図では、PostGISは常に遅くなります。

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

postgis# CREATE INDEX geotable_gix ON geotable USING GIST ( geocolumn );
postgis# VACUUM ANALYZE;

4.4.1.2.4.

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

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

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

DATA "geom FROM geotable USING UNIQUE gid"

4.4.1.2.5.

ジオグラフィカラム (PostGIS 1.5で機能追加)をMapServerのレイヤのソースとして使用できますか?

できます!MapServerはジオグラフィカラムをジオメトリカラムと同じに認識します。しかし、常にSRIDを4326とします。"using srid=4326"節をDATAステートメントに入れて下さい。他の部分はジオメトリの場合と同じです。

DATA "geog FROM geogtable USING SRID=4326 USING UNIQUE gid"

4.4.1.3. 踏み込んだ使用法

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"
USING UNIQUE <uniqueid>

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

[注記]

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

USING SRID=<srid>

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

4.4.1.4. 例

簡単な例から始めて、ステップアップしていきましょう。次の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を使用する方法も示しています。

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

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

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

public class JavaGIS {

public static void main(String[] args) {

  java.sql.Connection conn;

  try {
    /*
    * JDBCドライバをロードして接続を確立します。
    */
    Class.forName("org.postgresql.Driver");
    String url = "jdbc:postgresql://localhost:5432/database";
    conn = DriverManager.getConnection(url, "postgres", "");
    /*
    * ジオメトリ型を接続に追加します。
    * ご注意 : addDateType()を呼ぶ前に
    *   接続をpgsql特有の接続実装にキャストしなければなりません。
    */
    ((org.postgresql.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をご覧下さい。

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

...

4.4.3.1. テキストカーソル

...

4.4.3.2. バイナリカーソル

...

4.5. ラスタデータの管理、クエリ、アプリケーション

4.5.1. ラスタのロードと生成

raster2pgsqlラスタローダを使ってPostGISラスタを既存のラスタファイルからロードするのは、最もよく行われます。

4.5.1.1. raster2pgsqlを使ってラスタをロードする

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をご覧下さい。

使用例:

raster2pgsql raster_options_go_here raster_file someschema.sometable > out.sql

-?

ヘルプを表示します。引数を全く指定しない場合にも表示されます。

-G

サポートされているラスタ書式を印字します。

(c|a|d|p) 相互に排他的なオプションです

-c

新しいテーブルを生成し、ラスタを入れます。これがデフォルトモードです

-a

既存のテーブルにラスタを追加します。

-d

テーブルを削除し、新しいテーブルを生成し、ラスタを入れます。

-p

準備モード、テーブルを作るだけです。

ラスタ処理: ラスタカタログに適切に登録するための制約の適用

-C

SRIDやピクセルサイズ等のラスタ制約を適用して、raster_columnsビューで適切な登録ができるようにします。

-x

制約の最大範囲を無効にします。-Cフラグが使われている場合のみ適用されます。

-r

正規ブロック制約 (空間的に一意で網羅タイル)を適用します。-Cフラグが使用されている場合のみ適用されます。

ラスタ処理: 入力ラスタデータセットの操作に使われる追加的なパラメータ

-s <SRID>

出力ラスタを指定されたSRIDにします。 指定しないか0を指定した場合、ラスタのメタデータに対して、適切なSRIDを決定するためのチェックを行います。

-b BAND

ラスタから抽出するバンドのインデクス (1始まり)。1より多いバンドを抽出するには、コンマ(,)で区切ります。指定しない場合、全てのバンドが抽出されます。

-t TILE_SIZE

行毎に挿入するラスタを切断します。TILE_SIZEは、「幅x高さ」で表現しますが、"auto"を指定すると、最初のラスタを使って適切なタイルサイズが計算され、全てのラスタに適用されます。

-P

全てのタイルが同じ幅と高さを持つことを保証するために、右端、下端のタイルに詰め物を施します。

-R, --register

ファイルシステム (データベース外)ラスタとして、ラスタを登録します。

データベースには、ラスタのメタデータとラスタのファイルパスのみ格納されます (ピクセルは格納されません)。

-l OVERVIEW_FACTOR

ラスタのオーバビューを生成します。一つより多い係数を用いる場合は、コンマ (,) で区切ります。オーバビューのテーブル名はo_overview factor_tableとなります。overview factorにはオーバビュー係数が入り、tableには基底テーブル名が入ります。生成されるオーバビューはデータベースに格納され、-Rは無視されます。生成されたSQLファイルは元データのテーブルとオーバビューテーブルの両方を含むことに注意して下さい。

-N NODATA

NODATA値を持たないバンドで使用するNODATA値を設定します。

テータベースオブジェクトの操作に使われる追加的なパラメータ

-f COLUMN

出力先ラスタカラムの名前を指定します。デフォルトは'rast'です。

-F

ファイル名でカラムを追加します。

-n COLUMN

ファイル名カラムの名前を指定します。-Fを暗に含みます。

-q

PostgreSQL識別子に引用符を付けます。

-I

ラスタカラムにGiSTインデクスを生成します。

-M

ラスタテーブルにvacuum analyzeを行います。

-k

バンドごとのNODATA値のチェックを省略します。

-T tablespace

生成されるテーブルのテーブルスペースを指定します。-Xフラグを併用しない場合には、インデクス (主キーを含む)はデフォルトのテーブルスペースを使用することにご注意ください。

-X tablespace

テーブルの新しいインデクスに使うテーブル空間を指定します。主キーに適用され、-Iフラグがある場合においては空間インデクスにも適用されます。

-Y

INSERTステートメントでなくCOPYステートメントを使います。

-e

ステートメント毎に実行して、トランザクションを使用しないようにします。

-E ENDIAN

生成されるラスタのバイナリ出力のエンディアンを制御します。XDR (訳注: ビッグエンディアン)の場合は0を、NDR (訳注:リトルエンディアン)の場合は1を、それぞれ指定します。デフォルトは1です。現時点ではNDR出力のみサポートします。

-V version

出力書式の版を指定します。デフォルトは0です。現時点では0のみサポートします。

ローダを用いて入力ファイルを100x100のタイルで生成して、データベースにアップロードする例は、次の通りです。

[注記]

public.demelevationでなくdemelevation というようにスキーマ名を外すことができます。この場合、ラスタテーブルはデータベースまたユーザの指定するデフォルトのスキーマに生成されます。

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

4.5.1.2. PostGISラスタ関数を用いたラスタの生成

データベース内でラスタやラスタテーブルを生成したい場合が多くあります。これを行うための関数が多数あります。一般的な手順は次の通りです。

  1. 新しいラスタ行を保持するためのラスタカラムを持つテーブルを生成します。次を実行します。

    CREATE TABLE myrasters(rid serial primary key, rast raster);
  2. この目標で助けとなる関数は多数あります。他のラスタの派生でないラスタを生成する場合、ST_MakeEmptyRasterST_AddBandを順次実行して作業を開始します。

    ジオメトリからラスタを生成することもできます。ST_AsRasterを使います。ST_UnionST_MapAlgebraFctや、地図解析関数群等といった、他の関数を組み合わせる場合もあります。

    既存テーブルから新しいラスタテーブルを生成するための多数の選択肢があります。たとえば、ST_Transformを使って、既存テーブルから異なる投影法のラスタテーブルを生成します。

  3. はじめにテーブルにデータを入れたら、ラスタカラムに空間インデクスを生成したくなるでしょう。次のようにします。

    CREATE INDEX myrasters_rast_st_convexhull_idx ON myrasters USING gist( ST_ConvexHull(rast) );

    ST_ConvexHullを使用していることに注意して下さい。多くのラスタ演算子はラスタの凸包を元にしています。

    [注記]

    2.0より前の PostGIS ラスタは、エンベロープを基本にして、凸包ではありませんでした。空間インデクスを適切に働かせるには、エンベロープを基本にしたインデクスを削除して、凸包を元にしたインデクスに置き換えます。

  4. AddRasterConstraintsを用いてラスタ制約を適用します。

4.5.2. ラスタカタログ

PostGISが生成する、二つのラスタカタログのビューがあります。両方ともラスタテーブルの制約の中に埋め込まれる情報を用いています。結果として、カタログビューは、テーブル内のラスタデータに制約が働くため、常にラスタデータとの矛盾がありません。

  1. raster_columns ラスタタイプのデータベースにおける全てのラスタテーブルカラムのカタログです。

  2. raster_overviews データベース内の、より詳細なテーブルのためのオーバビューを提供するラスタテーブルのカラム全てのカタログです。この種のテーブルは、ロード時に-lを指定した時に生成されます。

4.5.2.1. ラスタカラムカタログ

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 ラスタの空間参照系識別番号です。「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 空間インデクスを持っているかどうかを示す真偽値です。

4.5.2.2. ラスタオーバビュー

raster_overviewsは、オーバビューで使われるラスタテーブルカラムに関する情報のカタログで、オーバビューを用いる際に知っておくと便利な情報も持ちます。オーバビューテーブルはraster_columnsraster_overviewsの両方のカタログに入れられます。オーバビューもラスタの一つであるのは確かですが、より高い解像度テーブルの解像度を落としたカリカチュアになるという特殊な目的を満たすためでもあるからです。ラスタをロードする際に-lスイッチを使うと、オーバビューが主ラスタテーブルと一緒に生成されます。もしくは、AddOverviewConstraintsを使うと手動で生成できます。

オーバビューテーブルには、他のラスタテーブルと同じ制約と、オーバビュー特有の制約となる追加情報があります。

[注記]

raster_overviewsの情報はraster_columnsとは重複しません。raster_columnsにあるオーバビューテーブルに関する情報が必要な場合は、raster_overviewsraster_columnsとを結合すると、必要な情報の集合を完全に取得することができます。

オーバビューの主たる理由は次の二つです。

  1. ズームアウトした際の地図表示を早くするために、元のテーブルの低解像度表現が一般的に使われます。

  2. レコード数が少なく、ピクセル毎の適用範囲が広いため、高解像度の元テーブルより計算が一般的に早くなります。計算は高解像度テーブルより精度は落ちますが、大まかな計算には十分でありえます。

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)ピクセル分)が低い解像度になっている点に注意して下さい。

4.5.3. PostGISラスタを使ったカスタムアプリケーションの構築

PostGISラスタには、対応イメージ書式のラスタをレンダリングするSQL関数があり、レンダリングを行うための多数の選択肢があります。たとえば、Rendering PostGIS Raster graphics with LibreOffice Base Reportsで例を挙げている通り、OpenOffice/LibreOfficeを使うことができます。さらに、ここで示すように、幅広い言語で使うことができます。

4.5.3.1. ST_AsPNG を他の関数とあわせて使った PHP 出力例

本節では、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]);
?>

4.5.3.2. ST_AsPNGを他の関数とあわせて使ったASP.NET C#出力例

本節では、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#で実装している点を除いては「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;
        }
}

4.5.3.3. rasterクエリを画像ファイルで出力するJavaコンソールアプリケーション

これは、一つの画像を返すクエリを取り、指定したファイルに出力する、簡単な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);
      }
  }
}

4.5.3.4. PLPython を使って SQL を介して画像をダンプする

これは、サーバディレクトリ内でレコードごとにファイルを生成する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

4.5.3.5. PSQLでラスタを出力する

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

4.6. トポロジ

PostGISトポロジ型と関数は、フェイス、エッジ、ノード等のトロポジオブジェクトを管理するために使います。

PostGIS Day Paris 2011におけるSandro Santilliさんの講演が、PostGISトポロジの概略説明として良いです。Topology with PostGIS 2.0 slide deckにあります。

Vincent Picavetさんはトポロジとは何か、どのように使われるか、および、対応するFOSS4Gツールに関する良い概略説明をPostGIS Topology PGConf EU 2012で出しています。

トポロジベースのGISデータベースの例としてUS Census Topologically Integrated Geographic Encoding and Referencing System (TIGER)があります。PostGISトポロジの試験がしたくて、何らかのデータが必要ならTopology_Load_Tigerをご覧下さい

PostGISトポロジモジュールは前の版にもありましたが、正式なPostGIS文書の中には入れていませんでした。PostGIS 2.0.0 では、全ての非推奨関数を無くし、知られていた使いやすさの問題を解決し、機能と関数の文書をより良くし、新しい関数を追加し、SQL-MM標準により準拠させるために、大整理を行っています。

このプロジェクトの詳細情報はPostGIS Topology Wikiにあります。

このモジュールに関する全ての関数とテーブルは、topologyスキーマにインストールされます。

SQL/MM標準で定義される関数はST_プリフィクスを持ち、PostGIS特有の関数はこのプリフィクスを持ちません。

PostGIS 2.0以降では、トポロジ機能はデフォルトでビルドされます。2章PostGISインストールで説明されている通り、ビルド時のコンフィギュアオプション --without-topology を指定することで、無効にできます。

4.6.1. トポロジ型

概要

本節では、PostGISトポロジでインストールされるPostgreSQLデータ型の一覧を挙げます。独自に関数をデザインする際に特に重要となる、キャストでの挙動を記述していることにご注意ください。

getfaceedges_returntype — 順列番号とエッジ番号の複合型です。ST_GetFaceEdgesが返す型です。
TopoGeometry — トポロジとして定義されたジオメトリを表現する型です。
validatetopology_returntype — エラーメッセージとエラーの場所を示すid1とid2からなる複合型です。これはValidateTopologyが返す型です。

名前

getfaceedges_returntype — 順列番号とエッジ番号の複合型です。ST_GetFaceEdgesが返す型です。

説明

順列番号とエッジ番号の複合型ですST_GetFaceEdges関数が返す型です。

  1. sequence (整数): トポロジスキーマとSRIDを定義するtopology.topologyテーブルで定義されるトポロジへの参照です。

  2. edge (整数): エッジの識別番号です。


名前

TopoGeometry — トポロジとして定義されたジオメトリを表現する型です。

説明

特定のトポロジレイヤ内のトポロジジオメトリを参照する複合型で、特定のタイプと特定のIDを持ちます。TopoGeometryの要素はtopology_id, layer_id, id integer, type integerの各属性です。

  1. topology_id (整数): トポロジスキーマとSRIDを定義するtopology.topologyテーブルで定義されているトポロジへの参照です。

  2. layer_id (整数): TopoGeometryが属するlayersテーブルにおけるlayer_idです。topology_idとlayer_idとの組み合わせで、topology.layersテーブルを一意に参照できます。

  3. id (整数): それぞれのトポロジでTopoGeometryを一意にするための順序整数で、自動生成されます。

  4. type (1から4の整数でジオメトリタイプを定義): 1:[multi]point, 2:[multi]line, 3:[multi]poly, 4:collectionとなります。

キャストの挙動

本節では、このデータ型で許容される明示的なキャストと自動キャストの一覧を挙げます。

キャスト先挙動
geometry自動

関連情報

CreateTopoGeom


名前

validatetopology_returntype — エラーメッセージとエラーの場所を示すid1とid2からなる複合型です。これはValidateTopologyが返す型です。

説明

エラーメッセージと二つの整数からなる複合型です。ValidateTopology関数は、これの集合を返します。評価エラーを示し、id1とid2でエラーを含むトポロジオブジェクトの識別番号を示します。

  1. error (varchar): エラーのタイプを示します。

    現在のエラー記述: coincident nodes (訳注: ノード重複), edge crosses node (訳注: エッジとノードのクロス), edge not simple (訳注: 単純でないエッジ), edge end node geometry mis-match (訳注: 終了ノードジオメトリの不整合), edge start node geometry mismatch (訳注: 開始ノードジオメトリの不整合), face overlaps face (訳注: フェイス同士のオーバラップ), face within face (訳注: フェイス間の包含)

  2. id1 (整数): エラーを持つエッジ/フェイス/ノードの識別番号を示します。

  3. id2 (整数): 2オブジェクトでのエラーにおける二つ目のエッジ/ノードの識別番号を示します。

関連情報

ValidateTopology

4.6.2. トポロジドメイン

概要

本節では、PostGISトポロジでインストールされるPostgreSQLドメインの一覧を挙げます。ドメインは、オブジェクト型のように扱え、関数やテーブルカラムのオブジェクトを返します。ドメインは存在するチェック制約を持つ既存の型である点で、型とは違います。

TopoElement — 二つの整数の配列で、通常TopoGeometry要素を識別するために使われます。
TopoElementArray — TopoElementオブジェクトの配列

名前

TopoElement — 二つの整数の配列で、通常TopoGeometry要素を識別するために使われます。

説明

二つの整数の配列で、単純または階層を持つTopoGeometryの一つのコンポーネントを表現するために使われます。

単純なTopoGeometryの場合は、配列の最初の要素がトポロジのプリミティブの識別を表現し、二つ目の要素がタイプ (1:ノード 2:エッジ, 3:フェイス)を表現します。階層的なTopoGeometryの場合は、一つ目の要素が子のTopoGeometryの識別子を表現し、二つ目の要素はレイヤ識別子を表現します。

[注記]

階層的なTopoGeometryについては、全ての子のTopoGeometry要素は同じ子レイヤから来ます。子レイヤは、定義されたTopoGeometryのレイヤのtopology.layerレコード内で指定されます。

SELECT te[1] AS id, te[2] AS type FROM
( SELECT ARRAY[1,2]::topology.topoelement AS te ) f;
 id | type
----+------
  1 |    2
                 
SELECT ARRAY[1,2]::topology.topoelement;
  te
-------
 {1,2}
                 
-- 3要素配列をtopoelementに使った際に発生するエラーの例
-- ご注意: topoelementは、必ず2要素を持ちます。次元チェックにひっかかります。
SELECT ARRAY[1,2,3]::topology.topoelement;
ERROR:  value for domain topology.topoelement violates check constraint "dimensions"
                 

名前

TopoElementArray — TopoElementオブジェクトの配列

説明

1以上のTopoElementオブジェクトの配列で、通常はTopoGeometryオブジェクトのコンポーネントを分配するために使われます。

SELECT '{{1,2},{4,3}}'::topology.topoelementarray As tea;
  tea
-------
{{1,2},{4,3}}

-- より長く書いた等価なもの --
SELECT ARRAY[ARRAY[1,2], ARRAY[4,3]]::topology.topoelementarray As tea;

  tea
-------
{{1,2},{4,3}}

-- トポロジに同梱されている配列集約関数 --
SELECT topology.TopoElementArray_Agg(ARRAY[e,t]) As tea
  FROM generate_series(1,4) As e CROSS JOIN generate_series(1,3) As t;
  tea
--------------------------------------------------------------------------
{{1,1},{1,2},{1,3},{2,1},{2,2},{2,3},{3,1},{3,2},{3,3},{4,1},{4,2},{4,3}}
                 
SELECT '{{1,2,4},{3,4,5}}'::topology.topoelementarray As tea;
ERROR:  value for domain topology.topoelementarray violates check constraint "dimensions"
                 

4.6.3. トポロジ管理とTopoGeometry管理

概要

本節では、新しいトポロジスキーマの構築、トポロジの評価、TopoGeometryカラムの管理のためのトポロジ関数の一覧を挙げます。

AddTopoGeometryColumn — 既存のテーブルにTopoGeometryカラムを追加し、topology.layer内に新しいレイヤとして新しいカラムを登録して、新しい layer_id を返します。
DropTopology — 使用上の注意: この関数によって、トポロジスキーマが削除され、topology.topologyテーブルからの参照が削除され、geometry_columnsテーブルから削除対象スキーマ内のテーブルへの参照が削除されます。
DropTopoGeometryColumnschema_nameで指定されたスキーマ内にあるtable_nameで指定されたテーブルからTopoGeometryカラムを削除し、topology.layerテーブルにある登録を解除します。
Populate_Topology_Layer — テーブルからメタデータを読み、topology.layerテーブルに不足しているものを追加します。
TopologySummary — トポロジ名を取り、トポロジ内のオブジェクトの型に関する概要の全体を提供します。
ValidateTopology — トポロジの問題についての詳細を示すvalidatetopology_returntypeの集合を返します。

名前

AddTopoGeometryColumn — 既存のテーブルにTopoGeometryカラムを追加し、topology.layer内に新しいレイヤとして新しいカラムを登録して、新しい layer_id を返します。

概要

integer AddTopoGeometryColumn(varchar topology_name, varchar schema_name, varchar table_name, varchar column_name, varchar feature_type);

integer AddTopoGeometryColumn(varchar topology_name, varchar schema_name, varchar table_name, varchar column_name, varchar feature_type, integer child_layer);

説明

それぞれのTopoGeometryオブジェクトは、特定のトポロジの特定のレイヤに属します。TopoGeometryオブジェクト生成の前に、トポロジレイヤの生成が必要です。トポロジレイヤは地物テーブルとトポロジとで組織されます。また、タイプと階層の情報を持ちます。レイヤの生成にはAddTopoGeometryColumn()を使います。

この関数は、リクエストされたカラムをテーブルに追加し、topology.layerテーブルに、与えられた全ての情報のレコードを追加します。

[child_layer]を指定しない (またはNULLを指定する)場合、このレイヤは、基本的なTopoGeometry (プリミティブなトポロジ要素で構成)を含みます。指定する場合、このレイヤは階層的なTopoGeometry (child_layerからのTopoGeometryで構成)を持ちます。

レイヤが生成される (これの識別番号は、AddTopoGeometryColumn関数が返します)と、TopoGeometryオブジェクトをこの中に構築する準備ができます。

妥当なfeature_typeは、POINT, LINE, POLYGON, COLLECTIONです。

Availability: 1.?

-- この例では、topology_nameとshecma_nameが異なる場合には、
-- 異なるスキーマに作ることができましたが、
-- ma_topoスキーマに新しいテーブルを作ったことに注意して下さい。

CREATE SCHEMA ma;
CREATE TABLE ma.parcels(gid serial, parcel_id varchar(20) PRIMARY KEY, address text);
SELECT topology.AddTopoGeometryColumn('ma_topo', 'ma', 'parcels', 'topo', 'POLYGON');
CREATE SCHEMA ri;
CREATE TABLE ri.roads(gid serial PRIMARY KEY, road_name text);
SELECT topology.AddTopoGeometryColumn('ri_topo', 'ri', 'roads', 'topo', 'LINE');

名前

DropTopology — 使用上の注意: この関数によって、トポロジスキーマが削除され、topology.topologyテーブルからの参照が削除され、geometry_columnsテーブルから削除対象スキーマ内のテーブルへの参照が削除されます。

概要

integer DropTopology(varchar topology_schema_name);

説明

トポロジスキーマを削除し、topology.topologyテーブルからの参照を削除し、geometry_columnsテーブルから削除対象スキーマ内のテーブルへの参照を削除します。この関数は *十分に注意してご使用下さい*。残しておきたかったデータが破壊される可能性があります。スキーマが存在しない場合、スキーマへの参照に関するエントリの削除だけを行います。

Availability: 1.?

ma_topoスキーマをカスケード削除し、topology.topologyにある参照のうち関係するものを全て削除します。

SELECT topology.DropTopology('ma_topo');

名前

DropTopoGeometryColumn — schema_nameで指定されたスキーマ内にあるtable_nameで指定されたテーブルからTopoGeometryカラムを削除し、topology.layerテーブルにある登録を解除します。

概要

text DropTopoGeometryColumn(varchar schema_name, varchar table_name, varchar column_name);

説明

schema_nameで指定されたスキーマ内にあるtable_nameで指定されたテーブルからTopoGeometryカラムを削除し、topology.layerテーブルにある登録を解除します。削除の概要報告を返します。ご注意: この関数は、参照整合性チェックをすり抜けるために、まずNULL値に上書きしてから削除します。

Availability: 1.?

SELECT topology.DropTopoGeometryColumn('ma_topo', 'parcel_topo', 'topo');

名前

Populate_Topology_Layer — テーブルからメタデータを読み、topology.layerテーブルに不足しているものを追加します。

概要

setof record Populate_Topology_Layer();

説明

テーブルの制約を読み、topology.layerテーブルに不足しているものを追加します。トポロジデータをスキーマに格納した後に、トポロジカタログで抜けているものを訂正するのに使います。

生成されたもののリストを返します。返されるカラムは schema_name, table_name, feature_columnです。

Availability: 2.3.0

SELECT CreateTopology('strk_topo');
CREATE SCHEMA strk;
CREATE TABLE strk.parcels(gid serial, parcel_id varchar(20) PRIMARY KEY, address text);
SELECT topology.AddTopoGeometryColumn('strk_topo', 'strk', 'parcels', 'topo', 'POLYGON');
-- この地物はすでに登録されているので返されるレコードはありません
SELECT *
  FROM topology.Populate_Topology_Layer();

-- 再構築してみます
TRUNCATE TABLE topology.layer;

SELECT *
  FROM topology.Populate_Topology_Layer();

SELECT topology_id,layer_id, schema_name As sn, table_name As tn, feature_column As fc
FROM topology.layer;

                                
schema_name | table_name | feature_column
-------------+------------+----------------
 strk        | parcels    | topo
(1 row)

 topology_id | layer_id |  sn  |   tn    |  fc
-------------+----------+------+---------+------
           2 |        2 | strk | parcels | topo
(1 row)

名前

TopologySummary — トポロジ名を取り、トポロジ内のオブジェクトの型に関する概要の全体を提供します。

概要

text TopologySummary(varchar topology_schema_name);

説明

トポロジ名を取り、トポロジ内のオブジェクトの型に関する概要の全体を提供します。

Availability: 2.0.0

SELECT topology.topologysummary('city_data');
                    topologysummary
--------------------------------------------------------
 Topology city_data (329), SRID 4326, precision: 0
 22 nodes, 24 edges, 10 faces, 29 topogeoms in 5 layers
 Layer 1, type Polygonal (3), 9 topogeoms
  Deploy: features.land_parcels.feature
 Layer 2, type Puntal (1), 8 topogeoms
  Deploy: features.traffic_signs.feature
 Layer 3, type Lineal (2), 8 topogeoms
  Deploy: features.city_streets.feature
 Layer 4, type Polygonal (3), 3 topogeoms
  Hierarchy level 1, child layer 1
  Deploy: features.big_parcels.feature
 Layer 5, type Puntal (1), 1 topogeoms
  Hierarchy level 1, child layer 2
  Deploy: features.big_signs.feature

名前

ValidateTopology — トポロジの問題についての詳細を示すvalidatetopology_returntypeの集合を返します。

概要

setof validatetopology_returntype ValidateTopology(varchar topology_schema_name);

説明

トポロジの問題についての詳細を示すvalidatetopology_returntypeの集合を返します。ありえるエラーと返されたIDが表現するものの一覧は次のとおりです。

Errorid1id2
edge crosses node (訳注: エッジとノードのクロス)edge_idnode_id
invalid edge (訳注: 不正なエッジ)edge_idnull
edge not simple (訳注: 単純でないエッジ)edge_idnull
edge crosses edge (訳注: エッジとエッジのクロス)edge_idedge_id
edge start node geometry mis-match (訳注: 開始ノードジオメトリの不整合)edge_idnode_id
edge end node geometry mis-match (訳注: 終了ノードジオメトリの不整合)edge_idnode_id
face without edges (訳注: エッジのないフェイス)face_idnull
face has no rings (訳注: 環のないフェイス)face_idnull
face overlaps face (訳注: フェイス同士のオーバラップ)face_idface_id
face within face (訳注: フェイス間の包含) 内側のface_id外側のface_id

Availability: 1.0.0

Enhanced: 2.0.0では、より効果的なエッジ交差検出が可能になり、以前の版で残っていた偽陽性を解決しています。

Changed: 2.2.0 エラーの記述と矛盾しないように'edge crosses node'のid1とid2の値が入れ替わっています。

SELECT * FROM  topology.ValidateTopology('ma_topo');
      error        | id1 | id2
-------------------+-----+-----
face without edges |   0 |
                                

4.6.4. トポロジ統計管理

概要

本節では、トポロジ構築時のデータベース統計の管理について説明します。

トポロジに要素を追加すると、そのトリガとして、分割されることになる既存のエッジを探索し、ノードを追加し、新しいラインでノードを作成するエッジを更新するために多数のデータベースクエリが発生します。このため、トポロジテーブル内のデータに関する統計情報が最新の状態になっているなら、統計情報を使うと便利です。

PostGISトポロジーの追加や編集の関数は、自動的に統計情報を更新することはありません。トポロジにおいて逐次変更していては、統計情報の更新が過剰になるためです。処理は呼び出し元の義務となっています。

[注記]

自動VACUUMによる統計情報更新では、自動VACUUM完了前に開始されたトランザクションからは*見えません*。長時間実行されるトランザクションが更新された統計情報を使うには、自身に対してANALYZEを実行する必要があります。

4.6.5. トポロジコンストラクタ

概要

本節では、新しいトポロジを生成するトポロジ関数を挙げます。

CreateTopology — 新しいトポロジスキーマを生成し、新しいスキーマをtopology.topologyテーブルに登録します。
CopyTopology — トポロジ構造 (ノード、エッジ、フェイス、レイヤ、TopoGeometry)を複写します。
ST_InitTopoGeo — 新しいトポロジスキーマを生成し、topology.topologyテーブルに新しいスキーマを登録し、処理の概要を表示します。
ST_CreateTopoGeo — 空のトポロジにジオメトリのコレクションを追加し、成否を示すメッセージを返します。
TopoGeo_AddPoint — 許容差を使って既存のトポロジにポイントを追加し、可能ならエッジを分割します。
TopoGeo_AddLineString — 許容差を使って既存のトポロジにラインストリングを追加し、可能ならエッジ/フェイスを分割します。エッジ識別番号を返します。
TopoGeo_AddPolygon — 許容差を使って既存のトポロジにラインストリングを追加し、可能ならエッジ/フェイスを分割します。エッジ識別番号を返します。

名前

CreateTopology — 新しいトポロジスキーマを生成し、新しいスキーマをtopology.topologyテーブルに登録します。

概要

integer CreateTopology(varchar topology_schema_name);

integer CreateTopology(varchar topology_schema_name, integer srid);

integer CreateTopology(varchar topology_schema_name, integer srid, double precision prec);

integer CreateTopology(varchar topology_schema_name, integer srid, double precision prec, boolean hasz);

説明

topology_nameで指定したスキーマを生成し、テーブル (edge_data, face, node, relation)を生成し、topology.topologyテーブルに新しいトポロジを登録します。トポロジテーブルにおけるトポロジのIDを返します。sridは、spatial_ref_sysテーブルで定義されている空間参照系識別番号です。トポロジの名称は一意でなければなりません。許容差は、空間参照系で規定される単位です。precで許容差を指定しない場合は 0 とされます。

SQL/MMのST_InitTopoGeoに似ていますが、少しだけこちらの方が機能追加されています。haszは、指定されていない場合はfalseとされます。

Availability: 1.?

本例ではメートル単位マサチューセッツ州平面のエッジ、フェイスとリレーションを保存するための、ma_topoという新しいスキーマを生成します。空間参照系はメートルを単位としているので、許容差は0.5メートルとなります。

SELECT topology.CreateTopology('ma_topo',26986, 0.5);

ロードアイランド州トポロジをフィート単位州平面で生成

SELECT topology.CreateTopology('ri_topo',3438) As topoid;
topoid
------
2

名前

CopyTopology — トポロジ構造 (ノード、エッジ、フェイス、レイヤ、TopoGeometry)を複写します。

概要

integer CopyTopology(varchar existing_topology_name, varchar new_name);

説明

new_topology_nameで指定した名前のトポロジを生成し、existing_topology_nameから取得されるSRIDと精度にして、ノード、エッジ、フェイス、レイヤ、TopoGeometryを複製します。

[注記]

topology.layerの新しい行には、schema_name, table_name, feature_columnの統合された値が入ります。TopoGeometryが定義には存在しても、どのユーザレベルのテーブルにも存在しないためです。

Availability: 2.0.0

本例では、ma_topoという名前のトポロジにバックアップをとっています。

SELECT topology.CopyTopology('ma_topo', 'ma_topo_bakup');

名前

ST_InitTopoGeo — 新しいトポロジスキーマを生成し、topology.topologyテーブルに新しいスキーマを登録し、処理の概要を表示します。

概要

text ST_InitTopoGeo(varchar topology_schema_name);

説明

これはCreateTopologyのSQL-MM互換ですが、CreateTopologyにある空間参照系とtoleranceオプションがありません。また、トポロジIDを返すのではなく、生成に関する記述を出力します。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.17

SELECT topology.ST_InitTopoGeo('topo_schema_to_create') AS topocreation;
                      astopocreation
------------------------------------------------------------
 Topology-Geometry 'topo_schema_to_create' (id:7) created.
                                

関連情報

CreateTopology


名前

ST_CreateTopoGeo — 空のトポロジにジオメトリのコレクションを追加し、成否を示すメッセージを返します。

概要

text ST_CreateTopoGeo(varchar atopology, geometry acollection);

説明

空のトポロジにジオメトリのコレクションを追加し、成否を示すメッセージを返します。

空トポロジの追加に使えます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.18

-- トポロジの投入 --
SELECT topology.ST_CreateTopoGeo('ri_topo',
 ST_GeomFromText('MULTILINESTRING((384744 236928,384750 236923,384769 236911,384799 236895,384811 236890,384833 236884,
  384844 236882,384866 236881,384879 236883,384954 236898,385087 236932,385117 236938,
  385167 236938,385203 236941,385224 236946,385233 236950,385241 236956,385254 236971,
  385260 236979,385268 236999,385273 237018,385273 237037,385271 237047,385267 237057,
  385225 237125,385210 237144,385192 237161,385167 237192,385162 237202,385159 237214,
  385159 237227,385162 237241,385166 237256,385196 237324,385209 237345,385234 237375,
  385237 237383,385238 237399,385236 237407,385227 237419,385213 237430,385193 237439,
  385174 237451,385170 237455,385169 237460,385171 237475,385181 237503,385190 237521,
  385200 237533,385206 237538,385213 237541,385221 237542,385235 237540,385242 237541,
  385249 237544,385260 237555,385270 237570,385289 237584,385292 237589,385291 237596,385284 237630))',3438)
  );

      st_createtopogeo
----------------------------
 Topology ri_topo populated


-- テーブルとTopoGeometryの生成--
CREATE TABLE ri.roads(gid serial PRIMARY KEY, road_name text);

SELECT topology.AddTopoGeometryColumn('ri_topo', 'ri', 'roads', 'topo', 'LINE');
                                

名前

TopoGeo_AddPoint — 許容差を使って既存のトポロジにポイントを追加し、可能ならエッジを分割します。

概要

integer TopoGeo_AddPoint(varchar atopology, geometry apoint, float8 tolerance);

説明

既存のトポロジにポイントを追加し、その識別番号を返します。指定されたポイントは、許容差の範囲内で既存のノードまたはエッジにスナップします。既存のエッジはスナップされたポイントで分割されることがあります。

Availability: 2.0.0


名前

TopoGeo_AddLineString — 許容差を使って既存のトポロジにラインストリングを追加し、可能ならエッジ/フェイスを分割します。エッジ識別番号を返します。

概要

SETOF integer TopoGeo_AddLineString(varchar atopology, geometry aline, float8 tolerance);

説明

既存のトポロジにラインストリングを追加し、これを構成するエッジの識別番号の集合を返します。指定されたラインは、許容差の範囲内で既存のノードまたはエッジにスナップします。既存のエッジとフェイスはラインで分割されることがあります。

[注記]

この関数を介してロードされたトポロジの統計情報の更新は呼び出し元次第です。maintaining statistics during topology editing and populationをご覧下さい。

Availability: 2.0.0


名前

TopoGeo_AddPolygon — 許容差を使って既存のトポロジにラインストリングを追加し、可能ならエッジ/フェイスを分割します。エッジ識別番号を返します。

概要

SETOF integer TopoGeo_AddPolygon(varchar atopology, geometry apoly, float8 tolerance);

説明

既存のトポロジにポリゴンを追加し、これを構成するフェイスの識別番号の集合を返します。指定されたポリゴンの境界線は、許容差の範囲内で既存のノードまたはエッジにスナップします。既存のエッジとフェイスはポリゴンの境界線で分割されることがあります。

[注記]

この関数を介してロードされたトポロジの統計情報の更新は呼び出し元次第です。maintaining statistics during topology editing and populationをご覧下さい。

Availability: 2.0.0

4.6.6. トポロジエディタ

概要

本節では、エッジ、フェイス、ノードの追加、移動、削除、分割に関する関数を挙げます。本節の関数はすべてISO SQL/MMで定義されています。

ST_AddIsoNode — フェイスに孤立ノードを追加し、新しいノードの識別番号を返します。フェイスがNULLの場合でもノードは生成されます。
ST_AddIsoEdgeanodeanothernodeで指定される二つの既存孤立ノードを接続するトポロジに、ジオメトリalinestringで定義される孤立エッジを追加し、新しいエッジの識別番号を返します。
ST_AddEdgeNewFaces — 新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを削除して、分割した二つのフェイスに置き換えます。
ST_AddEdgeModFace — 新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを編集し、一つのフェイスを追加します。
ST_RemEdgeNewFace — エッジを削除し、消去対象エッジでフェイスが二つに分割されているなら元の二つのフェイスを削除し、一つの新しいフェイスに置き換えます。
ST_RemEdgeModFace — エッジを削除し、削除対象エッジでフェイスが二つに分割されているなら、両方の空間をとるため、一つを削除して、もう一つを編集します。
ST_ChangeEdgeGeom — トポロジ構造に影響を与えることなくエッジの形状を変更します。
ST_ModEdgeSplit — 既存のエッジに沿って新しいノードを生成してエッジを分割します。もとのエッジは変更され、新しいエッジが一つ追加されます。
ST_ModEdgeHeal — 二つのエッジについて、接続しているノードを削除して修復します。1番目のエッジを編集して、2番目のエッジを削除します。削除されたノードの識別番号を返します。
ST_NewEdgeHeal — 二つのエッジについて、接続しているノードを削除して修復します。両方のエッジを削除し、1番目のエッジと同じ方向のエッジに置き換えます。
ST_MoveIsoNode — トポロジ内の孤立ノードを別の位置に移動させます。新しいapointジオメトリがノードとして存在しているなら、エラーが投げられます。移動に関する説明を返します。
ST_NewEdgesSplit — 新しいノードを既存のエッジに沿って作成して、エッジを分割します。もとのエッジは削除され、二つのエッジに置き換えられます。二つの新しいエッジに接続する新しいノードの識別番号を返します。
ST_RemoveIsoNode — 孤立ノードを削除し、実行結果が返されます。ノードが孤立していない (エッジの始端または終端である)場合には、例外が投げられます。
ST_RemoveIsoEdge — 孤立エッジを削除し、実行結果の記述を返します。エッジが孤立していない場合には、例外が投げられます。

名前

ST_AddIsoNode — フェイスに孤立ノードを追加し、新しいノードの識別番号を返します。フェイスがNULLの場合でもノードは生成されます。

概要

integer ST_AddIsoNode(varchar atopology, integer aface, geometry apoint);

説明

atopologyで指定されたトポロジのafaceの識別番号で示された既存のフェイスに対して、apointで示された位置に孤立ノードを追加します。

ポイントジオメトリの空間参照系 (SRID)がトポロジと同じでない場合、apointがポイントジオメトリでない場合、ポイントがNULLである場合、または、ポイントが既存のエッジ (境界も含む)とインタセクトする場合には、例外が投げられます。また、ポイントが既にノードとして存在する場合、例外が投げられます。

afaceがNULLでなく、かつapointがフェイス内に無い場合には、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X 3.1


名前

ST_AddIsoEdge — anodeanothernodeで指定される二つの既存孤立ノードを接続するトポロジに、ジオメトリalinestringで定義される孤立エッジを追加し、新しいエッジの識別番号を返します。

概要

integer ST_AddIsoEdge(varchar atopology, integer anode, integer anothernode, geometry alinestring);

説明

anodeanothernodeで指定される二つの既存孤立ノードを接続するトポロジに、ジオメトリalinestringで定義される孤立エッジを追加し、新しいエッジの識別番号を返します。

alinestringジオメトリとトポロジとで空間参照系 (SRID)が異なる場合、引数がNULLである場合、ノードが一つ以上のフェイスに含まれている場合には、二つのノードが既存エッジの始端または終端である場合には、例外が投げられます。

alinestringanodeanothernodeに属するフェイス内に無い場合には、例外が投げられます。

anodeanothernodeが、alinestringの始端と終端でない場合には、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.4


名前

ST_AddEdgeNewFaces — 新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを削除して、分割した二つのフェイスに置き換えます。

概要

integer ST_AddEdgeNewFaces(varchar atopology, integer anode, integer anothernode, geometry acurve);

説明

新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを削除して、分割した二つのフェイスに置き換えます。新しいエッジの識別番号を返します。

この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

引数がNULLの場合、与えられたノードが不明な場合(トポロジスキーマのnodeテーブル内に既に存在していなければなりません)、acurveLINESTRINGでない場合、anodeanothernodeが始端、終端でない場合には、例外が投げられます。

acurveジオメトリの空間参照系 (SRID) がトポロジと同じでない場合、例外が投げられます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.12


名前

ST_AddEdgeModFace — 新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを編集し、一つのフェイスを追加します。

概要

integer ST_AddEdgeModFace(varchar atopology, integer anode, integer anothernode, geometry acurve);

説明

新しいエッジを追加します。新しいエッジがフェイスを分割する場合には、もとのフェイスを編集し、一つのフェイスを追加します。

[注記]

可能なら、新しいフェイスは新しいエッジの左側に作られます。左側のフェイスがユニバースフェイス (境界がない)でなければならない場合には、可能ではありません。

新しく追加されたエッジの識別番号を返します。

この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

引数がNULLの場合、与えられたノードが不明な場合(トポロジスキーマのnodeテーブル内に既に存在していなければなりません)、acurveLINESTRINGでない場合、anodeanothernodeが始端、終端でない場合には、例外が投げられます。

acurveジオメトリの空間参照系 (SRID) がトポロジと同じでない場合、例外が投げられます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.13


名前

ST_RemEdgeNewFace — エッジを削除し、消去対象エッジでフェイスが二つに分割されているなら元の二つのフェイスを削除し、一つの新しいフェイスに置き換えます。

概要

integer ST_RemEdgeNewFace(varchar atopology, integer anedge);

説明

エッジを削除し、消去対象エッジでフェイスが二つに分割されているなら元の二つのフェイスを削除し、一つの新しいフェイスに置き換えます。

新しく作成されたフェイスの識別番号を返します。新しいフェイスが生成されない場合にはNULLを返します。削除対象エッジがダングルである (訳注: 「ぶらさがる」状態、すなわち一方の端が孤立ノードでなく、かつもう一方が孤立ノード)場合か、孤立している場合か、 ユニバースフェイスとの境界になっている (おそらく反対側のフェイスにユニバースが侵入します)場合には、フェイスは生成されません。

この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

既存のTopoGeometryの定義に入り込んでいるエッジは削除を拒絶されます。TopoGeometryが二つのフェイスのうちひとつだけで定義されている (かつ他方は定義に使われていない)場合、二つのフェイスの修復は拒絶されます。

引数がNULLである場合、与えられたエッジが不明である場合 (トポロジスキーマのedgeテーブル内に既に存在していなければなりません)、トポロジ名が不正である場合、例外が投げられます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.14


名前

ST_RemEdgeModFace — エッジを削除し、削除対象エッジでフェイスが二つに分割されているなら、両方の空間をとるため、一つを削除して、もう一つを編集します。

概要

integer ST_RemEdgeModFace(varchar atopology, integer anedge);

説明

エッジを削除し、削除対象エッジでフェイスが二つに分割されているなら、両方の空間をとるため、一つを削除して、もう一つを編集します。ST_AddEdgeModFaceと対称となるよう、右側のフェイスを優先して保持します。削除対象エッジの代わりに残存するフェイスの識別番号を返します。

この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

既存のTopoGeometryの定義に入り込んでいるエッジは削除を拒絶されます。TopoGeometryが二つのフェイスのうちひとつだけで定義されている (かつ他方は定義に使われていない)場合、二つのフェイスの修復は拒絶されます。

引数がNULLである場合、与えられたエッジが不明である場合 (トポロジスキーマのedgeテーブル内に既に存在していなければなりません)、トポロジ名が不正である場合、例外が投げられます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.15


名前

ST_ChangeEdgeGeom — トポロジ構造に影響を与えることなくエッジの形状を変更します。

概要

integer ST_ChangeEdgeGeom(varchar atopology, integer anedge, geometry acurve);

説明

トポロジ構造に影響を与えることなくエッジの形状を変更します。

NULLの引数があった場合、与えられたエッジがtopologyスキーマのedgeテーブルに存在しない場合、acurveLINESTRINGでない場合、anodeanothernodeacurveの開始点と終了点でない場合、または、変更によってトポロジが変わる場合には、エラーが投げられます。

acurveジオメトリの空間参照系 (SRID) がトポロジと同じでない場合、例外が投げられます。

新しいacurveが単純でない場合には、エラーが投げられます。

古い位置から新しい位置へのエッジ移動で障害物にあたった場合はエラーが投げられます。

Availability: 1.1.0

Enhanced: 2.0.0版で、トポロジ整合性の強制を追加しました。

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.6

SELECT topology.ST_ChangeEdgeGeom('ma_topo', 1,
                ST_GeomFromText('LINESTRING(227591.9 893900.4,227622.6 893844.3,227641.6 893816.6, 227704.5 893778.5)', 26986) );
 ----
 Edge 1 changed

名前

ST_ModEdgeSplit — 既存のエッジに沿って新しいノードを生成してエッジを分割します。もとのエッジは変更され、新しいエッジが一つ追加されます。

概要

integer ST_ModEdgeSplit(varchar atopology, integer anedge, geometry apoint);

説明

既存のエッジに沿って新しいノードを生成してエッジを分割します。もとのエッジは変更され、新しいエッジが一つ追加されます。この関数によって、既存の接続されているエッジとリレーションシップが更新されます。新しく追加されたノードの識別番号が返ります。

Availability: 1.?

Changed: 2.0 - 以前の版では名前を間違えてST_ModEdgesSplitになっていました。

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.9

-- エッジの追加 --
 SELECT topology.AddEdge('ma_topo', ST_GeomFromText('LINESTRING(227592 893910, 227600 893910)', 26986) ) As edgeid;

-- edgeid --
3


-- エッジの分割 --
SELECT topology.ST_ModEdgeSplit('ma_topo',  3, ST_SetSRID(ST_Point(227594,893910),26986)  ) As node_id;
        node_id
-------------------------
7

名前

ST_ModEdgeHeal — 二つのエッジについて、接続しているノードを削除して修復します。1番目のエッジを編集して、2番目のエッジを削除します。削除されたノードの識別番号を返します。

概要

int ST_ModEdgeHeal(varchar atopology, integer anedge, integer anotheredge);

説明

二つのエッジについて、接続しているノードを削除して修復します。1番目のエッジを編集して、2番目のエッジを削除します。削除されたノードの識別番号を返します。この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.9


名前

ST_NewEdgeHeal — 二つのエッジについて、接続しているノードを削除して修復します。両方のエッジを削除し、1番目のエッジと同じ方向のエッジに置き換えます。

概要

int ST_NewEdgeHeal(varchar atopology, integer anedge, integer anotheredge);

説明

二つのエッジについて、接続しているノードを削除して修復します。両方のエッジを削除し、1番目のエッジと同じ方向のエッジに置き換えます。 修復されたエッジに置き換えられた新しいエッジの識別番号を返します。 この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.9


名前

ST_MoveIsoNode — トポロジ内の孤立ノードを別の位置に移動させます。新しいapointジオメトリがノードとして存在しているなら、エラーが投げられます。移動に関する説明を返します。

概要

text ST_MoveIsoNode(varchar atopology, integer anedge, geometry apoint);

説明

トポロジ内の孤立ノードを別の位置に移動させます。新しいapointジオメトリがノードとして存在しているなら、エラーが投げられます。

引数がNULLである場合、apointがポイントでない場合、既存のノードが孤立していない (既存エッジの始端または終端)場合、 新しいノード位置が既存のエッジとインタセクトする (終端も含む)場合、例外が投げられます。

ポイントジオメトリの空間参照系 (SRID)がトポロジと異なる場合には、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.2

-- フェイスの無い孤立ノードの追加 --
SELECT topology.ST_AddIsoNode('ma_topo',  NULL, ST_GeomFromText('POINT(227579 893916)', 26986) ) As nodeid;
 nodeid
--------
      7
-- 新しいノードの移動 --
SELECT topology.ST_MoveIsoNode('ma_topo', 7,  ST_GeomFromText('POINT(227579.5 893916.5)', 26986) ) As descrip;
                      descrip
----------------------------------------------------
Isolated Node 7 moved to location 227579.5,893916.5

関連情報

ST_AddIsoNode


名前

ST_NewEdgesSplit — 新しいノードを既存のエッジに沿って作成して、エッジを分割します。もとのエッジは削除され、二つのエッジに置き換えられます。二つの新しいエッジに接続する新しいノードの識別番号を返します。

概要

integer ST_NewEdgesSplit(varchar atopology, integer anedge, geometry apoint);

説明

anedgeで指定される既存のエッジに沿ったapointの位置に新しいノードを作成して、エッジを分割します。もとのエッジは削除され、二つつのエッジに置き換えられます。二つの新しいエッジに接続する新しいノードの識別番号を返します。この関数によって、既存の接続されているエッジとリレーションシップが更新されます。

ポイントジオメトリの空間参照系 (SRID)がトポロジと異なる場合、apointがポイントジオメトリでない場合、ポイントがNULLの場合、ポイントが既にノードとして存在する場合、エッジが既存のエッジと一致しない場合、ポイントがエッジ内にない場合、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.8

-- エッジの追加  --
SELECT topology.AddEdge('ma_topo', ST_GeomFromText('LINESTRING(227575 893917,227592 893900)', 26986) ) As edgeid;
-- 結果 --
edgeid
------
        2
-- 新しいエッジの分割 --
SELECT topology.ST_NewEdgesSplit('ma_topo', 2,  ST_GeomFromText('POINT(227578.5 893913.5)', 26986) ) As newnodeid;
 newnodeid
---------
       6

名前

ST_RemoveIsoNode — 孤立ノードを削除し、実行結果が返されます。ノードが孤立していない (エッジの始端または終端である)場合には、例外が投げられます。

概要

text ST_RemoveIsoNode(varchar atopology, integer anode);

説明

孤立ノードを削除し、実行結果が返されます。ノードが孤立していない (エッジの始端または終端である)場合には、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.3

-- フェイスの無い孤立ノードの削除 --
SELECT topology.ST_RemoveIsoNode('ma_topo',  7 ) As result;
         result
-------------------------
 Isolated node 7 removed

関連情報

ST_AddIsoNode


名前

ST_RemoveIsoEdge — 孤立エッジを削除し、実行結果の記述を返します。エッジが孤立していない場合には、例外が投げられます。

概要

text ST_RemoveIsoEdge(varchar atopology, integer anedge);

説明

孤立エッジを削除し、実行結果の記述を返します。エッジが孤立していない場合には、例外が投げられます。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.3

-- フェイスの無い孤立ノードの削除 --
SELECT topology.ST_RemoveIsoNode('ma_topo',  7 ) As result;
         result
-------------------------
 Isolated node 7 removed

関連情報

ST_AddIsoNode

4.6.7. トポロジアクセサ

GetEdgeByPoint — 与えられたポイントにインタセクトするエッジの識別番号を探索します。
GetFaceByPoint — 与えられたポイントにインタセクトするフェイスの識別番号を探索します。
GetNodeByPoint — ポイント位置にあるノードの識別番号を探索します。
GetTopologyID — トポロジ名からtopology.topologyテーブル内にあるトポロジの識別番号を返します。
GetTopologySRID — トポロジ名からtopology.topologyテーブル内にあるトポロジのSRIDを返します。
GetTopologyName — 識別番号からトポロジ (スキーマ)の名前を返します。
ST_GetFaceEdges — 順序番号を含む、afaceの境界となる、整列したエッジの集合を返します。
ST_GetFaceGeometry — 指定されたトポロジの中の、フェイス識別番号で指定されたポリゴンを返します。
GetRingEdges — 与えられた側を歩いて得られた、正負符号付きエッジ識別番号の集合を、順序通りに返します。
GetNodeEdges — 与えられたノードに付随するエッジの集合を整列して返します。

名前

GetEdgeByPoint — 与えられたポイントにインタセクトするエッジの識別番号を探索します。

概要

integer GetEdgeByPoint(varchar atopology, geometry apoint, float8 tol1);

説明

与えられたポイントにインタセクトするエッジの識別番号を探索します。

この関数は、トポロジ、ポイント、許容差を引数にして、整数 (エッジの識別番号)を返します。許容差が0の場合、ポイントはエッジとインタセクトしていなければなりません。

apointがエッジとインタセクトしない場合には、0を返します。

許容差を0より大きくして、ポイント付近のエッジが一つより多い場合には、例外が投げられます。

[注記]

許容差が0の場合には、ST_Intersectsを使い、それ以外では、ST_DWinthinを使います。

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

Availability: 2.0.0

本例ではAddEdgeで作ったエッジを使います。

SELECT topology.GetEdgeByPoint('ma_topo',geom, 1) As with1mtol, topology.GetEdgeByPoint('ma_topo',geom,0) As withnotol
FROM ST_GeomFromEWKT('SRID=26986;POINT(227622.6 893843)') As geom;
 with1mtol | withnotol
-----------+-----------
         2 |         0
SELECT topology.GetEdgeByPoint('ma_topo',geom, 1) As nearnode
FROM ST_GeomFromEWKT('SRID=26986;POINT(227591.9 893900.4)') As geom;

-- エラー発生 --
ERROR:  Two or more edges found

名前

GetFaceByPoint — 与えられたポイントにインタセクトするフェイスの識別番号を探索します。

概要

integer GetFaceByPoint(varchar atopology, geometry apoint, float8 tol1);

説明

与えられたポイントにインタセクトするフェイスの識別番号を探索します。

この関数は、トポロジ、ポイント、許容差を引数にして、整数 (フェイスの識別番号)を返します。許容差が0の場合には、ポイントはフェイスとインタセクトしていなければなりません。

apointがフェイスとインタセクトしない場合には、0を返します。

許容差を0より大きくして、ポイント付近のフェイスが一つより多い場合には、例外が投げられます。

[注記]

許容差が0の場合には、ST_Intersectsを使い、それ以外では、ST_DWinthinを使います。

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

Availability: 2.0.0

本例ではAddFaceで作ったフェイスを使います。

SELECT topology.GetFaceByPoint('ma_topo',geom, 10) As with1mtol, topology.GetFaceByPoint('ma_topo',geom,0) As withnotol
        FROM ST_GeomFromEWKT('POINT(234604.6 899382.0)') As geom;

         with1mtol | withnotol
        -----------+-----------
                         1 |         0
SELECT topology.GetFaceByPoint('ma_topo',geom, 1) As nearnode
        FROM ST_GeomFromEWKT('POINT(227591.9 893900.4)') As geom;

-- エラー発生--
ERROR:  Two or more faces found

名前

GetNodeByPoint — ポイント位置にあるノードの識別番号を探索します。

概要

integer GetNodeByPoint(varchar atopology, geometry apoint, float8 tol1);

説明

ポイント位置にあるノードの識別番号を探索します。

トポロジ、POINT、許容値が与えられ、整数 (ノード識別番号)が返ります。tolerance = 0 の場合には、確実にインタセクトするノードを取得し、そうでない場合には、指定した間隔の中からノードを取得します。

apointがノードとインタセクトしない場合には、0を返します。

許容差を0より大きくして、ポイント付近のノードが一つより多い場合には、例外が投げられます。

[注記]

許容差が0の場合には、ST_Intersectsを使い、それ以外では、ST_DWinthinを使います。

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

Availability: 2.0.0

本例ではAddEdgeで作ったエッジを使います。

SELECT topology.GetNodeByPoint('ma_topo',geom, 1) As nearnode
 FROM ST_GeomFromEWKT('SRID=26986;POINT(227591.9 893900.4)') As geom;
  nearnode
----------
        2
 
SELECT topology.GetNodeByPoint('ma_topo',geom, 1000) As too_much_tolerance
 FROM ST_GeomFromEWKT('SRID=26986;POINT(227591.9 893900.4)') As geom;

 -- エラー発生 --
 ERROR:  Two or more nodes found
 

名前

GetTopologyID — トポロジ名からtopology.topologyテーブル内にあるトポロジの識別番号を返します。

概要

integer GetTopologyID(varchar toponame);

説明

トポロジ名からtopology.topologyテーブル内にあるトポロジの識別番号を返します。

Availability: 1.?

SELECT topology.GetTopologyID('ma_topo') As topo_id;
 topo_id
---------
       1

名前

GetTopologySRID — トポロジ名からtopology.topologyテーブル内にあるトポロジのSRIDを返します。

概要

integer GetTopologyID(varchar toponame);

説明

与えられたトポロジ名からtopology.topologyテーブル内のトポロジの空間参照系識別番号を返します。

Availability: 2.0.0

SELECT topology.GetTopologySRID('ma_topo') As SRID;
 SRID
-------
  4326

名前

GetTopologyName — 識別番号からトポロジ (スキーマ)の名前を返します。

概要

varchar GetTopologyName(integer topology_id);

説明

識別番号からトポロジ (スキーマ)の名前を返します。

Availability: 1.?

SELECT topology.GetTopologyName(1) As topo_name;
 topo_name
-----------
 ma_topo

名前

ST_GetFaceEdges — 順序番号を含む、afaceの境界となる、整列したエッジの集合を返します。

概要

getfaceedges_returntype ST_GetFaceEdges(varchar atopology, integer aface);

説明

順序番号を含む、afaceの境界となる、整列したエッジの集合を返します。それぞれの出力は、順序番号とエッジ識別番号からなります。順序番号は1から始まります。

環ごとのエッジの列挙は、識別番号が最も小さいものから始まります。エッジの順序は左手の法則に従います (境界フェイスは各有向辺の左側にあるようにします)。

Availability: 2.0

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.5

-- 1番フェイスの境界を返します。
SELECT (topology.ST_GetFaceEdges('tt', 1)).*;
-- 結果 --
 sequence | edge
----------+------
        1 |   -4
        2 |    5
        3 |    7
        4 |   -6
        5 |    1
        6 |    2
        7 |    3
(7 rows)
-- 1番フェイスの順序番号、エッジ識別番号とジオメトリを返します。
-- geomとseqが欲しいだけならST_GetFaceGeometryを使います。
SELECT t.seq, t.edge, geom
FROM topology.ST_GetFaceEdges('tt',1) As t(seq,edge)
        INNER JOIN tt.edge AS e ON abs(t.edge) = e.edge_id;

名前

ST_GetFaceGeometry — 指定されたトポロジの中の、フェイス識別番号で指定されたポリゴンを返します。

概要

geometry ST_GetFaceGeometry(varchar atopology, integer aface);

説明

指定されたトポロジの中の、フェイス識別番号で指定されたポリゴンを返します。フェイスを作るエッジからポリゴンを構築します。

Availability: 1.?

This method implements the SQL/MM specification. SQL-MM 3 トポロジ-ジオメトリ および トポロジ-ネットワーク 3: ルーチン詳細: X.3.16

-- AddFaceで追加したポリゴンのWKTを返します。
SELECT ST_AsText(topology.ST_GetFaceGeometry('ma_topo', 1)) As facegeomwkt;
-- 結果 --
               facegeomwkt

--------------------------------------------------------------------------------
 POLYGON((234776.9 899563.7,234896.5 899456.7,234914 899436.4,234946.6 899356.9,
234872.5 899328.7,234891 899285.4,234992.5 899145,234890.6 899069,
234755.2 899255.4,234612.7 899379.4,234776.9 899563.7))

関連情報

AddFace


名前

GetRingEdges — 与えられた側を歩いて得られた、正負符号付きエッジ識別番号の集合を、順序通りに返します。

概要

getfaceedges_returntype GetRingEdges(varchar atopology, integer aring, integer max_edges=null);

説明

与えられた側を歩いて得られた、正負符号付きエッジ識別番号の集合を、順序通りに返します。出力は順序番号と正負符号付きエッジ識別番号からなります。順序番号は1始まりです。

正のエッジ識別番号を渡すと、対応するエッジの左側を歩き、エッジを順方向に進みます。負のエッジ識別番号を渡すと、右側を歩き、エッジを逆方向に進みます。

max_edgesがNULLでな場合には、返されるレコードを超えることはありません。これは、不正なトポロジを扱うときの安全確保のためのパラメータであることを意味します。

[注記]

この関数はメタデータとリンクするエッジ環を使います。

Availability: 2.0.0


名前

GetNodeEdges — 与えられたノードに付随するエッジの集合を整列して返します。

概要

getfaceedges_returntype GetNodeEdges(varchar atopology, integer anode);

説明

与えられたノードに付随するエッジの集合を整列して返します。 出力は、連続する、正負符号を持つエッジ識別番号からなります。順序番号は1から始まります。 正のエッジは与えられたノードから始まるものです。 負のエッジは与えられたノードで終わるものです。 閉じたエッジは2回現れます (正と負になります)。 並び順は北側から時計回りになります。

[注記]

この関数は、並び順を計算していて、メタデータからのデータを使わないので、 連結しているエッジ環を構築するのに使えます。

Availability: 2.0

関連情報

GetRingEdges, ST_Azimuth

4.6.8. トポロジ処理

概要

本節では、非標準の手法でのトポロジ処理の関数を挙げます。

Polygonize — トポロジエッジで定義される全てのフェイスを探索し、追加します。
AddNode — 指定したトポロジスキーマのノードテーブルにポイントノードを追加し、新しいノードの識別番号を返します。指定したポイントに既にノードがある場合は既存のノード識別番号を返します。
AddEdge — 指定したラインストリングジオメトリを使って、ラインストリングエッジをエッジテーブルに追加し、指定したトポロジスキーマの始点終点をポイントノードテーブルに追加し、新しい (または既存の)エッジの識別番号を返します。
AddFace — フェイスプリミティブをトポロジに登録し、その識別番号を得ます。
ST_Simplify — 与えたTopoGeometryを「シンプル化した」ジオメトリを返します。ダグラス-ポーカーのアルゴリズムを使います。

名前

Polygonize — トポロジエッジで定義される全てのフェイスを探索し、追加します。

概要

text Polygonize(varchar toponame);

説明

トポロジエッジプリミティブで構築することができる全てのフェイスを登録します。

対象トポロジは自己インタセクトするエッジが無いと仮定しています。

[注記]

既に登録されているフェイスは認識されているので、同じトポロジに対してPolygonizeを複数回呼んでも問題ありません。

[注記]

この関数はエッジテーブルのnext_left_edgeとnext_right_edgeフィールドの読み書きを行いません。

Availability: 2.0.0

関連情報

AddFace, ST_Polygonize


名前

AddNode — 指定したトポロジスキーマのノードテーブルにポイントノードを追加し、新しいノードの識別番号を返します。指定したポイントに既にノードがある場合は既存のノード識別番号を返します。

概要

integer AddNode(varchar toponame, geometry apoint, boolean allowEdgeSplitting=false, boolean computeContainingFace=false);

説明

指定したトポロジスキーマのノードテーブルにポイントノードを追加します。 AddEdge関数は、呼ばれると自動的にエッジの始端と終端のポイントを追加するので、明示的にエッジのノードを追加する必要はあまりありません。

ノードとクロスするエッジが発見された場合は、例外が発生するか、エッジが分割されます。allowEdgeSplittingパラメータの値に依存します。

computeContainingFaceがtrueの場合には、新しく追加されたノードによって、ノードを含む正しいフェイスが計算されます。

[注記]

apointジオメトリが既にノードとして存在する場合、ノードは追加されずに、既存ノードの識別番号を返します。

Availability: 2.0.0

SELECT topology.AddNode('ma_topo', ST_GeomFromText('POINT(227641.6 893816.5)', 26986) ) As nodeid;
-- 結果 --
nodeid
--------
 4

関連情報

AddEdge, CreateTopology


名前

AddEdge — 指定したラインストリングジオメトリを使って、ラインストリングエッジをエッジテーブルに追加し、指定したトポロジスキーマの始点終点をポイントノードテーブルに追加し、新しい (または既存の)エッジの識別番号を返します。

概要

integer AddEdge(varchar toponame, geometry aline);

説明

指定したラインストリングジオメトリを使って、指定したtoponameスキーマのノードテーブルにノードを追加し、新しいまたは既存のレコードのエッジ識別番号を返します。ラインストリングエッジをエッジテーブルに追加し、指定したトポロジスキーマの始点終点をポイントノードテーブルに追加し、新規または既存のエッジの識別番号を返します。新しく追加されたエッジは両側にユニバースフェイスを持ち、自分自身にリンクしています。

[注記]

alineジオメトリが既存のエッジとクロスしたり、既存のエッジをオーバラップしたり、既存のエッジを包含したり、既存のエッジに包含されたりする場合には、エラーが投げられ、エッジは追加されません。

[注記]

alineのジオメトリはsridがトポロジで指定されたものと同じである必要があり、異なる場合には、不正な空間参照系エラーが投げられます。

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

Availability: 2.0.0

SELECT topology.AddEdge('ma_topo', ST_GeomFromText('LINESTRING(227575.8 893917.2,227591.9 893900.4)', 26986) ) As edgeid;
-- 結果 --
edgeid
--------
 1

SELECT topology.AddEdge('ma_topo', ST_GeomFromText('LINESTRING(227591.9 893900.4,227622.6 893844.2,227641.6 893816.5,
 227704.5 893778.5)', 26986) ) As edgeid;
-- 結果 --
edgeid
--------
 2

 SELECT topology.AddEdge('ma_topo', ST_GeomFromText('LINESTRING(227591.2 893900, 227591.9 893900.4,
  227704.5 893778.5)', 26986) ) As edgeid;
 -- エラー発生 --
 ERROR:  Edge intersects (not on endpoints) with existing edge 1

名前

AddFace — フェイスプリミティブをトポロジに登録し、その識別番号を得ます。

概要

integer AddFace(varchar toponame, geometry apolygon, boolean force_new=false);

説明

フェイスプリミティブをトポロジに登録し、その識別番号を得ます。

新しく追加されたフェイスのために、境界を形成するエッジとフェイスに含まれるエッジはleft_faceとright_faceフィールドに正しい値を持つよう更新されます。フェイスに含まれる孤立ノードも正しいcontaining_faceフィールド値を持つよう更新されます。

[注記]

この関数はエッジテーブルのnext_left_edgeとnext_right_edgeフィールドの読み書きを行いません。

対象トポロジは妥当 (自己インタセクトするエッジが無い)と仮定しています。ポリゴンの境界が既存のエッジでは完全には定義されない場合や、ポリゴンが既存のフェイスにオーバラップする場合には、例外が投げられます。

apolygonジオメトリが既にフェイスとして存在している場合には、 force_newがfalse (デフォルト)の場合は、既存フェイスのフェイス識別番号が返り、force_newがtrueの場合は、新しい識別番号が

[注記]

既存フェイスの新規登録が実行される時(force_new=true)、そのエッジ内の既存のフェイスへの参照のダングルを解決しません。また、関連テーブルのノードと既存フェイスのレコードのMBR(訳注: 最小境界矩形)フィールドの更新も行いません。これに対応するのは、この関数を呼び出した側です。

[注記]

apolygonジオメトリはトポロジと同じsridである必要があり、異なる場合には、不正な空間参照系エラーが投げられます。

Availability: 2.0.0

-- 最初に、反復子にgenerate_seriesを使用してエッジを追加
-- (generate_seriesの最大値の関係上、
-- 頂点が10000個未満のポリゴンでのみ動作します)

SELECT topology.AddEdge('ma_topo', ST_MakeLine(ST_PointN(geom,i), ST_PointN(geom, i + 1) )) As edgeid
    FROM (SELECT  ST_NPoints(geom) AS npt, geom
            FROM
                (SELECT ST_Boundary(ST_GeomFromText('POLYGON((234896.5 899456.7,234914 899436.4,234946.6 899356.9,234872.5 899328.7,
                234891 899285.4,234992.5 899145, 234890.6 899069,234755.2 899255.4,
                234612.7 899379.4,234776.9 899563.7,234896.5 899456.7))', 26986) )  As geom
            )  As geoms) As facen CROSS JOIN generate_series(1,10000) As i
         WHERE i < npt;
-- 結果 --
 edgeid
--------
      3
      4
      5
      6
      7
      8
      9
     10
     11
     12
(10 rows)
-- フェイスの追加

SELECT topology.AddFace('ma_topo',
    ST_GeomFromText('POLYGON((234896.5 899456.7,234914 899436.4,234946.6 899356.9,234872.5 899328.7,
    234891 899285.4,234992.5 899145, 234890.6 899069,234755.2 899255.4,
    234612.7 899379.4,234776.9 899563.7,234896.5 899456.7))', 26986) ) As faceid;
-- 結果 --
faceid
--------
 1


名前

ST_Simplify — 与えたTopoGeometryを「シンプル化した」ジオメトリを返します。ダグラス-ポーカーのアルゴリズムを使います。

概要

geometry ST_Simplify(TopoGeometry tg, float8 tolerance);

説明

与えたTopoGeometryを「シンプル化した」ジオメトリを返します。個々の要素エッジに対してダグラス-ポーカーのアルゴリズムを使います。

[注記]

返されるジオメトリは単純でなかったり不正であったりする場合があります。

要素エッジの分割によって単純性/妥当性を維持することがあります。

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

Availability: 2.1.0

関連情報

ST_Simplify (ジオメトリ), ST_IsSimple, ST_IsValid, ST_ModEdgeSplit

4.6.9. TopoGeometryコンストラクタ

概要

本節では、新しいTopoGeometryを生成するトポロジ関数を挙げます。

CreateTopoGeom — 新しいTopoGeometryオブジェクトをtopoエレメント配列から生成します - tg_type: 1:[multi]point, 2:[multi]line, 3:[multi]poly, 4:collection
toTopoGeom — 単純なジオメトリからTopoGeometryを生成します。
TopoElementArray_Agg — element_idとタイプの配列 (topoelements)からなるtopoelementarrayを返します。

名前

CreateTopoGeom — 新しいTopoGeometryオブジェクトをtopoエレメント配列から生成します - tg_type: 1:[multi]point, 2:[multi]line, 3:[multi]poly, 4:collection

概要

topogeometry CreateTopoGeom(varchar toponame, integer tg_type, integer layer_id, topoelementarray tg_objs);

topogeometry CreateTopoGeom(varchar toponame, integer tg_type, integer layer_id);

説明

layer_idで示されたレイヤでTopoGeometryオブジェクトを生成し、toponameスキーマの関連テーブルに登録します。

tg_typeは次の整数値とします: 1:[multi]point (点), 2:[multi]line (線), 3:[multi]poly (面), 4:collection。layer_idは、topology.layerテーブル内のレイヤ識別番号です。

点レイヤはノードの集合から形成され、線レイヤはエッジの集合から形成され、面レイヤはフェイスの集合から形成され、コレクションはノード、エッジ、フェイスの混合から形成されます。

要素の配列を省略した場合、空のTopoGeometryオブジェクトが生成されます。

Availability: 1.?

例: 既存エッジからの形成

ri_topoスキーマ内 (ST_CreateTopoGeoの例でロードしてあります)で、ラインタイプ (整数値で2)の、layer_idが2のレイヤ (ri_roads)の最初のエッジからTopoGeometryを生成します。

INSERT INTO ri.ri_roads(road_name, topo) VALUES('Unknown', topology.CreateTopoGeom('ri_topo',2,2,'{{1,2}}'::topology.topoelementarray);

例: 面ジオメトリから最善と推測されるTopoGeometryへの変換

フェイスのコレクションから形成されるジオメトリがあるとします。blockgroupsテーブルがあり、それぞれの区画群のTopoGeometryを知りたいとします。データが完全に整列しているなら、次のようにできます。

-- TopoGeometryカラムの生成 --
SELECT topology.AddTopoGeometryColumn(
        'topo_boston',
        'boston', 'blockgroups', 'topo', 'POLYGON');

-- addtopgeometrycolumn --
1

-- 全てがエッジに沿っている前提でのカラムのアップデート
UPDATE boston.blockgroups AS bg
        SET topo = topology.CreateTopoGeom('topo_boston'
        ,3,1
        , foo.bfaces)
FROM (SELECT b.gid,  topology.TopoElementArray_Agg(ARRAY[f.face_id,3]) As bfaces
        FROM boston.blockgroups As b
            INNER JOIN topo_boston.face As f ON b.geom && f.mbr
        WHERE ST_Covers(b.geom, topology.ST_GetFaceGeometry('topo_boston', f.face_id))
            GROUP BY b.gid) As foo
WHERE foo.gid = bg.gid;
-- 世界が誤差を完璧に許容することは、ほぼありません。
-- 50%がblockgroupの境界の内側に落ちるフェイスを数えます。
UPDATE boston.blockgroups AS bg
        SET topo = topology.CreateTopoGeom('topo_boston'
        ,3,1
        , foo.bfaces)
FROM (SELECT b.gid,  topology.TopoElementArray_Agg(ARRAY[f.face_id,3]) As bfaces
        FROM boston.blockgroups As b
            INNER JOIN topo_boston.face As f ON b.geom && f.mbr
        WHERE ST_Covers(b.geom, topology.ST_GetFaceGeometry('topo_boston', f.face_id))
        OR
 (  ST_Intersects(b.geom, topology.ST_GetFaceGeometry('topo_boston', f.face_id))
            AND ST_Area(ST_Intersection(b.geom, topology.ST_GetFaceGeometry('topo_boston', f.face_id) ) ) >
                ST_Area(topology.ST_GetFaceGeometry('topo_boston', f.face_id))*0.5
                )
            GROUP BY b.gid) As foo
WHERE foo.gid = bg.gid;

-- TopoGeometryから、フェイスやエッジに沿うような正規化が
-- なされていないジオメトリに戻すには、topoをジオメトリにキャストします。
-- 新しいジオメトリは、Tigerの道路中心線に沿っていて、とても素晴らしいです。
UPDATE boston.blockgroups SET new_geom = topo::geometry;

名前

toTopoGeom — 単純なジオメトリからTopoGeometryを生成します。

概要

topogeometry toTopoGeom(geometry geom, varchar toponame, integer layer_id, float8 tolerance);

topogeometry toTopoGeom(geometry geom, topogeometry topogeom, float8 tolerance);

説明

単純なジオメトリからTopoGeometryを生成します。

入力ジオメトリを表現するために必要なトポロジプリミティブが、下位にあるトポロジに追加されます。既存のものを分割することもあります。relationテーブル内のTopoGeometryの出力に紐づきます。

既存のTopoGeometryオブジェクトは形状を維持します (topogeomが与えられている場合には、それが例外となる可能性があります)。

toleranceは、与えられた場合には、入力ジオメトリを既存のプリミティブにスナップさせるために使われます。

1番目の形式では、新しいTopoGeometryは、与えられたトポロジ (toponame)の与えられたレイヤ (layer_id)に作られます。

2番目の形式では、変換結果のプリミティブが、既存のTopoGeometry (topogeom)に追加されます。また、最終の形状にスペースを追加することがあります。新しい形状を完全に持つには、古いものを入れ替えます。clearTopoGeomを参照して下さい。

Availability: 2.0

Enhanced: 2.1.0版では、既存のTopoGeometryを取る形式が追加されました。

これは完全に全て揃ったワークフローです。

-- トポロジのセットアップがまだ終わっていない場合に実行します。
-- 許容値を許可しません。
SELECT topology.CreateTopology('topo_boston_test', 2249);
-- 新しいテーブルの生成
CREATE TABLE nei_topo(gid serial primary key, nei varchar(30));
-- TopoGeometryカラムの追加
SELECT topology.AddTopoGeometryColumn('topo_boston_test', 'public', 'nei_topo', 'topo', 'MULTIPOLYGON') As new_layer_id;
new_layer_id
-----------
1

-- 新しいTopoGeometryカラムの投入に新しいレイヤIDを使います。
-- TopoGeometryを新しいレイヤに許容値0で追加します。
INSERT INTO nei_topo(nei, topo)
SELECT nei,  topology.toTopoGeom(geom, 'topo_boston_test', 1)
FROM neighborhoods
WHERE gid BETWEEN 1 and 15;

-- 何が発生したかの確認
SELECT * FROM
    topology.TopologySummary('topo_boston_test');

-- 結果--
Topology topo_boston_test (5), SRID 2249, precision 0
61 nodes, 87 edges, 35 faces, 15 topogeoms in 1 layers
Layer 1, type Polygonal (3), 15 topogeoms
 Deploy: public.nei_topo.topo
-- 全てのTopoGeometryポリゴンを10メートル縮小
UPDATE nei_topo SET topo = ST_Buffer(clearTopoGeom(topo), -10);

-- 上の操作で何も無いようになった土地の取得
-- GRASSでは"polygon0 layer"と呼ばれているものと思います
SELECT ST_GetFaceGeometry('topo_boston_test', f.face_id)
  FROM topo_boston_test.face f
  WHERE f.face_id 
> 0 -- don't consider the universe face
  AND NOT EXISTS ( -- check that no TopoGeometry references the face
    SELECT * FROM topo_boston_test.relation
    WHERE layer_id = 1 AND element_id = f.face_id
  );
        

名前

TopoElementArray_Agg — element_idとタイプの配列 (topoelements)からなるtopoelementarrayを返します。

概要

topoelementarray TopoElementArray_Agg(topoelement set tefield);

説明

TopoElementArrayTopoElementの集合から生成するために使います。

Availability: 2.0.0

SELECT topology.TopoElementArray_Agg(ARRAY[e,t]) As tea
  FROM generate_series(1,3) As e CROSS JOIN generate_series(1,4) As t;
  tea
--------------------------------------------------------------------------
{{1,1},{1,2},{1,3},{1,4},{2,1},{2,2},{2,3},{2,4},{3,1},{3,2},{3,3},{3,4}}

4.6.10. TopoGeometryエディタ

概要

本節では、既存のTopoGeometryを編集する関数を挙げます。

clearTopoGeom — TopoGeometryの中身を消去します。
TopoGeom_addElement — TopoGeometryの定義に要素を追加します。
TopoGeom_remElement — TopoGeometryの定義から要素を削除します。
toTopoGeom — ジオメトリの形状を既存のTopoGeometryに追加します。

名前

clearTopoGeom — TopoGeometryの中身を消去します。

概要

topogeometry clearTopoGeom(topogeometry topogeom);

説明

TopoGeometryの中身を消去し、空にします。toTopoGeomと併用して、既存オブジェクトと上位にある依存オブジェクトの形状の置換に、だいたい便利です。

Availability: 2.1

-- 全てのTopoGeometryポリゴンを10メートル縮める
UPDATE nei_topo SET topo = ST_Buffer(clearTopoGeom(topo), -10);
                                

関連情報

toTopoGeom


名前

TopoGeom_addElement — TopoGeometryの定義に要素を追加します。

概要

topogeometry TopoGeom_addElement(topogeometry tg, topoelement el);

説明

TopoElementをTopoGeometryオブジェクトの定義に追加します。要素がすでに定義の一部になっていても、エラーは発生しません。

Availability: 2.3

-- 5番エッジをTopoGeometry tgに追加
UPDATE mylayer SET tg = TopoGeom_addElement(tg, '{5,2}');
                                

名前

TopoGeom_remElement — TopoGeometryの定義から要素を削除します。

概要

topogeometry TopoGeom_remElement(topogeometry tg, topoelement el);

説明

TopoGeometryオブジェクトの定義からTopoElementを削除します。

Availability: 2.3

-- TopoGeometry tgから43番フェイスを削除します
UPDATE mylayer SET tg = TopoGeom_remElement(tg, '{43,3}');
                                

名前

toTopoGeom — ジオメトリの形状を既存のTopoGeometryに追加します。

説明

toTopoGeomを参照して下さい。

4.6.11. TopoGeometryアクセサ

GetTopoGeomElementArray — 与えられたTopoGeometry (プリミティブ要素)のトポロジ要素とタイプを含むtopoelementarray (topoelementの配列)を返します。
GetTopoGeomElements — 与えられたTopoGeometry (プリミティブ要素)の、トポロジのelement_idとelement_typeを含むtopoelementオブジェクトの集合を返します。

名前

GetTopoGeomElementArray — 与えられたTopoGeometry (プリミティブ要素)のトポロジ要素とタイプを含むtopoelementarray (topoelementの配列)を返します。

概要

topoelementarray GetTopoGeomElementArray(varchar toponame, integer layer_id, integer tg_id);

topoelementarray topoelement GetTopoGeomElementArray(topogeometry tg);

説明

トポロジ要素と与えられたTopoGeometry (プリミティブ要素)のタイプを含むTopoElementArrayを返します。GetTopoGeomElementsに近いですが、これは、要素群をデータセットでなく配列で返しています。

tg_idは、topology.layerテーブル内のlayer_idで指定されたレイヤのトポロジにおけるTopoGeometryオブジェクトの識別番号です。

Availability: 1.?


名前

GetTopoGeomElements — 与えられたTopoGeometry (プリミティブ要素)の、トポロジのelement_idとelement_typeを含むtopoelementオブジェクトの集合を返します。

概要

setof topoelement GetTopoGeomElements(varchar toponame, integer layer_id, integer tg_id);

setof topoelement GetTopoGeomElements(topogeometry tg);

説明

toponameスキーマ内の、与えられたTopoGeometryのelement_idとelement_type (topoelements)の集合を返します。

tg_idは、topology.layerテーブル内のlayer_idで指定されたレイヤのトポロジにおけるTopoGeometryオブジェクトの識別番号です。

Availability: 2.0.0

4.6.12. TopoGeometry出力

AsGML — TopoGeometryのGML表現を返します。
AsTopoJSON — opoGeometryのTopoJSON表現を返します。

名前

AsGML — TopoGeometryのGML表現を返します。

概要

text AsGML(topogeometry tg);

text AsGML(topogeometry tg, text nsprefix_in);

text AsGML(topogeometry tg, regclass visitedTable);

text AsGML(topogeometry tg, regclass visitedTable, text nsprefix);

text AsGML(topogeometry tg, text nsprefix_in, integer precision, integer options);

text AsGML(topogeometry tg, text nsprefix_in, integer precision, integer options, regclass visitedTable);

text AsGML(topogeometry tg, text nsprefix_in, integer precision, integer options, regclass visitedTable, text idprefix);

text AsGML(topogeometry tg, text nsprefix_in, integer precision, integer options, regclass visitedTable, text idprefix, int gmlversion);

説明

GML3の書式でTopoGeometryのGML表現を返します。nsprefix_inが指定されていない場合には、gmlが使われます。非修飾名前空間を得るにはnsprefixに空文字列を渡します。精度 (デフォルトは15)とoptions (デフォルトは1)パラメタは、与えられた場合には、裏で呼んでいるST_AsGMLにそのまま渡します。

visitedTableパラメタは、与えられた場合には、訪問したノード要素とエッジ要素のトラックを保持するために使われ、重複定義になるところで相互参照 (xlink:xref)を使います。テーブルは 整数カラムである'element_type'と'element_id'とを持つことを期待されます。この関数を呼び出したユーザは、このテーブルへの読み込み権限と書き込み権限とが必要です。効率よくするには、element_typeとelement_idに、この順序でインデクスを定義します。インデクスは一意制約をカラムに追加すると自動的に生成されます。例を示します。

CREATE TABLE visited (
  element_type integer, element_id integer,
  unique(element_type, element_id)
);

idprefixパラメタは、指定された場合には、Edgeタグ識別子とNodeタグ識別子の前に付きます。

gmlverパラメタは、指定された場合には、裏で呼んでいるST_AsGMLに渡されます。デフォルトは3です。

Availability: 2.0.0

ここではCreateTopoGeomで生成したTopoGeometryを使用しています。

SELECT topology.AsGML(topo) As rdgml
  FROM ri.roads
  WHERE road_name = 'Unknown';

-- rdgml--
<gml:TopoCurve>
    <gml:directedEdge>
        <gml:Edge gml:id="E1">
            <gml:directedNode orientation="-">
                <gml:Node gml:id="N1"/>
            </gml:directedNode>
            <gml:directedNode
></gml:directedNode>
            <gml:curveProperty>
                <gml:Curve srsName="urn:ogc:def:crs:EPSG::3438">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:posList srsDimension="2"
>384744 236928 384750 236923 384769 236911 384799 236895 384811 236890
                            384833 236884 384844 236882 384866 236881 384879 236883 384954 236898 385087 236932 385117 236938
                            385167 236938 385203 236941 385224 236946 385233 236950 385241 236956 385254 236971
                            385260 236979 385268 236999 385273 237018 385273 237037 385271 237047 385267 237057 385225 237125
                            385210 237144 385192 237161 385167 237192 385162 237202 385159 237214 385159 237227 385162 237241
                            385166 237256 385196 237324 385209 237345 385234 237375 385237 237383 385238 237399 385236 237407
                            385227 237419 385213 237430 385193 237439 385174 237451 385170 237455 385169 237460 385171 237475
                            385181 237503 385190 237521 385200 237533 385206 237538 385213 237541 385221 237542 385235 237540 385242 237541
                            385249 237544 385260 237555 385270 237570 385289 237584 385292 237589 385291 237596 385284 237630</gml:posList>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveProperty>
        </gml:Edge>
    </gml:directedEdge>
</gml:TopoCurve
>

上の例から名前空間を取った例です。

SELECT topology.AsGML(topo,'') As rdgml
  FROM ri.roads
  WHERE road_name = 'Unknown';

-- rdgml--
<TopoCurve>
    <directedEdge>
        <Edge id="E1">
            <directedNode orientation="-">
                <Node id="N1"/>
            </directedNode>
            <directedNode
></directedNode>
            <curveProperty>
                <Curve srsName="urn:ogc:def:crs:EPSG::3438">
                    <segments>
                        <LineStringSegment>
                            <posList srsDimension="2"
>384744 236928 384750 236923 384769 236911 384799 236895 384811 236890
                            384833 236884 384844 236882 384866 236881 384879 236883 384954 236898 385087 236932 385117 236938
                            385167 236938 385203 236941 385224 236946 385233 236950 385241 236956 385254 236971
                            385260 236979 385268 236999 385273 237018 385273 237037 385271 237047 385267 237057 385225 237125
                            385210 237144 385192 237161 385167 237192 385162 237202 385159 237214 385159 237227 385162 237241
                            385166 237256 385196 237324 385209 237345 385234 237375 385237 237383 385238 237399 385236 237407
                            385227 237419 385213 237430 385193 237439 385174 237451 385170 237455 385169 237460 385171 237475
                            385181 237503 385190 237521 385200 237533 385206 237538 385213 237541 385221 237542 385235 237540 385242 237541
                            385249 237544 385260 237555 385270 237570 385289 237584 385292 237589 385291 237596 385284 237630</posList>
                         </LineStringSegment>
                    </segments>
                </Curve>
            </curveProperty>
        </Edge>
    </directedEdge>
</TopoCurve
>

名前

AsTopoJSON — opoGeometryのTopoJSON表現を返します。

概要

text AsTopoJSON(topogeometry tg, regclass edgeMapTable);

説明

TopoGeometryのTopoJSON表現を返します。edgeMapTableがNULLでない場合には、エッジ識別番号とアーク添え字のルックアップと格納のマッピングに使われます。これは、最終的な文書内のコンパクトな"arcs"配列ができるようにするためです。

このテーブルは、与えられた場合には、"serial"型の"arc_id"カラムと整数型の"edge_id"とを持つことが期待されます。関数はこのテーブルに"edge_id"を問い合わせるので、このカラムにインデクスを追加することが推奨されます。

[注記]

TopoJSONでのアークのインデックスは0始まりですが、"edgeMapTable"テーブルでは1始まりです。

完全なTopoJSON文書は、この関数が返すスニペットだけでなく、実際のarcsメンバと、いくつかのヘッダを含む必要があります。 TopoJSON specificationをご覧ください。

Availability: 2.1.0

Enhanced: 2.2.1 点入力に対応するようになりました

関連情報

ST_AsGeoJSON

CREATE TEMP TABLE edgemap(arc_id serial, edge_id int unique);

-- ヘッダ
SELECT '{ "type": "Topology", "transform": { "scale": [1,1], "translate": [0,0] }, "objects": {'

-- オブジェクトn
UNION ALL SELECT '"' || feature_name || '": ' || AsTopoJSON(feature, 'edgemap')
FROM features.big_parcels WHERE feature_name = 'P3P4';

-- アーク
WITH edges AS (
  SELECT m.arc_id, e.geom FROM edgemap m, city_data.edge e
  WHERE e.edge_id = m.edge_id
), points AS (
  SELECT arc_id, (st_dumppoints(geom)).* FROM edges
), compare AS (
  SELECT p2.arc_id,
         CASE WHEN p1.path IS NULL THEN p2.geom
              ELSE ST_Translate(p2.geom, -ST_X(p1.geom), -ST_Y(p1.geom))
         END AS geom
  FROM points p2 LEFT OUTER JOIN points p1
  ON ( p1.arc_id = p2.arc_id AND p2.path[1] = p1.path[1]+1 )
  ORDER BY arc_id, p2.path
), arcsdump AS (
  SELECT arc_id, (regexp_matches( ST_AsGeoJSON(geom), '\[.*\]'))[1] as t
  FROM compare
), arcs AS (
  SELECT arc_id, '[' || array_to_string(array_agg(t), ',') || ']' as a FROM arcsdump
  GROUP BY arc_id
  ORDER BY arc_id
)
SELECT '}, "arcs": [' UNION ALL
SELECT array_to_string(array_agg(a), E',\n') from arcs

-- フッタ
UNION ALL SELECT ']}'::text as t;

-- 結果 --
{ "type": "Topology", "transform": { "scale": [1,1], "translate": [0,0] }, "objects": {
"P3P4": { "type": "MultiPolygon", "arcs": [[[-1]],[[6,5,-5,-4,-3,1]]]}
}, "arcs": [
 [[25,30],[6,0],[0,10],[-14,0],[0,-10],[8,0]],
 [[35,6],[0,8]],
 [[35,6],[12,0]],
 [[47,6],[0,8]],
 [[47,14],[0,8]],
 [[35,22],[12,0]],
 [[35,14],[0,8]]
 ]}

4.6.13. トポロジ空間関係関数

概要

本節では、TopoGeometryとトポロジプリミティブとの間の関係を見るトポロジ関数の一覧を挙げます。

Equals — 二つのTopoGeometryが同じトポロジプリミティブで成っている場合にtrueを返します。
Intersects — 二つのTopoGeometryからのプリミティブの組がインタセクトする場合にtrueを返します。

名前

Equals — 二つのTopoGeometryが同じトポロジプリミティブで成っている場合にtrueを返します。

概要

boolean Equals(topogeometry tg1, topogeometry tg2);

説明

二つTopoGeometryが同じトポロジプリミティブで成っている場合にtrueを返します。

[注記]

この関数はジオメトリコレクションのTopoGeometryに対応していません。異なるトポロジからなるTopoGeometryとの比較もできません。

Availability: 1.1.0

This function supports 3d and will not drop the z-index.


名前

Intersects — 二つのTopoGeometryからのプリミティブの組がインタセクトする場合にtrueを返します。

概要

boolean Intersects(topogeometry tg1, topogeometry tg2);

説明

二つのTopoGeometryからのプリミティブがインタセクトする場合にtrueを返します。

[注記]

この関数はジオメトリコレクションのTopoGeometryに対応していません。異なるトポロジからなるTopoGeometryとの比較もできません。また、現在のところ、階層TopoGeometry (他のTopoGeometryからなるTopoGeometry)に対応していません。

Availability: 1.1.0

This function supports 3d and will not drop the z-index.

関連情報

ST_Intersects

4.7. 住所標準化

これは、PAGC standardizerから分かれたものです (オリジナルのコードはPAGC PostgreSQL Address Standardizerにあります)。

住所標準化は単一行の住所のパーサで、入力に住所を取り、テーブルに保存された規則と、補助テーブルlex (lexicon, 語彙)およびgaz (gazetteer, 地名集)とを基に正規化します。

コードは、address_standardizerという名前の、1つのPostgreSQLエクステンションとしてビルドされます。CREATE EXTENSION address_standardizer;でインストールできます。address_standardizerエクステンションとともに、address_standardizer_data_usというサンプルデータのエクステンションがビルドされます。これには、アメリカのgaz, lexとrulesテーブルデータがあります。このエクステンションはCREATE EXTENSION address_standardizer_data_us;でインストールできます。

このエクステンションのコードはPostGISのextensions/address_standardizer内にあり、現在は自己充足しています。

インストール手順については、「PAGC住所標準化ツールのインストールと使用」を参照してください。

4.7.1. パーサの動作

パーサは右から左に見ます。最初に郵便番号、州/県、市のMACRO (訳注: マクロ)要素を見ます。その後、番地または交差点もしくはランドマークを扱う場合には、MICRO (訳注: マイクロ)要素を見ます。現在は、国別コードや国名を見ませんが、将来的には導入できると思います。

国別コード

USまたはCAを仮定します。郵便番号か州/県で米国かカナダを分けますが、判別できない場合は米国とします。

郵便番号

Perl互換の正規表現を使用して認識します。正規表現は現在はparseaddress-api.cにあり、必要な際の変更は比較的簡単です。

州/県

Perl互換の正規表現を使用して認識します。正規表現は現在はparseaddress-api.cにありますが、将来的には、メンテナンスを簡単にするためにインクルードファイルに移動するかも知れません。

4.7.2. 住所標準化の型

概要

本節では住所標準化でインストールされたPostgreSQLデータ型の一覧を挙げます。独自関数をデザインする時に特に重要となるキャストの振る舞いを記述しています。

stdaddr — 住所の要素からなる複合型です。standardize_address関数が返す型です。

名前

stdaddr — 住所の要素からなる複合型です。standardize_address関数が返す型です。

説明

住所の要素からなる複合型です。standardize_address関数が返す型です。要素の記述のいくつかはPAGC Postal Attributesから借りています。

トークン番号は、規則テーブル内の出力参照番号を示します。

This method needs address_standardizer extension.

building

文字列 (トークン番号0): 建物番号や建物名を参照します。解析されていない建物識別子と型です。一般的に、ほとんどの住所では空白です。

house_num

文字列 (トークン番号1): ストリートの番号です。75 State Streetでは75にあたります。

predir

文字列 (トークン番号2): North, South, East, Westといった、ストリート名の方角前置語です。

qual

文字列 (トークン番号 3): ストリート名の修飾前置語です。3715 OLD HIGHWAY 99ではOLDにあたります。

pretype

文字列 (トークン番号 4): STREET PREFIX TYPE (ストリート名の前置詞の種別)

name

文字列 (トークン番号 5): ストリート名

suftype

文字列 (トークン番号 6): St, Ave, Cir等の、後置詞の種別。ストリート名に続いて記述されるものです。75 State StreetではSTREETが該当します。

sufdir

文字列 (トークン番号 7): ストリート名に続くNorth, South, East, Westといった、ストリート名の方角前置語です。3715 TENTH AVENUE WESTではWESTが該当します。

ruralroute

文字列 (トークン番号 8): RURAL ROUTE (地方集配路線)。RR 7では8が該当します。

extra

文字列: 階番号のような追加的情報です。

city

文字列 (トークン番号 10): 市名です。Boston等が該当します。

state

文字列 (トークン番号 11): 州名です。MASSACHUSETTSが該当します。

country

文字列 (トークン番号 12): 国名です。USAが該当します。

postcode

文字列 (トークン番号 13): 郵便番号 (POSTAL CODE, ZIP CODE)です。02109等です。

box

文字列 (トークン番号 1415): 私書箱番号です。02109等です。

unit

文字列 (トークン番号 17): 部屋番号です。APT 3B3Bが該当します。

4.7.3. 住所標準化テーブル

概要

本節では、住所標準化が住所の正規化に使うPostgreSQLテーブルの書式を挙げます。これらのテーブルはここで参照している名前と同じである必要はありません。例または独自ジオコーダのために、国ごとに異なるlex (lexicon, 語彙)、gaz (gazetteer, 地名集)およびrulesテーブルを持つことができます。これらのテーブルの名前は、住所標準化関数に渡されます。

同梱されているaddress_standardizer_data_usエクステンションには、米国の住所標準化のためのデータがあります。

規則テーブル — 規則テーブルには、住所入力順列トークンから標準化した出力順列への対応付けに関する規則の集合が入ります。それぞれの規則は、入力トークン、-1 (終端)、出力トークン、-1、規則の種類を示す数字、規則の階級、からなります。
lexテーブル — lexテーブルは英数字の入力をクラス分けして (a) 入力トークン (「入力トークン」 参照)と (b) 標準化表現 とに関連付けます。
gaz table — gazテーブルは、地名を標準化し、入力と、(a)入力トークン (「入力トークン」を参照して下さい)および (b) 標準化された表現とを関連付けるために使われます。

名前

規則テーブル — 規則テーブルには、住所入力順列トークンから標準化した出力順列への対応付けに関する規則の集合が入ります。それぞれの規則は、入力トークン、-1 (終端)、出力トークン、-1、規則の種類を示す数字、規則の階級、からなります。

説明

規則テーブルには、少なくとも次に示すカラムが必要です。それ以外にカラムを追加してもかまいません。

id

テーブルの主キー。

rule

規則を示す文字列フィールド。 PAGC Address Standardizer Rule recordsに詳細情報があります。

ruleには、入力トークンを表現する非負の整数、終端を示す-1、郵便属性を表現する非負の整数、終端を示す-1、規則種別を表現する整数、規則の階級を示す整数からなる集合が入ります。規則は0 (最低)から17 (最高)まであります。

たとえば、2 0 2 22 3 -1 5 5 6 7 3 -1 2 6は、TYPE NUMBER TYPE DIRECT QUALIFなる入力トークン順列が、STREET STREET SUFTYP SUFDIR QUALIFなる出力トークン順列に対応付けされ、規則はARC_Cで、階級は6となります。

対応する出力トークンはstdaddrに挙げています。

入力トークン

個々の規則は、入力トークン順列、終端を示す-1の順です。PAGC Input Tokensから引用した正当な入力トークンは次の通りです。

書式ベースの入力トークン

AMPERS

(13) アンパサンド (&)は、"and"という語を短縮するために、よく使われます

DASH

(9) 区切り記号。

DOUBLE

(21) 二つの文字の順列。しばしば識別子に用いられます。

FRACT

(25) ときどき"civic nunber"または"unit number" (訳注: 各戸に付けられる番号)で使われます。

MIXED

(23) 英数文字列。識別子に用います。

NUMBER

(0) 数字からなる文字列。

ORD

(15) "First"や"1st"といったものを表現する文字列。しばしばストリート名の中で使われています。

ORD

(18) 一つの文字

WORD

(1) 任意長を持つ文字列です。一つの文字はSINGLEおよびWORDの両方になりえます。

機能ベースの入力トークン

BOXH

(14) 私書箱を示すために使われる語です。たとえば BoxまたはPO Boxです。

BUILDH

(19) 建物またはその複合体を示すための語で、通常は前置語になります。たとえばTower 7AではTowerが該当します。

BUILDT

(24) 建物またはその複合体を示すために使われる語または略語で、通常は後置語になります。たとえばShopping Centreです。

DIRECT

(22) 方位を示す語です。たとえば Northです。

MILE

(20) 距離標の住所を示す語です。

ROAD

(6) 高速道路と道路を示す語または略語です。たとえばInterstate 5Interstateです。

RR

(8) 地方集配路線を示す語または略語です。たとえばRRです。

TYPE

(2) ストリート種別を示す語または略語です。たとえばSTAVEです。

UNITH

(16) 内部の部分住所を示す語または略語です。たとえばAPTUNITです。

郵便型入力トークン

QUINT

(28) 5桁の番号。ZIPコードです。

QUAD

(29) 4桁の番号。ZIP4です。

PCH

(27) 英数3文字の順列です。カナダの郵便番号の先頭3文字であるFSAを示します。

PCT

(26) 英数3文字の順列です。カナダの郵便番号の末尾3文字です。

ストップワード

STOPWORD (訳注: 処理対象外とする語)はWORDと結合します。規則で、複数のWORDとSTOPWORDの列は、単一のWORDトークンで表現されます。

STOPWORD

(7) 重要性が低い語で、パース時に省かれます。たとえばTHEが該当します。

出力トークン

1番目の-1 (終端)の後に、出力トークンが続き、その後に-1が続きます。対応する出力トークンの番号は、stdaddrに挙げています。許されるものは、規則の種類に依存します。それぞれの規則種別で有効なトークンは「規則種別と階級」に挙げています。

規則種別と階級

規則の最後の部分は規則種別で、次に挙げるものの一つが示すものです。この後には階級が続きます。規則は0 (最低) から17 (最高)までに階級付けされます。

MACRO_C

(トークン番号 = "0") PLACE STATE ZIPのようなMACRO節をパースするための規則のクラス。

MACRO_C出力トークン (http://www.pagcgeo.org/docs/html/pagc-12.html#--r-typ--からの引用)

CITY

(トークン番号 "10") たとえば"Albany" (訳注: ニューヨーク州の州都)等。

STATE

(トークン番号 "11") たとえば"NY" (訳注: ニューヨーク州)等。

NATION

(トークン番号 "12") ほとんどの参照ファイル内で使われない属性です。たとえば"USA"等。

POSTAL

(トークン番号 "13") (SADS elements "ZIP CODE" , "PLUS 4" ). 米国Zip (郵便番号)とカナダ郵便番号の両方で使われます。

MICRO_C

(トークン番号 = "1") 完全なMICRO節 (House, street, sufdir, predir, pretyp, suftype, qualif等)をパースするための規則のクラス (ARC_CとCIVIC_Cの和)。建物フェーズでは使われません。

MICRO_C 出力トークン (http://www.pagcgeo.org/docs/html/pagc-12.html#--r-typ--からの引用)

HOUSE

文字列 (トークン番号1): ストリートの番号です。75 State Streetでは75にあたります。

predir

文字列 (トークン番号2): North, South, East, Westといった、ストリート名の方角前置語です。

qual

文字列 (トークン番号 3): ストリート名の修飾前置語です。3715 OLD HIGHWAY 99ではOLDにあたります。

pretype

文字列 (トークン番号 4): STREET PREFIX TYPE (ストリート名の前置詞の種別)

street

文字列 (トークン番号 5): ストリート名

suftype

文字列 (トークン番号 6): St, Ave, Cir等の、後置詞の種別。ストリート名に続いて記述されるものです。75 State StreetではSTREETが該当します。

sufdir

文字列 (トークン番号 7): ストリート名に続くNorth, South, East, Westといった、ストリート名の方角前置語です。3715 TENTH AVENUE WESTではWESTが該当します。

ARC_C

(トークン番号 = "2") HOUSE属性を除いたMICRO節をパースするための規則のクラス。MICRO_CからHOUSEトークンを除いた出力トークン集合と同じです。

CIVIC_C

(トークン番号 = "3") HOUSE属性をパースするための規則のクラス。

EXTRA_C

(トークン番号 = "4") EXTRA属性 (ジオコーディングから除かれる属性)をパースするための規則のクラス。

EXTRA_C 出力トークン (http://www.pagcgeo.org/docs/html/pagc-12.html#--r-typ--からの引用)

BLDNG

(トークン番号 0): パースされていない建物識別子と種別。

BOXH

(トークン番号 14): BOX 3B内のBOXにあたります。

BOXT

(トークン番号 15): BOX 3B内の3Bにあたります。

RR

(トークン番号 8): RR 7内のRRにあたります。

UNITH

(トークン番号 16): APT 3B内のAPTにあたります。

UNITT

(トークン番号17): APT 3B内の3Bにあたります。

UNKNWN

(トークン番号9): その他分類対象外の出力。


名前

lexテーブル — lexテーブルは英数字の入力をクラス分けして (a) 入力トークン (「入力トークン」 参照)と (b) 標準化表現 とに関連付けます。

説明

lex (lexiconの略語)テーブルは、英数入力を分類し、入力を (a) 「入力トークン」および (b) 標準化された表現、に関連付けます。

lexは少なくとも次のカラムを持ちます。追加できます。

id

テーブルの主キー。

seq

整数: 定義番号?

word

文字列: 入力単語

stdword

文字列: 正規化した置き換え語

token

整数: その語の種別。このコンテキストで使われる場合のみ置き換えられます。PAGC Tokensを参照して下さい。


名前

gaz table — gazテーブルは、地名を標準化し、入力と、(a)入力トークン (「入力トークン」を参照して下さい)および (b) 標準化された表現とを関連付けるために使われます。

説明

gaz (gazeteerの略語)テーブルは、地名を分類し、入力を (a) 「入力トークン」および (b) 標準化された表現、に関連付けます。例えば、アメリカのユーザなら、これらを州名および略語でロードします。

gazテーブルは少なくとも次のカラムを持ちます。独自の目的のために追加することができます。

id

テーブルの主キー。

seq

整数: 定義番号? - 語のインスタンスに使われる識別子

word

文字列: 入力単語

stdword

文字列: 正規化した置き換え語

token

整数: その語の種別。このコンテキストで使われる場合のみ置き換えられます。PAGC Tokensを参照して下さい。

4.7.4. 住所標準化関数

parse_address — 1行の住所を取り、分割します。
standardize_address — lexテーブル、gazテーブルおよび規則テーブルを使って、入力住所をstdaddr形式で返します。

名前

parse_address — 1行の住所を取り、分割します。

概要

record parse_address(text address);

説明

一つの住所を入力に取り、numstreetstreet2address1citystatezipzippluscountryからなるレコードを一つ返します。

初出: 2.2.0

This method needs address_standardizer extension.

単一の住所

SELECT num, street, city, zip, zipplus
        FROM parse_address('1 Devonshire Place, Boston, MA 02109-1234') AS a;
num |      street      |  city  |  zip  | zipplus
-----+------------------+--------+-------+---------
 1   | Devonshire Place | Boston | 02109 | 1234                

住所テーブル

-- 基本テーブル
CREATE TABLE places(addid serial PRIMARY KEY, address text);

INSERT INTO places(address)
VALUES ('529 Main Street, Boston MA, 02129'),
 ('77 Massachusetts Avenue, Cambridge, MA 02139'),
 ('25 Wizard of Oz, Walaford, KS 99912323'),
 ('26 Capen Street, Medford, MA'),
 ('124 Mount Auburn St, Cambridge, Massachusetts 02138'),
 ('950 Main Street, Worcester, MA 01610');

 -- 住所のパース
 -- 全てのフィールドで使う場合には (a).* が使えます
SELECT addid, (a).num, (a).street, (a).city, (a).state, (a).zip, (a).zipplus
FROM (SELECT addid, parse_address(address) As a
 FROM places) AS p;
addid | num |        street        |   city    | state |  zip  | zipplus
-------+-----+----------------------+-----------+-------+-------+---------
     1 | 529 | Main Street          | Boston    | MA    | 02129 |
     2 | 77  | Massachusetts Avenue | Cambridge | MA    | 02139 |
     3 | 25  | Wizard of Oz         | Walaford  | KS    | 99912 | 323
     4 | 26  | Capen Street         | Medford   | MA    |       |
     5 | 124 | Mount Auburn St      | Cambridge | MA    | 02138 |
     6 | 950 | Main Street          | Worcester | MA    | 01610 |
(6 rows)

関連情報


名前

standardize_address — lexテーブル、gazテーブルおよび規則テーブルを使って、入力住所をstdaddr形式で返します。

概要

stdaddr standardize_address(text lextab, text gaztab, text rultab, text address);

stdaddr standardize_address(text lextab, text gaztab, text rultab, text micro, text macro);

説明

指定されたlexテーブルgaz tableおよび規則テーブルのテーブルを使って、入力住所をstdaddr形式で返します。

1番目の形式: 単一行で住所を取る形式です。

2番目の形式: 住所を二つの部分から取ります。microhouse_num street等のような、標準的な宛先書式の1行目です。macroは、city, state postal_code country等のような、標準的な宛先書式の2行目です。

初出: 2.2.0

This method needs address_standardizer extension.

address_standardizer_data_usエクステンションを使います。

CREATE EXTENSION address_standardizer_data_us; -- only needs to be done once

一つ目の版: 単一行住所。米国でない住所では十分に働きません。

SELECT house_num, name, suftype, city, country, state, unit  FROM standardize_address('us_lex',
                           'us_gaz', 'us_rules', 'One Devonshire Place, PH 301, Boston, MA 02109');
house_num |    name    | suftype |  city  | country |     state     |      unit
----------+------------+---------+--------+---------+---------------+-----------------
1         | DEVONSHIRE | PLACE   | BOSTON | USA     | MASSACHUSETTS | # PENTHOUSE 301

Tigerジオコーダに同梱されているテーブルを使います。この例はpostgis_tiger_geocoderをインストールしている場合のみ動作します。

SELECT *  FROM standardize_address('tiger.pagc_lex',
         'tiger.pagc_gaz', 'tiger.pagc_rules', 'One Devonshire Place, PH 301, Boston, MA 02109-1234');

読みやすくするために、hstoreエクステンションを使ってダウンぷします。必要なら CREATE EXTENSION hstore; を実行します。

SELECT (each(hstore(p))).*
 FROM standardize_address('tiger.pagc_lex', 'tiger.pagc_gaz',
   'tiger.pagc_rules', 'One Devonshire Place, PH 301, Boston, MA 02109') As p;
key     |      value
------------+-----------------
 box        |
 city       | BOSTON
 name       | DEVONSHIRE
 qual       |
 unit       | # PENTHOUSE 301
 extra      |
 state      | MA
 predir     |
 sufdir     |
 country    | USA
 pretype    |
 suftype    | PL
 building   |
 postcode   | 02109
 house_num  | 1
 ruralroute |
(16 rows)
                        

二つ目の形式: 二つの部分からなる住所

SELECT (each(hstore(p))).*
 FROM standardize_address('tiger.pagc_lex', 'tiger.pagc_gaz',
   'tiger.pagc_rules', 'One Devonshire Place, PH 301', 'Boston, MA 02109, US') As p;
key     |      value
------------+-----------------
 box        |
 city       | BOSTON
 name       | DEVONSHIRE
 qual       |
 unit       | # PENTHOUSE 301
 extra      |
 state      | MA
 predir     |
 sufdir     |
 country    | USA
 pretype    |
 suftype    | PL
 building   |
 postcode   | 02109
 house_num  | 1
 ruralroute |
(16 rows)

4.8. PostGIS追加機能

本章では、PostGISのソースアーカイブとソースレポジトリのextrasフォルダにある機能を記述します。 これらは必ずPostGISバイナリ版に同梱されているものではありませんが、通常は実行可能なplpgsqlベースのものまたは標準的なシェルスクリプトです。

4.8.1. Tigerジオコーダ

概要

米国国勢調査局が公開しているTIGER (Topologically Integrated Geographic Encoding and Referencing system ) / Line and Master Address database exportで動作するよう書かれた、PL/pgSQLベースのジオコーダです。

データローダ機能、住所正規化、住所ジオコーダおよび逆ジオコーダ、の四つの要素があります。

米国のための設計ですが、概念および機能の多くは適用可能で、他国の住所と道路ネットワークで動作するように適合させることができます (訳注: 日本の地名については未知です)。

Tiger関連の関数、道路型前置辞・道路型後置辞・州といった再利用可能な参照データ、データロード管理のための様々な制御テーブル、全てのロードされたテーブルが継承するスケルトンテーブル、を収容するためのtigerというスキーマが、スクリプトによって作成されます。

tiger_dataという、もう一つのスキーマが作られます。ここに、ローダが米国国勢調査サイトからダウンロードしてデータベースにロードした州ごとの全ての国勢調査データが収容されます。現在のモデルでは、州ごとのテーブルは、ma_addrma_edgesといったように名前の先頭に州コードを付けていて、州データのみに強制する制約が付いています。これらのテーブルはtiger schemaにあるaddr, faces, edges等から継承されています。

全てのジオコード関数は基底テーブルを参照するだけです。そのため、tiger_dataデータスキーマやそのデータを他のスキーマに分割できないという条件はありません。例えば、州ごとに異なるスキーマにしても、tiger内のテーブルから継承されているなら使用可能です。

お手持ちのデータベース内のエクステンションを有効にし、使用するデータをロードする方法については、「TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用」を参照して下さい。

[注記]

Tigerジオコーダ (tiger_2010)を使っている場合には、extras/tiger内にあるupgrade_geocoder.bat / .sh を使ってアップグレードすることができます。tiger_2010tiger_2011以上での大きな変更点は、countyテーブルとstateテーブルが、stateごとに出現することがなくなっています。tiger_2010からのデータを持っていて、tiger_2015に置き換えたい場合には、「Tigerジオコーダのアップグレード」を参照して下さい。

[注記]

PostGIS 2.2.0での新規機能は、Tiger 2015データに対応したことと、住所標準化がPostGISの一部に取り入れられたことです。

PostGIS 2.1.0での新規機能は、PostgreSQL 9.1以上では、TigerジオコーダをPostgreSQLエクステンションモデルでインストールすることができるようになったことです。詳細については「TigerジオコーダをPostGISデータベースで有効にする: エクステンションを使用」を参照して下さい。

PostGISが用意しているNormalize_Addressの代替としてPagc_Normalize_Address文字列のストリート住所を与えると、道路後置辞、前置辞、標準タイプ、番地、ストリート名等を複数フィールドに分解して持つnorm_addy複合型を返します。この関数は、tiger_geocoder同梱のルックアップテーブルだけを使います (Tigerデータは不要です)。住所標準化エクステンションが必要です。関数があります。コンパイルとインストールの方法については、「PAGC住所標準化ツールのインストールと使用」を参照して下さい。

設計:

このプロジェクトの目標は、任意の米国住所文字列を処理し、正規化したTiger国勢調査データを使ってポイントジオメトリを生成し、与えられた住所の位置や、位置のもっともらしさを反映した評価値を算出する、十分に実用的なジオコーダを構築することです。なお、評価値は高いほど悪い結果とします。

PostGIS 2.0.0で導入されたreverse_geocodeは、GPS位置のストリート住所と交差点を得るのに便利です。

ジオコーダは、PostGISに慣れている方ならだれでもインストールと使用が容易な程度に単純であるべきで、PostGISがサポートする全てのプラットフォームで簡便にインストール、使用ができるべきです。

書式や綴りの誤りがあっても確実に機能するための十分なロバスト性があるべきです。

将来のデータ更新が使えるか、最小のプログラムの変更で他のデータが使えるための十分な拡張性もあるべきです。

[注記]

関数が確実に動作するために、tigerスキーマは、データベース検索パスに追加されていなければなりません。

Drop_Indexes_Generate_Script — tigerスキーマとユーザが指定したスキーマ上の、全ての主キーでなく、かつユニークでないインデックスを削除します。スキーマを指定しない場合のデフォルトスキーマは、tiger_dataです。
Drop_Nation_Tables_Generate_Script — 指定したスキーマ内のテーブルのうち、county_all, state_allまたは、county or stateを削除するスクリプトを生成します。
Drop_State_Tables_Generate_Script — 指定したスキーマ内の、名前が州コードから始まるテーブルを全て削除するスクリプトを生成します。スキーマが指定されていない場合のデフォルトスキーマはtiger_dataです。
Geocode — 住所を文字列 (もしくは他の正規化された住所)として取り、可能性のある位置の集合を返します。返される集合の