摘　要:提出了符合OpenGIS 规范的二维地理信息系统组件软件MapManager 的设计思想,介绍了MapManager
的设计过程,并对其不足和进一步研究方向进行了讨论。
关键词:OpenGIS; COMPDCOM; 空间数据库; 空间数据模型; 空间查询语言; 结构化存储; 空间存取方法
中图法分类号:P208 ; TP311. 12
　　自从20 世纪60 年代以来,GIS 软件及其应用
取得了巨大的发展。然而,由于空间数据及空间
实体间相互关系的复杂性以及GIS 设计思想和体
系结构上的局限性,使得早期的GIS 软件一直在
一个相对封闭的环境中发展,与IT 主流技术相距
甚远(方裕等,2001a) 。目前,面向对象软件方法
的成熟,使得面向对象的软件开发工具逐渐普及,
其中最突出的是组件技术。
MapManager 是使用微软基础类库开发的一个
符合OpenGIS 的OLEPCOM 简单要素实现规范
(OGC , 1999a ) 的小型二维矢量GIS 组件。
MapManager 旨在为与空间数据有关的各种行业应
用提供一个具有标准接口的GIS 组件。本文以
MapManager 的设计与开发作为实例,对GIS 组件
设计中的若干问题进行探讨。
1 　组件接口设计
基于组件开发的两个重要规范分别是
Microsoft 的COMPDCOM 和对象管理集团的
CORBA。目前,COMPDCOM 占市场领导地位,并
逐渐成为业界事实上的标准。基于COMPDCOM,
Microsoft 推出了ActiveX 技术。ActiveX 控件是当
今可视化程序设计中应用最为广泛的标准组件,
它由若干个OLE 自动化对象组成,在设计时有必
要对这些对象按照其实现的功能进行逻辑分类。
作为在COM 规范下实现的ActiveX 控件,
MapManager 包含了1 个控件对象和33 个OLE 自
动化对象,这些对象按照功能分为几何、数据访
问、地图显示、符号、空间参照系、空间分析等6 大
类。各类对象及其功能如表1 所示。MapManager
中各类接口(属性、方法和事件) 的总数目是627。
以几何对象类为例,不仅实现了OGC 定义的核心
接口, 包括IGeometry、IPoint 、ICurve 、ILineString、
ISurface、IPolygon、ISpatialRelation、ISpatialOperator 等
(OGC ,1999a) ,而且实现了为丰富软件的功能而自
定义的若干接口。

此主题相关图片如下：

2 　软件内核设计
在组件软件的设计过程中,除了要符合组件
设计规范,向外部提供标准的接口之外,更重要的
是软件内核的设计。对于矢量GIS 软件来说,其
内核设计指的是矢量空间数据库的设计。
2. 1 　空间数据模型
空间数据模型由空间数据结构、数据操作和
完整性约束三部分构成(王家耀,2001) 。在此主
要讨论数据结构部分,也称为空间数据库的存储
模型,指的是空间数据库中的空间数据和非空间
数据如何在物理内存中进行组织,并如何在外存
设备上持久存储。空间数据库的存储模型包含了
两个方面的内容:内存结构和外存结构。
MapManager 采用对象关系模型。大部分商业
关系数据库都提供长字段作为存储几何数据结构
的简单容器,关系中的某个长字段具有可变的长
度。几何数据以一种只有应用程序才能够解释的
方式存储在这个长字段中,数据库系统自身通常
无法解释这些几何数据,因此无法对这个长字段
进行标准的SQL 查询。为了在一个较高的层次
上以紧凑的、可重用的方式表达地理概念,最有效
的方法就是使空间数据类型标准化。在面向对象
模型的基础上提出的抽象数据类型是一种非常稳
健的解决方式。这种方法的基本思想是将数据类
型对象的实现部分封装起来,用户只能通过一套
定义明确的算子与数据类型对象的实例进行通
讯。数据类型及其算子的实现部分对所有外部用
户是隐藏的,外部用户无法检查或修改对象的内
部属性。面向对象的概念很适合于实现抽象空间
数据类型和算子(Egenhofer 等,1999) 。OpenGIS 的
OLEPCOM简单要素实现规范对几何对象的类层
次结构有一个详细的说明(见图1) ,MapManager
中所有抽象空间数据类型的定义完全符合这一规
范。
图1 　几何对象的类层次结构
Fig. 1 　Class Hierarchy of Geometry Objects
在MapManager 中, 所有几何对象都从类
CGeometry 派生而来, CGeometry 是一个实现了
IGeometry、ISpatialRelation、ISpatialRelation2 和
ISpatialOperator 接口的不可实例化的抽象类。
空间数据库的外存结构指的是内存中的空间
对象如何在二级存储设备上持久存储。用商业数
据库系统存储空间数据是今后的发展趋势,但是
对于小型GIS 软件来说,采用访问速度更快的文
件系统似乎更合适。不过,如果将所有的信息都
存储在单一文件内,会使文件结构变得异常复杂,
空间索引难以维护;而若将不同种类的信息分别
存储在多个文件中,则多个数据文件之间的关联
性容易遭到系统外部误操作的破坏。因此,若直
接在操作系统文件的级别上进行持久存储,存在
着两难的选择。
幸运的是,COMPDCOM 提供的结构化存储技
术为空间数据库的外存储模型提供了一个很好的

此主题相关图片如下：

方案。结构化存储可以看作是文件中的文件系
统,在单个文件中提供了类似目录、子目录和文件
的存储结构。结构化存储中的Storage 相当于磁
盘系统中的目录,Stream 则对应于文件( Eddon 和
Eddon , 2000) 。采用结构化存储的MapManager 外
存储体系结构如图2 所示。
2. 2 　空间查询语言
在设计空间数据库时,必须考虑的另外一个
重要问题是空间查询语言。
像其他软件一样,MapManager 也通过对标准
SQL 语言进行扩展的方式来提供空间查询语言,
进而实现空间查询功能。实现空间查询语言的关
键是对空间关系谓词进行准确而完整的定义
(OGC , 1999b) 。OGC 规范在基于维数扩展的92交
模型(DE29IM) 的基础上定义了5 种基本的空间关
系谓词, 它们分别是相离( disjoint ) 、相接
(touches) 、穿越( crosses) 、包含于(within) 、重叠
(overlaps) 。此外,为了应用上的方便,还定义了
其他两种空间关系谓词:
ò 包含(contains) : a. contains ( b) Z ! b. within
( a)
ò 相交( intersects) : a. intersects ( b ) Z ! a.
disjoint ( b)
对于尚未命名的其他空间关系,可用一个通
用的谓词Relate 表示: a. Relate ( b ,
intersectionPatternMatrix) 意味着a 与b 之间符合
intersectionPatternMatrix 所定义的92交矩阵模式关
系。
MapManager 按照OGC 的规范对空间关系进
行定义,方便地实现了基本的空间查询功能。
上述空间关系谓词的定义是CGeometry 对象

此主题相关图片如下：

所实现的ISpatialRelation 和ISpatialRelation2 接口
的基础。如果进一步将ISpatialOperator 接口应用
于空间表达式中,可以实现更复杂的空间查询。
2. 3 　空间数据表达
空间数据表达中最重要的部分是对空间拓扑
关系的表示。Open GIS 的简单要素几何对象模型
没有对拓扑关系作出表述,它建议通过数学方法
计算空间对象的拓扑关系。有多种空间数据的表
达方法,按照结构中包含的拓扑关系,可分为以下
三种有代表性的类型:面结构、节点2弧段2面拓扑
结构以及双重连接边表。
MapManager 采用结点2弧段2面结构存储了对
于一般空间运算必需的拓扑关系。在MapManager
中,空间数据和属性数据统一地存储在一个空间
数据库对象中。空间数据库对象包含了5 个数据
集合对象:1 个地类数据集合和4 个空间坐标数
据集合,分别称为节点库、弧段库、线库和多边形
库。4 个空间坐标数据集合中存储的是空间坐标
数据和拓扑数据。在节点库中存储每个节点的标
识号码( ID) 、节点的坐标以及按逆时针顺序排列
的包含了本节点的所有弧段的ID 集合。在弧段
库中存储每条弧段的ID、弧段上各点的坐标串以
及按逆时针顺序排列的包含了本弧段的所有线和
多边形的ID 集合。在线库中存储每条线对象的
ID、线所包含的所有弧段的ID 集合以及引用了本
线的所有地物的ID 集合。在多边形库中存储每
个多边形对象的ID、多边形的所有边界弧段的ID
集合以及引用了本多边形的所有地物的ID 集合。
在地类数据集合中定义了空间数据库中的所有地
类信息(如道路、河流、房屋) ,每个地类中包含了
若干个属于同一种类型的地物。MapManager 描述
4 种类型的地物:点状地物、线状地物、面状地物
和注记类地物,其中点状地物和注记类地物的空
间坐标都随地物本身存储。线状地物和面状地物
的空间坐标存储在上述4 个坐标库中,两者之间
通过互相指向的指针联系。所有地物的属性数据
都随地物本身存储于地类库中。
2. 4 　空间存取方法
在处理有大量数据的应用时, GIS 软件经常
无法将所有数据同时调入内存,因此要求有一个
可行的空间存取方法,即空间索引技术。
通常来说,通过空间索引来查找数据要经过
两个步骤: ① 对空间图形的近似值(通常是一个
简单的图形,如最小约束矩形MBR) 进行索引,使
之能被快速地筛选; ②对上一步筛选过程得到的
对象的实际数据进行测试,以消除由于近似处理
带来的误差。索引结构可能只管理每个对象的
MBR ,加上一个指向对象在外存数据库中入口的
指针(对象的ID) 。
依照简单、稳定的原则,MapManager 软件采用
R 树结构作为空间数据库的多维索引,在实际应
用中对数据的内外存调度可以满足大多数用户的
速度响应要求。
3 　软件功能设计
3. 1 　空间信息的可视化表达
空间信息的可视化表达包括投影和坐标系统、
专题图和图层管理、符号设计、统计数据的可视化。
MapManager 支持各种常用的投影方式和坐标系统。
统计数据的可视化通过向其他的商业组件提供统
计数据,由这些商业组件来实现。
在MapManager 中,空间数据库中的数据通过
专题图和图层这两个概念展现给用户。数据库中
存在着若干个专题图,可以把它直观地想象成一
本地图册,每一个专题图中包含若干个图层。图
层具有符号属性,并与地类数据集合中某个具体
的地类相连。在显示图形时,图层中的所有地物
按给定的符号依次绘制。专题图中所有图层被组
织成一个树状层次结构,树的高度和每个非叶节
点所包含的子节点的数目都没有限制。
与空间数据库中的4 类地物相对应,
MapManager 中存在着点状符号、线状符号、面状符
号和注记符号4 类符号。一个名为“符号设计器”
的桌面程序负责设计各类符号,如图3 所示。符
号的设计采用面向对象的方法。在图形的绘制过
程中,系统将图形的空间坐标串作为参数传递给
符号对象,由符号对象负责绘图过程。为了处理
同一地类中某些特殊的地物采用不同符号显示的
情况,在此提出符号异常的概念。所谓符号异常
是指对每个需要异常显示的地物对象赋予一个与
其所在地类不同的符号属性,图形绘制程序将识
别这些地物并给予不同的处理。符号异常较好地
解决了共性与个性之间的矛盾,但是如果这种情
况出现得太多将降低图形绘制的性能。

此主题相关图片如下：

3. 2 　数据交换和共享
在数据输入方面,MapManager 目前不提供从数
字化仪输入和图像扫描跟踪输入的能力,因此需要
利用其他软件的数据输入功能,将这些软件的数据
转换到本系统中。OpenGIS 组件的目标是实现不同
种类地理数据和地理处理方法间的透明访问,但目
前在实际生产中被广泛应用的许多软件尚未提供
对这种透明访问所必需的标准访问接口。因此,针
对不同的软件系统,必须编写特定的转换程序,将
空间数据从这些软件系统导入MapManager 中。这
个过程是可逆的,MapManager 同样可以向外部系统
输出标准的交换数据文件。目前,MapManager 提供
了4 种通用的矢量数据的转换接口———Autodesk
DXF File、ESRI Shape File、ESRI E00 File、MapInfo
Interchange Format 。
3. 3 　查询分析
MapManager 通过对标准SQL 语言进行空间
关系的扩展来实现空间查询功能。在此基础上,
实现了缓冲区分析,空间叠置分析中的求交、求
并、同一运算,以及网络分析中的最短路径分析。
3. 4 　数据编辑
数据编辑功能在很大程度上决定了GIS 软件
的易用性。MapManager 将对图形的编辑动作分解
成一个个功能单一的元操作,以图形对象的属性、
方法或事件等形式表现出来。当用户使用它进行
二次开发时,可以按照需求对这些元操作进行顺
序组合,以获得不同的效果。
在设计编辑子系统时,必须考虑拓扑结构的
自动维护和空间对象的目标捕捉功能。拓扑结构
的自动维护是指在对空间数据对象进行编辑时,
系统自动维护各空间对象之间的拓扑关系,在编
辑动作完成之后, 拓扑关系无需重建。
MapManager 实现了非常丰富的目标捕捉功能。捕
捉目标可以是弧段的节点、内点、中点、垂足、延长
线等等。
3. 5 　制图输出
在制图输出方面,MapManager 提供给用户一
整套完整的制图元素对象。它既可以输出到硬拷
贝设备上, 也可以输出到标准的绘图文件如
Enhanced PostScript 文件中。
4 　结　语
目前,以MapManager 软件作为核心组件开发
了若干专业应用。
1) 结合GPS 定位和无线通信技术,开发了一
套车辆监控导航系统,应用于公安、银行、交通等
多个部门。
2) 与多媒体技术结合,为多个旅游景点和部
门开发了功能实用、内容丰富的旅游电子地图。
实际应用表明,MapManager 运行稳定,具备标
准接口,具备符号制作能力强、显示速度快等特
点。但MapManager 在应用中还存在着许多不足,
主要体现为以下方面。
1) 缺乏对空间数据库并发访问的支持。
2) 在处理数据量非常巨大且实时性要求较
高的应用时,空间索引的效率还有待改进。
3) 空间分析功能不够丰富,需要进一步完善。
4) 符号对象的类层次结构使得显示效率有
所降低,尤其是在符号很复杂的情况下。
笔者认为,增加对大型空间数据库管理系统
的访问能力并丰富空间分析功能,从而拓宽软件
的应用范围,是MapManager 下一步的主要发展方
向。
参　考　文　献
1 　方　裕,田国良,史忠植,等. 现代IT 与第四代GIS 软
件. 中国图像图形学报,2001 ,6A(9) :824～829
2 　方　裕,周成虎,景贵飞,等. 第四代GIS 软件研究. 中
国图像图形学报,2001b ,6A(9) :817～823
3 　宋关福,钟耳顺. 组件式地理信息系统研究与开发. 中
国图像图形学报,1998 ,3 (4)
4 　王家耀. 空间信息系统原理. 北京:科学出版社,2001
5 　Eddon G, Eddon H. Inside COM + Base Services.
Redmond , Washington :Microsoft Press , 2000
6 　Egenhofer MJ . Why not SQL. IJGIS , 1992 , 6(2) : 71～
7 　Egenhofer M J , Glasgow J , Günther O , et al. Progress in
Computational Methods for Representing Geographical
Concepts. IJGIS , 1999 , 13(8) : 775～796
8 　Gaede V , Günther O. Multidimensional Access Methods.
ACM Computing Surveys , 1998 , 30(2) : 170～231
9 　Guttman A. R2trees : A Dynamic Index Structure for Spatial
Searching. ACM SIGMOD Int. Conf . on Management of
Data , Boston , 1984
10 　OGC. The OpenGISTM Guide. http :PPwww. opengis. orgP
technoPguidePguide1. htm , 1996
11 　OGC. OpenGIS Simple Features Specification for OLEPCOM
Revision 1. 1. http :PPwww. opengis. orgPtechnoPspecsP992
050. pdf , 1999
12 　OGC. OpenGIS Simple Features Specification for SQL.
http :PPwww. opengis. orgPtechnoPspecsP992049. pdf , 1999