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年时间会出现这样的产品。如果没有，我来做一个。