(地理情報システム)オブジェクトを格納することができます。PostGISは、GiSTベースのR木空間インデクスをサポートし、GISオブジェクトの解析および処理を行う機能を持ちます。本マニュアルは、3.0.0版のマニュアルです。ライセンスの下に提供されています。クレジット提示を求めます。可能な限りhttp://postgis.netへのリンクを求めます。Modelまたは略してDE-9IMを見てみましょう。他の貢献者PostGISは、PostgreSQLリレーショナルデータベースに空間拡張を施すものです。Incが、空間データベース技術の研究プロジェクトとして開発しました。Refractionsはカナダ・ブリティッシュコロンビア州・ビクトリアにある、データインテグレーションとカスタムソフトウェア開発に特化した、GISとデータベースのコンサルティング会社です。PostGISはOSGeo財団のプロジェクトです。PostGISは、多数のFOSS4G開発者と、PostGISの機能と多彩さから大きな利益を得る世界中の企業によって継続的に改善され、資金を得ています。(カバレッジ、サーフェス、ネットワーク)、GISデータの表示と編集を行うデスクトップユーザインタフェースツール、およびウェブベースのアクセスツールのためのデータソースに、より良く対応するよう、サポートと機能強化を行う予定です。PSC)は、総合的な指示、リリースサイクル、ドキュメンテーション、支援活動に関する調整を行っています。開発者のコミットのアクセス、新しい委員、APIの重要な変更といった、PostGISを含む雑多な問題に関する投票を行っています。大きなコード変更のスモークテスト。Windows他)での試験。(委員長)PostGISプロジェクトの副創始者。(開発中)、GEOS機能の統合とGEOSリリースとの調整、PostgreSQLのリリースとの調整、ローダ/ダンパ、シェープファイルGUIローダ。Santilli誤り修正とメンテナンス、gitミラーの管理、新しいGEOS機能のメンテナンス、GEOSリリースとの調整、トポロジ機能、ラスタフレームワークと低水準API関数。Arévaloラスタ開発、GDALドライバ機能、ローダ。開発中)と一般的なユーザサポート。GML)/GeoJSON入出力関数と3次元サポートとバグフィクス。Tile関数とGeoBuf関数、Gogsの試験とGitLabの実験。LoskotPostGISのCMakeサポート。オリジナルのPython版ラスタローダ低水準ラスタAPI関数の以前の開発。Botのメンテナンス。Racineラスタ全体のアーキテクチャ、プロトタイピング、プログラミング支援。Cave-Ayland誤り修正とメンテナンスの調整、空間インデクスの選択とバインディング、ローダ/ダンパ、シェープファイルGUIローダ、新機能の統合と強化。Hodgson以前のPSCメンバ。一般的な開発、サイトとBuildbotのメンテナンス、OSGeoインキュベーション管理。Neufeld以前のPSCメンバ。文書と文書補助ツール、Buildbotのメンテナンス、PostGISニュースグループでの高度なユーザサポート、PostGISメンテナンス機能の強化。BlasbyPostGISのオリジナルの開発/副創始者。サーバサイドのオブジェクト、インデクスのバインディングや多数のサーバサイドの解析機能を記述。Lounsburyシェープファイルのローダ/ダンパのオリジナルの開発者。現在のPostGISプロジェクトオーナーの代表。Leslie中核機能の、継続的なメンテナンスと開発。シェープファイルGUIローダ。(ほとんど地図代数解析関数)。Bay企業PostGISプロジェクトへの開発時間、ホスティング、直接的な金銭提供の貢献を行った企業です。Systemsクラウドファンディングキャンペーンクラウドファンディングキャンペーンは、PostGIS開発チームが走らせているキャンペーンです。欲しくて仕方ない機能に資金を与えて、多数の人々にサービスを提供できるようにするためのものです。それぞれのキャンペーンでは、特定の機能または機能の集合に焦点があてられます。それぞれのスポンサーは、必要な資金提供のうち少しだけを提供し、十分な人/組織の寄付で、たくさんの助けになる作業に支払う基金を持ちます。newsgroupに、その考えを投稿して下さい。2.0.0はこの戦略を実施する最初のリリースです。PledgeBankを使い、2件のキャンペーンが成功しました。10以上のスポンサーがTopoGeometry機能の構築と2.0.0でのトポロジ対応強化とのために、それぞれ250米ドルを寄付しました。64ビット版に必要な作業のために、それぞれ100米ドルを寄付しました。2.0.1ができ、PostgreSQLスタックビルダで使用可能なリリースを予定している最終版ができました。Warmerdamらによります。2.0.0で導入されたラスタ機能で、非常によく使われています。同じように、PostGISサポートに関するGDALの必要な改善でGDALプロジェクトに貢献しています。PostGISはこの巨人の肩に乗っています。PostGISの速度と柔軟性はPostgreSQLが提供する拡張性、偉大なクエリプランナ、GiSTインデクス、多数のSQL機能がないと成り立ちません。ローダ/ダンパ本章では、PostGISのインストールに必要な手順について説明します。全ての依存がパスに入っているとする場合、次のようにコンパイルします。installPostGISをインストールした後は、利用したいデータベース個々内で利用可能にする必要があります。“PostGISエクステンションのビルドとデプロイ”を参照して下さい。なんらかの理由で、ラスタ機能なしでコンパイルするか古いやり方でインストールする場合には、より長く、より苦痛を伴いますが、やり方はあります。インストールされた.sqlファイルは全てPostgreSQLがインストールされているフォルダ内のshare/contrib/postgis-3.0の中にあります。2.1.3では、データベース外ラスタと全てのラスタドライバは、デフォルトでは無効になっています。これらを有効にするには、サーバ上で、環境変数POSTGIS_GDAL_ENABLED_DRIVERSとPOSTGIS_ENABLE_OUTDB_RASTERSを設定します。Custom)変数”に従って設定する、クロスプラットフォームな手法があります。データベース外ラスタを有効にするには次のようにします。POSTGIS_ENABLE_OUTDB_RASTERS=1他の値を入れたり、値を入れない場合には、データベース外ラスタは無効になります。インストールしたGDALのドライバを有効にするには、次の環境変数を設定します。POSTGIS_GDAL_ENABLED_DRIVERS=ENABLE_ALL一部のドライバのみ有効にしたい場合には、環境変数を次のように設定します。XYZ"Windows上の場合は、ドライバリストに引用符をつけないで下さい。環境変数の設定はOSによって変わります。UbuntuやDebian上でapt-postgresqlからインストールしたPostgreSQLの場合には、/etc/postgresql/10/main/environmentを編集するのが好まれます。10はPostgreSQLの版を指し、mainはクラスタを示します。Windowsでサービスとして実行している場合には、システム変数で設定します。パネル項目\システムを指定します。環境変数を順にクリックして、新しいシステム環境変数を追加します。環境変数を設定した後は、設定を反映させるために、PostgreSQLサービスの再起動が必要です。インストール要件PostGISのビルドと利用のために、次のものが必要です。(サーバヘッダを含む)が必要です。http://www.postgresql.org/にあります。完全なPosgreSQL/PostGIS対応表とPostGIS/GEOS対応表についてはhttp://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGISをご覧ください。Cコンパイラの中には、PostGISをコンパイルできるものもありますが、gccでコンパイルするのが最も問題が少ないと見ています。(gmakeまたはmake)。makeがデフォルトのmakeになっています。-vを実行して版を確認して下さい。他版のmakeでは、PostGISのMakefileを完全に処理しきれないかもしれません。4.9以上が必要です。Proj4は、http://trac.osgeo.org/proj/からダウンロードできます。4.9以上が必要です。Proj4は、http://trac.osgeo.org/proj/からダウンロードできます。LibXML2の2.5.x以上。(ST_GeomFromGMLとST_GeomFromKML)で使っています。LibXML2はhttp://xmlsoft.org/downloads.htmlからダウンロード可能です。JSON-Cは現在、ST_GeomFromGeoJsonによるGeoJSONの取り込みに使われます。JSON-Cはhttps://github.com/json-c/json-c/releases/からダウンロード可能です。(古い版では一部機能が働かなかったり挙動が異なるので1.9以上を強く推奨します)。postgisでのインストールに必要となります。9.1以上での使用では非常に推奨されますhttp://trac.osgeo.org/gdal/wiki/DownloadSource/からダウンロード可能です。このパラメータは現在のところ壊れていて、PostgreSQLのインストール先にしかインストールされません。このバグのトラックについてはhttp://trac.osgeo.org/postgis/ticket/635をご覧ください。“簡略版”を参照してください。シェープファイルのローダであるshp2pgsql-guiのコンパイル用です。http://www.gtk.org/にあります。追加的な2次元や3次元の高度な解析関数をPostGISで使うために使用するものです。“SFCGAL関数”をご覧下さい。(たとえばST_IntersectionやST_Area)は、GEOSでなくSFCGALを使用することができます。(デフォルトではGEOS)。(http://oslandia.github.io/SFCGAL/installation.htmlをご覧下さい)が必要ですのでご注意下さい。https://github.com/Oslandia/SFCGALにあります。(Unix系システムには通常はインストール済みです)も必要です。CPANのRegex::Assembleパッケージのみ必要です。住所標準化は、PCREライブラリを検出するか、コンフィギュレーションで適切に--with-pcre-dir=/path/to/pcreを指定すると、自動的にビルドされます。(ビルド時)が必要です。protobuf-cの正しい最小版を確認するには、pkg-configが必要です。protobuf-cをご覧下さい。レグレッションテストに必要です。http://cunit.sourceforge.net/にあります。(xsltproc)。文書のビルドに必要です。http://www.docbook.org/にあります。文書をPDFでビルドするのに必要です。http://dblatex.sourcforge.net/にあります。文書で使う画像を生成するのに必要です。http://www.imagemagick.org/にあります。ソースの取得ダウンロードサイトhttp://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzからソースのアーカイブを入手します。postgis-3.0.0.tar.gzこれで、カレントディレクトリの下にpostgis-3.0.0ができます。svnレポジトリhttp://svn.osgeo.org/postgis/trunk/からチェックアウトします。postgis-3.0.0新しく作られたpostgis-3.0.0ディレクトトリに移動して、インストールを続けます。インストール多くのOSで、ビルドされたPostgreSQL/PostGISパッケージがあります。多くの場合、コンパイルが必要なのは、最もひどい最先端の版が欲しい場合やパッケージメンテナンスを行う人ぐらいです。本節では、一般的なコンパイル手順を示します。Wikiで、より詳細な助けが見つかるかも知れません。Packagesにあります。siteから安定版を得ることができます。buildsもあります。これらはPostGISの進行中のリリースでの試験に使用します。PostGISモジュールは、PostgreSQLバックエンドサーバの拡張です。3.0.0では、コンパイルのために、完全なPostgreSQLサーバヘッダが必要です。3.0.0以上でビルドできます。古い版のPostgreSQLはサポートされません。PostgreSQLをインストールしていないならPostgreSQLインストールガイドを参照して下さい。http://www.postgresql.org/にあります。GEOS機能を有効にするために、PostgreSQLをインストール時に明示的に標準C++ライブラリに対する明示的なリンクが必要になる場合があります。[コンフィギュアオプション]これは、古い開発ツールとインチキC++例外との対話のための応急処置です。(望んでいないのにバックエンドが閉じたりそれに近い挙動を起こす)を経験したなら、このトリックを試してみて下さい。これを行うにはPostgreSQLをはじめからコンパイルし直す必要があります。次のステップでは、PostGISソースのコンフィギュレーションとコンパイルに概要を記述します。これらは、Linuxユーザ用に書いてありますので、WindowsやMacでは動作しません。コンフィギュレーションほとんどのLinuxのインストールと同様に、最初のステップでは、ソースコードのビルドに使われるMakefileを生成します。これは、シェルスクリプトが行います。./configureパラメータを付けない場合には、このコマンドは自動で、PostGISのソースコードのビルドを行うのに必要なコンポーネントやライブラリをシステム上で探します。./configureとするのが一般的な使い方ですが、標準的でない位置に必要なライブラリやプログラムを置いてある場合のために、いくつかのパラメータを受け付けます。次のリストで、共通して使われるパラメータを示します。完全なリストについては、--helpまたは--help=shortパラメータを使って下さい。statement.--prefix=PREFIXPostGISライブラリとSQLスクリプトのインストール先を指定します。デフォルトでは、検出されたPostgreSQLのインストール先と同じになります。このパラメータは現在のところ壊れていて、PostgreSQLのインストール先にしかインストールされません。このバグのトラックについてはhttp://trac.osgeo.org/postgis/ticket/635をご覧ください。--with-pgconfig=FILEPostgreSQLは、PostGISなどの拡張に対してPostgreSQLのインストール先ディレクトリを伝えるpg_configというユーティリティを持っています。PostGISの対象とする特定のPostgreSQLのインストール先を手動で指定する場合に、このパラメータ(--with-pgconfig=/path/to/pg_config)を使います。--with-gdalconfig=FILE必須ライブラリであるGDALは、ラスタ機能に必要な機能を提供します。GDALには、インストール先ディレクトリをインストールスクリプトに伝えるgdal-configがあります。(--with-gdalconfig=/path/to/gdal-config)を使います。--with-geosconfig=FILE必須のジオメトリライブラリであるGEOSには、ソフトウェアのインストール時にGEOSのインストール先ディレクトリを伝えるgeos-configというユーティリティがあります。(--with-geosconfig=/path/to/geos-config)を使います。--with-xml2config=FILELibXMLはGeomFromKML/GML処理を行うのに必須のライブラリです。通常はlibxmlをインストールしているなら発見されますが、発見できない場合や特定の版を使用したい場合は、xml2-configを指定してインストールスクリプトにLibXMLのインストール先ディレクトリを伝えます。>--with-xml2config=/path/to/xml2-config)を使います。--with-projdir=DIRProj4はPostGISに必須の投影変換ライブラリです。(--with-projdir=/path/to/projdir)を使います。--with-libiconv=DIRiconvのインストール先ディレクトリを指定します。--with-jsondir=DIRJSON-Cは、MITライセンスのJSONライブラリで、PostGISのST_GeomFromJSONに必須です。(--with-jsondir=/path/to/jsondir)を使います。--with-pcredir=DIRPCREは、BSDライセンスのPerl互換正規表現ライブラリです。住所標準化エクステンションに必須です。(--with-pcredir=/path/to/pcredir)を使います。(GTK+2.0が必要)をコンパイルします。このパラメータによって、shp2pgsql-guiという、shp2pgsqlのグラフィカルユーザインタフェースが作成されます。--without-rasterラスタ機能をインストールします。--without-topologyトポロジ対応を無くしてコンパイルします。トポロジに必要なロジックは全てpostgis-3.0.0ライブラリ内に作られるので、関連ライブラリはありません。--with-gettext=noデフォルトでは、gettextの検出とこれを用いたコンパイルを試みますが、ローダ破損を引き起こす非互換性問題のもとで実行する場合には、このコマンドで無効にできます。これを使ったコンフィギュレーションによって解決する問題の例はhttp://trac.osgeo.org/postgis/ticket/748にあります。これを切ることで多くの機能がなくなるわけではありません。文書化されていなくて試験段階であるGUIローダにおける内部のヘルプ/ラベル機能に使われています。--with-sfcgal=PATHデフォルトでは、このスイッチなしではSFCGAL対応でインストールされません。PATHは、sfcgal-configへのパスを指定することができる追加的な引数です。instead.PostGISをSVNレポジトリから得る場合には、はじめに次のスクリプトを実行します。./autogen.shこのスクリプトによってconfigureスクリプトが生成されます。これはPostGISのインストールに関するカスタマイズに使われます。PostGISをアーカイブファイルで入手する場合には、configureが既に生成されているので./autogen.shは不要です。ビルドMakefileが生成されたら、PostGISのビルドは、次のコマンドを実行するだけです。install."と出れば終わりです。1.4.0版からは、全ての関数に文書から生成されるコメントが付きます。これらのコメントを後からインストールするには、次のコマンドを実行しますが、docbookが必要です。topology_comments.sqlは、docフォルダにあるので、コメントを作成する必要はありません。EXTENSIONによるインストールの一部として取り込まれます。2.0で導入されました。早見表に、または学習中の方のハンドアウトに適しているHTMLチートシートを生成します。postgis_cheatsheet.htmlの4ファイルが生成されます。Guidesにあります。9.1以上を使用している場合は、PostGISエクステンションが自動的にビルド、インストールされます。ソースレポジトリからビルドしている場合は、関数の記述を最初にビルドする必要があります。これらは、docbookがインストールされている時にビルドされます。手動でインストールするには次のようにします。commentsアーカイブファイルからのビルドの場合は、ビルド済みのものがあるので、コメントのビルドは必須ではありません。install処理の一部としてビルドするべきです。必要ならextensionsフォルダからビルドできますし、他のサーバで必要ならファイルの複製ができます。variablesエクステンションファイルは、OSに関係なく、常に同じ版のPostGISと同じです。PostGISバイナリを既にインストールしている限りは、エクステンションファイルをあるOSから別のものに複写して大丈夫です。extensionフォルダに複写します。postgis_topology.control。エクステンションごとの/sqlフォルダにあるファイル全て。share/extensionフォルダの最上位に複写する必要があることに注意して下さい。postgis_topologyが有効なエクステンションとして見えます。psqlを使う場合は、次のクエリを実行してエクステンションがインストールされていることを確認できます。rows)クエリを行ったデータベースにエクステンションがインストールされている場合は、installed_versionカラムに記載が見えます。EXTENSIONがインストールされていないことになります。1.14以上では、データベースブラウザツリーのextensionsセクションで提供されていて、右クリックでアップグレードまたアンインストールできます。有効なエクステンションがある場合、pgAdminエクステンションインタフェースまたは次のSQLの実行によって、選択したデータベースにPostGISエクステンションをインストールできます。postgis_topology;psqlでは、どの版が、どのスキーマにインストールされているかを見ることができます。topologyは、明示的にバックアップできません。それぞれのpostgisまたはpostgis_topologyエクステンションがバックアップされる時のみバックアップできます。これは、データベース全体のバックアップの時のみ行われます。2.0.1の時点では、データベースがバックアップされる際に、PostGISでパッケージ化されていないsridレコードのみバックアップされます。パッケージに入っているsridの変更は巡回せず、変更はそこにあるものと期待されます。2.0.1の時点では、データベースがバックアップされるときにPostGISに入っていないsridのレコードだけがバックアップされます。PostGISに入っていて後に変更されたsridの変更については巡回しません。問題が見られたら、チケットを発行して下さい。EXTENSIONで生成されるので、バックアップを行いません。エクステンションの与えられた版と同じものであると仮定されます。エクステンションモデルに組み込まれているため、これについては何もできません。この素晴らしいエクステンション機能を使わずに3.0.0をインストールした場合でもエクステンションベースに変更することができます。テストPostGISのテストを行うには、次のコマンドを実行します。checkこのコマンドで、実際のPostgreSQLデータベースに対して生成したライブラリを使用した、様々なチェックとレグレッションテストを行います。標準の位置にインストールしていない場合には、環境変数LD_LIBRARY_PATHに、ライブラリの位置を追加する必要があるかも知れません。環境変数PATHとPGPORTによっています。コンフィギュレーションパラメータ--with-pgconfigを使って特定したPostgreSQLではありません。PATHを編集して、コンフィギュレーションの際に検出したPostgreSQLと一致するようにして下さい。間もなく襲ってくる頭痛の準備をしておいて下さい。成功した場合は、テストの出力は次のようなかんじになります。n/apostgis_tiger_geocoderとaddress_standardizerは、現在は、標準的なPostgreSQLインストールチェックにのみ対応しています。これらをテストするには、次のようにします。installは重要ではありません。installcheck出力は次のようなかんじになります。Geocodeを使う場合には、使用するPostgreSQLインスタンス内にPostGISとfuzzystrmatchのエクステンションが必要です。PostGISをaddress_standardizer機能付きでビルドした場合は、address_standardizerのテストも行います。installcheck出力は次のようなかんじになります。インストールPostGISをインストールするには、次のコマンドを実行します。installこれにより、PostGISのインストールファイルが、--prefixパラメータで指定した、適切なサブディレクトリに複写されます。次に特筆すべきサブディレクトリを示します。ローダとダンパのバイナリのインストール先は[prefix]/binです。postgis.sqlなどのSQLファイルのインストール先は[prefix]/share/contribです。PostGISライブラリのインストール先は[prefix]/libです。raster_comments.sqlを生成していた場合は、次のコマンドを実行すると、これらのSQLファイルがインストールされます。topology_comments.sqlは、xsltprocの外部依存ができたので、通常のビルドとインストールから切り離されました。9.1以上を使っていて、extensions/postgisモジュールをコンパイルとインストールを行っている場合は、新しい方法で空間データベースを生成できます。[データベース名]PostGISエクステンションの中核によって、ジオメトリ、ジオグラフィ、ラスタ、spatial_ref_sysおよび全ての関数とコメントがインストールされます。次のコマンドを実行するだけです。postgis;"トポロジは別のエクステンションとして用意されています。次のコマンドでインストールします。postgis;"トポロジは別のエクステンションとして用意されています。次のコマンドでインストールします。postgis_topology;"以前の版の古いバックアップを新しいデータベースにリストアする予定の場合には、次を実行します。legacy.sqlレガシー関数が必要なら、PostGISのマイナーバージョンのアップグレードならいつでも、legacy.sqlスクリプトの再インストールが必要です。2.4.3から2.5.0にアップグレードした場合には、2.5.0のlegacy.sqlの再インストールが必要です。関数の中にライブラリへの参照を作るものがあり、ライブラリ名にマイナー版番号を含むためです。リストアとクリーンアップを行った後で非推奨関数を消すためにuninstall_legacy.sqlを実行できます。environment).PostGISデータベースを作る最初のステップは、単純なPostgreSQLデータベースの作成です。[データベース名]多くのPostGIS関数は、PL/pgSQL手続き言語で書かれています。次のステップは、PL/pgSQL言語を新たに作成したデータベースで有効にすることです。次のコマンドを実行します。8.4以上では、通常は既にインストールされています。[データベース名]次に、PostGISオブジェクトと関数定義をデータベースにロードします。定義ファイルpostgis.sql(コンフィギュレーション段階で指定した[prefix]/share/contribにあります)をロードします。postgis.sql完全なEPSG座標系定義IDセットについては、spatial_ref_sys.sql定義ファイルをロードしてspatial_ref_sysテーブルを生成して下さい。これによりジオメトリ関数ST_Transform()が実行できるようになります。spatial_ref_sys.sqlPostGISが持つ関数についての助けとなるコメントを求めるなら、postgis_comments.sqlを、データベースにロードします。[function_name]とすれば見ることができます。ロードは次のようにします。postgis_comments.sqlラスタ機能をインストールします。rtpostgis.sqlラスタ機能のコメントをインストールします。ラスタ関数ごとの簡易説明が提供されます。psqlまたはpgAdmin等の関数コメントを表示できるPostgreSQLツールで使えます。raster_comments.sqlトポロジ機能をインストールします。topology/topology.sqlトポロジ機能のコメントをインストールします。トポロジ関数/型ごとの簡易説明が提供されます。psqlまたはpgAdmin等の関数コメントを表示できるPostgreSQLツールで使えます。topology/topology_comments.sql以前の版の古いバックアップを新しいデータベースにリストアする予定の場合には、次を実行します。legacy.sqlテーブルを回復し、MapServerやGeoServerのようなアプリケーションで動作させるのに必要な最低限をインストールするにはlegacy_minimal.sqlという選択肢があります。distance/length等のようなものを使うビューがあるなら、完全なlegacy.sqlが必要になります。リストアとクリーンアップを行った後で非推奨関数を消すためにuninstall_legacy.sqlを実行できます。Regex::Assembleのインストールaddress_standardizerエクステンションは、別途ダウンロードする必要がある別パッケージとしていました。2.2からは同梱されています。住所標準化をご覧下さい。標準化エクステンションは、Normalize_Addressの後継で、PostGISに入っているTigerジオコーダエクステンションに使うことができます。エクステンションを使用”を参照して下さい。ユーザ自身がつくるジオコーダの要素として使用したり、住所の比較を簡単にするために住所を標準化するために使うことができます。住所標準化エクステンションはPCREに依存しています。PCREは多くのUNIX系システムにインストールされていますが、http://www.pcre.orgから最新版をダウンロードできます。“コンフィギュレーション”の際にPCREを発見すると、住所標準化エクステンションが自動的にビルドされます。使用したいPCREのインストールが独自なものである場合は、configureに--with-pcredir=/path/to/pcreを渡します。/path/to/pcreは、PCREのincludeとlibのあるルートフォルダです。EXTENSIONに行くことができます。インストールしたら、対象データベースに接続して次のSQLが実行できます。lexテーブルは必要ありません。02109');出力は次のようになります。Regex::AssembleのインストールPerlのRegex::Assembleは、ソースツリーの一部がこれで作られていますが、住所標準化エクステンションではもはや不要です。usps-st-city-adds.txを編集する必要がある場合は、parseaddress-stcities.hのリビルドでRegex:Assembleが必要です。Degianの場合には、次のようにしなければならないかも知れません。TigerジオコーダのアップグレードTigerジオコーダのような拡張機能はPostGISディストリビューションに同梱されていません。Versions節でPostgreSQLの版に合ったパッケージにあるshare/extension/postgis_tiger_geocoder.*ファイルを使います。これらのパッケージはWindows用ですが、postgis_tige_geocoderエクステンションファイルは、SQLとPL/pgSQLだけですので、他のOSでも動作します。2.1.0を使用している場合は、Tigerジオコーダのインストールで、新しいエクステンションモデルの利点を得ることができます。2.1.0のバイナリを取得するか、コンパイルしてインストールします。これにより重要なエクステンションファイルとTigerジオコーダのファイルがインストールされます。psql、pgAdminまたは他のツールでデータベースに接続して、次のSQLコマンドを実行します。PostGISを持っているデータベースにインストールする場合は、一つ目の手順は不要です。fuzzystrmatchエクステンションが既にインストールされている場合は、二つ目の手順は不要です。address_standardizer;既にpostgis_tiger_geocoderエクステンションをインストールしていて、最新版に更新するだけの場合には、次を実行します。UPDATE;独自のエントリを生成した場合や、tiger.loader_platformとtiger.loader_variablesに変更を加えた場合には、これらをアップデートしなければならないことがあります。インストールされたかを確認するために、インストール対象データベース内で次のSQLを実行します。na;出力は次のようになります。02109tiger.loader_platformテーブルの、実行ファイルやサーバのパスを持つ新しいレコードを生成します。shコンベンションのあとにdebbieというプロファイルを生成する例として、次のコマンドを実行します。psql他のパス位置に適応するようにします。loader_platformテーブルを編集しない場合は、一般的なアイテムの位置を持っているので、スクリプトが生成された後で、スクリプトを編集しなければなりません。Area)のロード手順が変更され、有効になった時にLoader_Generate_Nation_Scriptの一部として現在のZCTA5データをロードするようになりました。デフォルトでは切られています。(20から60分)が取られ、かなりのディスクスペースを占有するのに、そんなに頻繁には使わないためです。有効にするには、次のようにします。'zcta510';境界のフィルタが追加され、ちょうど境界内のZIPに制限された場合に、Geocode関数は、ZCTA5が存在するなら使います。(しばしば高速道路での逆ジオコーディングで発生します)、これを使います。(サーバへのネットワーク接続が早い場合)のルートにgisdataというフォルダを作成します。このフォルダはTigerファイルがダウンロードされ、処理される場所です。サーバのルートにフォルダを作ると不幸になる場合や、単に他のフォルダに移したい場合には、tiger.loader_variablesテーブルのstaging_foldフィールドを編集します。gisdataフォルダ内にtempというフォルダを作成します。staging_foldで示されたフォルダを作成します。ローダがダウンロードしたTigerデータを展開する場所です。SQL関数Loader_Generate_Nation_Scriptを実行して、独自のプロファイルの名前を使うか確認し、.shまたは.batファイルにスクリプトを複写します。新しいプロファイルで国のロードを行う場合には、次のようにします。/gisdata/nation_script_load.sh生成された国データをロードするコマンドラインスクリプトを実行します。nation_script_load.sh国スクリプトを実行した後、tiger_dataスキーマに三つのテーブルが作られ、データが格納されています。次のクエリをpsqlかpgAdminから実行して、確認します。tabblockに対応するテーブルはロードされません。ジオコーダはこれらのテーブルを使いませんが、一般に、人口統計に使います。州データのロードの一部としてロードするには、次の手続きを実行して有効にします。'tabblock');もしくは、Loader_Generate_Census_Scriptを使って州のデータをロードした後に、これらのテーブルだけをロードできます。データをロードしたい州ごとに、Loader_Generate_Scriptで州スクリプトを作ります。国データのロードを完了する前に*州スクリプトを作ってはなりません*。州スクリプトは国スクリプトでロードされる国リストを利用するためです。/gisdata/ma_load.sh生成されたコマンドラインスクリプトを実行します。ma_load.sh全てのデータのロードが完了するか中断ポイントに達した後に、全てのtigerテーブルに対してanalyzeを実行して、(継承されたものも含めて)状態を更新するのは良いことです。Tigerジオコーダ通常インストールのエクステンションモデルへの変換エクステンションモデルを使わずにTigerジオコーダをインストールしている場合に、次のようにして、エクステンションモデルに変換できます。“Tigerジオコーダのアップグレード”の指示に従って非エクステンションモデルのアップグレードを行います。psqlまたはpgAdminでデータベースに接続して、次のコマンドを実行します。エクステンション不使用まず、上述の手順でPostGISをインストールします。extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzをダウンロードします。(違う年のものをロードしたくないならば最新のローダファイル)をあなたの実行サーバ等のパスに編集します。loader_platformがインストールされた後に一度これを更新します。このファイルもloader_platformも編集しない場合には、一般的なアイテムの位置を持っているだけなので、Loader_Generate_Nation_ScriptとLoader_Generate_Scriptを実行した後に、生成されたスクリプトを編集しなければなりません。OSXではcreate_geocode.shを、使用するPostgreSQLにとって独自の設定に変更したうえで、コマンドラインから対応するスクリプトを実行します。データベースにtigerスキーマがあることを確認します。無い場合は、次の行を参考に、コマンドを実行します。tiger;住所正規化機能は、トリッキーな住所を除いて、大体データなしで動作します。テストを実行して次のように見えることを確認して下さい。皆さんが問題と思われるの多くのことのひとつに、ジオコーディング前の準備に住所を正規化する関数Normalize_Addressがあります。住所正規化は万全と言うにはほど遠く、パッチをあてようとすると膨大な資源を費やします。よって、より良い住所標準化エンジンを持つ他のプロジェクトに統合しました。“PAGC住所標準化ツールのインストールと使用”で記述するようにエクステンションをコンパイルし、使用するデータベースにインストールします。タイプ、番地、ストリート名等を複数フィールドに分解して持つnorm_addy複合型を返します。(Tigerデータは不要です)。住所標準化エクステンションが必要です。Normalize_Addressの代わりに使うことができます。このエクステンションはTigerジオコーダからは見えないので、国際的な住所といった他のデータソースでも使えます。(tiger.pagc_lex)を同梱しています。これらは、必要に応じて標準化の改善のために追加や更新ができます。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インストール時にデフォルトでインストールされます。通常はほとんどの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();を実行するようにして下さい。行うべきことができたかをテストするために、Geocodeを使用する州の中の住所についてジオコーダを実行してみます。Tigerジオコーダのアップグレード2.0以上に含まれるTigerジオコーダがインストールされている場合には、どうしても必要な訂正があるときは、いつでも臨時のアーカイブファイルからでも機能のアップグレードができます。これは、エクステンションでインストールされていないTigerジオコーダで動作します。extrasフォルダが無い場合、http://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gzをダウンロードします。Xの場合はupgrade_geocoder.shスクリプトの位置を特定します。PostGISデータベースの資格情報を持つように編集します。2010または2011からアップグレードする場合には、確実にローダスクリプトのコメントアウトを消すと、2012データのロードのための最新のスクリプトを得ます。対応するスクリプトをコマンドラインから実行します。次に、全ての国テーブルを削除し、新しい国テーブルをロードします。Drop_Nation_Tables_Generate_Scriptに詳細がある通り、このSQLステートメントを使った削除スクリプトを生成します。drop_nation_tables_generate_script();生成した削除SQLステートメントを実行します。Loader_Generate_Nation_Scriptに詳細がある通り、このSELECTステートメントを使った削除スクリプトを生成します。“Tigerデータのロード”を参照して下さい。これは一度だけ実行する必要があります。2010/2011州テーブルを混在させることができ、それぞれの州について個別にアップグレードできます。2011にアップグレードする前に、まず、Drop_State_Tables_Generate_Scriptを使って、2010州テーブルを削除します。1.1.5のWin32インストーラ)の中には、template_postgisというテンプレートにPostGIS関数をロードしていることがあります。PostgreSQLにtemplate_postgisデータベースが存在するなら、ユーザやアプリケーションは、空間データベースの生成をコマンドひとつで済ませられます。この2種類のやり方のどちらを使うににしても、データベースユーザは、新しいデータベースを作成する権限を与えられている必要があります。シェルからの実行は次の通りです。my_spatial_dbSQLからの実行は次の通りです。ハードアップグレード既存の空間データベースのアップグレードは、新しいPostGISオブジェクト定義の置き換えや導入を必要とするとき、慎重を要することがあります。不幸なことに、定義の全てが実行中のデータベース内で簡単には置き換えられるわけではないので、ダンプ/リロードが最善策となることがあります。PostGISには、マイナーバージョンアップやバグフィクスリリースの場合に使うソフトアップグレードと、メジャーアップグレードで使うハードアップグレードが用意されています。PostGISをアップグレードしようとする前にデータのバックアップを取ることは、常に価値のあるものです。フラグを使うと、ハードアップグレードによってダンプを常にリストアすることができます。9.1以上でエクステンションを使ったソフトアップグレードエクステンションを使ってインストールした場合は、エクステンションモデルでアップグレードしなければなりません。古いSQLスクリプトを使ってインストールした場合は、SQLスクリプトでアップグレードすべきです。適切な方を参照して下さい。9.1より前またはエクステンションを使わないソフトアップグレードPostGISをエクステンションを使わずにインストールした人向けです。エクステンションを使っていてこの方法を使うと、次のようなメッセージが現れます。[データベース名]ラスタ機能とトポロジ機能についても同じ手続きです。それぞれrtpostgis_upgrade*.sqlとtopology_upgrade*.sqlとになります。[データベース名]アップグレードのための特定の版のpostgis_upgrade*.sqlが見つからない場合は、非常に古い版を使っています。ハードアップグレードが必要です。upgrade"というメッセージで、この種のアップグレードを実行する必要性についての情報が得られます。9.1以上でエクステンションを使ったソフトアップグレードエクステンションを使ってPostGISをインストールした場合には、エクステンションを使ってアップグレードする必要があります。エクステンションを使ったマイナーアップグレードはかなり楽です。"3.0.0";次のようなエラー通知が表示されることがあります。“エクステンションを使った空間データベースの生成”に記述されているように新しいデータベースを生成し、バックアップを新しいデータベースにリストアしなければなりません。次のようなメッセージを得ることがあります。installedこの場合は、全てアップデートされていて、安全に無視できます。SVN版から次版(新しい版番号を得ていないもの)にアップグレードしようとしない限り、"next"を版文字列に追加できます。次回に"next"を削除する必要があります。EXTENSIONの再インストールをとばすことができます。postgisだけで、リストアの間に最新版になります。ハードアップグレードハードアップグレードとは、PostGISで利用可能なデータの完全なダンプ/リロードを意味します。PostGISオブジェクトの内部格納状態が変更される場合や、ソフトアップグレードができない場合に、ハードアップグレードが必要です。(ハードアップグレード)の要否を記載しています。ダンプ/リロード作業はpostgis_restore.plスクリプトが補助します。(古いものを含む)に属する定義を全て飛ばすように注意します。重複シンボルエラーや非推奨オブジェクトを持越すことなく、スキーマとデータをPostGISをインストールしたデータベースにリストアできます。upgradeにあります。手続きは次の通りです。(-v)で生成します。ユーザはデータベースのオーナーになることができ、PostgreSQLのスーパーユーザである必要はありません。olddb新しいデータベースにPostGISを、PostGISが無い状態からインストールします。このデータベースをnewdbと呼ぶことにします。“エクステンションを使った空間データベースの生成”とを参照して下さい。ダンプにあるspatial_ref_sysは、リストアされますが、既にあるspatial_ref_sysを上書きしません。リストア対象のデータベースに公式データセットの訂正が確実に伝わるようにするためです。標準のエントリを上書きしたい場合は、newdbを生成する際にspaltial_ref_sys.sqlファイルをロードしないだけです。データベースが本当に古く、ビューや関数に、長く非推奨になっている関数があるような場合には、関数やビューを使えるようにするlegacy.sqlをロードする必要があるでしょう。本当に必要な場合に限ります。可能なら、ビューや関数をダンプせずにアップグレードすることを検討して下さい。非推奨関数は、uninstall_legacy.sqlで後から削除することができます。バックアップを新しいnewdbデータベースにリストアするには、postgis_restore.plを使います。psqlが予期せぬエラーを標準エラー出力に出すことがあります。これらのログを保存しておいて下さい。errors.txtエラーは次の場合に起こりえます。関数の中に非推奨のPostGISオブジェクトを使っているものがある場合。これの訂正には、リストア前にlegacy.sqlスクリプトのロードを試してみることができます。非推奨オブジェクトをまだ持っている版のPostGISにリストアして、コードを作り替えた後に再び移動させることもできます。legacy.sqlを利用する場合は、非推奨関数を使うのをやめたコードに訂正して、uninstall_legacy.sqlをロードするのを忘れないでください。ダンプファイル内のspatial_ref_sysにあるカスタムレコードが不正なSRIDになっていることがあります。妥当なSRID値は0より大きく999000より小さくなります。999000から999999の間は内部利用のための予約領域ですが、999999より大きい値は一切使用できません。全ての不正なSRIDを持つ独自レコードは、予約領域に移動しても保持されます。spatial_ref_sysテーブルから、値が保持されるように設定されているチェック制約が外れます。(複数の不正なSRIDが同じ予約領域のSRID値に変換されるとき)、主キーも外れます。共通の問題インストールやアップグレードが思うようにいかない時にチェックすることがいくつかあります。9.5以上をインストールしているか、実行中のPostgreSQLと同じ版のソースでコンパイルしているか、をチェックします。混乱が発生することがあります。9.5以上で動作します。古い版のものを使った場合には、おかしな予想外のエラーメッセージが表示されます。実行中のPostgreSQLの版をチェックするには、psqlを使ってデータベースを接続して、次のクエリを実行して下さい。postgresqlでチェックできます。アップグレードに失敗する場合、既にPostGISがインストールされているデータベースにリストアしているか確認して下さい。postgis_full_version();また、コンフィギュアが正しくPostgreSQL、Proj4ライブラリ、GEOSライブラリのインストール先を検出したかチェックして下さい。コンフィギュアからの出力でpostgis_config.hファイルが作られます。POSTGIS_PGSQL_VERSION、POSTGIS_PROJ_VERSIONおよびPOSTGIS_GEOS_VERSION変数が正しくセットされたかをチェックして下さい。ローダ/ダンパデータのローダとダンパは、PostGISのビルドの一部として、自動的にビルド、インストールされます。手動でビルド、インストールするには、次を実行します。installローダはshp2pgsqlと呼ばれ、ESRIシェープファイルをPostGIS/PostgreSQLにロードするのに適したSQLに変換します。ダンパはpgsql2shpと呼ばれ、PostGISのテーブル(またはクエリ)からESRIシェープファイルに変換します。詳しいドキュメントをご覧になるには、オンラインヘルプとマニュアルページをご覧ください。2.0では動作しなくなりました。"gist"というエラーが発生しました。1.5では正しく動作していました。pgAdminを使ってジオメトリカラムを表示しようとしたら空っぽでした。ジオグラフィについて聞きたいです。ジオグラフィカラムにデータを入れて合理的な答えが得られる領域範囲はどれぐらいでしょうか、とか。2008はそう)、速度等の制限はあるのでしょうか、とか。ST_AsEWKTとST_AsTextとを、かなり大きいジオメトリで実行すると、空のフィールドが返りました。ST_Intersectsを使うと、二つのジオメトリがインタセクトしているのが分かっているのに、インタセクトしていないと言います。PostGISを用いたソフトウェアをリリースしています。PostGISを出しています。Suiteでの作業の入門編だけでなく梱包されたデータもあります。PostGISの最善のチュートリアルかも知れません。startedがあります。Windowsユーザに、より軸足を置いています。2.0では動作しなくなりました。2.0で、多数の非推奨関数がPostGISコードから削除されました。OpenJump等のサードバーティツールに加えて、アプリケーションにも影響が出ます。これを解決する方法が二つあります。サードパーティアプリケーションの場合は、これらの問題の多くが解決されている最新版にアップグレードしてみることで対応できます。ご自身のコードの場合は、削除された関数を使わないようにソースを変更することで対応できます。ST_Length等のエイリアスで、ST_を取ったものです。最後の手段としてlegacy.sqlの全体またはlegacy.sqlの必要な部分をインストールします。legacy.sqlファイルはpostgis.sqlのインストール先と同じフォルダにあります。postgis.sqlとspatial_ref_sys.sqlをインストールした後、このファイルをインストールすると、削除した200余の関数を復帰させられます。"gist"というエラーが発生しました。1.5では正しく動作していました。2では、デフォルトのジオメトリ演算子クラスがgist_geometry_opsからgist_geometry_ops_2dに変更され、gist_geometry_opsは完全に削除されました。2は3次元対応のためN次元空間インデクスを導入しました。古い名前は混乱させるものであり、誤称であると考えました。古いアプリケーションには、処理の一部として、テーブルやインデクスを生成する際に、明示的に演算子クラス名を参照しているものがありました。デフォルトの2次元インデクスが欲しい場合には重要ではありません。エラーが内容に管理するために、インデクス生成を次に示す悪い例から良い例に変えて下さい。gist(geom);演算子クラスを指定する必要が出るのは、3次元空間が求められる場合です。2.0.2以上に同梱されているlegacy_gist.sqlを使用して、古いクラスを生成することができます。この方法を使う場合は、後ほどインデクスを削除して、演算子クラスを指定せずに再生成させるべきです。将来再びアップデートする必要がある時に泣いてしまうことを抑制します。9.0以上では、byteaデータのデフォルトのエンコーディングがhexに変更されました。古いJDBCドライバはエスケープ形式を仮定しています。古いJDBCドライバを使ったJavaアプリケーションや古いNpgsqlドライバを使った.Netアプリケーションといった、ST_AsBinaryの古い挙動を期待するアプリケーションが影響を受けます。動作させるには二つの方法があります。9.0版にアップグレードします。http://jdbc.postgresql.org/download.htmlからダウンロードできます。2.0.11以上を使います。http://pgfoundry.org/frs/?group_id=1000140からダウンロードできます。entryに説明があります。PostgreSQLドライバのアップグレードが選択できないなら、デフォルトで古い挙動をするようにします。bytea_output='escape';3.5.pgAdminを使ってジオメトリカラムを表示しようとしたら空っぽでした。何か方法はありませんか?pgAdminは大きなジオメトリを表示しません。ジオメトリカラムがそうなっていないかを確かめる最善の方法は次の通りです。sometable;3.6.どの種類のジオメトリオブジェクトを格納できますか?ポイント、ラインストリング、ポリゴン、マルチポイント、マルチラインストリング、マルチポリゴン、ジオメトリコレクションです。2.0以上では、基本ジオメトリタイプとしてTINと多面体サーフェスも格納できます。XYZM拡張付き)で指定されます。現在サポートされているのは3つのデータ型です。計測に平面座標系を使う標準OGCジオメトリデータ型があります。地理座標系を使い、球面または回転楕円体面上の計算を行うジオグラフィデータ型があります。最新のPostGIS空間型群に追加されたのが、ラスタデータの格納と解析に使われるラスタ型です。ラスタ型単独で「よくある質問」を用意しています。リファレンスをご覧ください。3.7.たいへん混乱しました。ジオグラフィは長距離の測定をサポートする新しいデータ型ですが、計算速度は現在のところジオメトリの計算より遅いです。ジオグラフィを使う場合は、平面座標系についてあまり多く学習する必要がありません。行うことが距離や長さの計測に限定され、かつ世界中からのデータを持っている場合は、一般的にジオグラフィが最善です。ジオメトリは古いデータ型で、サポートする関数が多く、サードパーティからの多大なサポートが得られます。計算速度も早く、大きなジオメトリでは10倍違います。(SRID)が単一で済むような局所的なデータを扱っているか、あるいは、空間処理を多く行う必要がある場合には、ジオメトリが最善です。簡単に二つの型の相互変換を行ってそれぞれの利点を得ることができます。Matrix”を参照して下さい。matrixとを参照して下さい。3.8.もっとジオグラフィについて聞きたいです。ジオグラフィカラムにデータを入れて合理的な答えが得られる領域範囲はどれぐらいでしょうか、とか。2008はそう)、速度等の制限はあるのでしょうか、とか。その質問は相当深く複雑で、このセクションで十分に答えられません。“ジオグラフィに関する高度なよくある質問”を参照して下さい。3.9.GISオブジェクトをデータベースに挿入するにはどうしますか?まず、GISデータを保持するために"geometry"または"geogprahy"カラムを持つテーブルを作成します。ジオグラフィデータ型の格納は、ジオメトリデータ型とは若干異なります。“ジオグラフィ基礎”を参照して下さい。ジオメトリについては、psqlでデータベースに接続して、次のSQLを試してみて下さい。geometry(LINESTRING));ジオメトリカラムの追加に失敗する場合は、もしかしたらPostGISの関数とオブジェクトをデータベースにロードしていないか、2.0より前の版のPostGISなのかも知れません。詳細”を参照して下さい。これで、SQLのINSERTステートメントを使って、ジオメトリをテーブルに挿入することができます。text"形式を使っています。referenceをご覧ください。テーブル内にあるGISデータを表示するには、次のようにします。gtest;返り値は次のようなかんじになります。row)3.10.空間クエリを作成するにはどうするのですか?他のデータベースクエリを作るのと同じで、返り値、関数、テストのSQLの組み合わせです。空間クエリでは、クエリを作成する際に心を平静に保つための重要な二つの問題があります。一つは、使用することができる空間インデクスがあるか、です。一つは、多数のジオメトリを相手に計算量の多い計算を行っているか、です。&&演算子が便利な理由は、速度向上のために空間インデクスが付けられているなら、&&演算子は空間インデクスを使うからです。これによって、クエリの速度はとてもとても速くなります。いった空間関数を使うことでしょう。ほとんどの空間クエリは、インデクスのテストと空間関数のテストを含みます。インデクスのテストで返ってくるタプルを、求める条件に合致するかもしれないタプルのみとして、タプルの数を制限します。それから、空間関数で確実な条件のテストを行います。(トランザクションサポートもそうですが)で、良いインデクスは重要です。INDEX"を使って、次のようにします。Tree)インデクスを作るよう指示が渡ります。GiSTインデクスは、不可逆であると仮定します。(空間インデクスの場合はバウンディングボックス)を使います。PostgreSQLのクエリプランナがインデクスを作るべきかについて合理的な決定を行うよう、十分な情報を確実に持てるようにすべきです。statistics"を実行しなければなりません。ANALYZEコマンドを実行するだけです。UPDATE_GEOMETRY_STATS()を実行します。3.12.なぜPostgreSQLのR木インデクス機能を持たないのですか?PostGISの、かつての版では、PostgreSQLのR木インデクスを使っていましたが、0.6版でPostgreSQLのR木は完全に捨てて、R-Tree-over-GiSTスキームによる空間インデクスを提供しています。私たちの試験では、R木とGiSTの検索速度は同程度であることが示されています。(これらの制限は現在のPostgreSQLネイティブのR木実装についてであって、R木一般の話ではありません)。PostgreSQLのR木インデクスは、8K以上のサイズのフィーチャーは扱えません。GiSTインデクスはフィーチャー自体の代わりにバウンディングボックスを用いる「不可逆」トリックを使っているので扱うことができます。PostgreSQLのR木インデクスは「NULLセーフ」ではなく、NULLジオメトリを含むジオメトリカラムではインデクス作成に失敗します。AddGeometryColumn()関数と他のOpsnGIS関数を使うべきなのですか?OpenGIS関数を使いたくないのでしたら、使う必要はありません。単純にジオメトリカラムをCREATEステートメントで定義する古いやり方で作成して下さい。全てのジオメトリはSRIDが-1になり、OpenGISメタデータテーブルは適切に書き込まれません。これによって、ほとんどのPostGISベースのアプリケーションでは失敗します。一般的にはAddGeometryColumn()を用いることをお勧めします。MapServerはgeometry_columnsメタデータを使うアプリケーションのひとつです。踏み込んでいえば、MpaServerはジオメトリカラムのSRIDを使って、正しい地図投影へのフィーチャーの自動投影変換を行います。3.14.半径内にあるオブジェクトを全て検索する最善の方法は何ですか?データベースを最も効果的に使うには、半径検索とバウンディングボックス検索を組み合わせた半径検索を行うのが最も良いです。バウンディングボックス検索で空間インデクスを使用するので、半径検索が適用されるサブセットへのアクセスが早くなります。distance)関数は、インデクス付きの距離検索を実行する手軽な方法です。インデクス付きの結果サブセットに対して確実な距離検索を行います。1000)から100メートル内の全てのオブジェクトを見つけるためには、次のクエリで動作します。投影変換されるジオメトリがそのSRIDを持っている必要があります。これが行われていると、投影変換は求める変換先SRIDを参照するのと同じぐらい簡単です。83経度緯度に投影しています。(空間参照系が定義されていない)でない場合のみ動作します。geotable;3.16.ST_AsEWKTとST_AsTextとを、かなり大きいジオメトリで実行すると、空のフィールドが返りました。したら良いですか?pgAdminまたは大きなテキストを表示しないその他のツールを使用しているのかも知れません。ジオメトリが十分に大きい場合、ツールには空として表示されます。本当にWKTで見たり出力したりしなければならない場合は、PSQLを使用して下さい。NULL;3.17.ST_Intersectsを使うと、二つのジオメトリがインタセクトしているのが分かっているのに、インタセクトしていないと言います。したら良いですか?二つの場合がよくあります。一つは、ジオメトリが不正な場合です。???で確認できます。一つは、ST_AsTextで数字を切り捨てていて、表示されている分より後にたくさんの小数が付いている場合です。3.18.PostGISを用いたソフトウェアをリリースしています。PostGISのようにGPLライセンスを使う必要があるのでしょうか?PostGISを使うとコードを全て公開しなければならないのでしょうか?ほぼ確実に違います。例として、Linux上で動作するOracleを考えてみます。LinuxはGPLでOracleは違いますが、Linuxで動作するOracleはGPLで配布しなければならないでしょうか?違います。あなたのソフトウェアはPostgreSQL/PostGISデータベースを好きなだけ使うことができ、ライセンスは好きなようにできます。PostGISソースコードに変更を加えて、変更したPostGISを配布したときだけは例外です。(PostGIS上で動作するアプリケーションのコードではありません)。この限られた場合でも、ソースコードはバイナリの配布相手にだけ配布します。GPLはソースコードの公開までは求めておらず、バイナリを配布した相手との共有を求めています。CGALを使った関数とともにPostGISを使ってでも、このことに違いはありません。CGALのライセンスの一つにGPLがありますが、PostGISの全てが既にGPLですので、CGALによってPostGISの元々のライセンスよりも厳しくなることはありません。Modelまたは略してDE-9IMを見てみましょう。SQL"仕様で定められた全てのオブジェクトと関数に対応しています。XYZM)座標に対応しています。WKBとWKTOpenGIS仕様は空間オブジェクトの表現について二つの標準を定義しています。WKTもWKBも、オブジェクトの型とオブジェクトを形成する座標に関する情報を持っています。(WKT)の例は、次の通りです。SRID)を含むことも求められます。SRIDはデータベースへの挿入のために空間オブジェクトが生成される時に求められます。これらの書式の入出力は次のインタフェースを用いて実現できます。WKT、SRID);たとえば、OGC空間オブジェクトを生成して挿入する妥当なINSERTステートメントは次の通りです。EWKTと標準形式OGC書式は2次元ジオメトリしかサポートされておらず、また、入出力の表現においてSRIDは*決して*埋め込まれません。(全ての妥当なWKB/WKTは妥当なEWKB/EWKTです)。OGCがPostGIS拡張と矛盾する新しい書式を出すことがあるなら、これは将来変更されるかも知れません。ゆえにこの機能に頼るべきではありません。座標サポートが追加され、SRID情報が埋め込まれます。(EWKT)の例は、次の通りです。)これらの書式の変換は次のインタフェースを用いて実現できます。EWKT);たとえば、PostGISの空間オブジェクトを作成し挿入する妥当なINSERTステートメントは次の通りです。COPYで受け付けられることが保障されるものです。PostGISの"geometory"型の場合は次の通りです。HEXEWKB|EWKTたとえば、次のステートメントは、標準的なASCII文字列による入出力の処理でEWKTを読み、HEXEWKBを返すものです。SQL-MM第3部SQLマルチメディア・アプリケーション空間仕様は、円弧補完曲線を定義したSQL仕様の拡張です。SQL-MMの定義では、3DM、3DZと4Dの座標を含みますが、SRID情報の埋め込みはできません。Text拡張はまだ完全にはサポートされていません。単純な曲線ジオメトリの例を次に示します。0)CIRCULARSTRINGは基本的な曲線型で、線型のLINESTRINGに似ています。(一つめと三つめ)と弧上の任意の点、の3点が必要です。例外として、始点と終点が同じとなる閉曲線があります。閉曲線では二つ目の点が弧の中心、すなわち円の反対側にならなければなりません。弧の連結では、LINESTRINGと同じように、前の弧の最後の点が次の弧の最初の点となります。よって、妥当なCIRCULARSTRINGは1以上の奇数になります。(円弧)セグメントと線型セグメントの両方を持つ、単一の連続した曲線です。(最終要素は除く)の終点は次の要素の始点と同じになる必要があります。1))曲線ポリゴンの中に複合ポリゴンがある例は次の通りです。)CURVEPOLYGONは外環と0以上の内環とを持つ点でPOLYGONと似ています。異なる点は、環に曲線ストリング、線型ストリング、複合ストリングのいずれも取れる点です。1.4から、PostGISで曲線ポリゴンで複合曲線をサポートするようになりました。4))MULTICURVEは曲線のコレクションで、線型ストリング、曲線ストリング、複合ストリングを取れます。11)))サーフェスのコレクションです。(線型)ポリゴンか曲線ポリゴンを取れます。SQL-MM実装での全ての浮動小数点数の比較では、所定の丸め誤差があります。経度緯度などとも呼ばれます)上で表現された空間フィーチャーのネイティブサポートするためのものです。(度)で表現される球面座標です。PostGISジオメトリ型の基礎は平面です。平面上の二点間の最短コースは直線になります。(面積、距離、長さ、インタセクション等)は、デカルト座標と線型ベクトルを使用することができます。PostGISのジオグラフィ型の基礎は球面です。球面上での二点間の最短距離は大圏の弧です。(面積、距離、長さ、インタセクション等)は、球面上で計算しなければならず、複雑な計算が必要となります。正確な計測のためには、世界の実際の回転楕円体の形を考慮に入れなければならず、非常に複雑です。基礎となる数学が大変に複雑なので、ジオグラフィ型用に定義された関数は、ジオメトリ型よりも少ないです。時間とともに、新しいアルゴリズムが追加されて、ジオグラフィ型の能力は拡大していくでしょう。geographyと呼ばれるデータ型を使用します。GEOS関数はgeography型に対応していません。回避策として、ジオメトリとジオグラフィの型変換を行うことができます。(SRID:4326)だけに対応していました。2.2以降は、spatial_ref_sysで定義されている経度緯度ベースの空間参照系の全てが使えます。earthの記述にある通り、独自の回転楕円体の空間参照系を追加することもできます。ST_Area)の返り値の単位と、???の入力の単位はメートルです。ジオグラフィ型はPostgreSQLのtypmod定義書式を使います。ジオグラフィカラムを持つテーブルに1ステップで追加できます。標準OGC書式は曲線を除いてサポートします。ジオグラフィ基礎ジオグラフィ型はシンプルフィーチャーの最も簡単なもののみサポートします。標準的なジオメトリ型データで、SRIDが4326の場合は、ジオグラフィに自動でキャストされます。データ挿入においてEWKTとEWKBの取り決めを使うこともできます。SRID指定なしでの2次元ポイントジオグラフィのテーブル生成は次の通りです。WGS84経度緯度となります。NAD83経度緯度での2次元ポイントジオグラフィのテーブル生成は次の通りです。);Z値を持ち、明示的にSRIDを指定したポイントのテーブル生成は次の通りです。);MULTIPOINTMULTILINESTRINGMULTIPOLYGONGEOMETRYCOLLECTIONジオグラフィ型のフィールドはgeography_columnsシステムビューに登録されます。"geography_columns"ビューをチェックして、テーブルが一覧にあるか見て下さい。TABLEの文法でジオグラフィカラムを持つテーブルを新規に生成できます。);locationカラムはジオグラフィ型で、二つの任意修飾子に対応していることにご注意ください。一つは、そのカラムで使用できる形状と次元を限定する型修飾子です。一つは、座標参照IDを特定の数に限定するSRID修飾子です。MULTIPOLYGONです。ZMの後置子を付けることで次元制限にも対応します。'LINESTRINGM'という型修飾子で、三つ目の次元をMとする3次元のラインストリングのみ受け付けることになります。同じように'POINTZM'で、4次元データを期待します。84を使って行われます。テーブルを作ったら、次のようにしてGEOGRAPHY_COLUMNSを見ることができます。geography_columns;ジオメトリカラムを使うのと同じようにテーブルへのデータの挿入ができます。49)');ジオメトリと同じ操作でインデックスを作成します。PostGISは、カラム型がジオグラフィであるかを見て、ジオメトリで使われる平面用インデックスの代わりに球面ベースのインデックスを作成します。);クエリと計測関数はメートル単位となります。(面積の場合は平方メートル)単位となります。64.15))に最も近くなるときの距離を求めてみると分かります。64.15)'::geometry);異なる経度緯度座標系を試します。spatial_ref_sysテーブルで挙げられている経度緯度の空間参照系なら全て可能です。34)'::geography;ジオグラフィ型は、レイキャビクとシアトル-ロンドン間の飛行機の大圏コースとの間の、球面上での本当に最も近い距離を計算します。ジオメトリ型は、平面の世界地図上にプロットされたレイキャビクとシアトル-ロンドン間の直線とのデカルト距離という意味のない値を出します。結果の名目上の単位は「度」ですが、点間の本当の角度差にあっていませんので、「度」と言うこと自体不正確です。ジオグラフィ型をジオメトリ型にして使用すべき時ジオグラフィ型によって、経度緯度座標でデータを格納できるようになりましたが、ジオグラフィで定義されている関数が、ジオメトリより少ないのと、実行にCPU時間がかかる、というところが犠牲になっています。選択した型が、期待する領域から出ないことを、ジオメトリ型にして使用する条件とすべきです。使用するデータは地球全体か、大陸か、州か、自治体か?データが小さいエリア内におさまるなら、適切な投影を選択してジオメトリを使うのが、効率面でも機能面でも最も良い方法です。データが地球全体か大陸なら、ジオグラフィで投影法の細かい問題を気にせずにシステムを構築できるでしょう。経度/緯度のデータを保存して、ジオグラフィで定義された関数使います。投影法を理解していなくて、学習したくもなくて、かつ、ジオグラフィで使える関数が限られていることを受け入れるのなら、ジオグラフィを使った方が簡単です。単純にデータを経度/緯度でロードして、そこから進めて下さい。Matrix”をご覧下さい。Functions”をご覧下さい。ヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか?4.2.3.1.球または回転楕円体のどちらで計算するのでしょうか?デフォルトでは、全ての距離と面積の計算は回転楕円体で行います。局所的なエリアでの計算結果と良好な投影を施した平面での結果と比較して下さい。大きなエリアの場合は、回転楕円体計算は、投影平面上でのどの計算よりも精度が高くなります。全てのジオグラフィ関数には、最後の真偽パラメータを'FALSE'にすると球面を使った計算を行うというオプションがあります。これは、特にジオメトリが非常に単純である場合に計算を速くするためのものです。4.2.3.2.日付変更線や極に関してはどうなっていますか?全ての計算に日付変更線や極の概念がありません。(経度/緯度)であるので、日付変更線とクロスする形状は、計算の観点からは、他のものと変わりありません。4.2.3.3.処理できる最も長い弧はどうなりますか?大圏の弧を2点の「補完線」として使用しています。任意の2点は、実際には2方向につながっていて、どちらの方向に行くかに依存します。PostGISの全てのコードは、大圏コースの2コースのうち*短い*方でつながっていると仮定しています。結果として、180度以上の弧を持つ形状は正しくモデル化されません。4.2.3.4.なぜヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか?ポリゴンがとんでもなく大きいからです。二つの理由から、大きなエリアは悪いです。一つは、バウンダリボックスが大きいため、どのようなクエリを走らせても、インデックスがフィーチャーを引っ張ってくる傾向にあるためです。(Nは、もう一方のフィーチャーの頂点数)回、頂点を横断しなければならないためです。ジオメトリでは、大きなポリゴンを持っているけれども小さな範囲のクエリを実行する時、ジオメトリデータ情報を小片に「非正規化」します。これにより、インデックスが効果的にオブジェクトの一部を問い合わせるようになり、またクエリが常にオブジェクト全体を引っ張りこむようなことがないようになります。ST_Subdivideを参照して下さい。ヨーロッパ全体を一つのポリゴンに*格納できる*からといって、*そうすべき*だというわけではありません。Modelまたは略してDE-9IMを見てみましょう。OpenGISの「SQL用シンプルフィーチャー仕様」では、標準GISオブジェクト型とこれらを操作するために必要な関数、メタデータテーブルのセットが定義されています。メタデータが一貫性を維持していることを保証するために、空間カラムの生成、消去といった操作はOpenGISで定義されている空間プロシージャを通して実行されます。OpenGISメタデータテーブルにはSPATIAL_REF_SYSとGEOMETRY_COLUMNSの二つがあります。SPATIAL_REF_SYSテーブルは空間データベースで用いられる座標系の、数字によるIDと文字による説明を持っています。SPATIAL_REF_SYSテーブルと空間参照系spatial_ref_sysテーブルは、PostGISに含まれるもので、3000以上の空間参照系と、座標変換/投影変換を行うのに必要な詳細情報との一覧を持つ、OGC準拠のデータベーステーブルです。PostGISのspatial_ref_sysテーブルには、projライブラリで使われる3000以上の一般に使われる空間参照系定義がありますが、全てを持っているわけではなく、proj4の構築に慣れているならカスタム投影を定義することができます。ほとんどの空間参照系は地域限定のもので、想定されている範囲の外で使うと意味が無いことに注意して下さい。PostGISのコアセットに入っていない空間参照系を探すための素晴らしい資料がhttp://spatialreference.org/にあります。日本では状況が異なります)。経度)の領域しかカバーしません。通常は州ごとに一つか二つあります。メートル単位のもののほとんどがPostGISのコアセットに入っていますが、多数のフィート単位のものやESRIが作ったものについてはspatialreference.orgから取得して下さい。functionを参照して下さい。SPATIAL_REF_SYSテーブル定義は次の通りです。VARCHAR(2048))SPATIAL_REF_SYSのカラムは次の通りです。(SRS)を識別するものです。AUTH_NAMEその参照系の引用元である標準の名前です。「EPSG」は妥当なAUTH_NAMEです。AUTH_SRIDAUTH_NAMEで引用される団体によって定義された空間参照系のIDです。EPSGの場合、EPSG投影コードが入ります。SRTEXT空間参照系のWell-Knownテキスト表現です。SRSの表現は、次のようになります。UNIT["metre",1]]EPSG投影コードと対応するWKT表現の一覧については、http://www.opengeospatial.org/をご覧下さい。WKTの一般的な議論については、OpenGISのhttp://www.opengeospatial.org/standardsにある「座標変換サービス実装仕様」をご覧下さい。EPSG)とEPSG空間参照系のデータベースに関する情報は、http://www.epsg.org/をご覧下さい。PROJ4TEXTPostGISは座標変換機能を提供するためにProj4ライブラリを用いています。PROJ4TEXTカラムには、特定のSRIDを示すProj4座標定義文字列が入ります。+units=m詳細情報については、Proj4ウェブサイトhttp://trac.osgeo.org/proj/をご覧下さい。spatial_ref_sys.sqlは、全てのEPSG投影法のためのSRTEXTとPROJ4TEXTとを持っています。GEOMETRY_COLUMNSビューGEOMETRY_COLUMNSは、データベースのシステムカタログから読み取るビューです。|カラムの意味は次の通りです。F_TABLE_NAMEジオメトリカラムを持つフィーチャーテーブルの完全修飾名。"catalog"および"schema"の語はOracle風であることに注意して下さい。"catalog"に類似するものはPostgreSQLになく、このカラムは空白にされます。(publicがデフォルトです)。F_GEOMETRY_COLUMNフィーチャーテーブル内のジオメトリカラムの名前。SRIDこのテーブルの座標ジオメトリのために使われる空間参照系のID。SPATIAL_REF_SYSへの外部キーになっています。TYPE空間オブジェクトの型。空間カラムを単一型に制限するには、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTIONのうちのいずれかを、また、XYMで使う場合には、LINESTRINGM、POLYGONM、MULTIPOINTM、MULTILINESTRINGM、MULTIPOLYGONM、GEOMETRYCOLLECTIONMのうちのいずれかを使います。複数の型が混合するコレクションの場合は"GEOMETRY"を型とすることができます。(おそらく)OpenGIS仕様に入っていませんが、型の同一性を保証するために必要です。空間テーブルを作る空間データを持つテーブルの生成は、1段階でできます。2次元ラインストリングでWGS84経度緯度のジオメトリカラムを持つroadsテーブルの生成の例を次に示します。TABLEコマンドを使ってカラムを追加できます。手動でジオメトリカラムをgeometry_columnsに登録するこれが必要になる事例に、SQLビューとバルクインサートの二つがあります。TABLEを実行することで、geometry_columnsテーブル内の登録を訂正することができます。ビューの場合には、CAST演算を使用します。カラムが型修飾子に基づく場合には、生成処理によって正しく登録されるので、何も行う必要がありません。ジオメトリに適用する空間関数を持たないビューも、基礎となるテーブルのジオメトリカラムと同じように登録されます。ジオメトリをキャストします。