水文地质应用分析系统建设方案

水文地质信息系统平台技术方案1 项目概述水文地质，地质学分支学科，指自然界中地下水的各种变化和运动的现象。水文地质学是研究地下水的科学。它主要是研究地下水的分布和形成规律，地下水的物理性质和化学成分，地下水资源及其合理利用，地下水对工程建设和矿山开采的不利影响及其防治等。随着科学的发展和生产建设的需要，水文地质学又分为区域水文地质学、地下水动力学、水文地球化学、供水水文地质学、矿床水文地质学、土壤改良水文地质学等分支学科。作为传统的地质学科，经过若干年的发展，积累了大量的水文数据，迫切需要进行系统化的信息管理，借助IT技术及GIS等技术，将复杂的水文地质模型在GIS的环境下展示出来并且进行进一步的分析，数据梳理的同时又能分析出更深层次的信息来。建立水文地质信息系统平台是地质行业发展的必然趋势。2 总体设计2.1 数据资源平台数据资源平台包括水利公用数据库、各业务专用数据库、空间数据库、对数据库数据描述的元数据库和数据字典。根据信息依附的具体对象、实体和信息本身的属性对现有的水利数据信息进行分类与标准化，以此为基础建立水利数据库。数据中心水利数据库设计包括水利公用数据库、水利专业和元数据库3大类。水利公用数据是提供给水利业务的基本资料，能够比较广泛地为各种业务应用提供服务，水利业务数据是为某个或某类特定业务应用专用的信息，服务对象包括防汛抗旱、水资源管理、水土保持、工程管理与建设、农田水利、水利行政管理等。元数据库是对以上各数据进行描述的元数据的集合，是进行数据交换的基础。每大类数据库又可分为若干个子数据库。2.2 数据库管理平台数据库管理平台负责对数据资源进行管理维护、数据交换，包括数据库维护管理系统、信息资源目录与信息发布系统、水利综合查询系统和元数据管理系统。1）数据库维护管理系统数据库管理系统主要是对综合数据库的管理，主要功能有数据库模式定义、数据更新维护、数据库用户管理、代码维护、数据库性能优化管理等。2）信息资源目录与发布系统以水利数据中心为枢纽建立水利信息资源共享，通过元数据管理，组建数据资源目录管理。信息资源目录系统提供分布式数据共享的基础，对于物理上分散的数据资源建立统一的数据清单，系统能够数据所有者提供发布的平台，为数据使用者提供查询服务。在数据中心建设中，省水资源中心数据、省水文局水情中心数据、省水土保持监测站数据、省水利信息中心数据以数据资源目录的形式提供发布和检索平台。虚拟的信息目录中心设在省水利信息中心，统一管理信息目录，提供注册和发布平台。3）水利综合查询系统水利综合查询系统是对中心数据资源的检索服务，提供基础性水利数据的信息浏览。4）元数据管理元数据管理系统集中管理的元数据的系统，实现对异构、异地数据资源的分布式管理与服务。其基本功能包括元数据的提取、质量保证和再处理、系统的维护。 2.3 应用支撑平台建设应用支撑平台是构筑整个水利数据中心应用系统的统一支撑平台。应用支撑平台介于中心数据库和各种应用系统之间，与业务应用系统的运行网络环境、软硬件环境无关。通过管理软件、中间件、数据备份软件等构造数据中心的软件运行环境。数据中心应用支撑平台包括操作系统、数据库系统、存储备份软件、地理信息系统软件和工作流等各种应用中间件。平台的功能主要为各种应用系统提供数据库的访问、地理空间服务、系统之间的信息交换、事务处理、流程控制、认证等各种服务和统一的Web服务器平台。3 数据层设计数据层由基础地理空间数据和水文地质专题数据两大部分组成。基础地理空间数据根据国家测绘局相关规范中的要求，需要对基础地理信息数据进行内容提取、分层细化、模型对象化重构、统计分析、符号化表现等处理改造，形成用于水文地质信息服务平台的公共地理框架数据，主要包括基础框架要素、影像数据、三维数据、地名地址、地面高程模型和基础框架要素。地理框架数据由地理框架数据库管理系统生产、加工和维护等。建立水文地质数据中心，方便资源的整合和利用。3.1 数据库设计3.1.1 数据库设计原则3.1.1.1 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。3.1.1.2 主键与外键 一般而言，一个实体不能既无主键又无外键。在ER 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键。主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。3.1.1.3 基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。 理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。3.1.1.4 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。 为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。三个范式： 通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)： 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解； 第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。3.1.1.5 识别与正确处理多对多的关系 若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。3.1.1.6 主键PK的取值方法 PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。3.1.1.7 中间表、报表和临时表 中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。3.1.1.8 完整性约束域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通 过它定义字段的值城。 参照完整性：用PK、FK、表级触发器来实现。 用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。3.1.2 数据库表设计原则3.1.2.1 先局部后整体不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。3.1.2.2 领域模型驱动采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。3.1.2.3 满足范式标准根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1N或NN的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。3.1.2.4 建立索引应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其是表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。3.1.2.5 平衡考虑存储过程尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。3.1.2.6 表关联约束设计当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。3.2 技术路线结合目前水利数据中心现有的需求，ArcGIS提供了一系列解决方案来支撑水利数据中心的建设。3.2.1 统一数据标准利用ArcGIS Geodatabase可以对水文地质各种数据进行空间建模，整合现有种类不同、结构各异的分散数据库资源，按照水利部、省相关技术规范，制定统一数据库表结构及标识符标准。3.2.2 梳理水文地质数据资源入库把整理好的水文地质数据资源,最终按照预先定义好的数据模型，将数据加载到目标数据容器中。3.2.3 数据库体系建设结合水文地质行业特点分为基础库，专题库，元数据库，辅助数据的建设3.2.4 专业水文地质模型充分借鉴ArcHydro数据模型，ArcHydro 数据模型目前专注于地表水水文数据的组织，它是把GIS和水文地理领域知识相结合的水文地理数据模型。该模型是针对流域水文信息与水文模型集成存在的问题，在分析流域水文系统结构、总结目前水文模型需要参数的基础上，采用Geodatabase 地理数据库技术构建的水文数据模型，将对象的属性和对象的行为很好的结合在一起。ArcHydro 水文数据模型是面向对象的地理数据模型，它将要素、空间单元、水文联系等作为对象，表达流域系统的结构，组织不同对象的属性特征，实现最接近流域现实的表达；ArcHydro 水文数据模型集成了流域要素状态的时间序列，是一个时空地理数据模型；ArcHydro 水文数据模型包括了流域水文模拟最基本的流域要素和参数，是流域模拟的标准信息平台，它是一种基于ArcGIS 水文数据模型工具，它为基于GIS 的水文、水力学应用模型与GIS 的数据模型集成提供了一种途径。 建立流域地理数据库常考虑以下两种方法，具体如下： (1) 基于存储的数据模型：根据地表事物的属性，按目录的形式组织数据，将流域相关的要素表示为不同的点、线、面。这是设计地理数据库时最常用也是最容易实现的方法，是GIS组织数据的经典方法。但是在这种数据组织方式中，要素类与要素类之间没有关系，每个图层都是离散的。(2) 基于行为的数据模型：雨滴降落于地面后，先通过坡面汇流流入小河、后通过河网汇流流入大江大海，根据水流的运动属性，模拟这种行为。这种数据模型寻找并描述与行为相关的要素，阐明各要素间如何相互影响，并解释整个系统的行为。这是经典的水文建模方法，能够很好的描述水流的运动，使用者可以很方便的得知雨滴的流动方向和流动路径，获取河流的上下游关系。但是这种数据模型对研究区域内的水文环境缺乏描述，无法获取和水流相关的其他要素的信息（如无法获知某个取水口位于哪条河流上等信息）。4 服务层设计服务层设计采用基于面向服务架构（Service-Oriented Architecture, SOA）的基本思想和方法，包括服务提供方、服务使用方和服务中介三个基本角色：（1）服务提供方：是负责企业级GIS平台运行维护的部门，负责建立运行和维护企业GIS平台。 （2）服务中介：负责服务注册中心和门户网站的部署、运行和维护的机构，由平台的运行管理机构担当。（3）服务使用方：是通过标准接口调用在线地图与地理信息服务的各类专业系统开发人员和普通用户。另一方面，由于不同部门应用地理信息的复杂程度不同，在服务层除了以Web Services 方式对外提供在线服务以外，传统的地理信息离线分发还是不可或缺的。4.1 服务层构成服务层由系列基于标准接口规范的地理信息在线服务、门户网站及各类应用系统构成。应用系统是建立平台的最终目的，但不包含在平台内，利用平台提供的标准化网络服务，可以面向不同的部门、根据不同的应用需求开发建立特定的应用系统。比如面向综合资源，可以提供地图浏览、网络资源查询定位服务，业务图层编辑服务，与应用系统结合，可以提供巡检、资源查询、资源更新等多种应用；在市场营销通过消费数据和地理数据结合，可以提供基于地图的各类统计分析，为决策和经营层提供辅助。4.2 服务模式4.2.1 服务提供模式作为服务提供方的服务机构，须配备必要的计算机设备，并制作各类服务内容，部署各类符合接口规范的地理信息服务软件系统，成为企业级GIS平台网络中基础地图内容提供方。4.2.2 服务使用模式面向三种角色，服务的使用者主要包括四类，即普通用户、应用系统开发人员、服务提供用户和平台维护管理用户。（1）普通用户不需要注册和认证，可以直接访问浏览器或通用客户端软件获得各类基于在线地图和地理信息服务的业务系统。（2）应用系统开发人员可以通过调用系列网络服务实现平台地理信息与其自身业务信息的分布式集成，并快速构建业务应用系统。（3）服务提供用户需要部署各类符合标准接口规范的服务软件，使用服务管理系统完成服务注册和管理自己注册的服务信息，并可利用管理系统对自己发布的服务进行访问权限控制。（4）平台运行管理用户通过服务管理系统对平台中各类注册服务和注册用户实现综合管理，包括对服务注册信息审核、用户信息审核、用户权限管理、服务状态监测以及用户行为审计等。对于服务提供用户和平台运行管理用户，主要与平台的管理系统打交道。4.2.3 服务类型企业GIS服务平台具有两种服务资源，一类资源是数据资源，另一类是GIS功能资源，因此对外服务也主要是数据的共享发布和GIS功能的共享应用。按照数据服务和功能服务，可以将应用接口划分为两大类。一类是数据共享发布服务，为应用系统访问各类空间基础信息数据提供接口；另一类是空间处理与统计分析服务，为业务应用系统提供基于服务端的GIS分析功能服务。4.2.3.1 可视化服务4.2.3.1.1 地图服务地图服务以提供对电子地图的访问服务。创建地图服务之前，需要通过ArcGIS桌面产品或ArcGIS Engine开发的桌面应用创建地图文档，指定矢量和栅格数据源，创建专题图，设置注记，然后通过ArcGIS桌面或基于浏览器的ArcGIS Server管理器发布为地图服务。发布的地图服务可以预先创建地图缓存以提高地图显示和访问效率。地图服务是最常见的GIS服务。除了提供基本的地图浏览功能外，一些位于GIS功能服务层的服务也基于地图服务来实现，如地图查询服务、地图查找服务、地图编辑服务。4.2.3.1.2 Globe服务在ArcGlobe（ArcGIS桌面3D分析扩展模块的一部分）中创建的Globe文档可以发布为ArcGIS Server的globe服务。Globe服务提供对三维地球的访问能力，我们可以交互使用三维地球，并将它与其他地理信息叠加显示。我们可以在ArcGlobe，ArcReader和新的免费的ArcGIS Explorer应用中使用globe服务。4.2.3.1.3 OGC标准服务ArcGIS可以基于空间数据资源，发布基于OGC标准的服务，包括WMS服务、WFS服务、WCS服务等。4.2.3.1.4 KML服务KML服务是Google可以使用的标准服务。在ArcGIS中，可以将地图数据和三维空间数据发布为KML服务，被其他的可视化应用所使用。4.2.3.1.5 地图切片服务对平台的地图和影像数据服务，直接调用平台提供的图片服务接口，来提供服务。地图切片服务是为了满足多用户并发时对地图服务的高性能需求而组织开发的综合数据服务接口，它作为其他空间信息服务的有益补充，是一种获取地理空间信息的快速解决方案,它提供接口包括:基本操作：放大、缩小、平移、测距、测面积、鹰眼、打印等图元显示：包括显示点、线、面、文本、图标等数据查询和编辑：可以通过点选、框选、圆形选择等方式进行信息的查询；可以对图元进行增加、修改、删除。4.2.4 数据服务GIS数据服务也是GIS的基本服务类型，它通过直接发布空间数据库而获得，进而实现通过LAN、WAN或Internet访问空间数据库的能力。4.2.4.1 空间数据服务空间数据服务允许我们使用ArcGIS Server通过LAN，WAN或Internet访问空间数据库。空间数据服务可以使用任何类型的空间数据库，包括ArcSDE空间数据库，个人化空间数据库和文件空间数据库。但是从安全性，数据完整性，高性能和可伸缩能力方面考虑，ArcSDE空间数据库推荐使用企业级ArcSDE空间数据库。除了支持对空间数据库的查询操作，该服务还可以支持空间数据库的编辑，空间数据库复制，或通过指定空间范围，进行空间数据抽取、转换并下载到本地。4.2.4.2 移动空间数据访问服务提供移动终端对空间数据的访问能力。4.2.5 功能服务GIS功能服务主要指可以实现某些GIS特定功能和分析的服务，GIS功能服务往往需要依托于GIS可视化或数据服务来实现，或者在调用GIS功能服务时，往往需要同时调用GIS可视化或数据服务。4.2.5.1 空间分析服务在地理信息共享平台业务应用系统中，涉及到很多专业的分析模型，这些模型以空间数据为基础，分析的结果需要在用户应用中展现。ArcGIS Server提供一个简单的机制可以将ArcGIS桌面中构建的空间分析工具和模型发布为服务器上的服务，供远程的客户端调用，而其本身在服务器端执行。这种将空间分析模型和脚本发布为Web服务的能力，使得GIS服务器变得异常强大。这些空间分析服务可以被多种客户端访问和使用，包括浏览器，免费的ArcGIS Explorer，ArcGIS桌面产品以及通过ArcGIS Engine构建的应用等。4.2.5.2 地图查询服务地图查询服务基于地图服务或空间数据服务来实现，支持通过鼠标点击方式对空间数据进行基于空间位置的属性查询。4.2.5.3 地图查找服务地图查找服务基于地图服务或空间数据服务来实现，支持通过关键字对存储在空间数据库中的关键内容进行查找。4.2.5.4 地图编辑服务地图编辑服务基于地图服务或者空间数据服务来实现，支持通过浏览器对空间数据直接进行编辑。4.2.5.5 空间数据抽取（空间数据转换）服务空间数据抽取（空间数据转换）服务基于空间数据服务来实现，可以通过用户指定特定空间区域，将该范围的空间数据转换为用户指定的数据格式，并下载到本地。4.2.5.6 空间数据复制服务空间数据复制服务基于空间数据服务实现，可以基于增量方式同步分布式空间数据库的内容。可以将ArcSDE空间数据库在Internet上发布为空间数据服务。然后我们可以通过空间数据服务定期在Internet上进行同步更新，在两个数据库服务器间共享变化的部分。4.2.5.7 地理编码服务此服务提供通过地理编码进行空间位置定位的服务。4.2.5.8 GIS目录服务提供基于服务元数据的目录查找服务和GIS服务列表。4.2.6 空间信息服务实现流程4.2.6.1 服务内容的创建GIS资源是用于创建GIS服务的基础，包括符号化的二维地图，用于可视化的三维地图、进行空间分析的模型以及用于共享的空间数据库等。GIS资源和GIS服务对照表从上表，我们可以看到GIS资源和GIS服务的对应关系。创建GIS资源的工作可以在ArcGIS的桌面系统中完成。二维地图文档的创建，包含图层的管理、加载、符号设置、空间参考设置等。三维地图文档的创建需要在ArcGIS的三维环境ArcGlobe中完成。而空间分析模型则可以基于ArcGIS桌面的可视化建模环境Model Builder，采用交互式方式，拖拽相应的GIS分析工具，进行搭建；也可以基于Python脚本或ArcObjects进行二次开发。在进行内容组织时， 地图服务可被视作与本地数据相同的数据源来操作。来自外部或内部的地图服务，如WMS/WFS服务，可以与本地的数据同时被加载并显示。根据服务类型的不同支持对地图服务层进行不同的操作。多个地图服务以及本地数据可在服务器端被聚合，并发布成另外的服务，即服务器端的服务聚合。在这一过程中，不需要单独的服务聚合器。服务器端服务聚合下图为ArcGIS Server服务器端进行聚合的应用示例，本图展示的是将ArcGIS所发布的地图服务和Google地图服务在应用服务器端融合的效果，可以清楚的看到Google的底图上叠加着ArcGIS发布的山东省区域地图。对于用户来说，无论是C/S还是B/S的应用，可操作的GIS资源的来源都是一致的。用户无需专门为共享的服务框架准备GIS资源。在桌面系统中创建的地图文档、空间分析模型、空间数据库既可以在C/S应用中直接调用，也可以直接方便地转化为GIS服务，在B/S环境下被调用。空间分析服务内容的创建基于空间分析模型搭建环境。ArcGIS提供一个完备的空间处理框架，主要包括两个部分：ArcToolbox 一个空间处理工具集和ModelBuilder 为建立空间处理流程和脚本提供的可视化的建模工具。通过交互式的方式，用户在可视化建模环境ModelBuilder中添加参与分析的数据源、加载各类空间分析工具，自定义和组合空间处理流程，配置模型参数，该环境还支持对外部模型的集成。分析模型还可以进一步转换为脚本，以后台运行的方式执行。这个框架方便了对空间处理模型的创建、使用、说明和共享。用户可以根据自身需求灵活自主搭建空间分析模型。分析模型可以很方便地发布为空间处理服务，供外部应用基于网络进行调用。4.2.6.2 服务的发布基于预创建的服务内容，可以便捷、高效的直接发布多种类型的服务，包括可视化、功能类型服务。发布的服务会宿主至少一个服务器进程，支持进程占用模式的按需设置，即设置实例和进程间的关系，例如独立实例进程，拥有独立的计算资源，实例间互不影响，便于应用效率的提升和服务故障的排查。发布服务时可给予支持空间服务器对象池化（Pooling）机制，获得多用户并发访问性能，提升请求响应速度。4.2.6.3 空间处理服务发布空间分析模型可以很容易发布为空间处理服务。这类服务集中在服务器端提供数据和GIS分析功能，供远程的客户端基于网络进行调用。ArcGIS Server提供的将空间分析模型和脚本发布为Web服务的能力，使得它变得异常强大。这些分析服务可以被包括浏览器在内的多种客户端访问和使用。相比较与其他类型的服务，因GIS的分析功能通常较为复杂，且运行时间较长。ArcGIS专门设计了空间处理服务可以以同步或异步的方式运行。在同步运行状态下，客户端会一直处于等待状态，直到服务器端运行模型结束，返回结果；在异步运行状态下，客户端提交了执行服务的请求后，可以继续执行其他任务。同时定时向服务器端发送请求，获得服务器端运行状态。通过ArcGIS的空间处理框架，可以通过非编程方式直接将空间分析模型发布为空间处理服务。空间处理框架为面向用户需求，提供支持决策分析的空间处理服务提供了无限的扩展性和可能性。5 系统应用层设计水文数据中心的建设最终是为水文地质信息系统平台服务，根据目前水文地质的应用需求，系统提供主要应用如下：5.1 水文地质数据采集子系统系统支持对水文地质调查、检测、钻孔等多源异构数据（空间数据、文档、图像、视频）的导入、存储、预览和统一管理，并能为数据的访问提供统一的接口和权限控制，支持各种图形化的显示和专题显示，管理区域的钻孔、水文地质数据的管理。提供DEM编辑工具，可以对DEM数据进行编辑更新。5.2 数据管理子系统系统支持用户根据自己的需要灵活选择地图数据维护管理、存储的模式。提供了浏览电子地图的工具，如放大、缩小、漫游、全图、按照固定比例放大、按照固定比例缩小、上一视图、下一视图等等，也可以使用鼠标右键中提供的快捷菜单对电子地图进行浏览操作。提供对水文数据中心现有资料的快速检索。5.3 二三维一体化展示子系统系统提供统一的二维视图管理界面，可叠加展示影像数据、地图数据、矢量数据、地形高程数据以及勘察钻孔数据，视图支持放大、缩小、漫游、全屏等基本操作，同时提供基本的图层渲染和控制，方便人工目视判读。5.4 三维建模子系统系统可根据钻孔、地形、地质及三维属性数据生成三维空间模型，生成模型可保存和导出为其它主流的三维模型数据；对钻孔、地层等结果数据建立统一的三维符号、模型库，便于批量建模。具体建模方法：1）通过钻孔点构建体。通过点建模思路较为简单，将所有钻孔点中数据整理完成之后，抽取出每个地层分界面上的点数据，再将每个分界面插值层一个表面，通过每两个表面之间构成一个体，保存为ArcGIS的格式，最后将所有的体构成一个完整的矿体模型。2）通过剖面线建模通过剖面线建模的方法与通用算法较为一致，主要使用ArcMap完成剖面线的连接过程，也可以将其他GIS平台的剖面直接转为ArcGIS中使用。通过面插值成多面体。5.5 系统管理子系统支持进行权限控制，划分不同的用户组，提供用户管理、功能权限管理、数据权限管理，对系统用户及权限的增删改查、菜单和工具箱管理等功能；6 实施方案项目组织结构图为保证本项目的顺利实施，我们将分别成立项目管理协调委员会、咨询专家组、项目管理组、项目研发组、质量管理组、项目集成组、数据准备组等多个项目小组，分工合作。项目管理协调委员会由XXXXXXXX、XXXXXXXX有限公司联合成立，负责项目的变动控制、质量保证检查，风险监督控制、项目进度检查等工作。项目经理组是项目组织、保障的具体管理负责小组，项目总负责人由XXXXXXXX有限公司安排，其他人员和工作职责由三方在项目正式启动时共同协商确定。项目研发组负责平台的设计与开发工作，负责系统的需求分析、总体和详细设计以及功能模块的代码编写、软件测试等开发工作，由XXXXXXXX有限公司人组织10名以上相关技术骨干组成。质量管理组负责整个项目需求调研、设计、开发、系统集成和交付等环节的质量保证。由北京捷泰科技有限公司的质管人员组成，湖北省测绘局地理信息中心指定系统管理员参与。数据准备组主要负责各种数据源的数据服务的准备工作，确保数据的质量和进度满足项目实施的需要。主要将由XXXXXXXX有限公司派技术人员负责实施，XXXXXXXX派人参与协助。用户培训组主要负责针对用户的相关技术培训工作，确保用户获得项目有关的全面的技术培训内容。培训教师由XXXXXXXX有限公司人员组织。售后维护组主要负责项目的售后维护，在项目后期及项目开发完成后入场，通过各种技术手段和实现形式，向用户提供及时、有力的售后服务。7 技术支持计划1.1 技术支持流程用户可以通过我公司的售后服务热线，随时要求本公司提供技术支持服务。公司将根据用户的服务合同号，将电话转接到相应的技术服务工程师。服务工程师为用户提供电话维护和咨询，必要时即赴现场维护以及在需要时提供相应的备件服务，力求尽快的为用户解决问题。另本公司会将会定期地将反馈表寄给用户，征求意见。故障优先级定义公司使用4级故障等级来定义系统故障的严重程度：故障级别一：系统瘫痪-现有的系统瘫痪，或对用户的业务操作有重大影响。故障级别二：严重退化-现有系统性能令人无法接受，将对用户的业务操作产生消极的影响。故障级别三：性能的削弱-系统性能削弱，但用户业务操作仍可继续。故障级别四：信息或援助-用户需要关于产品性能安装、配置方面的信息或援助。公司对不同级别的故障明确定义了故障解决时限，并且绝大多数故障将在限时内解决。对于服务超时（即在限时内不能解决故障）本公司具有明确定义了服务超时上报程序。服务超时上报程序定义从接电话后的持续时间故障级别一故障级别二故障级别三故障级别四1小时用户服务工程师技术支持主管4小时用户服务部总监用户服务工程师技术支持主管6小时副总经理用户服务部总监用户服务工程师技术支持主管8小时总经理副总经理用户服务部总监技术支持主管用户服务工程师12小时总经理用户服务部总监以上时间以12小时一天为准。1.2 用户服务模式在系统维护方面，服务模式的特征主要体现在以下三个方面：远程支持：在传统维护概念中，现场支持是解决故障的第一步骤。而在计算机网络技术的维护概念中，远程支持是解决故障的第一步，在时效上远程支持将明显高于现场支持模式。因为用户服务部可以集中本公司的所有技术知识，而现场维护人员基本上是基于本身的技术知识。基于统计数据表明，80%的设备故障属于软件故障，并且可以通过远程维护方式解决；20%的设备故障属于硬件故障。在线支持：在传统维护模式中，维护手册是维护技术人员的必读之物，但是在新通信技术维护模式中，在线故障数据库以其信息量和及时性将逐步替代维护手册。公司对于具有普遍意义的设备故障通过故障数据库确定故障解决方案。由于IP技术的高速发展，数据中心的应用被广泛接受，故障数据库中的数据也日益广泛和详尽。基于本公司的统计，60%的故障可以通过故障数据库得到排除故障的答案。故障解决方案使所有使用新技术设备的最终用户在排除故障的技巧和技术上保持统一的水准。并得以两个明显益处：对第一次出现的故障产生“似曾相识”的感觉，建立信心；根据故障数据库中所建议的方案排除故障可以保证排除故障的准确性并提高时效。现场支持：如在远程支持、在线支持不能解决系统故障时，我公司将派工程师进行现场的支持，并在最短的时间内指派专业人员进行现场故障排除，并进行故障预防性处理。系统故障排除后，就故障进行分析，提供故障情况报告，以帮助系统管理员进行系统管理工作。定期维护：我公司将制订预防性维护时程，其日程安排以不影响用户正常工作为前提。预防性的维护包括：软硬件系统协调性测试，数据资料备份检查等，以期在问题出现之前就能够发现问题并采取相应的措施，以避免问题的发生或堆积。1.3 技术支持标准系统维护:在本系统进入正常运行后，本系统的维护工作主要由本公司提供为期三年免费维护、我们维护要求立即做出响应，能远程维护解决及时解决，如不能解决的，2-4小时内到达现场进行维护。本系统修改、增加系统功能，应用系统和操作系统等升级的处理方法：当客户提出对系统修改、增加功能，应用系统和操作系统等升级时，我们将及时响应，并根据用户不同的要求（如有需要，我们将进行现场调研），最长在一周时间提交解决方案及完成的周期相关问题。本系统更改时文档变更方法：在对系统修改、增加功能，应用系统和操作系统等升级时，我们将根据不同的情况，或对原文档进行补充说明，或对原文档进行整体更新。