地理信息系統集成平臺框架結構研究
【摘 要】 提出了基于客戶/服務器結構的地理信息系統集成平臺總體結構，探討了基于元數據的地理信息系統數據集成平臺以建立物理上分布而邏輯上集中的分布式地理信息系統數據庫，提出了應用符合3NF范式的關系數據庫進行模型管理的模式，在此基礎上探討了地理信息系統可視化建模工具。
【關鍵詞】 地理信息系統 集成平臺框架結構 GIS數據集成平臺 GIS模型集成平臺 可視化建模工具
近年來，隨著GIS應用的廣泛和深入建立了一大批地理信息系統。隨著網絡技術的發展和實際的需要，這些分散的系統要求集成運行，以實現信息共享，提高運行效率。在國家“八五”攻關中就開展了這方面的研究[1，2]，在“九五”攻關中對系統實用化和運行業務化提出了更高的要求。地理信息系統集成的重要性得到普遍的認識[3，4]。
地理信息系統集成可以分為兩個層次，一個是地理信息之間相互關系的概念層次集成，側重于地理信息的空間分析；另一個是不同數據和模型之間組織和管理的技術層次集成。本文所指的地理信息系統集成主要指后者意義上的集成。
在計算機集成制造（Computer Integrated Manufacture System， 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提出的分布式計算環境（Distributed Computation Environment）也是基于API的思想。
（4）對象連接與嵌入（OLE）的自動化功能（Automation）提供了對象之間的互操作功能，一些最近開發的商業GIS軟件如Mapinfo公司的 MaplnfoProfessional和Golden Soft公司開發的Surfer，都提供OLE Automation，用戶可以將該軟件作為一個對象嵌入自己的系統。
（5） 最近發展起來的對象—關系數據庫技術（ORDBMS）將空間數據作為一種數據類型直接集成進入數據庫系統，用戶可以在這種平臺上直接管理矢量空間數據、遙感圖像數據和普通關系數據，可以利用這種數據庫平臺的API開發GIS應用系統。
（6） OPENGIS組織采用COBRA標準，發布了其簡單特征規范（Simple Features Specification）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 基于元數據的地理信息系統數據集成平臺
地理信息系統數據庫集成平臺的目的在于形成物理上分布而邏輯上集中的整體數據視圖。實現方式可以采用基于元數據的方式，也可以采用基于空間開放數據庫連接（Spatial Open Database Connectivity， S-ODBC）的結構化查詢語言（Structure Query Language， SQL）和動態連接庫（Dynamic Link Library， DLL）方式，以及基于面向對象的方式，如分布式公共對象模型（Distributed Common Object Model， DCOM）和公共對象請求代理結構（Common Object Request Broker Architecture）等方式[8]。由于大型業務化運行的地理信息系統大都建立在商業軟件的基礎上，很少全部從底層開發，而目前絕大部分商業軟件都不支持這些軟件協議機制。從實用角度出發，基于元數據的集成平臺是一種行之有效的地理信息系統數據集成模式。
美國聯邦地理數據委員會（Federal Geographical Data Committee， FGDC）制訂了分布式地理信息元數據規范，在地理信息標準化和規范化方面做了大量的工作。但是，一方面該規范過于煩瑣，在實際應用中很難對該規范的每一項都有明確的表達，另一方面該規范主要針對靜態數據集而對動態交互式應用如多源數據融合等考慮不足。因此本文設想，針對地理信息的特點，抽取FGDC的關鍵內容，對每一個具體空間數據庫建立一個與之相對應的元數據記錄，將每一個分布式數據庫節點形成一個與具體空間數據集相對應的元數據庫。根據分布式數據庫系統場地自治的原則，各節點負責維護本地數據庫與元數據項的一致和統一。數據集成平臺服務器保存相應元數據庫的副本，并維持與各接點元數據庫的動態連接。這種方式的概念模式如圖2。