地理Web服务

Web服务是WebGIS发展的一个重大进步,是现代WebGIS的核心技术和重要标志。它集GIS、程序组件和互联网的优点于一身,深刻改变了GIS开发和应用的方式。它绕过了本地数据转换和本地软件安装的复杂环节,使得不同的计算机系统和不同的部门之间可以在Web服务层面进行集成,为软件应用开发提供了一个新的基础模块,为跨部门的协调合作提供了一种新的方式,为国家空间数据基础设施(NSDI)提供了技术框架。越来越多的机构在把自己的数据和功能发布和共享为Web服务,供本单位、往往也供其他单位使用。这些服务即可以被组合到其他的WebGIS应用之中。

着重介绍Web服务的基础知识,包括Web服务的概念、影响、作用及优点,SOAP和REST风格的Web服务,Web服务的相关标准,如WMS、WFS、WCS、CSW、GML、KML 和 GeoRSS,以及 Web 服务的优化。

从Web站点到Web服务

Web服务的产生及优势

WebGIS在90年代初产生之后迅速发展,但早期的Web应用系统和软件, 包括WebGIS , 大都是仅能独立使用的网站,这种系统在内部结构和外部开放方面都逐渐显示出其局限,难以充分发挥WebGIS的潜力。

局限1

系统之间缺乏良好的互操作性,每一个WebGIS是孤立的、封闭的系统,不同的系统之间无法互相调用对方的功能和共享信息,不能进行互操作。假设系统A的某一个功能正是系统B所需要的,但因为系统A是封闭的,没有对外提供基于Web的编程接口,无论是系统B的客户端还是服务器端,均无法调用系统A的功能。反之亦然,系统A也不能调用系统B。

局限2

系统内部耦合度较强,应用模式不够灵活每个系统都是作为“独立解决方案”来开放的,系统中各个模块之间的接口是紧密的和局部的。当系统需要改进时,这种高度耦合的结构在源程序更改和系统维护上的代价比较高,不够灵活。

随着信息社会的发展,越来越多的现实应用需要调用、组合、或套嵌其他 WebGIS系统所提供的功能和信息,因此,如何使WebGIS变得开放,使不同的系统之间能够进行互相调用就变得非常重要。在90年代后期,这不仅是WebGIS领域面临的问题和需求,也是整个信息技术行业的需求,当时的MicroSoft、Oracle、IBM、万维网联盟(W3C)等机构都展开了对这方面的探索,研究发布了Web服务技术。

近年来,Web服务的技术不断改进,其定义也发生了变化。早期Web服务的定义大都涉及SOAP、XML和WSDL技术,现在SOAP已经不再是实现Web服务的唯一方式,REST风格的Web服务扩展了Web服务的概念。

Web服务是一种运行于Web服务器上的程序,它们具有可以被别的程序通过互联网协议(主要是HTTP)来调用的编程接口。Web服务技术代表了分布式计算的重要进展,它用远程服务器上的功能来代替本地计算机上的功能。

可以这样理解Web服务:桌面软件由一系列共同运行的本地程序构成,假定这些程序分布和运行于不同的Web服务器中,但它们之间仍然能够通信,并作为一个整体进行工作----这就是Web服务的初衷。

对Web网页和Web服务的比较有助于理解Web服务。Web服务与一般的网页不同:

  • 网页是供人理解和阅读的,主要采用HTML格式,它包含内容和样式(字体大小和颜色、页面的布局……)等。
  • Web服务是一种基于Web的编程组件,它是供客户计算机程序来调用的。 它的结果主要采用XML或JSON等计算机程序能自动解析的格式,而不是供人直接阅读的。

完整的Web服务体系有三个部分:提供者、使用者和门户网站。服务提供者和使用者不必知道对方的存在。提供者可以把自己的Web服务信息注册登记到门户网站中,而使用者可以查询到这个门户网站,找到需要的服务,然后使用这些服务(下图)。

Web服务体系的三个组成部分及其相互关系

Web服务继承了Web程序和开发接口这两者的特性,与传统计算方式比,具有以下优势:

(1) 开放性

Web服务可以和Web上其他计算机软件交互,供其他系统调用,进行功能和信息的交换和共享,打破了早期Web应用孤立封闭的局限。

(2) 独立于编程语言和操作系统

Web服务是以Web为平台,以HTTP协议被远程调用的,它不和调用它的客户端程序一起编译。一个Web服务不管是使用什么编程语言开发的(如 Java、.NET或C++等)、部署在什么样的操作系统上(如Windows、Linux或MacOS等)、运行在什么样的Web应用服务器里(如IIS或Apache/Tomcat等),都能一样地被客户机所调用。客户机在调用一个Web服务时也没有被绑定任何编程语言,开发者可以自由选择.NET、Java、Python、JavaScript、Flex 或Silverlight 等开发语言。

(3) 松散耦合式的可集成性

客户软件和它所调用的Web服务不必运行在一个机器上,两者不必一定依赖对方而存在。当一个客户机对某一个Web服务不满意或者这个Web服务不能使用时,客户机可以用其他Web服务来代替它。只要这两个Web服务的接口相同,客户机仅需要指向这个新的Web服务的URL,而无需做其他改动。从Web服务提供者的角度讲,他可以改变或更新Web服务,如从J2EE迁移到.NET或者是相反的迁移,只要保持Web服务的接口不变,这些改变对调用者都是透明的,调用者不需要做任何改动(柴晓路,2002)。这 种松散耦合的特点便于进行灵活的组合和套嵌,满足用户的业务需要。

(4) 发布和更新的统一性

当Web服务更新或发布新的版本时,只需要在服务器端更新,每个客户端程序调用到的自然是最新的Web服务,这样就不必到每个客户端分别进行软件包的安装和更新。这是Web服务优于桌面组件技术的一个重要方面。

地理空间Web服务的影响

目前,Web服务已经成为GIS的核心,它的出现对地理空间产业产生了很大的影响,为实现地理空间信息共享、互操作和跨部门协同合作提供了一个优秀的解决方案。

(1) 是WebGIS产品分化和新市场形成的加速器

以Web服务为中心,地理信息界发布了新的产品或新的功能,来实现地理资源的制作(author)、服务的发布(publish )、服务的发现(discovery)和使用 (use)这一系列的工作流程。

Web服务是WebGIS的核心,WebGIS产品分化为支持地理空间Web服务的创作、发布、注册、查询和使用的多种产品

在服务器方面:如果你拥有大量的数据,你可以成为数据和地图服务的提供者。如果你具有独特的分析模型,你可以将它们作为专业地理处理服务发布。这些服务可以是免费的,也可以按次使用收费。

在客户端方面:如果你擅长开发,你可以选择开发Web服务的桌面客户端或手机客户端,在所支持的服务类型或可用性等方面显示出自己的优势。

在门户网站方面:你可以收集一定区域、一定专题或者符合一定标准的Web服务,把这些信息编目发布,并让需要这些服务的人们能查询。

(2) 是GIS融入主流信息系统的基本组件

在地理Web服务之前,GIS与其他信息系统的集成往往要在“本地”实现,即把地理数据复制到本地,把GIS软件安装到本地,对GIS功能的调用很复杂也很有局限,这些原因多年来一直把GIS限制在一个小圈子里,阻碍着GIS与主流信息系统的无缝集成。地理Web服务隐藏了上述复杂性,其他的信息系统,如企业资源计划(ERP)和客户关系管理(CRM)系统,可以灵活方便地调用和集成远程的地理Web服务,从中获得地图、数据和地理分析功能。Web服务的开放性和灵活性将大大地拓宽GIS的市场。

(3)是实现互操作的一种新途径

GIS应用的挑战之一就是如何实现互操作,即让不同GIS软件厂商的产品能够一起工作。在Web服务技术以前,互操作主要在数据格式层面完成,也就是采用标准机构所制定的交换格式。不同厂家的软件需要能够输入、输出这些格式或直接读写这些数据格式。这种方法往往牵涉到数据的复制和本地软件的安装等,是脱节的和不灵活的。

Web服务使得GIS界可以把互操作提升到基于Web服务的层面,超越数据转换和转换工具的安装这些层面(Bacharach, 2005)。地理信息标准机构,如开放地理空间信息联盟(OGC)和国际标准化组织(ISO ),与时俱进,制定了一系列的Web服务标准。严格遵循这些标准,不同厂商的服务器和客户端之间就可以交叉使用,不必到考虑这些服务是哪家公司的产品发布的,也不必考虑是哪家公司的客户端在使用这些服务。

(4)是实现空间数据基础设施一个重要架构

空间数据基础设施(SDI)指的是地理信息的采集、处理、存储、发布、利用和保护所必需的技术、政策、标准和人力资源的总称。建设区域、国家、全球空间基础设施的关键是标准、共享、协作和协调。

Web服务体系在服务提供者和信息使用者之间建立了一个动态交流和集成的方式,是构建空间基础设施的关键。地理数据等信息可以把数据留在原有单位中,由他们进行数据维护,通过Web服务进行共享,当数据更新时,Web服务也随之更新,保证了Web服务的现势性。例如,一个地方政府可以不断地维护和更新其土地记录,同时把这些信息通过Web服务共享给其他单位。一个公共设施部门可以直接利用这个地图服务作为底图,而不需要去把其地图的原始数据复制安装到本地。另一方面,这个公共设施部门也可以把自己的基础设施信息以Web服务的方式共享给其他政府部门,以便市政府利用该信息进行土地利用规划和审批等业务需要。这种协同方式为不同机构之间的地理信息共享和协作提供了一个新的、灵活的技术框架(Dangermond,2008 ) 。

地理Web服务的功能

地理Web服务按照功能可以分为地图服务、数据服务、分析服务和元数据服务等几类。本节介绍这些服务类型的功能。

地图和要素服务

地图服务是最常见的地理Web服务形式。它允许客户端请求一定地理范围内的地图,它以图像格式,如JPEG、PNG或GIF等格式把地图返回给客户端。

地图服务的地图可以是动态制作的,也可以是预先做好的瓦块。瓦块地图服务可以大大地提高WebGIS应用的运行效率、缩短响应时间,主要用于内容相对静止或者更新频率较低的基础底图或地图。动态地图服务在接到客户端的请求后,从数据库中实时读取数据制作地图,所以尤其适用于数据更新频率较高的地图。地图服务可以是二维的或三维的。三维地图服务,也称为Globe服务,可以将地面高程作为第三维,展现自然地形;还可以将建筑物高度作为第三维,加上建筑表面的纹理模型,表现城市的轮廓或逼真街景;三维地图服务可以展现地形和城市建筑景观。

还可以用某一属性字段的值作为第三维,突出该主题。三维地图服务也可以将某一属性的值作为第三维,突出显示该属性所表达的主题。

三维地图服务需要在三维客户端中显示,用户可以进行缩放和旋转等操作。除了制图之外,地图服务往往还可以支持属性查询、空间查询和动态投影变换等功能。

地理要素服务(feature service)允许Web客户端对服务器端的地理数据库中的矢量地理数据进行读写操作,可以对数据库中地理要素及其坐标进行添加、编辑和删除。如图所示,市民可以在该地图网站上标注,标明他们在何时何地发现过濒临灭绝的鸟类,提供相关的信息,这些信息被存储到服务器端的地理数据库中,便于政府部门划定生态保护区。

要素服务允许设计者快速地在数字地图上勾勒出设计草图,并同时分享他们的方案,允许其他同事对之进行修改,能够有效地支持协同式的地理设计。要素服务还便于公众在Web地图上进行标注,分享他们的所见所闻,

促进公众参与地理信息系统(PPGIS)和自发式地理信息的发展。

搜索服务能够对GIS资源(例如,一个数据层或者整个企业地理数据库)的内容进行索引,并让Web用户可以通过关键字等方式查询搜索自己需要的GIS资源。搜索服务与本节后面将要介绍的元数据目录服务不同,虽然两者都可以支持GIS资源的搜索和发现,但前者索引的是地理数据本身,尤其是属性表,而元数据目录服务依赖的是地理数据的元数据。

影像服务主要是通过Web服务来提供栅格数据(如遥感影像和数字高程)。它支持栅格数据的提取、下载以及地图制作。例如,MapServer 允许遥感部门等把获取的大量影像不经预处理就可以发布成影像服务,并可以进行快速的实时处理,包括拼接、增强和衍生出多种影像产品,供Web客户端进行浏览和下载。

分析服务

地理编码服务:地理编码是把街道地址转换成地理坐标的一个过程。与之对应,反向地理编码是把地理坐标转换成相应的地址的一个过程。地理编码服务是以Web的形式发布地理编码或反向地理编码功能。目前,网上有许多免费的地理编码服务,如ArcGIS Online、Google、Microsoft等提供的服务。在有些情况下,如Google等免费系统中的地址数据过时或你希望能通过当地人所知道的地址别名进行匹配,你可以用ArcGIS Sever等产品来创建自己的地理编码服务。

网络分析服务:地理网络这里是指诸如街道和高速公路等组成的交通网,地下管线、管线接头、阀门开关所组织的管线网等。

网络分析服务可以提供以下功能:

1.计算最佳路径:给定起点和终点,计算从起点到终点的最短或最快路径,或者给定多个站点,计算能够走遍它们的最短或最快路径。路径服务应当考虑限速和转向规则,还可以考虑交通阻塞、交通信号灯等待时间和道路(因施工或事故)关闭等因素。

2.计算服务区:计算从某一个或多个点出发,在一定的行驶时间内所能到达的街区。服务区分析可以帮助用户评估一个地点的覆盖性或可达性,例如,可以帮助城市规划者选择最佳的消防站地址,以便它能在数分钟内覆盖指定的区域,或者帮助零售商选择最佳的商店地址,以便它能够服务较多的潜在顾客。

3.查找最近的设施:查找距离某点距离最近或开车时间最少的设施。这在基于位置的服务(LBS)中比较常用,如查找距某一手机用户最近的餐馆或者邮局。

4.几何服务:它可以进行几何变换、缓冲区计算、制图综合(要素化简)、地理要素的合并、切割、计算面积和长度及坐标投影转换等。

5.地理处理服务:地理处理服务可以把用户创建的多种功能和分析模型发布成Web服务。地理处理服务的功能很广泛,从简单的缓冲区分析和面叠加分析到复杂的回归分析和影像分类,从本地社区规划到全球气候变化分析,从模拟过去到预测未来。

元数据目录服务

元数据是关于数据的数据,它可以描述GIS数据和服务。元数据目录服务可以用于发布和搜索元数据,可以促进地理信息和服务的共享。例如,一个提供者可以发布关于他们数据和服务的元数据,而一个用户可以查询这一元数据服务,发现能满足其需要的数据和服务。

Web服务的接口类型

本节介绍Web服务的两种主要接口类型,即SOAP风格的Web服务和REST风格的Web服务,它们也被称为SOAP API和REST API。需要强调的是,Web服务并不局限于这两种类型,那些通过HTTP传送格式化数据的Web程序,都应该被认为是Web服务。

SOAP风格的Web服务

SOAP的原名是简单对象访问协议(Simple Object Access Protocol),它使用一种封装过的XML进行信息交换。2003年,它被万维网联盟采用,成为一种推荐标准。后来大家认为“简单对象访问协议”这个全名容易让人误解,因此,万维网联盟在2007年放弃了这个全名,现在人们只是沿用SOAP这个简称而已。SOAP风格的Web服务采用HTTP Post和SOAP封装的XML在客户端和服务器之间发送请求和传递结果。

基于SOAP的Web服务依靠HTTP Post和SOAP封装的XML在客户端和服务器之间发送请求和传递结果

基于SOAP的Web服务把XML信息体封装在另外一个XML 文档中。这种“XML套XML”的格式不便于人们手工创建SOAP请求和解析SOAP结果,因此SOAP服务的调用比较困难。当然,有一些工具可简化SOAP服务的调用。基于SOAP 的 Web 服务一般具有 WSDL( Web Service Description Language),即网络服务描述语言。它以XML的格式来描述一个Web服务所提供的具体编程接口,便于开发人员理解和使用这个Web服务。

REST风格的Web服务

REST(representational state transfer;表述性状态转移或表象状态转移) 是Roy Fielding于2000年在其博士毕业论文中所提出的一种架构风格。Roy Fielding曾经参与过HTTP规范的制定,他认为SOAP没有充分利用HTTP的优势,他提出的这种REST风格的构架可以充分发挥HTTP的优点,降低开发的复杂性,提高系统的扩展性(Richardson and Ruby,2007)。REST刚被提出时没有获得过多关注,其概念和准则比较抽象,不同人的解释也不尽相同,在现实应用中并没有被完全遵守或实现。REST风格的Web服务通过HTTP发送数据,所发送的信息不采用SOAP封装。其最常见的实现方式是把请求的参数放在URL中,通过URL发送请求参数。REST风格的Web服务经常以JSON和不经SOAP封装的XML向客户端返回结果。下图显示的用REST的形式来实现上图中相同的功能,可以看出,REST接口比SOAP接口更加简洁。

REST接口的服务

可以看出,这种目录式结构的URL层次直观、可预测且易于理解,不需要过多的文档,开发人员可以很容易地构建这些URL,指向他们所需要的Web资源。

REST服务中Web资源支持特定的操作,例如,一个地图服务可以进行制图和查询操作,地图服务中单个数据层可以进行查询操作。这些操作的结果可以JSON等格式返回给客户端。例如,通过REST接口请求某地图服务制作一幅美国地图,要求返回 800x500 像素的JPEG图像,URL请求大致是

http://server.mycompany.com/ArcGIS/rest/services/QSMap/MapServer/
export?
bbox=-185.33, 15.20, -9 .53 , 74 .08
&size=800 , 500
&format=jpg
&dpi=96
&f=image

利用REST来查询一个地图服务中加利福尼亚州每个县的中等家庭收入,要求返回JSON格式,URL请求大致是:

http://server.mycoinpany.com/ArcGIS/rest/services/USMap/MapServer/0/query?where=STATE_NAME='California'&OutFields=MEDHINC_CY&f=pjson

可以看出,REST中基本上所有的请求都是一个URL,比较容易理解。你可以采用很多种编程语言,如.NET、Java JavaScript和Flex等来产生这个URL字符串并发送这个URL请求。你甚至可以不用编程,直接把这个URL放到你的Web浏览器中就可以看到你要的地图等结果,因此,REST被认为是“Web的命令行”。

SOAP 和 REST 的比较

下面比较了 SOAP和REST类型的Web服务。SOAP类型的Web服务产生早,相关技术比较成熟,使用比较普遍,其接口定义明确而严谨,开发环境对其支持程度高。但它过于复杂,编程工作量和难度较大;没有充分利用HTTP的优势,传输效率低;SOAP的封装使传递的XML复杂和庞大,这样往往会降低信息传递和解析的效率乃至整个系统的性能。鉴于这些认识,人们逐渐转向了REST风格的Web服务,它简单而高效(Cappelaereet al.,2007)。在很多情况下,REST的简洁和高效胜过了采用SOAP所带来的严谨(Fu et al. ,2008)。

比较SOAP类型的Web服务和REST类型的Web服务

SOAP类型的Web服务

  • 传输方式,HTTP POST ;
  • 请求参数,放在XML中并以SOAP封装;
  • 响应结果,放在XML中并以SOAP封装 ;
  • 优点,产生早、成熟,接口严谨,功能 强大;
  • 缺点,重型、复杂、人门门槛高;SOAP 封装的XML信息传输效率和 解析效率低;不能充分利用 HTTP的优势, 不够严谨、略显随意。

REST类型的Web服务

  • 主要是HTTP GET;虽然定义了 PUT、P0ST和 DELETE的语义和用法,但实际上很少使用;
  • 参数(键-值对)一般放在 URL 中;
  • 比较多样,JSON、XML(非SOAP封装的)和二进制文件流等;
  • 轻型、简易、效率高,能充分利用Web的缓存 等优势,使用逐渐广泛;
  • 对服务提供商来说,可以降低创建服务的成本以及服务托管的经费;
  • 对基于Web服务做应用开发的开发者来说,可以减少人门难度、缩短学习时间、加快开发速度、降低开发费用;
  • 对管理者来说,REST提供了较好的系统架构,能获得较高的系统响应速度、较高的可靠性和可扩展性。