http://www.blogjava.net/sinoly/archive/2007/09/25/148002.html
值此FOSS4G大会即将召开之日,最近我会在Blog上依次介绍一些OpenGIS标准、架构及用于实现的软件。一方面给初涉此行的朋友一个快速入门的概览,另一方面也是对我接触OpenGIS近一年来的总结。
OpenGIS定义了一组基于数据的服务,而数据的基础是要素(Feature)。所谓要素简单地说就是一个独立的对象,在地图中可能表现为一个多边形建筑物,在数据库中即一个独立的条目。要素具有两个必要的组成部分,几何信息和属性信息。OpenGIS将几何信息分为点、边缘、面和几何集合四种:其中我们熟悉的线(Linestring)属于边缘的一个子类,而多边形(Polygon)是面的一个子类。也就是说OpenGIS定义的几何类型并不仅仅是我们常见的点、线、多边形三种,它提供了更复杂更详细的定义,增强了未来的可扩展性。另外,几何类型的设计中采用了组合模式(Composite),将几何集合(GeometryCollection)也定义为一种几何类型,类似地,要素集合(FeatureCollection)也是一种要素。属性信息没有做太大的限制,可以在实际应用中结合具体的实现进行设置。
相同的几何类型、属性类型的组合成为要素类型(FeatureType),要素类型相同的要素可以被存放在一个数据源中。而一个数据源只能拥有一个要素类型。因此,可以用要素类型来描述一组属性相似的要素。在面向对象的模型中,完全可以把要素类型理解为一个类,而要素则是类的实例。
通过GIS中间件可以从数据源中取出数据,供WMS服务器和WFS服务器使用。
WMS服务器接收请求,根据请求内容的不同,可以返回不同格式的最终数据。例如,WMS可以返回常用图片格式的地图片段供最终用户阅读(类似Google Maps),其中地图是根据一个样式文件(SLD)生成的,它描述了地图的线划粗细,色彩等;WMS也可以返回GeoRSS和KML用来和其它地图服务互通。
WFS服务器也可以接收请求,但WFS将返回GML格式的地理信息数据。GML是一种基于XML的数据格式,它可以完整的再现数据,也是OpenGIS数据源的重要形式。也就是说,WFS返回的GML可以继续作为数据源。在WFS请求中,OpenGIS定义了一个Filter标准,用来实现对数据的筛选,使WFS更加灵活。另一方面,WFS还支持通过WFS-t提交客户端对数据的修改。通俗地说,WMS是“只读”的,而WFS则是可以读写的。
草草说完,发现自己的理解也十分有限,如有谬误,还望读者不吝指正。另外还有WCS方面不曾涉及,要获得更进一步的了解,请下载OpenGIS的标准进行阅读。
今天来说OpenGIS架构的软件、类库实现情况。OpenGIS是一个开放标准,不过它已经不仅仅在开源世界发挥作用,许多商业软件也支持了OpenGIS的标准。当然,这里所提到的软件全部都是开源软件。
几何基础类库
代表: JTS(Java), GEOS(C++), Shapely(Python)
这类几何基础类库主要实现的是OpenGIS的Simple Feature Access标准,简单地说他们就是对几何类型(Geometry)进行了一定程度的封装。以JTS为例,它按照OpenGIS对于Geometry的描述实现了基于Java的接口和继承关系,制作好了可以使用的类似Point、LineString这样的类。另外这些类库还普遍实现了OpenGIS的DE-9IM空间位置关系判断和一些常用的计算几何方法(如缓冲(buffer))。
此类软件是所有GIS类库的基础,正如几何是GIS的基础之一一样。
数据源实现
代表:PostGIS(PostgreSQL),MySQL Spatial
数据源的实现主要是开源数据库的空间扩展。数据库的空间扩展不仅仅在数据表中支持几何类型的存储,而且更提供了SQL级别的集合关系判断,例如,可以直接利用SQL查询在某个多边形内的点。
中间件
代表:GeoTools(Java)
中间件在系统中扮演连接数据和服务的角色。GeoTools承担了从各种数据源(如PostGIS,GML,Shapefile,WFS)读取数据并将数据标准化的工作。Feature接口就定义在GeoTools中,不同数据源的数据读出后被统一成包含一个Geometry成员(定义在JTS中)的Feature接口的实现。这样,进一步的操作只需面向Feature即可,省去了高层软件对于不同数据源的解读过程。另外,GeoTools还是OpenGIS标准的全面实现,其中包括Filter、坐标转换、GML。
WMS/WFS服务器
代表: GeoServer(Java),MapServer(PHP)
地图服务器扮演向网络中的客户端提供地图服务的角色。这类地图服务器可以接收统一规范的WMS和WFS请求(request),返回多种格式的数据。这个过程有WMS/WFS规范的严格规定,所以,对客户端来说其地图服务器的实现究竟是什么并不会造成太大影响。这样的规范,为公共的、联合的地图服务创造了可能。
客户端
代表:OpenLayers/MapBuilder(JavaScript),uDig(Java),QGIS(C++)
客户端分为浏览器和桌面客户端程序两种。以OpenLayers为代表的B/S系统客户端现在已经非常强大,它可以封装WMS请求,在浏览器上实现地图的切片载入功能。另外拖动、缩放都功能也非常完善,可以实现跨浏览器操作。最近的OpenLayers版本还支持了矢量编辑功能,可以通过WFS-t提交。而传统的桌面客户端程序功能则更加强大,支持多种包括WMS和WFS在内的数据源,另外编辑功能、操作性也要比浏览器中的强大。
Shapefile
ESRI的Shapefile格式是GIS矢量文件格式的事实标准,通常由.shp, .shx, .prj, .dbf等文件组成。OpenGIS的实现软件普遍支持Shapefile的读写。Shapefile在GeoServer中可以直接作为数据源,但是这种方式并不被推荐,原因很简单,基于文件的数据源可能造成性能不佳和数据丢失。
GML
GML是OpenGIS的标准规范之一,它基于xml描述地理数据。于Shapefile相比,xml更容易读写,易于在网络中以各种形式传播。同时,xml还具有可读性,人可以理解和辨识。GeoTools实现了GMLDataStore,因此在GeoServer中GML也可以直接作为数据源(需要下载GML扩展)。同时,GML的数据源为数据源动态化提供了实现的思路和可能性。
PostGIS
PostGIS是加拿大Refractions公司支持的开源项目,它为开源数据库PostgreSQL提供了空间支持。PostGIS安装后,PostgreSQL中出现一个模版数据库,新建空间数据库时只需以PostGIS为模版即可。PostGIS在SQL级别上实现了基本的空间运算功能。另外绝大多数开源GIS软件(即使是不严格遵守OpenGIS标准的)都支持PostGIS数据表的直接载入,读写等功能。毋庸置疑,PostGIS是OpenGIS数据源最佳实现。
MySQL Spatial
MySQL是开源数据库的大鳄,从MySQL4.0开始加入了Spatial扩展功能,实现了OpenGIS规定的几何数据类型,在SQL中的简单空间运算。但是从4.0之后到现在,MySQL的Spatial部分一直没有继续的更新和增强。加上早先MySQL在SQL上对空间运算支持的不完善(只支持基于最小外接矩形的关系判断),所以MySQL是开源数据源中一个不太让人满意的选择。不过由于MySQL在小型项目上的广泛引用,在一些情况下也是可以以MySQL为数据源的。
db4o?: 对象数据库作为数据源的可能性
OpenGIS的系统架构完全是基于一个面向对象的模型的,而传统的关系数据库、Shapefile文件是现在应用的主流。在地理描述的过程中,关系数据库的特性并没有被完全发挥,而为此还需要有中间件做ORM的工作。试想直接将FeatureType和Features以对象形式存入对象数据库,整个系统至少在理论上可以减少一层。不过,以对象数据库作为数据源,还需要对象数据库的性能进一步提升。而之后的和已有软件的对接应该不成问题,因为db4o可以直接存储Feature对象和Geometry对象。
但是因此产生的数据对实现的依赖性又是一个问题:数据和实现紧密耦合,数据中捆绑了代码,虽然db4o号称支持Java和.NET的的互操作,但是对于其它实现来说又成了问题。从这个角度来说,对象数据库作为数据源是一种倒退。
为什么没有KML?
KML作为一种新的标准(没有在意最后是否通过),它的作用主要是网络中地理信息的传输。KML是一种面向客户端设计的数据形式,这是它不能取代GML地位的原因,同时也是它在GoogleEarth和很多地图应用上远强于GML的原因。对照一下KML和GML的形式就很容易理解,GML将属性数据存储为Element,而KML则是以超文本的形式存储属性数据,前者便于数据读取,后者便于客户端表现。于KML很类似的就是GeoRSS,效果是相似的。