PostGis
postgis
PostgreSQL 是一种对象-关系型数据库管理系统（ORDBMS），也是目前功能最强大、特性最丰富和最复杂的自由软件数据库系统。它起源于伯克利（BSD）的数据库研究计划，目前是最重要的开源数据库产品开发项目之一，
有着非常广泛的用户。PostGIS在对象关系型数据库PostgreSQL上增加了存储管理空间数据的能力，相当于Oracle的spatial部分。PostGIS最大的特点是符合并且实现了OpenGIS的一些规范，是最著名的开源GIS数据库。
有着非常广泛的用户。PostGIS在对象关系型数据库PostgreSQL上增加了存储管理空间数据的能力，相当于Oracle的spatial部分。PostGIS最大的特点是符合并且实现了OpenGIS的一些规范，是最著名的开源GIS数据库。
1986年，加州大学伯克利分校的Michael Stonebraker教授领导了Postgres的项目，它是PostgreSQL的前身。随后出现了PostGIS，PostGIS是对象－关系型数据库系统PostgreSQL的一个扩展，它的出现让人们开始重视基于数据库管理系统的空间扩展方式，而且使PostGIS有望成为今后管理空间数据的主流技术。
为了提高数据库管理系统（DBMS）对空间数据的管理能力，国内外先后出现过:文件与关系数据库混合管理系统、全关系型空间数据库管理系统、关系型数据库+空间数据引擎、扩展对象关系型数据库管理系统，以及面向对象空间数据库管理系统等多种解决方案。目前，国内外较为流行的主要集中在“关系型数据库+空间数据引擎”、“扩展对象关系型数据库”两方面。
“关系型数据库+空间数据引擎”通常是近年来由GIS厂商研发的一种中间件解决方案。用户将自己的空间数据交给独立于数据库之外的空间数据引擎，有空间数据引擎来组织空间数据在关系型数据库中的存储;当用户需要访问数据的时候，再通知空间数据引擎，有引擎从关系型数据库中取出数据，并转化为客户可以使用的方式。
因此，关系型数据库仅仅是存放空间数据的容器，而空间数据引擎则是空间数据进出该容器的转换通道。这类系统的典型代表有ESRI的ArcSDE和MapInfo的SpatialWare。其优点是，访问速度快，支持通用的关系数据库管理系统，空间数据按BLOB存取，可跨数据库平台，与特定GIS平台结合紧密，应用灵活。其缺点主要表现为，空间操作和处理无法在数据库内核中实现，数据模型较为复杂，扩展SQL比较困难，不易实现数据共享与互操作。
此系统支持抽象的数据类型（ADT）及其相关操作的定义;用户利用这种能力可以增加空间数据类型及相关函数，从而将空间数据类型与函数就从中间件（空间数据引擎）转移到了数据库管理系统中，客户也不必采用空间数据引擎的专用接口进行编程，而是使用增加了的空间数据类型和函数的标准扩展型SQL语言来操作空间数据。
这类支持空间扩展的产品有Oracle的Oracle Spatial, IBM的DB2 Spatial Extender, Informix 的Spatial DataBlade。其优点是，空间数据的管理与通用数据库系统融为一体，空间数据按对象存取，可在数据库内核中实现空间操作和处理，扩展SQL比较方便，较易实现数据共享与互操作。其缺点主要表现为，实现难度大，压缩数据比较困难，目前的功能和性能与第一类系统尚存在差距。
缘起PostgrSQL
1986年，加州大学伯克利分校的Michael Stonebraker教授领导了Postgres的项目，它是PostgreSQL的前身。这个项目的成果非常显著，在现代数据库的许多方面都作出了大量的贡献，如在面向对象的数据库、部分索引技术、规则、过程和数据库扩展方面都取得了显著的成果。同时，Stonebraker将PostgreSQL纳入到BSD版权体系中，使得PostgreSQL在各种科研机构和一些公共服务组织得到了广泛的应用。
在PostgreSQL中已经定义了一些基本的集合实体类型，这些类型包括:点（POINT）、线（LINE）、线段（LSEG）、方形（BOX）、多边形（POLYGON）和圆（CIRCLE）等;另外，PostgreSQL定义了一系列的函数和操作符来实现几何类型的操作和运算;同时，PostgreSQL引入空间数据索引R-tree。
尽管在PostgreSQL提供了上述几项支持空间数据的特性，但其提供的空间特性很难达到GIS的要求，主要表现在:缺乏复杂的空间类型;没有提供空间分析;没有提供投影变换功能。为了使得PostgreSQL更好的提供空间信息服务，PostGIS应运而生。
PostGIS简介
PostGIS是对象关系型数据库系统PostgreSQL的一个扩展，PostGIS提供如下空间信息服务功能:空间对象、空间索引、空间操作函数和空间操作符。同时，PostGIS遵循OpenGIS的规范。
PostGIS的版权被纳入到GNU的GPL中，也就是说任何人可以自由得到PostGIS的源码并对其做研究和改进。正是由于这一点，PostGIS得到了迅速的发展，越来越多的爱好者和研究机构参与到PostGIS的应用开发和完善当中。
PostGIS发展历程
PostGIS是由Refractions Research Inc开发的，Refractions是一家GIS和数据库咨询公司，Refraction公司最初是在PostgreSQL的基础上研究空间数据库的实现，由于PostgreSQL所提供的空间数据类型和功能远远不能满足GIS的需求，研究工作经常陷入到进退维谷的境地，最终的结果往往是耗费了大量的人力物力，而产品却极其复杂并且性能低下。这些原因直接或间接促成PostGIS项目的实施。
PostGIS的实施也不是一帆风顺，直到PostgreSQL 7.1发布之后，PostGIS的实现才变为可能，主要原因是7.1版本之前PostgreSQL支持的记录大小最大为8Kb，从7.1之后，PostgreSQL将这一限制摈弃。即使采用二进制方式存储，空间数据对象也往往会经常超过8Kb，如果这个限制存在的话，空间数据的存储就无从谈起。
伴随着这一限制的消除，PostGIS的研究和开发也随即在2001年的4月展开，并于2001年的5月发布了PostGIS的第一版（PostGIS V0.1）。在PostGIS的第一版中，主要包括空间数据库、采用标准表示方式的空间数据对象、支持快速查询的空间索引和一些简单的分析函数（如area和length等）。PostGIS
V0.1中支持的空间数据对象类型包括:点、线、多边形、几何对象类型，以及多点、多线、多多边形的几何对象类型。
V0.1中支持的空间数据对象类型包括:点、线、多边形、几何对象类型，以及多点、多线、多多边形的几何对象类型。
2001年5月发布的PostGIS V0.2增加了对于Windows平台下二进制表示的支持，同时为新用户提供帮助文档。不过，用户反馈PostGIS的函数命名没有遵循OpenGIS规范。
2001年7月PostGIS V0.5发布，PostGIS增加了OpenGIS现有的所有功能性函数并在函数的命名上与其保持一致。增加了24个OpenGIS存取函数，同时删除了与这些函数功能等价的不标准的原有函数。
伴随着来自不列颠哥伦比亚省政府的资金支持，对于在球体表面的长度运算支持也加入到0.5版中。同期，Refractions公司将British Columbia省的数字道路地图集移植到PostGIS中，同时使用数据库的模式和数据转换功能为地图集客户提供支持（急救车派遣、紧急事物响应，以及其他市政事物等）。
PostGIS V0.5之所以重要，还有一个原因就是Minnesota大学的Mapserver的发布。Minnesota大学的Mapserver是一个开源的互联网地图发布引擎，就像ESRI公司的ArcIMS系统，Mapserver同时增加了对于PostGIS的支持。
在Mapserver中，提供了一个Web驱动的接口，这个接口用于检查数据库中数据的空间特征。在PostGIS中，PostGIS为了使得Mapserver能够更好的提供服务，提供了一个易于读写的数据源，这个数据源将会在网络事务繁忙的时候发挥其效用。比如，如果用标准的GIS文件作为数据源，如果有两个用户并发的对同一文件进行写入操作，这样将会不可避免的导致操作冲突，而利用PostGIS就能够很好的解决这个缺陷，同时确保数据的完整性。
2001年9月，PostGIS V0.6发布，PostGIS V0.6提供了完整的OpenGIS支持，加入了标准的元数据表，并且提供了对于空间参照系统标识的支持。另外还加入了OpenGIS支持的12个功能函数，同时对于Mapserver的支持得到了进一步的增强。
2002年2月，PostgreSQL V7.2发布，在7.2版中，GIST索引的API函数作了一点改进。由于这些API函数同样应用于PostGIS中，这给PostGIS V0.6的应用带来了麻烦，促使PostGIS必须作出改进适应PostgreSQL的变化。2002年PostGIS V0.7发布，在0.7版中，提供了新的对于GIST的API函数支持，同时在这一版中，提供了对于坐标变换的支持。
从2002年到现在，PostGIS又陆续发布了一系列的新版本，这些PostGIS产品在继承PostGIS产品原有优点的同时，又针对PostGIS本身存在的问题和不足进行了进一步的改进。到现在为止，PostGIS的最新版本是PostGIS V1.1.4。PostGIS V1.1.4主要改进的地方包括:⑴提供了对于将要发布的PostgreSQL V8.2的支持；⑵修复了函数collect中存在的bug；⑶在MakeBox2d和MakeBox3d中增加了对SRID的匹配检查；⑷提高了pgsql2shp的运行并发性；⑸进一步改进了对于Java的支持。
PostGIS特性
PostGIS支持所有的空间数据类型，这些类型包括:点（POINT）、线（LINESTRING）、多边形（POLYGON）、多点（MULTIPOINT）、多线（MULTILINESTRING）、多多边形（MULTIPOLYGON）和集合对象集（GEOMETRYCOLLECTION）等。PostGIS支持所有的对象表达方法，比如WKT和WKB。
PostGIS支持所有的数据存取和构造方法，如GeomFromText()、AsBinary()，以及GeometryN()等。
PostGIS提供简单的空间分析函数（如Area和Length）同时也提供其他一些具有复杂分析功能的函数，比如Distance。
PostGIS提供了对于元数据的支持，如GEOMETRY_COLUMNS和SPATIAL_REF_SYS，同时，PostGIS也提供了相应的支持函数，如AddGeometryColumn和DropGeometryColumn。
PostGIS提供了一系列的二元谓词（如Contains、Within、Overlaps和Touches）用于检测空间对象之间的空间关系，同时返回布尔值来表征对象之间符合这个关系。
PostGIS提供了空间操作符（如Union和Difference）用于空间数据操作。比如，Union操作符融合多边形之间的边界。两个交迭的多边形通过Union运算就会形成一个新的多边形，这个新的多边形的边界为两个多边形中最大边界。
PostGIS还提供以下功能:
数据库坐标变换
数据库中的几何类型可以通过Transform函数从一种投影系变换到另一种投影系中。在OpenGIS中的几何类型都将SRID作为自身结构的一部分，但不知什么原因，在OpenGIS的SFSQL规范中，并没有引入Transform。
球体长度运算
存储在普通地理坐标系中的集合类型如果不进行坐标变换是无法进行程度运算的，OpenGIS所提供的坐标变换使得积累类型的程度计算变成可能。
三维的几何类型
SFSQL规范只是针对二维集合类型。OpenGIS提供了对三维集合类型的支持，具体是利用输入的集合类型维数来决定输出的表现方式。例如，即便所有几何对象内部都以三维形式存储，纯粹的二维交叉点通常还是以二维的形式返回。此外，还提供几何对象在不同维度间转换的功能。
空间聚集函数
在数据库中，聚集函数是一个执行某一属性列所有数据操作的函数。比如Sum和Average，Sum是求某一关系属性列的数据总和，Average则是求取某一关系属性列的数据平均值。与此对应，空间聚集函数也是执行相同的操作，不过操作的对象是空间数据。例如聚集函数Extent返回一系列要素中的最大的包裹矩形框，如“SELECT
EXTENT(GEOM) FROM ROADS”这条SQL语句的执行结果是返回ROADS这个数据表中所有的包裹矩形框。
EXTENT(GEOM) FROM ROADS”这条SQL语句的执行结果是返回ROADS这个数据表中所有的包裹矩形框。
栅格数据类型
PostGIS通过一种新的数据类型片，提供对于大的栅格数据对象的存储。片由以下几个部分组成:包裹矩形框、SRID、类型和一个字节序列。通过将片的大小控制在数据库页值（32×32）以下，使得快速的随即访问变成可能。一般大的图片也是通过将其切成32×32像素的片然后再存储在数据库中的。
PostGIS发展展望
目前，由于“关系型数据库+空间数据引擎”的技术方案访问迅速、与GIS联系紧密的优点，在应用中占有一定的优势，但空间数据引擎独立于数据库内核，难以充分利用关系型数据库中各种成熟的数据管理、访问技术，成为进一步发展的致命弱点。另外，难以支持扩展SQL，不易实现数据共享与互操作等问题也逐渐暴露出来。
尽管面向对象空间数据库管理系统最适应于空间数据的表达和管理,不仅支持变长记录,而且支持对象的嵌套、信息的继承与聚集。有关面向对象数据库管理系统的研究已有十多年了，由于缺乏良好的数据基础，在访问速度尚未有重大突破，难以发展成熟，据估计在较长一段时间内面向对象数据库管理系统都不会替代对象关系型数据库管理系统。
扩展对象关系型数据库管理系统无疑将成为以后的发展方向。尽管目前PostGIS/PostgreSQL和Spatial Oracle的性能与ArcSDE仍有一定的差距，但是随着数据库厂商对空间数据管理市场的不断重视、结构化数据管理方式与空间数据管理方式的进一步融合、数据压缩传输技术的不断提高，基于数据库管理系统的空间扩展方式将会不断的完善，成为今后管理空间数据的主流技术。而多数GIS厂商则应将精力集中到空间分析、空间模型等方面，从而形成较好的社会分工结构。
转载自：https://blog.csdn.net/supernever/article/details/12950045
