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技术分离出实体的地理坐标和属性信息，最终在地图上绘制实体，以列表的形式表示属性。