2010年2月13日 星期六

Web GIS與Cloud Computing

雲端運算近來很熱,到底雲端計算是什麼?由台大資工黃老師在「淺談雲端運算」指出:

「雲端運算」的概念事實上也不算新,其本質大抵承襲自「分散式運算」(Distributed Computing)以及「「網格運算」」(Grid Computing)

「雲端運算」與「網格運算」兩者都是分散式運算的延伸並沒有顯著的不同。唯獨「網格運算」著眼於整合眾多異構平台,而「雲端運算」則強調在本地端資源有限的情況下,利用網路取得遠方的運算資源。

我非常同意以上的觀點,除此之外我還認為雲端運算的可親近性較佳。當網格運算提出時,就指稱未來網格運算就像是自來水的基本設施,打開水龍頭就可以使用。現在雲端運算取代了網格運算作到這點了。當我們在使用Gmail或Google Map時就使用了雲端服務。當我使用Google App Engine及Microsoft Windows Azure開發系統時,就使用了雲端技術。當系統使用者暴增時(如果你有付錢時),自然雲端服務就會調配更多運算資訊應付。

在Web GIS的服務也是運多大量的雲端運算。

例如 Google Map 0~19的圖層的產生稱為影像金字塔圖層。也有人稱作Tile,這種服務OGC也在草擬OGC Tile Service。我認為就是用Tile一片片建成完每一層,各層建完後就成了影像金字塔。真實世界中的埃及的金字塔也是用一個個大型的磚一層一層建立。

pyramid1圖片來源

great-pyramid
圖片來源

 

2010-02-13_094303 Google / Microsoft 呈現的這些影像金字塔圖層都已經預先產生好了。若要更新全世界的影像金字塔圖層得花上不少時間,若使用雲端運算,可以減少不少的時間。尤其是地圖繪圖運算及大量小圖(tiles)IO存取的時間會大符的減少。雲端運算讓繪圖更快是一定的。比較特別是IO存取的時間,以下就加以說明。通常架構簡單速度會愈快,於是使用NAS來存放是不錯的選擇,但是提供Web GIS服務時大量檔案IO存取會讓NAS、PC甚至Server無法負荷。透過雲端的大量電腦將產生/存取小圖的IO時間大量的分散,達到快速大量服務的目的(high Scalability)。

若要自已架設雲端運算的架構可以使用Java-based的hadoop,網址如下http://hadoop.apache.org/
http://www.hadoop.tw/

有興趣的朋友可以自行研究。

在Web GIS上呈現向量的資料是很消耗頻寬及瀏覽器運算能力的事,例如台灣的鄉鎮行政區的資料大約6MB,總不能讓每個User都下載6MB的向量地圖再呈現。在網路環境下比較好的作法是將向量資料轉成圖片(tiles)再呈現。這樣多大量的資料都變成固定大小的圖片,速度快了不少。但是少了向量資料的特性,無法動態變更樣式及無段縮放大小(所以Web GIS 常用固定比例尺分層)。

Google Map最近也把影像金字塔的雲端運算運用在Google Map API上,使用GGeoXML來呈現向量資料時,Google會轉這些向量資料轉換成小圖(tiles)再呈現,這樣速度快非常多,尤其是呈現大量的多邊形,例如行政區、地籍圖…等。其運作示意圖如下。

2010-02-13_094302

天啊!Google怎麼這麼貼心呢?以前都要小心Web GIS上呈現資料的大小,現在Google都幫我們作成影像金字塔後呈現,且圖片上的圖徵透過Image Map及Json技術還是可以點選的。使用上與原本的沒有差別。真是太好用也太方便了。但是大家有沒注意到一件事,就是所以有資料都會送到Google一份,當然Google會好好的善待它,而我們也在同意使用Google Map API時就同意這件事了。Google蒐集到愈來愈多的空間資料,也可以作更多的是事。雖然Google企業文化、精神是”Don't be evil”,但是也不代表未來一直是如此,再加上駭客也一直在惡意攻擊Google(由最近Google欲退出中國的事件可看出其嚴重性),放在Google上的資料還是有可能被二次使用及作惡意用途。所以建議私人及機密的資料,別使用Google Map API的GGeoXML及其後使用雲端運算的方法來呈現資料。例如地籍圖資網路便民服務系統查詢可以將地籍資料呈現在Google Map上的作法,就得小心地避開此點。不然久而久之Google就會有全台的地籍資料、甚至政府大部分的空間資料。

透過方便使用取得雲端運算可以解決網路系統開發的許多問題。但是衍生出隱私權的問題值得再建立系統前就考量清楚。這樣會是一個比較正確的作法。

若真的不要使用Google或微軟的雲端運算及Web GIS API,當然還有其它的選擇,在Open GIS 、Hadoop都是不錯的選擇,只是需要花時間自己研究建立。另一個思考的方向是完全分散式的架構。使用OGC的標準來建立運算服務及圖資服務。例如:GIS空間運算使用Hadoop實作,再由OGC WPS(Web Processing Servic)方式提供服務。這樣使用QGIS或其它支援WPS的Client就可以使用其功能來作運算。類似這樣的方式就可以集中自己的精神作自己擅長的事,且與整個的GIS作結合,也是一個不錯的方向。