国家1:五万地形图制图项目算是我参加的项目中时间最长的了，从项目开始参与时才刚结婚，到近期项目验收时，自己的孩子都已经满地跑了。艰难得项目过程着实让人窒息。几年时间的持续开发，几乎耗尽了每个参与者的所有精力，幸好结果是圆满的。
很多人不了解五万的特点，其实从用途上来说五万地形图适合野外考察，行军打战，记得以前在周口店实习，用的地图好像就是五万地形图。因为军事用途，客观上五万的要素信息要非常的丰富，所以给制图带来的特点就是数据量巨大。制图要求也非常高，依比例尺符号，不依比例尺符号等等规范，着实让我们这些做GIS开发的人蛋疼。全国的数据需要采用同一的方式制图，最后要把制图信息全部保存到数据库中(所谓图库一体)。
960万平方公里的国土，全部采集的数据整理后分层入库，而后编图再入库。从需求上来说，就是数据入库->入库数据分发->数据制图编辑->制图数据回收入库的过程。非常理想及自然的一个过程。问题的表象往往掩盖住了问题的严重性，在着手开始需求分析及架构设计的时候，我们从常规角度以及经验出发，来实施，没错这是软件设计及开发所遵循的一般规律，我们在初期顺利的按照设计过程进行实施，在小范围的试验中，我们取得了初步成效。在一段测试后，开始了生产试验，要知道生产项目可不是一般性的项目，如果有一点问题后果将非常严重。初期的设计上并没有出现什么问题，根据需求采用分布式架构，所有五万数据按标准分幅检出，下发到各个作业员手中，等作业员完成工作，通过质检后，检入回数据库中。因为这是一个无比巨大的工程，即有建库也有制图生产，而且工作是并行过程，虽然我们只是参与制图库建设及制图过程的开展，但是我们的进度是耽误不起的，建库数据验收完一部分，我们就在制图库中计算一部分用于生产。等到项目中期，数据量上来了（每个批次的验收数据中光等高线数据就是以几千万计），服务器的数据压力以上来，发现现有的功能都几乎无法正常运作了，数据检出慢，数据检出同样慢，这是无法忍受的全国两万多分幅数据，一幅数据要检一个小时那几乎要疯掉的。
能够救赎我们的人，只有我们自己。这次的经验告诉我们，在海量数据面前，常规的软件功能都是徒劳的。检入(CheckIn)，检出(CheckOut)的背后是版本控制，在两三千个版本出现后SDE数据库依然正常运行(SDE很强呀)，但是检出速度明显会变慢。解决的方法只能重写这些过程，教训呀，真正的环境中，常规的模式或现有的东西是需要考验的。关于检入问题也是一堆问题，检入需求改变后(需求是人为制定的没有规则)，例如图外可能有些数据编辑的信息需要入库，有的可以舍弃，这都没有规律可循，但是AO提供的功能是无法实现这些的，没办法，只能写更细粒度的检入控制(也几乎重写了这部分功能)。
制图数据在入库过程中也需要接边(每个图幅内的数据编辑信息都要通过接边的方式在制图表达上一致)，超级复杂的功能。
一个问题的出现，往往加班数周才能解决或部分解决。生产项目的要求使得项目实施压力巨大无比，此类项目接手需要慎重呀。经历了这些，创新的工作有很多，例如制图过程中基于规则的的自动化或半自动化生产，国标的完全支持(是完全)，海量数据的处理，最大的创新图库一体(喊了这么些年，真正在海量数据上实现的仅此一家)。
当然分布式生产，统一入库，非常有意义。举个简单的例子，以后如果某个区域发生问题需要立刻有地形图支持，可能我只要画个范围检出制图数据，以往的编辑成果就能以任意范围直接生产出标准地形图(多低碳)，不必还是分幅检出哦！
2010年度已经获得了ESRI最佳应用奖。http://events.esri.com/uc/2010/sag/list/#international
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
