PostGIS学习教程一：PostGIS介绍

一、什么是空间数据库

PostGIS是一个空间数据库，Oracle Spatial和SQL Server(2008和之后版本）也是空间数据库。

但是这意味着什么？是什么使普通数据库变成空间数据库？

简短的答案是…

空间数据库像存储和操作数据库中其他任何对象一样去存储和操作空间对象。

下面简短介绍了空间数据库的发展，然后回顾了将空间数据与数据库关联起来的三个要素：数据类型、索引和函数

空间数据类型用于指定图形为点（point）、线（line）和面（polygon）
多维度空间索引被用于进行空间操作的高效处理（注意是多维度哦，而不是只有针对二维空间数据的索引）
空间函数构建于SQL语言中，用于进行空间属性和空间关系的查询
空间数据类型、空间索引和空间函数组合在一起，提供了灵活的结构用于空间数据库的性能优化和分析。

文章目录

一、什么是空间数据库
- 1.1、开端
- 1.2、空间数据类型
- 1.3、空间索引和边界框（bounding box）
- 1.4、空间函数
- 二、PostGIS是什么？
- 2.1、什么是PostgreSQL呢？
- - 2.1.1、为什么选择PostgreSQL？
- 2.2、为什么不直接使用文件？
- 2.3、PostGIS简史
- 2.4、谁使用PostGIS？
- - 2.4.1、法国国家地理研究所
  - 2.4.2、RedFin
  - 2.4.3、GlobeXplorer
- 2.5、什么应用程序支持PostGIS？

1.1、开端

在传统的第一代地理信息系统（GIS）实现中，所有的空间数据都存储在平面文件（关于平面文件-flat files可以查看这个链接：flat file_百度百科）中，需要专门的GIS软件来解释和操作这些数据。这些第一代管理系统旨在满足用户的需求，其中所有所需的数据都在用户的组织领域中。它们是专为处理空间数据而构建的专有的、独立的系统，即应用程序和平面文件之间的耦合性非常高，平面文件里的空间数据没有数据独立性。

第二代空间系统将一些数据存储在关系数据库（RDBMS）中（通常是“属性”或非空间信息部分），但仍然缺乏直接集成所具有的灵活性，包含空间信息部分的数据仍然没有数据独立性。

真正的空间数据库诞生于人们开始把空间要素当作第一级数据库对象的时候。

空间数据库将空间数据和对象关系数据库（Object Relational database）完全集成在一起。实现从以GIS为中心向以数据库为中心的转变。

有了空间数据库之后，就不再需要专门的GIS数据引擎（GIS Data Engine）去处理和操纵空间数据了，应用程序只需要通过SQL语言就能轻松地操纵空间数据。

说明：空间数据库管理系统也可用于地理信息以外的应用。例如，空间数据库可以用于管理与人体解剖、大规模集成电路、分子结构和电磁场等相关的数据。

1.2、空间数据类型

普通数据库拥有字符串（string）、数值（number）和日期（date）这些数据类型，空间数据库添加了额外的数据类型（空间数据类型）以用于表达地理特征（geographic features）。

这些空间数据类型抽象并封装了诸如边界（boundary）和维度（dimension）等空间结构。

在许多方面，空间数据类型可以简单的理解为形状（shape）
空间数据类型按类型层次结构组织。每个子类型继承其父类型的结构（属性）和行为（方法或函数）。
在这里插入图片描述

1.3、空间索引和边界框（bounding box）

普通数据库提供索引机制以允许对数据子集进行快速、随机地访问。

标准的数据类型（number、string、date）的索引通常是B-tree索引（B树索引），B树索引使用自然排序顺序（natural sort order）对数据进行分区，以便将数据放入分层树中。

数字、字符串和日期的自然排序顺序很容易确定 —— 每个值都小于、大于或等于其他值。

但是由于多边形（Polygon）可以重叠，可以相互包含，并且可以排列在二维（或更多维数）空间中，因此无法使用B树索引有效地索引它们。

空间数据库提供了一个“空间索引（spatial index）”，它回答了“哪些对象在这个特定的边界框内？”这个问题。

边界框（bounding box）—— 或者称为包围盒BBOX，唉，随便了——是平行于坐标轴且包含给定地理要素（feature）的最小的矩形。

使用边界框是为了判断”A被包含在B中吗？"这个问题，对多边形进行计算，计算量非常大而且难以计算，但在计算矩形的情况下，计算比较容易，而且速度非常快。

即使是最复杂的多边形和线串（LineString)也可以用一个简单的边界框来表示。

索引必须快速执行才能起到理想的作用。因此，空间索引不像B树索引那样提供精确的结果，而是提供近似的结果。

"多边形内部包含哪些线段“将由空间索引解释为”这个多边形边界框内部包含哪些线段边界框？“

各种数据库实际实现的空间索引差异很大，最常见的实现是R-tree（在PostGIS中使用），但在其他空间数据库中也有基于四叉树（Quadtrees）的实现和基于网格的索引（grid-based indexes）的实现。

1.4、空间函数

关于查询的数据操作，普通数据库提供的函数功能包括连接字符串、对字符串执行哈希操作、对数值进行数学运算以及从日期中提取信息等。

空间数据库为分析几何信息、确定空间关系和操作几何图形提供了一套完整的空间函数。

空间函数中的大部分可以被归纳为以下五类：

转换 —— 在geometry（PostGIS中存储空间信息的格式）和外部数据格式之间进行转换的函数
管理 —— 管理关于空间表和PostGIS组织的信息的函数
检索 —— 检索几何图形的属性和空间信息测量的函数
比较 —— 比较两种几何图形的空间关系的函数
生成 —— 基于其他几何图形生成新图形的函数
函数列表可能非常长，OGC SFSQL定义了一组通用空间函数规范，PostGIS实现了这些规范（并另外实现了其他有用的空间函数）。

二、PostGIS是什么？

PostGIS通过向PostgreSQL添加对空间数据类型、空间索引和空间函数的支持，将PostgreSQL数据库管理系统转换为空间数据库。

因为PostGIS是建立在PostgreSQL之上的，所以PostGIS自动继承了重要的"企业级"特性以及开放源代码的标准。

可以说PostGIS仅仅只是PostgreSQL的一个插件，但是它将PostgreSQL变成了一个强大的空间数据库！

2.1、什么是PostgreSQL呢？

PostgreSQL是一个强大的对象关系数据库管理系统（ORDBMS）。

它是在BSD风格的许可下发布的，因此是自由和开放源代码的软件。

和许多其他开源程序一样，PostgreSQL不是由任何一家公司控制、运维的，而是有一个由众多开发人员和公司组成的全球社区来开发它。

PostgreSQL从一开始就考虑到类型扩展 —— 能够在运行时添加新的数据类型、函数和访问方法的机制。

正因为如此，PostGIS扩展可以由单独的开发团队开发，但仍然可以非常紧密地集成到PostgreSQL数据库中。

2.1.1、为什么选择PostgreSQL？

熟悉开源数据库的人提出的一个常见问题是：“为什么PostGIS不是基于MySQL构建的？”
PostgreSQL的特点：

被证明默认情况下强大的可靠性和事务完整性（ACID）
严谨地支持SQL标准（完整SQL92)
可插、拔的类型扩展和功能扩展
面向社区的发展模式（开源）
不限制列大小（"TOAST"机制-The Oversized-Attribute Storage Technique，超尺寸属性存储技术））以支持大型GIS对象
通用索引结构（Generic Index Structure - GIST）允许R-Tree索引
易于添加自定义功能、函数
这些因素结合在一起，PostgreSQL提供了一条非常简单的开发路径来添加新的空间类型。

在私有或商业软件世界中，只有Illustra（现在的 Infomix Universal Server）允许这么容易的扩展。这并不是巧合，Illustra是80年代以来对原始PostgreSQL代码库的私有改造。

因为将类型添加到PostgreSQL的开发路径非常简单，所以使用PostgreSQL是正确的。当MySQL在版本4.1中发布基本空间数据类型时，PostGIS团队查看了它们的代码，这坚定了最初使用PostgreSQL的决定。因为MySQL空间对象必须作为一种特殊情况被强行添加在字符串类型的顶部，所以MySQL代码分散在整个代码库中。

PostGIS 0.1的开发花费了不到一个月的时间，但做一个“MyGIS" 0.1可能需要更长的时间，可能永远也不会成功。

2.2、为什么不直接使用文件？

自GIS软件被首次开发以来，Shapefile（和其他文件格式诸如Esri File Geodatabase、GeoPackage）一直是空间数据存储和交互的标准数据格式。

但是，这些“平面文件”有以下缺点：

文件需要特殊的应用程序才能读写 —— SQL是对随机数据访问和分析的抽象。如果没有这种抽象，你将需要自己编写所有的访问和分析数据的代码（就是数据和应用程序耦合）
并发操作可能导致损坏数据 —— 虽然可以编写额外的代码以确保对同一文件的多次写入不会损坏数据，但当你解决了问题并同时解决了相关性能问题时，你已经编写了数据库系统的较好部分。那为什么不直接使用标准数据库呢？（数据库系统有事务管理器）
复杂的问题需要复杂的应用程序来应对 —— 复杂而有趣的空间分析问题（空间连接、聚合等）可以在数据库中使用一行SQL代码来表达，但是在对文件进行编程时，需要数百行专门的代码来解决。（空间数据库对底层进行了抽象、封装；另外SQL是非过程化语言）
大多数PostGIS用户都在建立多个应用程序访问数据的系统，因此，使用标准的SQL访问方法可以简化部署和开发。

有些用户正在处理大型数据集，如果使用文件存储，它们可能被分成多个文件；但在数据库中，它们可以存储在单个大的二维表中。

总之，对多个用户的支持、复杂的即时查询和对于大型数据集的高性能表现，是空间数据库比文件系统的优越之处。

2.3、PostGIS简史

2001年5月，Refractions Research 发布了第一版PostGIS。PostGIS 0.1具有空间对象、空间索引和一些空间函数。结果是PostGIS 0.1是一个适合存储和检索的数据库，但不适合分析。

随着空间函数数量的增加，相关标准化组织的必要性变得越发明显。开放地理空间联盟（OGC）的“Simple Features for SQL”（SFSQL）规范提供了函数命名和需求的指导性原则。

由于PostGIS对简单分析和空间连接的支持，Mapserver成为第一个提供数据库中数据可视化的外部应用程序。

在接下来的几年中，PostGIS函数的数量有所增加，但其功能仍然有限。许多有趣的函数（如ST_Intersects()、ST_Buffer()、ST_Union()）都很难编写，从头开始写这些函数需要多年时间。

幸运的是，第二个项目”Geometry Engine, Open Source“ （GEOS）出现了，GEOS库为实现SFSQL规范提供了必要的算法。通过结合GEOS，PostGIS在0.8版中提供了对SFSQL的完整支持。

随着PostGIS数据容量的增长，另一个问题浮出水面：用于存储几何图形的表示（元数据）被证明效率相对较低。对于像点和短线这样的小对象，表示中的元数据却占据了多达300%的开销。出于性能方面的考虑，有必要对元数据进行缩减。通过缩减元数据头和所需的维度，大大减少了开销。在PostGIS 1.0中，这种新的、更快的、轻量级的数据表示成为了默认的数据表示。

PostGIS的最新版本继续添加新功能和提高性能，并支持PostgreSQL核心系统中的新功能。