關於WebGIS開源解決方案的探討

 文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/。

1.背景

公司目前的多數項目採用的是ArcGIS產品+Oracle+WebLogic/Tomcat/APUSIC/WebShpere這樣的架構。因爲公司從事的是政府項目，甲方單位廣泛均採購有以上產品，因此不少時候忽略購買以上產品所須要的費用。而且不少項目的推廣，ARCGIS、IBM還有聯通或者移動是公司的合做夥伴，涉及到商務問題，對開源的需求並非很大。再則，政府項目通常側重的是系統的穩定和易維護，因此他們在基礎建設上投資比較大方。

不過隨着政府經費的控制趨於嚴格，管理者水平的提升，對相關軟件的購買開始謹慎起來。目前，公司愈來愈多的項目現場是沒有ArcGIS產品的，雖然，咱們已能利用GeoServer來代替ArcGIS Server使用，也推出了相應的產品，而且在不少個項目中已經運用，可是仍然是有不足的。

2.目前公司GIS開源項目的不足——沒有全套的開源解決方案

A.底圖的總體處理仍是用ArcGIS Desktop來進行的配置，而後將配置好的底圖用ArcGIS切圖。

B.雖然利用本地瓦片文件做爲底圖，繞開了地圖的在線服務，可是就切圖工具來講，雖然公司有本身的切圖軟件，可是廣泛採用的仍是ArcGIS的工具切好圖了再給現場實施。

C.涉及到空間數據的管理時，依然是用的ArcGIS Catalog+SDE導入到Oracle數據庫中。不涉及到大量空間數據庫管理時，是採用的直接經過GeoServer來修改shp數據。並無統一管理，也不利於其餘業務組獲取數據。

D.目前基於GeoServer的項目，空間分析能力不強。部分功能已經探索出來，可是尚未在專門的空間分析產品上作出GeoServer版本。

3.WebGIS通用型全套開源解決方案

根據開發環境，能夠將主流的WebGIS開源解決方案分紅兩派，一派是C/C++，一派是java。

C/C++的解決方案爲：Mapserver（服務器）+QGIS（桌面軟件）+Tomcat（中間件）+PostGIS|MySQL空間擴展（數據庫）+Openlayers(JS)/ openscale (FLex)(瀏覽器客戶端)

JavaEE的解決方案爲：Geoserver（服務器）+uDig（桌面軟件）+Tomact（中間件）+PostGIS|MySQL空間擴展（數據庫）+Openlayers(JS)/ openscale (FLex)(瀏覽器客戶端)

3.1MapServer和GeoServer的整體對比

功能上：MapServer弱於GeoServer，QGIS要強於UDIG。

效率上：Mapserver對WMS（Web Map service）的支持更爲高效，而Geoserver則更擅長於結合WFS（Web Feature service）規範的屬性查詢。

如下是來自於http://www.cnblogs.com/mazhenyu/archive/2013/03/16/2963177.html統計的MapServer和GeoServer的使用量趨勢圖。

                       

3.1.1 MapServer的特色

提供兩種工做方式，CGI方式（適用於CGI、AJAX、FLEX開發人員）和MapScript方式（適用於Php、Java、 C#、Python開發人員）。以原生CGI方式效率最高，配合TileCache，能夠快速生成大範圍的地圖瓦片數據。比較基於.Net和J2EE的商 業或開源平臺，MapServer更適合高負荷的大型互聯網地圖應用。MapServer 是基於C寫的地圖服務軟件，比用JAVA寫的GeoServer速度要快。並且 MapServer 歷史要比 GeoServer 悠久，甚至MapServer 的性能與商業的 ArcIMS 的功能能夠娉美。

3.1.2 GeoServer的特色

GeoServer(http://geoserver.org/)是一個符合J2EE規範，且實現了WCS、WMS及WFS規格，支持TransactionWFS(WFS-T)，其技術核心是整合了享有盛名的JavaGISolkit--GeoTools。對於空間信息存儲，它支持ESRI Shapefile及PostGIS、Oracle、ArcSDE等空間數據庫，輸出的GML檔案知足GML2.1的要求。因爲它是純Java的，因此更適合於複雜的環境要求，並且因爲它的開源，因此開發組織能夠基於GeoServer靈活實現特定的目標要求，而這些都是商業GIS組件所缺少的。GeoServer做爲一個純粹的Java實現，被部署在應用服務器中，簡單的如Tomcat等；它的WMS和WFS組件響應來自於瀏覽器或uDig的請求，訪問配置的空間數據庫，如PostGIS、OracleSpatial等，產生地圖和GML文檔傳輸至客戶端。

具備如下優勢： 1） 用 java 語言編寫、標準的 J2EE 框架、基於 ser vlet 和 STRUTS 框架、 支持高效的 Spring 框架開發； 2） 兼容 WMS 和 WFS 特性、支持 WFS-T 規範； 3） 高效的數據庫支持 PostGIS、ShapeFile、ArcSDE,Oracle、MySQL 等； 4） 支持上百種投影； 5） 可以將網絡地圖輸出爲 jpeg、gif、png 等格式；

3.2QGIS和uDig的比較

A.界面：QGIS優於uDig。

B.空間分析能力：QGIS優於uDig。

C.發展趨勢上：uDig優於QGIS。

D.操做上：uDig優於QGIS。

E.支持的數據源上：uDig優於QGIS。

 

QGIS的界面：

 

uDig的界面：

 

3.3 PostGIS和MySQL空間擴展的對比

根據http://www.cnblogs.com/shanyou/p/3256906.html所提供的觀點，下面將其截取總結。

3.3.1 PostGIS的特色

A.PostgreSQL 的穩定性極強。

B. 任何系統都有它的性能極限，在高併發讀寫，負載逼近極限下，PG的性能指標仍能夠維持雙曲線甚至對數曲線，到頂峯以後再也不降低，而 MySQL 明顯出現一個波峯後下滑。

C. PostGIS多年來在 GIS 領域處於優點地位，由於它有豐富的幾何類型，實際上不止幾何類型，PG有大量字典、數組、bitmap 等數據類型，相比之下MySQL就差不少，instagram就是由於PostGIDS的空間數據庫擴展POSTGIS遠遠強於MySQL的my spatial而採用PGSQL的。

D. 對於WEB應用來講，複製的特性很重要，mysql到如今也是異步複製，pgsql能夠作到同步，異步，半同步複製。還有MySQL的同步是基於binlog複製，相似oracle golden gate,是基於stream的複製，作到同步很困難，這種方式更加適合異地複製，pgsql的複製基於wal，能夠作到同步複製。同時，pgsql還提供stream複製。

3.3.2mySql空間擴展的特色

A.MySQL有一些實用的運維支持，如 slow-query.log ，這個PostGIS確定能夠定製出來，可是若是能夠配置使用就更好了。
B. MySQL的innodb引擎能夠充分優化利用系統全部內存，超大內存下PostGIS對內存使用的不那麼充分，
C.MySQL的複製能夠用多級從庫，可是在9.2以前，PostgreSQL不能用從庫帶從庫。
D.從測試結果上看，MySQL5.5的性能提高很大，單機性能強於PostgreSQL，5.6應該會強更多.
E.對於web應用來講, MySQL5.6 的內置MC API功能很好用，PostgreSQL差一些。

4.適合公司的解決方案

4.1緣由

公司的後臺均由Java編寫，因此選擇確定更偏向於基於JavaEE的解決方案。且咱們GIS組已經在GeoServer的開源框架上進行了相關開發，好比最短路徑服務的開發和道路優化的開發等，而且已經能很好的利用GeoServer提供的WMS服務和WFS服務來進行替AGS化，並且還編寫了面向GeoServer的項目配置和發佈工具。

同時，公司的V14GIS產品前端採用的是ArcGIS_JS，而且已經對其方法進行了大量封裝和整合。

因此，適合目前公司的GIS開源化的解決方案應該是首選：

Geoserver（服務器）+uDig（桌面軟件）+Tomact（中間件）+PostGIS（數據庫）+ArcGIS_JS (JS)。

對於老項目，只須要將js部分換成咱們已有的基於Flex的產品便可。

4.2具體解決方案

A．利用PostGIS將shp數據入庫管理。

B．利用uDig鏈接PostGIS後進行配圖。uDig能夠生成sld文件，以及發佈到GeoServer的樣式服務上去，從而實現對服務的配圖控制。

C．利用GeoServer來代替ArcGIS Server。經過WMS服務能夠實現相似於AGS中的export出圖方式，實現部件圖層的動態出圖。經過WFS服務能實現與相似於AGS中的Query服務。經過WFS服務也能夠實現相似於AGS中的FeatureServer服務，從而進行圖層的編輯。同時，經過WFS服務還能實現相似於AGS中的GeometryServer服務，實現好比union等功能。

D. 利用GeoWebCache插件，能夠實現相似於AGS中的cache功能。同時支持切圖。

E.利用GeoTools，能夠在後臺開發覆雜的空間分析和相關操做的功能。

5.亟待解決的問題

5.1技術問題

A．須要驗證GeoWebCache的配置和切圖功能。以及對GB以上數據的切圖效果。

B.須要驗證PostGIS對中文的支持（目前測試是支持的）。以及大數據入庫時的穩定性。

C.配圖的易用性。目前已測試uDig能夠配圖生成sld，且能配置比較複雜的圖。可是如何能直接將所配的圖層發佈到GeoServer後，讓此sld自動與該圖層關聯，還沒測試。後期還需考慮是否有必要開發一個更簡易的配圖及發佈工具。

D.基於GeoServer的空間分析功能尚未驗證，目前只開發了部分。

5.2業務問題

若是GIS方面完全換成開源方案，MIS、工做流、統計、手機等等業務如何和GIS業務結合？

目前公司對固定業務基本採用同一標準庫。不一樣的業務使用標準庫中的不一樣用戶空間。有交互的部分的表共用一個業務用戶空間。假如咱們GIS部分所有采用了開源方案，甚至空間數據的管理都採用開源的數據庫來進行管理。如何作到和其餘業務的整合，也是一個須要思考和通力解決的地方。

我我的以爲，是能夠將GIS的空間數據用開源數據庫存放，GIS的業務表仍是放入到主版本的數據庫中，應該是能夠解決以上問題的。

可是問題又來了，既然都有主版本所用的數據庫了，好比Oracle，又何須還採用開源數據庫呢。

不過，通過我最近的研究，GeoServer也是支持Oracle中的數據的發佈的，只是有相關的插件要安裝。同時，也有不經過SDE將空間數據導入Oracle的方法。

可是，這種方案，有個最大的問題就是操做相對複雜。

5.3 項目實施人員的實施難度加大問題

開源項目的部署實施問題，是對工程人員的一個巨大挑戰。同時，維護的難度也會加大。人的問題實際上是最大的問題。

並且工程人員的培訓所須要的開銷也應該是公司必須考慮的一個方面。

 

　　　　　　　　　　　　　　　　　　　　　　　　 -----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                           若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^