地图分幅组件的实现(六)——国家1:5万地形图制图的巨大挑战

         国家1:五万地形图制图项目算是我参加的项目中时间最长的了,从项目开始参与时才刚结婚,到近期项目验收时,自己的孩子都已经满地跑了。艰难得项目过程着实让人窒息。几年时间的持续开发,几乎耗尽了每个参与者的所有精力,幸好结果是圆满的。

        很多人不了解五万的特点,其实从用途上来说五万地形图适合野外考察,行军打战,记得以前在周口店实习,用的地图好像就是五万地形图。因为军事用途,客观上五万的要素信息要非常的丰富,所以给制图带来的特点就是数据量巨大。制图要求也非常高,依比例尺符号,不依比例尺符号等等规范,着实让我们这些做GIS开发的人蛋疼。全国的数据需要采用同一的方式制图,最后要把制图信息全部保存到数据库中(所谓图库一体)。

        960万平方公里的国土,全部采集的数据整理后分层入库,而后编图再入库。从需求上来说,就是数据入库->入库数据分发->数据制图编辑->制图数据回收入库的过程。非常理想及自然的一个过程。问题的表象往往掩盖住了问题的严重性,在着手开始需求分析及架构设计的时候,我们从常规角度以及经验出发,来实施,没错这是软件设计及开发所遵循的一般规律,我们在初期顺利的按照设计过程进行实施,在小范围的试验中,我们取得了初步成效。在一段测试后,开始了生产试验,要知道生产项目可不是一般性的项目,如果有一点问题后果将非常严重。初期的设计上并没有出现什么问题,根据需求采用分布式架构,所有五万数据按标准分幅检出,下发到各个作业员手中,等作业员完成工作,通过质检后,检入回数据库中。因为这是一个无比巨大的工程,即有建库也有制图生产,而且工作是并行过程,虽然我们只是参与制图库建设及制图过程的开展,但是我们的进度是耽误不起的,建库数据验收完一部分,我们就在制图库中计算一部分用于生产。等到项目中期,数据量上来了(每个批次的验收数据中光等高线数据就是以几千万计),服务器的数据压力以上来,发现现有的功能都几乎无法正常运作了,数据检出慢,数据检出同样慢,这是无法忍受的全国两万多分幅数据,一幅数据要检一个小时那几乎要疯掉的。

        能够救赎我们的人,只有我们自己。这次的经验告诉我们,在海量数据面前,常规的软件功能都是徒劳的。检入(CheckIn),检出(CheckOut)的背后是版本控制,在两三千个版本出现后SDE数据库依然正常运行(SDE很强呀),但是检出速度明显会变慢。解决的方法只能重写这些过程,教训呀,真正的环境中,常规的模式或现有的东西是需要考验的。关于检入问题也是一堆问题,检入需求改变后(需求是人为制定的没有规则),例如图外可能有些数据编辑的信息需要入库,有的可以舍弃,这都没有规律可循,但是AO提供的功能是无法实现这些的,没办法,只能写更细粒度的检入控制(也几乎重写了这部分功能)。

       制图数据在入库过程中也需要接边(每个图幅内的数据编辑信息都要通过接边的方式在制图表达上一致),超级复杂的功能。

       一个问题的出现,往往加班数周才能解决或部分解决。生产项目的要求使得项目实施压力巨大无比,此类项目接手需要慎重呀。经历了这些,创新的工作有很多,例如制图过程中基于规则的的自动化或半自动化生产,国标的完全支持(是完全),海量数据的处理,最大的创新图库一体(喊了这么些年,真正在海量数据上实现的仅此一家)。

      当然分布式生产,统一入库,非常有意义。举个简单的例子,以后如果某个区域发生问题需要立刻有地形图支持,可能我只要画个范围检出制图数据,以往的编辑成果就能以任意范围直接生产出标准地形图(多低碳),不必还是分幅检出哦!

    2010年度已经获得了ESRI最佳应用奖。http://events.esri.com/uc/2010/sag/list/#international

地图分幅组件的实现(六)——国家1:5万地形图制图的巨大挑战_第1张图片

    

    

 

你可能感兴趣的:(数据库,工作,架构设计,服务器,作业,2010)