搜索引擎 WEBGIS 开发
-----入门篇
第一章 概述
1.1 诞生
Google Earth 的推出,无异于在 GIS 业界引发了一次不小的地震,非 GIS 行业的这种
准 GIS 服务模式,对所谓的专业 GIS 服务是个不小的冲击,首先感到有压力的就是 WEBGIS
业务了。在综合了 Google 地图服务各功能后,我们推出了“搜索引擎版 WEBGIS”这一概
念和产品。就提供地理底图的方式来讲,再也不是传统的方式——服务器端将矢量地图临时
生成栅格图发给客户端,而是事先生成好栅格图,用户请求时不必做任何处理就可以即时发
给客户端;就客户端的显示方式来讲,摒弃了传统的一张地图的显示方式,客户端采用多幅
小图拼接的方式显示,总体看起来像是小图片填充一个大的栅格的效果。
1.2 实现
搜索引擎版 WEBGIS 一个很显著的特点就是它显示的某一范围的地图的比例尺是限定
的,如武汉市的电子地图在搜索引擎版 WEBGIS 的组织方式下,用户可以看到的是 1:2000,
1:5000,1:10000……1:250000 这样 8 个级别。从数学概念上来说,搜索引擎版 WEBGIS
提供的是一种离散比例尺的地图服务,而传统 WEBGIS 提供的是线性比例尺的地图服务。
在组织数据的时候,对每一比例尺的栅格地图进行分割,将其按照某一尺寸(如 256×256
象素)划分为若干块,每一块都是一个独立的栅格图片。客户端进行显示的时候,先确定需
要的比例尺(级别),显示范围(小的栅格图片的块数),再从服务器下载显示。
1.3 优势
1.3.1 速度快
传统的 WEBGIS 生成地图的运算是在运行时进行的,即用户每做一次缩放或漫游操作,
都会引发服务器矢量数据转栅格数据的一次运算。而搜索引擎版 WEBGIS 则省去了这一过
程,地图都已经事先生成好,客户机/服务器的一次交互主要是 I/O 过程,其效率可想而知。
并且,搜索引擎版 WEBGIS 采用强客户端设计,大量的逻辑坐标转换和图片行列号的计算
都放在客户端,服务器端主要处理图片资源的调度,更进一步的,处理查询,负担大大减轻
了,其承载客户量,服务器速度和质量都有很大提升。
1.3.2 效果好,平滑过渡
与传统的 WEBGIS 的单图显示不同,搜索引擎版 WEBGIS 在客户端地图显示区显示的
是多幅小图,并且都在客户端缓存起来。用户在进行漫游时,尚在显示范围内的地图直接从
客户端缓存中读取,显示范围以外的地图再从服务器实时读取,这样就会实现一种平滑的过
渡的效果;那么,如果用户想查看已经漫游过的区域时,仅仅需要从本地磁盘读取图片,显
示就非常之快了。
1.3.3 将更多服务器端的计算放到客户端进行
搜索引擎版 WEBGIS 采用强客户端设计,大量的逻辑坐标转换和图片显示拼接的计算
都放在客户端,服务器端主要处理图片资源的调度,更进一步处理查询等复杂操作,负担大
大减轻了,其承载客户量,服务器速度和质量都有很大提升。解决了超大矢量地图显示慢的
问题。服务器端实时地显示一张大数据量的矢量地图(如上 G 的矢量数据)肯定是很消耗
资源和时间的,即使是对显示进行了优化,如抽稀地图要素。在搜索引擎版 WEBGIS 中,
这种耗时的工作在前期的数据组织阶段就已经完成。在站点运行过程中,对于同一窗口范围
大小的地图,几个 G 的矢量数据处理出来的图片和几十 K 数据处理出来的图片大小是差不
多的,显示起来也是同样的速度。
1.3.4 在传统 B/S 结构中增加 AJAX ENGINE 层,体验页面无刷新
与传统的 Web 应用开发方式比较,搜索引擎版 WEBGIS 在浏览器端添加了一个层---Ajax
engine,由用户产生的页面事件交由这个引擎处理,它负责向服务器发送请求,服务器传回
的是业务数据而非 HTML,引擎接受之后,进行渲染,通过浏览器的解析在页面上显示出来。
也就是将事件监听与页面渲染的工作交给了浏览器,而后台服务器只负责业务逻辑的处理。
在 Ajax engine 方式下,HTTP 基于请求/响应的范式仍然没有变化,但是由于有
XmlHttpRequest 对象(Ajax engine 的核心)的支持,我们不需要像以前那样将每一次请求发
到服务器后,由服务器解析请求再进行事件发配,之后返回刷新用的 HTML 页面。在新的方
式下,由于事件的监听和处理在浏览器内部实现,它的反应周期可以被缩短,事件的处理力
度可以更方便的做到更细,而且由于支持异步方式发送 Request 请求和接受 Response 响应,
用户事件的控制有了更大的灵活性。
1.3.5 能够满足巨大人数的访问要求
传统的 WEBGIS 生成地图的运算是在运行时进行的,即用户每做一次缩放或漫游操作,
都会引发服务器矢量数据转栅格数据的一次运算。而搜索引擎版 WEBGIS 则省去了这一过
程,地图都已经事先裁剪好,用户执行操作后,服务器的任务就是选择地图传给客户机,客
户机/服务器的一次交互主要是 I/O 过程,这样大大减少了服务器端的负荷,新技术的采用
能够满足大用户量的同时访问,经测试表明,一台普通的 PC 机就可以承担每秒上千次的访
问。
1.3.6 基于全国的地图搜索系统
搜索引擎版 WEBGIS 另一个重要特点是实现全国范围内的地图搜索和信息显示。相比与
以往的基于城市级的 WEBGIS 系统,搜索引擎版 WEBGIS 能够让用户在全国甚至全球范围
内进行 GIS 方面的各类查询,实用性更加广阔。搜索引擎版 WEBGIS 主要包括以下功能:
城市地名搜索:例如选择‘湖北’的‘武汉’,然后直接显示武汉市的城市地图;
全国性的信息点搜索:例如在‘武汉’范围内搜索‘酒店’,可以直接显示武汉市
内酒店列表,供用户选择;
基于全国范围的路径分析:例如分析从‘北京’的‘天安门’到‘武汉’的‘黄鹤
楼’的路径,系统会给出最安全可行的自驾车路线;
市内公交路线搜索:例如搜索‘武汉’市的‘黄鹤楼’到‘中山公园’的乘车路线。
图 1-1 基于全国的地图搜索界面
1.4 适用范围
以目前的眼光来看,搜索引擎版 WEBGIS 可以在两个方面有其突出优势。一是面向大
众的地图服务,这种服务的要求不是很高,但用户量大,要求显示速度高;二是海量矢量数
据的业务应用,这种应用如果采取原先的方式,地图显示效率难免会出现问题,可以针对具
体业务需求定制显示级别更为详细,查询分析功能更强的搜索引擎版 WEBGIS 应用。
第二章 实现技术
2.1 JAVASCRIPT
JavaScript 可以使多种任务仅在客户端就可以完成而不需要网络和服务器的参与,从而
支持分布式的运算和处理。因此,把 JavaScript 技术应用于 WEBGIS,大大减轻了网络传输
和服务器的负担。在这种技术下,所有的 GIS 操作都是在本地完成的,服务器仅需提供 GIS
数据服务,网络也只需将 GIS 数据一次性传输。
2.1.1 JavaScript 的由来
JavaScript 语言的前身叫作 LiveScript。自从 Sun 公司推出 Java 语言之后,Netscape 公
司就引进 Java 的程序设计概念,将原有的 LiveScript 重新设计后,改名为 JavaScript。之所
以取名为 JavaScript,原因在于 JavaScript 是一种嵌入 HTML 文档的、基于对象的脚本设计
语言,语法同 Java 语言很相似,而且 JavaScript 的设计使它很容易同 Java 语言一同工作,
还可以充分支持 Java 的 applet 小应用程序。所以,可把 JavaScript 看成 Java 语言的某种简
化版本。
2.1.2 JavaScript 的定义
JavaScript 是一种通用的、基于原型的、面向对象的脚本语言,它的设计目标是在不占
用很多系统和网络资源的情况下提供一种可以嵌入不同的应用程序的通用代码。它不需要依
赖于特定的机器和操作系统,即它是独立于操作平台的。使用它的目的是与 html 超文本标
记语言、java 脚本语言(java 小程序)一起实现在一个 web 页面中链接多个对象,与 web
客户交互作用。从而可以开发客户端的应用程序等。它是通过嵌入或调入在标准的 html 语
言中实现的。它的出现弥补了 html 语言的缺陷,它是 java 与 html 折衷的选择。
2.1.3 JavaScript 应用的优点
1. 首先,在 JavaScript 这样的用户端脚本语言出现之前,传统的大数据量的提交与验证,
都要由用户端浏览器通过网络传输到服务器上进行,这对网络和服务器来说实在是一种
无形的浪费,而 JavaScript 的出现解决了这一问题,客户端可由 JavaScript 实现自动的
验证;
2. 其次,JavaScript 可根据用户的需要“定制”浏览器,从而使网页更加友好;它采用小
程序段的方式实现编程。像其它脚本语言一样,Javascript 同样已是一种解释性语言,它提
供了一个易的开发过程。
3. JavaScript 可以使多种任务仅在客户端就可完成,而不需要网络和服务器的参与,从而
支持分布式的运算和处理。
4. JavaScript 是一种解释性的语言,即不需要对 JavaScript 程序进行预先编译而产生可执
行的机器代码。使它比编译性语言更加易于编程和应用。
5. Javascript 的简单性主要体现在:首先它是一种基于 java 基本语句和控制流之上的简单
而紧凑的设计, 从而对于学习 java 是一种非常好的过渡。其次它的变量类型是采用弱类
型,并未使用严格的数据类型。