建库项目有感

时间:2021-04-23 08:40:26

     由于公司领导要求写一篇文章发表到公司内部报刊,加之近期准备考个证,要笔试论文,多年没有用笔写字了,借此机会练练手。博客长期没变化了,于是一并发到随笔中充数,哈哈!

 

建库项目有感

 

摘要:

         本文以我参与的多个建库项目为实例,探讨了我对建库项目的理解、建库系统开发过程中涉及的关键技术,以及项目实施的过程,最后总结项目过程中遇到的问题。我以项目负责人及主要开发人员的身份参与了这些项目,项目开展过程中,借鉴了公司多年在建库领域的丰富经验,主要在地图展现、入库机制等方面有所改进,借此机会与大家共同探讨。

 

正文:

         一、建库项目理解

         我们公司最早开展建库项目,多年来经过大批优秀软件工程师的不懈努力,积累了丰富的经验和成果。建库系统最通常指的是对基础地形数据的建库,除此之外,还包括对控规、规划成果,甚至地下管线的初始建库。是各种基础数据的整理统一入库应用的过程。

         我们常说数据是GIS的核心,可见数据的重要性。而建库系统就正是采集制作、集中入库、统一管理、数据共享服务的这样一个载体。在数据的采集制作过程中,系统需要提供严格遵循数据标准的数据辅助成图及数据监理软件,来保证原始数据的质量;在集中入库过程中,我们要对多源异构GIS数据提供高效无损转换功能,并与数据更新机制、历史数据版本机制协调运作,完成各类数据的更新入库;统一管理是对各类数据的使用及加工,通常提供常用GIS功能、专题查询统计、空间分析,历史数据维护使用等功能;数据共享服务包括地图转换输出,及逐渐形成的一个数据服务共享平台,为第三方或其他系统提供GIS基础数据支持服务。

         二、关键技术

         建库系统由于开展较早,属于基础建设级别信息化产物,大部分的需求、技术较成熟稳定,然而建库系统又是与外业测量,数据生产加工,与GIS数据结合最紧密的数据处理管理系统。随着ITGIS技术的不断发展,我们在系统设计,功能实现上从未停止过完善与创新。

         建库系统首先要解决的就是要灵活应对各种地方特色的数据标准、生产流程差异性。通过产品化的思路,最大限度的提高系统的灵活性、可扩展性,有效应对用户特色需求。

         其次就是要解决多源异构GIS数据的无损可逆转换问题。无损是建库系统追求的终极目标之一,但是我们应该把它理解成误差最小。绝对的无损是不实际的,因为我们使用的最基本的度量数据是有限精度的,我们应该通过技术的改进减少误差,尽量避免外业测量后数据的生产、加工、管理过程产生不可接受的误差,如:我们可以减少数据转换的中间环节,减少使用容易带来误差的数据格式等。Shape file格式是我们常用的GIS数据格式,但它在描述定义弧段、圆等实体时力不从心,只能通过一些小段线的微积分模拟的方式实现,在数据转换过程中我们可以选用支持实体类型更完整的GeoDatabase格式。数据转换过程中还要注意对数据精度的保证,尽量控制在千分之一以内。

         接下来要谈到的是历史数据版本机制。该机制应该是建库系统乃至所有需要维护历史数据的信息系统最重要部分,它往往会影响到整个系统框架的搭建,与编辑机制、入库出库、应用功能等紧密联系。我个人总结了三种实现方式,分别是完全编码实现、完全ArcGIS方式实现、混合方式实现。以前的建库系统属于第一种,采取对每个实体打上时间戳的方式,涉及到几乎所有系统的功能都与该版本机制耦合,额外的增加了编辑功能的复杂度,带来系统稳定性的降低;第二种方式中,ArcGIS平台给我们提供了编辑事务版本和历史档案数据版本。我们可以采用编辑事务版本来实现编辑功能,有点众多,可以有效解决多人并发编辑冲突,自动实现逐步撤销、恢复,对长编辑事务的支持等。对历史数据的管理,采用ArcGIS提供的历史档案数据版本机制,其实现原理与我们自己维护实体时间戳方式类似,但远不如我们自己维护来的灵活实用,历史档案版本机制在实际项目应用中不是很实用,不能很好的满足建库系统中用户对历史数据版本管理应用的需求。第三种方式力求综合前两种方式的优点,避免它们的缺点。多采用编辑事务型版本机制来实现要素级编辑,开发人员可以专注于编辑功能本身,历史数据版本机制则采用要素级维护时间戳的方式实现。这第三种方式是最复杂、实际操作起来实现的组合最多的。我们在实际项目中也在不断探索更优秀的方式,如按照项目需求要素级编辑要不要产生历史数据版本的不同,可以采用绝多数功能使用AE开放的功能模块,特殊功能单独开发,由于AE开放的功能暂时无法追加对编辑要素时间戳的维护,所以这种方式必然无法产生要素级编辑历史版本。对于一定需要记录要素级编辑过程中产生的历史版本的需求,我们可以在场事务编辑机制的前提下,编写带时间戳的编辑功能。数据批量更新产生的历史数据采用维护时间戳的灵活应用方式实现,对时间戳的按工程、子工程分组管理,可以改善版本管理的用户体验。由于用户对系统性能的更高要求,考虑将现势数据库与历史数据库相分离的机制,从物理存储上减轻服务器负担,改善系统整体性能。更多的细节还需要我们到现实的项目开发实施中去实践、探索、发现。

三、项目实施

    建库系统的实施也是有独特之处的,由于包含有数据生产、加工、初始建库的过程,与其他数据应用型系统有很大不同。我们需要计划安排相当长一段时间用于数据生产加工,在此过程中我们一般需要开发相应的数据辅助生产、数据监理等工具来保证原始数据的质量,可能还需要负责数据监理相关的工作,在常州武进建库项目中我们正是充当了建库方与监理方的角色,如果建库系统要朝着基础数据生产加工、入库出库、管理应用的全流程系统方向发展,辅助成图软件和数据监理软件是不可或缺的。

    初始建库过程往往需要相当长的一段时间,为了提高效率,我们可以把它与后期数据更新维护功能分开,只需要提供数据的转换入库及接边功能。建库系统是一个使用集中、管理集中的系统,需要对甲方系统管理员进行认真仔细的维护培训,用户手册要编写详尽规范,培训好一个甲方系统管理员,可以很大程度的减少我们后期项目的维护服务成本。

四、总结

    系统的稳定性在建库系统中体现得尤为突出,频繁的大数据量、复杂数据结构的导入导出对系统及平台稳定性是一个考验,一般的有效方法可以及时升级数据库管理系统到推荐版本,及时更新ArcGIS平台补丁等。

    目前,建库系统朝着高扩展性、产品化方向及数据共享服务平台方向发展。数据标准是建库系统的灵魂,它的扩展维护机制是产品化首要解决的问题,基础数据共享服务接口及运营模式是数据共享服务平台发展的首要问题。