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）規範的屬性查詢。

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空間擴充套件的對比

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/p/4187679.html