诠释地理信息系统集成平台框架结构研究

导语：诠释地理信息系统集成平台框架结构研究一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

【摘要】提出了基于客户/服务器结构的地理信息系统集成平台总体结构，探讨了基于元数据的地理信息系统数据集成平台以建立物理上分布而逻辑上集中的分布式地理信息系统数据库，提出了应用符合3NF范式的关系数据库进行模型管理的模式，在此基础上探讨了地理信息系统可视化建模工具。

【关键词】地理信息系统集成平台框架结构GIS数据集成平台GIS模型集成平台可视化建模工具

1引言

近年来，随着GIS应用的广泛和深入建立了一大批地理信息系统。随着网络技术的发展和实际的需要，这些分散的系统要求集成运行，以实现信息共享，提高运行效率。在国家“八五”攻关中就开展了这方面的研究[1，2]，在“九五”攻关中对系统实用化和运行业务化提出了更高的要求。地理信息系统集成的重要性得到普遍的认识[3，4]。

地理信息系统集成可以分为两个层次，一个是地理信息之间相互关系的概念层次集成，侧重于地理信息的空间分析；另一个是不同数据和模型之间组织和管理的技术层次集成。本文所指的地理信息系统集成主要指后者意义上的集成。

在计算机集成制造（ComputerIntegratedManufactureSystem，CIMS）领域，集成基础结构或集成平台的概念得到广泛的应用，集成平台被认为是实现企业信息集成、功能集成所需的基本信息处理和通信公共服务的集合[5]。IBM公司基于系统使能器（Enabler）的集成平台在企业应用中获得极大成功[6]，中国在CIMS应用中也广泛使用集成平台技术[7]，收到巨大的经济和社会效益。

文献[8]中作者论述了地理信息系统集成的概念、内涵和必要性，地理信息系统集成平台的功能和特点。本文借鉴CIMS的经验，结合信息技术的新发展，提出了基于客户/服务器的地理信息系统集成总体结构，基于元数据的地理信息系统数据集成平台和基于关系数据库的地理信息系统模型集成平台和可视化构模工具方法。

2地理信息系统集成分析

回顾地理信息系统的发展过程，可以看出地理信息系统的集成在技术上可以分为如下几种形式：

（1）同一GIS软件系统不同模块之间或不同系统之间采用Import/Export的文本文件交换形式。这是最简单也是效率最低的一种方式，它适用于任意系统之间的数据和模型集成。

（2）大型商业GIS软件如ARC/INFO具有一致的数据模型和数据结构，提供二次开发语言，构成软件开发平台。不同模块之间可以采用二进制进行数据交换（如Arcedit和Arcplot），具有密切关系的不同GIS软件系统之间也可以采用这种方式（如ARC/INFO和ERDAS）。在这种模式下用户除了在操作系统的基础上开发应用模型被宿主系统调用外，其它所有的操作只能建立在这个商业软件平台基础上，不同的商业软件平台一般无法直接进行数据共享和功能互补。

（3）采用应用程序接口（API）的形式进行集成。如ARC/INFO提供RPC接口实现客户端与服务器端的通讯，提供ARC/INFO与ARCVIEW的集成。同时用户可以遵循RPC规范开发应用模块以实现系统集成。ESRI提出的分布式计算环境（DistributedComputationEnvironment）也是基于API的思想。

（4）对象连接与嵌入（OLE）的自动化功能（Automation）提供了对象之间的互操作功能，一些最近开发的商业GIS软件如Mapinfo公司的MaplnfoProfessional和GoldenSoft公司开发的Surfer，都提供OLEAutomation，用户可以将该软件作为一个对象嵌入自己的系统。

（5）最近发展起来的对象—关系数据库技术（ORDBMS）将空间数据作为一种数据类型直接集成进入数据库系统，用户可以在这种平台上直接管理矢量空间数据、遥感图像数据和普通关系数据，可以利用这种数据库平台的API开发GIS应用系统。

（6）OPENGIS组织采用COBRA标准，了其简单特征规范（SimpleFeaturesSpecification）1.0版本作为开放地理信息系统的基础，这无疑是地理信息系统软件向开放和互操作发展的重要方向之一，但这种方式需要从底层重新开发GIS软件，在短期内很难直接应用于工程实践。

在以上地理信息系统集成的各种形式中，都存在如下的问题需要解决。

（1）地理信息采集和应用的分布性特点决定了地理信息系统的分布性，地理信息系统集成需要一种分布式空间数据管理和分析模型的相互通讯机制。这种机制既可以适应在目前比较成熟的基于数据文件交换形式（如（1）和（2）），又可以为以后基于API（如（3）和（5））面向对象的地理系统集成（包括（4）—（6））提供发展余地。

（2）地理信息涉及不同的时间、空间和属性，需要有一种有效的地理数据管理的机制，并提供数据融合的能力。

（3）地理分析模型与多种地理数据发生联系，不同模型之间有复杂的串并联关系，模型的组织与管理是需要解决的另一个重要问题。

基于以上的分析，本文提出了基于客户/服务器机制的地理信息系统集成总体结构，基于元数据的数据库集成平台和基于关系数据库管理系统的模型集成平台，以及在系统总体结构和数据库集成平台、模型集成平台的基础上进行可视化建模以辅助空间决策的方法和技术。

3基于客户/服务器的地理信息系统集成总体结构

近年来，客户/服务器（Client/Sever，C/S）体系结构在分布式系统中得到了广泛的应用。尽管这种模式至今还没有一个完整的权威性定义，但人们对这个概念的基本看法是一致的。在C/S结构下，一个或更多个客户机和一个或更多个服务器，以及下层的硬件网络、操作系统和支撑平台进程间通信系统，共同组成一个支持分布式计算、分析和表示的系统，在该模式下，应用分为前端的客户部分和后端的服务器部分。客户方发出请求，网络通信服务系统将请求的内容传到服务器，服务器根据请求完成预定的操作，然后把结果送回客户。

地理信息系统集成平台引入客户/服务器机制后，可以将地理信息系统集成定义为两层C/S结构（图1）。前端用户和数据库集成平台、模型库集成平台、应用模型构成第1层C/S结构，集成平台和应用模型与商业软件构成第2层C/S结构。客户端负责引导用户输入数据源、功能要求和模型选择，以及有关输入输出选择项，将这些信息提交模型集成平台服务器和数据集成平台服务器。模型集成平台服务器负责在模型库中检索符合用户功能要求的模型，并支持模型的组合和建立新的模型，然后将这些模型（包括模型库中已有的和通过宏语言或API新建的）对数据的要求提交数据集成平台服务器，其功能请求转化为RS服务器、GIS服务器、RDBMS服务器可以实现的基本操作并提交给这些服务器。数据集成平台服务器、RS、GIS、RDBMS服务器操作结果将返回给模型集成平台服务器，进而返回给客户端。

当客户端有特殊的显示、制图要求时，模型集成平台服务器将负责根据用户的要求调用其它服务器来实现；如果客户端要求将模型运行的结果进入数据库时，模型集成平台将向数据集成平台服务器发出请求，完成在数据库中的注册。数据集成平台服务器除了接收模型集成平台发出的请求外，还可以直接响应按照时间、空间和属性信息数据查询的要求，在空间框架的基础上实现多元数据的融合，数据集成平台的功能也是调用RS、GIS、RDBMS服务器的功能来实现的。模型与数据库之间、模型与模型之间即可以采用IMPORT/EXPORT的文件交换形式（如ARC/INFO的E00格式等），也为将来全部过渡到API的内存交换形式（如DLL，OLE，ActiveX，COBRA等）提供可能。

这种设计使得系统只考虑软件的功能而不会过分依赖于具体的软件平台，因此系统具有良好的可扩充性，无论采用商业软件还是采用国产软件，只要具有该项功能可以作为服务器，服务器软件类型的变化都不会影响系统结构，便于将来采用国产软件和系统的升级换代。

4基于元数据的地理信息系统数据集成平台

地理信息系统数据库集成平台的目的在于形成物理上分布而逻辑上集中的整体数据视图。实现方式可以采用基于元数据的方式，也可以采用基于空间开放数据库连接（SpatialOpenDatabaseConnectivity，S-ODBC）的结构化查询语言（StructureQueryLanguage，SQL）和动态连接库（DynamicLinkLibrary，DLL）方式，以及基于面向对象的方式，如分布式公共对象模型（DistributedCommonObjectModel，DCOM）和公共对象请求结构（CommonObjectRequestBrokerArchitecture）等方式[8]。由于大型业务化运行的地理信息系统大都建立在商业软件的基础上，很少全部从底层开发，而目前绝大部分商业软件都不支持这些软件协议机制。从实用角度出发，基于元数据的集成平台是一种行之有效的地理信息系统数据集成模式。

美国联邦地理数据委员会（FederalGeographicalDataCommittee，FGDC）制订了分布式地理信息元数据规范，在地理信息标准化和规范化方面做了大量的工作。但是，一方面该规范过于烦琐，在实际应用中很难对该规范的每一项都有明确的表达，另一方面该规范主要针对静态数据集而对动态交互式应用如多源数据融合等考虑不足。因此本文设想，针对地理信息的特点，抽取FGDC的关键内容，对每一个具体空间数据库建立一个与之相对应的元数据记录，将每一个分布式数据库节点形成一个与具体空间数据集相对应的元数据库。根据分布式数据库系统场地自治的原则，各节点负责维护本地数据库与元数据项的一致和统一。数据集成平台服务器保存相应元数据库的副本，并维持与各接点元数据库的动态连接。这种方式的概念模式如图2。