Ajax and WebGIS
如今WebGIS大家应该都不陌生,Google Map将本属于专业应用的GIS引入大众化,不管是做过WebGIS开发还是只是使用Google Map、Mapbar、51ditu做公交查询、位置搜索的人,都已非常了解WebGIS给我们提供的各种基本服务。
WebGIS应用需要和空间应用服务器进行大量交互,简单的如漫游、查询、搜索,复杂的有地理编码、路径计算、空间分析,在发布面向企业的地图服务时,多台空间应用服务器做负载均衡是家常便饭,更不用说面向公众的地图服务。三四年前大家配置好服务器后,能在客户端看到地图显示,做一些基本查询就觉得非常新鲜了,没有过多去关心用户体验,后来为了适应大量用户访问的需要,WebGIS开始应用多级缓存技术,其中切片或瓦片就是其中关键技术之一,简单易用,同时Ajax的出现被立即证明它和WebGIS是不可分割的,所有WebGIS基本功能都可以基于Ajax方式去实现,缓存技术和Ajax在减轻空间应用服务器负载的同时大大改善了原有的用户体验,成为支撑现在WebGIS的经典技术(Ajax暂且也称为技术吧)。
Ajax和WebGIS颇有渊源的,两者几乎是在同一时期开始流行,2006年我参与的一个项目就用Ajax异步调用的方法实现地理查询和动态显示,当时还没有多少项目使用prototype,更不用提mootools、jquery了,全部手工去写,现在大家看来都非常easy,那时确实给客户留下了深刻印象。现在小结一些基本Ajax+WebGIS应用模式:
1.地图漫游。放大、缩小、全图、移动,曾经这些基本操作可是要刷新整个页面的,等待地图加载时弹出一个GIF进度条,现在大家已经习惯了Ajax带来的体验,包括执行每个操作时渐变平滑的效果
2.Identity查询。鼠标点击地图,和指定图层地理要素进行Intersect查询,查询结果以div形式异步弹出,显示要素的基本信息,并给出详细信息链接。
3.搜索。在文本框中输入搜索条件,然后在地图上显示查询结果的位置并高亮显示。
4.根据属性记录定位地理要素。在浮动列表中显示一系列属性记录,鼠标移动到列表中某一记录时,地图动态居中显示该记录的地理位置,并高亮显示。
5.鹰眼。鹰眼和地图之间的平滑联动效果。
6.放大镜。不至于执行一次放大镜操作刷新全图吧,移动放大镜框和按照指定倍数放大地图理所当然应该通过Ajax实现。
7.距离面积量算。动态在地图上绘制出量算范围,并计算结果。
8.地理编码。Geocoding和Reverse Geocoding,在地图上异步显示查询结果,如坐标位置或具体地址。
9.路径计算。路径计算目前有两种实现方式,一种是查询之后刷新整个Map,并返回文字描述信息,一种是查询之后不刷新Map,直接返回文字描述信息。
10.空间分析。空间分析是一个综合名词,缓冲区分析、叠加分析、服务区分析都可以认为是空间分析,空间分析计算量一般相对较大,Ajax异步显示分析结果理所当然。
11.其他。不一一列举了。
WebGIS应用需要和空间应用服务器进行大量交互,简单的如漫游、查询、搜索,复杂的有地理编码、路径计算、空间分析,在发布面向企业的地图服务时,多台空间应用服务器做负载均衡是家常便饭,更不用说面向公众的地图服务。三四年前大家配置好服务器后,能在客户端看到地图显示,做一些基本查询就觉得非常新鲜了,没有过多去关心用户体验,后来为了适应大量用户访问的需要,WebGIS开始应用多级缓存技术,其中切片或瓦片就是其中关键技术之一,简单易用,同时Ajax的出现被立即证明它和WebGIS是不可分割的,所有WebGIS基本功能都可以基于Ajax方式去实现,缓存技术和Ajax在减轻空间应用服务器负载的同时大大改善了原有的用户体验,成为支撑现在WebGIS的经典技术(Ajax暂且也称为技术吧)。
Ajax和WebGIS颇有渊源的,两者几乎是在同一时期开始流行,2006年我参与的一个项目就用Ajax异步调用的方法实现地理查询和动态显示,当时还没有多少项目使用prototype,更不用提mootools、jquery了,全部手工去写,现在大家看来都非常easy,那时确实给客户留下了深刻印象。现在小结一些基本Ajax+WebGIS应用模式:
1.地图漫游。放大、缩小、全图、移动,曾经这些基本操作可是要刷新整个页面的,等待地图加载时弹出一个GIF进度条,现在大家已经习惯了Ajax带来的体验,包括执行每个操作时渐变平滑的效果
2.Identity查询。鼠标点击地图,和指定图层地理要素进行Intersect查询,查询结果以div形式异步弹出,显示要素的基本信息,并给出详细信息链接。
3.搜索。在文本框中输入搜索条件,然后在地图上显示查询结果的位置并高亮显示。
4.根据属性记录定位地理要素。在浮动列表中显示一系列属性记录,鼠标移动到列表中某一记录时,地图动态居中显示该记录的地理位置,并高亮显示。
5.鹰眼。鹰眼和地图之间的平滑联动效果。
6.放大镜。不至于执行一次放大镜操作刷新全图吧,移动放大镜框和按照指定倍数放大地图理所当然应该通过Ajax实现。
7.距离面积量算。动态在地图上绘制出量算范围,并计算结果。
8.地理编码。Geocoding和Reverse Geocoding,在地图上异步显示查询结果,如坐标位置或具体地址。
9.路径计算。路径计算目前有两种实现方式,一种是查询之后刷新整个Map,并返回文字描述信息,一种是查询之后不刷新Map,直接返回文字描述信息。
10.空间分析。空间分析是一个综合名词,缓冲区分析、叠加分析、服务区分析都可以认为是空间分析,空间分析计算量一般相对较大,Ajax异步显示分析结果理所当然。
11.其他。不一一列举了。
确实,简单的几个技术组合将WebGIS向前推进了一大步,直接提升了客户对WebGIS应用的认识和要求,在经过新鲜感的过渡期之后,越来越多的客户需要将WebGIS和具体业务紧密结合在一起,最典型的应用之一是在WebGIS基础去查询或管理业务POI。过去,咱们都是在体验Ajax带给WebGIS的便捷,现在开始出现困惑了,例如WebGIS查询,当查询POI结果有几千到几万时,就会出现性能问题,客户端要异步刷新显示成千上万个POI点,会对客户端会造成较大的压力,如果还要基于这些点进行分级渲染,压力就更大了,有时在稍微年长一点的电脑上根本无法完成。抽稀是一种解决方法,以网状结点去代表每个比例尺级别周围临近的POI点,但这种方法不能适用于所有情况,有的应用非常关心POI点所在的位置有没有超出规定界限,这时抽稀反而带来了显示结果的不准确性。
对于这个问题曾想过很多办法,最后发现自己陷入了固定思维的泥潭,Ajax和WebGIS是天生一对,但在这种模式下,用传统地图请求响应模式比Ajax有效,一万个点在服务器端生成好后,以图片形式传给客户端,网络传输加上客户端的压力和对十个点查询的压力基本相同,压力抛给服务器去处理,看来WebGIS也有不适应Ajax的时候。综合考虑,当请求不多时可以考虑这种模式,当请求量很大时,服务器压力会大大增加,也不是一种万能的方法,不知道有没有更好的技术方案?
现在WebGIS Flex客户端已经开始流行,WebGIS在Flex中同样是基于异步的调用,一万个点仍然是可望不可及的事情,除非提升客户端电脑的配置,如果从开发技术上去实现有没有更好的方法?
一起学习GIS及其二次开发,一起进步!