写在前面

　　作为一个水文人，研究水文相关的模型、方法很多年。在最初的一段时间关注各种文章上的理论、算法，自己尝试去实现以后期待有些发展，通过此也的确自娱自乐了很久，觉得同行有的研究思路非常好，成果也非常好。可时间久了总觉得自己就停留在理论上，涉及到实际问题时又一筹莫展，方向太窄，无法解决综合性的实际问题，于是又拓展自己的知识结构，将我们这个方向的水文、水动力、地下水都弄一遍，模型都自己编一遍，又是一阵劳累。可是又出来了新问题，地学涉及到大量的模型、需要空间上时间上的集成耦合，单个模型自身可能并不复杂，但集成到一起之后就异常麻烦，往往是建模3个月，运行5分钟完事。大量的工作都在做重复的数据处理，不过对于写文章这是值得的，但要解决实际问题效率就比较低了。于是乎需要有一个工具能帮助快速地完成模型集成。多番搜寻国际上著名的软件，比如水文领域的SWAT、DHI-MIKE系列、Visual ModFlow、BASINS、HEC系列等等，这些软件经过多年的发展已经产出了大量的文章，也有诸多研究人员使用，在研究领域具有不可撼动的地位。可当用这些软件来解决实际问题，尤其是水文领域的实时问题时又显得力不从心，比如很难使用SWAT做实时洪水预报，难以用Visual ModFlow考虑河道水流交互，也很难去修改这些封闭半封闭的软件，而且它们的前处理也比较麻烦。最最不甘心的就是，用这些软件后自己研究的一些模型就没用了，而且在别人的基础上还发展不了模型，只能用这些模型来分析问题，稍微深入的修改就不行了。那是不是需要把自己的模型集成起来封装成软件呢？经常有人说“别人都有轮子了，干嘛要自己重复发明轮子？”，可有人就想干重复发明轮子的事。

遇到的困难

　　真要自己造轮子何其困难。首先，造的轮子一定比别人的好很难，但至少要有点特色，比如在可操作性、易用性、美观性上能做到有一点点优势吗？模型、方法就算没有优势，那在耦合程度上能有点特色吗？软件的框架怎么设计能保证以后的扩展性、可维护性？怎么能够充分体现水文的地学属性，让别人不仅能看到数据结果，还能实时地看到图形结果？这些都是拦路虎，只能一个一个去解决，设想的大方向是把目前最好的GIS软件ArcGIS与自己研究的一些水文模型耦合起来，而且是想完全集成起来，即所见即所得的方式。对一个非计算机专业的人说，这种集成立刻就遇到了三个无法回避的问题，这些问题在上述成熟软件中也同样存在：

• GIS的点、线、面的矢量图层结构和水文模型的对象不一致，采用组合图层又非常难以控制

• 不同空间尺度的模型在GIS上能不能做到以图形化方式地耦合是集成的关键问题

• 不同时间尺度的模型在GIS上嵌套运行的标准是模型能耦合计算的关键问题

目前的成果

　　虽然这些都是障碍，可自己既然定下了目标就还得去克服，还好有时间，而且能力不强，只能一门心思就做这点小事情，多年的摸索有了一点点小结果，主要做了以下几个事情：

• 详细学习ArcMap这个软件本身的架构，模仿它且以AO二次开发方式实现了一个插件式的GIS系统软件

• 按照面向对象的方式在AO中自定义图层，深度扩展出水文模型通用的数据模型，并让GIS可视化表达

• 借鉴OpenMI的模型耦合接口，设计出了在GIS图形界面上图形化地耦合集成和耦合计算的通用模型接口

• 在集成模型内部按照时间尺度从大到小（地下水->地表水位->河网水动力）的嵌套运行模块

• UI界面和模型都插件化，即可以通过插件的方式增加界面以及水文模型

  
  

 　　下面是目前的进展，在后面的博客中将记录所采用的方法，给自己一本笔记