GIS之路在何方

GIS之路在何方
——兼论ArcGIS
(本文仅探讨GIS软件的未来发展趋势。纯属自娱自乐。观点有失偏颇,欢迎评论!)
GIS是地理信息系统的简称,作为一个行业,其更应该具有软件工程的属性,而与地理学关系不大。所以,各大学地理系(偏文)开设此专业,不太适合。GIS是个技术性很强,却没多少理论价值的学科。
搞自己的GIS软件,难度很大,但也不是不可行,如北京超图和武汉中地就做的很好。GIS软件经历了集成式、组件式、Web服务式等几个发展阶段。集成式已经被淘汰,可能为数不多的系统躺在国外大学的研究所里。组件式虽然发展多年,但仍不过时,因为应用系统的千差万别,需要灵活搭建应用平台,所以最好的办法是做成组件式。目前应用领域越来越宽广。
可以设想,组件式这种模式还会存在相当长的一段时间。需要指出的是ESRI ArcGIS的组件式GIS产品,如MapObjects(MO)和ArcObjects(AO)。我觉得AO好象是在MO基础上开发出来的,或者至少受了MO的启发。但是AO走了一个极端,就是凡物则组件。就象Java语言,万物皆是对象。这其实是个误区。任何事情到了极端都未必是好事情,就象AO,复杂庞大到让人望而生畏。我自觉也算熟练开发人员,目前还不敢用AO来做项目。给我的感觉,设计AO的人应该是学院派。
接着,ArcEngine产生了。因为没使用过,所以不好评论。如果说ArcEngine是用来弥补AO的缺陷的,那么不正说明AO设计上的失误么。
MO是一套ActiveX对象的体系结构。设计思想简单实用。但也可以看出它是用比较老的Windows 组件开发语言框架(我估计是MFC)。有些地方写的还是敷衍了事,功能较少,谈不上体系。在大项目中使用MO会给程序员带来很大的困扰。比如符号化、线型化、图层配置、地物编辑、多数据源、打印等等。而这些基本的GIS功能,是客户需要的。不能期待一个使用VB的开发人员来完善MO的这些功能,如果无法深入到MO内部,这些事情无论如何是做不好的。
这样就存在一个悖论,用AO太难了(起码对大多数程序员),用MO太简单了(简单是指MO本身的功能太简单,而无法完成业务)。这个现实的问题是回避不了的。ESRI设计AO本来的目的是替代MO的,但是MO目前的市场并不弱,说明AO本身的局限导致AO的应用出现了问题。AO的设计缺点是太过庞大、复杂、混乱。庞大是指软件的尺寸和规模;复杂指对象之间的关系错综复杂;两者结合起来就是混乱。
设计需要匠心,要精巧和细致。这样写出来的代码才精简高效。而ESRI以为搞了一套AO就万事大吉了,所有GIS开发,就是AO组件搭台唱戏的过程,这就错了——天下没有不变的道理。
自己开发组件GIS也需要吸取MO、AO的特点和教训。MO太简单、AO太复杂。所以可以折衷一下,只做必要的事情,不做所有的事情。还有就是隐藏复杂于简单的背后。当一个人习惯简单的东西,才能适应越来越复杂的东西。这是一个过程。
我的看法是:未来的GIS要发展出类似游戏一样的行业应用来。GIS地图引擎其实类似游戏引擎。这样看,无论AO还是MO最终都要淘汰。(那么象AO那样设计出复杂的接口干什么呢?)如果以为掌握了ESRI的开发工具就可以万事大吉了,那就错了。未来的2次开发只能越来越简单,没有人会花几个月甚至半年的工夫学ArcObjects,有那时间还真不如打打游戏有意义。
目前地图的显示太枯燥、刻板,当然这也是工程的需要。但是,一个大胆的设想就是未来的GIS必须给我们构筑一个虚拟现实的世界,这个世界是有生命的,不仅仅是枯燥的点、线、面,要有建筑、阳光、空气、绿色植物、水和情感——它应该是现实世界的再造。当我们漫游在GIS的世界里,就进入一个现实的世界,这里有一切我们需要的东西:你可以看到KFC店里香喷喷的鸡翅;可以看到南京路上攒动的人群;可以在西湖里看自己的影子;你还可以开着越野车撒欢地跑在乡村公路上。
Web服务式的GIS其实是一种应用模式。它与组件是不矛盾的。任何一个大型软件都要细分成单元,所以组件式的发展会与软件工程密切相关。服务式的GIS简化了对客户的要求,所以必将成为占统治地位的应用模式——WebGIS。
      无论哪种 GIS ,都需要构筑一个丰富多彩的世界。这就是 GIS 未来发展的方向。我预计 5 年时间会出现这样的产品。如果没有,我来做一个 。

你可能感兴趣的:(游戏,mfc,语言,开发工具,web服务,引擎)