OpenLayer源代码总体结构分析
通过前面的项目介绍，我们大概已经知道 Openlayers是什么，能够做什么，有什么意义。接下来我们分析它怎么样，以及怎样实现的等问题。
这个图是从它的文档上截取的，旨在从感官上认识一下OpenLayers的类。下面分别介绍（文档中的类是按字母顺序排列的，也按这个顺序说吧）：
我们看到在类的顶层“高高在上”的是OpenLayers，它为整个项目实现提供名称空间（JavaScript语言没有名称空间一说，但是它确实有自己的机制实现类似的功能，后面会说明），它直接拥有一常量
VERSION_NUMBER，以标识版本。
Ajax：顾名思义，用于实现Ajax功能，只是OpenLayers的开发者们把它单独写到一个类里了，其中用到了Prototype.js框架里的一些东西。同时，设计的时候也考虑了跨浏览器的问题。
BaseTypes：这里定制了OpenLayers中用到的 string，number 和
function。比如，OpenLayers. String. startsWith，用于测试一个字符串是否一以另一个字符串开头；OpenLayers. Number. limitSigDigs，用于限制整数的有效数位；OpenLayers.
Function.bind，用于把某一函数绑定于对象等等。
Console： OpenLayers.Console，此名称空间用于调试和把错误等输出到“控制台”上，需要结合使用../Firebug/firebug.js。
Control：我们通常所说的控件类，它提供各种各样的控件，比如上节中说的图层开关 LayerSwitcher，编辑工具条EditingToolbar等等。加载控件的例子：
class = newOpenLayers.Map(‘map’, { controls: [] });
map.addControl(new OpenLayers.Control.PanZoomBar());
map.addControl(new OpenLayers.Control.MouseToolbar());
Events：用于实现OpenLayers的事件机制。具体来说， OpenLayers中的事件分为两种，一种是浏览器事件，例如mouseup,mousedown之类的；另外一种是自定义的，如addLayer之类的。 OpenLayers中的事件机制是非常值得我们学习的，后面将具体讨论。
Feature：我们知道：Feature是 geography 和attributes的集合。在OpenLayers中，特别地OpenLayers.Feature 类由一个marker 和一个lonla组成。
OpenLayers. Feature.WFS与OpenLayers. Feature. Vector继承于它。
Format：此类用于读／写各种格式的数据，它的子类都分别创建了各个格式的解析器。这些格式有： XML、 GML、GeoJSON 、 GeoRSS、JSON、KML 、WFS、WKT(
Well-Known Text )。
Geometry：怎么翻译呢，几何？是对地理对象的描述。它的子类有Collection、Curve、LinearRing、LineString、MultiLineString、MultiPoint、MultiPolygon、Point、Polygon、Rectangle、Surface，正是这些类的实例，构成了我们看到的地图。需要说明的是， Surface 类暂时还没有实现。
Handler：这个类用于处理序列事件，可被激活和取消。同时，它也有命名类似于浏览器事件的方法。当一个 handler 被激活，处理事件的方法就会被注册到浏览器监听器listener ，以响应相应的事件；当一个handler被取消，这些方法在事件监听器中也会相应的被取消注册。Handler通过控件control被创建，而control通过icon表现。
Icon：在计算机屏幕上以图标的形式呈现，有url、尺寸size和位置position３个属性。一般情况，它与
OpenLayers.Marker结合应用，表现为一个 Marker。
Layer：图层。
Map：网业中动态地图。它就像容器，可向里面添加图层Layer和控件Control。实际上，单个Map是毫无意义的，正是Layer和Control成就了它。
Marker：它的实例是 OpenLayers.LonLat 和OpenLayers.Icon的集合。通俗一点儿说， Icon附上一定的经纬度就是Marker。
它们的组合关系是：
Popup：地图上一个小巧的层，实现地图“开关”功能。使用例子：
Class = new OpenLayers.Popup(“chicken”,
new OpenLayers.LonLat(5,40),
new OpenLayers.Size(200,200),
“example popup”,
true);
map.addPopup(popup);
Renderer ：渲染类。在OpenLayers中，渲染功能是作为矢量图层的一个属性存在的，我们称之为渲染器，矢量图层就是通过这个渲染器提供的方法将矢量数据显示出来。以SVG 和VML为例，继承关系是这样的：
至于 OpenLayers. Renderer. Elements为什么要存在，以及它的渲染机制，后面会说。
Tile：设计这个类用于指明单个“瓦片”Tile，或者更小的分辨率。Tiles存储它们自身的信息，比如url和size等。它的类继承关系如下：
Util：“ 跑龙套”的类。
写到这里，可以看到OpenLayers 的类缠绕的挺麻烦的，接下来的文章将从代码部分分析更细部的东西。
2月26日 6:02 | 添加评论 | 固定链接 |写入日志 | GIS
五个基于Google Earth的小游戏
Google Earth是互联网巨头Google公司于2005年推出的一款虚拟地球仪软件，它把卫星照片、航空照相和地理信息系统布置在一个地球的三维模型上，使用者可以通过这个软件浏览全球各地的高清晰度卫星图片。自这项服务问世以来，深受广大网友的喜爱，给人们的生活带来了很多方便。Google
Earth不仅仅是一个有用的卫星地图软件，由于其开放了Google Maps API，于是产生了很多基于Google
Earth的第三方应用，其中有一些是一些有趣的游戏，可以大为加强Google Earth的趣味性，让大家在玩乐之中轻松掌握了Google Earth的使用方法，这里我就介绍一些有趣的基于Google
Earth和Google Maps的小游戏，供大家参考。
Google Earth上有很多未解之谜，也有很多引人入胜的图片，这个游戏的任务是在Google Earth卫星地图上找到某个指定的地点，系统会随机显示一个世界上某个独特景观的卫星图片，并给出一些提示信息，根据这些提示信息，用户可以在卫星地图上去搜索这个地点，挑战自己的地理常识，当用户把经度和纬度移动到该景观附近，并且显示放大比率相同，则算赢得了这次游戏的胜利。
这个游戏的难度非常大，可以说同时挑战了用户的地理常识和卫星地图查看能力，通常只有卫星图片专家才有可能轻松的玩过这个游戏的每一关。
Google Earth解谜游戏的地址是：http://www.williamlong.info/google/earth/
这是Google Earth内置的一个小游戏，打开Google Earth，然后按Ctrl+Alt+A，就会看到一个让你选择两架飞机的对话框，选择一个飞机和机场位置后，就可以进入这个模拟飞行游戏了。游戏完全是在真实的卫星地图上飞行，视角是飞机驾驶舱的视角，和通常的模拟飞行游戏挺像，不过操作起来还是挺困难的，对于网速的要求较高，低速的网络玩起来比较卡。
这个游戏将带我们进入神秘的海底世界，我们可以模拟潜水艇（或者是模拟鲨鱼），在世界各个地区海底进行模拟旅行。目前已经发布了6个地方：加利福尼亚、直布罗陀海峡、希腊、马利亚纳群岛海沟、美国沃尔基海域的深海探险和罗曼西海沟探秘。操作的方法是，点击页面左下角的Run/Pause，就可以开始或者暂停，Speed按钮用来调节浏览速度，使用左右键可以转向，使用上下键控制深度。另外，这个网站也提供了另外一个版本的模拟飞行的游戏。
Google Earth模拟海底潜水艇游戏的地址：http://www.sea-seek.com/
请不要误会，这不是另一个Google Earth的模拟飞行游戏，而是一个有趣的Google Earth查看应用，点击下载这个直升飞机地标，就可以从直升飞机里面观察卫星地图。飞机的窗户都是透明的，所以这时候的Google
Earth看上去就像是从直升飞机里面望向窗外一样，这是一个非常酷的显示效果。
Google Earth模拟直升飞机下载地址：http://bbs.keyhole.com/ubb/download.php?Number=987400
这又是一个基于Google地图的小游戏，可以在Google地图上模拟驾车，在全球各个角落上飙车，我们可以在自己熟悉的城市和熟悉的街道上四处开车。玩家可以指定的城市名称，然后开始模拟驾驶，用户可以选择不同的车型，操作非常简单，四个方向箭头来控制，拐弯有些困难，不是很好操作，车辆也太小，看不太清楚。
Google Earth的模拟赛车游戏的地址：http://geoquake.jp/en/webgame/DrivingSimulatorGM/
好了，以上就是我介绍的一些有趣的Google Earth小游戏，如果大家还知道什么其他的Google
Earth游戏，请留言告诉我。
2月23日 9:35 | 添加评论 | 固定链接 |写入日志 | GIS
Google推出GoogleMaps地图版大富翁游戏
据报道，Google将与美国孩之宝（Hasbro）合作，于美国当地时间9月9日推出一款名为MonopolyCityStreets（地产大亨：街道）的桌面游戏Monopoly（地产大亨）的Google地图版。
据悉，这款游戏完全基于Google Maps地图，游戏的名称将定为“大富翁城市风云（Monopoly
City Streets）”，玩家可以在游戏中购买全球任何国家任何城市的一条街道，建立大厦或酒店，根据游戏发展从而成为世界上最富有的人。
消息称，玩家的初始游戏资金是300万Monopoly币，其中购买美国华盛顿宾夕法尼亚大道（白宫门前）的价格约为200万，而英国唐宁街的价格为231万，街道根据建筑物不同租金不同，小楼房至摩天大楼的租金费用从5万元至1亿元不等。
该游戏官方网站上目前写道：9月9日，一个以无法想象的规模建立的地产世界即将呈现在你眼前！地产大亨将推出基于Google地图服务的网络版游戏。游戏目标很简单，参与竞争打败你的朋友和任何人，成为全球最富有的地产巨头。
2月23日 9:34 | 添加评论 | 固定链接 |写入日志 | GIS
地图应用是一项热门的网络服务，很多本地信息类网站，比如旅游，房屋租赁，餐饮信息等，都是使用Google Maps API来实现地图服务的，那么这些地图类网站如何通过地图服务来获取收益呢？可以通过Google
AdSense for Maps来实现地图广告显示。
Google AdSense for Maps有两种广告显示格式，一种是搜索类广告，一种是内容类广告，这很类似于Google的搜索联盟和内容广告。Google在地图API的文档中讲述了这两类地图广告的代码设置方法。
1、搜索类广告
这类广告是在搜索内容结果中显示广告，需要使用GoogleBar的功能，首先将你的publisher ID放在client内容里，然后将渠道的id号码放在channel中，下面是一个通过GoogleBar实现地图搜索广告的代码，在实际使用的时候，你要将你的publisher
ID替换代码里的client内容。
var map;
if (GBrowserIsCompatible()) {
var mapOptions = {
googleBarOptions : {
style : “new”,
adsOptions: {
client:”partner-google-maps-api”,
channel: “AdSense for Searchchannel“,
adsafe: “high”,
language: “en”
}
}
}
map = new GMap2(document.getElementById(“map_canvas”),mapOptions);
map.setCenter(new GLatLng(33.956461,-118.396225), 13);
map.setUIToDefault();
map.enableGoogleBar();
}
点击这里查看该广告详细的参数含义（英文）。
2、内容类广告
这类广告在地图上显示一个类似AdSense内容类的文字广告，广告使用了GAdsManager结构，你要将你的publisher
ID和channel ID加入到GAdsManager，就可以显示广告，目前这类广告的样式似乎无法自定义，下面是内容类地图广告的演示代码。
var publisher_id = yourPublisherID;
var adsManagerOptions = {
maxAdsOnMap : 2,
style: ‘adunit’,
// The channel field is optional – replace this field with a channel number
// for Google AdSense tracking
channel: ‘your_channel_id‘
};
adsManager = new GAdsManager(map, publisher_id, adsManagerOptions);
adsManager.enable();
点击这里查看该广告详细的参数含义（英文）。
上图是该广告的实际显示效果，该广告的背景色是淡蓝色，无法调整，广告尺寸也无法调整，感觉样式不是特别好看，广告内容好像是和地理坐标位置相匹配，例如在深圳上海宾馆的坐标，就显示服装批发和订票等广告。目前只有文字广告，没有看到多媒体广告。
2月23日 9:19 | 添加评论 | 固定链接 |写入日志 | GIS
2. GIS平台软件技术发展展望
组件化、Web化、微型化和数据库化深刻影响了过去十年的GIS应用方式，也成为当前GIS应用的主旋律，特别是在GIS平台选型中，以上“四化”带来的相关技术已逐渐被大家理解和接受。
然而GIS技术发展一日千里，当“四化”大行其道的时候，一些新的趋势正在形成。提前理解和认识到这些技术趋势，将有利于在下一步GIS平台和技术方案选型中做出做出有预见性的决策，避免造成日后不必要的浪费，同时有利于占领新的技术高地和应用市场。
本文所谈及的发展趋势，是从产业化应用的角度出发，而非仅仅是研究视角的延伸与反刍。也就是说，那些在短期内还不能达到大规模推广应用的产业化要求的研究热点，不在本文讨论之列；相反，后文中将要谈到的发展趋势，若从研究和研发角度来看，从几年前可能就已经开始显现。
从软件技术角度来看，GIS平台软件新的发展趋势包括跨平台化、组件多样化、服务化和三维化几个方面。
2.1. 跨平台化
在以客户端为功能重心的GIS应用时代，服务器主要用于空间数据库管理，GIS平台的大部分功能则主要在客户端上实现。过去十多年来，客户端计算机的操作系统是Windows一统天下的格局。从二十世纪九十年代中期开始，主要的GIS厂商大都经历了一个GIS平台软件从Unix到Windows的移植过程，还没来得及完成移植工作的个别品牌已惨遭淘汰，Windows顺理成章地成了GIS平台的主要操作系统。
伴随着Web GIS应用的大范围普及以及Service GIS技术的迅速崛起，GIS应用的功能重心从客户端向服务器端偏移，以服务器计算(Server
Computing)为主的GIS应用格局正在形成。这种应用格局对GIS软件的跨平台能力提出了强烈的需求。
据 IDC报告，2005年不同操作系统服务器市场份额分别为：Windows
39.1%、Unix 38.6%、Linux 11.7%以及其他 10.6%。服务器操作系统形成Windows、Unix和Linux三足鼎立的局面，其中非Windows服务器所占比例仍高达60%以上。
在以客户端为GIS功能重心时代，主流GIS厂商把GIS迁移到Windows上，当GIS功能重心转移到服务器上时，多数GIS平台都还没有做好跨平台的准备，GIS厂商不得不引导用户使用Windows作为GIS服务器。但近几年来，跨平台已经成为GIS软件技术不得不面对的发展趋势，更为重要的是，GIS的高端服务器如小型机，通常采用像IBM
AIX、 HP UX和SUN Solaris等的Unix，另外一部分则采用Linux。因此，若不能友好地支持Unix和Linux，GIS平台厂商将失去进军高端市场的机会。
如何实现跨平台，对GIS平台软件厂商而言，是个不小的挑战。因为GIS厂商已经在Windows上投入了大量人力和财力，如果放弃这些代码，重新开发包括桌面GIS、组件式GIS、Web
GIS和Service GIS在内的一系列跨平台GIS软件，代价将十分巨大。就中国GIS企业而言，完成整个体系的调整可能意味着上亿元人民币的投资，对美国企业而言这个数字将是上亿美元，而且至少需要4~5年才能完成。
那么有没有一种既能保护以往在Windows上的投资又能实现跨平台应用的办法呢？一些专门从事代码迁移工作的公司提供了这样的策略：通过软件工具，把基于Windows的Visual
C++的代码迁移到Unix或Linux上，充分利用在Windows上已有的庞大代码资产，从而以较小的代价实现跨平台。例如，有些GIS平台厂商就在第三方的代码迁移工具支持下，把整个基于COM的组件式GIS，移植到了Unix和Linux上。
尽管从理论上讲，一些基本的C++ 代码移植到Unix和Linux上进行本地编译后的效率很高，但事实上同样的C++代码在不同操作系统上还需要进行针对性的性能优化。因此依赖于第三方的移植，在效率上仍然大打折扣。而且，移植后的组件式GIS软件将在一个第三方的运行库(Runtime)基础上运行。由于这个运行环境要负责在Unix和 Linux上实现COM/DCOM、ATL、WinSock这些Windows原生技术，所以在性能上具有不可掌控的明显损失，这对GIS这类计算密集型的软件而言，是难以接受的。再者，这种跨平台的策略究竟支持哪些操作系统，还受制于第三方的代码迁移技术，不能由GIS厂商自己做主。
鉴于以上原因，超图选择了重写GIS内核的跨平台策略。在继续升级发展基于Windows的GIS软件的同时，超图于2001年开始基于标准C++研发下一代跨平台GIS内核UGC(Universal
GIS Classes)。2005年，超图发布了UGC 1.0，以及基于UGC的跨平台组件式GIS软件和跨平台Web
GIS软件；2007年，超图发布了跨平台GIS产品线2.0版，并新增了跨平台的Service
GIS产品，已经在越来越多的行业得到应用；2009年，超图还将推出跨平台GIS产品线6.0版。近十年的跨平台研发实践证明，重写GIS内核确实是一项代价巨大的工程，但是，相比较于它给用户带来的软件在各个操作系统上的高性能，以及可无限扩展支持其他操作系统方面的能力，这个代价是非常值得的。
2.2. 组件多样化
组件式GIS影响了过去十年的GIS应用开发方式，直到今天，组件式GIS还是胖客户端应用系统的主要开发平台，同时也是Web
GIS和后文将提到的Service GIS的技术基础。目前，组件式GIS技术还在进一步发展。
早期主流的组件式GIS都是基于COM组件技术开发的，但曾经带来GIS技术变革的COM技术也存在诸多不足。因“动态库地狱 (DLL
Hell)”所导致的组件版本冲突，因对象无法继承而导致的二次开发扩展能力局限，甚至有人评价COM不是真正的面向对象技术，这些都影响了基于COM的 GIS技术向更深层次的发展。
为了与Java竞争，微软公司推出了.NET技术和.NET组件技术。.NET组件技术显然比COM更加完善。微软公司也计划逐步用.NET组件技术淘汰COM，并最终将形成Java
Beans组件技术和.NET组件技术并行发展的局面。经过简单封装，原有基于COM的组件式GIS仍然可以在Java和.NET 环境中调用，就延长GIS平台厂商已有COM产品的生命周期而言，这是一个不得已的策略。但基于这种方式提供的不是真正的Java
Beans和.NET组件，其COM内核的局限仍然没有突破，在跨平台问题上它将面临更多困难。
真正能彻底解决问题的方案是基于标准 C++而不是COM编写GIS内核，从更底层封装Java
Beans和.NET组件。超图的SuperMap Objects Java和SuperMap
Objects .NET采用了后一策略。2008年，中国铝业集团的生产应急救援指挥系统采用SuperMap Objects Java进行了开发实施，从而与企业基于Java的MIS应用系统采用了相同的技术路线。可以预见，无论作为独立的应用开发工具，还是作为Service
GIS和Web GIS的技术基础，Java Beans和.NET组件都是未来的方向!
此外，随着Python和Ruby等面向对象的脚本语言的应用发展，基于Python和Ruby的组件式GIS也可能成为未来的发展趋势。
2.3. 服务化
软件工程方法的发展总能带来GIS技术架构的革命，当软件工程方法从面向对象(Objects Oriented)发展到面向组件(Components
Oriented)，就催生了组件式GIS技术。由于面向组件技术允许跨语言复用代码，因此面向组件的GIS技术大幅度提高了应用系统开发效率，应用十分广泛。
面向服务(Service Oriented)，是在面向组件基础上的又一次软件工程方法的革命性升级，与之对应的面向服务的体系架构(Service Oriented Architecture,
SOA)正在逐步成为一种主流的软件工程思想。要在GIS应用系统中成功实现SOA，不仅需要系统架构师按照面向服务的思想来构建系统体系架构，同时还需要GIS平台的良好支持，方可降低应用系统二次开发的工作量。在已有的组件式GIS基础上，研发面向服务的GIS软件开发平台，是GIS应用大规模实践 SOA所必需的。
服务是一种升级的组件，面向服务强调粗粒度和松耦合。粗粒度提高了通过网络远程调用组件(即SOA中的服务)的效率；松耦合则降低了应用系统各模块之间的依赖度，这使得局部的系统修改不会影响更大范围的代码变动和重新部署，提高了代码维护和局部升级的灵活性和效率。因此，面向服务提高了应用系统的业务敏捷(Business
Agility)特性。所谓业务敏捷包含两层含义：第一，信息系统在业务提出变化之后一个恰当的时间段里响应这种变化；第二，信息系统所做出的变化能够恰当地反映出业务的需求。
服务式GIS (Service GIS)，是产生于面向服务软件工程方法的GIS软件技术。Service
GIS脱胎于组件式GIS，是在组件式GIS基础上质的飞跃，也是对组件式GIS顺理成章的升级。在组件式GIS功能强大的组件群基础上，Service
GIS采用面向服务的软件工程方法，把GIS的全部功能封装为Web服务(Web
Service)，从而实现了被多种客户端跨平台、跨网络、跨语言地调用，并具备了服务聚合能力以集成来自其他服务器发布的GIS服务。
Service GIS继承了组件式GIS所具备的一系列优点，如跨语言二次开发、所见即所得的应用开发方式、与其他IT技术集成的强大能力、高度可伸缩性等。除此以外，Service
GIS还具备一些新的特性：
★跨网络集成与应用。Service GIS把组件式GIS 的强大功能扩展到了网络上，通过Web服务开放的所有接口，这些功能都可以在网络上被调用。在这种模式之下，更加容易构建分布式的GIS应用系统。
★业务敏捷。业务敏捷是SOA的真正内涵，也是Service GIS为GIS应用开发领域带来的价值。基于Service
GIS构建应用系统，能够通过聚合与集成已有的服务，快捷地构建新的应用系统或升级已有的应用系统，以满足快速变化的用户需求。
服务是特殊的、更高级别的组件，因此我们也可以说，Service GIS是面向服务的组件式GIS，是更高级别的组件式GIS。尽管Service
GIS与Web GIS看起来都是B/S结构下的GIS应用开发平台，但二者还是具有相当大的差异。从定位上看，Web
GIS侧重于Web开发，主要用于地理信息的发布和共享，用于开发简单的GIS应用系统；而Service
GIS则不局限于Web平台，其客户端可以是桌面应用、Web应用、嵌入式应用甚至3G移动终端等，除了发布和共享地理空间信息外，更重要的是能够通过 Web
Service发布整个GIS平台的功能，能够在更大程度上替代原来组件式GIS才能够完成的应用系统。
Service GIS不仅带来了GIS应用开发的革命性变化，同时也引发了第三代地理信息共享革命，带来了全新的、面向服务的地理信息共享新模式。第三代地理信息共享不仅解决了异构GIS平台之间的共享与集成问题，还提供了数据共享与功能共享并举的独特优势。基于SuperMap
iServer这一Service GIS开发平台，重庆市地理信息中心和西安市信息办正在实施面向服务的数字城市地理信息共享平台。
可以说，Service GIS是专门为GIS应用的SOA实践而生的下一代GIS开发平台。随着SOA在GIS应用领域的进一步推广，Service
GIS将成为影响未来十年应用系统开发的主流GIS软件技术。
2.4. 三维化
近年来，基于虚拟现实技术的三维GIS技术获得了较快地发展，并被应用于规划、房产、测绘、军事等诸多领域。Google Earth和Microsoft
Virtual Earth等三维GIS网络服务的推出，不仅有利于GIS技术的普及，也推进了三维GIS技术在面向个人服务领域的应用。
但总体而言，当前基于虚拟现实技术的三维GIS，其应用水平仅相当于十多年前的二维GIS应用，还停留在可视化阶段，只满足了“看一看”和“查一查”的最基本需求层面，因而有些人把它称为“面子工程”阶段，无法满足高端GIS应用需求，无法解决面向政府、企业、军事的业务管理和辅助决策，阻碍了三维GIS应用推广的步伐。造成这种局面的原因主要有以下两个方面：
★与主流大型二维GIS平台割裂。当前的三维GIS软件与主流大型二维GIS软件在技术底层上存在着相互割裂的现象。三维GIS的应用离不开业已成熟的二维GIS，但由于从数据底层无法实现高效共享与集成，二维GIS强大的分析功能无法通过三维方式得到高效展现。尽管在一些三维软件中可以连接二维GIS的空间数据库，但效率较低。三维GIS与二维GIS的一体化，不仅需要在三维GIS开发方面努力兼容已有的二维GIS，同时，也需要在二维GIS软件技术方面做出必要的改进，才能解决底层割裂带来的应用障碍。
★缺乏高端GIS分析功能。当前基于虚拟现实技术的三维GIS尚缺乏高端分析功能，阻碍了三维GIS的应用发展。
目前，市场上还没有真正与二维一体化的、面向管理和分析的三维GIS软件。虽然为了跟进三维化的潮流，一些GIS平台厂商在结合二维GIS的空间数据引擎的基础上，采用第三方的三维可视化引擎推出了三维GIS软件，但由于第三方的三维引擎不是专门针对GIS特点设计的，加上二维GIS也没有来得及做出必要的改变，所以GIS软件在二、三维一体化的征程上还存在一定困难。
令人欣慰的是，GIS平台厂商们现在正在致力于新一代与二维一体化的、面向管理和分析的三维GIS软件的研发工作，相信在未来2~3年内，将会有新的产品将相继面世。尽管在虚拟现实技术方面，这些新产品可能还无法立即超过目前的三维软件，但更加“GIS”的体系架构会让产品具有更强的生命力，虚拟现实技术也会逐步得到完善，并逐渐取代现在的过渡性三维GIS软件，从而真正解决三维GIS软件的深度应用问题。
掌握 GIS软件技术发展的脉搏，无论对GIS最终用户、应用开发商，还是对GIS平台厂商，都具有十分重要的意义。这世界唯一不变规律的就是永远在变，在今后相当长的一段时期内，GIS软件技术还会保持快速发展的势头，除本文提到的新“四化”发展趋势外，必定还将产生更多的变革和发展。因此，我们唯一能做的，就是拥抱变革，并引领变革！
2月22日 2:02 | 添加评论 |固定链接 |写入日志 | GIS
自诞生以来，地理信息系统(GIS)平台软件技术就从未停止过其快速发展的步伐，在不断带来惊喜的同时，也带来了挑战。技术进步意味着新市场机会的出现，意味着新的应用模式成为可能，但技术进步同时也意味着现有的技术面临淘汰的风险，这令GIS平台的选型变得更加困难。无论是行业应用系统开发商，还是最终用户，一旦所选的GIS平台不符合未来发展的方向，很可能造成巨大的浪费。
笔者将在回顾过去十年GIS平台软件技术发展历程的基础上，展望未来的发展方向，并分析其对未来应用的影响，以期对GIS应用的技术选型提供参考。
1. GIS平台软件技术发展回顾
从二十世纪九十年代末到现在的十年期间，GIS软件技术的发展经历了“四化”，即：组件化、Web化、微型化和数据库化。这“四化”深深地影响了过去十年的GIS应用开发方式，并把GIS的应用推到前所未有的高度。
1.1. 组件化
正如《三国演义》开篇所云，“天下大事，分久必合，合久必分”，GIS软件技术的发展也经历了一段类似的历程。
在 GIS软件诞生之初，不同研究机构分别独立开发了完成不同功能的模块，有的倾力投影转换，有的聚焦数据编辑等等，可称为GIS模块阶段。GIS模块阶段的出现，在GIS发展史上具有里程碑意义，但处在这个阶段的GIS软件是分散的，并未构成完整的体系，很难满足大规模应用需要。
顺应应用需要，有些机构开发了汇集各种GIS功能于一身的集成式GIS软件。从GIS模块阶段到集成式GIS阶段，GIS技术完成了由“分”走向“合”的演变，并凭借强大的功能和自成体系的系统， GIS软件应用开始得到快速发展起来。然而，应用需求始终是检验一切技术的硬指标，尽管集成式GIS功能强大，但若用户只需要做GIS应用中某个环节的工作，却不得不花费昂贵的代价购买整个GIS软件，最终仅能使用到其中10%~20%的功能，这对用户和软件本身，都是浪费。
于是，GIS软件技术又从“合”向“分”回归，模块化GIS被开发出来。用户可以根据需求选购必要的模块。Intergraph的MGE是模块化GIS的典型代表，MGE就是模块化GIS环境(Modular
GIS Environment)的简称。基于统一的图形内核，Intergraph开发了满足不同需要的功能模块，比如坐标配准、交互式矢量化、GIS制图、拓扑处理和GIS分析等。这些模块既可以集成在一起协同工作，也可以拆开独立使用，符合GIS应用社会化分工的需要。但问题依然存在：由于模块划分方式以及模块之间的集成接口均由GIS厂商独立制定，因此容易实现同一套GIS软件各模块之间的集成，即同构集成；却很难实现不同GIS软件之间的集成，即异构集成。事物的发展总是螺旋式上升的，GIS模块阶段和模块化GIS阶段从名称上看有相似之处，但却又本质的区别：前者的不同模块是不同单位开发的，没有形成一个完整的体系；而后者是同一个单位开发的不同模块，这些模块组合起来是一个完整的产品体系。
在像微软的COM这样的组件对象平台发展起来以后，GIS厂商终于找到了模块之间集成的接口标准，组件式GIS由此诞生，异构集成的问题得到解决。组件式GIS是按照组件对象标准和规范划分和组织的模块化GIS，GIS的不同模块仍然可以拆分销售和使用。基于统一的规范(比如COM)，来源于不同GIS厂商的多个GIS模块之间可以非常方便地集成，异构集成的理想得以实现。目前流行的典型的大型组件式GIS平台有SuperMap
Objects和ArcEngine等，轻量级的GIS组件有MapX和MapObjects等，组件式GIS的发展推动GIS应用得以快速发展。 2000年前后，在一个选用了MapObjects作为其开发平台的国土应用项目开发中，开发人员发现该组件产品没有内置的线状符号系统，所有的线型必须编程绘制，工作量非常大。为提升工作效率，开发人员使用了组件式GIS平台SuperMap
Objects的线型系统，直接调用其中的线型绘制接口，把线状符号绘制到MapObjects的地图窗口，以异构集成方式解决了问题。
作为当前流行的开发工具，组件式GIS摒弃了传统的GIS专用开发语言，采用所见即所得的通用软件开发工具，具备高度伸缩性（既可用于大型GIS应用系统开发，也可在被裁减后适用于小型应用系统），并具有与其他信息技术的无缝集成的特点，真正让GIS融入了IT大潮。凭借独特的优势，组件式GIS影响了过去十年的GIS应用开发方式，在GIS软件技术发展历程中书写了浓墨重彩的一笔。
1.2. Web化
“19 世纪是铁路的时代，20世纪是高速公路的时代，21世纪是网络的时代”。Internet的迅速崛起和在全球范围内的飞速发展，使Web成为高效的全球性信息发布渠道。互联网逐步渗透到各行各业，信息高速公路上奔跑着越来越多的信息。随着Internet技术的不断发展和人们对地理信息系统(GIS)的需求增长，利用Internet在Web上发布空间数据，为用户提供空间数据浏览、查询和分析的功能，已经成为GIS发展的必然趋势。于是，基于Web技术的地理信息系统――Web
GIS应运而生。
Web GIS是Web技术应用于GIS开发的产物。通过Web功能，GIS应用空间得以扩展，真正成为了一种可以为大众服务的工具。从WWW的任意一个节点，Internet用户可以浏览Web
GIS站点中的空间数据、制作专题图以及进行各种空间检索和空间分析，从而使GIS飞进了千家万户。
早期的Web GIS应用开发缺少所见即所得的能力，当Web Control技术引进后，基于Web的GIS应用开发变得跟组件式GIS一样方便，可以把平台中提供的或应用开发人员预先定制的Web控件放置在网页中相应的位置，实现所见即所得的软件开发能力。
此外，引进Ajax技术也大幅度提高了客户端的响应效率和用户体验。早期的Web GIS平台开发人员集中精力提高后端机制(Backend
Mechanics)，忽略了客户端的用户体验。AjaxMap技术通过异步通讯模式，实现可视化图片分区异步下载，配以服务器端瓦片金字塔的缓存机制，大幅度提高了Web GIS的客户端用户体验。
Web GIS为Internet应用而生，但同时也为局域网内的GIS应用系统提供了全新的瘦客户端模式的解决方案。作为GIS开发平台，Web
GIS具有以下特点：
★更广泛的访问范围，网络内能访问服务器的任何一个节点，都可以访问Web GIS提供的各种功能；
★更简便的系统部署，客户端无需安装独立软件，系统部署变得更加简单；
★降低大型系统的GIS软件采购成本，对于客户端数量巨大的应用系统，若采用桌面GIS或组件式GIS，将支付大量的客户端软件费用，采用Web
GIS则只需购买和安装服务器端软件，即可实现大量客户端访问，节约大量资金；
★集中维护与即时升级，系统维护和升级都集中在服务器端，一旦服务器端系统完成升级，所有客户端就可及时获得最新的功能和服务。
Web GIS带来的瘦客户端GIS应用模式在越来越多领域得到广泛应用，但由于Web GIS功能相对较弱，还无法代替组件式GIS开发所有的应用系统。因此，不少应用系统需要同时使用组件式GIS和Web
GIS，前者完成复杂功能的应用，后者完成功能简单但访问范围大的应用。组件式GIS与Web GIS双剑合璧，承担了绝大多数的GIS应用开发。
1.3. 微型化
微型化是GIS软件发展的另一方向，尽管桌面应用仍然占GIS应用的主要部分，但不少用户对于GIS移动化应用的需求也越来越多，比如电力巡线，农业田间数据采集、外业测绘和邮递送货等，他们需要在室外移动作业环境中使用GIS。包括笔记本电脑和桌面PC在内的计算机设备，显然很难满足野外作业的需要，PDA、手机和其他移动设备也加入到GIS应用的硬件行列。这些设备多采用Windows
CE、嵌入式Linux等嵌入式操作系统，内存和计算能力也相对较低，传统的GIS客户端无法运行。
为适应小内存、较低处理能力的嵌入式计算环境，GIS厂商纷纷推出一种精简的嵌入式GIS软件，国内产品如eSuperMap和MAPGIS–EMS，国外产品如ArcPad和 MapX
Mobile。嵌入式GIS被广泛应用作为数字*******************终端、电力巡线、农业田间数据采集和外业测绘等领域。
1.4. 数据库化
数据库化是空间数据存储与管理的发展方向。早期的GIS软件采用普通文件(Flat File)存储和管理空间数据，如Arc/Info的Coverage就由一个目录里的多个文件组成。纯文件管理空间数据的模式的属性数据管理能力相对欠缺。
为解决这个问题，一些商用软件采用普通文件和数据库混合模式，即用普通文件存储图形数据，用数据库存储和管理属性数据，充分利用数据库系统的功能，提高了 GIS软件中属性数据管理能力。如：MGE采用DGN文件存储图形数据，通过Oracle和SQL
Server管理属性数据。但这种模式造成了属性数据和图形数据的分离，给维护二者之间的对应关系带来一定的困难；同时，使用普通文件存储图形数据，很难应付海量空间数据的管理，且在权限管理、多用户并发写操作等方面都存在不足。
空间数据库技术的出现较完善地解决了以上问题。空间数据库完全基于商业关系数据库存储和管理空间数据，不仅实现了图形数据和属性数据的一体化管理，而且带来了一系列的优势，包括：1)海量数据管理能力；2)支持多用户并发写操作；3)数据访问的权限管理；4)可利用数据库的集群(或互备)机制提高并发访问能力和系统可用性。
在过去十年间，空间数据库技术已经发展成为大型GIS应用系统的主流数据管理方案。从技术架构来看，空间数据库技术可分为数据库内扩展型和数据库外扩展型两种。 Oracle Spatial就是典型的数据库内扩展型，拥有数据库系统源代码的厂商可以从数据库底层实现一些基础的空间数据管理能力。ESRI的 GeoDatabase、超图的SuperMap
SDX+和中地的空间数据库则属于数据外扩展型，这类由GIS厂商研发的空间数据库技术主要从数据库系统外围，通过调用数据库系统的非空间数据管理能力来实现空间数据的管理。
相比较而言，前者更容易实现，研发代价更小，而且可以提高空间数据库系统内部的性能。但从应用效果来看，后者反而比前者的访问效率来得更高，这是为什么呢？原因在于：GIS软件访问空间数据库时，必须把数据库中存储的图形数据结构要转换为GIS软件的数据结构，由于数据库厂商定义的图形存储结构与GIS软件有较大差异，因此这种转换对性能有较大影响；而由GIS厂商研发的数据库外扩展型空间数据库技术，二者相对一致，基本不需要转换，因此效率更高。从实际应用来看，数据库外扩展型的空间数据库仍占主流，尤其在有海量数据管理需求的项目中占绝对优势。
转载自：https://blog.csdn.net/vernonzheng/article/details/8046514
