現時点ではkNN探索に対応していません。インデックスを使う通常、インデックスは見えないところでデータアクセスの速度向上を行います。ひとたびインデックスが構築されたら、クエリプランナは透過的に、クエリプランの速度を向上させるためにインデックス情報を使うべき時を判断します。残念なことに、PostgreSQLクエリプランナは、GiSTインデックスの使用について十分に最適化できず、時々、検索で空間インデックスを使用すべきなのに、テーブル全体を順に走査することがあります。(または属性インデックスがその問題のために使用されていない)場合、次の二つのことができます。クエリプランを読んで、クエリが実際に必要な計算をしようとしているか確認します。JOIN条件を忘れていたり、間違ったテーブルに付けていたりすることで、暴走することがあり、予期せずに何度もテーブル全体を得ることになります。クエリプランを取得するには、クエリの前にEXPLAINキーワードを追加します。次に、テーブル内の値の数量と分布に関する統計情報を収集するとともに、クエリプランナにインデックス使用にかかる意思決定のための、より良い情報を与えるようにします。ANALYZEは両方を計算します。データベースに対する定期的なvacuumは常に実行するべきです。多くのPostgreSQLデータベースエージェントは、閑散時のcronジョブとして定期的にVACUUMを実行します。off;コマンドで、一時的にプランナに対してインデックス情報の使用を強制することができます。この方法で、プランナがインデックスを使用するプランを生成できるかどうか確認できます。このコマンドはデバッグにのみ使用すべきです。一般的に言うと、プランナはあなたよりインデックスを使うべき時を知っています。クエリを実行したら、ENABLE_SEQSCAN設定を戻して、他のクエリでは通常通りプランナを使用します。off;がクエリの実行に役立っているなら、お使いのPostgreSQLはハードウェアにあわせた調整をしていないようです。1.1;を使ってみてください。(高速磁気ディスクの場合)にして下さい。値を減らすことで、プランナがよりインデックススキャンを行う傾向になります。off;がクエリの役に立たない場合には、PostgreSQLがまだ解決できない構文を使ってしまっているのかもしれません。インラインSELECTのサブクエリが一つの例です。プランナが最適化できるように書き直す必要があります。空間データベース機能のレゾンデートルは、通常はデスクトップGISに求める機能を、データベース内部のクエリで実現してすることです。PostGISを効果的に使用するには、どの空間関数が有効かを知り、また、良好なパフォーマンスを提供する所に適切にインデックスがあることが保証されていることが求められます。312を使っていますが、これは純粋に例として出しているだけです。spatial_ref_sysテーブルにあり、データの投影法に合致している、本当のSRIDを使ってください。空間参照系を持たないデータについては、なぜ持っていないのか、持つべきなのかも知れないのか、をじっくり*考えてください*。分子内部や火星旅行の到達位置といった、定義された空間参照系を持たない場合には、単にSRIDを無視するか、一つ作成してspatial_ref_sysテーブルに追加して下さい。分子の内部構造や開発前の遊園地の間取り図といった、空間参照系を持たないものを扱うためだったら、問題ありません。遊園地の位置が決まっている場合だと、遊園地が既存構造の上に入り込まないようにするためだけでも、その位置に適切な平面座標系を使うようにします。2000といった地球以外の座標系を作成し、spatial_ref_sysに挿入して使うことができます。(回転楕円体面の度)ですが、ジオグラフィ型で長さや、計測近似値を、度単位でなくメートル単位で得ることができます。インデックスの利点を使うクエリを作成するとき、&&のようなバウンディングボックスを基準とした演算子によってのみGiST空間インデックスの利点が出てくることだけは覚えておくことが重要です。ST_Distance()のような関数では演算の最適化を行うためにインデックスを使うことができません。次のクエリでは、大きなテーブルでは本当に遅くなります。200000)の点から距離が100単位以内にある全てのジオメトリを選択します。このクエリは、テーブル内にあるそれぞれの点と指定した点との距離を計算する、すなわち、それぞれの行で一つのST_Distance()計算を行うため、遅くなります。1ステップでインデックスを利用するST_DWithin関数を使って、求められる距離計算の量を減らすことで回避できます。100)このクエリは、同じジオメトリを選択しますが、より効果的な方法で行われます。the_geomにGiSTインデックスがあると仮定すると、クエリプランナはST_Distance()関数の結果を計算する前にインデックスを使って行を減らせると認識します。&&演算子で使われるST_MakeEnvelopeジオメトリは、元のポイントに中央寄せした200単位の正方形です。これは「クエリボックス」です。&&演算子は、結果セットを「クエリボックス」にオーバラップするバウンディングボックスを持つジオメトリだけに素早く減らすためにインデックスを使います。「クエリボックス」がジオメトリテーブル全体の範囲より十分に小さいと仮定すると、行われなければならない距離計算の量は劇的に減少します。本節の例では、線型の道、ポリゴンの自治体境界、の二つのテーブルを使います。テーブルの定義をしまします。bc_roadsについては次の通りです。(Linestring)bc_municipalityテーブルの定義については次の通りです。穴を持つ自治体ポリゴンのうち最も大きいのはどれでしょう?4.7.2.1.道路の総延長はkm表記でいくらになるでしょう?この問題は、次のようなとても単純なSQLで答えを得ることができます。(面積)を併用しています。row)4.7.2.3.県内で最も大きな面積となる自治体はどこでしょう?このクエリは、空間計測をクエリ条件に持ってきています。この問題へのアプローチの方法はいくつかありますが、最も効率的なのは次の通りです。row)このクエリの答えを出すためには、全てのポリゴンの面積を求める必要があることに注意して下さい。このクエリを多く実行する場合、性能向上のためにテーブルにareaカラムを追加して、別のインデックスを追加することができるようにするのは、意義のあることです。結果を距離について降順に並べ替え、PostgreSQLの"LIMIT"コマンドを用いることで、max()のような集約関数を使わずに、簡単に最も大きい値を集約関数を得ることができます。(結合して)いるので「空間結合」の例です。(「含む」)を使っています。(この例での話ですが約250Kmの道です)にまとめられるので、少し時間がかかります。(数百の道路で数千のレコード)の場合、応答はもっと早くなりえます。4.7.2.5.プリンスジョージ市内の全ての道路からなるテーブルを作るこれは「オーバレイ」の例です。二つのテーブルを取得して、空間的に切り取られた結果からなる新しいテーブルを出力します。上で示した「空間結合」と違い、このクエリは実際に新しいジオメトリを生成します。生成されたオーバレイはターボのかかった空間結合みたいなもので、より確かな解析作業に便利です。PostGISラスタ関数を用いたラスタの生成raster2pgsqlラスタローダを使ってPostGISラスタを既存のラスタファイルからロードするのは、最もよく行われます。raster2pgsqlを使ってラスタをロードするraster2pgsqlは、GDALがサポートするラスタ書式をPostGISラスタテーブルにロードするのに適切なSQLにするバイナリファイルです。ラスタのオーバビューの生成だけでなく、ラスタファイルのフォルダのロードも可能です。(GDALライブラリをコンパイルしている場合)が、バイナリファイルによってサポートされるラスタタイプは、GDALでコンパイルされたのと同じです。raster2pgsqlがサポートするラスタタイプの一覧を得るには、-Gスイッチを使います。提供するST_GDALDriversと同じになるはずです。このツールの古い版では、Pythonスクリプトでした。実行ファイルに置き換えられています。Usageに、Pythonの例があります。rasterでは動作しないかも知れませんし、サポートされませんので、ご注意ください。同じアラインメントを持つラスタの集合から特定の要素のオーバビューを生成する時、オーバビューが同じアラインメントを持たないことがあります。オーバビューが同じアラインメントを持たない例についてはhttp://trac.osgeo.org/postgis/ticket/1764をご覧下さい。out.sql-?ヘルプを表示します。引数を全く指定しない場合にも表示されます。-Gサポートされているラスタ書式を印字します。相互に排他的なオプションです-c新しいテーブルを生成し、ラスタを入れます。これがデフォルトモードです。-a既存のテーブルにラスタを追加します。-dテーブルを削除し、新しいテーブルを生成し、ラスタを入れます。-p準備モード、テーブルを作るだけです。ラスタカタログに適切に登録するための制約の適用-CSRIDやピクセルサイズ等のラスタ制約を適用して、raster_columnsビューで適切な登録ができるようにします。-x制約の最大範囲を無効にします。-Cフラグが使われている場合のみ適用されます。(空間的に一意で網羅タイル)を適用します。-Cフラグが使用されている場合のみ適用されます。<SRID>出力ラスタを指定されたSRIDにします。指定しないか0を指定した場合、ラスタのメタデータに対して、適切なSRIDを決定するためのチェックを行います。1より多いバンドを抽出するには、コンマ(,)で区切ります。指定しない場合、全てのバンドが抽出されます。TILE_SIZE行毎に挿入するラスタを切断します。TILE_SIZEは、「幅x高さ」で表現しますが、"auto"を指定すると、最初のラスタを使って適切なタイルサイズが計算され、全てのラスタに適用されます。-P全てのタイルが同じ幅と高さを持つことを保証するために、右端、下端のタイルに詰め物を施します。(データベース外)ラスタとして、ラスタを登録します。(ピクセルは格納されません)。OVERVIEW_FACTORラスタのオーバビューを生成します。factor_tableとなります。factorにはオーバビュー係数が入り、tableには基底テーブル名が入ります。生成されるオーバビューはデータベースに格納され、-Rは無視されます。生成されたSQLファイルは元データのテーブルとオーバビューテーブルの両方を含むことに注意して下さい。NODATANODATA値を持たないバンドで使用するNODATA値を設定します。COLUMN出力先ラスタカラムの名前を指定します。デフォルトは'rast'です。-Fファイル名でカラムを追加します。COLUMNファイル名カラムの名前を指定します。-qPostgreSQL識別子に引用符を付けます。-IラスタカラムにGiSTインデクスを生成します。analyzeを行います。-kバンドごとのNODATA値のチェックを省略します。tablespace生成されるテーブルのテーブルスペースを指定します。(主キーを含む)はデフォルトのテーブルスペースを使用することにご注意ください。tablespaceテーブルの新しいインデクスに使うテーブル空間を指定します。主キーに適用され、-Iフラグがある場合においては空間インデクスにも適用されます。-YINSERTステートメントでなくCOPYステートメントを使います。-eステートメント毎に実行して、トランザクションを使用しないようにします。ENDIAN生成されるラスタのバイナリ出力のエンディアンを制御します。(訳注:リトルエンディアン)の場合は1を、それぞれ指定します。現時点ではNDR出力のみサポートします。version出力書式の版を指定します。現時点では0のみサポートします。ローダを用いて入力ファイルを100x100のタイルで生成して、データベースにアップロードする例は、次の通りです。いうようにスキーマ名を外すことができます。この場合、ラスタテーブルはデータベースまたユーザの指定するデフォルトのスキーマに生成されます。elev.sql変換とアップロードはUNIXのパイプを使うと一回で実行できます。gisdbマサチューセッツ州平面のメートル単位の空中写真タイルをaerialという名前のスキーマにロードします。4レベルのオーバビューのテーブルとを生成します。(待たずにテーブルのデータを見たい場合には良いです)。ラスタを128x128ピクセルのタイルに分解してラスタ制約を適用します。INSERTモードでなくCOPYモードを使用します。-Fで、カラム名をタイル切り出し元ファイルのファイル名にします。-G-Gコマンドの出力は次のようになります。PostGISラスタ関数を用いたラスタの生成データベース内でラスタやラスタテーブルを生成したい場合が多くあります。これを行うための関数が多数あります。一般的な手順は次の通りです。新しいラスタ行を保持するためのラスタカラムを持つテーブルを生成します。raster);この目標で助けとなる関数は多数あります。他のラスタの派生でないラスタを生成する場合、ST_MakeEmptyRasterとST_AddBandを順次実行して作業を開始します。ジオメトリからラスタを生成することもできます。ST_AsRasterを使います。いった、他の関数を組み合わせる場合もあります。既存テーブルから新しいラスタテーブルを生成するための多数の選択肢があります。ST_Transformを使って、既存テーブルから異なる投影法のラスタテーブルを生成します。はじめにテーブルにデータを入れたら、ラスタカラムに空間インデクスを生成したくなるでしょう。);ST_ConvexHullを使用していることに注意して下さい。多くのラスタ演算子はラスタの凸包を元にしています。ラスタは、エンベロープを基本にして、凸包ではありませんでした。空間インデクスを適切に働かせるには、エンベロープを基本にしたインデクスを削除して、凸包を元にしたインデクスに置き換えます。AddRasterConstraintsを用いてラスタ制約を適用します。ラスタオーバビューPostGISが生成する、二つのラスタカタログのビューがあります。両方ともラスタテーブルの制約の中に埋め込まれる情報を用いています。結果として、カタログビューは、テーブル内のラスタデータに制約が働くため、常にラスタデータとの矛盾がありません。ラスタタイプのデータベースにおける全てのラスタテーブルカラムのカタログです。データベース内の、より詳細なテーブルのためのオーバビューを提供するラスタテーブルのカラム全てのカタログです。この種のテーブルは、ロード時に-lを指定した時に生成されます。ラスタカラムカタログraster_columnsは、ラスタタイプのデータベースにおける全てのラスタテーブルカラムのカタログです。テーブルの制約を使ったビューなので、他のデータベースのバックアップからラスタテーブルをリストアしたとしても、情報は常に矛盾がありません。raster_columnsカタログには次のカラムがあります。フラグを忘れたりした場合には、事後にAddRasterConstraintsで制約を強制でき、raster_columnsカタログは、ラスタタイルの共通の情報を登録します。テーブルが存在するデータベースです。これは常に現在のデータベースを読みます。ラスタテーブルが属するデータベーススキーマです。ラスタタイプであるr_table_nameテーブルのカラムです。PostGISには、一つのテーブルに複数のラスタカラムを持つことを妨げません。異なるラスタカラムを持つラスタテーブルが、ラスタカラム毎に複数回出現するテーブルを持つことができます。“SPATIAL_REF_SYSテーブルと空間参照系”にあるエントリであるべきです。地理空間座標とピクセルの間の拡大縮小係数です。これは、ラスタカラムのすべてのタイルが同じscale_xを持ち、制約が適用されている場合のみ出現します。詳細情報についてはST_ScaleXを参照してください。地理空間座標とピクセルの間の拡大縮小係数です。これは、ラスタカラムのすべてのタイルが同じscale_yを持ち、制約が適用されている場合のみ出現します。詳細情報についてはST_ScaleYを参照してください。(横方向のピクセル数)です。詳細情報についてはST_Widthを参照してください。(縦方向のピクセル数)です。詳細情報についてはST_Heightを参照してください。全てのラスタタイルが同じアラインメントを持っているかを示す真偽値です。詳細情報についてはST_SameAlignmentを参照してください。ラスタカラムが空間的に一意かつカバレッジタイルの制約を持つなら、TRUEとなります。その他の場合はFALSEになります。ラスタ集合のタイルごとのバンド数。バンドごとのピクセルタイプを定義する配列です。この配列の要素数はバンド数と同じです。pixel_typesは、ST_BandPixelTypeで定義されるピクセルタイプの一つを取ります。バンド数と同じ配列数となります。これらの値は、バンド毎のほとんどの処理で無視されるべきピクセル値の定義です。これはST_BandNoDataValueで得られる情報と似ています。ラスタバンドデータがデータベース外で維持されているかを示す真偽値の配列です。この配列の添え字はバンド番号と同じです。ラスタ集合における全てのラスタ行の範囲です。集合の範囲を変更するデータを別途ロードする予定である場合、ロード前にDropRasterConstraints関数を実行して、ロード後にAddRasterConstraintsで制約を再適用します。空間インデクスを持っているかどうかを示す真偽値です。ラスタオーバビューraster_overviewsは、オーバビューで使われるラスタテーブルカラムに関する情報のカタログで、オーバビューを用いる際に知っておくと便利な情報も持ちます。オーバビューテーブルはraster_columnsとraster_overviewsの両方のカタログに入れられます。オーバビューもラスタの一つであるのは確かですが、より高い解像度テーブルの解像度を落としたカリカチュアになるという特殊な目的を満たすためでもあるからです。ラスタをロードする際に-lスイッチを使うと、オーバビューが主ラスタテーブルと一緒に生成されます。AddOverviewConstraintsを使うと手動で生成できます。オーバビューテーブルには、他のラスタテーブルと同じ制約と、オーバビュー特有の制約となる追加情報があります。raster_overviewsの情報はraster_columnsとは重複しません。raster_columnsにあるオーバビューテーブルに関する情報が必要な場合は、raster_overviewsとraster_columnsとを結合すると、必要な情報の集合を完全に取得することができます。オーバビューの主たる理由は次の二つです。ズームアウトした際の地図表示を早くするために、元のテーブルの低解像度表現が一般的に使われます。レコード数が少なく、ピクセル毎の適用範囲が広いため、高解像度の元テーブルより計算が一般的に早くなります。計算は高解像度テーブルより精度は落ちますが、大まかな計算には十分でありえます。raster_overviewsカタログには、次の情報のカラムがあります。オーバビューテーブルが存在するデータベースです。常に現在のデータベースを読みます。オーバビューラスタテーブルが属するデータベーススキーマです。ラスタオーバビューテーブル名です。オーバビューテーブル内のラスタカラムです。このオーバビューの元となるラスタテーブルのデータベースです。常に現在のデータベースを読みます。このオーバビューの元となるラスタテーブルが属するデータベーススキーマです。このオーバビューの元となるラスタテーブルです。このオーバビューの元となるラスタカラムです。オーバビューテーブルのピラミッドレベルです。高い数字ほど解像度が低くなります。raster2pgsqlは、画像のフォルダを渡された場合は、分割して、イメージファイルのオーバビューの計算とロードを行います。レベル1は元ファイルと同じです。レベル2は、元ファイルの4分の1になります。200行のレコードを持ちます。(完全には値が入っていない)が得られます。Power(2,overview_factor)ピクセル分)が低い解像度になっている点に注意して下さい。PSQLでラスタを出力するPostGISラスタには、対応イメージ書式のラスタをレンダリングするSQL関数があり、レンダリングを行うための多数の選択肢があります。Reportsで例を挙げている通り、OpenOffice/LibreOfficeを使うことができます。ここで示すように、幅広い言語で使うことができます。imgタグに埋め込むことができるPHPリクエストストリームにラスタの1、2、3バンドを出力する方法を示します。ST_Unionでインタセクトしたタイルを結合して全てのバンドを返し、ST_Transformでユーザ指定投影法に変換し、ST_AsPNGを使ってPNGで結果を出力するためのラスタ関数群全体をまとめる方法を示します。(フィート単位)のラスタ画像を取得するものです。imgタグに埋め込むことができるように、ラスタの1、2、3バンドを出力する方法を示します。PostgreSQLドライバが必要です。最新版はhttp://npgsql.projects.postgresql.org/にあります。binフォルダに入れるだけでうまくいきます。ST_Unionでインタセクトしたタイルを結合して全てのバンドを返し、ST_Transformでユーザ指定投影法に変換し、ST_AsPNGを使ってPNGで結果を出力するためのラスタ関数群全体をまとめる方法を示します。(フィート単位)のラスタ画像を取得します。rasterクエリを画像ファイルで出力するJavaコンソールアプリケーションこれは、一つの画像を返すクエリを取り、指定したファイルに出力する、簡単なJavaコンソールアプリケーションです。JDBCドライバはhttp://jdbc.postgresql.org/download.htmlからダウンロードできます。あとで示すコードをコンパイルします。コマンドは次の通りです。*.class次のようにコマンドラインから呼び出します。介して画像をダンプするこれは、サーバディレクトリ内でレコードごとにファイルを生成するPythonストアド関数です。plpythonが必要です。plpythonuとplpython3uの両方が正しく動作します。5つの画像をPostgreSQLサーバに可変サイズで描きます。生成されたファイル名をエコーバックします。PSQLでラスタを出力するPSQLから組み込み機能を用いてバイナリを出力するのは簡単ではありません。ここで紹介する方法は、レガシーなラージオブジェクトをサポートするPostgreSQL上に乗っかる、ちょっとしたハックです。psqlを起動して、データベースに接続します。Server仕様を満たすウェブマッピングサーバです。MapServerのウェブサイトはhttp://mapserver.org/です。Specificationはhttp://www.opengeospatial.org/standards/wmsにあります。基本的な使い方MapServerでPostGISを使うには、MapServerのコンフィギュレーション方法についての知識が必要ですが、この文書の範囲外です。この節では、PostGIS特有の問題とコンフィギュレーション詳細について記載します。PostGISをMapServerで使うには、次のものが必要です。3.5以上MapServerは、他のクライアントのように、libpqインタフェースを使って、PostGIS/PostgreSQLデータにアクセスします。よってMapServerはPostGISサーバにアクセスするネットワークを持つ計算機にインストールでき、PostGISをデータソースとして使用することができます。システム間の接続は速いほど良いです。"--with-postgis"と好きなconfigureオプションを付けてMpaServerのコンパイルとインストールを行います。Mapserverのmapファイルの中に、PostGISレイヤを追加します。ENDEND上の例におけるPostGIS特有のディレクティブは次の通りです。CONNECTIONTYPEPostGISレイヤでは常に"postgis"とします。CONNECTIONデータベース接続は「接続文字列」によって制御されます。接続文字列は、次に示すような標準的なキーと値からなります(<>内はデフォルト値)。port=<5432>空の接続文字列も妥当とされますし、あらゆるキーと値のペアは省略できます。接続するためには一般的にはdbnameとusernameとが最少で与えるものとなります。<主キー>"となります。(またはインデックスを伴う一意の値を持つカラム)です。unique"節は省略できます。MapServerは可能なら自動的に正しい値を判断しますが、地図を描画するサーバ上で余分なクエリを若干実行するコストがかかります。PROCESSING接続を閉じずに複数のレイヤで再利用する場合にCLOSE_CONNECTION=DEFERとします。Tipsを参照して下さい。FILTERフィルタは、妥当なSQL文字列でなければなりません。この文字列は、通常はSQLクエリにおける"WHERE"に続く論理式に対応します。6"というフィルタを使います。(GiST)インデックスを、マップに描かれるレイヤ全てに構築していることを保証して下さい。unique"節もDATAステートメントに追加しなければなりません。MapServerでは、クエリ実行の際には、それぞれの空間レコードを識別するための一意な識別子が必要です。MapServerのPostGISモジュールは、一意な識別子を提供するために、ユーザ指定の一意な値を使います。テーブルの主キーを使うのが最も良い方法です。EXPRESSIONをマップファイルで使う時に、値がテーブルにあるのを確認しているのに条件がtrueになりません。シェープファイルで使っているFILTERが、同じデータを持つPostGISテーブルでは動作しません。PostGISレイヤはちゃんと描けましたが、クエリが本当に遅いです。1.5で機能追加)をMapServerのレイヤのソースとして使用できますか?6.1.2.1.EXPRESSIONをマップファイルで使う時に、値がテーブルにあるのを確認しているのに条件がtrueになりません。EXPRESIONで使うフィールド名は、シェープファイルと違ってPostGISの場合小文字になります。6)6.1.2.2.シェープファイルで使っているFILTERが、同じデータを持つPostGISテーブルでは動作しません。(PostGISコネクタがMapServerでレイヤを描画するために生成するSQLステートメントに追加されます)。4"6.1.2.3.PostGISレイヤの描画がシェープファイルより遅くなりますが、これが普通なのでしょうか?一般的に、地図に描画されるフィーチャーが多くなると、PostGISはシェープファイルより遅くなります。(1000件台)と、PostGISの方が遅くなります。重大な描画性能の問題があるようでしたら、テーブルにある空間インデックスを構築していないというのがありそうです。ANALYZE;6.1.2.4.PostGISレイヤはちゃんと描けましたが、クエリが本当に遅いです。何が問題なのですか?クエリを早くするには、空間テーブルに一意なキーを持たせ、そのキーにインデックスを持たせなければなりません。UNIQUE節で、MapServerで使用する一意なキーをどれにするか指定することができます。1.5で機能追加)をMapServerのレイヤのソースとして使用できますか?できます!MapServerはジオグラフィカラムをジオメトリカラムと同じに認識します。常にSRIDを4326とします。srid=4326"節をDATAステートメントに入れて下さい。他の部分はジオメトリの場合と同じです。踏み込んだ使用法USING疑似SQL節を使ってMapServerがより複雑なクエリの結果を理解できるようにするための情報を追加します。(DATA定義で"FROM"の右にあるもの)として使われる時、MapServerが自動的に一意な識別子がそれぞれの行にあるか、また、SRIDがテーブルにあるかを判別するのは困難です。USING節によって、MapServerがこれらの情報を得ることができます。<uniqueid>MapServerは、マップクエリを実行する際、行識別のために、それぞれの行に一意な識別子を求めます。通常ならシステムテーブルから主キーを識別しますが、ビューや副問い合わせでは、一意性のあるカラムを自動的に知ることができません。UNIQUE宣言を付ける必要があります。この目的のための主キー値のテーブルでのカラム名や、結果セットで一意性が保障されたカラムを明示的にSELECTに入れることができます。「マップクエリ」はマップ上でクリックして、その場所におけるフィーチャーに関する情報を問い合わせる動作です。「マップクエリ」とDATA定義におけるSQLクエリと混同しないで下さい。SRID=<srid>PostGISは、MapServerに正しいデータを返すために、ジオメトリがどの空間参照系を使っているかを知る必要があります。通常は、この情報はPostGISデータベースの"geometry_columns"テーブルから得ることができます。副問い合わせやビューのような一時テーブルでは、この方法は不可能です。SRID=オプションを使って、正しいSRIDがDATA定義で使われるように指定します。簡単な例から始めて、ステップアップしていきましょう。次のMapServerレイヤ定義を考えて下さい。ENDENDこのレイヤは"roads"テーブルにある道路ジオメトリの全部を黒線で表示するものです。少なくとも1:100000にズームするまでは高速道路だけを表示したい、としましょう。次の二つのレイヤで、その効果が実現できます。ENDEND一つ目のレイヤはスケールが1:100000以上であるときに使われ、道路タイプが"highway"である道路のみ黒線で表示されます。FILTERオプションによって、道路タイプが"highway"の場合のみ表示することになります。二つ目のレイヤはスケールが1:100000未満である時に使われ、"highway"は赤い二重細線で表示され、他の道路は黒線で表示されます。MapServerの機能を使うだけで、二つのおもしろいことを実行しました。DATAのSQLステートメントは、単純なままです。(どういう理由かは知りませんが)他のテーブルに収められていて、それのデータを取得するためにテーブルを連結して、道路のラベルを取る必要がある、とします。ENDENDこのANNOTAIONレイヤでは、縮尺が1:20000以下のときに、全ての道路に緑色のラベルを表示します。DATA定義で、SQLのJOINを使用する方法も示しています。(JDBC)Javaクライアントは、直接的にテキスト表現として、またはPostGISに同梱されているJDBC拡張オブジェクトを使用して、PostgreSQLデータベース内にある、PostGISの"geometry"オブジェクトにアクセスできます。CLASSPATHに置く必要があります。JDBCドライバをロードして接続を確立します。ジオメトリ型を接続に追加します。接続をpgsql特有の接続実装にキャストしなければなりません。ステートメントの生成とSELECTクエリの実行を行います。ジオメトリをオブジェクトとして検索してジオメトリ型にキャストします。("Geometory"抽象クラスの子クラス)を持つラッパオブジェクトです。}}幾何オブジェクトのさまざまなデータアクセサ関数に関する参照情報については、拡張オブジェクトのJavaDocをご覧下さい。(9.6を含む)では、TOASTテーブルに従うクエリオプティマイザの弱さに苦しみます。TOASTテーブルは、(長いテキスト、イメージ、多数の頂点を持つ複合ジオメトリといった)通常のデータページに適合しない、(データサイズという意味では)巨大な値を納めるための「拡張部屋」の一種です。TOASTをご覧ください。(高解像度で全てのヨーロッパの国の境界を含むテーブルのような)大きなジオメトリがあるうえ、行がそう多くないテーブルを持つようになると、この問題が出てきます。テーブル自体は小さいのですが、多くのTOASTスペースを使います。例として、テーブル自体は概ね80行で3データページしか使わなくてもTOASTテーブルで8225ページを使うとします。ここで、ジオメトリ演算子の&&を使って、ほとんどマッチしないようなバウンダリボックスを検索するクエリを出してみます。クエリオプティマイザにはテーブルは3ページ80行しかないように見えます。オプティマイザは、小さなテーブルを順に走査する方がインデクスを使うよりも早いと見積もります。GiSTインデクスは無視すると決めます。通常なら、この見積もりは正しいです。この場合は&&演算子が全てのジオメトリをディスクから呼び出してバウンディングボックスと比較しなければならなくなり、ゆえに、全てのTOASTページもまた呼び出す必要があります。ANALYZE"コマンドを使います。詳細情報と技術情報については、PostgreSQL性能メーリングリストのスレッドhttp://archives.postgresql.org/pgsql-performance/2005-02/msg00030.phpをご覧下さい。PostGISの新しいスレッドhttps://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.htmlもご覧下さい。応急処置PostgreSQLコミュニティでは、TOASTを意識したクエリ見積もりを作ることで、この問題を解決しようとしています。今のところは、二つの応急処置があります。一つは、クエリプランナにインデクスの使用を強制することです。off;"をサーバに送信します。これは基本的にクエリプランナに対して可能な限り順に走査することを避けるよう強制します。そのためGiSTインデクスを通常使うようになります。on;"をクエリの後に送信すべきです。一つは、順に走査することをクエリプランナが考える程度に早くすることです。これは、バウンダリボックスの「キャッシュ」を行う追加カラムを作成し、このカラムにマッチさせるようにすることで達成することができます。ここでの例では次のようになります。ST_Envelope(ST_Force2D(the_geom));そして、次のように、&&演算子をgeom_columnに対して行っていたものをbboxに変更します。1)'::box3d,4326);もちろん、mytableの行を変更または追加したら、bboxを「同期」するようにしなければなりません。した方法はトリガです。アプリケーションを変更してbboxカラムの現状を保持するか、テーブル更新後にいつもUPDATEクエリを実行するかでも対応できます。ジオメトリインデクスでCLUSTERを実行する読み込むことがほとんどで、かつほとんどのクエリでひとつのインデクスを使うようなテーブルのために、PostgreSQLはCLUSTERコマンドを提供しています。このコマンドは、全てのデータ行を、インデクス基準にあわせて物理的に再整理するので、二つの性能の利点を生みます。一つは、インデクスの範囲走査のために、データテーブルのシーク回数が劇的に減少することです。(この点で、PostgreSQLマニュアルのCLUSTERコマンドのドキュメントを読むように仕向けられていると感じて下さい)。GiSTインデクスは単純にNULL値を無視するため現在のところPostGISのGiSTインデクスのクラスタリングはできず、次のようなエラーメッセージを得ます。null"制限を追加することで、この欠陥にとりあえず対応できます。TABLEもちろん、ジオメトリカラムで実際にNULL値が必要な場合、この対応はできません。null);"のようなCHECK制限は使えません。2次元ジオメトリを出力させるようなことが起きます。内部でST_Force_2d()関数を呼んでいるために発生しますが、これは、大きなジオメトリでは重大なオーバヘッドを誘引することになります。このオーバヘッドを回避するには、一度追加された次元を前もって落とし、かつこれを永続化するのが適当かも知れません。mytable;AddGeometryColumn()を使ってジオメトリカラムを追加した場合、ジオメトリの次元に関する制限があることに注意してください。この制限を迂回するには、制限の削除が必要になります。geometry_columnsテーブル内のエントリを更新して、その後で制限を再作成することを忘れないで下さい。大きなテーブルの場合、WHERE節、およびプライマリキー若しくは他の適切な基準によってテーブルの一部へのUPDATEを制限させて、UPDATEの実行の間に単に"VACUUM;"と実行することで、UPDATEをより小さい塊に分割するのが賢いやり方かもしれません。これにより、テンポラリディスクスペースが劇的に減少します。dimension(the_geom)>2"によってUPDATEを制限することで、2次元で書かれているジオメトリの再書き込みをスキップさせることができます。実行時PostGISの調整はPostgreSQLの作業量の調整と非常に似ています。ジオメトリとラスタは重く、メモリ関連の最適化は他のPostgreSQLクエリと比べて影響が大きい点だけは留意して下さい。Serverをご覧ください。SYSTEM..を使うことで、postgresql.confやpostgresql.auto.confを触ることなくサーバレベルで設定できます。起動時設定でない設定を強制します。新規接続に影響を与えます。Custom)変数”で示している、いくつかの独特の設定があります。起動時これらの設定はpostgresql.conf内にあります。partition一般的にテーブルのパーティショニングに使われます。デフォルトとして"partition"に設定されています。8.4以上ではこれが理想的です。利用可能なRAMの25%から40%を設定します。Windowsでは高く設定することができないかも知れません。9.4以上で有効です。9.6以上では、パラレルクエリ処理に使うプロセス数の最大値の制御で、さらに重要なものとなっています。8システムが対応できるバックグラウンドプロセスの最大値を設定します。このパラメータはサーバ起動時のみ設定できます。1-4MB大きなデータベースの場合や、複雑なクエリの場合、RAMが多い場合は値を大きくするように調整します。同時接続ユーザ数が多い場合や、RAMが少ない場合には値を小さくするように調整します。たくさんのRAMを持ち、少数の開発者しかいない場合は次のようにします。メモリスワップの間、入出力が拘束され、オブジェクトがロックされます。たくさんのRAMを持つ本番サーバでは32MBから1GBが推奨ですが、同時接続ユーザ数に依存します。たくさんのRAMを持ち、少数の開発者しかいない場合は次のようにします。9.6以上で有効です。2.3以上でのみ影響が出ます。0より大きい値にすると、ST_Intersects等の関係関数が複数のプロセスを使えるようになり、2倍以上高速になります。多数のプロセッサを予備に持っているなら、この値を、持っているプロセッサ数にあわせるべきです。max_worker_processesを少なくともこの値より大きくするようにして下さい。0単一のGatherノードが開始できるワーカの最大数を設定します。並列ワーカは、max_worker_processesで確立されたプロセスのプールから取得されます。要求したワーカ数は、実際には実行可能になっていない場合があることに注意して下さい。これが発生する場合には、想定より少ないワーカでプランが実行され、非効率になります。(デフォルト値)にすると、パラレルクエリ実行が無効になります。ロングトランザクション機能ここで示す関数はPostGISユーザが必要とすると思われる関数です。この他に、一般的なユーザが使わないPostGISオブジェクトに対して求められるサポート関数があります。PostGISは、既存の名前付け方針からSQL-MM中心の方針への切り替えを開始しています。プレフィクスを使うように名前変更されました。2.0では基本的に外れています)。これらの関数は非推奨であり、将来のリリースでは削除されますので、*使わないでください*。Geometry/Geography/Box型Abstract本節では、PostGISによってインストールされるPostgreSQLデータ型を挙げます。ユーザ定義関数をデザインする際に大変重要なキャストの挙動を記載しています。zmaxで作られるボックス。ジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。zmaxで作られるボックス。ジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。geographyは球面座標系での地物表現に使われる空間データ型です。zmaxで作られるボックス。ジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。説明box3dは、ジオメトリまたはジオメトリ集合を囲むボックスを表現するPostGIS空間データ型です。ST_3DExtentはbox3dオブジェクトを返します。zmaxで作られるボックス。ジオメトリやジオメトリのコレクションの3次元範囲を返すために使われます。説明box3dは、ジオメトリまたはジオメトリ集合を囲むボックスを表現するPostGIS空間データ型です。ST_3DExtentはbox3dオブジェクトを返します。本節では、このデータ型で許容される明示的なキャストと自動キャストの一覧を挙げます。geographyは球面座標系での地物表現に使われる空間データ型です。説明geometryは基礎的なPostGIS空間データ型です。ユークリッド座標系上の地物を表現するために使われます。ジオメトリに関する全ての空間演算は、ジオメトリの空間参照系の単位を使います。本節では、このデータ型で許容される明示的なキャストと自動キャストの一覧を挙げます。systems.説明geographyは球面座標系での地物表現に使われる空間データ型です。本節では、このデータ型で許容される明示的なキャストと自動キャストの一覧を挙げます。Custom)変数の一覧を上げます。これらは、グローバル、データベースごと、セッションごと、またはトランザクションごとに設定できます。グローバルまたはデータベースごとの設定が最善です。GEOSとSFCGALで重複する関数を提供するバックエンドです。GEOSまたはSFCGALを選択します。デフォルトはGEOSです。GDALのGDAL_DATAオプションの値を設定するためのコンフィギュレーションオプションです。設定しない場合には、GDAL_DATA環境変数が使われます。PostGIS環境でGDALドライバを有効にするコンフィギュレーションオプションです。GDALコンフィギュレーション変数GDAL_SKIPに影響を与えます。データベース外ラスタのバンドにアクセスできるようにする、真偽型のコンフィギュレーションオプション。GEOSとSFCGALで重複する関数を提供するバックエンドです。GEOSまたはSFCGALを選択します。デフォルトはGEOSです。説明このGUCはSFCGALサポートでPostGISをコンパイルした場合にのみ適切なものとなります。デフォルトでは、geosバックエンドはGEOSとSFCGALが同じ名前の関数を持つ関数で使われます。この変数によって、SFCGALをリクエストを提供するバックエンドにすることができます。2.1.0例バックエンドを接続時にだけ設定します。sfcgal;データベースへの新規接続にバックエンドを設定します。GDALのGDAL_DATAオプションの値を設定するためのコンフィギュレーションオプションです。設定しない場合には、GDAL_DATA環境変数が使われます。postgis.gdal_datapath値は完全にGDALのデータファイルへの物理的なパスになるべきものです。コンフィギュレーションオプションは、GDALのデータファイルパスがハードコーディングされていないWindowsプラットフォームのためにほとんど使われます。このオプションは、GDALのデータファイルがGDALの期待されているパスに無いときに設定します。このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。Optionsにあります。例postgis.gdal_datapathの設定とリセット。default;Windows上における特定のデータベース上で設定する場合は次の通りです。PostGIS環境でGDALドライバを有効にするコンフィギュレーションオプションです。GDALコンフィギュレーション変数GDAL_SKIPに影響を与えます。説明PostGIS環境でGDALドライバを有効にするコンフィギュレーションオプションです。GDALコンフィギュレーション変数GDAL_SKIPに影響を与えます。このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。postgis.gdal_enabled_driversの初期値は、PostgreSQL開始プロセスに渡される、有効とするドライバの一覧からなる環境変数POSTGIS_GDAL_ENABLED_DRIVERSによって設定されます。有効にするGDALドライバは、ドライバの短縮名またはコードで指定します。Formatsにあります。複数のドライバを指定するには、ドライバの間に一つの空白を置きます。postgis.gdal_enabled_driversには三つの特別なコードがあります。大文字小文字を区別します。全てのGDALドライバを無効にします。postgis.gdal_enabled_driversにある他の全ての値を上書きします。全てのGDALドライバを有効にします。GDALの仮想ファイルシステム/vsicurl/を有効にします。ST_AsPNG()を使おうとすると、エラーメッセージが返されます。postgis.gdal_enabled_driversはDISALBE_ALLに設定されます。Optionsにあります。2.2.0例postgis.gdal_enabled_driversの設定とリセット。データベースへの新規接続にバックエンドを設定します。JPEG';サーバへの全ての新規接続のための、有効なドライバのデフォルトを設定します。9.4以上が必要です。データベース、セッション、ユーザ設定によって上書きされます。default;全てのGDALドライバを有効にします。'ENABLE_ALL';全てのGDALドライバを無効にします。データベース外ラスタのバンドにアクセスできるようにする、真偽型のコンフィギュレーションオプション。説明データベース外ラスタのバンドにアクセスできるようにする、真偽型のコンフィギュレーションオプションです。このオプションは、PostgreSQLのコンフィギュレーションファイルpostgresql.confで設定できます。コネクションまたはトランザクションでも設定できます。postgis.enable_outdb_rastersの初期値は、環境変数POSTGIS_ENABLE_OUTDB_RASTERSが0でない値で、PostgreSQL開始プロセスに渡されることでで設定されます。postgis.enable_outdb_rastersは、アクセス可能なラスタ書式を判定します。標準的なPostGISのインストールでは、postgis.enable_outdb_rastersはFALSEに設定されています。2.2.0例postgis.enable_outdb_rastersの設定とリセット。ジオメトリカラムを空間テーブルから除去します。ジオメトリカラムを空間テーブルから除去します。テーブルとgeometry_columnsの当該テーブルへの参照の全てを削除します。ジオメトリカラムを空間テーブルから除去します。use_typmod=true);説明ジオメトリカラムを既存の属性テーブルに追加します。schema_nameはスキーマ名です。sridはSPATIAL_REF_SYSテーブルのエントリを参照する整数でなければなりません。typeは'POLYGON'や'MULTILINESTRING'といった、ジオメトリタイプを示す文字でなければなりません。(または現在のsearch_pathからは見えない)場合、または指定したSRID、ジオメトリタイプもしくは次元が不正である場合はエラーが投げられます。geometry_columnsがシステムカタログを読むビューになったため、geometry_columnsを更新しないようになりました。デフォルトでは制約を生成せず、PostgreSQLの型修飾子を使います。geometry(Point,4326);とは等価です。制約を使う必要がある場合には、use_typmodをFALSEにします。ビューについては、geometry_columnsへの手動登録はできなくなりました。typmodテーブルジオメトリに対して構築されていて、かつラッパ関数が無いビューは、親テーブルカラムのtypmodの挙動を継承するので、正しく登録されます。他のジオメトリを出力するジオメトリ関数を使うビューについては、ビューのジオメトリカラムが正しく登録されるようにするため、typmodジオメトリへのキャストが必要です。“手動でジオメトリカラムをgeometry_columnsに登録する”を参照して下さい。use_typmod引数が導入されました。デフォルトでは制約を基にしたものでなくtypmodジオメトリカラムが生成されます。ジオメトリカラムを空間テーブルから除去します。column_name);説明ジオメトリカラムを空間テーブルから除去します。schema_nameはgeometry_columnsテーブルの該当行のf_table_schemaフィールドと一致しなければならないことにご注意ください。この関数は後方互換のためのものです。TABLEを使った削除が可能です。テーブルとgeometry_columnsの当該テーブルへの参照の全てを削除します。table_name);説明テーブルとgeometry_columnsの当該テーブルへの参照の全てを削除します。スキーマ対応版PostgreSQLではスキーマが与えられない場合はcurrent_schema()を使います。この関数は後方互換のためのものです。TABLEを使った削除が可能です。use_typmod=true);説明ジオメトリカラムが型修飾子で定義されるか、適切な制約を持つことを確実にします。ジオメトリカラムがgeometry_columnsに正しく登録されることを確実にします。デフォルトでは、型修飾子によらないジオメトリカラムを型修飾子によるジオメトリカラムに変換します。以前の挙動にするにはuse_typmod=falseとします。後方互換のためと、それぞれの子テーブルが異なるジオメトリタイプを持つテーブル継承といった空間テーブルにとって必要があるためとの二つの理由から、古いCHECK制約の挙動がなお有効になっています。古い挙動が必要な場合には、新しいオプション引数でuse_typmod=falseを渡す必要があります。これが実行されると、型修飾子なしのジオメトリカラムが生成され、三つの制約が定義されます。これは、テーブルに属するすべてのジオメトリカラムが少なくとも三つの制約を持つことを意味します。(???をご覧下さい)テーブルにoidがある場合には、この関数はテーブルのジオメトリカラム全てについて、SRIDと次元とジオメトリタイプを判定して、必要に応じて制約を追加しようとします。成功した場合には、geometry_columnsに適切な行が追加され、その他の場合には、例外が捕まえられ、問題を記述したエラーが通知されます。ビューのoidがある場合、テーブルの場合と同じで、SIRDと次元とジオメトリタイプを判定して、適切なエントリをgeometry_columnsテーブルに挿入しますが、制約の追加はされません。パラメタの無い形式は、geometry_columnsの行を削除したうえで、全ての空間テーブルと空間ビューについて再挿入し、適切な空間制約をテーブルに追加する、パラメタ付きの形式の単純なラッパです。パラメタが無い形式は、検出したジオメトリカラムの数の要約とgeometry_columnsに挿入された行の数とを返します。パラメタ付きの形式は単純にgeometry_columnsに挿入された行の数を返します。デフォルトでは、ジオメトリタイプの制限について、制約を確認する代わりに型修飾子を使います。新しいuse_typmodをFALSEに設定して使うことで、制約確認を使用することができます。use_typmod任意引数が導入されました。カラムが型修飾子で生成されるか制約チェックで作られるかの制御ができます。srid);説明ジオメトリカラムの全てのフィーチャーのSRID、geometry_columnsメタデータとSRIDテーブル制約を更新します。スキーマ対応版pgsqlでは、スキーマが提供されていない場合には、この関数はcurrent_schema()を使うことにご注意下さい。0)\.この関数は、以前のSRIDに関係なく、道路テーブルのSRIDを4326に変更します。TABLE等が該当します)とは同じです。(またはunknownになっている)けれどもWebメルカトルに一度の処理で変換したい場合、DDLで実行可能ですが、PostGIS管理関数では一度の処理ですむ等価なものはありません。マルチポイントジオメトリからラインストリングを生成します。与えられた最小値と最大値から長方形ポリゴンを生成します。入力値はSRIDで指定された空間参照系でなければなりません。ポイント、マルチポイント、ラインジオメトリからラインストリングを生成します。2次元、XYZの3次元または4次元のポイントジオメトリを生成します。M座標を持つポイントジオメトリを生成します。与えられた座標値のST_Pointを返します。ST_MakePointのOGC別名です。ST_MakeLine(geomarray)が導入されました。ST_MakeLine集約関数はより多くのポイントをより早く扱うための強化が施されています。マルチポイントジオメトリからラインストリングを生成します。aMultiPoint);説明マルチポイントジオメトリからラインストリングを生成します。Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。z-index.例マルチポイントジオメトリからラインストリングを生成します。与えられた最小値と最大値から長方形ポリゴンを生成します。入力値はSRIDで指定された空間参照系でなければなりません。与えられた最小値と最大値から長方形ポリゴンを生成します。入力値はSRIDで指定された空間参照系でなければなりません。SRIDが指定されない場合には、不明な空間参照系と仮定します。SRID指定なしでエンベロープを指定できるようになりました。ポイント、マルチポイント、ラインジオメトリからラインストリングを生成します。マルチポイントの入力要素に対応するようになりました。ラインストリング入力要素が導入されました。ST_MakeLine(geomarray)が導入されました。ST_MakeLine集約関数はより多くのポイントをより早く扱うための強化が施されています。4)与えられた二つの3次元ポイントジオメトリから定義されるBOX3Dを生成します。5)ポイント、マルチポイント、ラインジオメトリからラインストリングを生成します。空間集計版この例では、GPS位置の順列を取り、ジオメトリフィールドがGPSポイントからなるラインストリングで行程順になるよう、行程ごとに一つのレコードを生成します。プランナが副問い合わせの並び順を尊重しない選択を発生させることがあります。2次元、XYZの3次元または4次元のポイントジオメトリを生成します。m);説明2次元、XYZの3次元または4次元のポイントジオメトリを生成します。Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。(M値を持つジオメトリ)のポイントジオメトリを生成します。ST_MakePointはOGC準拠ではありませんが、一般的に???や???より速く、高精度です。WKTでなく生の座標値を持っている場合は扱いやすいです。84経度緯度とするポイントを返します。M座標を持つポイントジオメトリを生成します。M座標を持つポイントジオメトリを生成します。Mのポイントを生成する必要がある場合には、ST_MakePointMを使います。M座標を持つポイントジオメトリを生成します。与えられた外環で形成されるポリゴンを生成します。入力ジオメトリは閉じたラインストリングでなければなりません。constructs.この関数はマルチラインストリングを受け付けません。ST_LineMergeまたはST_Dumpでラインストリングを生成して下さい。配列使用版エンコード化ポリラインからラインストリングを生成します。foo;エンコード化ポリラインからラインストリングを生成します。蟻の穴を持つドーナツの生成です。foo;県ポリゴン/マルチポリゴンと水涯線から、湖を表現する穴を持つ県の境界を構築します。PostGISのST_Accumを使う例です。NULL配列をST_MakePolygonに渡すとNULLを返すのでCASEを使います。配列に変換するPostgreSQL組み込み関数ARRAY()を使っています。与えられた座標値のST_Pointを返します。ST_MakePointのOGC別名です。与えられた座標値のST_Pointを返します。XとYを取るST_MakePointのMM対応の別名です。???この関数はマルチラインストリングを受け付けません。ST_LineMergeまたはST_Dumpでラインストリングを生成して下さい。ST_Geometry値のジオメトリ型を返します。ジオメトリの組み合わせ境界の閉包を返します。—ST_Geometry値の座標次元を返します。—ST_Geometry値の座標次元を返します。ST_LineStringまたはST_CircularStringのポイント数を返します。(float8)バウンディングボックスを表現するジオメトリを返します。与えられたジオメトリのバウンディングボックスの対角線を返します。ポリゴンジオメトリの内環の数を返します。ST_Geometry値のジオメトリ型を返します。ST_Geometry値のジオメトリ型を返します。ポリゴンジオメトリの内環の数を返します。全ての外環が反時計回りで、全ての内環が時計回りならTRUEを返します。入力ジオメトリの全てのポリゴン要素の外環については時計回りで、全ての内環については反時計回りである場合には、TRUEを返します。LINESTRINGの始点と終点が一致する場合にTRUEを返します。(ボリュームであるかどうか)を返します。ジオメトリが、空のジオメトリコレクション、ポリゴン、ポイント等の場合に、trueを返します。ジオメトリが自己インタセクションや自己接触のような異常な幾何学ポイントを持っていない場合にTRUEを返します。ST_Geometry値のジオメトリ型を返します。—ST_Geometry値の座標次元を返します。(頂点)数を返します。ポリゴンジオメトリの内環の数を返します。ジオメトリのポイントの数を返します。全てのジオメトリに対して動作します。ポリゴンジオメトリの内環の数を返します。ジオメトリ内のポリゴンの内環の数を返します。ST_NumInteriorRingsと同義です。多面体サーフェスのフェイス数を返します。多面体でないジオメトリの場合にはNULLを返します。ST_LineStringまたはST_CircularStringのポイント数を返します。ST_Geometry値のジオメトリ型を返します。ST_LineStringまたはST_CircularStringのポイント数を返します。ジオメトリの全ての座標値からなるマルチポイントを返します。—ジオメトリについての要約文を返します。ST_Geometry値の座標次元を返します。ST_Geometry値のジオメトリ型を返します。'MULTIPOINT'などの文字列で返します。このジオメトリインスタンスがメンバーになっているジオメトリのインスタンス化可能な派生タイプの名前を返します。インスタンス化可能な派生タイプの名前は、文字列として返されます。この関数は、'POINTM'等が返るので、ジオメトリがM値を持っているかどうかも示します。多面体サーフェス対応、三角対応、TIN対応が導入されました。ジオメトリの組み合わせ境界の閉包を返します。ラインストリングは端点、ポリゴンはエッジ、複合オブジェクトは境界のうち奇数番)。組み合わせ境界はOGC仕様の3.12.3.2節に記述されています。3.12.2で議論されているように、ジオメトリプリミティブを使って表現できます。GEOSモジュールによって実現しています。2.0.0より前の版では、この関数はGEOMETRYCOLLECTION.を与えると例外を投げました。2.1.0で三角対応が導入されました。—ST_Geometry値の座標次元を返します。geomA);説明ST_Geometry値の座標次元を返します。この関数はST_NDimsのMM対応の別名です。—ST_Geometry値の座標次元を返します。g);説明ジオメトリの固有次元を返します。ジオメトリは座標次元以下でなければなりません。0ならPOINT、1ならLINESTRING、2ならPOLYGONで、GEOMETRYCOLLECTIONの場合は要素ごとの次元の最大値です。(空ジオメトリ)の場合はNULLが返ります。多面体サーフェス対応とTIN対応が導入されました。空ジオメトリを与えた場合に例外を投げなくなりました。2.0.0より前では、空ジオメトリを与えると例外を投げていました。多面体サーフェス対応、三角対応、TIN対応が導入されました。higher.1.3.4より前では、曲線を含むジオメトリで使用すると、この関数はクラッシュします。これは1.3.4以上で訂正されています。多面体サーフェスをフェイスに分解します。多面体サーフェス対応、三角対応、TIN対応が導入されました。higher.この関数はマルチポリゴンでは動作しません。マルチポリゴンに対してはST_Dumpを併用して下さい。ST_LineStringまたはST_CircularStringのポイント数を返します。);説明LINESTRINGの最後のポイントをPOINTで返します。パラメタがLINESTRINGでない場合はNULLを返します。2.0.0では単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。古い挙動は記載されていませんでしたが、LINESTRINGとして格納されているデータを持っていると思われる人々は2.0でNULLが返って来ることを経験することでしょう。(float8)バウンディングボックスを表現するジオメトリを返します。g1);説明ジオメトリのfloat8数の最小バウンディングボックスをジオメトリとして返します。MINY))となります。可能ならZMIN/ZMAX座標が追加されます。(縦のライン、ポイント)はPOLYGONより低い次元のジオメトリ、すなわちPOINTまたはLINESTRINGを返します。挙動が変更され出力がfloat4からfloat8になりました。与えられたジオメトリのバウンディングボックスの対角線を返します。与えられたジオメトリのバウンディングボックスの対角線をラインストリングで返します。入力ジオメトリが空の場合には、対角線も空になります。その他の場合には、最小値のポイントを始点とし、最大値のポイントを終点とする、二つのポイントからなるラインストリングになります。(ZとMがあること)を維持します。fitsパラメータは、最良適合が必要かどうかを指定するものです。(多数の頂点からなるジオメトリの取得が早くなります)。いずれにしても返された対角線のバウンディングボックスは常に入力ジオメトリを含みます。返り値を意味的な不正にはしません。ポリゴンジオメトリの内環の数を返します。a_polygon);説明POLYGONの外環を表現するラインストリングを返します。ジオメトリがポリゴンでない場合はNULLを返します。POLYGONタイプでのみ動作します。それぞれのポリゴンの外環からなるマルチラインストリングを返させたいとします。ST_Geometry値のジオメトリ型を返します。POLYHEDRALSURFACEの場合には、1始まりでN番目のジオメトリを返します。それ以外の場合にはNULLを返します。OGC仕様のため0.8.0版からインデクスを1始まりにしています。これより前の版では0始まりになっています。一つのジオメトリから全てのジオメトリを抽出したい場合は、ST_Dumpを使う方が効果的ですし、単一ジオメトリにも対応しています。多面体サーフェス対応、三角対応、TIN対応が導入されました。以前の版では非マルチのジオメトリではNULLが返りました。ST_GeometryN(..,1)の場合にはジオメトリを返すよう変更されました。多面体サーフェスをフェイスに分解します。ST_Geometry値のジオメトリ型を返します。'ST_MultiPolygon'等の文字列で返します。この関数はGeometryType(geometry)とは異なり、先頭に'ST'が付き、M値を持っているかを示しません。多面体サーフェス対応が導入されました。geomA);説明ジオメトリが、空のジオメトリコレクション、ポリゴン、ポイント等の場合に、trueを返します。ポリゴンジオメトリの内環の数を返します。n);説明ポリゴンのN番目の内環となるラインストリングを返します。ジオメトリがポリゴンでないかNが範囲外の場合はNULLを返します。この関数はマルチポリゴンでは動作しません。マルチポリゴンに対してはST_Dumpを併用して下さい。全ての外環が反時計回りで、全ての内環が時計回りならTRUEを返します。入力ジオメトリの全てのポリゴン要素の外環については反時計回りで、全ての内環については時計回りである場合には、TRUEを返します。ジオメトリがポリゴン要素を持っていない場合にはTRUEを返します。閉じたラインストリングはポリゴン要素とみなされません。単一の閉じたラインストリングを渡すと、右回り左回りにかかわらずTRUEが得られます。両方ともにFALSEを返します。入力ジオメトリの全てのポリゴン要素の外環については時計回りで、全ての内環については反時計回りである場合には、TRUEを返します。入力ジオメトリの全てのポリゴン要素の外環については時計回りで、全ての内環については反時計回りである場合には、TRUEを返します。ジオメトリがポリゴン要素を持っていない場合にはTRUEを返します。閉じたラインストリングはポリゴン要素とみなされません。単一の閉じたラインストリングを渡すと、右回り左回りにかかわらずTRUEが得られます。両方ともにFALSEを返します。LINESTRINGの始点と終点が一致する場合にTRUEを返します。(ボリュームであるかどうか)を返します。g);説明LINESTRINGの始点と終点が一致する場合にTRUEを返します。(閉じているか)を返します。9.3.3SQL-MMではST_IsClosed(NULL)は0を返しますが、PostGISではNULLを返します。多面体サーフェス対応が導入されました。ジオメトリが、空のジオメトリコレクション、ポリゴン、ポイント等の場合に、trueを返します。引数が次のいずれかの場合にはTRUEを返します。ジオメトリコレクションマルチポイント、マルチポリゴン、マルチラインストリング、マルチ曲線、マルチサーフェス複合曲線この関数はジオメトリのタイプを解析します。これは、空のコレクションである場合、または一つのエレメントを持つコレクションである場合にはTRUEを返すことを意味します。geomA);説明ジオメトリが空ジオメトリの場合にtrueを返します。trueの場合には、このジオメトリは、空のジオメトリコレクション、ポリゴン、ポイント等です。SQL-MMでは、ST_IsEmpty(NULL)は0を返しますが、PostGISではNULLを返します。以前の版のPostGISではST_GeomFromText('GEOMETRYCOLLECTION(EMPTY)')を許しました。2.0.0では、SQL/MM標準により準拠させるため、これは不正となります。(自己インタセクションが無い)場合にTRUEを返します。7.1.6SQL-MMでは、ST_IsRing(NULL)は0を返しますが、PostGISではNULLを返します。ジオメトリが自己インタセクションや自己接触のような異常な幾何学ポイントを持っていない場合にTRUEを返します。geomA);説明ジオメトリが自己インタセクションや自己接触のような異常な幾何学ポイントを持っていない場合にTRUEを返します。OGCのジオメトリ単純性と妥当性の定義に関する詳細情報については「ジオメトリのOpenGIS準拠を確実にする」をご覧ください。SQL-MMでは、ST_IsSimple(NULL)は0を返しますが、PostGISではNULLを返します。a_point);説明ポイントのM座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。(いまだに)OGC仕様に入っていませんが、ポイント座標抽出関数のリストを完全にするために挙げています。ST_Geometry値のジオメトリ型を返します。geomA);説明ST_Geometry値のジオメトリ型を返します。—ST_Geometry値の座標次元を返します。g1);説明ジオメトリの座標次元返します。(X,Y,Z,M)に対応しています。(頂点)数を返します。g1);説明ジオメトリのポイントの数を返します。全てのジオメトリに対して動作します。多面体サーフェス対応が導入されました。1.3.4より前では、曲線を含むジオメトリで使用すると、この関数はクラッシュします。これは1.3.4以上で訂正されています。ポリゴンジオメトリの内環の数を返します。geomA);説明ジオメトリがポリゴンまたはマルチポリゴンの場合、リング数を返します。NumInteriorRingsと違い、外環も数えます。ジオメトリのポイントの数を返します。全てのジオメトリに対して動作します。geom);説明ジオメトリの数を返します。ジオメトリがジオメトリコレクションまたはマルチ系の場合は、ジオメトリの数を返し、単一のジオメトリの場合は1を返し、それ以外の場合はNULLを返します。多面体サーフェス対応、三角対応、TIN対応が導入されました。前の版では、ジオメトリがコレクション/マルチ系でない場合にはNULLを返しました。POINTといった単一ジオメトリについては1を返します。マルチ系はコレクションで一つのジオメトリと数えます。ポリゴンジオメトリの内環の数を返します。a_polygon);説明ポリゴンジオメトリの内環の数を返します。ジオメトリがポリゴンでない場合には、NULLを返します。以前の版では、MULTIPOLYGONを渡して最初のPOLYGONの内環の数を返すことができました。ジオメトリ内のポリゴンの内環の数を返します。ST_NumInteriorRingsと同義です。多面体サーフェスのフェイス数を返します。多面体でないジオメトリの場合にはNULLを返します。多面体サーフェスのフェイス数を返します。多面体でないジオメトリの場合にはNULLを返します。ST_NumGeometriesの別名で、MMの名前付けに対応するためのものです。MM規約を気にしない場合はST_NumGeometriesの方が速いです。ST_LineStringまたはST_CircularStringのポイント数を返します。g1);説明ST_LineStringまたはST_CircularStringのポイント数を返します。1.4より前は仕様通りにラインストリングにのみ対応していました。1.4以上ではラインストリングだけでなく頂点数を返すST_NPointsの別名です。多目的で多数のジオメトリタイプで動作するST_NPointsを使うことを考えて下さい。ST_Geometry値のジオメトリ型を返します。(フェイス)を返します。それ以外の場合には、NULLを返します。多面体サーフェスを引数にとるST_GeometryNと同じ答えが返ります。ST_GeometryNの方が速いです。インデクスは1始まりです。一つのジオメトリから全てのジオメトリを抽出したい場合は、ST_Dumpを使う方が効率的です。ST_LineStringまたはST_CircularStringのポイント数を返します。n);説明ラインストリングまたは曲線ストリングのN番目の点を返します。負数はラインストリングの終端から逆方向に遡って数えます。-1は終端を指します。ジオメトリにラインストリングが無い場合には、NULLを返します。OGC仕様のため0.8.0版からインデックスを1始まりにしています。これより前の版では0はじまりになっています。(負数インデックス)はOGC仕様ではありません。マルチラインストリングからN番目のポイントを得たい場合には、ST_Dumpを併用して下さい。単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。ジオメトリの全ての座標値からなるマルチポイントを返します。);説明ジオメトリの全ての座標値からなるマルチポイントを返します。(この挙動を望まない場合にはST_RemoveRepeatedPointsを使って消します)。M値とZ値は、存在する場合には保存されます。geomA);説明LINESTRINGまたはCIRCULARLINESTRINGジオメトリの、最初のポイントをPOINTで返します。入力パラメータがLINESTRINGでもCIRCULARLINESTRINGでもない場合には、NULLを返します。2.0.0では単一ジオメトリのMULTILINESTRINGで動作しなくなりました。単一のラインストリングからなるMULTILINESTRINGについては幸運にも動いていて、最初のポイントを返していました。2.0.0では他のMULTILINESTRINGと同様にNULLを返すようになりました。古い挙動は記載されていませんでしたが、LINESTRINGとして格納されているデータを持っていると思われる人々は2.0でNULLが返って来ることを経験することでしょう。—ジオメトリについての要約文を返します。g);説明ジオメトリについての要約文を返します。ジオメトリ型の後の角括弧で示されたフラグには次の意味があります。2.0.0でジオグラフィ対応が追加されました。空間参照系を持つかを示すSフラグが追加されました。TINと曲線の対応が追加されました。a_point);説明ポイントのX座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。a_point);説明ポイントのY座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。a_point);説明ポイントのZ座標値を返し、有効でないならNULLを返します。入力はポイントでなければなりません。ST_Geometry値の座標次元を返します。geomA);説明ST_Geometry値の座標次元を返します。ラインストリングにポイントを追加します。(マルチ)ジオメトリを返します。ジオメトリコレクションを与えると、「最も単純な」表現を返します。ジオメトリを2次元モードに強制します。ジオメトリをXYZモードに強制します。これはST_Force3DZの別名です。ジオメトリをXYZモードに強制します。ジオメトリをXYMモードに強制します。ジオメトリをXYZMモードに強制します。全ての外環を反時計回りに、全ての内環を時計回りに、それぞれ強制します。ジオメトリをジオメトリコレクションに変換します。全ての外環を時計回りに、全ての内環を反時計回りに、それぞれ強制します。1.1ジオメトリタイプのみ使うようジオメトリに強制します。ポリゴンの頂点の方向を右回りに強制します。該当する場合は、ジオメトリを曲線タイプに変換します。(またはその集合)を返します。マルチ系ジオメトリを返します。標準的な形式に変えたジオメトリを返します。ラインストリングからポイントを削除します。頂点の順序を逆にしたジオメトリを返します。与えた距離を超える線分を持たないよう変更したジオメトリ/ジオグラフィを返します。ラインストリングのポイントを与えられたポイントに置き換えます。入力ジオメトリの全ての点を規則的なグリッドにスナップします。入力ジオメトリの辺と頂点を参照ジオメトリの頂点にスナップします。頂点の順序を逆にしたジオメトリを返します。ラインストリングにポイントを追加します。(0はじまり)の前にポイントを追加します。第3引数に-1を指定すると末尾に追加できます。(マルチ)ジオメトリを返します。(マルチ)ジオメトリを返します。指定したタイプでないジオメトリ要素は無視されます。正しいタイプのジオメトリ要素が無い場合はEMPTYジオメトリが返ります。ポイント、ラインストリング、ポリゴンのみをサポートします。1.5.01.5.3より前では、この関数は、非コクレションの入力については手を付けずに問題のないタイプで返しました。1.5.3では、適合しない単一ジオメトリについてはNULLを返しました。2.0.0では、適合するジオメトリが無い場合は常にEMPTYを返すようになりました。POLYGONを指定すると、エッジが共有されていたとしてもマルチポリゴンが返ります。この関数をST_Splitの結果への適用の多くの場合に不正なマルチポリゴンとなります。ジオメトリコレクションを与えると、「最も単純な」表現を返します。collection);説明ジオメトリコレクションを与えると、「最も単純な」表現を返します。非マルチなタイプは非マルチのタイプを返します。同質なコレクションは適切なマルチ系タイプを返します。POLYGONを指定すると、エッジが共有されていたとしてもマルチポリゴンが返ります。この関数をST_Splitの結果への適用の多くの場合に不正なマルチポリゴンとなります。ジオメトリを2次元モードに強制します。geomA);説明ジオメトリを「2次元モード」に強制させます。全ての出力表現はXY座標値のみを持つことになります。(OGCは2次元ジオメトリのみ策定しています)に強制するために使われます。多面体サーフェス対応が導入されました。2.0.xの間はST_Force_2Dと呼ばれていました。ジオメトリをXYZモードに強制します。これはST_Force3DZの別名です。geomA);説明ジオメトリをXYZモードに強制します。これはST_Force_3DZの別名です。ジオメトリがZ値を持っていない場合は0のZ値を追加します。多面体サーフェス対応が導入されました。2.0.xの間はST_Force_3Dと呼ばれていました。ジオメトリをXYZモードに強制します。geomA);説明ジオメトリをXYZモードに強制します。これはST_Force3Dと同義です。