企业级GIS应用系统的一般框架

  作者：jimxu（转载请注明出处http://blog.csdn.net/xujim，谢谢）

  到目前为止也已经参加过3、4个GIS项目的开发，涉及到国土资源利用、规划，电信管线资源管理的业务，系统架构有B/S，C/S的均是三层架构，系统平台自己所使用过的有SuperMap，ArcView，ArcGis，MapInfo，Geomedia，其他的多有了解，最擅长的和喜欢的还是ArcGIS。其实GIS平台都是大同小异，往往一通百通。

  所做过的系统所采用的业务逻辑模型有LandEx的基态修正模型、LandPlan的WorkFlow，以及现在Gcomm的元模型。
其实一般规模的GIS系统（和企业OA结合）即使所采用的平台不同在架构上都是大同小异。模块划分上都少不了：权限管理，图库管理，空间数据维护（一般包括查询，分析，编辑），地图出图几个模块。
  对于权限管理模块一般来说套用OA系统的权限即可，但是在（空间）数据库系统中权限不仅仅是对用户的操作上进行控制还需要对用户所看到的数据上进行控制。数据层面上的控制在GIS系统中有其特殊性，因为GIS系统的数据是空间数据，它要求权限管理从空间关系上对用户的权限进行定义，如甲用户只能察看A点周围800米内的地物或设施。这种语义的表达对于平常的关系型数据库来说是爱莫能助；在GIS系统中可以基于空间数据库的空间算子对这用关系进行模拟表达。
  权限系统的设计上也很有讲究，完美的系统要考虑到权限控制的广度和粒度。所谓的广度是指权限所控制的对象的广度，横向上有人、组织等等；粒度上是指被控制对象的细化，不仅要控制到组织，还要控制到人，不仅要控制到表，还要控制到纪录集以及某条纪录甚至某几个字段。
我接触过的权限管理系统不多只有早期的LandEx和现在的GridView的系统。GridView系统的权限管理后期设计、实现上我参与了不少，对其结构比较了解也有许多的看法。总体上说GridView的权限在体系上已经初具模型，灵活性上也很强，具体的是不断的在细节与功能上对其进行完善。
权限模块的设计还是挺简单的，关键是对问题域的抽象，抽象的越好，设计越灵活，不过这也是架构设计的至理阿。
  图库管理是海量数据管理的关键所在。空间数据在空间布局上成区域性分布，在建库上分层，所以图库管理的口号是：“横向分幅，纵向分层”。横向分幅就要求图库需要有图幅索引（类似空间索引，说开去还可以实现缓存机制），如此能加快浏览速度，而且在图幅与图幅交界处的管理时能够自动的探取到对应的图幅，从而实现图幅的无缝管理。图幅应该有相应的元数据以对数据有详细的描述。图幅入库手段的开发很有讲究，因为地图数据有多源的特异性，所以入库必须多不同数据格式进行读取，空间坐标上要进行一致性转换，有些数据还需要进行图幅接边，影像数据还要建金字塔。GIS领域有个“多源异构数据集”的提法指的就是这个意思。其中图幅接边是个比较麻烦的事情，很多需要人工干预。
图库管理其实还需许多工具，如线转面，拓扑校验等，对于一个智能系统还应该有空间数据挖掘方面的功能。
图库管理往往在国土、城市规划等领域用的比较多，电信GIS上很好用到（我现在参与的项目就没有）。
LandEx在图库管理做了一点点尝试，但是不完善。
  我一师兄博士后对这一块很有见地，我现在的一些想法很多都是当初在实验室时从他身上学到的。
空间数据编辑模块初看似乎很简单，其实不然，数据库的编辑其实学问就很大，不如说协同性，事务机制等，何况空间数据库呢？
事务机制和协同性其实关系密切，这里着重讨论下协同性。协同性一般指在保持事务机制的基础上不同用户对同一数据进行编辑时冲突的发现及解决。一般的GIS平台对于协同性都有解决方案，如ArcGIS的版本机制，Gcomm的作业提交机制，LandEx的工程管理机制等等。简单的方法是将用户所正在编辑的纪录独占锁定，然后将用户所做的编辑修改保存为某种作业，然后统一提交。所以有了长事务与短事务的概念。复杂的协同机制就大有学问了，如ArcGIS的版本机制，ArcGIS并不对用户的正在修改的纪录做锁定，它是将用户某次session所做的所有修改作为一个版本，子版本还可以继承于父版本，版本的提交得过程中会自动发现编辑冲突并且人工或自动做出冲突解决。如果你用过CVS，你就明白这种冲突的解决方式了。这种版本管理方式很适合离线编辑的情况，而ArcGIS正是支持离线编辑的。
  空间数据库还有个重中之重，那就是空间分析了，与业务相关的如网络拓扑分析，这个gcomm和ArcGIS都作的很好，赞一把。网络拓扑的算法，我最近也有些理解，当然距离实现那是另一回事。
地图出图直接涉及到地图产品的输出，所以美观、方便是该模块的终极目标。
  首先简单的说，地图如何美观主要取决于地图色彩搭配，配件（surround，如比例尺，指北针等），地图符号，标注等方面。最主要的是地图符号。一般的地图符号都以字体文件为主，字体符号一般不是很美观，当然GIS平台一般都提供自己的符号格式与定义方法，我感觉比较方便的有ArcGIS。地图符号绘制还可以使用数学法，即某些规则的符号，如五角星就可以使用数学方式进行绘制。前面所说的符号都是矢量符号，其实还可以使用栅格符号，直接用图片作为符号或者用图片填充面的地图符号；当然一些GIS平台提供了符号进行叠加从而产生出新的符号（原理也很简单就是符号组合绘制一下嘛）。
  当然，地图制图学问很深，其中比较难的就是制图综合。它考虑到地图数据的取舍，流动注记等。地图数据取舍一般指不同比例尺下会自动地展示合适的地图数据，以及线、面数据的合并，不如在1：5万的比例尺下一条河流应该以面的形式出现，而在1：10万时它就应该以线的方式了。流动注记指注记沿着线进行绘制，及注记之间绘制冲突的解决防止叠盖。
  制图综合已经涉及到人工智能了，如MAS(Multi-Agent)等技术，当初在学校的时候研究了一般，最后面想想“理论还是不能脱离实践”阿，放弃了。
业务逻辑模型处于三层架构的中间，处于封装业务逻辑的作用。不同系统之间的差异真正表现在的还是业务逻辑。我所参与过的有解决空间数据变更在时间维度上的维护问题的“基态修正模型”和工作流引擎及现在所做的元模型。
  基态修正模型在GIS界是很流行的用于解决时空数据编辑的一个重要的模型。它将当前态或某一历史时刻为基态对空间数据的历史变化进行维护模拟，从而将空间数据从三维扩展到四维，从时间的维度上对空间数据进行分析，编辑。时空数据模型是个尚在解决的问题，但基态修正模型从实用的角度出发，还是能解决现实中的一些问题。我所在的实验室开发的LandEx系统便是基于该模型，解决了土地利用数据变更方面历史空间数据回溯，回退，变更统计等问题。具体基态修正模型可以参看GIS上的一些文档。
  工作流的本质在于对业务流程进行定制与流转。关于工作流的文献上一般将工作流抽象为节点与路由，典型的如Petr网。当初搞工作流的时候，我所参与的不多，对于逻辑模型的设计应该不难，关键可能还是在开发设计上，如可设计的报表等等。
  个人认为元模型其实和工作流比较象，因为他们都追求灵活的可配置。工作流追求流程，界面可配置，元模型追求底层设施、界面可配置。不过我觉得元模型应该是工作流的一小块，因为工作流里应该也会有设施的可配置的，一个真正的工作流系统不应该仅适用于某一领域（如国土），如果拿到其他领域（如电信，水利）它应该只需要重新配置以下底层设施就可重新使用了。
  最后要说的题外话是一般企业级的大型GIS应用，海量数据的管理是关键，而此时GIS的二次开发就显得并不时很重要了，而且二次开发由于其简单，很容易被鄙视。所以此时DBA就比较吃香了。我就比较羡慕那些DBA，尤其搞Oracle的，工作轻松，工资也高。