第 4 章 数据管理

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

几何是一种抽象类型。几何值属于其具体子类型之一，表示各种类型和尺寸的几何形状。这些包括原子类型点、线、线环和多边形，以及集合类型多点、多线、多边形和几何集合。简单要素访问 - 第 1 部分：通用架构 v1.2.1为多面体、三角形和TIN结构添加了子类型。

几何在二维笛卡尔平面上建模形状。多面体、三角形和 TIN 类型还可以在三维空间中表示形状。形状的大小和位置由其坐标指定。每个坐标都有一个 X 和 Y 纵坐标值，用于确定其在平面中的位置。形状由点或线段构成，点由单个坐标指定，线段由两个坐标指定。

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

几何值与空间参考系统相关联，该系统指示其嵌入其中的坐标系。空间参考系统由几何 SRID 号码标识。X 和 Y 轴的单位由空间参考系统确定。在平面参考系中，X 和 Y 坐标通常表示东向和北向，而在大地系中，它们表示经度和纬度。SRID 0 表示一个无限的笛卡尔平面，其轴上未分配任何单位。请参阅第 4.5 节，“空间参考系统”。

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

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

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

几何模型允许评估拓扑空间关系，如第 5.1.1 节“维度扩展的 9 交集模型”中所述。为了支持这一点，为每种几何类型定义了内部、边界和外部的概念。几何在拓扑上是封闭的，因此它们始终包含其边界。边界是一个维度比几何本身低 1 的几何。

OGC 几何模型为每种几何类型定义了有效性规则。这些规则确保几何值表示现实情况（例如，可以指定一个孔洞位于壳体外部的多边形，但这在几何上没有意义，因此无效）。PostGIS 还允许存储和操作无效几何值。这允许在需要时检测并修复它们。请参阅第 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 类型支持 3DM、3DZ 和 4D 坐标。

	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 用作记录格式（例如，在 DUMP 文件中）。

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

例如，此语句通过从 EWKT 文本值强制转换来创建几何，并使用 HEXEWKB 的规范形式输出它

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

您可以使用带有 geography 类型列的 CREATE TABLE SQL 语句创建用于存储地理数据的表。以下示例创建了一个地理列的表，该列在 WGS84 大地坐标系（SRID 4326）中存储 2D 线串

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

地理数据类型允许您以经度/纬度坐标存储数据，但代价是：在 GEOGRAPHY 上定义的函数比 GEOMETRY 上的函数少；定义的那些函数执行起来需要更多 CPU 时间。

您选择的的数据类型应由您正在构建的应用程序的预期工作区域决定。您的数据将跨越全球或大洲区域，还是仅限于州、县或市级？

请参阅 第 12.11 节，“PostGIS 函数支持矩阵” 以比较地理与几何支持的内容。有关地理函数的简要列表和说明，请参阅 第 12.4 节，“PostGIS 地理支持函数”

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

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

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

LINESTRING 如果不经过同一点两次（端点除外），则为 简单 的。如果简单 LineString 的端点相同，则称其为 闭合，并称为线形环。

(a) 和 (c) 是简单的 LINESTRING。 (b) 和 (d) 不是简单的。 (c) 是一个闭合线形环。

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

一个 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 使多点和线形几何变得简单。

几何有效性主要适用于 2 维几何（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 是空间函数的一个案例，允许 无效输入！）

默认情况下，PostGIS 在加载几何时不会检查有效性，因为对于复杂几何，有效性测试可能需要大量 CPU 时间。如果您不信任您的数据源，可以通过添加检查约束在表上强制执行有效性检查

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 使用以下策略

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

用于查找核心集中未定义的空间参考系统的资源是 http://spatialreference.org/

一些常用的空间参考系统包括：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 和 US 中心 Lambert 等角投影的 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'
);

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

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

geometry 类型支持两个可选的 类型修饰符

创建带有几何列的表的示例

表中可以有多个几何列。可以在创建表时指定这一点，也可以使用 ALTER TABLE SQL 语句添加列。此示例添加了一个可以容纳 3D 线串的列

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

OGC SQL 的简单要素规范 定义了 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 视图和批量插入。对于批量插入情况，可以通过约束列或执行 ALTER TABLE 来更正 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);

-- If you are using PostGIS 2.0 and for whatever reason, you
-- you need 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;

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

                                  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 的 geom 视图列注册正确，但基于约束的列注册不正确。

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

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

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

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

如果空间数据可以转换为文本表示（作为 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;

可以使用 psql 将 SQL 文件加载到 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((...))');

最常见的空间查询可能是“基于框架”的查询，客户端软件（如数据浏览器和 Web 制图工具）使用该查询来获取“地图框架”的数据以供显示。

使用“&&”运算符时，您可以指定 BOX3D 作为比较要素或 GEOMETRY。但是，当您指定 GEOMETRY 时，其边界框将用于比较。

使用“BOX3D”对象作为框架，此类查询看起来像这样

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

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

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

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

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

命令行选项为

GiST 代表“广义搜索树”，是一种用于多维数据的通用索引形式。PostGIS 使用在 GiST 之上实现的 R 树索引来索引空间数据。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);

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

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

在构建索引后，有时强制 PostgreSQL 收集表统计信息（用于优化查询计划）会有所帮助

VACUUM ANALYZE [table_name] [(column_name)];

BRIN 代表“块范围索引”。它是一种在 PostgreSQL 9.5 中引入的通用索引方法。BRIN 是一种有损索引方法，这意味着需要进行二次检查以确认记录与给定的搜索条件匹配（所有提供的空间索引都是这种情况）。它提供了更快的索引创建和更小的索引大小，并具有合理的读取性能。其主要目的是支持在与表内物理位置具有相关性的列上对非常大的表进行索引。除了空间索引之外，BRIN 还可以加速对各种类型的属性数据结构（整数、数组等）的搜索。有关更多信息，请参阅PostgreSQL 手册。

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

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

构建 BRIN 索引的 CPU 密集程度远低于构建 GiST 索引。通常会发现，构建 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] ); 

以上语法构建一个 2D 索引。要构建一个 3D 维度索引，请使用此语法

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 情况（对于 &&、~ 和 @ 运算符）仅可以使用 geometry 和 geography，而对于 3D 几何仅可以使用 &&& 运算符。目前不支持 kNN 搜索。

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

总结使用 BRIN 处理空间数据

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

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

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

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

上述语法将构建一个 2 维索引。可以使用 3D 运算符类为几何类型创建 3 维索引

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

构建空间索引是一个计算密集型操作。它还会在创建期间阻止对表的写访问，因此在生产系统上，您可能希望以较慢的 CONCURRENTLY 兼容方式进行

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

在构建索引后，有时强制 PostgreSQL 收集表统计信息（用于优化查询计划）会有所帮助

VACUUM ANALYZE [table_name] [(column_name)];

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

目前不支持 kNN 搜索。

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

如果您发现您的空间索引没有被使用，您可以采取一些措施

有关详细信息，请参阅 Postgres 手册中的 查询规划 部分。