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比较方便，较易实现数据共享与互操作。其缺点主要表现为，实现难度大，压缩数据比较困难，目前的功能和性能与第一类系统尚存在差距。

目前开源空间信息软体领域性能最优秀的资料库软体当属PostgreSQL资料库，而构建在其上的空间对象扩展模组PostGIS则使得其成为一个真正的大型空间资料库。PostGIS在对象关係型资料库PostgreSQL上增加了存储管理空间数据的能力，相当于Oracle的spatial部分。PostGIS最大的特点是符合併且实现了OpenGIS的一些规範，是最着名的开源GIS资料库。

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是对象关係型资料库系统PostgreSQL的一个扩展，PostGIS提供如下空间信息服务功能:空间对象、空间索引、空间操作函式和空间操作符。同时，PostGIS遵循OpenGIS的规範。

PostGIS的着作权被纳入到GNU的GPL中，也就是说任何人可以自由得到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中支持的空间数据对象类型包括:点、线、多边形、几何对象类型，以及多点、多线、多多边形的几何对象类型。

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支持所有的空间数据类型，这些类型包括:点（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运算就会形成一个新的多边形，这个新的多边形的边界为两个多边形中最大边界。

资料库中的几何类型可以通过Transform函式从一种投影系变换到另一种投影系中。在OpenGIS中的几何类型都将SRID作为自身结构的一部分，但不知什幺原因，在OpenGIS的SFSQL规範中，并没有引入Transform。

存储在普通地理坐标系中的集合类型如果不进行坐标变换是无法进行程度运算的，OpenGIS所提供的坐标变换使得积累类型的程度计算变成可能。

SFSQL规範只是针对二维集合类型。OpenGIS提供了对三维集合类型的支持，具体是利用输入的集合类型维数来决定输出的表现方式。例如，即便所有几何对象内部都以三维形式存储，纯粹的二维交叉点通常还是以二维的形式返回。此外，还提供几何对象在不同维度间转换的功能。

在资料库中，聚集函式是一个执行某一属性列所有数据操作的函式。比如Sum和Average，Sum是求某一关係属性列的数据总和，Average则是求取某一关係属性列的数据平均值。与此对应，空间聚集函式也是执行相同的操作，不过操作的对象是空间数据。例如聚集函式Extent返回一系列要素中的最大的包裹矩形框，如“SELECT EXTENT(GEOM) FROM ROADS”这条SQL语句的执行结果是返回ROADS这个数据表中所有的包裹矩形框。

PostGIS通过一种新的数据类型片，提供对于大的栅格数据对象的存储。片由以下几个部分组成:包裹矩形框、SRID、类型和一个位元组序列。通过将片的大小控制在资料库页值（32×32）以下，使得快速的随即访问变成可能。一般大的图片也是通过将其切成32×32像素的片然后再存储在资料库中的。

目前，由于“关係型资料库+空间数据引擎”的技术方案访问迅速、与GIS联繫紧密的优点，在套用中占有一定的优势，但空间数据引擎独立于资料库核心，难以充分利用关係型资料库中各种成熟的数据管理、访问技术，成为进一步发展的致命弱点。另外，难以支持扩展SQL，不易实现数据共享与互操作等问题也逐渐暴露出来。

儘管面向对象空间资料库管理系统最适应于空间数据的表达和管理,不仅支持变长记录,而且支持对象的嵌套、信息的继承与聚集。有关面向对象资料库管理系统的研究已有十多年了，由于缺乏良好的数据基础，在访问速度尚未有重大突破，难以发展成熟，据估计在较长一段时间内面向对象资料库管理系统都不会替代对象关係型资料库管理系统。

扩展对象关係型资料库管理系统无疑将成为以后的发展方向。儘管目前PostGIS/PostgreSQL和Spatial Oracle的性能与ArcSDE仍有一定的差距，但是随着资料库厂商对空间数据管理市场的不断重视、结构化数据管理方式与空间数据管理方式的进一步融合、数据压缩传输技术的不断提高，基于资料库管理系统的空间扩展方式将会不断的完善，成为今后管理空间数据的主流技术。而多数GIS厂商则应将精力集中到空间分析、空间模型等方面，从而形成较好的社会分工结构。

目前，软体开源已经成为IT界的一种发展趋势，越来越多的软体加入到开源系统中。PostGIS不论在功能还是扩展性方面都不落后于商业GIS平台的空间资料库，而且由于其原始码的公开性，更加容易吸引广大爱好者参与到PostGIS的开发中，不断完善现有的功能同时进一步扩展新的特性，相信PostGIS的发展前景将会非常美好。