4.2. Web资源的类型

4.2.1. 浏览器端API #

具有浏览器端API的Web资源比较容易聚合，是目前聚合应用中最受欢迎的一类接口。 该类接口有好几种形式， 包括JavaScript API、FlexAPI、SilverlightAPI和Web微件。 JavaScript是互联网上应用最广泛的编程语言。配合像Dojo这样的工具包，JavaScript支持复杂的图形显示和用户交互（图4. 6)。 Flex和Silverlight API具有优良的图形支持、动画效果和灵活的用户交互性能，能提供良好的用户体验，特别适用于开发富互联网应用。

表4. 1比较了浏览器端的API和Web服务，前者比后者更易于使用，便于更快地构建WebGIS应用。 如图4. 7所示,Web服务的功能仅限于服务器端，而对浏览器端的用户交互任务则鞭长莫及， 无法解决诸如监测用户鼠标事件、计算地图参数、发送请求、接收响应结果、解析结果和显示地图等客户端的任务。 浏览器端的API却能胜任这些工作，它能与用户互动，当用户拖动地图时， 浏览器端的API能自动检测用户鼠标的移动，计算新的地图范围， 向后台的Web服务发出请求,收到服务器端的响应结果后，解析结果，显示地图， 而且这个过程是在用户不知不觉中完成的。 所以浏览器端的API —方面解决了与Web服务的互动，另一方面又能很方便地与用户互动。 用一个比喻:Web服务像后台的厨师，而浏览器端API就像上菜的服务员，他把你的要求转达给厨师， 再为你奉上已做好的菜肴。

很多机构通过浏览器端的API提供他们的Web资源如众所周知的谷歌公司和微软公司的街道图、影像图、地址与地点定位、路径分析等功能。 EsriArc- GIS Online提供更多样的地图和专题图。 用户还可以利用ArcGIS forServer来发布自己的地图服务或分析服务， 这些资源也自动具有浏览器端的API,可以方便地调用。

表4.1 Web服务与浏览器端API比较

针对聚合设计模式中的基础底图、业务图层与任务这三个部分(见第2. 3. 3节）， ArcGIS的浏览器端API提供了相对应的类。

• 地图:对应于基础底图（有时也可用于展示可操作图层）， 支持ArcGIS forServer制作的动态地图和瓦块地图、Microsoft Bing Maps、WMS、WMTS 、&&KML等。 地图类内置有鼠标与键盘事件的侦听功能，能方便地实现地图与用户之间的交互操作。

• 图形:通常用于表达可操作图层，包括查询与分析的结果。图形是矢量的， 具有坐标和属性，能以某种符号显示，也能以小窗口或弹出窗口的形式显示详细信息，见公式(4.1)。 图形的坐标和属性被下载到浏览器端,其显示符号可以在服务器端指定(如继承该服务的MXD中的符号）， 也可以由浏览器端的程序指定。浏览器端的程序可以根据单个属性或多个属性来显示图形， 如,用动画图标显示飞行中的直升机、把地震按震级分类，用饼状图显示各州各民族的百分比， 也可以把相互邻近的点综合显示为群簇，还可以用热度图表示点的分布密度（图4.8)。 图形能快捷地与用户交互，当用户鼠标扑捉或点击时，能迅速弹出信息窗口， 显示属性、图表、照片、音频、视频或HTML链接等。值得注意的是， 浏览器端能同时显示的矢量图形数量是有限的，大致在数千个左右，超过这个限制后， 浏览器的性能就降低。如果可操作图层的数据量很大， 可以采用比例尺依赖（即只在放大到一定比例尺时才显示该业务图层)或采用地图类(包括瓦块地图和动态地图）。

（A)根据某属性值进行分类， 用不同大小或不同颜色的符号来显示；（B)用饼状图显示多个属性，如各民族的人口比重； (C)把相互邻近的点显示为点簇(cluster);(D)使用热度地图表达点的密度分布。 (致谢:美国国家公园管理局、 美国地质调查局 和美国人口普查局）

• 任务：即浏览器与后端ArcGIS Server交互，执行查询、编辑、地理编码、 路径分析和几何投影等地理处理任务（图4. 9)。

Web微件(Web widget)进一步简化了聚合应用开发。它是易于嵌入网页的短代码，它封装了若干行HTML和JavaScript代码，也有基于Flex或MicrosoftSilverlight的微件。 图4.10显示ArcGIS. com所产生的一个微件，它只有几行简单的HTML源代码， 把它嵌入到一个HTML网页中，该网页中就可以显示一个来自ArcGIS. com的地图应用。

<iframe width = " 500 " height =" 400 " frameborder = " 0 " scrolling
="no"
marginheight = "0 " marginwidth = "0 "
<iframe widt^^»"500,, heiQht»"400" frameborder^O" scrbHrng="non'marg^
imarginwidth»"0”src*"http://www.arc〇is，com;tiome/webmap/embedViewer.html?

4.2.2. 移动平台的API #

ArcGIS为智能手机和平板电脑也提供了开发接口。其原理类似浏览器端的接口，也是能调用和组合ArcGIS Server或ArcGIS Online中的Web服务，这些接口也能通过触摸屏与用户交互。值得一提的是，这些针对移动平台的接口需要采用Object C、C#或Java等语言，比上述浏览器端的接口难度略大，但能实现时尚的移动应用界面，获得良好的用户体验(详见第5. 3节）。

4.2.3. 幕后英雄Web服务 #

在聚合这一舞台上，浏览器端的API拥有大部分的光环，但是它的许多优势来自于幕后的Web服务。 Web服务有SOAP和REST两种风格，其中REST风格的Web服务能较好地利用Web的优势，效率较高。 浏览器端的API主要是建立于REST风格的Web服务之上的。

地理信息门户网站如ArcGIS. com上发布有数以千计的Web服务，可以供用户查询和使用。 如果Web上没有自己所需要的资源可用，组织机构可以使用自己的数据发布自己的Web服务。 政府机构如 美国地质调查局 、美国国家海洋与大气管理局和美国环境保护局等， 就发布了很多很有应用价值的Web服务。 企业和科研单位也是重要的Web服务提供者。 值得一提的是GeoNames把RSS转为GeoRSS的Web服务，对于 地理聚合 应用是非常有用的。 RSS文档（见第3.4节）通常包含实时信息，但一般没有地理坐标，因此难以直接用于GIS。 GeoNames这个将RSS转换为GeoRSS的Web服务，能从RSS中提取地址和地名，找到其经纬度，然后将坐标补充到RSS中，生成GeoRSS。例如，美国疾病控制与预防中心有一个RSS报告有关大肠杆菌传染和发病的最新事件（ http://www2c.cdc.gov/podcasts/createrss.asp?t=r&c=280 )。 如果你想把这些事件显7K在地图上，你可利用上述GeoNames的Web服务， URL为 http://ws.geonames.org/rssToGeoRSS?feedUrl=http//www2c.cdc.gov/podcasts/creat-erss.asp ?t=r&c=280 ,就可以得到具有坐标的GeoRSS格式， 从而可以把它聚 合到WebGIS之中。

4.2.4. 无正式接口的Web资源 #

万维网上有数以亿计的HTML网页，它们是万维网上最主要的资源， 这些海量的网页中有很多有价值的信息可以综合到其他的应用系统之中。 但是，HTML网页是供人阅读和理解的， 它们混合了内容和样式（如字体大小和颜色、页面的布局等）（图4.11),不具有正式的编程接口， 从中抽取信息比较困难，需要开发人员仔细分析这些网页的HTML代码，从中寻找字符的规律。 编写针对性的程序，对HTML源代码字符串进行处理，从中抓取信息，这种方法被称为屏幕抓取或抓屏。 如果从Web抓取得到的内容中没有地理坐标，还需要对这些内容进行地理解析(见第10.1.4节）， 从中提取出地址或地名，进行地址匹配或地名查找，转换为坐标。

Web抓取与地理解析功能通常需要在服务器端开发完成,原因是这一过程很复杂，轻量级编程语言难以胜任。另外，在服务端处理,只需处理一次，所有的浏览器都可使用这个结果。 网络抓取与地理解析的结果往往采用XML(如GeoRSS) JS0N或其他结构化格式，便于聚合使用。

抓屏通常被认为是一个不雅的解决方案。 原因之一是没有通用的抓屏工具，开发者往往要针对每一个或每一类Web资源的特定情况编写针对性的程序， 这个程序也不具有通用性。 一旦Web资源有所改变，有时即使是外观的改变或者只是增添了一个空格，原来的抓屏程序就有可能不再适用。 原因之二是没有提供编程接口的网站往往没有考虑到或者不希望被其他网站二次开发所利用， 这样调用者和提供者之间的服务关系不很清晰，有时还可能产生纠纷。