PostGIS - en to ja translation catalogue (352 entries)

note: Tag: title
en: Data Management
ja: データ管理

note: Tag: title
en: Spatial Data Model
ja: 空間データ モデル

note: Tag: title
en: OGC Geometry
ja: OGC ジオメトリ

note: Tag: para
en: The Open Geospatial Consortium (OGC) developed the <ulink url="https://www.ogc.org/standards/sfa"><emphasis>Simple Features Access</emphasis></ulink> standard (SFA) to provide a model for geospatial data. It defines the fundamental spatial type of <emphasis role="bold">Geometry</emphasis>, along with operations which manipulate and transform geometry values to perform spatial analysis tasks. PostGIS implements the OGC Geometry model as the PostgreSQL data types <link linkend="PostGIS_Geometry">geometry</link> and <link linkend="PostGIS_Geography">geography</link>.
ja: Open Geospatial Consortium (OGC)は、地理空間データのモデルを提供するために<ulink url="https://www.ogc.org/standards/sfa"><emphasis>Simple Features Access</emphasis></ulink> (SFA)標準を開発しました。これは、<emphasis role="bold">ジオメトリ (Geometry)</emphasis>の基本的な空間タイプを、空間解析処理実行のための操作や変換といった演算に沿って定義します。PostGISは空間解析タスクを実現するためにOGCジオメトリモデル値をPostgreSQLデータ型の<link linkend="PostGIS_Geometry">geometry</link>、<link linkend="PostGIS_Geography">geography</link>として実装しています。

note: Tag: para
en: Geometry is an <emphasis>abstract</emphasis> type. Geometry values belong to one of its <emphasis>concrete</emphasis> subtypes which represent various kinds and dimensions of geometric shapes. These include the <emphasis role="bold">atomic</emphasis> types <link linkend="Point">Point</link>, <link linkend="LineString">LineString</link>, <link linkend="LinearRing">LinearRing</link> and <link linkend="Polygon">Polygon</link>, and the <emphasis role="bold">collection</emphasis> types <link linkend="MultiPoint">MultiPoint</link>, <link linkend="MultiLineString">MultiLineString</link>, <link linkend="MultiPolygon">MultiPolygon</link> and <link linkend="GeometryCollection">GeometryCollection</link>. The <ulink url="https://portal.ogc.org/files/?artifact_id=25355"><emphasis>Simple Features Access - Part 1: Common architecture v1.2.1</emphasis></ulink> adds subtypes for the structures <link linkend="PolyhedralSurface">PolyhedralSurface</link>, <link linkend="Triangle">Triangle</link> and <link linkend="TIN">TIN</link>.
ja: ジオメトリは<emphasis>抽象的な</emphasis>タイプです。ジオメトリ値は複数ある<emphasis>具体的な</emphasis>サブタイプの一つに属します。サブタイプは様々な種類の様々な次元のジオメトリの形状を表現するものです。これらには<emphasis role="bold">原子的な</emphasis>タイプである<link linkend="Point">ポイント (Point)</link>、<link linkend="LineString">ラインストリング (LineString)</link>、<link linkend="LinearRing">リニアリング (LinearRing)</link>、<link linkend="Polygon">ポリゴン (Polygon)</link>があります。また、<emphasis role="bold">コレクション (collection)</emphasis> (訳注: 「マルチ系」と書いている場合があります)タイプの<link linkend="MultiPoint">マルチポイント (MultiPoint)</link>、<link linkend="MultiLineString">マルチラインストリング (MultiLineString)</link>、<link linkend="MultiPolygon">マルチポリゴン (MultiPolygon)</link>、<link linkend="GeometryCollection">ジオメトリコレクション (GeometryCollection)</link>があります。 <ulink url="https://portal.ogc.org/files/?artifact_id=25355"><emphasis>Simple Features Access - Part 1: Common architecture v1.2.1</emphasis></ulink>では<link linkend="PolyhedralSurface">多面体サーフェス (PolyhedralSurface)</link>、<link linkend="Triangle">三角形 (Triangle)</link>、<link linkend="TIN">TIN</link>が追加されています。

note: Tag: para
en: Geometry models shapes in the 2-dimensional Cartesian plane. The PolyhedralSurface, Triangle, and TIN types can also represent shapes in 3-dimensional space. The size and location of shapes are specified by their <emphasis role="bold">coordinates</emphasis>. Each coordinate has a X and Y <emphasis role="bold">ordinate</emphasis> value determining its location in the plane. Shapes are constructed from points or line segments, with points specified by a single coordinate, and line segments by two coordinates.
ja: ジオメトリは2次元デカルト平面上の形状をモデル化しています。多面体サーフェス、三角形、TINは3次元空間内の形状を表現することもできます。形状のサイズと位置は<emphasis role="bold">座標</emphasis>によって指定されます。それぞれの座標は、平面上で位置を判定するXとYの<emphasis role="bold">座標軸</emphasis>値を持っています。形状はポイントと線分から構築され、ポイントは単一の座標で定められ、線分は二つの座標値から定められます。

note: Tag: para
en: Coordinates may contain optional Z and M ordinate values. The Z ordinate is often used to represent elevation. The M ordinate contains a measure value, which may represent time or distance. If Z or M values are present in a geometry value, they must be defined for each point in the geometry. If a geometry has Z or M ordinates the <emphasis role="bold">coordinate dimension</emphasis> is 3D; if it has both Z and M the coordinate dimension is 4D.
ja: 座標は任意軸ZとMを持つことができます。Z軸はしばしば標高を示すために使われます。M軸は計測値が入りますが、計測値は時間であったり距離であったりします。Z値またはM値はジオメトリ値の中にあり、ジオメトリの各ポイントで定義されているものです。ジオメトリがZ値またはM値を持っている場合には<emphasis role="bold">座標次元</emphasis>は三次元です。Z値とM値の両方を持っている場合には四次元です。

note: Tag: para
en: Geometry values are associated with a <emphasis role="bold">spatial reference system</emphasis> indicating the coordinate system in which it is embedded. The spatial reference system is identified by the geometry SRID number. The units of the X and Y axes are determined by the spatial reference system. In <emphasis role="bold">planar</emphasis> reference systems the X and Y coordinates typically represent easting and northing, while in <emphasis role="bold">geodetic</emphasis> systems they represent longitude and latitude. SRID 0 represents an infinite Cartesian plane with no units assigned to its axes. See <xref linkend="spatial_ref_sys"/>.
ja: ジオメトリ値は、そのジオメトリが組み込まれている座標系を示す<emphasis role="bold">空間参照系</emphasis>に関連付けられます。空間参照系はジオメトリのSRID番号で識別されます。X軸とY軸の単位は空間参照系によって決まります。<emphasis role="bold">平面</emphasis>参照系では伝統的にX座標値とY座標値が東、北をそれぞれ示します。<emphasis role="bold">地理</emphasis>参照系では、経度と緯度を表現しています。SRIDが0の場合には、軸の単位が無い、無限の直交平面を表します。<xref linkend="spatial_ref_sys"/>を参照して下さい。

note: Tag: para
en: The geometry <emphasis role="bold">dimension</emphasis> is a property of geometry types. Point types have dimension 0, linear types have dimension 1, and polygonal types have dimension 2. Collections have the dimension of the maximum element dimension.
ja: ジオメトリの<emphasis role="bold">次元</emphasis>は、ジオメトリタイプのプロパティです。ポイントタイプは0次元、ラインタイプは1次元、ポリゴンタイプは2次元、コレクションは要素の次元の最大値、となります。

note: Tag: para
en: A geometry value may be <emphasis role="bold">empty</emphasis>. Empty values contain no vertices (for atomic geometry types) or no elements (for collections).
ja: ジオメトリ値は<emphasis role="bold">empty</emphasis>になることがあります。空値とは、非マルチ系ジオメトリの場合は頂点を持っていないという意味で、コレクションでは要素を持っていないという意味です。

note: Tag: para
en: An important property of geometry values is their spatial <emphasis role="bold">extent</emphasis> or <emphasis role="bold">bounding box</emphasis>, which the OGC model calls <emphasis role="bold">envelope</emphasis>. This is the 2 or 3-dimensional box which encloses the coordinates of a geometry. It is an efficient way to represent a geometry's extent in coordinate space and to check whether two geometries interact.
ja: ジオメトリ値の重要なプロパティは<emphasis role="bold">範囲 (extent)</emphasis>または<emphasis role="bold">バウンディングボックス (bounding box)</emphasis>です。OGCモデルでは<emphasis role="bold">エンベロープ (envelope)</emphasis>と呼ばれています。これは、ジオメトリの座標を囲む2次元または3次元のボックスです。ジオメトリの座標空間内の範囲を表現するための、また、二つのジオメトリの相互関係をチェックするための、効率の良い方法です。

note: Tag: para
en: The geometry model allows evaluating topological spatial relationships as described in <xref linkend="DE-9IM"/>. To support this the concepts of <emphasis role="bold">interior</emphasis>, <emphasis role="bold">boundary</emphasis> and <emphasis role="bold">exterior</emphasis> are defined for each geometry type. Geometries are topologically closed, so they always contain their boundary. The boundary is a geometry of dimension one less than that of the geometry itself.
ja: ジオメトリモデルでは、<xref linkend="DE-9IM"/>に示されている通り、トポロジ空間関係を評価することができます。これに対応するために、<emphasis role="bold">内部 (interior)</emphasis>、<emphasis role="bold">境界 (boundary)</emphasis>、<emphasis role="bold">外部 (exterior)</emphasis>の概念が、ジオメトリタイプ毎に定義されます。ジオメトリはトポロジ的に閉じていて、常に境界を持っています。境界の次元はジオメトリの次元より1小さくなります。

note: Tag: para
en: The OGC geometry model defines validity rules for each geometry type. These rules ensure that geometry values represents realistic situations (e.g. it is possible to specify a polygon with a hole lying outside the shell, but this makes no sense geometrically and is thus invalid). PostGIS also allows storing and manipulating invalid geometry values. This allows detecting and fixing them if needed. See <xref linkend="OGC_Validity"/>
ja: OGCジオメトリモデルは、ジオメトリタイプ毎に妥当性規則が定義されています。これらの規則によって、ジオメトリ値が現実的な状況を示すようになります (たとえば、外部に穴を持つポリゴンを指定できますが、ジオメトリ的に無意味であり、よって不正とします)。PostGISは不正なジオメトリ値を格納、操作することができます。これによって、必要なら修正できることになります。<xref linkend="OGC_Validity"/>を参照して下さい。

note: Tag: title
en: Point
ja: ポイント (Point)

note: Tag: para
en: A Point is a 0-dimensional geometry that represents a single location in coordinate space.
ja: ポイントは、座標空間内の一つの位置を表現する0次元ジオメトリです。

note: Tag: title
en: LineString
ja: ラインストリング (LineString)

note: Tag: para
en: A LineString is a 1-dimensional line formed by a contiguous sequence of line segments. Each line segment is defined by two points, with the end point of one segment forming the start point of the next segment. An OGC-valid LineString has either zero or two or more points, but PostGIS also allows single-point LineStrings. LineStrings may cross themselves (self-intersect). A LineString is <emphasis role="bold">closed</emphasis> if the start and end points are the same. A LineString is <emphasis role="bold">simple</emphasis> if it does not self-intersect.
ja: ラインストリングは連続する一連の線分で形成される1次元のラインです。線分はそれぞれ2点で定義付けられ、ある線分の終点は次の線分の始点を形成します。OGC妥当なラインストリングには、0または2以上のポイントがあります。ただしPostGISはラインストリングの一つのポイントを許容します。ラインストリングは、自身とクロスする場合があります (自己交差)。始端と終端とが同じ場合にはラインストリングは<emphasis role="bold">閉じた</emphasis>ことになります。自己交差しない場合には、ラインストリングは<emphasis role="bold">単純</emphasis>です。

note: Tag: title
en: LinearRing
ja: リニアリング (LinearRing)

note: Tag: para
en: A LinearRing is a LineString which is both closed and simple. The first and last points must be equal, and the line must not self-intersect.
ja: リニアリングは閉じていて、かつ単純なラインスリングです。始端と終端は同じでなければなりませんし、ラインは自己交差してはなりません。

note: Tag: title
en: Polygon
ja: ポリゴン (Polygon)

note: Tag: para
en: A Polygon is a 2-dimensional planar region, delimited by an exterior boundary (the shell) and zero or more interior boundaries (holes). Each boundary is a <link linkend="LinearRing">LinearRing</link>.
ja: ポリゴンは2次元平面領域です。一つの外側の境界 (殻)と0個以上の内の境界 (穴)とで区切られています。それぞれの境界は<link linkend="LinearRing">リニアリング</link>です。

note: Tag: title
en: MultiPoint
ja: マルチポイント (MultiPoint)

note: Tag: para
en: A MultiPoint is a collection of Points.
ja: マルチポイントはポイントのコレクションです。

note: Tag: title
en: MultiLineString
ja: マルチラインストリング (MultiLineString)

note: Tag: para
en: A MultiLineString is a collection of LineStrings. A MultiLineString is closed if each of its elements is closed.
ja: マルチラインストリングはラインストリングのコレクションです。各要素が閉じている場合には、そのマルチラインストリングは閉じています。

note: Tag: title
en: MultiPolygon
ja: マルチポリゴン (MultiPolygon)

note: Tag: para
en: A MultiPolygon is a collection of non-overlapping, non-adjacent Polygons. Polygons in the collection may touch only at a finite number of points.
ja: マルチポリゴンは相互にオーバラップも隣接もしていないポリゴンのコレクションです。コレクション内のポリゴンの接触は有限数のポイントでのみ可能です。

note: Tag: title
en: GeometryCollection
ja: ジオメトリコレクション (GeometryCollection)

note: Tag: para
en: A GeometryCollection is a heterogeneous (mixed) collection of geometries.
ja: ジオメトリコレクションは、ジオメトリの異種 (混合)のコレクションです。

note: Tag: title
en: PolyhedralSurface
ja: 多面体サーフェス (PolyhedralSurface)

note: Tag: para
en: A PolyhedralSurface is a contiguous collection of patches or facets which share some edges. Each patch is a planar Polygon. If the Polygon coordinates have Z ordinates then the surface is 3-dimensional.
ja: 多角形はサーフェスは、パッチまたはエッジを共有する面の隣接するコレクションです。それぞれのパッチは平面ポリゴンです。ポリゴンがZ値を持つ場合には、サーフェスは3次元になります。

note: Tag: title
en: Triangle
ja: 三角形 (Triangle)

note: Tag: para
en: A Triangle is a polygon defined by three distinct non-collinear vertices. Because a Triangle is a polygon it is specified by four coordinates, with the first and fourth being equal.
ja: 三角形は三つの異なる非共線頂点で定義されるポリゴンです。三角形はポリゴンですので、四つの座標で指定され、一つ目と四つ目は同じです。

note: Tag: para
en: A TIN is a collection of non-overlapping <link linkend="Triangle">Triangle</link>s representing a <ulink url="https://en.wikipedia.org/wiki/Triangulated_irregular_network">Triangulated Irregular Network</ulink>.
ja: TINは<ulink url="https://en.wikipedia.org/wiki/Triangulated_irregular_network">Triangulated Irregular Network</ulink>を表現する、オーバラップしない<link linkend="Triangle">三角形</link>のコレクションです。

note: Tag: title
en: SQL/MM Part 3 - Curves
ja: SQL/MM Part 3 - 曲線

note: Tag: para
en: The <ulink url="https://www.iso.org/obp/ui/#iso:std:iso-iec:13249:-3:ed-5:v1:en"><emphasis>ISO/IEC 13249-3 SQL Multimedia - Spatial</emphasis></ulink> standard (SQL/MM) extends the OGC SFA to define Geometry subtypes containing curves with circular arcs. The SQL/MM types support 3DM, 3DZ and 4D coordinates.
ja: <ulink url="https://www.iso.org/obp/ui/#iso:std:iso-iec:13249:-3:ed-5:v1:en"><emphasis>ISO/IEC 13249-3 SQL Multimedia - Spatial</emphasis></ulink>標準 (SQL/MM) は、OGC SFAを拡張して、曲線ジオメトリを含むサブタイプを定義しています。SQL/MMタイプはXYM, XYZ, XYZMに対応します。

note: Tag: para
en: All floating point comparisons within the SQL-MM implementation are performed to a specified tolerance, currently 1E-8.
ja: SQL-MM実装での全ての浮動小数点数の比較では、所定の丸め誤差があります。現在は1E-8です。

note: Tag: title
en: CircularString
ja: 曲線ストリング (CircularStringCircularString)

note: Tag: para
en: CircularString is the basic curve type, similar to a LineString in the linear world. A single arc segment is specified by three points: the start and end points (first and third) and some other point on the arc. To specify a closed circle the start and end points are the same and the middle point is the opposite point on the circle diameter (which is the center of the arc). In a sequence of arcs the end point of the previous arc is the start point of the next arc, just like the segments of a LineString. This means that a CircularString must have an odd number of points greater than 1.
ja: 曲線ストリングは、基本的な曲線タイプです。線形の世界のラインストリングに似ています。単一の円弧線分は、始点、終点 (1番目と3番目)、弧の他の点の三つの点で定義されます。閉じた円を指定するには、開始点と終了点を同じにし、中間点を対称点 (円弧の中心)に置きます。連続する円弧では、前の円弧の終端と次の円弧の始端とが同じです。よって曲線ストリングは1以上の奇数個のポイントを持つことになります。

note: Tag: title
en: CompoundCurve
ja: 複合曲線 (CompoundCurve)

note: Tag: para
en: A CompoundCurve is a single continuous curve that may contain both circular arc segments and linear segments. That means that in addition to having well-formed components, the end point of every component (except the last) must be coincident with the start point of the following component.
ja: 複合曲線は、曲線区間と直線区間の両方を含むことができる単一の連続した曲線です。このことは、整形された要素を持つことに加えて、全ての要素の最後のポイントは次の要素の最初のポイントでなければならないことを意味します。

note: Tag: title
en: CurvePolygon
ja: 曲線ポリゴン (CurvePolygon)

note: Tag: para
en: A CurvePolygon is like a polygon, with an outer ring and zero or more inner rings. The difference is that a ring can be a CircularString or CompoundCurve as well as a LineString.
ja: 曲線ポリゴンは、外側の輪がひとつで0以上の内側のリングがある点はポリゴンに似ています。違いは、ポリゴンのリングはラインストリングですが曲線ポリゴンのリングは曲線ストリングまたは複合ストリングである点です。

note: Tag: para
en: As of PostGIS 1.4 PostGIS supports compound curves in a curve polygon.
ja: PostGIS 1.4から、PostGISで曲線ポリゴンで複合曲線をサポートするようになりました。

note: Tag: para
en: Example: A CurvePolygon with the shell defined by a CompoundCurve containing a CircularString and a LineString, and a hole defined by a CircularString
ja: 例: CIRCULARSTRINGとLINESTRINGからなるCOMPOUNDCURVEで定義される外殻を持ち、CIRCULARSTRINGで定義される穴を持つCURVEPOLYGON

note: Tag: title
en: MultiCurve
ja: マルチ曲線 (Multicurve)

note: Tag: para
en: A MultiCurve is a collection of curves which can include LineStrings, CircularStrings or CompoundCurves.
ja: マルチ曲線は曲線のコレクションで、ラインストリング、曲線ストリング、複合曲線を含むことができます。

note: Tag: title
en: MultiSurface
ja: マルチサーフェス (MultiSurface)

note: Tag: para
en: A MultiSurface is a collection of surfaces, which can be (linear) Polygons or CurvePolygons.
ja: マルチサーフェスはサーフェスのコレクションです。サーフェスは(線形)ポリゴンまたは曲線ポリゴンとなることができます。

note: Tag: title
en: WKT and WKB
ja: WKTとWKB

note: Tag: para
en: The OGC SFA specification defines two formats for representing geometry values for external use: Well-Known Text (WKT) and Well-Known Binary (WKB). Both WKT and WKB include information about the type of the object and the coordinates which define it.
ja: OGC SFA仕様では、ジオメトリ値を外部で使用するための表現として二つの標準書式が定義されています。Well-Known Text (WKT)とWell-Known Binary (WKB)です。WKTとWKBは両方ともそのオブジェクトを定義するタイプと座標に関する情報を含んでいます。

note: Tag: para
en: Well-Known Text (WKT) provides a standard textual representation of spatial data. Examples of WKT representations of spatial objects are:
ja: Well-Known Text (WKT)で空間データの標準的な文字表現が可能です。空間オブジェクトのWKT表現の例を次に挙げます。

note: Tag: para
en: Input and output of WKT is provided by the functions <xref linkend="ST_AsText"/> and <xref linkend="ST_GeomFromText"/>:
ja: WKTの入出力は関数<xref linkend="ST_AsText"/>と<xref linkend="ST_GeomFromText"/>によって提供されます。

note: Tag: para
en: For example, a statement to create and insert a spatial object from WKT and a SRID is:
ja: 例えば、WKTとSRIDからの空間オブジェクトの生成と挿入のステートメントは次の通りです。

note: Tag: para
en: Well-Known Binary (WKB) provides a portable, full-precision representation of spatial data as binary data (arrays of bytes). Examples of the WKB representations of spatial objects are:
ja: Well-Known Binary (WKB)は、空間データのバイナリデータ (バイト列)で、移植可能かつ正確な表現です。空間オブジェクトのWKB表現を次に挙げます。

note: Tag: para
en: Input and output of WKB is provided by the functions <xref linkend="ST_AsBinary"/> and <xref linkend="ST_GeomFromWKB"/>:
ja: WKBの入出力は関数<xref linkend="ST_AsBinary"/>と<xref linkend="ST_GeomFromWKB"/>が提供されています。次のように使います。

note: Tag: para
en: For example, a statement to create and insert a spatial object from WKB is:
ja: たとえば、WKBから空間オブジェクトの生成、挿入は次のようにします。

note: Tag: title
en: Geometry Data Type
ja: ジオメトリデータタイプ

note: Tag: para
en: PostGIS implements the OGC Simple Features model by defining a PostgreSQL data type called <varname>geometry</varname>. It represents all of the geometry subtypes by using an internal type code (see <xref linkend="GeometryType"/> and <xref linkend="ST_GeometryType"/>). This allows modelling spatial features as rows of tables defined with a column of type <varname>geometry</varname>.
ja: PostGISは、<varname>geometry</varname>というPostgreSQIデータ型を定義して、OGC Simple Features model を実装しています。これで、内部タイプコード (<xref linkend="GeometryType"/>と<xref linkend="ST_GeometryType"/>参照)で全てのジオメトリのサブタイプを表現します。これにより、カラム型で定義されたテーブルの行として、空間地物をモデリングすることが可能となります。

note: Tag: para
en: The <varname>geometry</varname> data type is <emphasis>opaque</emphasis>, which means that all access is done via invoking functions on geometry values. Functions allow creating geometry objects, accessing or updating all internal fields, and compute new geometry values. PostGIS supports all the functions specified in the OGC <ulink url="https://portal.ogc.org/files/?artifact_id=25354"><emphasis>Simple feature access - Part 2: SQL option</emphasis></ulink> (SFS) specification, as well many others. See <xref linkend="reference"/> for the full list of functions.
ja: <varname>geometry</varname>データ型は<emphasis>透過</emphasis>です。ジオメトリ値に関する関数から全てにアクセスできることを意味します。関数によって、ジオメトリオブジェクトの生成、全ての内部フィールドへのアクセスと更新、新しいジオメトリ値の計算が可能です。PostGISは、OGC <ulink url="https://portal.ogc.org/files/?artifact_id=25354"><emphasis>Simple feature access - Part 2: SQL option</emphasis></ulink> (SFS)仕様で定義されている全ての関数に、他の多数の関数とあわせて対応しています。関数の完全な一覧は<xref linkend="reference"/>をご覧下さい。

note: Tag: para
en: PostGIS follows the SFA standard by prefixing spatial functions with "ST_". This was intended to stand for "Spatial and Temporal", but the temporal part of the standard was never developed. Instead it can be interpreted as "Spatial Type".
ja: PostGISは、空間関数にプリフィクス"ST_"を付けて、SFA標準に従っています。これは、"Spatial and Temporal (空間と時間)"を示していますが、標準の時間の部分はまだ開発していません。その代わりに"Spatial Type (空間タイプ)"と解釈できます。

note: Tag: para
en: The SFA standard specifies that spatial objects include a Spatial Reference System identifier (SRID). The SRID is required when creating spatial objects for insertion into the database (it may be defaulted to 0). See <xref linkend="ST_SRID"/> and <xref linkend="spatial_ref_sys"/>
ja: SFA標準は、空間オブジェクトは空間参照系識別子 (SRID)を含むと規程しています。SRIDは、空間オブジェクトをデータベースに挿入するために生成した時に求められます (デフォルトとして0になるかも知れません)。<xref linkend="ST_SRID"/>と<xref linkend="spatial_ref_sys"/>をご覧下さい。

note: Tag: para
en: To make querying geometry efficient PostGIS defines various kinds of spatial indexes, and spatial operators to use them. See <xref linkend="build-indexes"/> and <xref linkend="using-query-indexes"/> for details.
ja: ジオメトリのクエリを効率的にするため、PostGISでは様々な種類の空間インデクスを定義しています。詳細については<xref linkend="build-indexes"/>と<xref linkend="using-query-indexes"/>をご覧下さい。

note: Tag: title
en: PostGIS EWKB and EWKT
ja: PostGIS EWKBとEWKT

note: Tag: para
en: OGC SFA specifications initially supported only 2D geometries, and the geometry SRID is not included in the input/output representations. The OGC SFA specification 1.2.1 (which aligns with the ISO 19125 standard) adds support for 3D (ZYZ) and measured (XYM and XYZM) coordinates, but still does not include the SRID value.
ja: OGC SFA仕様は、まず2次元ジオメトリのみに対応しました。また、入出力表現にジオメトリのSRIDは取り入れていまません。OGC SFA仕様 1.2.1 (ISO 19125標準に準拠)では3次元 (XYZ)とM値 (XYMとXYZM)座標に対応するようになりましたが、SIRD値の取り込みは依然行われていません。

note: Tag: para
en: Because of these limitations PostGIS defined extended EWKB and EWKT formats. They provide 3D (XYZ and XYM) and 4D (XYZM) coordinate support and include SRID information. Including all geometry information allows PostGIS to use EWKB as the format of record (e.g. in DUMP files).
ja: これらの制限のため、PostGISでは拡張書式であるEWKBとEWKTを定義しました。3次元 (XYZ, XYM)と4次元 (XYZN)座標系に対応し、SRID情報を取り込めるようにしました。すべてのジオメトリ情報を含めたので、PostGISはEWKBを格納用書式 (DUMPファイル等)として使えるようになりました。

note: Tag: para
en: EWKB and EWKT are used for the "canonical forms" of PostGIS data objects. For input, the canonical form for binary data is EWKB, and for text data either EWKB or EWKT is accepted. This allows geometry values to be created by casting a text value in either HEXEWKB or EWKT to a geometry value using <varname>::geometry</varname>. For output, the canonical form for binary is EWKB, and for text it is HEXEWKB (hex-encoded EWKB).
ja: PostGISデータオブジェクトの「カノニカルな形式」のためにEWKBとEWKTを使います。入力では、バイナリデータのカノニカルな形式はEWKB、テキストデータについてはEWKBかEWKTが受け付けられます。これにより、HEXEWKBまたはEWKTのテキスト値から<varname>::geometry</varname>を使用してキャストを行い、ジオメトリ値が生成できるようになりました。出力では、バイナリのカノニカルな形式はEWKBで、テキストはHEXEWKB (HEXエンコードを施したEWKB)です。

note: Tag: para
en: For example this statement creates a geometry by casting from an EWKT text value, and outputs it using the canonical form of HEXEWKB:
ja: たとえば、この手続きでは、EWKTテキスト値からのキャストでジオメトリを生成して、HEXWKBのカノニカルな形式を使った出力を行います。

note: Tag: para
en: PostGIS EWKT output has a few differences to OGC WKT:
ja: PostGIS EWKT出力はOGC WKTと次の通り相違点があります。

note: Tag: para
en: For 3DZ geometries the Z qualifier is omitted:
ja: XYZジオメトリでZ修飾子が省略されます。

note: Tag: para
en: For 3DM geometries the M qualifier is included:
ja: M値を含むXYMジオメトリ:

note: Tag: para
en: For 4D geometries the ZM qualifier is omitted:
ja: 4次元ジオメトリでZM修飾子を省略:

note: Tag: para
en: EWKT avoids over-specifying dimensionality and the inconsistencies that can occur with the OGC/ISO format, such as:
ja: EWKTは、次のようにOGC/ISO書式で発生しうる過剰次元と不整合を回避しています。

note: Tag: para
en: PostGIS extended formats are currently a superset of the OGC ones, so that every valid OGC WKB/WKT is also valid EWKB/EWKT. However, this might vary in the future, if the OGC extends a format in a way that conflicts with the PosGIS definition. Thus you SHOULD NOT rely on this compatibility!
ja: PostGISの拡張書式はOGC書式の上位互換であり、全ての妥当なOGC WKB/WKTは妥当なEWKB/EWKTでもあります。しかし、OGCがPostGISの定義と衝突する方法で書式を拡張した場合には、将来的に書式を変更する可能性があります。ゆえに、この互換性に*頼るべきではありません*!

note: Tag: para
en: Examples of the EWKT text representation of spatial objects are:
ja: 空間オブジェクトのEWKTテキスト表現の例:

note: Tag: para
en: SRID=32632;POINT(0 0) -- XY with SRID
ja: SRID=32632;POINT(0 0) -- SRID付きXY

note: Tag: para
en: SRID=4326;MULTIPOINTM(0 0 0,1 2 1) -- XYM with SRID
ja: SRID=4326;MULTIPOINTM(0 0 0,1 2 1) -- SRID付きXYM

note: Tag: para
en: Input and output using these formats is available using the following functions:
ja: これらの書式を使う入出力は次の関数を使うと有効です。

note: Tag: para
en: For example, a statement to create and insert a PostGIS spatial object using EWKT is:
ja: たとえば、EWKTを使ってPostGISの空間オブジェクトを作成し挿入するステートメントは次の通りです。

note: Tag: title
en: Geography Data Type
ja: ジオグラフィデータタイプ

note: Tag: para
en: The PostGIS <varname>geography</varname> data type provides native support for spatial features represented on "geographic" coordinates (sometimes called "geodetic" coordinates, or "lat/lon", or "lon/lat"). Geographic coordinates are spherical coordinates expressed in angular units (degrees).
ja: <varname>geography</varname>データタイプによって地理座標 ("geographic", "geodetic", "lat/lon", "lon/lat"など)上の空間地物表現にネイティブに対応できます。地理座標系は角度 (度)単位で表現される球面座標系です。

note: Tag: para
en: The basis for the PostGIS geometry data type is a plane. The shortest path between two points on the plane is a straight line. That means functions on geometries (areas, distances, lengths, intersections, etc) are calculated using straight line vectors and cartesian mathematics. This makes them simpler to implement and faster to execute, but also makes them inaccurate for data on the spheroidal surface of the earth.
ja: PostGISジオメトリ型の基礎は平面です。平面上の2点間の最短経路は直線です。ジオメトリに関する関数 (面積、距離、長さ、インタセクション等)は直線ベクトルとデカルト平面を使って計算しています。これで実装が簡単になり実行速度も上がりますが、地球の球面の上にあるデータについては不正確になります。

note: Tag: para
en: The PostGIS geography data type is based on a spherical model. The shortest path between two points on the sphere is a great circle arc. Functions on geographies (areas, distances, lengths, intersections, etc) are calculated using arcs on the sphere. By taking the spheroidal shape of the world into account, the functions provide more accurate results.
ja: PostGISジオグラフィというデータ型は球面モデルに基づいています。球面上の2点の最短経路は大円の弧にあたります。ジオグラフィの関数 (面積、距離、長さ、インタセクション等)は球面上の弧を使います。球面上の世界の形状を考慮に入れるので、より正確な結果が得られます。

note: Tag: para
en: Because the underlying mathematics is more complicated, there are fewer functions defined for the geography type than for the geometry type. Over time, as new algorithms are added the capabilities of the geography type will expand. As a workaround one can convert back and forth between geometry and geography types.
ja: 基礎となる数学はより複雑になるため、ジオグラフィ型で定義された関数はジオメトリ型で定義された関数よりも少なくなります。時間が経つにつれて新しいアルゴリズムが追加されて、ジオグラフィの機能が拡大していきます。回避策として、ジオメトリ型とジオグラフィ型との相互変換が可能です。

note: Tag: para
en: Like the geometry data type, geography data is associated with a spatial reference system via a spatial reference system identifier (SRID). Any geodetic (long/lat based) spatial reference system defined in the <varname>spatial_ref_sys</varname> table can be used. (Prior to PostGIS 2.2, the geography type supported only WGS 84 geodetic (SRID:4326)). You can add your own custom geodetic spatial reference system as described in <xref linkend="user-spatial-ref-sys"/>.
ja: ジオグラフィ型は、ジオメトリ型のように、空間参照系識別子 (SRID)を介して空間参照系と関連付けられます。<varname>spatial_ref_sys</varname>テーブルで定義されているあらゆる地理空間参照系 (経度/緯度を使う)が使えます (PostGIS 2.2より前ではジオグラフィ型はWGS 84地理座標系 (SRID:4326)にのみ対応していました)。<xref linkend="user-spatial-ref-sys"/>に書いている通り、独自の空間参照系を追加することもできます。

note: Tag: para
en: For all spatial reference systems the units returned by measurement functions (e.g. <xref linkend="ST_Distance"/>, <xref linkend="ST_Length"/>, <xref linkend="ST_Perimeter"/>, <xref linkend="ST_Area"/>) and for the distance argument of <xref linkend="ST_DWithin"/> are in meters.
ja: 計測関数 (例 <xref linkend="ST_Distance"/>、<xref linkend="ST_Length"/>、<xref linkend="ST_Perimeter"/>、<xref linkend="ST_Area"/>)によって返されるものの単位と、<xref linkend="ST_DWithin"/>の引数で与えられる距離との、空間参照系の単位は、メートルです。

note: Tag: title
en: Creating Geography Tables
ja: ジオグラフィテーブルの生成

note: Tag: para
en: You can create a table to store geography data using the <ulink url="https://www.postgresql.org/docs/current/sql-createtable.html">CREATE TABLE</ulink> SQL statement with a column of type <varname>geography</varname>. The following example creates a table with a geography column storing 2D LineStrings in the WGS84 geodetic coordinate system (SRID 4326):
ja: ジオグラフィデータを格納するテーブルは、SQLステートメント<ulink url="https://www.postgresql.org/docs/current/sql-createtable.html">CREATE TABLE</ulink>に<varname>geography</varname>型のカラムを付けることで生成することができます。2次元ラインストリングをWGS84地理座標系 (SRID 4326)で保存するジオグラフィカラムを持つテーブルを生成する例を次に示します。

note: Tag: para
en: The geography type supports two optional type modifiers:
ja: 二つの任意の型修飾子に対応するジオグラフィ型:

note: Tag: para
en: the spatial type modifier restricts the kind of shapes and dimensions allowed in the column. Values allowed for the spatial type are: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION. The geography type does not support curves, TINS, or POLYHEDRALSURFACEs. The modifier supports coordinate dimensionality restrictions by adding suffixes: Z, M and ZM. For example, a modifier of 'LINESTRINGM' only allows linestrings with three dimensions, and treats the third dimension as a measure. Similarly, 'POINTZM' requires four dimensional (XYZM) data.
ja: 空間の型修飾子は、カラム内で許される形状の種類や次元を規制します。値によって空間型はPOINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTIONが可能です。ジオグラフィ型は曲線や三角形、多面体サーフェスに対応していません。型修飾子に後置詞Z、M、ZMを付けることで、座標次元の制約に対応しています。たとえば、'LINESTRINGM'は、3次元で3番目の軸はMであるラインストリングのみを許します。同様に'POINTZM'では4次元 (XYZM)データが求められます。

note: Tag: para
en: the SRID modifier restricts the spatial reference system SRID to a particular number. If omitted, the SRID defaults to 4326 (WGS84 geodetic), and all calculations are performed using WGS84.
ja: SRID修飾子は空間参照系(SRID)を特定の数値になるよう制約します。省略した場合には、デフォルトは4326 (WGS84地理座標系)となり、全ての計算はWGS84を使ったものになります。

note: Tag: para
en: Examples of creating tables with geography columns:
ja: ジオグラフィカラムを持つテーブルの生成の例を次に挙げます。

note: Tag: para
en: Create a table with 2D POINT geography with the default SRID 4326 (WGS84 long/lat):
ja: SRIDがデフォルトの4326 (WGS84 経度/緯度)である2次元ポイントジオグラフィを持つテーブルの生成:

note: Tag: para
en: Create a table with 2D POINT geography in NAD83 longlat:
ja: NAD83緯度/経度の2次元ポイントジオグラフィを持つテーブルの生成:

note: Tag: para
en: Create a table with 3D (XYZ) POINTs and an explicit SRID of 4326:
ja: SRIDを4326で明示した3次元 (XYZ)ポイントジオグラフィを持つテーブルの生成:

note: Tag: para
en: Create a table with 2D LINESTRING geography with the default SRID 4326:
ja: SRIDがデフォルトの4326である2次元ラインストリングジオグラフィを持つテーブルの生成:

note: Tag: para
en: Create a table with 2D POLYGON geography with the SRID 4267 (NAD 1927 long lat):
ja: SRIDがデ4326 (NAD 1927 経度/緯度)である2次元ポリゴンジオグラフィを持つテーブルの生成:

note: Tag: para
en: Geography fields are registered in the <varname>geography_columns</varname> system view. You can query the <varname>geography_columns</varname> view and see that the table is listed:
ja: ジオグラフィカラムは<varname>geography_columns</varname>システムビューに登録されます。<varname>geography_columns</varname>ビューにクエリを出してテーブルを見るには、次の通りにします。

note: Tag: para
en: Creating a spatial index works the same as for geometry columns. PostGIS will note that the column type is GEOGRAPHY and create an appropriate sphere-based index instead of the usual planar index used for GEOMETRY.
ja: 空間インデックスはジオメトリカラムと同じように機能します。PostGISは、カラム型がジオグラフィであると通知したうえで、ジオメトリに使う通常の平面用インデックスでなく、球面を基にした適切なインデックスを生成します。

note: Tag: title
en: Using Geography Tables
ja: ジオグラフィテーブルの使用

note: Tag: para
en: You can insert data into geography tables in the same way as geometry. Geometry data will autocast to the geography type if it has SRID 4326. The <link linkend="EWKB_EWKT">EWKT and EWKB</link> formats can also be used to specify geography values.
ja: ジオメトリと同じ方法でジオグラフィテーブルにデータを挿入できます。ジオメトリデータは、SRID 4326の場合には、ジオグラフィ型に自動キャストされます。<link linkend="EWKB_EWKT">EWKTとEWKB</link>書式はジオグラフィ値を指定するために使うことができます。

note: Tag: para
en: Any geodetic (long/lat) spatial reference system listed in <varname>spatial_ref_sys</varname> table may be specified as a geography SRID. Non-geodetic coordinate systems raise an error if used.
ja: <varname>spatial_ref_sys</varname>テーブルにある地理 (経度/緯度)参照系は、ジオグラフィのSRIDとして指定することができます。非地理座標系を使うとエラーが発生します。

note: Tag: para
en: Query and measurement functions use units of meters. So distance parameters should be expressed in meters, and return values should be expected in meters (or square meters for areas).
ja: クエリと計測関数はメートル単位となります。そのため距離パラメータはメートル (面積の場合は平方メートル)単位となります。

note: Tag: para
en: You can see the power of geography in action by calculating how close a plane flying a great circle route from Seattle to London (LINESTRING(-122.33 47.606, 0.0 51.5)) comes to Reykjavik (POINT(-21.96 64.15)) (<ulink url="http://gc.kls2.com/cgi-bin/gc?PATH=SEA-LHR">map the route</ulink>).
ja: シアトルからロンドンへの (LINESTRING(-122.33 47.606, 0.0 51.5))大円航路を行く航空機がレイキャビク (POINT(-21.96 64.15)) にどれだけ近づくかを計算することで、ジオグラフィの力を見ことができます (<ulink url="http://gc.kls2.com/cgi-bin/gc?PATH=SEA-LHR">航路の地図表示</ulink>)。

note: Tag: para
en: The geography type calculates the true shortest distance of 122.235 km over the sphere between Reykjavik and the great circle flight path between Seattle and London.
ja: ジオグラフィ型は、レイキャビクとシアトル－ロンドン間の大円航路との距離について、球面上で122.235 kmという本当の最短距離を計算します。

note: Tag: para
en: The geometry type calculates a meaningless cartesian distance between Reykjavik and the straight line path from Seattle to London plotted on a flat map of the world. The nominal units of the result is "degrees", but the result doesn't correspond to any true angular difference between the points, so even calling them "degrees" is inaccurate.
ja: ジオメトリ型では、平面の世界地図上で見て、レイキャビクとシアトル－ロンドン間の直線とのデカルト距離が計算され、意味がありません。計算結果の名目上の単位は「度」ですが、点間の本当の角度差に応じるものではなく、「度」と呼ぶこと自体が不正確です。

note: Tag: title
en: When to use the Geography data type
ja: ジオグラフィ型を使用すべき時

note: Tag: para
en: The geography data type allows you to store data in longitude/latitude coordinates, but at a cost: there are fewer functions defined on GEOGRAPHY than there are on GEOMETRY; those functions that are defined take more CPU time to execute.
ja: ジオグラフィ型によって、経度緯度座標でデータを格納できるようになりましたが、ジオグラフィで定義されている関数が、ジオメトリより少ないのと、実行にCPU時間がかかる、というところが犠牲になっています。

note: Tag: para
en: The data type you choose should be determined by the expected working area of the application you are building. Will your data span the globe or a large continental area, or is it local to a state, county or municipality?
ja: 選択した型が、期待する領域から出ないことを、ジオメトリ型にして使用する条件とすべきです。使用するデータは地球全体か、大陸か、州か、自治体か?

note: Tag: para
en: If your data is contained in a small area, you might find that choosing an appropriate projection and using GEOMETRY is the best solution, in terms of performance and functionality available.
ja: データが小さいエリア内におさまるなら、適切な投影を選択してジオメトリを使うのが、効率面でも機能面でも最も良い方法です。

note: Tag: para
en: If your data is global or covers a continental region, you may find that GEOGRAPHY allows you to build a system without having to worry about projection details. You store your data in longitude/latitude, and use the functions that have been defined on GEOGRAPHY.
ja: データが地球全体か大陸なら、ジオグラフィで投影法の細かい問題を気にせずにシステムを構築できるでしょう。経度/緯度のデータを保存して、ジオグラフィで定義された関数使います。

note: Tag: para
en: If you don't understand projections, and you don't want to learn about them, and you're prepared to accept the limitations in functionality available in GEOGRAPHY, then it might be easier for you to use GEOGRAPHY than GEOMETRY. Simply load your data up as longitude/latitude and go from there.
ja: 投影法を理解していなくて、学習したくもなくて、かつ、ジオグラフィで使える関数が限られていることを受け入れるのなら、ジオグラフィを使った方が簡単です。単純にデータを経度/緯度でロードして、そこから進めて下さい。

note: Tag: para
en: Refer to <xref linkend="PostGIS_TypeFunctionMatrix"/> for compare between what is supported for Geography vs. Geometry. For a brief listing and description of Geography functions, refer to <xref linkend="PostGIS_GeographyFunctions"/>
ja: ジオグラフィとジオメトリ間のサポート状況の比較については<xref linkend="PostGIS_TypeFunctionMatrix"/>をご覧下さい。ジオグラフィ関数の簡潔なリストと説明については<xref linkend="PostGIS_GeographyFunctions"/>をご覧下さい。

note: Tag: title
en: Geography Advanced FAQ
ja: ジオグラフィに関する高度なよくある質問

note: Tag: para
en: Do you calculate on the sphere or the spheroid?
ja: 球または回転楕円体のどちらで計算するのでしょうか?

note: Tag: para
en: By default, all distance and area calculations are done on the spheroid. You should find that the results of calculations in local areas match up will with local planar results in good local projections. Over larger areas, the spheroidal calculations will be more accurate than any calculation done on a projected plane.
ja: デフォルトでは、全ての距離と面積の計算は回転楕円体で行います。局所的なエリアでの計算結果と良好な投影を施した平面での結果と比較して下さい。大きなエリアの場合は、回転楕円体計算は、投影平面上でのどの計算よりも精度が高くなります。

note: Tag: para
en: All the geography functions have the option of using a sphere calculation, by setting a final boolean parameter to 'FALSE'. This will somewhat speed up calculations, particularly for cases where the geometries are very simple.
ja: 全てのジオグラフィ関数には、最後の真偽パラメータを'FALSE'にすると球面を使った計算を行うというオプションがあります。これは、特にジオメトリが非常に単純である場合に計算を速くするためのものです。

note: Tag: para
en: What about the date-line and the poles?
ja: 日付変更線や極に関してはどうなっていますか?

note: Tag: para
en: All the calculations have no conception of date-line or poles, the coordinates are spherical (longitude/latitude) so a shape that crosses the dateline is, from a calculation point of view, no different from any other shape.
ja: 全ての計算に日付変更線や極の概念がありません。座標は球 (経度/緯度)であるので、日付変更線とクロスする形状は、計算の観点からは、他のものと変わりありません。

note: Tag: para
en: What is the longest arc you can process?
ja: 処理できる最も長い弧はどうなりますか?

note: Tag: para
en: We use great circle arcs as the "interpolation line" between two points. That means any two points are actually joined up two ways, depending on which direction you travel along the great circle. All our code assumes that the points are joined by the *shorter* of the two paths along the great circle. As a consequence, shapes that have arcs of more than 180 degrees will not be correctly modelled.
ja: 大圏の弧を2点の「補完線」として使用しています。任意の2点は、実際には2方向につながっていて、どちらの方向に行くかに依存します。PostGISの全てのコードは、大圏コースの2コースのうち*短い*方でつながっていると仮定しています。結果として、180度以上の弧を持つ形状は正しくモデル化されません。

note: Tag: para
en: Why is it so slow to calculate the area of Europe / Russia / insert big geographic region here ?
ja: なぜヨーロッパやロシアといった大きな範囲の面積計算はとても遅いのですか?

note: Tag: para
en: Because the polygon is so darned huge! Big areas are bad for two reasons: their bounds are huge, so the index tends to pull the feature no matter what query you run; the number of vertices is huge, and tests (distance, containment) have to traverse the vertex list at least once and sometimes N times (with N being the number of vertices in the other candidate feature).
ja: ポリゴンがとんでもなく大きいからです。二つの理由から、大きなエリアは悪いです。一つは、バウンダリボックスが大きいため、どのようなクエリを走らせても、インデックスがフィーチャーを引っ張ってくる傾向にあるためです。もう一つは、頂点数が巨大で、テスト (距離、包含)関数では、少なくとも1回、通常はN (Nは、もう一方のフィーチャーの頂点数)回、頂点を横断しなければならないためです。

note: Tag: para
en: As with GEOMETRY, we recommend that when you have very large polygons, but are doing queries in small areas, you "denormalize" your geometric data into smaller chunks so that the index can effectively subquery parts of the object and so queries don't have to pull out the whole object every time. Please consult <xref linkend="ST_Subdivide"/> function documentation. Just because you *can* store all of Europe in one polygon doesn't mean you *should*.
ja: ジオメトリでは、大きなポリゴンを持っているけれども小さな範囲のクエリを実行する時、ジオメトリデータ情報を小片に「非正規化」します。これにより、インデックスが効果的にオブジェクトの一部を問い合わせるようになり、またクエリが常にオブジェクト全体を引っ張りこむようなことがないようになります。<xref linkend="ST_Subdivide"/>を参照して下さい。ヨーロッパ全体を一つのポリゴンに*格納できる*からといって、*そうすべき*だというわけではありません。

note: Tag: title
en: Geometry Validation
ja: ジオメトリ検証

note: Tag: para
en: PostGIS is compliant with the Open Geospatial Consortium’s (OGC) Simple Features specification. That standard defines the concepts of geometry being <emphasis>simple</emphasis> and <emphasis>valid</emphasis>. These definitions allow the Simple Features geometry model to represent spatial objects in a consistent and unambiguous way that supports efficient computation. (Note: the OGC SF and SQL/MM have the same definitions for simple and valid.)
ja: PostGISはOpen Geospatial Consortium (OGC)のSimple Feature Specificationに準拠しています。この標準では、<emphasis>単純</emphasis>なジオメトリと<emphasis>妥当</emphasis>なジオメトリの概念が定義されています。これらの定義によって、Simple Featureのジオメトリモデルが一貫性があって、かつ明確な方法で空間オブジェクトを表現することができ、効率的な計算を助けます (OGC Simple FeatureとSQL/MMとにおいては、単純性と妥当性について同じ定義です)。

note: Tag: title
en: Simple Geometry
ja: 単純ジオメトリ

note: Tag: para
en: A <emphasis>simple</emphasis> geometry is one that has no anomalous geometric points, such as self intersection or self tangency.
ja: <emphasis>単純</emphasis>なジオメトリは、自己交差や自己接触といった異常な幾何学上のポイントを持たないジオメトリです。

note: Tag: para
en: A <varname>POINT</varname> is inherently <emphasis>simple</emphasis> as a 0-dimensional geometry object.
ja: <varname>POINT</varname>は0次元ジオメトリオブジェクトとして常に<emphasis>単純</emphasis>です。

note: Tag: para
en: <varname>MULTIPOINT</varname>s are <emphasis>simple</emphasis> if no two coordinates (<varname>POINT</varname>s) are equal (have identical coordinate values).
ja: <varname>MULTIPOINT</varname>は、任意の二つの座標値 (<varname>POINT</varname>)が同じでないなら<emphasis>単純</emphasis>です。

note: Tag: para
en: A <varname>LINESTRING</varname> is <emphasis>simple</emphasis> if it does not pass through the same point twice, except for the endpoints. If the endpoints of a simple LineString are identical it is called <emphasis>closed</emphasis> and referred to as a Linear Ring.
ja: <varname>LINESTRING</varname>は、同じポイントを二回通過しないものが<emphasis>単純</emphasis>です。単純なラインストリングの端点が同一の場合には、<emphasis>閉じている</emphasis>とされ、線形リングと呼ばれます。

note: Tag: emphasis
en: <emphasis role="bold">(a)</emphasis> and <emphasis role="bold">(c)</emphasis> are simple <varname>LINESTRING</varname>s. <emphasis role="bold">(b)</emphasis> and <emphasis role="bold">(d)</emphasis> are not simple. <emphasis role="bold">(c)</emphasis> is a closed Linear Ring.
ja: <emphasis role="bold">(a)</emphasis>と<emphasis role="bold">(c)</emphasis>は単純な<varname>LINESTRING</varname>です。<emphasis role="bold">(b)</emphasis>と<emphasis role="bold">(d)</emphasis>は単純ではありません。<emphasis role="bold">(c)</emphasis>は閉じた線形リングです。

note: Tag: para
en: A <varname>MULTILINESTRING</varname> is <emphasis>simple</emphasis> only if all of its elements are simple and the only intersection between any two elements occurs at points that are on the boundaries of both elements.
ja: <varname>MULTILINESTRING</varname>は、要素が全て単純で、かつ、全ての要素同士のインタセクションが要素の境界上でのみ出現する場合には、<emphasis>単純</emphasis>です。

note: Tag: emphasis
en: <emphasis role="bold">(e)</emphasis> and <emphasis role="bold">(f)</emphasis> are simple <varname>MULTILINESTRING</varname>s. <emphasis role="bold">(g)</emphasis> is not simple.
ja: <emphasis role="bold">(e)</emphasis>と<emphasis role="bold">(f)</emphasis>は単純な<varname>MULTILINESTRING</varname>です。<emphasis role="bold">(g)</emphasis>は単純ではありません。

note: Tag: para
en: <varname>POLYGON</varname>s are formed from linear rings, so valid polygonal geometry is always <emphasis>simple</emphasis>.
ja: <varname>POLYGON</varname>は線形リングから形成されるので、妥当なポリゴンジオメトリは常に<emphasis>単純</emphasis>です。

note: Tag: para
en: To test if a geometry is simple use the <xref linkend="ST_IsSimple"/> function:
ja: ジオメトリが単純かどうかを試すには<xref linkend="ST_IsSimple"/>関数を使います。次のようにします。

note: Tag: para
en: Generally, PostGIS functions do not require geometric arguments to be simple. Simplicity is primarily used as a basis for defining geometric validity. It is also a requirement for some kinds of spatial data models (for example, linear networks often disallow lines that cross). Multipoint and linear geometry can be made simple using <xref linkend="ST_UnaryUnion"/>.
ja: 一般的にPostGIS関数は引数ジオメトリの単純性を求めていません。単純性は主にジオメトリの妥当性を定義するための基礎として用いられます。空間データモデルによっては要件としていることもあります (たとえば、線形ネットワークはしばしばクロスを認めません)。マルチポイントと線形ジオメトリは<xref linkend="ST_UnaryUnion"/>を使って単純にできます。

note: Tag: title
en: Valid Geometry
ja: 妥当なジオメトリ

note: Tag: para
en: Geometry validity primarily applies to 2-dimensional geometries (<varname>POLYGON</varname>s and <varname>MULTIPOLYGON</varname>s) . Validity is defined by rules that allow polygonal geometry to model planar areas unambiguously.
ja: ジオメトリの妥当性は主に2次元ジオメトリ (<varname>POLYGON</varname>と<varname>MULTIPOLYGON</varname>)に適用されます。妥当性はポリゴンジオメトリが平面領域を明確にモデル化できる規則によって定義されます。

note: Tag: para
en: A <varname>POLYGON</varname> is <emphasis>valid</emphasis> if:
ja: <varname>POLYGON</varname>は次の条件では<emphasis>妥当</emphasis>です。

note: Tag: para
en: the polygon boundary rings (the exterior shell ring and interior hole rings) are <emphasis>simple</emphasis> (do not cross or self-touch). Because of this a polygon cannnot have cut lines, spikes or loops. This implies that polygon holes must be represented as interior rings, rather than by the exterior ring self-touching (a so-called "inverted hole").
ja: ポリゴン境界リング (外側の殻リングと内側の穴リング)が<emphasis>単純</emphasis> (交差も自己接触もしていない)であること。これによりポリゴンは切断線、トゲ、循環を持つことができなくなります。これは、ポリゴンの穴を外側のリングの自己接触 (いわゆる "inverted hole" (逆穴))でなく、内側のリングとして表現されなけれならないことを意味します。

note: Tag: para
en: boundary rings do not cross
ja: 境界リングがクロスしないこと

note: Tag: para
en: boundary rings may touch at points but only as a tangent (i.e. not in a line)
ja: 境界リングは点で接触したとしても接点として接触すること (線上にあってはなりません)

note: Tag: para
en: interior rings are contained in the exterior ring
ja: 内側リングは外側リング内にあること

note: Tag: para
en: the polygon interior is simply connected (i.e. the rings must not touch in a way that splits the polygon into more than one part)
ja: ポリゴン内部は単純に接続されていること (リングはポリゴンを複数に分割するように接触してはなりません)

note: Tag: emphasis
en: <emphasis role="bold">(h)</emphasis> and <emphasis role="bold">(i)</emphasis> are valid <varname>POLYGON</varname>s. <emphasis role="bold">(j-m)</emphasis> are invalid. <emphasis role="bold">(j)</emphasis> can be represented as a valid <varname>MULTIPOLYGON</varname>.
ja: <emphasis role="bold">(h)</emphasis>と<emphasis role="bold">(i)</emphasis>は妥当な<varname>POLYGON</varname>です。<emphasis role="bold">(j-m)</emphasis>は不正です。<emphasis role="bold">(j)</emphasis>は妥当な<varname>MULTIPOLYGON</varname>として表すことができます。

note: Tag: para
en: A <varname>MULTIPOLYGON</varname> is <emphasis>valid</emphasis> if:
ja: <varname>MULTIPOLYGON</varname>は次の条件では<emphasis>妥当</emphasis>です。

note: Tag: para
en: its element <varname>POLYGON</varname>s are valid
ja: 要素となる<varname>POLYGON</varname>が妥当であること

note: Tag: para
en: elements do not overlap (i.e. their interiors must not intersect)
ja: 要素がオーバラップしない (内部同士がインタセクトしない)こと

note: Tag: para
en: elements touch only at points (i.e. not along a line)
ja: 要素同士の接触が点でけである (線に沿って接触しない)こと

note: Tag: emphasis
en: <emphasis role="bold">(n)</emphasis> is a valid <varname>MULTIPOLYGON</varname>. <emphasis role="bold">(o)</emphasis> and <emphasis role="bold">(p)</emphasis> are invalid.
ja: <emphasis role="bold">(n)</emphasis>は妥当な<varname>MULTIPOLYGON</varname>です。<emphasis role="bold">(o)</emphasis>と<emphasis role="bold">(p)</emphasis>は不正です。

note: Tag: para
en: These rules mean that valid polygonal geometry is also <emphasis>simple</emphasis>.
ja: これらの規則は妥当なポリゴンジオメトリも<emphasis>単純</emphasis>であることも示しています。

note: Tag: para
en: For linear geometry the only validity rule is that <varname>LINESTRING</varname>s must have at least two points and have non-zero length (or equivalently, have at least two distinct points.) Note that non-simple (self-intersecting) lines are valid.
ja: 線ジオメトリについては、<varname>LINESTRING</varname>が少なくとも二つのポイントを持ち、長さが0でない (少なくとも二つの異なるポイントを持つことと同じ)、というのが唯一の妥当性規則です。単純でない (自己交差がある)ラインは妥当です。

note: Tag: para
en: <varname>POINT</varname> and <varname>MULTIPOINT</varname> geometries have no validity rules.
ja: <varname>POINT</varname>と<varname>MULTIPOINT</varname>は妥当性規則を持っていません。

note: Tag: title
en: Managing Validity
ja: 妥当性の管理

note: Tag: para
en: PostGIS allows creating and storing both valid and invalid Geometry. This allows invalid geometry to be detected and flagged or fixed. There are also situations where the OGC validity rules are stricter than desired (examples of this are zero-length linestrings and polygons with inverted holes.)
ja: PostGISは妥当なジオメトリも不正なジオメトリも、生成も格納もできます。このため、不正なジオメトリを検出し、フラグを付け、訂正することができます。OGC妥当性規則が求める規則 (長さが0のラインストリングや逆穴を持つポリゴン等)よりも厳格であることもあります。

note: Tag: para
en: Many of the functions provided by PostGIS rely on the assumption that geometry arguments are valid. For example, it does not make sense to calculate the area of a polygon that has a hole defined outside of the polygon, or to construct a polygon from a non-simple boundary line. Assuming valid geometric inputs allows functions to operate more efficiently, since they do not need to check for topological correctness. (Notable exceptions are that zero-length lines and polygons with inversions are generally handled correctly.) Also, most PostGIS functions produce valid geometry output if the inputs are valid. This allows PostGIS functions to be chained together safely.
ja: PostGISが提供する関数の多くは、引数ジオメトリが妥当であるとの仮定によっています。たとえば、ポリゴンの外部に穴があるポリゴンの面積を計算しても意味がありませんし、単純でない境界線からポリゴンを形成するのも意味がありません。妥当なジオメトリ入力を仮定することで、トポロジ的に正しいことを確認する必要がなくなるので、関数がより効率的に動作することができます (例外として、長さ0のラインと反転したポリゴンは一般的に正しく取り扱われます)。また、ほとんどのPostGIS関数は、入力ジオメトリが妥当な場合には、妥当なジオメトリ出力を生成します。これにより、PostGIS関数を安全に連鎖させられます。

note: Tag: para
en: If you encounter unexpected error messages when calling PostGIS functions (such as "GEOS Intersection() threw an error!"), you should first confirm that the function arguments are valid. If they are not, then consider using one of the techniques below to ensure the data you are processing is valid.
ja: PostGIS関数を呼ぶときに予期しないエラーメッセージ ("GEOS Intersection() threw an error!"等)に遭遇する場合には、まず関数の引数が妥当かどうかを確認します。妥当でないなら、次に示す方法のいずれかによる、処理中のデータの妥当性の確認を検討して下さい。

note: Tag: para
en: If a function reports an error with valid inputs, then you may have found an error in either PostGIS or one of the libraries it uses, and you should report this to the PostGIS project. The same is true if a PostGIS function returns an invalid geometry for valid input.
ja: 関数が妥当な入力でエラーを報告する場合には、PostGISまたは使用しているライブラリの一つの中にエラーがあるのを発見することがありますが、その際はPostGISプロジェクトに報告して下さい。PostGIS関数が妥当な入力から不正なジオメトリを返す場合も同様です。

note: Tag: para
en: To test if a geometry is valid use the <xref linkend="ST_IsValid"/> function:
ja: ジオメトリが妥当かをテストするには<xref linkend="ST_IsValid"/>関数を使います。次のようにします。

note: Tag: para
en: Information about the nature and location of an geometry invalidity are provided by the <xref linkend="ST_IsValidDetail"/> function:
ja: ジオメトリの不正性の性質と位置に関する情報は<xref linkend="ST_IsValidDetail"/>関数で得られます。次のようにします。

note: Tag: para
en: In some situations it is desirable to correct invalid geometry automatically. Use the <xref linkend="ST_MakeValid"/> function to do this. (<code>ST_MakeValid</code> is a case of a spatial function that <emphasis>does</emphasis> allow invalid input!)
ja: 不正なジオメトリを自動的に訂正することが望ましいような状況があります。その際は<xref linkend="ST_MakeValid"/>関数を使います (<code>ST_MakeValid</code>は不正な入力を<emphasis>許す</emphasis>特別な関数です)。

note: Tag: para
en: By default, PostGIS does not check for validity when loading geometry, because validity testing can take a lot of CPU time for complex geometries. If you do not trust your data sources, you can enforce a validity check on your tables by adding a check constraint:
ja: 複雑なジオメトリの不正性テストには多大なCPU時間を取ることになるため、デフォルトでは、ジオメトリのロード時にPostGISは妥当性の確認をしません。データソースが信用できない場合には、チェック制約を使って、テーブル上で妥当性を強制的に確認することができます。次のようにします。

note: Tag: title
en: Spatial Reference Systems
ja: 空間参照系

note: Tag: para
en: A <ulink url="https://en.wikipedia.org/wiki/Spatial_reference_system">Spatial Reference System</ulink> (SRS) (also called a Coordinate Reference System (CRS)) defines how geometry is referenced to locations on the Earth's surface. There are three types of SRS:
ja: <ulink url="https://en.wikipedia.org/wiki/Spatial_reference_system">空間参照系</ulink> (Spatial Reference System, SRS) (座標参照系、Coordinate Reference System, CRSとも呼ばれます)は、ジオメトリが地表上の位置をどのように参照するかを定義しています。SRSには次の通り三種あります。

note: Tag: para
en: A <emphasis role="bold">geodetic</emphasis> SRS uses angular coordinates (longitude and latitude) which map directly to the surface of the earth.
ja: <emphasis role="bold">測地</emphasis> (geodetic) 空間参照系は、地表に直接対応付けられる極座標系 (経度と緯度)を使います。

note: Tag: para
en: A <emphasis role="bold">projected</emphasis> SRS uses a mathematical projection transformation to "flatten" the surface of the spheroidal earth onto a plane. It assigns location coordinates in a way that allows direct measurement of quantities such as distance, area, and angle. The coordinate system is Cartesian, which means it has a defined origin point and two perpendicular axes (usually oriented North and East). Each projected SRS uses a stated length unit (usually metres or feet). A projected SRS may be limited in its area of applicability to avoid distortion and fit within the defined coordinate bounds.
ja: <emphasis role="bold">投影</emphasis> (projected)空間参照系は、回転楕円体面を「平面にする」ための数学的な投影変換を使います。距離、面積、角度といった量を直接計測することが可能な位置座標系です。この座標系はデカルト座標系ですので、原点と二つの直交軸 (通常は来北と東方向)が定義されています。個々の投影座標系は、定まった距離単位 (通常はメートルかフィート)を使います。投影座標系は、歪みを避けて定義された座標範囲に納めるために、適応範囲を制限してもいいことになっています。

note: Tag: para
en: A <emphasis role="bold">local</emphasis> SRS is a Cartesian coordinate system which is not referenced to the earth's surface. In PostGIS this is specified by a SRID value of 0.
ja: <emphasis role="bold">局所</emphasis> (local)座標系は、地表への参照がないデカルト座標系です。PostGISではSRID値を0に指定します。

note: Tag: para
en: There are many different spatial reference systems in use. Common SRSes are standardized in the European Petroleum Survey Group <ulink url="http://www.epsg.org/">EPSG database</ulink>. For convenience PostGIS (and many other spatial systems) refers to SRS definitions using an integer identifier called a SRID.
ja: 使用されている空間参照系には多数の相違点があります。一般的空間参照系は欧州石油調査グループ (European Petroleum Survey Group)の<ulink url="http://www.epsg.org/">EPSG database</ulink>で標準化されています。利便性向上のためPostGIS (と多くの空間系)はSRIDと呼ぶ整数を使って空間参照系の定義を参照します。

note: Tag: para
en: A geometry is associated with a Spatial Reference System by its SRID value, which is accessed by <xref linkend="ST_SRID"/>. The SRID for a geometry can be assigned using <xref linkend="ST_SetSRID"/>. Some geometry constructor functions allow supplying a SRID (such as <xref linkend="ST_Point"/> and <xref linkend="ST_MakeEnvelope"/>). The <link linkend="EWKB_EWKT">EWKT</link> format supports SRIDs with the <code>SRID=n;</code> prefix.
ja: ジオメトリは、SRID値で空間参照系に関連付けられています。SRID値の取得には<xref linkend="ST_SRID"/>を使います。ジオメトリのSRIDの設定には<xref linkend="ST_SetSRID"/>を使います。ジオメトリ構築関数の中には、SRIDを与えられるものもあります (<xref linkend="ST_Point"/>や<xref linkend="ST_MakeEnvelope"/>等)。<link linkend="EWKB_EWKT">EWKT</link>書式は<code>SRID=n;</code>を前置することでSRIDに対応できます。

note: Tag: para
en: Spatial functions processing pairs of geometries (such as <link linkend="Overlay_Functions">overlay</link> and <link linkend="Spatial_Relationships">relationship</link> functions) require that the input geometries are in the same spatial reference system (have the same SRID). Geometry data can be transformed into a different spatial reference system using <xref linkend="ST_Transform"/> and <xref linkend="ST_TransformPipeline"/>. Geometry returned from functions has the same SRS as the input geometries.
ja: 二つのジオメトリを処理する空間関数 (<link linkend="Overlay_Functions">オーバレイ関数</link> 、<link linkend="Spatial_Relationships">関係関数</link>など)の入力ジオメトリは、同じ空間参照系である (同じSRIDを持つ)必要があります。<xref linkend="ST_Transform"/>や<xref linkend="ST_TransformPipeline"/>を使うことで、ジオメトリデータを異なる空間参照系に変換できます。関数から返されるジオメトリは、入力ジオメトリと同じ空間参照系になります。

note: Tag: title
en: SPATIAL_REF_SYS Table
ja: SPATIAL_REF_SYSテーブル

note: Tag: para
en: The <varname>SPATIAL_REF_SYS</varname> table used by PostGIS is an OGC-compliant database table that defines the available spatial reference systems. It holds the numeric SRIDs and textual descriptions of the coordinate systems.
ja: PostGISが使用する<varname>SPATIAL_REF_SYS</varname>テーブルは利用可能な空間参照系を定義するOGC準拠のデータベーステーブルです。このテーブルは、数値でSRIDを持ち、文字列で座標系の記述を持っています。

note: Tag: para
en: The <varname>spatial_ref_sys</varname> table definition is:
ja: <varname>spatial_ref_sys</varname>の定義は次の通りです。

note: Tag: para
en: The columns are:
ja: カラムは次の通りです。

note: Tag: para
en: An integer code that uniquely identifies the <ulink url="http://en.wikipedia.org/wiki/SRID">Spatial Reference System</ulink> (SRS) within the database.
ja: データベース内の<ulink url="http://en.wikipedia.org/wiki/SRID">Spatial Reference System</ulink> (SRS, 空間参照系)で一意に識別される整数コードです。

note: Tag: para
en: The name of the standard or standards body that is being cited for this reference system. For example, "EPSG" is a valid <varname>auth_name</varname>.
ja: この参照系に引用されている標準の名前もしくは標準そのものです。たとえば「EPSG」は妥当な<varname>auth_name</varname>です。

note: Tag: para
en: The ID of the Spatial Reference System as defined by the Authority cited in the <varname>auth_name</varname>. In the case of EPSG, this is the EPSG code.
ja: 空間参照系のIDは<varname>auth_name</varname>に引用される機関によって定義されます。ここがEPSGの場合には、これはEPSGコードです。

note: Tag: para
en: The Well-Known Text representation of the Spatial Reference System. An example of a WKT SRS representation is:
ja: 空間参照系のWell-Knownテキスト表現です。たとえば、WKT SRSの表現は、次のようになります。

note: Tag: para
en: For a discussion of SRS WKT, see the OGC standard <ulink url="http://docs.opengeospatial.org/is/12-063r5/12-063r5.html">Well-known text representation of coordinate reference systems</ulink>.
ja: SRS WKTの詳細については、OGC標準の<ulink url="http://docs.opengeospatial.org/is/12-063r5/12-063r5.html">Well-known text representation of coordinate reference systems</ulink>をご覧下さい。

note: Tag: para
en: PostGIS uses the PROJ library to provide coordinate transformation capabilities. The <varname>proj4text</varname> column contains the PROJ coordinate definition string for a particular SRID. For example:
ja: PostGISは座標変換機能を提供するためにProj4ライブラリを用いています。 <varname>proj4text</varname>カラムには、特定のSRIDを示すProj4座標定義文字列が入ります。たとえば次のようになります。

note: Tag: para
en: For more information see the <ulink url="https://proj.org/">PROJ web site</ulink>. The <filename>spatial_ref_sys.sql</filename> file contains both <varname>srtext</varname> and <varname>proj4text</varname> definitions for all EPSG projections.
ja: 詳細情報については<ulink url="https://proj.org/">PROJウェブサイト</ulink>をご覧下さい。<filename>spatial_ref_sys.sql</filename>ファイルには、全てのEPSG投影について、<varname>srtext</varname>と<varname>proj4text</varname>の定義があります。

note: Tag: para
en: When retrieving spatial reference system definitions for use in transformations, PostGIS uses fhe following strategy:
ja: 投影変換で空間参照系の定義を使用する場合には、次の戦略を取ります。

note: Tag: para
en: If <varname>auth_name</varname> and <varname>auth_srid</varname> are present (non-NULL) use the PROJ SRS based on those entries (if one exists).
ja: <varname>auth_name</varname>と<varname>auth_srid</varname>がある (NULLでない)場合には、これに基づいてPROJSRSを使います (存在する場合)。

note: Tag: para
en: If <varname>srtext</varname> is present create a SRS using it, if possible.
ja: <varname>srtext</varname>がある場合には、可能ならそれを使用してSRSを生成します。

note: Tag: para
en: If <varname>proj4text</varname> is present create a SRS using it, if possible.
ja: <varname>proj4text</varname>がある場合には、可能ならこれを使用してSRSを生成します。

note: Tag: title
en: User-Defined Spatial Reference Systems
ja: ユーザ定義空間参照系

note: Tag: para
en: The PostGIS <varname>spatial_ref_sys</varname> table contains over 3000 of the most common spatial reference system definitions that are handled by the <ulink url="https://proj.org">PROJ</ulink> projection library. But there are many coordinate systems that it does not contain. You can add SRS definitions to the table if you have the required information about the spatial reference system. Or, you can define your own custom spatial reference system if you are familiar with PROJ constructs. Keep in mind that most spatial reference systems are regional and have no meaning when used outside of the bounds they were intended for.
ja: PostGIS<varname>spatial_ref_sys</varname>テーブルには<ulink url="https://proj.org/">PROJ</ulink>投影ライブラリで処理される最も一般的な空間参照系定義3000件以上があります。しかし、そこに無い多くの座標系があります。空間参照系に関する必要な情報がある場合は、SRS定義をテーブルに追加できます。PROJに詳しいなら独自の空間参照系を定義することもできます。ほとんどの空間参照系は地域的なものであり、目的の範囲外で使用する場合は意味を持たない点に注意してください。

note: Tag: para
en: A resource for finding spatial reference systems not defined in the core set is <ulink url="http://spatialreference.org/">http://spatialreference.org/</ulink>
ja: PostGISのコアセットに入っていない空間参照系を探すための素晴らしい資料が<ulink url="http://spatialreference.org/">http://spatialreference.org/</ulink>にあります。

note: Tag: para
en: Some commonly used spatial reference systems are: <ulink url="http://spatialreference.org/ref/epsg/4326/">4326 - WGS 84 Long Lat</ulink>, <ulink url="http://spatialreference.org/ref/epsg/4269/">4269 - NAD 83 Long Lat</ulink>, <ulink url="http://spatialreference.org/ref/epsg/3395/">3395 - WGS 84 World Mercator</ulink>, <ulink url="http://spatialreference.org/ref/epsg/2163/">2163 - US National Atlas Equal Area</ulink>, and the 60 WGS84 UTM zones. UTM zones are one of the most ideal for measurement, but only cover 6-degree regions. (To determine which UTM zone to use for your area of interest, see the <ulink url="http://trac.osgeo.org/postgis/wiki/UsersWikiplpgsqlfunctionsDistance">utmzone PostGIS plpgsql helper function</ulink>.)
ja: 一般的に使用される空間参照系には<ulink url="http://spatialreference.org/ref/epsg/4326/">4326 - WGS 84経度緯度</ulink>、<ulink url="http://spatialreference.org/ref/epsg/4269/">4269 - NAD 83 経度緯度</ulink>、<ulink url="http://spatialreference.org/ref/epsg/3395/">3395 - WGS 84 メルカトル</ulink>、<ulink url="http://spatialreference.org/ref/epsg/2163/">2163 - 米国ナショナルアトラス正積図法</ulink>、60個のWGS84 UTMゾーンがあります。UTMゾーンは計測に最適ですが、6度 (訳注: 経度)の領域のみをカバーします (対象地域に使用するUTMゾーンを決定するには<ulink url="http://trac.osgeo.org/postgis/wiki/UsersWikiplpgsqlfunctionsDistance">utmzone PostGIS plpgsql helper function</ulink>を参照してください)。

note: Tag: para
en: US states use State Plane spatial reference systems (meter or feet based) - usually one or 2 exists per state. Most of the meter-based ones are in the core set, but many of the feet-based ones or ESRI-created ones will need to be copied from <ulink url="http://spatialreference.org">spatialreference.org</ulink>.
ja: 米国の州では、州平面空間参照系 (メートルまたはフィート単位)を使用します。この空間参照系は州ごとに一つか二つ存在します。ほとんどのメートル単位のものはコアのセットに存在しますが、フィート単位の多数のものやESRIが作成したものは<ulink url="http://spatialreference.org">spatialreference.org</ulink>からロードする必要があります。

note: Tag: para
en: You can even define non-Earth-based coordinate systems, such as <ulink url="http://spatialreference.org/ref/iau2000/mars-2000/">Mars 2000</ulink> This Mars coordinate system is non-planar (it's in degrees spheroidal), but you can use it with the <varname>geography</varname> type to obtain length and proximity measurements in meters instead of degrees.
ja: 地球外の座標系でさえも定義することができます。たとえば<ulink url="http://spatialreference.org/ref/iau2000/mars-2000/">Mars 2000</ulink>です。この火星の座標系は非平面 (回転楕円体の度)ですが、<varname>geography</varname>型で、度でなくメートル単位で長さや近接測定値を取得することができます。

note: Tag: para
en: Here is an example of loading a custom coordinate system using an unassigned SRID and the PROJ definition for a US-centric Lambert Conformal projection:
ja: 割当外のSRIDとPROJ定義を使って米国中央のランベルト正角円錐図法の独自座標系をロードする例を次に示します。

note: Tag: title
en: Spatial Tables
ja: 空間テーブル

note: Tag: title
en: Creating a Spatial Table
ja: 空間テーブルを作る

note: Tag: para
en: You can create a table to store geometry data using the <ulink url="https://www.postgresql.org/docs/current/sql-createtable.html">CREATE TABLE</ulink> SQL statement with a column of type <varname>geometry</varname>. The following example creates a table with a geometry column storing 2D (XY) LineStrings in the BC-Albers coordinate system (SRID 3005):
ja: <varname>geometry</varname>型のカラムを付けた<ulink url="https://www.postgresql.org/docs/current/sql-createtable.html">CREATE TABLE</ulink> SQLステートメントでジオメトリデータを保存するテーブルを生成することができます。次の例では、BC-アルベルス座標系 (SRID 3005)の2次元 (XY)ラインストリングを保存するジオメトリカラムを持つテーブルを生成します。

note: Tag: para
en: The <varname>geometry</varname> type supports two optional <emphasis role="bold">type modifiers</emphasis>:
ja: <varname>geometry</varname>型は、次の通り、二つの任意指定<emphasis role="bold">型修飾子</emphasis>に対応しています。

note: Tag: para
en: the <emphasis role="bold">spatial type modifier</emphasis> restricts the kind of shapes and dimensions allowed in the column. The value can be any of the supported <link linkend="RefObject">geometry subtypes</link> (e.g. POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION, etc). The modifier supports coordinate dimensionality restrictions by adding suffixes: Z, M and ZM. For example, a modifier of 'LINESTRINGM' allows only linestrings with three dimensions, and treats the third dimension as a measure. Similarly, 'POINTZM' requires four dimensional (XYZM) data.
ja: <emphasis role="bold">空間タイプ修飾子</emphasis>はカラムで許される形状と次元の種類を制約するものです。値は、対応している<link linkend="RefObject">ジオメトリタイプ</link> (POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION等)なら全て可能です。空間タイプ修飾子は、後置詞 Z, M, ZMを付け加えることで座標次元の制約に対応します。例えば、`LINESTRINGM`修飾子では、3次元で3番目がM軸となるラインストリングだけを許します。同様に、'POINTZM'では4次元 (XYZM)データが求められます。

note: Tag: para
en: the <emphasis role="bold">SRID modifier</emphasis> restricts the <link linkend="spatial_ref_sys">spatial reference system</link> SRID to a particular number. If omitted, the SRID defaults to 0.
ja: <emphasis role="bold">SRID修飾子</emphasis>は<link linkend="spatial_ref_sys">空間参照系</link>のSRIDを特定の数値に制約します。省略した場合には、デフォルトは0となります。

note: Tag: para
en: Examples of creating tables with geometry columns:
ja: ジオグラフィカラムを持つテーブルの生成の例を次に挙げます。

note: Tag: para
en: Create a table holding any kind of geometry with the default SRID:
ja: デフォルトSRIDであらゆる種類のジオメトリを保持するテーブルの生成:

note: Tag: para
en: Create a table with 2D POINT geometry with the default SRID:
ja: 2次元ポイントでSRIDがデフォルトのテーブル作成:

note: Tag: para
en: Create a table with 3D (XYZ) POINTs and an explicit SRID of 3005:
ja: 3次元 (XYZ)ポイントでSRIDが3005のテーブル作成:

note: Tag: para
en: Create a table with 4D (XYZM) LINESTRING geometry with the default SRID:
ja: 4次元 (XYZM)ラインストリングでSRIDがデフォルトのテーブル作成:

note: Tag: para
en: Create a table with 2D POLYGON geometry with the SRID 4267 (NAD 1927 long lat):
ja: 2次元ポリゴンでSRIDが4276 (NAD 1927地理座標系)のテーブル作成:

note: Tag: para
en: It is possible to have more than one geometry column in a table. This can be specified when the table is created, or a column can be added using the <ulink url="https://www.postgresql.org/docs/current/sql-altertable.html">ALTER TABLE</ulink> SQL statement. This example adds a column that can hold 3D LineStrings:
ja: 一つのテーブルが一つ以上のジオメトリカラムを持つことができます。テーブル生成時に指定するか、<ulink url="https://www.postgresql.org/docs/current/sql-altertable.html">ALTER TABLE</ulink> SQLステートメントを使って追加するかで実現できます。次に3次元ラインストリングを格納するカラムを追加する例を示します。

note: Tag: title
en: GEOMETRY_COLUMNS View
ja: GEOMETRY_COLUMNSビュー

note: Tag: para
en: The OGC <emphasis>Simple Features Specification for SQL</emphasis> defines the <varname>GEOMETRY_COLUMNS</varname> metadata table to describe geometry table structure. In PostGIS <varname>geometry_columns</varname> is a view reading from database system catalog tables. This ensures that the spatial metadata information is always consistent with the currently defined tables and views. The view structure is:
ja: OGC <emphasis>Simple Features Specification for SQL</emphasis>は、ジオメトリテーブル構造を記述するための<varname>GEOMETRY_COLUMNS</varname>メタデータテーブルを定義しています。PostGISでは<varname>geometry_columns</varname>は、データベースのシステムカタログテーブルから読み取るビューです。これによって、空間メタデータ情報が常に現在定義されているテーブルやビューと矛盾しなくなります。

note: Tag: para
en: The fully qualified name of the feature table containing the geometry column. There is no PostgreSQL analogue of "catalog" so that column is left blank. For "schema" the PostgreSQL schema name is used (<varname>public</varname> is the default).
ja: ジオメトリカラムを持っている地物テーブルの完全修飾名。PostgreSQLには"catalog"の類似カラムが無いので、このカラムは空白のままです。"schema"についてはPostgreSQLスキーマ名が使われます (デフォルトは<varname>public</varname>です)。

note: Tag: para
en: The name of the geometry column in the feature table.
ja: フィーチャーテーブル内のジオメトリカラムの名前。

note: Tag: para
en: The coordinate dimension (2, 3 or 4) of the column.
ja: カラムの座標次元 (2, 3, 4)。

note: Tag: para
en: The ID of the spatial reference system used for the coordinate geometry in this table. It is a foreign key reference to the <varname>spatial_ref_sys</varname> table (see <xref linkend="spatial_ref_sys_table"/>).
ja: このテーブルのジオメトリの座標系として使用される座標系空間参照系のIDです。<varname>spatial_ref_sys</varname>テーブルを参照する外部キーです (<xref linkend="spatial_ref_sys_table"/>を参照して下さい)。

note: Tag: para
en: The type of the spatial object. To restrict the spatial column to a single type, use one of: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION or corresponding XYM versions POINTM, LINESTRINGM, POLYGONM, MULTIPOINTM, MULTILINESTRINGM, MULTIPOLYGONM, GEOMETRYCOLLECTIONM. For heterogeneous (mixed-type) collections, you can use "GEOMETRY" as the type.
ja: 空間オブジェクトの型。空間カラムを単一型に制限するには、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTIONのうちのいずれかを、また、XYMで使う場合には、LINESTRINGM、POLYGONM、MULTIPOINTM、MULTILINESTRINGM、MULTIPOLYGONM、GEOMETRYCOLLECTIONMのうちのいずれかを使います。複数の型が混合するコレクションの場合は"GEOMETRY"を型とすることができます。

note: Tag: title
en: Manually Registering Geometry Columns
ja: 手動でジオメトリカラムをgeometry_columnsに登録する

note: Tag: para
en: Two of the cases where you may need this are the case of SQL Views and bulk inserts. For bulk insert case, you can correct the registration in the geometry_columns table by constraining the column or doing an alter table. For views, you could expose using a CAST operation. Note, if your column is typmod based, the creation process would register it correctly, so no need to do anything. Also views that have no spatial function applied to the geometry will register the same as the underlying table geometry column.
ja: これが必要になる事例に、SQLビューとバルクインサートの二つがあります。バルクインサートの場合には、カラムに制約を与えるか、ALTER TABLEを実行することで、geometry_columnsテーブル内の登録を訂正することができます。ビューの場合には、CAST演算を使用します。カラムが型修飾子に基づく場合には、生成処理によって正しく登録されるので、何も行う必要がありません。ジオメトリに適用する空間関数を持たないビューも、基礎となるテーブルのジオメトリカラムと同じように登録されます。

note: Tag: para
en: Although the old-constraint based method is still supported, a constraint-based geometry column used directly in a view, will not register correctly in geometry_columns, as will a typmod one. In this example we define a column using typmod and another using constraints.
ja: 古い制約を基にした手法は現在も対応していますが、制約を基にしたジオメトリカラムで直接的にビューで使われている場合は、型修飾子のようには正しくgeometry_columnsに登録されません。次の例では、型修飾子を使ったカラム定義と、制約に基づくカラムの定義とを行っています。

note: Tag: para
en: If we run in psql
ja: psqlで次を実行します。

note: Tag: para
en: We observe they are defined differently -- one is typmod, one is constraint
ja: 型修飾子と制約に基づくのとでは異なった定義になっているのが見えます。

note: Tag: para
en: In geometry_columns, they both register correctly
ja: geometry_columnsでは、両方とも正しく登録されています。

note: Tag: para
en: However -- if we were to create a view like this
ja: しかし、次のようにビューを作ろうとします。

note: Tag: para
en: The typmod based geom view column registers correctly, but the constraint based one does not.
ja: 型修飾子によるgeomのビューカラムは正しく登録されますが、制約に基づくものは正しく登録されません。

note: Tag: para
en: This may change in future versions of PostGIS, but for now to force the constraint-based view column to register correctly, you need to do this:
ja: これは、将来的にPostGISの版で変更されるかもしれませんが、今のところは、制約に基づくビューカラムを正しく登録させるには、次のようにします。

note: Tag: title
en: Loading Spatial Data
ja: 空間データのロード

note: Tag: para
en: Once you have created a spatial table, you are ready to upload spatial data to the database. There are two built-in ways to get spatial data into a PostGIS/PostgreSQL database: using formatted SQL statements or using the Shapefile loader.
ja: 空間テーブルを作成したら、これでGISデータをデータベースにアップロードする準備ができたことになります。現在、PostGIS/PostgreSQLデータベースにデータをロードするには、SQLステートメントを使う、またはシェープファイルのローダ/ダンパを使う、という二つの方法があります。

note: Tag: title
en: Using SQL to Load Data
ja: SQLを使ってロードする

note: Tag: para
en: If spatial data can be converted to a text representation (as either WKT or WKB), then using SQL might be the easiest way to get data into PostGIS. Data can be bulk-loaded into PostGIS/PostgreSQL by loading a text file of SQL <code>INSERT</code> statements using the <code>psql</code> SQL utility.
ja: 空間データを文字表現 (WKTかWKB)に変換できたら、SQLを使うのがPostGISにデータを持たせる最も簡単です。SQLユーティリティの<code>psql</code>を使用して、SQLの<code>INSERT</code>ステートメントのテキストファイルをロードすると、データをPostGIS/PostgreSQLに一括読み込みできます。

note: Tag: para
en: A SQL load file (<filename>roads.sql</filename> for example) might look like this:
ja: データアップロードファイル (たとえば<filename>roads.sql</filename>)は次のようになるでしょう。

note: Tag: para
en: The SQL file can be loaded into PostgreSQL using <code>psql</code>:
ja: SQLファイルのPostgreSQLへのロードは<code>psql</code>を使います。次のようにします。

note: Tag: title
en: Using the Shapefile Loader
ja: シェープファイルローダを使う

note: Tag: para
en: The <filename>shp2pgsql</filename> data loader converts Shapefiles into SQL suitable for insertion into a PostGIS/PostgreSQL database either in geometry or geography format. The loader has several operating modes selected by command line flags.
ja: <filename>shp2pgsql</filename>データローダは、ESRIシェープファイルをPostGIS/PostgreSQLデータベースに、ジオメトリまたはジオグラフィとして挿入するための適切なSQLに変換します。ローダには、次に示すコマンドラインフラグによって区別される、いくつかの操作モードがあります。

note: Tag: para
en: There is also a <filename>shp2pgsql-gui</filename> graphical interface with most of the options as the command-line loader. This may be easier to use for one-off non-scripted loading or if you are new to PostGIS. It can also be configured as a plugin to PgAdminIII.
ja: グラフィカルユーザインタフェースを持つ<filename>shp2pgsql-gui</filename>もあります。コマンドラインローダのオプションのほとんどが使えます。これは、スクリプト化されていない1回限りのロードの場合や、PostGIS初心者がロードする場合に、簡単に使用できます。PgAdminIIIのプラグインとすることもできます。

note: Tag: term
en: (c|a|d|p) These are mutually exclusive options:
ja: (c|a|d|p) 相互に排他的なオプションです。

note: Tag: para
en: Creates a new table and populates it from the Shapefile. <emphasis>This is the default mode.</emphasis>
ja: 新しいテーブルの作成とシェープファイルからのデータの読み込みを行います。<emphasis>これがデフォルトモードです</emphasis>。

note: Tag: para
en: Appends data from the Shapefile into the database table. Note that to use this option to load multiple files, the files must have the same attributes and same data types.
ja: シェープファイルからデータベーステーブルにデータを追加します。複数のファイルをロードするためにこのオプションを使う場合は、これらのファイルは同じ属性と同じデータ型を持つ必要があります。

note: Tag: para
en: Drops the database table before creating a new table with the data in the Shapefile.
ja: シェープファイルにあるデータを持つ新しいテーブルを作成する前にデータベーステーブルを削除します。

note: Tag: para
en: Only produces the table creation SQL code, without adding any actual data. This can be used if you need to completely separate the table creation and data loading steps.
ja: テーブル作成のSQLコードを生成するだけで、実際のデータは追加しません。このモードは、テーブル作成とデータロードとを完全に分けたい場合に使用します。

note: Tag: para
en: Display help screen.
ja: ヘルプ画面を表示します。

note: Tag: para
en: Use the PostgreSQL "dump" format for the output data. This can be combined with -a, -c and -d. It is much faster to load than the default "insert" SQL format. Use this for very large data sets.
ja: 出力データにPostgreSQLのダンプ書式を用います。このモードは-a, -c, -dと組み合わせて利用します。デフォルトの"insert"によるSQL書式よりも、大変早くロードできます。大きなデータセットではこちらを使用して下さい。

note: Tag: para
en: Creates and populates the geometry tables with the specified SRID. Optionally specifies that the input shapefile uses the given FROM_SRID, in which case the geometries will be reprojected to the target SRID.
ja: 指定したSRIDを持つジオメトリテーブルの生成や追加を行います。FROM_SRIDが与えられた場合には、入力シェープファイルに、これを使います 。この場合には、ジオメトリは変更先SRIDに投影変換します。

note: Tag: para
en: Keep identifiers' case (column, schema and attributes). Note that attributes in Shapefile are all UPPERCASE.
ja: 識別子 (カラム、スキーマおよび属性)の大文字小文字を保持します。シェープファイルの属性は全て大文字であることに注意して下さい。

note: Tag: para
en: Coerce all integers to standard 32-bit integers, do not create 64-bit bigints, even if the DBF header signature appears to warrant it.
ja: 全ての整数を標準の32ビット整数に強制します。DBFヘッダではそれが正当であったとしても、64ビットのbigintを生成しません。

note: Tag: para
en: Create a GiST index on the geometry column.
ja: ジオメトリカラムにGiSTインデックスを生成します。

note: Tag: para
en: -m <filename>a_file_name</filename> Specify a file containing a set of mappings of (long) column names to 10 character DBF column names. The content of the file is one or more lines of two names separated by white space and no trailing or leading space. For example:
ja: -m <filename>a_file_name</filename>で、長いカラム名を10文字のDBFカラム名に対応付けるファイルを指定します。ファイルは、1以上の行を持ちます。各行は空白区切りで二つの名前を持ち、行頭行末に空白を入れません。例を次に示します。

note: Tag: para
en: Generate simple geometries instead of MULTI geometries. Will only succeed if all the geometries are actually single (I.E. a MULTIPOLYGON with a single shell, or or a MULTIPOINT with a single vertex).
ja: マルチ系ジオメトリの替りに単一ジオメトリを生成します。全てのジオメトリが実際に単一である (たとえば単一の外環でなるMULTIPOLYGONや単一の頂点でなるMULTIPOINT)場合にのみ成功します。

note: Tag: term
en: -t &lt;dimensionality&gt;
ja: -t &lt;次元&gt;

note: Tag: para
en: Force the output geometry to have the specified dimensionality. Use the following strings to indicate the dimensionality: 2D, 3DZ, 3DM, 4D.
ja: 出力ジオメトリが特定の次元を持つよう強制します。次元は、2D, 3DZ, 3DM, 4Dの文字列を使います。

note: Tag: para
en: If the input has fewer dimensions that specified, the output will have those dimensions filled in with zeroes. If the input has more dimensions that specified, the unwanted dimensions will be stripped.
ja: 入力の次元が出力より小さい場合には、出力では0が入ります。入力の次元が大きい場合には、外されます。

note: Tag: para
en: Output WKT format, instead of WKB. Note that this can introduce coordinate drifts due to loss of precision.
ja: 出力書式をWKBでなくWKTにします。精度が低下して、座標変動が発生しうることに注意が必要です。

note: Tag: para
en: Execute each statement on its own, without using a transaction. This allows loading of the majority of good data when there are some bad geometries that generate errors. Note that this cannot be used with the -D flag as the "dump" format always uses a transaction.
ja: トランザクションを使わずに、ステートメントごとに実行するようにします。エラーの元となる不良なジオメトリがいくつか含んでいる時に、大半の良好なデータのロードが可能にするものです。ダンプ書式ではトランザクションを常に使うので、-Dフラグを指定している場合には使えません。

note: Tag: term
en: -W &lt;encoding&gt;
ja: -W &lt;エンコーディング&gt;

note: Tag: para
en: Specify encoding of the input data (dbf file). When used, all attributes of the dbf are converted from the specified encoding to UTF8. The resulting SQL output will contain a <code>SET CLIENT_ENCODING to UTF8</code> command, so that the backend will be able to reconvert from UTF8 to whatever encoding the database is configured to use internally.
ja: 入力データ (dbfファイル)のエンコーディングを指定します。全てのdbfの属性は指定されたエンコーディングからUTF8に変換されます。SQL出力結果には <code>SET CLIENT_ENCODING to UTF8</code>が含まれるようになり、バックエンドはUTF-8からデータベースが内部利用のために設定したエンコーディングに再変換できます。

note: Tag: term
en: -N &lt;policy&gt;
ja: -N &lt;方針&gt;

note: Tag: para
en: NULL geometries handling policy (insert*,skip,abort)
ja: NULLジオメトリ操作方針(insert*=挿入, skip=スキップ, abort=強制終了)を選択します。

note: Tag: para
en: -n Only import DBF file. If your data has no corresponding shapefile, it will automatically switch to this mode and load just the dbf. So setting this flag is only needed if you have a full shapefile set, and you only want the attribute data and no geometry.
ja: DBFファイルのみインポートします。対応するシェープファイルを持っていない場合、 自動的にこのモードになり、DBFファイルのみロードします。 このフラグは、完全なシェープファイル群を持っていて、属性データだけが欲しくてジオメトリが欲しくない時のみ使用します。

note: Tag: para
en: Use geography type instead of geometry (requires lon/lat data) in WGS84 long lat (SRID=4326)
ja: ジオメトリ型のかわりに、ジオグラフィ型で、WGS84経度緯度 (SRID=4326)を使用します (経度緯度データが必要です)。

note: Tag: para
en: Specify the tablespace for the new table. Indexes will still use the default tablespace unless the -X parameter is also used. The PostgreSQL documentation has a good description on when to use custom tablespaces.
ja: 新しいテーブルのテーブル空間を指定します。 -Xパラメータが使われない場合には、インデックスはデフォルトのテーブル空間を使用します。PostgreSQL文書には、テーブル空間を用いるべき時に関する良い文書があります。

note: Tag: para
en: Specify the tablespace for the new table's indexes. This applies to the primary key index, and the GIST spatial index if -I is also used.
ja: 新しいテーブルのインデックスで使われるテーブル空間を指定します。 主キーインデックスに適用され、-Iが合わせて使われている場合にはGiST空間インデックスにも適用されます。

note: Tag: para
en: When used, this flag will prevent the generation of <code>ANALYZE</code> statements. Without the -Z flag (default behavior), the <code>ANALYZE</code> statements will be generated.
ja: このフラグをこれを使う時、<code>ANALYZE</code>手続きの生成を防ぎます。-Zフラグが無い (デフォルトの振る舞い)場合には、<code>ANALYZE</code>手続きが生成されます。

note: Tag: para
en: An example session using the loader to create an input file and loading it might look like this:
ja: ローダを使って入力ファイルを生成してアップロードするセッション例は次の通りです。

note: Tag: para
en: A conversion and load can be done in one step using UNIX pipes:
ja: 変換とアップロードはUNIXのパイプを使うと一回で実行できます。

note: Tag: title
en: Extracting Spatial Data
ja: 空間データの抽出

note: Tag: para
en: Spatial data can be extracted from the database using either SQL or the Shapefile dumper. The section on SQL presents some of the functions available to do comparisons and queries on spatial tables.
ja: 空間データはSQLかシェープファイルダンパを使うと抽出できます。SQLの節では空間テーブルで比較とクエリに使用できる関数を示します。

note: Tag: title
en: Using SQL to Extract Data
ja: SQLを使ってデータを抽出する

note: Tag: para
en: The most straightforward way of extracting spatial data out of the database is to use a SQL <code>SELECT</code> query to define the data set to be extracted and dump the resulting columns into a parsable text file:
ja: データベース外へのデータ抽出の最も簡単な方法は、抽出するデータセットを定義し、<code>SELECT</code>問い合わせを使って、結果カラムを解析可能なテキストファイルにダンプすることです。

note: Tag: para
en: There will be times when some kind of restriction is necessary to cut down the number of records returned. In the case of attribute-based restrictions, use the same SQL syntax as used with a non-spatial table. In the case of spatial restrictions, the following functions are useful:
ja: 返されるレコードの数を減らすためにある種の制限が必要になる場合があります。属性ベースで制限をかける場合には、非空間テーブルで使うのと同じSQL文を使います。空間に制限をかけるには次の関数を使います。

note: Tag: para
en: This function tells whether two geometries share any space.
ja: この関数は、二つのジオメトリが空間を共有しているかどうかをテストします。

note: Tag: para
en: This tests whether two geometries are geometrically identical. For example, if 'POLYGON((0 0,1 1,1 0,0 0))' is the same as 'POLYGON((0 0,1 1,1 0,0 0))' (it is).
ja: この関数で、二つのジオメトリが幾何的に同一であるかを見ることができます。たとえば、'POLYGON((0 0,1 1,1 0,0 0))' は 'POLYGON((0 0,1 1,1 0,0 0))' と同じかを見ることができます (これは同じとなります)。

note: Tag: para
en: Next, you can use these operators in queries. Note that when specifying geometries and boxes on the SQL command line, you must explicitly turn the string representations into geometries function. The 312 is a fictitious spatial reference system that matches our data. So, for example:
ja: 次に、これらの演算子をクエリで使うことができます。SQLコマンドラインからジオメトリとボックスの指定を行うときは、明示的に文字列表現をジオメトリに変換しなければならないことに注意して下さい。たとえば、次のようになります。ただし312は架空の空間参照系番号で、ここでのデータに合致しています。

note: Tag: para
en: The above query would return the single record from the "ROADS_GEOM" table in which the geometry was equal to that value.
ja: 上のクエリは"ROADS_GEOM"テーブルから、その値と等価である単一のレコードを返します。

note: Tag: para
en: To check whether some of the roads passes in the area defined by a polygon:
ja: 道路がポリゴンで定義した面を通過するかどうかをチェックするには次のようにします。

note: Tag: para
en: The most common spatial query will probably be a "frame-based" query, used by client software, like data browsers and web mappers, to grab a "map frame" worth of data for display.
ja: 最も一般的な空間クエリは「フレームベース」のクエリでしょう。これは、表示するためのデータの価値のある「マップフレーム」を取得するために、データブラウザやウェブマッパのようなクライアントソフトウェアに使われます。

note: Tag: para
en: When using the "&amp;&amp;" operator, you can specify either a BOX3D as the comparison feature or a GEOMETRY. When you specify a GEOMETRY, however, its bounding box will be used for the comparison.
ja: "&amp;&amp;"演算子を使うとき、比較フィーチャーをBOX3DかGEOMETRYかに指定することができます。ただし、GEOMETRYを指定すると、それのバウンディングボックスが比較に使われます。

note: Tag: para
en: Using a "BOX3D" object for the frame, such a query looks like this:
ja: 次に示すクエリのように、フレームにBOX3Dオブジェクトを使います。

note: Tag: para
en: Note the use of the SRID 312, to specify the projection of the envelope.
ja: エンベロープの投影を指定するためにSRID 312を使っていることに注意して下さい。

note: Tag: title
en: Using the Shapefile Dumper
ja: ダンパを使う

note: Tag: para
en: The <filename>pgsql2shp</filename> table dumper connects to the database and converts a table (possibly defined by a query) into a shape file. The basic syntax is:
ja: <filename>pgsql2shp</filename>テーブルダンパは、データベースに直接接続して、テーブル (あるいはクエリによって定義されたもの)をシェープファイルに変換するものです。基本的な文は次の通りです。

note: Tag: para
en: The commandline options are:
ja: コマンドラインオプションは次の通りです。

note: Tag: term
en: -f &lt;filename&gt;
ja: -f &lt;ファイル名&gt;

note: Tag: para
en: Write the output to a particular filename.
ja: 特定のファイル名に出力を書きこみます。

note: Tag: term
en: -h &lt;host&gt;
ja: -h &lt;ホスト&gt;

note: Tag: para
en: The database host to connect to.
ja: 接続先データベースのホスト名。

note: Tag: term
en: -p &lt;port&gt;
ja: -p &lt;ポート&gt;

note: Tag: para
en: The port to connect to on the database host.
ja: 接続先データベースのポート。

note: Tag: term
en: -P &lt;password&gt;
ja: -P &lt;パスワード&gt;

note: Tag: para
en: The password to use when connecting to the database.
ja: データベースに接続するためのパスワード。

note: Tag: term
en: -u &lt;user&gt;
ja: -u &lt;ユーザ名&gt;

note: Tag: para
en: The username to use when connecting to the database.
ja: データベースに接続する際のユーザ名。

note: Tag: term
en: -g &lt;geometry column&gt;
ja: -g &lt;ジオメトリカラム&gt;

note: Tag: para
en: In the case of tables with multiple geometry columns, the geometry column to use when writing the shape file.
ja: 複数のジオメトリカラムを持つテーブルの場合の、シェープファイルの出力に使用するジオメトリカラム。

note: Tag: para
en: Use a binary cursor. This will make the operation faster, but will not work if any NON-geometry attribute in the table lacks a cast to text.
ja: バイナリカーソルを使います。これは、実行時間を短くしますが、テーブルの非ジオメトリ属性がテキストへのキャストを持っていない場合には、動作しません。

note: Tag: para
en: Raw mode. Do not drop the <varname>gid</varname> field, or escape column names.
ja: Rawモード。<varname>gid</varname>フィールドを落としたり、カラム名をエスケープしてはいけません。

note: Tag: term
en: -m <varname>filename</varname>
ja: -m <varname>ファイル名</varname>

note: Tag: para
en: Remap identifiers to ten character names. The content of the file is lines of two symbols separated by a single white space and no trailing or leading space: VERYLONGSYMBOL SHORTONE ANOTHERVERYLONGSYMBOL SHORTER etc.
ja: 識別名を10文字名に再割り当てします。 ファイルの中身は、一つの空白で区切られ、前と後に空白が無い二つのシンボルの行からなります。VERYLONGSYMBOL SHORTONE ANOTHERVERYLONGSYMBOL SHORTER等となります。

note: Tag: title
en: Spatial Indexes
ja: 空間インデックス

note: Tag: para
en: Spatial indexes make using a spatial database for large data sets possible. Without indexing, a search for features requires a sequential scan of every record in the database. Indexing speeds up searching by organizing the data into a structure which can be quickly traversed to find matching records.
ja: インデックスによって巨大データセットの空間データベースの使用が可能となります。インデックス無しでは、地物の検索を行う際に、データベースの全てのレコードに対するシーケンシャルスキャンが必要となります。インデックスによって、レコード探索のために早く移動できる構造を構築するので、検索速度が向上します。

note: Tag: para
en: The B-tree index method commonly used for attribute data is not very useful for spatial data, since it only supports storing and querying data in a single dimension. Data such as geometry (which has 2 or more dimensions) requires an index method that supports range query across all the data dimensions. One of the key advantages of PostgreSQL for spatial data handling is that it offers several kinds of index methods which work well for multi-dimensional data: GiST, BRIN and SP-GiST indexes.
ja: 一般的に属性データに使われるインデックス手法でありB木は、空間データではあまり有用ではありません。1次元データの格納とクエリにだけしか対応していないためです。ジオメトリのような2次元以上の次元を持つデータでは、全ての次元の範囲を指定できるインデックス手法が求められます。PostgreSQLの空間データ処理に関する主要な利点の一つに、多次元データで上手く動作するGiST、BRIN、SP-GiSTの複数のインデックス手法を提供していることです。

note: Tag: para
en: <emphasis role="bold">GiST (Generalized Search Tree)</emphasis> indexes break up data into "things to one side", "things which overlap", "things which are inside" and can be used on a wide range of data-types, including GIS data. PostGIS uses an R-Tree index implemented on top of GiST to index spatial data. GiST is the most commonly-used and versatile spatial index method, and offers very good query performance.
ja: <emphasis role="bold">GiST (Generalized Search Tree)</emphasis>インデックスは、データを「一方にあるもの」「オーバラップするもの」「内部にあるもの」に分解するもので、GISデータを含む幅広い範囲で使えます。PostGISはGiSTインデックス空間データをR木インデックス実装のベースにています。GiSTは最も一般的に使われ、多目的なインデックス手法で、非常に良好な問い合わせ効率を提供しています。

note: Tag: para
en: <emphasis role="bold">BRIN (Block Range Index)</emphasis> indexes operate by summarizing the spatial extent of ranges of table records. Search is done via a scan of the ranges. BRIN is only appropriate for use for some kinds of data (spatially sorted, with infrequent or no update). But it provides much faster index create time, and much smaller index size.
ja: <emphasis role="bold">BRIN (Block Range Index)</emphasis>インデックスは、空間範囲を集計することで動作します。探索は範囲のスキャンを通して行われます。BRINは一部の種類 (空間的にソートされ、更新がほぼ無いか全く無い)のデータだけに適切です。しかし、インデックス生成時間は非所に早く、インデックスサイズは非常に小さくなります。

note: Tag: para
en: <emphasis role="bold">SP-GiST (Space-Partitioned Generalized Search Tree)</emphasis> is a generic index method that supports partitioned search trees such as quad-trees, k-d trees, and radix trees (tries).
ja: <emphasis role="bold">SP-GiST (Space-Partitioned Generalized Search Tree)</emphasis>は4分木、kd木、基数木 (トライ木)のような部分木探索に対応する一般的なインデックス手法です。

note: Tag: para
en: Spatial indexes store only the bounding box of geometries. Spatial queries use the index as a <emphasis role="bold">primary filter</emphasis> to quickly determine a set of geometries potentially matching the query condition. Most spatial queries require a <emphasis role="bold">secondary filter</emphasis> that uses a spatial predicate function to test a more specific spatial condition. For more information on queying with spatial predicates see <xref linkend="using-query-indexes"/>.
ja: 空間インデックスはジオメトリのバウンディングボックスだけを格納します。空間クエリはインデックスは<emphasis role="bold">初期フィルタ</emphasis>として使用して、クエリ条件に一致する可能性のあるジオメトリを早く求めます。ほとんどの空間クエリでは、空間述語関数を使って特定の空間条件をテストする<emphasis role="bold">二次フィルタ</emphasis>が必要です。空間述語関数を使ったクエリの詳細情報については<xref linkend="using-query-indexes"/>をご覧下さい。

note: Tag: para
en: See also the <ulink url="https://postgis.net/workshops/postgis-intro/indexing.html">PostGIS Workshop section on spatial indexes</ulink>, and the <ulink url="https://www.postgresql.org/docs/current/indexes.html">PostgreSQL manual</ulink>.
ja: また、<ulink url="https://postgis.net/workshops/postgis-intro/indexing.html">PostGIS Workshop section on spatial indexes</ulink>と<ulink url="https://www.postgresql.org/docs/current/indexes.html">PostgreSQL manual</ulink>もご覧下さい。

note: Tag: title
en: GiST Indexes
ja: GiSTインデックス

note: Tag: para
en: GiST stands for "Generalized Search Tree" and is a generic form of indexing for multi-dimensional data. PostGIS uses an R-Tree index implemented on top of GiST to index spatial data. GiST is the most commonly-used and versatile spatial index method, and offers very good query performance. Other implementations of GiST are used to speed up searches on all kinds of irregular data structures (integer arrays, spectral data, etc) which are not amenable to normal B-Tree indexing. For more information see the <ulink url="https://www.postgresql.org/docs/current/gist.html">PostgreSQL manual</ulink>.
ja: GiSTは「汎用検索木 (Generalized Search Tree)」の意味で、多次元データのインデックスの一般化された形式です。PostGISはGiST上で実装しているR木インデックスをを空間データのインデックスに使用しています。GiSTは最も一般的に使われ、多目的なインデックス手法で、クエリ能率を非常に良くします。他のGiSTの実装は、通常のB木インデックスに従わない全ての種類の不規則なデータ構造 (整数配列, スペクトラルデータ等)の検索速度を向上させるために使います。詳細情報については<ulink url="https://www.postgresql.org/docs/current/gist.html">PostgreSQL manual</ulink>をご覧ください。

note: Tag: para
en: Once a spatial data table exceeds a few thousand rows, you will want to build an index to speed up spatial searches of the data (unless all your searches are based on attributes, in which case you'll want to build a normal index on the attribute fields).
ja: GISデータテーブルが数千行を超えたら、空間検索の速度向上のためインデックスを構築したくなるでしょう (これは属性検索でない場合です。属性でしたら通常のインデックスを属性フィールドに追加します)。

note: Tag: para
en: The syntax for building a GiST index on a "geometry" column is as follows:
ja: GiSTインデックスをジオメトリカラムに追加するための文は次の通りです。

note: Tag: para
en: The above syntax will always build a 2D-index. To get the an n-dimensional index for the geometry type, you can create one using this syntax:
ja: 上の文では常に2次元インデックスを構築します。n次元インデックスをジオメトリ型で使うには、次の文でインデックスを生成できます。

note: Tag: para
en: Building a spatial index is a computationally intensive exercise. It also blocks write access to your table for the time it creates, so on a production system you may want to do in in a slower CONCURRENTLY-aware way:
ja: 空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムではより遅いCONCURRENTLYを選択するかも知れません。次のようにします。

note: Tag: para
en: After building an index, it is sometimes helpful to force PostgreSQL to collect table statistics, which are used to optimize query plans:
ja: インデックス構築後に、時々PostgreSQLにテーブルの統計情報を集めさせると助かります。クエリプランの最適化に使われます。

note: Tag: title
en: BRIN Indexes
ja: BRINインデックス

note: Tag: para
en: BRIN stands for "Block Range Index". It is a general-purpose index method introduced in PostgreSQL 9.5. BRIN is a <emphasis>lossy</emphasis> index method, meaning that a secondary check is required to confirm that a record matches a given search condition (which is the case for all provided spatial indexes). It provides much faster index creation and much smaller index size, with reasonable read performance. Its primary purpose is to support indexing very large tables on columns which have a correlation with their physical location within the table. In addition to spatial indexing, BRIN can speed up searches on various kinds of attribute data structures (integer, arrays etc). For more information see the <ulink url="https://www.postgresql.org/docs/current/brin.html">PostgreSQL manual</ulink>.
ja: BRINは"Block Range Index"の略です。PostgreSQL 9.5で導入された汎用インデックス手法です。BRINは<emphasis>不可逆</emphasis>インデックス手法であり、レコードが与えた検索条件に合致することを確認する二番目のチェックが必要であることを意味しています (全ての空間インデックスで言えます)。非常に速いインデックス作成、非常に小さいインデックスサイズで、合理的な読み込み効率を持ちます。主目的は、非常に大きいテーブルのテーブル内の物理位置と関係があるカラムにインデックスを作ることに対応するためです。空間インデックスに加えて、BRINは様々な種類の属性データ構造 (整数、配列等)で速度向上させることができます。詳細情報については<ulink url="https://www.postgresql.org/docs/current/brin.html">PostgreSQL manual</ulink>をご覧ください。

note: Tag: para
en: Once a spatial table exceeds a few thousand rows, you will want to build an index to speed up spatial searches of the data. GiST indexes are very performant as long as their size doesn't exceed the amount of RAM available for the database, and as long as you can afford the index storage size, and the cost of index update on write. Otherwise, for very large tables BRIN index can be considered as an alternative.
ja: 空間テーブルが、ひとたび数千行を超えると、データの空間検索の速度向上にインデックスが必要と感じることになります。GiSTインデックスは、サイズがデータベースで使えるRAM容量を超えず、インデックスのストレージサイズに余裕があり、書き込み時のインデックス更新コストにも余裕があるなら、非常に高いパフォーマンスを発揮します。そうでない場合には、非常に大きなテーブルにおいては、BRINインデックスを代替に考えることができます。

note: Tag: para
en: A BRIN index stores the bounding box enclosing all the geometries contained in the rows in a contiguous set of table blocks, called a <emphasis>block range</emphasis>. When executing a query using the index the block ranges are scanned to find the ones that intersect the query extent. This is efficient only if the data is physically ordered so that the bounding boxes for block ranges have minimal overlap (and ideally are mutually exclusive). The resulting index is very small in size, but is typically less performant for read than a GiST index over the same data.
ja: BRINインデックスは、連続するテーブルブロックの集合 (<emphasis>ブロック範囲</emphasis>と言います)の全てのジオメトリを囲むバウンディングボックスを格納します。インデックスを使用した問い合わせを実行する時に、問い合わせ範囲とインタセクトするブロック範囲を見つけるためにスキャンします。これは、データが物理的に整列していて、ブロック範囲のバウンディングボックスのオーバラップが最小である (理想的には相互に排他的である)場合に限って効率的です。結果インデックスは非常に小さいサイズですが、通常、読み込み効率は、同じデータにおけるGiSTインデックスより悪くなります。

note: Tag: para
en: Building a BRIN index is much less CPU-intensive than building a GiST index. It's common to find that a BRIN index is ten times faster to build than a GiST index over the same data. And because a BRIN index stores only one bounding box for each range of table blocks, it's common to use up to a thousand times less disk space than a GiST index.
ja: BRINインデックスの構築は、はGiSTインデックスと比べて、CPU集中を非常に減らします。BRINインデックスはGiSTインデックスよりも、同じデータに対して10倍速く構築するのが普通です。BRINインデックスはテーブルブロックの範囲ごとに一つのバウンディングボックスしか格納しないので、GiSTインデックスと比べて、ディスクスペースを1000倍少なくできます。

note: Tag: para
en: You can choose the number of blocks to summarize in a range. If you decrease this number, the index will be bigger but will probably provide better performance.
ja: レンジ内で要約するブロック数を選択できます。この数字を減らすと、インデックスは大きくなりますが、効率向上の助けになる可能性があります。

note: Tag: para
en: For BRIN to be effective, the table data should be stored in a physical order which minimizes the amount of block extent overlap. It may be that the data is already sorted appropriately (for instance, if it is loaded from another dataset that is already sorted in spatial order). Otherwise, this can be accomplished by sorting the data by a one-dimensional spatial key. One way to do this is to create a new table sorted by the geometry values (which in recent PostGIS versions uses an efficient Hilbert curve ordering):
ja: BRINを効果的にするには、テーブルデータをブロック範囲のオーバラップの量を最小にするような物理的オーダーで格納します。データが既に適切に並び替えられているかも知れません (たとえば、既に空間オーダーで並び替えられているデータセットを他のデータベースからロードする場合)。そうでない場合には、一つの空間キーによるデータの並べ替えで実現できます。一つの方法として、ジオメトリ値で並べ替えた新しいテーブルを生成することです (最近のPostGISのバージョンで効果的なヒルベルト曲線オーダーが使われています)。

note: Tag: para
en: Alternatively, data can be sorted in-place by using a GeoHash as a (temporary) index, and clustering on that index:
ja: もしくは、データは、ジオハッシュを (一時的な)インデックスに使い、そのインデックスでクラスタリングを行うことによって適切に並べ替えることができます。

note: Tag: para
en: The syntax for building a BRIN index on a <code>geometry</code> column is:
ja: BRINインデックスを<code>ジオメトリ</code>カラムに追加するための文は次の通りです。

note: Tag: para
en: The above syntax builds a 2D index. To build a 3D-dimensional index, use this syntax:
ja: 上の文で2次元インデックスを構築します。3次元インデックスをビルドするには、この文を使います。

note: Tag: para
en: You can also get a 4D-dimensional index using the 4D operator class:
ja: また、4次元演算子クラスを使う4次元インデックスを使うこともできます。

note: Tag: para
en: The above commands use the default number of blocks in a range, which is 128. To specify the number of blocks to summarise in a range, use this syntax
ja: 上記のコマンドでは、範囲のブロック数はデフォルトの128を使用しています。集計で範囲のブロック数を指定するには、この文を使います。

note: Tag: para
en: Keep in mind that a BRIN index only stores one index entry for a large number of rows. If your table stores geometries with a mixed number of dimensions, it's likely that the resulting index will have poor performance. You can avoid this performance penalty by choosing the operator class with the least number of dimensions of the stored geometries
ja: また、BRINインデックスは、多数の行で一つのインデックス値を格納することを心に留めておいて下さい。テーブルに違う次元のジオメトリを格納する場合には、インデックスの効率が悪くなります。この効率欠落を回避するには、格納したジオメトリの次元数の最小値となる演算子クラスを選択します。

note: Tag: para
en: The <code>geography</code> datatype is supported for BRIN indexing. The syntax for building a BRIN index on a geography column is:
ja: 「ジオグラフィ」型もまたBRINインデックスに対応しています。BRINインデックスを「ジオグラフィ」カラムに構築するための文は次の通りです。

note: Tag: para
en: The above syntax builds a 2D-index for geospatial objects on the spheroid.
ja: 上の文では常に回転楕円体面上の地理空間オブジェクトの2次元インデックスを構築します。

note: Tag: para
en: Currently, only "inclusion support" is provided, meaning that just the <varname>&amp;&amp;</varname>, <varname>~</varname> and <varname>@</varname> operators can be used for the 2D cases (for both <code>geometry</code> and <code>geography</code>), and just the <varname>&amp;&amp;&amp;</varname> operator for 3D geometries. There is currently no support for kNN searches.
ja: 現在のところは「包括対応」だけをここで考えています。これは、<varname>&amp;&amp;</varname>, <varname>~</varname>, <varname>@</varname>の演算子だけが2次元で使われることを意味します (<code>ジオメトリ</code>と<code>ジオグラフィ</code>の両方)。 <varname>&amp;&amp;&amp;</varname>演算子は3次元ジオメトリで使えます。しばらくはKNN検索に対応しません。

note: Tag: para
en: An important difference between BRIN and other index types is that the database does not maintain the index dynamically. Changes to spatial data in the table are simply appended to the end of the index. This will cause index search performance to degrade over time. The index can be updated by performing a <code>VACUUM</code>, or by using a special function <code>brin_summarize_new_values(regclass)</code>. For this reason BRIN may be most appropriate for use with data that is read-only, or only rarely changing. For more information refer to the <ulink url="https://www.postgresql.org/docs/current/brin-intro.html#BRIN-OPERATION">manual</ulink>.
ja: BRINと他のインデックスとの重要な違いは、データベースがインデックスを動的に保守しないことです。テーブルの空間データを変更すると、単純にインデックスの末尾に追加しています。このためインデックス探索の能率が時間とともに低下します。インデックスは<code>VACUUM</code>か空間関数<code>brin_summarize_new_values(regclass)</code>を実行することで更新できます。このため、BRINは読み込み専用か、書き込みがほとんど発生しないよなデータでの利用では最も適切になりえます。詳細情報については、<ulink url="https://www.postgresql.org/docs/current/brin-intro.html#BRIN-OPERATION">manual</ulink>をご覧下さい。

note: Tag: para
en: To summarize using BRIN for spatial data:
ja: 空間データにBRINを使用して集計するには:

note: Tag: para
en: Index build time is very fast, and index size is very small.
ja: インデックス構築時間は非常に速く、インデックスサイズは非常に小さいです。

note: Tag: para
en: Index query time is slower than GiST, but can still be very acceptable.
ja: インデックスのクエリ時間はGiSTより遅いですが、十分許容できます。

note: Tag: para
en: Requires table data to be sorted in a spatial ordering.
ja: テーブルデータを空間順序で並べ替える必要があります。

note: Tag: para
en: Requires manual index maintenance.
ja: 手動でインデックスの保守をする必要があります。

note: Tag: para
en: Most appropriate for very large tables, with low or no overlap (e.g. points), which are static or change infrequently.
ja: 巨大なテーブルであって、オーバラップが少ないか無く (ポイントなど)、かつ静的か頻繁には変更しないようなものに、最も適しています。

note: Tag: para
en: More effective for queries which return relatively large numbers of data records.
ja: 比較的多数のデータレコードを返すクエリでの使用が、より効果的です。

note: Tag: title
en: SP-GiST Indexes
ja: SP-GiSTインデックス

note: Tag: para
en: SP-GiST stands for "Space-Partitioned Generalized Search Tree" and is a generic form of indexing for multi-dimensional data types that supports partitioned search trees, such as quad-trees, k-d trees, and radix trees (tries). The common feature of these data structures is that they repeatedly divide the search space into partitions that need not be of equal size. In addition to spatial indexing, SP-GiST is used to speed up searches on many kinds of data, such as phone routing, ip routing, substring search, etc. For more information see the <ulink url="https://www.postgresql.org/docs/current/spgist.html">PostgreSQL manual</ulink>.
ja: SP-GiSTは、「空間分割された一般探索木」を表します。四分木、k次元木、基数木 (トライ木)のような分割探索木に対応するインデックスの総称的な形式です。このデータ構造の一般的な機能は、検索空間を反復して分割することですが、分割は等しいサイズである必要はありません。SP-GiSTは、GISインデックスだけでなく、電話回線のルーティングや、IPルーティング、部分文字列検索等といった、様々な種類のデータを探索する速度の向上に使われます。詳細情報については<ulink url="https://www.postgresql.org/docs/current/spgist.html">PostgreSQL manual</ulink>をご覧下さい。

note: Tag: para
en: As it is the case for GiST indexes, SP-GiST indexes are lossy, in the sense that they store the bounding box enclosing spatial objects. SP-GiST indexes can be considered as an alternative to GiST indexes.
ja: GiSTインデックスを利用しているので、空間オブジェクトを覆うバウンディングボックスを保存するという意味で、SP-GiSTインデックスは不可逆です。SP-GiSTインデックスは、GiSTインデックスの代替と考えることができます。

note: Tag: para
en: Once a GIS data table exceeds a few thousand rows, an SP-GiST index may be used to speed up spatial searches of the data. The syntax for building an SP-GiST index on a "geometry" column is as follows:
ja: 一度GISデータテーブルが数千行を超えると、データの空間探索の速度向上にSP-GiSTインデックスを使うと良いかも知れません。「ジオメトリ」カラムにSP-GiSTインデックスを構築するための文は次の通りです。

note: Tag: para
en: The above syntax will build a 2-dimensional index. A 3-dimensional index for the geometry type can be created using the 3D operator class:
ja: 上の文では、2次元インデックスを構築します。ジオメトリ型の3次元インデックスは、次のように、3次元演算子クラスを使用して生成します。

note: Tag: para
en: Building a spatial index is a computationally intensive operation. It also blocks write access to your table for the time it creates, so on a production system you may want to do in in a slower CONCURRENTLY-aware way:
ja: 空間インデックスの構築は、計算量を集中させて行われます。また、この時には、テーブルへの書き込みアクセスがブロックされます。そのため、本番システムでは、より遅いCONCURRENTLYを選択するかも知れません。次のようにします。

note: Tag: para
en: An SP-GiST index can accelerate queries involving the following operators:
ja: SP-GiSTインデックスは次の演算子を含むクエリの実行速度を向上させられます。

note: Tag: para
en: &lt;&lt;, &amp;&lt;, &amp;&gt;, &gt;&gt;, &lt;&lt;|, &amp;&lt;|, |&amp;&gt;, |&gt;&gt;, &amp;&amp;, @&gt;, &lt;@, and ~=, for 2-dimensional indexes,
ja: 2次元インデックスについては &lt;&lt;, &amp;&lt;, &amp;&gt;, &gt;&gt;, &lt;&lt;|, &amp;&lt;|, |&amp;&gt;, |&gt;&gt;, &amp;&amp;, @&gt;, &lt;@, ~=です。

note: Tag: para
en: &amp;/&amp;, ~==, @&gt;&gt;, and &lt;&lt;@, for 3-dimensional indexes.
ja: 3次元インデックスについては &amp;/&amp;, ~==, @&gt;&gt;, and &lt;&lt;@ 。

note: Tag: para
en: There is no support for kNN searches at the moment.
ja: 現時点ではkNN探索に対応していません。

note: Tag: title
en: Tuning Index Usage
ja: インデックス使用のチューニング

note: Tag: para
en: Ordinarily, indexes invisibly speed up data access: once an index is built, the PostgreSQL query planner automatically decides when to use it to improve query performance. But there are some situations where the planner does not choose to use existing indexes, so queries end up using slow sequential scans instead of a spatial index.
ja: 通常、インデックスは知らないうちにデータアクセスの速度を向上します。ひとたびインデックスを構築すれば、PostgreSQLクエリプランナは自動的にクエリの能率を向上させるために使うべきかどうかを決定します。しかし、プランナが既存のインデックスを選択せず、遅いシーケンシャルスキャンを使い続ける場合があります。

note: Tag: para
en: If you find your spatial indexes are not being used, there are a few things you can do:
ja: 空間インデックスが使われていないのが分かった場合には、少しの行えることがあります。

note: Tag: para
en: Examine the query plan and check your query actually computes the thing you need. An erroneous JOIN, either forgotten or to the wrong table, can unexpectedly retrieve table records multiple times. To get the query plan, execute with <code>EXPLAIN</code> in front of the query.
ja: クエリプランの試験とクエリの確認で、必要なものを計算できます。誤ったJOINや忘れ去られたテーブルや間違ったテーブルでは、予期しないテーブルレコード検索が複数回行われることがありえます。クエリプランを得るにはクエリの先頭に<code>EXPLAIN</code>を付けて実行します。

note: Tag: para
en: Make sure statistics are gathered about the number and distributions of values in a table, to provide the query planner with better information to make decisions around index usage. <command>VACUUM ANALYZE</command> will compute both.
ja: テーブル内の値の数量と分布に関する統計情報を収集するとともに、クエリプランナにインデックス使用にかかる意思決定のための、より良い情報を与えるようにします。<command>VACUUM ANALYZE</command>は両方を計算します。

note: Tag: para
en: You should regularly vacuum your databases anyways. Many PostgreSQL DBAs run <command>VACUUM</command> as an off-peak cron job on a regular basis.
ja: データベースに対する定期的なvacuumは常に実行するべきです。多くのPostgreSQLデータベースエージェントは、閑散時のcronジョブとして定期的に<command>VACUUM</command>を実行します。

note: Tag: para
en: If vacuuming does not help, you can temporarily force the planner to use the index information by using the command <command>SET ENABLE_SEQSCAN TO OFF;</command>. This way you can check whether the planner is at all able to generate an index-accelerated query plan for your query. You should only use this command for debugging; generally speaking, the planner knows better than you do about when to use indexes. Once you have run your query, do not forget to run <command>SET ENABLE_SEQSCAN TO ON;</command> so that the planner will operate normally for other queries.
ja: VACUUMが役に立たない場合には、<command>SET ENABLE_SEQSCAN TO OFF;</command>コマンドを使用して、一時的にプランナにインデックス情報の使用を強制することができます。この方法で、プランナがインデックス使用を多くしたクエリプランを生成できるかどうかを確認できます。このコマンドはデバッグにのみ使用してください。一般的に言えば、プランナはインデックスを使用するタイミングをよく知っています。クエリを実行したら<command>SET ENABLE_SEQSCAN TO ON;</command>を実行して、他のクエリでは通常操作にすることを忘れないでください。

note: Tag: para
en: If <command>SET ENABLE_SEQSCAN TO OFF;</command> helps your query to run faster, your Postgres is likely not tuned for your hardware. If you find the planner wrong about the cost of sequential versus index scans try reducing the value of <varname>RANDOM_PAGE_COST</varname> in <code>postgresql.conf</code>, or use <command>SET RANDOM_PAGE_COST TO 1.1;</command>. The default value for <varname>RANDOM_PAGE_COST</varname> is 4.0. Try setting it to 1.1 (for SSD) or 2.0 (for fast magnetic disks). Decreasing the value makes the planner more likely to use index scans.
ja: <command>SET ENABLE_SEQSCAN TO OFF;</command>でクエリ速度が向上する場合には、PostgreSQLのハードウェア関連のチューンが行われていないのかも知れません。プランナがシーケンシャル対インデックスのコストが誤っている場合には、<code>postgresql.conf</code>内にある<varname>RANDOM_PAGE_COST</varname>の値を変更してみて下さい。<command>SET RANDOM_PAGE_COST TO 1.1;</command>とします。<varname>RANDOM_PAGE_COST</varname>のデフォルト値は4.0です。1.1 (SSDの場合)または2.0 (高速磁気ディスクの場合)を試してみて下さい。値を小さくするほど、プランナがインデックススキャンをしやすくなります。

note: Tag: para
en: If <command>SET ENABLE_SEQSCAN TO OFF;</command> does not help your query, the query may be using a SQL construct that the Postgres planner is not yet able to optimize. It may be possible to rewrite the query in a way that the planner is able to handle. For example, a subquery with an inline SELECT may not produce an efficient plan, but could possibly be rewritten using a LATERAL JOIN.
ja: <command>SET ENABLE_SEQSCAN TO OFF;</command>がクエリの助けにならないなら、クエリはPostgreSQLプランナがまだ最適化できないSQL構成なのかも知れません。プランナが処理できるようにクエリを再記述できるかもしれません。例えば、インラインSELECTを持つ副問い合わせがあると、効果的なプランを作らないことがあり、LATERAL JOINを使うように書き換えることができます。

note: Tag: para
en: For more information see the Postgres manual section on <ulink url="https://www.postgresql.org/docs/current/runtime-config-query.html">Query Planning</ulink>.
ja: 詳細情報についてはPostgreSQLマニュアルの<ulink url="https://www.postgresql.jp/document/current/html/runtime-config-query.html">問い合わせ計画</ulink>節をご覧下さい。
