地理資訊系統整合平臺框架結構研究

【摘　要】 提出了基於客戶/伺服器結構的地理資訊系統整合平臺總體結構，探討了基於元資料的地理資訊系統資料整合平臺以建立物理上分佈而邏輯上集中的分散式地理資訊系統資料庫，提出了應用符合3NF正規化的關係資料庫進行模型管理的模式，在此基礎上探討了地理資訊系統視覺化建模工具。
【關鍵詞】 地理資訊系統 整合平臺框架結構 GIS資料整合平臺 GIS模型整合平臺 視覺化建模工具

　　1 引 言
　　近年來，隨著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。