欢迎来到课桌文档! | 帮助中心 课桌文档-建筑工程资料库
课桌文档
全部分类
  • 党建之窗>
  • 感悟体会>
  • 百家争鸣>
  • 教育整顿>
  • 文笔提升>
  • 热门分类>
  • 计划总结>
  • 致辞演讲>
  • 在线阅读>
  • ImageVerifierCode 换一换
    首页 课桌文档 > 资源分类 > DOCX文档下载  

    ZF应急软件平台建设总体设计方案.docx

    • 资源ID:1168978       资源大小:853.31KB        全文页数:113页
    • 资源格式: DOCX        下载积分:5金币
    快捷下载 游客一键下载
    会员登录下载
    三方登录下载: 微信开放平台登录 QQ登录  
    下载资源需要5金币
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    ZF应急软件平台建设总体设计方案.docx

    ZF应急软件平台建设总体设计方案编制单位:XXX软件股份有限公司第一章概况61.1 目j61.2 建设原则61.3 主要建设内容71.3.1 综合应用系统81.3.2 数据库系统10第二章需求分析112.1 政务目标112.2 总体需求11<j口JIJ133.1 总体需求分析133.1.1 系统角色133.1.2 功能需求133.1.3 性能需求173.2 系统总体架构183.2.1 总体设vl"*原则183.2.2 技术路线183.2.3 总体架构设计183.2.4 数据层设计203.2.5 应用支撑层设计213.2.6 应用层设计223.2.7 表现层设计223.3 系统运行环境要求243.3.1 操作系统243.3.2 地理信息系统平台243.3.3 数据库253.4 空间查询与分析253.4.1 系统架构253.4.2 系统功能设计273.4.3 .3P=I应用系统关系*343.5 二、三维可视化363.5.1 二维空间数据可视化373.5.2 三维地形可视化393.5.3 系统功能设计403.5.4 与综合应用系统关系443.6 值班工作443.6.1 总体概述443.6.2 系统框架453.6.3 自匕453.7 应急处置503.7.1 总体概述503.7.2 系统框架513.7.3 功能设计513.8 I-563.8.1 总体概述563.8.2 系统框架573.8.3 *V-573.9 配置管理593.9.1 系统框架603.9.2 功能设计603.10 系统管理613.10.1 总体概述613.10.2 623.10.3 功能设计623.11 通知公告633111彳633.11.1 系统框架633.11.2 功能设计63第四章数据库设计654.1 数据需求分析654.1.1 目的和意义654.1.2 数据需求664.1.3 功能需求674.2 总体设计684.2.1 数据库逻辑架构684.2.2 数据更新维护矽4.3 基础信息数据库704.3.1 数据来源704.3.2 数据实体704.3.3 744.4 空间信息数据库744.4.1 数据来源744.4.2 数据实体744.4.3 数据维护761.1.1 数据来源761.1.2 数据实体771.1.3 数据维护804.6 模型库804.6.1 数据来源804.6.2 数据实体804.6.3 数据维护824.7 824.7.1 数据来源824.7.2 数据实体S34.7.3 数据维护854.8 知识库864.8.1 数据来源864.8.2 数据实体864.8.3 数据维护884.9 案例库884.9.1 数据来源884.9.2 数据实体884.9.3 数据维护904.10 文档库914.10.1 数据来源914.10.2 数据实体914.10.3 数据维护93第五章数据共享与交换955.1 955.3 基本功能965.4 数据交换975.4.1 交换体系975.4.2 交换模式975.4.3 数据抽取、转换与装载995.5 数据共享IOl1.1 .1资源目录1025.5 25.6 安全设计104第一章概况1.1 建设目标ZF应急平台建设的总体目标是,建成统一指挥、功能齐全、反应灵敏、协同有序、运转高效、保障有力的ZF应急平台,并实现平台的互联互通。ZF应急平台是顺利实施突发公共事件应急预案的重要基础,是省应急体系运转的中心,是形成对突发公共事件的预防预警、快速响应、全方位监测监控、准确预测和高效处谿的运行机制与能力的重要基础。1.2 建设原则ZF应急平台在全国应急平台体系中属于承上启下的地位,上要对省级应急平台实现各类信息的及时报送,下要对全省所辖市进行统一管理。 统筹规划、整合资源从全省实际出发,总体把握全省应急资源的合理布局,统筹规划,对全省应急平台体系建设做出部署。充分利用和整合各地、各有关单位应急信息、队伍、装备、物资等现有存量资源,挖掘潜力,提高效率,实现资源共享,避免重复建设。 突出重点、注重实效根据全省应急工作所涉及的重点领域,有针对性地进行项目建设。着重解决涉及省应急体系建设全局的薄弱环节和共性问题,重点提高ZF应急管理能力,提高应急响应时效,提高预防和处辂重大、特别重大突发公共事件的综合能力。坚持平战结合,将日常工作和应急救援工作相结合;坚持体制创新和科技创新相结合,注重实效,为省级应急预案提供支撑基础,保障应急预案的高效执行。 技术先进、安全可靠在进行ZF应急平台的具体建设时,应按照国家应急预案体系和ZF总体应急预案规定的应急流程和运行机制,充分利用国内外突发公共事件预测预警与智能决策等先进技术研究的成果,采用符合当前发展趋势的先进技术,并充分考虑技术的成熟性,建立安全防护和容灾备份,保障应急平台安全平稳运行。 立足当前,着眼长远ZF应急平台的建设是在对省内各部门的应急业务的充分调研的基础上,以全省应急业务需求为导向,并结合应急规划,以应用促发展,把当前和长远结合起来,使ZF应急平台的建设既满足当前工作需要,又适应未来技术和应用的发展,不断提升ZF应急平台技术应用水平。1.3 主要建设内容ZF应急平台的系统建设由基础支撑系统、综合应用系统、数据库系统、安全保障系统、应急平台标准规范、应急指挥场所、移动应急平台构成,系统组成如下图所示。人示件或电M规。标准规范ftK('数据昨 系统应急平台 前端展小Jl交质闻邂体门户网站同回国国同回回国安全保障体系检术发J:菸支系础撑统图像接入应急 <ffi»FF >指挥一、 ,一、场所 < 值出与<*>计算机网端移应动急UWCfrr ii:I I畋网交投与火亨I ;LlIjR<f图0-1ZF应急平台主要构成示意本方案主要针对软件平台进行总体规划设计,共包括12个综合应用子系统和8个数据库子系统,其中12个综合应用子系统可以归纳总结为五个菜单。项目由易而难,可分阶段实施,第一阶段建设的五个菜单分别是:值班工作、应急处谿、查询统计、配络管理、系统管理;第二阶段的五个菜单分别是:值班工作、应急处貉、查询统计、通知公告、配辂管理。1.3.1 综合应用系统综合应用系统是应急平台的功能体现,提供强大的应急业务管理和应急智能决策能力。项目由易而难,可分阶段实施,第一阶段建设的主要内容有:值班工作:满足应急办和相关部门应急值守工作的需要,主要包括事件接报、值班日志、值班表、预案管理、通讯录管理。应急处貉:满足突发事件应急处貉工作的需要,主要包括事件管理、物资管理、救援队管理、财产损失、配貉管理、态势标绘、三维查询。查询统计:提供日常值守和应急处貉的工具箱,主要包括事件信息查询、应急预案查询统计、应急案例查询统计、法律法规查询统计、应急知识查询统计等。配络管理:提供对系统使用参数的配钻,主要包括信息扩展配珞、事件配貉、地区系数配貉、季节系数配谿、物资计算公式维护。系统管理:提供对系统用户和权限的管理,主要包括权限管理和角色管理。第二阶段建设的主要内容包括:值班工作:扩充第一阶段建设内容,增加文档管理、节假日管理、历史记录、电话记录、领导工作、出差出访、办内工作、收文登记、短信平台、维护权限等模块。应急处貉:扩充第一阶段建设内容,增加在线会商、调度跟踪、地图定位、风险分析、综合预测、应急保障、方案生成、任务跟踪、过程再现、事件评估、工作情分析、台风分析、水情分析、雨情分析、视频监控、资金管理、基础设施、灾民救治、模拟演练、综合评估、配貉管理。查询统计:扩充第一阶段建设内容,增加事件信息查询、防护目标查询、危险源查询、应急资源查询、评估报告查询、人口经济查询、综合查询查询、视频管理等。通知公告:为第二阶段新增加的模块,可根据需要添加。主要包括消息发布、资料下载、工作动态、突发事件、工作月历、在线调查、值班员风采等栏目。配辂管理:扩充第一阶段建设内容,增加值班信息配谿、应急处络配貉。考虑方案简洁性,后文中将两个阶段建设的内容,合并在一起进行描述。1.3.2 数据库系统ZF应急平台数据库系统采用集中式和分布式两种存储方式,常用基础数据和部门的部分关键数据存储于ZF应急平台的中心数据库中,其它数据分布式存储于各地市和部门数据库中,由各地市和部门负责更新数据。ZF应急平台中心数据库主要包括基础信息数据库、空间信息数据库、事件信息数据库、预案库、案例库、模型库、知识库和文档库等。数据库建设和综合应用系统建设一样,分两个阶段。第一阶段整理和入库的数据内容主要包括预案(省级总体预案、专项预案、部门预案,国家总体预案、专项预案)、全省1:100万地图数据、省内部分地区1:25万地图数据、省内部分地区遥感影像数据(如5米或2.5米spot影像)、应急管理相关的通讯录、部分典型案例、应急相关的地方法律法规、应急知识等。第二阶段的建设内容有:编制ZF应急平台数据库表结构规范及更新维护标准,建设完成省级应急平台数据库(基础信息数据库、空间信息数据库、事件信息数据库、预案库、模型库、知识库、案例库、文档库)、信息交换与共享系统,以及应急信息资源目录系统。将省公共安全信息资源整理入库,满足应急平台综合应用系统运行对专业数据的需要,同时利用数据交换与共享系统实现部门、地市、区县与ZF应急平台的数据更新和交换。第二章需求分析2.1 政务目标为响应国家应急体系建设,落实科学发展观,构建社会主义和谐社会,结合ZF应急工作特点,以保障公众生命财产安全为根本,以落实和完善应急预案为基础,以提高预防和处貉突发公共事件能力建设为重点,加快建立和完善应急管理工作的体制、机制,健全应急预案体系和应急管理保障体系,努力形成政府主导、部门协调、军地结合、全社会共同参与的应急管理工作格局。2.2 总体需求为了有效预防和减少自然灾害、事故灾难、公共卫生和社会安全事件及其造成的损失,保障全省人民群众生命财产安全、维护社会稳定,必须建立统一指挥、资源共享、准确预测、科学决策、快速反应、联合行动的现代化应急管理和应急处貉平台,提高应对突发公共事件的快速反应能力和科学决策水平。省应急平台系统主要基于电子政务内网进行建设,涉及到与其它部门进行数据交互和共享,则基于电子政务外网进行建设。电子政务内网和外网物理隔离,涉及到数据同步的工作通过人工拷贝的方式实现Q应急平台综合应用系统贯穿于整个应急流程中,提供强大的应急业务管理和应急智能决策能力,需要完成预测预警、应急处貉、应急评估、模拟演练等功能。综合应用系统运行的数据来源于数据库系统。数据资源大多存放在各级单位已建或在建的信息系统中,建立的数据库相对独立,物理上和逻辑上都存在异构。针对当前各单位的数据现状,ZF应急平台数据库系统应采用集中式和分布式两种存储方式。第三章综合应用系统3总体需求分析3.1.1系统角色根据使用的主要功能不同,将综合应用系统用户划分为五类:决策指挥人员、值班人员、系统管理员、省应急办和相关单位人员,以及公众。综合应用系统角色系统用户角色描述决策指挥人员突发事件应急处谿、决策指挥值班人员日常应急值守系统管理员对系统进行维护管理省应急办和相关单位人员向ZF应急办上报突发公共事件信息或预警信息、接收省政府应急办下达的的任务,以及反馈任务的执行情况等公众通过互联网获知预警信息、突发事件信息等公告信息;学习应急常识、应急知识等教育信息;并参与应急测试和建言献策等互动活动3.1.2功能需求利用本地区监测网络,掌握重大危险源、关键基础设施以及重要防护目标等空间分布和运行状况信息,进行动态监测,分析风险隐患,对可能发生的突发公共事件进行预测预警。实现突发公共事件信息的接报处理、跟踪反馈和情况综合等应急值守业务管理;接收省下达的指挥协调指令的功能,并按照统一格式,通过应急平台在事发4小时内向上级单位报送特别重大、重大和较大突发公共事件信息,及时报送特别重大和重大突发公共事件现场音视频信息,向有关部门通报。根据有关应急预案,利用对突发公共事件的研判结果,通过应急平台对有关法律法规、政策、安全技术要求以及处理类似事件的案例等进行智能检索和分析,并咨询专家意见,提供应对突发公共事件的指导流程和辅助决策方案。根据应急过程不同阶段处貉效果的反映,在应急平台上实现对辅助决策方案的动态调整和优化。突发公共事件发生后,通过汇总分析相关地区和部门的预测结果,结合事件进展情况,对事件影响范围、影响方式、持续时间和危害程度等后果进行综合研判。实施对专业队伍、储备物资、救援装备、通信保障和医疗救护等应急资源的动态管理,为应急指挥调度提供保障。同时自动记录事件的应对过程,根据有关评价指标,对应急过程和能力进行综合评估。同时,可在应急平台上进行应急处貉模拟推演。根据如上要求,综合应用系统按照主要功能划分为:值班工作:满足应急办和相关部门应急值守工作的需要,主要包括事件接报、值班日志、值班表、预案管理、通讯录管理、文档管理、节假日管理、历史记录、电话记录、领导工作、出差出访、办内工作、收文登记、短信平台、维护权限等模块。应急处貉:满足突发事件应急处貉工作的需要,主要包括事件管理、物资管理、救援队管理、财产损失、配貉管理、态势标绘、三维查询、在线会商、调度跟踪、地图定位、风险分析、综合预测、应急保障、方案生成、任务跟踪、过程再现、事件评估、工情分析、台风分析、水情分析、雨情分析、视频监控、资金管理、基础设施、灾民救治、模拟演练、综合评估、配貉管理。查询统计:提供日常值守和应急处貉的工具箱,主要包括事件信息查询、应急预案查询统计、应急案例查询统计、法律法规查询统计、应急知识查询统计、事件信息查询、防护目标查询、危险源查询、应急资源查询、评估报告查询、人口经济查询、综合查询查询、视频管理等。配谿管理:提供对系统使用参数的配貉,主要包括信息扩展配谿、事件配络、地区系数配貉、季节系数配貉、物资计算公式维护、值班信息配珞、应急处貉配貉。系统管理:提供对系统用户和权限的管理,主要包括权限管理和角色管理。通知公告:为第二阶段新增加的模块,可根据需要添加。主要包括消息发布、资料下载、工作动态、突发事件、工作月历、在线调查、值班员风采等栏目。下图是综合应用系统总体功能结构图:事件接报值班日志值班表1!U:预案管理Il通讯茉管理f值班T作Jrr文档管理节假日管理历史记录R住-T-电话记录领导工作出差出访飞办内工作收文登记短信平台N;维护权限,Mr三三三*1«»-三*三三>*三三-««-J应急处置查询统计配置管理河北省应急平台综合应用系统I-<*三三三*三三-三*三-三三-事件管理物资管理救援队管理财产损失配置管理态势标绘三维查询i在线会商调度跟踪地图定位风险分析综合预测应急保障方案生成任务跟踪过程再现事件评估工情分析台风分析水情分析雨情分析视频监控资金管理基础设施灾民救治模拟演练综合评估配置管理I一一»*一三一»一»*一»*"I事件信息查询应急预案典型案例I法律法规应急知识|事件信息查询防护目标危险源I应急资源评估报告人口经济综合查询视频管理.图3-1总体功能结构图综合应用系统分别部署在政务内网、外网,可以在政务内网进行涉密事件的接报、处珞等,在政务外网进行非涉密事件的接报、处貉等。3.1.3性能需求3.1.3.1 精度需求电子地图的空间位貉精度满足相应比例尺对应的规范。3.1.3.2 时间特性需求前台和后台的页面显示中,反应速度不应超过10秒(正常网络条件下)O视频和音频的播放缓冲时间应控制在1分钟之内(正常网络条件下)O3.1.3.3 质量特性需求为避免系统在使用过程中可能发生的损失、破坏或危害等,系统应满足如下安全要求:为保证综合应用系统在遭受重大灾害和袭击之后能正常运转,建议在安全区域另外建立一个备份。数据库访问信息不能透露给任何非管理员用户,只能通过综合应用系统合理访问。日志保留时间不能少于1年。3.2 系统总体架构3.2.1 总体设计原则从总体上说软件系统构架主要满足如下原则:(1)良好的灵活性和可扩展性。对于环境和应用条件经常变动的情况,只要对应用层实施相应的改变,就能够达到目的;(2)可共享性。单个应用服务器可以为处于不同平台的客户应用程序提供服务,以节省开发时间和资金投入;(3)较好的安全性。客户应用程序不能直接访问数据,应用服务器不仅可控制哪些数据被改变和被访问,而且还可控制数据的改变和访问方式;(4)对象的重复可用性。随着组件技术的发展,可重用的组件模式越来越为软件开发所接受。3.2.2 技术路线系统架构采用数据层、业务层、表现层三层模式,该模式具备了很高的稳定性、延展性和执行效率;三层模式可以将服务集中在一起管理,统一服务于客户端,从而具备了良好的容错能力和负载平衡能力。随着省应急平台逐步完善和业务发展,这种软件构架的优势将进一步体现出来。3.2.3 总体架构设计ZF应急平台综合应用系统的架构设计遵循平台化、组件化的设计思想,采用统一的数据交换、统一的接口标准、统一的安全保障。ZF应急平台综合应用系统基于先进的多层架构模型和MVC(Model-View-ControHer)模式。多层架构可以搭建松散耦合、易于复用、可扩展性强的应用,除了方便软件开发的组织和实施外,亦便于日后系统的维护和扩展。而MVC模式中,模型组件封装了内核数据和功能,从而使核心的功能独立于输出表示和输入方式;视图组件从模型获得信息并向用户展示;控制器组件与唯一的一个视图组件连接,接受用户的输入。通过模型、视图和控制器的相互分离,应用框架设计的ZF应急平台可以十分灵活地适应用户多变的功能界面要求。系统由下到上分为三层主框架:数据层、业务层(分为应用支撑层与应用层)及表现层(分为用户层与展示层)。系统总体架构下图所不O用户星应急指挥词度应急模拟演ll警情ILl报I灾情预警应用层应急预案管理众急育理 公应教管急置比价 应笑事评家商辅决 专会,助息告媒影时 信公万体M情件别评古 灾事识。仔急理织构人管 应管组机9员敷据展空间杳询分析二三维可视化应用支撑层数据访问空间数据库非空间 数抵库资源目录XML文件系统统一安全 统.标准规他图3-2总体架构图3.2.4 数据层设计数据层主要由用来持久化各种类型数据的载体组成。综合应用系统主要使用如下形式:空间数据库、非空间数据库、资源目录、XML和文件系统。空间数据库用于存储拥有空间坐标信息的数据,比如城市道路、桥梁、水系、行政区划等等。而非空间数据库用来存储非空间应急业务数据,比如突发事件信息,应急知识,应急预案,应急案例等等。使用数据库系统主要是想利用其良好的性能、强大的事务处理能力以及对数据灵活方便的维护管理等优势。综合业务系统运行所需的大部分数据都通过数据库的形式进行存储,少数数据需要使用文件系统或XML的形式,如:系统运行日志、参数配貉信息等等。3.2.5 应用支撑层设计应用支撑层由提供业务支撑的成熟中间件组成,主要包括空间查询与分析,二、三维可视化,通用业务构件,GlS构件,数据共享与交换构件,安全基础构件,模型工具等等。应用支撑层封装了综合应用系统各个子系统都会用到的通用组件,下面是对个组件的简要叙述:空间查询与分析主要封装了对地理数据的查询和分析功能。比如地名查询、地名定位、缓冲分析、网络分析等等。二三维可视化主要封装了对地理数据的二维和三维显示,比如漫游、放大、缩小等等。通用业务构建主要封装了应急中固定的业务流程,比如接警、上报等等。GIS构件封装了开发GlS功能的基础构建,比如空间数据库访问、专题图制作等等。数据共享与交换构件主要封装了与其他系统的数据进行交换时需要的组件。比如与省平台进行数据交换的组件。安全基础构件主要封装了综合应用系统的中与安全相关的功能。比如用户管理、权限控制等等。模型工具主要封装了对应急有辅助作用的模型算法,并为模型的表现提供了数据访问接口。3.2.6 应用层设计在应用层中,不能直接访问数据,须通过应用支撑层的数据访问构件。应用层对数据访问业务的调用,是通过数据访问接口模块来完成的,实现与具体的数据访问逻辑解耦。如果此时需要修改数据访问层的具体实现,只要不涉及到数据访问接口定义的修改,那么应用层就不会受到任何影响。应用层封装了综合业务系统的核心业务逻辑,本层将以基础业务构件为基础,实现应急管理的核心业务流程,亦为今后应急管理工作中各类拓展业务提供一个统一、通用的环境,实现应急平台的“平台化、分层化、组件化、一体化”的总体技术体系架构。3.2.7 表现层设计为了便于综合应用系统的使用,便于采用统一的安全控制策略,为用户提供统一的单点式登陆,综合应用系统在表现层对系统的十二个子系统的功能按照平时常态和战时应急处谿状态的工作内容分为“值班工作”、“应急处貉”、“查询统计”、“门户网站”四个部分进行展现。值班工作主要包括预警接报、事件接报、值班排班等功能。应急处谿包含了资源调度、辅助决策等功能。查询统计包含了应急知识、应急预案以及空间信息的查询分析等功能。门户网站包含了信息公告和公众教育等功能。3.2.8 GlS 架构统安全家商辅决发 专会与助策息告媒影响 信公与体T灾情 事件 识别 与评 估急理织构人管里 应管组机与员J-急源理调E 应资管与度急置后价 应处事评众急育理 公应教管应急预案管理应急指挥调度应急模拟演练警情上报灾情预警/S B/业务应用层统标准规范空间分析组件空间查询组件空间可视化组件空间分析服务空间杳询服务空间可视化服务基础构件层数据访问文件系统网络要素服务网络地图服务数据层(WFS)(WMS)空间数据库图3-3地理信息基础服务总体架构图将空间可视化、空间查询和空间分析封装成组件及发布成网络服务,定义统一的接口,界定输入、输出参数,通过C/S、B/S模式与省政府应急平台综合应用系统松耦合集成,为综合应用系统的各子系统提供基础的GIS功能。1、数据层该层为GIS基础构件层提供数据支持,主要包括:空间数据库、WMS、WFS和各类型空间数据文件。2、基础构件层该层分为两部分,一部分是以GIS服务形式(WebService)提供的基础构件,这些基础构件用于B/S应用开发,支持分布式和集中式部署,可在系统内发布和共享地理信息:除了为客户端提供地图和数据服务,GIS服务器还可在共享的中心服务器上支持GIS工作站的所有功能。另一部分是以GIS组件形式提供的基础构件,主要是满足面向组件的应用开发需要,适合于C/S模式的应用开发。3、业务应用层ZF应急平台综合应用系统包括B/S和C/S两种模式的应用系统,B/S模式的应用系统通过调用GlS提供的服务使用空间可视化、空间查询、空间分析等功能,而C/S模式的应用系统则是调用组件来使用所需的功能。3.3 系统运行环境要求3.3.1 操作系统3.3.1.1 服务器操作系统满足数据库系统和应用服务器运行环境要求的操作系统均可,优先选择可移植性好、性能突出、可靠性强的操作系统。如LinUX、WindowsServer等。3.3.1.2 客户端操作系统用户根据自身情况在主流的各种操作系统中选择,原则上满足用户友好的操作界面或用户熟悉的操作风格,易于使用、功能实用即可。如WindowsXp等。3.3.2 地理信息系统平台ZF应急平台综合应用系统是复杂的应急管理与决策支持系统,对GlS平台软件有着较高的要求,在技术方面主要要求GIS平台具有超强的空间数据组织与管理能力、支持跨平台、良好的系统集成性、对空间数据发布和交换规范支持性好、具有强大的制图功能、强大的空间分析功能、可扩展性以及高安全性。如ArCGlS等。3.3.3 数据库ZF应急平台综合应用系统运行的业务和数据具有高负载、要求比较完整的业务逻辑和高安全性等应用特点,采用大型商业数据库。如Oracle等。3.4 空间查询与分析3.4.1 系统架构在应急业务流程中,不论是应急信息展示还是应急指挥决策,都与空间位络息息相关。空间查询提供了获取空间信息的手段,空间分析则利用空间分析模型,模拟现实世界,解决实际问题,为应急提供空间辅助决策支持。因此,空间查询与分析是ZF应急平台综合应用系统中各业务系统都涵盖的内容,而且是必备的技术支撑。空间查询与分析与综合应用系统的总体关系如下图所示,空间查询和空间分析被封装成组件及服务进行发布,并定义统一的接口,界定输入、输出参数,与ZF应急平台综合应用系统紧密耦合,为综合应用系统的各子系统提供基础GIS服务。空间查询、空间分析采用了B/S和C/S混合模式的多层软件架构,主要分为数据层、空间信息服务层、客户层。各软件层和组件群之间的通讯符合标准的工业规范,软件框架具有持续的可扩展性,可支持集中式和分布式的部署,可同时支持B/S模式和C/S模式的应用。总体架构图如下图所示:图3-4空间查询与分析系统体系架构图1、数据层该层为各应用系统提供数据支持,主要包括集中存储的基础信息数据库和空间信息数据库。2、空间信息服务层该层主要由GlSSerVer组成,除了为客户端提供地图和数据服务,GISServer还可在共享的中心服务器上支持GlS工作站的所有功能,包括制图、搜索、空间查询等。该层通过开放的Internet协议和基于SOAP的Webservices为各类客户端和应用提供服务,如WMS(WebMapService:网络地图服务)、WFS(WebFeatureService:网络要素服务)等。3、客户层包括C/S客户端和B/S浏览器端。C/S客户层由面向对象的组件开发的独立应用软件组成,主要完成模型计算结果动态可视化等复杂功能,为典型的C/S软件架构;B/S浏览器层、空间查询与分析功能由GISSerVer发布的数据服务和工具服务来共同完成,为典型的B/S软件架构。3.4.2 系统功能设计空间查询与分析功能框图如下图所示:空间查询屈性条件查询空间条件查询线查询矩形查询点击查询混合查询圆查询多边形查询统计查询空间查询与分析网络分析服务范围划分最小费用最大流导航空间分析缓冲区分析点缓冲分析线缓冲分析面缓冲分析叠置分析几何量算坐标殳算长度量算面积量算I I体积量算I周长量算质心虽算图3-5空间查询与分析功能框图3.4.2.1空间查询3.4.2.1.1基于空间关系查询空间实体之间存在着多种空间关系,包括拓扑、顺序、距离、方位等关系。通过空间关系查询和定位空间实体是地理信息系统不同于一般数据库系统的功能之一。1、面面查询, 2、面线查询, 3、面点查询, 4、线面查询,简单的面、线、点相互关系的查询包括:如与某个多边形相邻的多边形有哪些。如某个多边形的边界有哪些线。如某个多边形内有哪些点状地物。如某条线经过(穿过)的多边形有哪些,某条链的左、右多边形是哪些。5、线线查询,如与某条河流相连的支流有哪些,某条道路跨过哪些河流。6、线点查询,如某条道路上有哪些桥梁,某条输电线上有哪些变电站。7、点面查询,如某个点落在哪个多边形内。8、点线查询,如某个结点由哪些线相交而成。3.4.2.1.2基于空间关系和属性特征的联合查询目前的空间查询是通过对标准SQL进行扩展,即在其中加入空间关系查询。如增加空间数据类型(如点、线、面)和空间操作算子(如求长度、面积、叠加等)。基于属性的GIS查询,则可以直接通过关系数据库的SQL语言进行查询。一般来说,地物的图形数据和属性数据是分开存贮的,图形和属性之间通过目标的ID码进行关联,通过SQL语言操作数据库进行查询。3.4.2.1.3 地址匹配查询根据街道的地址来查询事物的空间位貉和属性信息,是地理信息系统特有的一种查询功能。这种查询利用地理编码,输入街道的门牌号码,就可知道大致的位貉和所在的街区。该查询能够根据一段地址的描述性语言,自动地从空间位貉的角度将该地址定位,经常用于公用事业管理,事故分析等方面,如邮政、通讯、供水、供电、治安、消防、医疗等领域。3.4.2.1.4 超文本查询超文本查询把图形、图像、字符等皆当作文本,并设貉一些“热点”(HOtSPot),“热点”可以是文本、键等。用鼠标点击“热点”后,可以弹出说明信息、播放声音、完成某项工作。但超文本查询只能预先设貉好,用户不能实时构建自己要求的各种查询。在地图上进行多种空间查询操作,获取满足特定属性筛选和空间筛选条件的地理信息、安全信息及案例信息。功能详细设计如下表所示:超文本查询功能列表名称描述属性条件查询建立属性信息的过滤条件来查询满足该条件的空间要素或要素集合,即为“属性查询图形”空间条件查询以某一空间实体为参考,按照空间实体间的空间关系(包括:拓扑关系、距离关系、方位关系等),查询满足条件的空间要素或要素集合混合查询属性条件和空间条件联合查询点击查询在地图上用鼠标点击,查询以鼠标中心为圆心,容限误差为半径的圆形区域内的所有图层要素线查询在地图上用鼠标画线,查询线条路径所经过的区域内的所有要素矩形查询在地图上用鼠标按住左键拖拽画矩形框,查询矩形框内的所有要素圆查询在地图上用鼠标按住左键,拖拽画圆,查询圆内的所有要素多边形查询在地图上用鼠标拖拽画任意多边形,查询多边形封闭的区域内的所有要素统计查询指定地理区划或者按照某一属性特征或者空间特征进行统计查询,并以报表的形式输出、打印,这里包括属性信息的输出,也包括相关标注的添加、图形美化与输出图-属抽取给定空间要素或要素集合的所有属性信息,并以图标的形式显示出来空间定位将查询出来的空间要素定位、闪烁,并添加标注显示3.4.2.2空间分析3.4.2,2.1网络分析模块现实世界中的基础设施(所有高速公路、电缆、和各种能进行人、能量、商品和思想流动的传输途径)均可抽象为网络模型。网络模型具有良好的数学特性和空间分析功能,可以解决复杂的交通系统、能量系统、通讯系统、应急中人财物流动系统等问题,实现资源的最优配珞,为应急救援提供辅助决策支持。网络分析模块功能列表名称描述网络数据建立与管理对原始空间数据进行预处理,建立几何网络(GeOrnetriCnetworks)和网络数据集(Networkdatasets),即建立效用网络和传输网络,为网络分析做数据准备路径分析由用户界面输入或系统输入参数,包括:起点(一个或多个)、终点(一个或多个)、障碍点(一个或多个)、权重因子,给出一条或多条符合要求的路径分析结果,并将路径可视化表达。路径分析子模块静态最佳路径在给定的每条链上的属性后,求最佳路径。N条最佳路径确定起点或终点,设貉障碍点,可以是一个起点,多个终点的,也可以是多个起点一个终点,障碍点自由设貉,影响因子也可以是一个或多个,求代价最小的N条路径。最短路径或最低耗费路径确定起点、终点、障碍点以及要经过的中间点、中间连线,求最短路径或最小耗费路径服务范围划分对救援力量(如:110、120、119、医院)的服务区域,按照到达时间(如:1分钟可达、5分钟可达、10分钟可达等)划分服务区域,对那些服务盲区进行识别,并进行最优配辂资源分配为网络中的线(结点)寻找最近(距离、耗时、代价等最小)的资源(包括救援力量、救援物资等),确保有效的资源分配。根据资源容量和网络线(结点)提出的需求,将资源进行不断的分配,资源随着不断的分配,其储存量在不断的臧少,当耗尽时,该分配就停止。解决救援力量和救援物资的分配问题。查找最邻近设施查找、分析目标点附近最邻近的服务设施,可按距离、按时间、按通行代价等权值进行分析。解决救援力量和救援物资的调度问题。最小费用最大流统筹调度救援力量和救援物资,让资源能以最小的代价(距离、时间、耗费等最小)到达现场,取得最好的效果,解决资源的最优化调度问题导航对分析出来的最优路径生成导航图,用于打印下

    注意事项

    本文(ZF应急软件平台建设总体设计方案.docx)为本站会员(夺命阿水)主动上传,课桌文档仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知课桌文档(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    备案号:宁ICP备20000045号-1

    经营许可证:宁B2-20210002

    宁公网安备 64010402000986号

    课桌文档
    收起
    展开