2.3　地理数据服务现状分析

传统的空间信息服务以系统为实现方式,不同系统之间差距明显,造成了数据共享服务困难、数据资源浪费等难题。同时,地理信息服务模式也存在信息孤岛、数据更新周期长、数据编辑困难和可视化效果差等弊端。但随着地理信息规模的不断膨胀和复杂化,用户对地理信息数据服务提出了更高的要求,尤其在可视化服务方面,主要表现在对系统实时响应的需求越来越高。因此,地理信息的存储策略与显示方式的选择成为地理信息服务领域面临的一个重要问题[82,83]。地理信息服务遵循网络服务体系架构和标准,利用网络服务技术在网络环境下实现地理信息数据的管理、分析、可视化、共享等应用功能[84]。基于互联网的地理信息服务经历了三个阶段的演变,分别为服务器实时绘图、服务端预先渲染生成地图瓦片、客户端全矢量绘图等方案[84]。

基于地图切片的WebGIS架构是在服务器端实时绘图方案,在此基础上将数据查询和地图渲染提前完成以改进性能[85,86]。WMTS[87-89]与TMS[90,91]本质上是基于栅格数据格式,栅格格式地图结构简单,但无法进行高效的用户交互操作,数据更新、分析、编辑、自定义制图等功能由于需要原始的矢量数据因而较难完成。WMS[92]则因地理信息服务与元数据不对称造成无法针对性地获取到所需要的矢量或栅格图层信息,从而难以实现矢量或栅格图层的无缝集成、数据更新等。

开源组织MapZen推出基于矢量瓦片的项目TileStache[93,94]、OpenGIS渲染引擎Mapnik推出的矢量瓦片格式Mapnik Vector Tile、CartoDB构建的DBaaS[95]、Map Box公司基于开源的OpenStreet Map工具均采用了矢量瓦片的方式。但是这种矢量瓦片的方式难以实现实时的数据更新与渲染,当数据更新时,需要重新建立和组织矢量瓦片,代价较高。

在地理信息服务中,现阶段的WebGIS技术受到了矢量图形显示、数据格式、数据量、栅格瓦片与矢量瓦片在交互式操作与更新等多种因素的限制,为了更好地解决地理空间数据共享与服务,全矢量WebGIS架构应运而生。全矢量WebGIS架构的特征是地理数据的管理、查询功能分布在服务端,数据可视化、数据分析、数据编辑分布在客户端Web浏览器内,客户端与服务器交换基于对象的地理矢量数据。全矢量WebGIS可以弥补栅格切片方案的缺陷。客户端的分析、编辑、自定义制图等功能可以得到完整实现。全矢量WebGIS由三部分组成:①支持误差与响应时间约束条件的空间查询数据引擎;②运行于客户端的地图渲染引擎;③运行于客户端的数据分析、数据编辑等功能模块。目前已实现的全矢量WebGIS架构的应用包括OSM potlatch[96,97]以及基于WebGL[98,99]的Google maps。(https://www.daowen.com)

图2-2　全矢量WebGIS框架结构

运行于客户端的地图渲染引擎使用户可以自定义符号、风格等,实现高亮选择等,需要依赖浏览器的绘图技术[100,101]。数据分析模块可以利用客户端获得的数据进行可达性分析、最短路径分析、空间分布分析等。数据更新模块使数据可以在客户端得到更新,之后上传至服务器,以在线以众包(Crowdsourcing)的方式完成自发地理信息(Volunteered Geographic Information,VGI)的采集[102]。数据传输的协议与编码方式可以采用已有的网络要素服务(Web Feature Service,WFS)与地理标记语言(Geography Markup Language,GML)[103,104],也可采用更为紧凑的协议与格式。虽然目前的浏览器端技术已经能够完全支持全矢量WebGIS应用客户端的实现,但已实现的全矢量WebGIS架构的应用还较少。