作者:网络 时间: 2020-10-16
**PostGIS**是一个空间数据库,Oracle Spatial和****SQL Server**(2008 和之后版本)也是空间数据库**。
但是这意味着什么?是什么使普通数据库变成空间数据库?
简短的答案是...
空间数据库像存储和操作数据库中其他任何对象一样去存储和操作空间对象。
下面简短介绍了空间数据库的发展,然后回顾了将空间数据与数据库关联起来的三个方面:数据类型、索引和****函数****
空间数据类型用于指定图形为点(point)、线(line)和面(polygon)
多维度空间索引被用于进行空间操作的高效处理
空间函数构建于 SQL 语言中,用于空间属性和空间关系的查询
空间数据类型、空间索引和空间函数组合在一起,提供了灵活的结构用于优化性能和分析。
在传统的第一代地理信息系统(GIS)实现中,所有的空间数据都存储在平面文件中,需要专门的 GIS 软件来解释和操作这些数据。
这些第一代管理系统旨在满足用户的需求,其中所有所需的数据都在用户的组织领域中。
它们是专为处理空间数据而构建的专有的、独立的系统。
第二代空间系统将一些数据存储在关系数据库(RDBMS)中(通常是“属性”或非空间部分),但仍然缺乏直接集成所具有的灵活性。
真正的空间数据库诞生于人们开始把空间特征当作第一级数据库对象的时候。
空间数据库将空间数据和对象关系数据库(Object Relational database)完全集成在一起。实现从以 GIS 为中心向以数据库为中心的转变。
空间数据存储的体系架构的发展
从上图可以看出,有了空间数据库之后,就不再需要专门的 GIS 数据引擎(GIS Data Engine)去处理和操纵空间数据了,应用程序只需要通过 SQL 语言就能轻松地操纵空间数据。
说明:空间数据库管理系统也可用于地理信息以外的应用。例如,空间数据库可以用于管理与人体解剖、大规模集成电路、分子结构和电磁场等相关的数据。
普通数据库拥有字符串(string)、数值(number)和日期(date)这些数据类型,空间数据库添加了额外的数据类型(空间数据类型)以用于表达地理特征(geographic features)。
这些空间数据类型抽象并封装了诸如边界(boundary)和维度(dimension)等空间结构。
在许多方面,空间数据类型可以简单的理解为形状(shape)
空间数据类型组织结构图
空间数据类型按类型层次结构组织。每个子类型继承其父类型的结构(属性)和行为(方法或函数)。
普通数据库提供索引机制以允许对数据子集进行快速、随机地访问。
标准的数据类型(number、string、date)的索引通常是B-tree索引(B 树索引),B 树索引使用自然排序顺序(natural sort order)对数据进行分区,以便将数据放入分层树中。
数字、字符串和日期的自然排序顺序很容易确定 —— 每个值都小于、大于或等于其他值。
但是由于多边形(Polygon)可以重叠,可以相互包含,并且可以排列在二维(或更多维数)空间中,因此无法使用B 树索引有效地索引它们。
空间数据库提供了一个“空间索引(spatial index)”,它回答了“哪些对象在这个特定的边界框内?”这个问题。
边界框(bounding box)是平行于坐标轴且包含给定地理要素(feature)的最小的矩形。
边界框示例
使用边界框是为了判断”A 被包含在 B 中吗?"这个问题,对多边形进行计算,计算量非常大而且难以计算,但在计算矩形的情况下,计算比较容易,而且速度非常快。
即使是最复杂的多边形和线串(LineString)也可以用一个简单的边界框来表示。
索引必须快速执行才能起到理想的作用。因此,空间索引不像B 树索引那样提供精确的结果,而是提供近似的结果。
"多边形内部包含哪些线段“将由空间索引解释为”这个多边形边界框内部包含哪些线段边界框?“
各种数据库实际实现的空间索引差异很大,最常见的实现是R-tree(在 PostGIS 中使用),但在其他空间数据库中也有基于四叉树(Quadtrees)的实现和基于网格的索引(grid-based indexes)的实现。
关于查询的数据操作,普通数据库提供的函数功能包括连接字符串、对字符串执行哈希操作、对数值进行数学运算以及从日期中提取信息等。
空间数据库为分析几何信息、确定空间关系和操作几何图形提供了一套完整的空间函数。
空间函数中的大部分可以被归纳为以下五类:
转换 —— 在 geometry(PostGIS 中存储空间信息的格式)和外部数据格式之间进行转换的函数
管理 —— 管理关于空间表和 PostGIS 组织的信息的函数
检索 —— 检索几何图形的属性和空间信息测量的函数
比较 —— 比较两种几何图形的空间关系的函数
生成 —— 基于其他几何图形生成新图形的函数
函数列表可能非常长,OGC SFSQL定义了一组通用空间函数规范,PostGIS 实现了这些规范(并另外实现了其他有用的空间函数)。
PostGIS 通过向 PostgreSQL 添加对空间数据类型、空间索引和空间函数的支持,将 PostgreSQL 数据库管理系统转换为空间数据库。
因为 PostGIS 是建立在 PostgreSQL 之上的,所以 PostGIS 自动继承了重要的"企业级"特性以及开放源代码的标准。
可以说 PostGIS 仅仅只是 PostgreSQL 的一个插件,但是它将 PostgreSQL 变成了一个强大的空间数据库!
PostgreSQL是一个强大的对象关系数据库管理系统(ORDBMS)。
它是在BSD 风格的许可下发布的,因此是自由和开放源代码的软件。
和许多其他开源程序一样,PostgreSQL 不是由任何一家公司控制、运维的,而是有一个由众多开发人员和公司组成的全球社区来开发它。
PostgreSQL 从一开始就考虑到类型扩展 —— 能够在运行时添加新的数据类型、函数和访问方法的机制。
正因为如此,PostGIS 扩展可以由单独的开发团队开发,但仍然可以非常紧密地集成到 PostgreSQL 数据库中。
2.1.1、为什么选择 PostgreSQL?
熟悉开源数据库的人提出的一个常见问题是:“为什么 PostGIS 不是基于 MySQL 构建的?”
转存失败重新上传取消
MySQL 和 PostgreSQL
PostgreSQL 的特点:
被证明的默认情况下的强大的可靠性和事务完整性(ACID)
严谨地支持SQL 标准(完整 SQL92)
可插、拔的类型扩展和功能扩展
面向社区的发展模式(开源)
不限制列大小(可用元组)以支持大型 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 可能需要更长的时间,可能永远也不会成功。
自 GIS 软件被首次编写以来,Shapefile(和其他文件格式)一直是空间数据的存储和交互的标准方式。
但是,这些平面文件有以下缺点:
文件需要特殊的应用程序才能读写 —— SQL 是对随机数据访问和分析的抽象。如果没有这种抽象,你将需要自己编写所有的访问和分析数据的代码
并发操作可能导致损坏数据 —— 虽然可以编写额外的代码以确保对同一文件的多次写入不会损坏数据,但当你解决了问题并同时解决了相关性能问题时,你已经编写了数据库系统的较好部分。那为什么不直接使用标准数据库呢?
复杂的问题需要复杂的应用程序来回答 —— 复杂而有趣的空间分析问题(空间连接、聚合等)可以在数据库中使用一行 SQL 代码来表达,但是在对文件进行编程时,需要数百行专门的代码来解决。
大多数 PostGIS 用户都在建立多个应用程序访问数据的系统,因此,使用标准的SQL 访问方法可以简化部署和开发。
有些用户正在处理大型数据集,如果使用文件存储,它们可能被分成多个文件;但在数据库中,它们可以存储在单个大的二维表中。
总之,对多个用户的支持,复杂的即时查询和对于大型数据集的高性能表现,是空间数据库比文件系统的优越之处。
2001 年 5 月,Refractions Research 发布了第一版 PostGIS。PostGIS 0.1 具有空间对象、空间索引和一些空间函数。结果是 PostGIS 0.1 是一个适合存储和检索的数据库,但不适合分析。
随着空间函数数量的增加,相关标准化组织的需求变得明确。开放地理空间联盟(OGC)的“Simple Features for SQL”(SFSQL)规范提供了函数命名和要求的指导性原则。
在接下来的几年中,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 最新的更新致力于提高对于标准的遵从性,增加了对 ISO SQL/MM标准中制定的基于曲线的几何图形和函数签名的支持。
因为继续注重性能,PostGIS 1.4 大大提高了几何图形测试例程的速度。
有关案例研究的完整列表,请参阅PostGIS 案例研究页面。 2.4.1、法国国家地理研究所
法国国家地理研究所(Institut Geographique National, France —— IGN)是法国的国家制图机构,利用 PostGIS 存储该国的高分辨率地形图“**BDUni**"。
“BDUni"有 1 亿多个地理要素,由 100 多名专业工作人员维护,他们每天核实观察的结果并向数据库添加新的地图。
IGN 安装使用数据库事务系统来确保更新过程中的一致性,并使用热备用系统(warm standby system)在系统故障时保持正常运行。
2.4.2、GlobeXplorer
GlobeXplorer是一家基于 Web 提供全球卫星和航空图像千兆字节在线访问的服务商。
GlobeXplorer 使用 PostGIS 管理与图像目录相关的元数据,因此,图像查询首先搜索 PostGIS 目录以查找相关图像的位置,然后从存储中提取图像并将其返回给客户端。
在构建他们的系统时,GlobeXplorer 尝试了其他的空间数据库,但是由于 PostGIS 所提供的价格和性能的巨大优势,最终选择了 PostGIS。
PostGIS 已经成为了一个广泛使用的空间数据库,支持使用它存储和检索数据的第三方程序的数量也在增加。
支持 PostGIS 的程序包括服务器端和桌面端的开源软件和闭源软件。
下表列出了一些使用或支持 PostGIS 的软件: