Chapter 4. 数据管理

开放地理空间联盟 (OGC) 定义了简单功能访问标准 (SFA)，以提供地理空间数据模型。 它定义了几何的基本空间类型，以及操纵和转换几何值以执行空间分析任务的操作。 PostGIS 将 OGC 几何模型实现为 PostgreSQL 数据类型 geometry 和 geography。

几何是一种抽象类型。几何值属于其具体子类型之一。子类型表示各种类型和各种维度的几何形状。其中包括基本类型点, 线, 线性环 和 面, 以及集合类型多点, 多线, 多面 和 几何对象集合。简单 功能访问 - 第一部分:通用体系结构v1.2.1 为结构PolyhedralSurface, Triangle和TIN添加了子类型。

几何图形在二维笛卡尔平面上对形状进行建模。PolyhedralSurface, Triangle,和 TIN 也可以表示三维空间中的形状。形状的大小和位置由坐标指定。每个坐标都有 X 和 Y 坐标轴值，用于确定其在平面上的位置。形状由点和线构造，点由单个坐标定义，线由两个坐标定义。

坐标可能包含可选的Z和M纵坐标值。Z纵坐标通常用于表示高程。M纵坐标包含一个测量值，该值可能表示时间或距离。如果几何值中存在Z或M值，则必须为几何中的每个点定义这些值。如果几何具有 Z 或 M 纵坐标，则坐标尺寸为 3D;如果它同时具有 Z 和 M，则坐标尺寸为 4D。

几何值与 空间参考系统指示它所嵌入的坐标系。空间参考系由几何SRID编号标识。X轴和Y轴的单位由空间参考系确定。平面参考系统中，X 和 Y 坐标通常表示东向和北向，而在 大地测量测量系统中，它们表示经度和纬度。SRID 0 表示一个具有无单位的无限笛卡尔平面。请参见Section 4.5, “空间参考系统”。

几何维度是几何类型的属性。点类型的维度为 0，线性类型的维度为 1， 多边形类型的维度为 2。集合具有最大元素维度的维度。

几何值可以为 空。空值不包含顶点（对于原子几何类型）或不包含元素（对于集合）。

几何值的一个重要属性是它们的空间范围或边界框，OGC模型将其称为包络。这是包含几何坐标的2维或3维框。它是在坐标空间中表示几何图形范围并检查两个几何图形是否相互作用的有效方法。

几何模型允许评估拓扑空间关系，如Section 5.1.1, “维度扩展九交模型（Dimensionally Extended 9-Intersection Model）”中所述。为了支持这一点，为每种几何类型定义了内部, 外部和边界的概念。几何图形在拓扑上是封闭的，因此它们总是包含它们的边界。边界是比几何体本身小一维的几何体。

OGC几何模型为每种几何类型定义了有效性规则。这些规则确保几何值表示现实情况（例如，可以指定一个具有孔的多边形位于外壳之外，但从几何角度来看这是没有意义的，因此是无效的）。PostGIS 也允许存储和操作无效的几何值。这允许在需要时检测和修复它们。请参阅Section 4.4, “几何有效性验证”

POINT (1 2)
POINT Z (1 2 3)
POINT ZM (1 2 3 4)

LINESTRING (1 2, 3 4, 5 6)

LINEARRING (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0)

POLYGON ((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0))

MULTIPOINT ( (0 0), (1 2) )

MULTILINESTRING ( (0 0,1 1,1 2), (2 3,3 2,5 4) )

MULTIPOLYGON (((1 5, 5 5, 5 1, 1 1, 1 5)), ((6 5, 9 1, 6 1, 6 5)))

GEOMETRYCOLLECTION ( POINT(2 3), LINESTRING(2 3, 3 4))

POLYHEDRALSURFACE Z (
  ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
  ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
  ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
  ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
  ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
  ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

TRIANGLE ((0 0, 0 9, 9 0, 0 0))

TIN Z ( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

ISO/IEC 13249-3 SQL多媒体-空间标准 （SQL/MM）扩展了 OGC SFA 以定义包含弯曲几何图形的子类型。SQL/MM 类型支持 XYM、XYZ 和 XYZM。

	SQL-MM 实现中的所有浮点比较 按照指定的公差执行，目前为 1E-8。

CIRCULARSTRING(0 0, 1 1, 1 0)

CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)

COMPOUNDCURVE( CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))

CURVEPOLYGON(
  CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),
  (1 1, 3 3, 3 1, 1 1) )

CURVEPOLYGON(
  COMPOUNDCURVE( CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),
                 (4 3, 4 5, 1 4, 0 0)),
  CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )

MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

MULTISURFACE(
  CURVEPOLYGON(
    CIRCULARSTRING( 0 0, 4 0, 4 4, 0 4, 0 0),
    (1 1, 3 3, 3 1, 1 1)),
  ((10 10, 14 12, 11 10, 10 10), (11 11, 11.5 11, 11 11.5, 11 11)))

OGC SFA规范定义了两种标准格式，用于表示供外部使用的几何值。已知文本（WKT）和已知二进制文件（WKB）。WKT和WKB都包含有关定义对象的类型和坐标的信息。

已知文本（WKT）提供空间数据的标准字符表示形式。以下是空间对象的 WKT 表示形式示例：

WKT输入和输出由函数ST_AsText和ST_GeomFromText提供：

text WKT = ST_AsText(geometry);
geometry = ST_GeomFromText(text WKT, SRID);

例如，从WKT和SRID创建并插入空间对象的语句如下所示：

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

已知二进制 （WKB） 是空间数据二进制数据（字节数组）的可移植且准确的表示形式。空间对象的 WKB 表示如下所示：

WKB 的输入和输出由以下函数ST_AsBinary和 ST_GeomFromWKB提供：

bytea WKB = ST_AsBinary(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);

例如，用于创建和插入WKB的空间对象如下所示：

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromWKB('\x0101000000000000000000f03f000000000000f03f', 312), 'A Place');

OGC SFA 规范最初仅支持 2D 几何形状， 并且几何 SRID 不包含在输入/输出表示中。OGC SFA 规范 1.2.1（与 ISO 19125 标准一致） 增加了对 3D （ZYZ） 和测量（XYM 和 XYZM）坐标的支持， 但仍然不包括 SRID 值。

由于这些限制，PostGIS定义了扩展的EWKB和EWKT格式。它们提供 3D（XYZ 和 XYM）和 4D （XYZM） 坐标支持，并包括 SRID 信息。 包含所有几何信息允许 PostGIS 使用 EWKB 作为记录格式 （例如，在转储文件中）。

EWKB 和 EWKT 用于 PostGIS 数据对象的“规范形式”。 对于输入，二进制数据的规范形式是 EWKB，对于文本数据，接受 EWKB 或 EWKT。 这允许通过使用 ::geometry将 HEXEWKB 或 EWKT中的文本值转换为几何值来创建几何值。 对于输出，二进制的规范形式是 EWKB，对于文本，规范形式是 HEXEWKB（十六进制编码的 EWKB）。

例如，此过程使用来自EWKT文本值的强制转换生成几何图形，并使用HEXWKB的规范格式输出它们：

SELECT 'SRID=4;POINT(0 0)'::geometry;
  geometry
  ----------------------------------------------------
  01010000200400000000000000000000000000000000000000

PostGIS EWKT 输出与 OGC WKT 有一些不同之处：

EWKT避免过度指定维度以及OGC/ISO格式可能发生的不一致，例如：

	PostGIS扩展格式向上兼容OGC格式，因此，每个有效的 OGC WKB/WKT 也是有效的 EWKB/EWKT。但是，将来这可能会有所不同，如果 OGC 以与 PosGIS 定义冲突的方式扩展格式。因此，您不应该依赖这种兼容性！

空间对象的 EWKT 文本表示的示例如下：

可以使用以下函数使用这些格式的输入和输出：

bytea EWKB = ST_AsEWKB(geometry);
text EWKT = ST_AsEWKT(geometry);
geometry = ST_GeomFromEWKB(bytea EWKB);
geometry = ST_GeomFromEWKT(text EWKT);

例如，使用 EWKT 创建和插入 PostGIS 空间对象的语句为：

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

您可以使用带有地理类型列的 CREATE TABLE SQL 语句创建一个表来存储地理数据。 以下示例创建一个表，其中包含存储 WGS84 大地坐标系 (SRID 4326) 中的 2D LineString 的地理列：

CREATE TABLE global_points (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    location geography(POINT,4326)
  );

地理类型支持两个可选的类型修饰符:

以下是生成包含地理列的表的示例：

地理字段在geography_columns系统视图中注册。 您可以查询geography_columns视图并看到该表已列出：

SELECT * FROM geography_columns;

创建空间索引的工作方式与创建几何列相同。 PostGIS 将注意到列类型是 GEOGRAPHY，并创建适当的基于球体的索引，而不是用于 GEOMETRY 的常用平面索引。

-- Index the test table with a spherical index
CREATE INDEX global_points_gix ON global_points USING GIST ( location );

您可以采用与几何相同的方式将数据插入地理表中。如果几何数据具有 SRID 4326，则几何数据将自动转换为地理类型。也可以使用 EWKT和EWKB 格式 以指定地理值。

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

spatial_ref_sys表中列出的任何大地测量（经/纬度）空间参考系统都可以指定为地理 SRID。如果使用非大地坐标系，则会产生错误。

-- NAD 83 lon/lat
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140

-- NAD27 lon/lat
SELECT 'SRID=4267;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140

-- NAD83 UTM zone meters - gives an error since it is a meter-based planar projection
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.

查询和测量功能以米为单位。因此，距离参数以米为单位（面积为平方米）。

-- A distance query using a 1000km tolerance
SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

通过计算一架从西雅图飞往伦敦的飞机（LINESTRING(-122.33 47.606, 0.0 51.5) 表示的大圆航线）飞行过程中距离雷克雅未克（POINT(-21.96 64.15)）的距离，您可以看到地理学的作用（绘制路线）。

地理类型计算出雷克雅未克与西雅图和伦敦之间的大圆飞行路径之间的球体上的真实最短距离为 122.235 公里。

-- Distance calculation using GEOGRAPHY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);
   st_distance
-----------------
 122235.23815667

几何类型在平面世界地图上计算雷克雅未克之间的笛卡尔距离以及西雅图和伦敦之间的直线，这是没有意义的。计算结果的标称单位是“度”，但它与点之间的真实角度差并不对应，称其为“度”本身是不准确的。

-- Distance calculation using GEOMETRY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);
      st_distance
--------------------
 13.342271221453624

地理数据类型允许您将数据存储在经度/纬度坐标中，但有代价：在地理上定义的函数比在几何上定义的函数少;定义的那些函数需要更多 CPU 时间来执行。

您选择的数据类型应由正在构建的应用程序的预期工作区域确定。您的数据是跨越全球还是大片大陆区域，还是州、县或直辖市的本地数据？

有关地理和几何之间的支持比较，请参见Section 13.11, “PostGIS函数支持矩阵”。有关地理函数的简要列表和说明，请参见 Section 13.4, “PostGIS 地理支持函数”

简单几何是指没有异常几何点（例如自交或自相切）的几何。

作为 0 维几何对象，POINT 本质上是简单。

MULTIPOINT是简单的，如果没有两个坐标（POINT）的坐标值相同（具有相同的坐标值）。

如果LINESTRING不两次穿过同一点（端点除外），则该 LINESTRING 很简单。如果简单线串的端点相同，则称为闭合线并称为线性环。

(a) 和(c) 是简单的LINESTRING. (b) 和 (d) 不简单。 (c) 是一个封闭的线性环。

(a)	(b)
(c)	(d)

仅当MULTILINESTRING 的所有元素都很简单 并且任意两个元素之间的唯一交集发生在两个元素边界上的点时，MULTILINESTRING 才是简单的。

(e) 和(f) 是简单的 MULTILINESTRING。(g)不简单。

(e)

(f)

(g)

POLYGON是由线性环形成的，所以常见的多边形几何总是简单的。

测试几何图形是否简单，使用 ST_IsSimple函数：

SELECT
   ST_IsSimple('LINESTRING(0 0, 100 100)') AS straight,
   ST_IsSimple('LINESTRING(0 0, 100 100, 100 0, 0 100)') AS crossing;

 straight | crossing
----------+----------
 t        | f

一般来说，PostGIS 函数不要求几何参数很简单。简单性主要用作定义几何有效性的基础。这也是某些类型的空间数据模型的要求（例如，线性网络通常不允许线交叉）。使用 ST_UnaryUnion 可以使多点和线性几何变得简单。

几何有效性主要适用于二维几何形状（POLYGON和MULTIPOLYGON）。有效性是由允许多边形几何形状明确地模拟平面区域的规则定义的。

POLYGON以下条件是有效的：

(h)和(i) 是有效的POLYGON。(j-m) 是无效的。(j)可以表示为有效的MULTIPOLYGON。

(h)	(i)	(j)
(k)	(l)	(m)

MULTIPOLYGON以下条件是有效的：

(n)是有效的MULTIPOLYGON。(o)和(p)无效。

(n)

(o)

(p)

这些规则意味着有效的多边形几何也很简单。

对于线性几何，唯一的有效性规则是LINESTRING必须至少有两个点并且具有非零长度（或等效地，至少有两个不同的点。请注意，非简单（自相交）线是有效的。

SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)') AS len_nonzero,
   ST_IsValid('LINESTRING(0 0, 0 0, 0 0)') AS len_zero,
   ST_IsValid('LINESTRING(10 10, 150 150, 180 50, 20 130)') AS self_int;

 len_nonzero | len_zero | self_int
-------------+----------+----------
 t           | f        | t

POINT和MULTIPOINT 几何形状没有有效性规则。

PostGIS允许创建和存储有效和无效的几何图形。这允许检测并标记或修复无效的几何图形。在某些情况下，OGC有效性规则比预期更严格（例如零长度线串和带有倒孔的多边形。）

PostGIS提供的许多功能都依赖于几何参数有效的假设。例如，计算在多边形外部定义有孔的多边形的面积，或者从非简单边界线构造多边形是没有意义的。假设有效的几何输入允许函数更有效地运行，因为它们不需要检查拓扑正确性。（值得注意的例外是零长度线和具有反转的多边形通常可以正确处理。）此外，如果输入有效，大多数 PostGIS 函数都会生成有效的几何输出。 这使得 PostGIS 功能可以安全地链接在一起。

如果在调用 PostGIS 函数时遇到意外错误消息 （例如“GEOS Intersection（） 抛出了一个错误！”),应首先确认函数参数是否有效。如果无效，请考虑使用以下技术之一来验证您正在处理的数据。

	如果函数报告有效输入错误，那么您可能在 PostGIS 或其使用的库之一中发现错误，您应该将此报告给 PostGIS 项目。如果 PostGIS 函数为有效输入返回无效几何图形，情况也是如此。

要测试几何图形是否有效,请使用ST_IsValid函数。 执行以下操作：

SELECT ST_IsValid('POLYGON ((20 180, 180 180, 180 20, 20 20, 20 180))');
-----------------
 t

有关几何无效的性质和位置的信息由ST_IsValidDetail函数确定：

SELECT valid, reason, ST_AsText(location) AS location
    FROM ST_IsValidDetail('POLYGON ((20 20, 120 190, 50 190, 170 50, 20 20))') AS t;

 valid |      reason       |                  location
-------+-------------------+---------------------------------------------
 f     | Self-intersection | POINT(91.51162790697674 141.56976744186045)

在某些情况下，需要自动纠正无效的几何形状。 使用 ST_MakeValid 函数来执行此操作。 （ST_MakeValid 是空间函数的一种情况，确实允许无效输入！）

测试复杂几何的刚度需要花费大量CPU时间，因此默认情况下，PostGIS 在加载几何时不会验证几何。如果不信任数据源，则可以使用检查约束对表进行强制验证。执行以下操作：

ALTER TABLE mytable
  ADD CONSTRAINT geometry_valid_check
        CHECK (ST_IsValid(geom));

PostGIS使用的SPATIAL_REF_SYS表是一个符合 OGC 标准的数据库表，用于定义可用的空间参考系统。它包含数字 SRID 和坐标系的文本描述。

spatial_ref_sys表定义为：

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

这些列是：

检索用于变换的空间参考系统定义时，PostGIS使用以下策略：

PostGISspatial_ref_sys表包含由PROJ投影库处理的 3000 多个最常见的空间参考系统定义。但有很多坐标系它不包含。如果您具有有关空间参考系统的所需信息，则可以将 SRS 定义添加到表中。或者，如果您熟悉 PROJ 构造，则可以定义自己的自定义空间参考系统。请记住，大多数空间参考系统都是区域性的，在其预期范围之外使用时没有任何意义。

http://spatialreference.org/可用于查找不在 PostGIS 核心集中的空间参考系统

一些常用的空间参考系统包括：4326 - WGS 84 经纬度, 4269 - NAD 83 经纬度, 3395 - WGS 84 世界墨卡托投影, 2163 - 美国国家地图等面积投影以及 60 个 WGS84 UTM 区域。UTM 区域是最理想的测量区域之一，但仅覆盖 6 度区域。（要确定您感兴趣的区域使用哪个UTM区域，请参阅 utmzone PostGIS plpgsql帮助程序函数。）

美国各州使用国家平面空间参考系统（基于米或英尺）- 通常每个州有一个或两个。 大多数基于米的数据都在核心集中，但许多基于英尺的数据或 ESRI 创建的数据需要从spatialreference.org复制。

您甚至可以定义非基于地球的坐标系，比如 火星2000这个火星坐标系是非平面的（以球度为单位），但是您可以将其与 geography类型一起使用,以米而不是度为单位获得长度和邻近测量值。

以下是使用未分配的SRID和以美国为中心的兰伯特等角投影的PROJ定义加载自定义坐标系的示例：

INSERT INTO spatial_ref_sys (srid, proj4text)
VALUES ( 990000,
  '+proj=lcc  +lon_0=-95 +lat_0=25 +lat_1=25 +lat_2=25 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs'
);

您可以使用SQL语句中的CREATE TABLE语句创建一个用于存储几何数据的表，其中包括一个geometry类型的列。以下示例创建了一个带有几何列的表，该列存储BC-Albers坐标系统（SRID 3005）中的2D（XY）LineStrings：

CREATE TABLE roads (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    geom geometry(LINESTRING,3005)
  );

geometry类型对应于两个可选的类型修饰符：

创建具有几何列的表的示例：

一个表可以有多个几何列。这可以通过在创建表时指定它或使用ALTER TABLE语句添加它来实现。下面的示例演示如何添加列以存储 3D LineStrings：

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);

适用于SQL的OGC简单要素规范定义了用于描述GEOMETRY_COLUMNS结构的元数据表。在 PostGIS 中，geometry_columns是从数据库的系统目录表中读取的视图。这可确保空间元数据信息始终与当前定义的表或视图一致。视图结构为:

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

这些列是：

您可能需要这样做的两种情况是 SQL 视图和批量插入。对于批量插入情况，您可以通过约束列或执行更改表来更正 Geometry_columns 表中的注册。对于视图，您可以使用 CAST 操作来公开。 请注意，如果您的列是基于typmod的，创建过程将正确注册它，因此无需执行任何操作。 此外，未对几何应用空间函数的视图将与基础表几何列注册相同。

-- Lets say you have a view created like this
CREATE VIEW public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395) As geom, f_name
        FROM public.mytable;

-- For it to register correctly
-- You need to cast the geometry
--
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
        FROM public.mytable;

-- If you know the geometry type for sure is a 2D POLYGON then you could do
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name
        FROM public.mytable;

--Lets say you created a derivative table by doing a bulk insert
SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

-- Create 2D index on new table
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- If your points are 3D points or 3M points,
-- then you might want to create an nd index instead of a 2D index
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- To manually register this new table's geometry column in geometry_columns.
-- Note it will also change the underlying structure of the table to
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- To retain the constraint-based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); 

尽管仍然支持旧的基于约束的方法，但直接在视图中使用的基于约束的几何列将无法在 Geometry_columns 中正确注册，typmod 也是如此。在此示例中，我们使用typmod定义一个列，使用约束定义另一个列。

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

在 psql 中运行

\d pois_ny;

我们观察到它们的定义不同——一个是类型，一个是约束

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

在geometry_columns中，两者都已正确注册

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

但是 - 如果我们要创建这样的视图

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

基于typmod的几何视图列正确注册， 但基于约束的约束没有。

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

这可能会在未来版本的PostGIS中发生变化，但目前 要强制基于约束的视图列正确注册，您需要执行以下操作：

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

如果空间数据可以转换为文本表示（如 WKT 或 WKB），那么使用SQL可能是将数据导入 PostGIS 的最简单方法。通过使用psql SQL 实用程序加载 SQL INSERT语句的文本文件，可以将数据批量加载到 PostGIS/PostgreSQL 中。

SQL加载文件（例如roads.sql ）可能看起来像这样：

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres');
COMMIT;

SQL文件可以使用psql方法加载到PostgreSQL中:

psql -d [database] -f roads.sql

shp2pgsql数据加载器将 Shapefile 转换为适合以几何或地理格式插入PostGIS/PostgreSQL 数据库的 SQL。加载程序有多种通过命令行标志选择的操作模式。

还有一个shp2pgsql-gui图形界面，其中大多数选项作为命令行加载程序。对于一次性非脚本加载或者您是 PostGIS 新手，这可能更容易使用。它还可以配置为 PgAdminIII 的插件。

使用加载程序创建输入文件并加载它的示例会话可能如下所示：

# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable 
> roads.sql
# psql -d roadsdb -f roads.sql

转换和加载可以使用 UNIX 通道一步完成：

# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

从数据库中提取空间数据的最直接方法是使用 SQL SELECT 查询来定义要提取的数据集并将结果列转储到可解析的文本文件中：

db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
          1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
          2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
          3 | LINESTRING(192783 228138,192612 229814) | Paul St
          4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
          5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
          6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
          7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

有时需要某种限制来减少返回的记录数量。对于基于属性的限制，请使用与非空间表相同的 SQL 语法。在空间限制的情况下，以下函数很有用：

接下来，您可以在查询中使用这些运算符。请注意，在 SQL 命令行上指定几何图形和框时，必须显式将字符串表示形式转换为几何函数。312是一个虚构的空间参考系统，与我们的数据相匹配。例如：

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

上面的查询从“ROADS_GEOM”表中返回与该值等效的单个记录。

要检查道路是否穿过由多边形定义的面，请执行以下操作：

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

最常见的空间查询可能是“基于框架”的查询，由数据浏览器和网络制图器等客户端软件使用，以获取“地图框架”的数据进行显示。

使用“&&”运算符时，可以指定比较特征是 BOX3D 还是几何。 但是，如果指定几何图形，则其边界框用于比较。

使用框架的“BOX3D”对象，查询如下所示：

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

请注意使用 SRID 312 来指定包络的投影。

pgsql2shp表转储器连接到数据库并将表（可能由查询定义）转换为形状文件。 基本语法是：

pgsql2shp [<options
>] <database
> [<schema
>.]<table>

pgsql2shp [<options
>] <database
> <query>

命令行选项包括：

GiST 代表“广义搜索树”，是多维数据索引的通用形式。PostGIS 使用在 GiST 之上实现的 R-Tree 索引来索引空间数据。GiST是最常用、最通用的空间索引方法，提供非常好的查询性能。GiST 的其他实现用于加速对不适合普通 B 树索引的各种不规则数据结构（整数数组、光谱数据等）的搜索。有关详细信息，请参阅PostgreSQL手册。

一旦空间数据表超过几千行，您将需要构建索引来加速数据的空间搜索（除非您的所有搜索都基于属性，在这种情况下，您将需要在空间数据表上构建普通索引） 属性字段）。

在“geometry”列上构建 GiST 索引的语法如下：

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

上述语法将始终构建 2D 索引。若要获取几何类型的 n 维索引，可以使用以下语法创建一个索引：

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

构建空间索引是一项计算密集型工作。它还会在创建表时阻止对表的写入访问，因此在生产系统上，您可能希望以较慢的并发感知方式执行：

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

建立索引后，让 PostgreSQL 不时收集表上的统计信息会很有帮助。它用于优化查询计划：

VACUUM ANALYZE [table_name] [(column_name)];

BRIN stands for "Block Range Index". It is a general-purpose index method provided by PostgreSQL. BRIN is a lossy 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 PostgreSQL manual.

一旦空间表超过几千行，您将需要构建索引来加速数据的空间搜索。只要 GiST 索引的大小不超过数据库可用的 RAM 量，并且只要您能够承受索引存储大小以及写入时更新索引的成本，GiST 索引的性能就非常好。 否则，对于非常大的表，可以考虑将 BRIN 索引作为替代方案。

BRIN 索引存储包围一组连续的表块（称为块范围）中的行中包含的所有几何图形的边界框。使用索引执行查询时，将扫描块范围以查找与查询范围相交的块范围。仅当数据经过物理排序以使块范围的边界框具有最小重叠（并且理想情况下是互斥的）时，这才是有效的。 生成的索引非常小，但读取相同数据时的性能通常低于 GiST 索引。

构建 BRIN 索引比构建 GiST 索引占用的 CPU 资源要少得多。我们经常发现，对于相同数据，BRIN 索引的构建速度比 GiST 索引快十倍。由于 BRIN 索引只为每个表块范围存储一个边界框，因此通常使用的磁盘空间比 GiST 索引少一千倍。

您可以选择要在某个范围内汇总的块数。 如果减少这个数字，索引会更大，但可能会提供更好的性能。

为了使 BRIN 有效，表数据应按物理顺序存储，从而最大限度地减少块范围重叠量。数据可能已经适当排序（例如，如果它是从已按空间顺序排序的另一个数据集加载的）。否则，这可以通过按一维空间键对数据进行排序来完成。 一种方法是创建一个按几何值排序的新表（在最近的 PostGIS 版本中使用有效的希尔伯特曲线排序）：

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

或者，可以通过使用 GeoHash 作为（临时）索引并对该索引进行聚类来对数据进行适当排序：

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

在geometry 列上构建 BRIN 索引的语法为：

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geome_col] ); 

上述语法构建二维索引。若要生成三维索引，请使用以下语法：

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_3d);

您还可以使用 4D 运算符类获取 4D 维度索引：

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_4d);

在上面的命令中，范围内的块数使用默认值 128。 此语句用于指定聚合中某个区域中的块数

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ( [geome_col] ) WITH (pages_per_range = [number]); 

请记住，BRIN 索引仅存储大量行的一个索引条目。如果您的表存储具有混合维数的几何图形，则生成的索引的性能可能会很差。您可以通过选择存储几何图形维数最少的运算符类来避免这种性能损失

BRIN 索引支持geography数据类型。在geography列上构建 BRIN 索引的语法是：

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geog_col] ); 

上述语法为椭球体上的地理空间对象构建 2D 索引。

目前，仅提供“包容性支持”，这意味着只有&&、~和 @运算符可用于 2D 情况（对于几何和地理 ），而运算符 &&&只能用于 3D 几何图形。目前不支持 kNN 搜索。

BRIN 与其他索引类型的一个重要区别是数据库不会动态维护索引。对表中空间数据的更改只需附加到索引的末尾。这将导致索引搜索性能随着时间的推移而降低。 可以通过执行 VACUUM或使用特殊函数brin_summarize_new_values(regclass)来更新索引。 因此，BRIN 可能最适合用于只读或很少更改的数据。有关更多信息，请参阅手册。

总结一下对空间数据使用 BRIN 的情况：

SP-GiST代表“空间分区广义搜索树”，是多维数据类型索引的通用形式，支持分区搜索树，例如四叉树、k-d 树和基数树 (tries)。 这些数据结构的共同特征是它们将搜索空间重复划分为大小不必相等的分区。除了空间索引之外，SP-GiST 还用于加速多种数据的搜索，例如电话路由、ip 路由、子字符串搜索等。有关更多信息，请参阅PostgreSQL手册。

与 GiST 索引的情况一样，SP-GiST索引是有损的，因为它们存储包围空间对象的边界框。SP-GiST 索引可以被视为 GiST 索引的替代方案。

一旦 GIS 数据表超过几千行，就可以使用 SP-GiST 索引来加速数据的空间搜索。 在“geometry”列上构建 SP-GiST 索引的语法如下：

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

上面的语句构建了一个二维索引。 几何类型的三维索引是使用三维运算符类生成的，如下所示：

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

构建空间索引是一项计算密集型操作。它还会在创建表时阻止对表的写入访问，因此在生产系统上，您可能希望以较慢的并发感知方式执行操作：

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

建立索引后，让 PostgreSQL 不时收集表上的统计信息会很有帮助。它用于优化查询计划：

VACUUM ANALYZE [table_name] [(column_name)];

SP-GiST 索引可以加速涉及以下运算符的查询：

目前不支持 kNN 搜索。

通常，索引会无形中加速数据访问：一旦建立索引，PostgreSQL查询规划器就会自动决定何时使用它来提高查询性能。但在某些情况下，规划器不会选择使用现有索引，因此查询最终会使用缓慢的顺序扫描而不是空间索引。

如果发现空间索引未被使用， 您可以执行以下几项操作：

有关更多信息，请参阅 PostgreSQL 手册的查询规划部分。