ajax與webGIS[轉載]

 

去年看的文章，很不錯 <轉>     現在越來越多的案頭應用轉向Web平台，而人們也一直希望日益豐富的Web應用能夠做到簡單易用、高效並具有良好的互動效能。隨著Google推出Google Maps、GMail等一系列服務讓人們看到了曙光，感受到一種全新的Web使用體驗。這種體驗的顯著特點就是無需下載、安裝，操作響應速度快，具有良好的互動性，尤其是再也沒有出現以往那種在等待返回結果期間由於瀏覽器重新整理而造成的白屏現象。        這種令人欣喜的體驗源自服務中所採用的Ajax方法。Ajax（Asynchronous JavaScript + XML）並不是一種新的技術。正如它的名字所表現的那樣，Ajax是由幾種蓬勃發展的技術以新的方式組合而成：使用XMLHttpRequest進行非同步資料轉送；利用XML和XSLT技術進行資料的交換與處理；以XHTML和CSS作為顯示標準，通過DOM實現動態顯示和互動；而這一切都通過JavaScript串聯銜接起來。正是這些傳統技術看似簡單的重組卻給Web應用開發帶來新的活力。 對於WebGIS而言，這種良好的使用者體驗是其應用一直缺乏的，研究與開發人員總是難以在效能和使用體驗之間找到合適的平衡點。針對這個問題，本文探討了Ajax方法在WebGIS用戶端實現中的應用，以期改善使用者體驗。 AJAX用戶端分析 傳統用戶端分析       經過多年的發展，WebGIS的系統架構已趨於成熟穩定，通常採用三層B/S（Browser/Server）結構，即由瀏覽器、GIS應用伺服器、空間資料庫等三部分構成。其中，瀏覽器對應於傳統C/S（Client/Server）結構中的用戶端。         用戶端是聯絡使用者與GIS服務的橋樑，作用重大，但先天受制於瀏覽器，後天則深受系統所採用開發技術的影響。初期的WebGIS採用CGI方式，互動操作完全依賴瀏覽器處理，使用者體驗很差，經常遇到白屏狀況。研究人員隨即引入Plug-In技術擴充瀏覽器的GIS 功 能，但收效並不顯著。而隨著Java、DCOM 等技術的大規模應用，主流GIS廠商紛紛採用Applet、ActiveX等技術開發用戶端。它們嵌入網頁運行，功能較強，但與服務端耦合度高，初次使用前還要下載並安裝相應程式。不同之處在於：Applet可以跨平台運行，前提是有Java運行環境的支援；而ActiveX只適用於Windows平台，安裝時還需安全認證與註冊。這些額外的要求對普通使用者是種負擔。因而，除Applet與ActiveX外，ArcIMS等商業WebGIS軟體同時提供了基於JavaScript和DHTML等技術的用戶端實現。雖然簡便，但效果不甚理想，使用者常陷入等待之中。         此外，WebGIS所採用的空間資料傳輸模式對用戶端的開發也有較大影響，一直存在著矢柵資料之爭。地圖可在伺服器端完成處理與繪製，以JPG等映像形式通過HTTP協議傳輸給用戶端。這種柵格地圖是靜態，缺乏互動性，傳輸佔用網路頻寬大，但可直接通過瀏覽器查看，用戶端功能因而比較簡單而對伺服器的要求高。相關工作也可部分移至用戶端完成，Applet和ActiveX方式中常採用。向量資料通常基於TCP/IP協議傳輸，由於資料量相對較小，所以速度快。這種用戶端在本地繪製地圖，可以實現即時互動，甚至完成一些較複雜的分析工作。權衡利弊，開發人員不得不在用戶端和服務端之間進行平衡，或採用胖用戶端模式，或是瘦用戶端模式，抑或是混合模式。       隨著OGC（Open GIS Consortium）共用標準的出台與不斷完善，WebGIS逐步向著資訊共用的方向發展：向量資料統一採用GML作為交換格式，可以和柵格資料一樣通過HTTP協議進行傳輸；所提供的服務也逐步細化、標準化。只要遵循OGC各類服務規範即可在異構環境下完成相關空間資料處理任務，降低了服務端與用戶端的耦合度。這些變化對基於瀏覽器的用戶端提出了新的要求，同時也帶了機遇。 Ajax模型        傳統Web應用程式模型的運行流程為：使用者的操作觸發提交給Web伺服器的HTTP請求，伺服器接到請求後執行相應操作，然後返回一個HTML頁面給用戶端。這個過程不斷重複直到使用者退出。整個過程是同步的，前一步結束才能進入下一環節，因而導致使用者在發出請求後，得到返回結果前的這段時間裡一直處於等待狀態。瀏覽器同樣因為等待而無法響應使用者的進一步操作，並由於頁面重新整理引發白屏現象。          Ajax模型與傳統模型的不同之處在於服務應答的非同步性（圖1）。這是通過在用戶端與服務端之間引入一個中介層——Ajax引擎（Ajax Engine）實現的。Ajax引擎將用戶端的頁面剝離為資料層、控制層和表現層：瀏覽器中的各類資料被組織成一棵DOM樹；針對操作觸發的各種事件，利用JavaScript處理DOM資料並依據XHTML和CSS規範進行介面的繪製。結構的明晰為非同步應答奠定基礎，所有與服務端的通訊都被集中提交給XmlHttpRequest對象處理。該對象封裝了XML-RPC協議，支援非同步請求，相當於提供了獨立使用者互動線程之外，與服務端通訊的專用線程。簡而言之，通過XmlHttpRequest可以使用JavaScript向伺服器提出請求並處理響應，而不阻塞使用者。這種非同步通訊機制是Ajax模型的核心。這種特性決定了它適用於需要與服務端頻繁互動，操作即時響應要求高的環境。 這裡以IE環境為例說明XmlHttpRequest的基本運用。建立XmlHttpRequest對象request，以GET方法向伺服器提交參數url，收到回應後調用callback函數。代碼如下： request = new ActvieXObject(“Microsoft.XMLHTTP”); if (request!= null) { url = “http://localhost/q?x=1 ”; request.onreadystatechange = callback; request.open (“GET”, url, true); request.send ( ); } 基於Ajax和OGC規範的WebGIS架構 通過用戶端的發展回顧和Ajax機制分析，我們不難發現WebGIS具備採用Ajax開發的基本特徵：需要即時的互動響應，大量、頻繁地與伺服器通訊並以GML或圖片形式傳輸資料。實際上，ArcIMS早已徘徊在Ajax大門外了。它的HTML Viewer模式可傳輸ArcXML資料與圖片，利用JavaScript指令碼控制操作同時採用DHTML技術顯示地圖，只缺非同步傳輸這關鍵一環。所以，Ajax完全可以擔當起WebGIS用戶端實現的重任，提升使用者體驗。 在符合OGC規範的WebGIS中採用Ajax實現用戶端是極其合適的，顯而易見的好處就是以極自然的方式實現了空間資訊共用所需要的通用用戶端。人們無需安裝額外的程式，僅依靠瀏覽器本身就可以從網上擷取空間資訊，系統開發的焦點僅需集中在提高服務端效能。Google Maps已為我們展現了這種情境。 Google Maps可以看作是OGC規範中WCS 服務（Web Coverage Service）與WFS服務（Web Feature Service）的應用，分別提供映像與興趣點查詢服務。地圖是渲染好的，和衛星影像一樣以映像形式存放在伺服器端，並被切片按金字塔方式組織。含有地理座標的興趣點資料則單獨存放在資料庫中。在用戶端，整個互動過程為： 1、Ajax引擎響應使用者操作得到當前比例尺、視場範圍以及滑鼠所在螢幕位置； 2、將螢幕座標換算為地理做標，以非同步方式讀取相關資料； 3、將返回的興趣點座標換算為螢幕座標，在用戶端完成繪製併疊加在地圖與影像上。 Google Maps作為一種面向福士的地圖發布系統不失為一個好的解決方案，但對於WebGIS應用來說是遠遠不夠的，地圖在這裡只是一個簡單的參照系統，使用者無法完成更多的空間資料處理與分析工作。 一個基本的WebGIS應該提供WMS服務（Web Map Service）和WFS服務。WMS允許使用者以指定方式繪製地圖並輸出為映像，主要支援GetCapabilities，GetMap和GetFeatureInfo三種介面調用，由GetMap介面實現製圖功能。WFS提供關於實體的各項檢索服務，如相鄰查詢等。擴充的WFS-T服務額外支援資料編輯、更新操作。調用OGC服務可採用兩種方式：一種是把參數寫成URL形式，通過GET方式提交給服務端；或是將請求命令封裝成XML以POST方法提交。柵格地圖常採用GET方法擷取，如 http://wms.jpl.nasa.gov/wms.cgi?&VERSION=1.1.1&REQUEST=GetMap&STYLES=&LAYERS=global_mosaic&FORMAT=image/png&SRS=EPSG:4326&BBOX=73,18,135,53&width=800&height=456， 表示向JPL（Jet Propulsion Laboratory）請求製圖服務，採用WGS84座標系統，範圍為北緯18-53度與東經73-135度之間，包含global_mosaic圖層的地圖輸出格式為png，大小為800*456。而複雜的WFS調用則將服務要求封裝成XML格式，採用POST方式提交，返回的GML結果用XPATH與XSLT技術分離出實體的地理座標和屬性資訊，最終在地圖上繪製實體，以列表的形式表示屬性。