一种基于WebGIS的B/S架构多专家在线协商标绘系统

摘要

本发明涉及一种基于WebGIS的B/S架构多专家在线协商标绘系统，其中，所述系统包括：服务器以及与服务器通信连接的多个客户端；所述服务器中包括：用户功能模块、GIS功能模块、标绘符号库模块、协商标绘功能模块以及方案管理功能模块；所述用户功能模块用于控制客户端，使客户端的可视界面中展示用户登录界面；所述用户功能模块还用于接收用户在客户端展示用户登录界面的可视界面中所输入的验证信息，并根据所述验证信息进行用户注册、用户登录、用户新增或用户删除。

说明书

技术领域

本发明涉及协同标绘技术领域，尤其涉及一种基于WebGIS的B/S 架构多专家在线协商标绘系统。

背景技术

协同标绘最初被用作军事用途，目前已被部分外军用于军事规划和 指挥。美军于2004年开发的一个网络通用态势图WebCOP，它以Arcgis 平台作为基础，显示了关于战场的各种相关信息，其中包括：地图、情 报、各类作战设施、带有时间标记以及空间位置的相关信息，指挥者通 过这套系统可以实时获取信息，并做出应对决策。这项技术早已被美军 用于局部战争以及军事模拟演习，它具有信息传输的实时性、地图标绘 的便捷性以及直观性，所以收到军队的一致推崇。而在我国军事协同标 绘发展较晚，单用户标绘系统开发已经较为成熟，基于网络的实时性军 事协同标绘系统的开发也有了一定成果。如今也已经有不少人提出了协 同标绘的不同技术，曹玉会等人2012年在ICACII会议上针对移动协同 绘图问题提出了一种多模式移动协同绘图框架(M2CPF)模型(Affective Computing andIntelligent Interaction，2012，P159-167)，首先根据共有 特征绘制关键要素移动，其次为满足移动环境的高度动态性与复杂性设 计了一种多模式灵活的移动协同绘图框架模型，最后引入协同感知并发 控制技术使其全面适用于移动协同环境。马得生等人设计了基于Arcgis 平台.Net框架下的协同标绘系统，其系统采用“主控—用户”应用模式(计 算机工程与设计，2013，34(6):2235-2239.)，主控端进行数据管理以及 会议控制，与会者根据分工对目标区域进行信息采取标绘交流，其主要 特点是客户端上传图元修改操作的同时服务器进行数据入库，更新数据 库。张立生(河北省科学院学报，2011,28(3)：56-60)基于J2ME框 架设计与实现了移动端实时协同标绘系统，其特点是移动端内部存放基 本图形方便标绘，通过无线网络传递到服务器，其他用户通过本地图形 同步更新。

目前的其他人的协同标绘方案，多采用单机版的C/S架构进行设计 实现，对于单机版的协同标绘系统，在使用过程中多需要硬件的支持， 并且移动性能力差，当应急事件发生时，不能有效的进行实时协同工作。

发明内容

(一)要解决的技术问题

鉴于现有技术的上述缺点、不足，本发明提供一种基于WebGIS的 B/S架构多专家在线协商标绘系统。

(二)技术方案

为了达到上述目的，本发明采用的主要技术方案包括：

第一方面，本发明实施例提供一种基于WebGIS的B/S架构多专家 在线协商标绘系统。所述系统包括：服务器以及与服务器通信连接的多 个客户端；

所述服务器中包括：用户功能模块、GIS功能模块、标绘符号库模块、 协商标绘功能模块以及方案管理功能模块；

所述用户功能模块用于控制客户端，使客户端的可视界面中展示用户登 录界面；

所述用户功能模块还用于接收用户在客户端展示用户登录界面的可视 界面中所输入的验证信息，并根据所述验证信息进行用户注册、用户登录、 用户新增或用户删除。

优选的，

所述GIS功能模块用于控制客户端，使客户端的可视界面中展示预先设 定的地图；

所述预先设定的地图由工作底图、工作标绘图层组成；

所述工作底图为OpenStreetMap地图；

所述工作底图包括：矢量图、遥感图、交通底图；

所述工作标绘图层为通过GeoServer发布的WFS、WMS服务图；

所述GIS功能模块还用于接收用户在客户端展示预先设定的地图的可 视界面中对所述地图的操作指令，并根据所述操作指令在客户端的可视界面 中对所述地图平移、旋转、放大、缩小；

所述GIS功能模块还用于接收用户在客户端展示预先设定的地图的可 视界面中预先设定的工作底图中的选择指令，根据所述选择指令在客户端的 可视界面中展示相应的工作底图。

优选的，

所述标绘符号库模块用于控制客户端，使客户端的可视界面中展示静态 标绘界面或动态标绘界面或标绘样式修改界面；

所述标绘符号库模块还用于接收用户在客户端展示的静态标绘界面的 可视界面中对静态标绘的管理指令，并根据所述管理指令，进行相应的操作；

所述管理指令包括：符号增加、符号存储、符号编辑以及符号删除操作 指令；

所述静态标绘包括灾害类型标绘、应急等级标绘以及应急类型标绘；

灾害类型标绘包括火灾标绘、交通事故标绘、地质灾害标绘、建筑物倒 塌标绘、洪水灾害标绘、山体滑坡标绘以及地震灾害标绘；

应急等级标绘包括应急等级Ⅰ标绘、应急等级Ⅱ标绘、应急等级Ⅲ标绘、 应急等级Ⅳ标绘；

应急类型标绘包括应急供电标绘、应急供水标绘、应急停车标绘、应急 通讯标绘、应急维修标绘、应急物资标绘、应急医院标绘、应急避难标绘、 应急消防标绘、应急车辆标绘、应急资源标绘；

所述标绘符号库模块还用于接收用户在客户端展示的动态标绘界面的 可视界面中对动态标绘的管理指令，根据所述管理指令，进行相应的操作；

所述动态标绘包括箭头标绘、线状标绘以及面状标绘；

箭头标绘包括单箭头标绘、双箭头标绘、分队标绘、钳击标绘；

线状标绘包括曲线标绘、折线标绘、自由线标绘以及防洪线标绘；

面状标绘包括自由面标绘、集结地标绘、扇形标绘、圆形标绘、矩形标 绘以及闭合曲面标绘；

所述标绘符号库模块还用于接收用户在客户端展示的标绘样式修改界 面的可视界面中对标绘样式的修改指令，根据所述修改指令对标绘进行修 改，获取相应的修改结果。

优选的，

所述协商标绘功能模块包括会议功能单元、通讯功能单元、协同编辑与 并发控制单元；

所述会议功能单元用于控制客户端，使客户端的可视界面中展示创建标 绘小组界面、加入标绘小组界面、退出标绘小组界面；

所述会议功能单元还用于接收用户在客户端展示的创建标绘小组界面 的可视界面中的创建指令，并根据所述创建指令进行获取标绘小组；

所述标绘小组内各客户端的可视界面中的地图内容一致；

所述会议功能单元还用于接收用户在客户端展示的加入标绘小组界面 的可视界面中的进入会议指令，并根据所述进入会议指令进入所述标绘小 组；

所述会议功能单元还用于接收用户在客户端展示的退出标绘小组界面 的可视界面中的退出会议指令，并根据所述退出会议指令进行退出所述标绘 小组。

优选的，

所述通讯功能单元用于接收用于在标绘小组中任一客户端输入的标绘 消息，并将所述标绘消息推送到标绘小组其他客户端。

优选的，

所述通讯功能单元用于获取用户在所述标绘小组中任一客户端输入的 标绘消息，并对所述标绘消息进行标绘消息封装获取封装后的信息，并将接 收到的所述封装后的信息传递给标绘小组内的其他客户端；

标绘小组内的其他客户端根据所述封装后的信息在工作地图上获取与 所述封装后的信息相应的标绘结果。

优选的，

对所述标绘消息进行标绘消息封装获取封装后的信息，具体包括：

构建XML文档，并将所述标绘消息采用以操作为根节点的XML；

添加操作类型XML子节点、要素修改操作类型XML子节点、要素删 除操标绘操作分成要素类型XML子节点、元素添加操作类型XML子节点、 元素删除操作类型XML子节点、对象上锁操作类型XML子节点；

所述要素和元素均具有点线面三种形态；

将元素或要素压缩成字符串形式，添加到XML子节点中，并在所述 XML子节点中添加预先设定的基础信息、图形属性、图形定义、图形几何 形态属性、要素图层信息。

优选的，

标绘小组内的其他客户端根据所述封装后的信息在工作地图上获取与 所述封装后的信息相应的标绘结果，具体包括：标绘小组内的其他客户端根 据所述封装后的信息在工作地图上获取添加元素或要素的标绘结果、删除元 素或要素的标绘结果、修改元素或要素的标绘结果。

优选的，

协同编辑与并发控制单元用于用户在所述标绘小组中任一客户端对所 选定的要素进行编辑时，对所述要素进行上锁处理，获取所述要素的上锁处 理结果；

所述要素的上锁处理结果为标绘小组中其他客户端没有对所述要素进 行编辑的权限；

协同编辑与并发控制单元用于用户在所述标绘小组中任一客户端对所 选定的要素完成编辑时，对所述要素进行解锁处理，获取所述要素的解锁处 理结果；

所述要素的解锁处理结果为标绘小组中其他客户端具有对所述要素进 行编辑的权限。

优选的，

所述方案管理功能模块用于根据预先获取的发生灾害的具体信息从预 先设定的预案库里获取与所述预先获取的发生灾害的具体信息匹配的历史 应急预案信息；

历史应急预案信息包括历史应急灾害的处理方法信息；

所述方案管理功能模块还用于对制定的预案按照预先设定的规则进行 存储或备份或删除。

(三)有益效果

本发明的有益效果是：本发明的基于WebGIS的B/S架构多专家在 线协商标绘系统，由于采用B/S模式架构，它将客户端直接集成到浏览 器上，摆脱了本地客户端形式的笨重，任何用户都可以通过互联网对应 用程序进行访问，同时运用WebGIS的协同标绘可以随时随地的参与会 议、参与协商，可以有效的节约宝贵的救援时间，为应急协商提供良好 的方案支持。

附图说明

图1为本发明的基于WebGIS的B/S架构多专家在线协商标绘系统 结构示意图；

图2为本发明的基于WebGIS的B/S架构多专家在线协商标绘系统 功能结构示意图；

图3为本发明实施例中的用户登录界面；

图4为本发明实施例中的静态标绘界面；

图5为本发明实施例中的动态标绘界面；

图6为本发明实施例中的标绘样式修改界面；

图7为本发明实施例中的创建应急标绘小组界面；

图8为本发明实施例中的加入标绘小组界面；

图9为本发明实施例中的退出标绘小组界面；

图10为本发明实施例中小组在线协商功能图；

图11为本发明实施例中地图标绘示意图；

图12为本发明中标绘消息封装流程图；

图13为本发明实施例中标绘重现流程图；

图14为本发明实施例中添加点要素后的客户端界面；

图15为本发明实施例中添加线要素后的客户端界面；

图16为本发明实施例中添加面要素后的客户端界面；

图17为本发明实施例中将图16中的面要素删除后的客户端界面；

图18为本发明实施例中将图17中的线要素修改后的客户端界面；

图19为本发明实施例中并发控制流程图；

图A为本发明的基于WebGIS的B/S架构多专家在线协商标绘系统 中前端展示层、业务逻辑层、数据层示意图；

图B为本发明的基于WebGIS的B/S架构多专家在线协商标绘系统 网络结构图；

图C为本发明的基于WebGIS的B/S架构多专家在线协商标绘系统 整体技术路线图。

具体实施方式

为了更好的解释本发明，以便于理解，下面结合附图，通过具体实 施方式，对本发明作详细描述。

为了更好的理解上述技术方案，下面将参照附图更详细地描述本发 明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应 当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。 相反，提供这些实施例是为了能够更清楚、透彻地理解本发明，并且能 够将本发明的范围完整的传达给本领域的技术人员。

一个完整的WebGIS系统主要由三个部分构成，即客户端地图引擎、 服务器端以及数据库端。结合这种情况，本实施例中的基于WebGIS的 B/S架构多专家在线协商标绘系统的整体网络结构图设计如图A和图B 所示。

实现一个系统，参见图C，根据系统需求分析设计技术路线是一个必 要的环节，根据实际情况，技术路线主要分为协同标绘并发控制、消息 网络推送机制两大模块。

经过对系统的整体分析和各方资料的查询，本发明的基于WebGIS 的B/S架构多专家在线协商标绘系统设计前端将以WebStorm为集成开发 环境，前端开发将采用HTML+CSS+JavaScript的常规Web开发模式，后 台开发将以Eclipse为开发平台，采用SSM框架，即Spring+SpringMVC+MyBatis的模式进行设计开发。服务器则采用轻量级 的Tomcat服务器。

在系统开发实现中，GIS功能部分的实现主要采用OpenLayers+ GeoServer+PostgreSQL/PostGIS的模式进行开发设计，具体为：前端的 地图展示部分主要采用OpenLayers框架，地图服务将使用开源的 GeoServer地图服务器，系统的空间数据将使用开源的PostGIS存储，属 性数据将使用PostgreSQL数据库进行存储。

平台实现所需要的软件工具列表如下：

参见图1和图2，本实施例提供一种基于WebGIS的B/S架构多专家 在线协商标绘系统，所述系统包括：服务器以及与服务器通信连接的多 个客户端；

所述服务器中包括：用户功能模块、GIS功能模块、标绘符号库模块、 协商标绘功能模块以及方案管理功能模块；

所述用户功能模块用于控制客户端，参见图3使客户端的可视界面中展 示用户登录界面；

所述用户功能模块还用于接收用户在客户端展示用户登录界面的可视 界面中所输入的验证信息，并根据所述验证信息进行用户注册、用户登录、 用户新增或用户删除。

本实施例的实际应用中，所述GIS功能模块用于控制客户端，使客户端 的可视界面中展示预先设定的地图；

所述预先设定的地图由工作底图、工作标绘图层组成；

所述工作底图为OpenStreetMap地图，包括：矢量图、遥感图、交通底 图；

所述工作标绘图层为通过GeoServer发布的WFS、WMS服务图；

所述GIS功能模块还用于接收用户在客户端展示预先设定的地图的可 视界面中对所述地图的操作指令，并根据所述操作指令在客户端的可视界面 中对所述地图平移、旋转、放大、缩小；

所述GIS功能模块还用于接收用户在客户端展示预先设定的地图的可 视界面中预先设定的工作底图中的选择指令，根据所述选择指令在客户端的 可视界面中展示相应的工作底图。

本实施例的实际应用中，GIS功能模块的实现系统的一些基本操作，主 要包括公共地图加载、地图的基本操作以及地图底图的切换等三个部分。

公共地图加载：本系统的地图主要由两个图层组成，其一为工作底图， 其二为工作标绘图层。对于工作底图则主要为协商标绘工作等提供地理位置 信息，可以选择Google地图或者开源的OpenStreetMap地图，本系统中将默 认为OpenStreetMap地图。对于工作标绘图层，可以加载自行通过GeoServer 发布的WFS、WMS服务图等。最终以可视化的地图展示在界面上。

地图的基本操作：在一幅电子地图上，实现对地图的常规基础操作，如 地图的平移、旋转操作、放大缩小控制等。该部分功能主要为协商标绘工作 等提供基础技术支持。

地图底图的切换：针对不同的需求，提供不同的工作底图，如在城市区 域可以选择矢量图、在山区可以选择地形图或者遥感图、在交通领域可以选 择交通底图等。通过多种底图的切换，可以匹配所需要的工作地图。核心代 码如下所示：

在本实施例的实际应用中，参见图4、图5、图6，所述标绘符号库模块 用于控制客户端，使客户端的可视界面中展示静态标绘界面或动态标绘界面 或标绘样式修改界面。

所述标绘符号库模块还用于接收用户在客户端展示的静态标绘界面的 可视界面中对静态标绘的管理指令，并根据所述管理指令，进行相应的操作。

所述管理指令包括：符号增加、符号存储、符号编辑以及符号删除操作 指令。

所述静态标绘包括灾害类型标绘、应急等级标绘以及应急类型标绘。

灾害类型标绘包括火灾标绘、交通事故标绘、地质灾害标绘、建筑物倒 塌标绘、洪水灾害标绘、山体滑坡标绘以及地震灾害标绘。

应急等级标绘包括应急等级Ⅰ标绘、应急等级Ⅱ标绘、应急等级Ⅲ标绘、 应急等级Ⅳ标绘。

应急类型标绘包括应急供电标绘、应急供水标绘、应急停车标绘、应急 通讯标绘、应急维修标绘、应急物资标绘、应急医院标绘、应急避难标绘、 应急消防标绘、应急车辆标绘、应急资源标绘。

所述标绘符号库模块还用于接收用户在客户端展示的动态标绘界面的 可视界面中对动态标绘的管理指令，根据所述管理指令，进行相应的操作。

所述动态标绘包括箭头标绘、线状标绘以及面状标绘。

箭头标绘包括单箭头标绘、双箭头标绘、分队标绘、钳击标绘。

线状标绘包括曲线标绘、折线标绘、自由线标绘以及防洪线标绘。

面状标绘包括自由面标绘、集结地标绘、扇形标绘、圆形标绘、矩形标 绘以及闭合曲面标绘。

所述标绘符号库模块还用于接收用户在客户端展示的标绘样式修改界 面的可视界面中对标绘样式的修改指令，根据所述修改指令对标绘进行修 改，获取相应的修改结果。

在本实施例的实际应用中，在多方应急专家协商标绘中，协同标绘符号 库的构建是一个需要解决的重要问题，但是对目前的研究现状而言，尚未有 标准的符号库作为参照标准，在贾艳的“公共安全事件应急符号的设计研究” 一文中指出，设计一个符号系统，需要遵循四个原则，即：

1.图案化应急符号的同时应该充分考虑符号的象征性；

2.应急符号应该是简洁性和生动性的和谐统一；

3.设计应急符号应考虑系统性；

4.设计应急符号时，应注意符号的使用适应性和可行性。

基于这种情况，本系统将根据实际情况将标绘分成两个模块，分别为动 态标绘库和静态标绘库，动态标绘主要包括箭头标绘、线状标绘以及面状标 绘；其中箭头状标绘又包括单箭头标绘、双箭头标绘、分队标绘、钳击标绘 等，线状标绘则包含曲线标绘、折线标绘、自由线标绘以及防洪线标绘等， 面状标绘则包括自由面标绘、集结地标绘、扇形标绘、圆形标绘、矩形标绘 以及闭合曲面标绘等六类。静态标绘则主要包括灾害类型标绘、应急等级标 绘以及应急类型标绘等。其中灾害类型包括火灾、交通事故、地质灾害、建 筑物倒塌、洪水灾害、山体滑坡以及地震灾害等；应急等级主要分为应急等 级Ⅰ、Ⅱ、Ⅲ、Ⅳ四个等级，应急类型主要包括应急供电、应急供水、应急 停车、应急通讯、应急维修、应急物资、应急医院、应急避难、应急消防、 应急车辆、应急资源等。此外，协商标绘符号库构建还包括标绘样式的修改 设计，如标绘的填充色、标绘线的宽度等基础设计。

目前我国的应急符号并没有成熟的或者标准的统一规范，所以各种灾害 对应的应急符号体系的建设还在进一步的探索研究中，在构建应急标绘符号 库时，需要考虑各方面的因素，同时也应参照目前国内外广泛应用的制图符 号体系，例如常用的地图符号体系和自然灾害符号体系等。同时本系统中分 别采用绿、蓝、橙、紫四种颜色代表应急事件的等级。

最后构建好的符号库应具备地图符号的简介性、实用性、科学性、美观 性、易懂性等特点。

本实施例中设计的应急符号库对比其它的符号库，通过分为动态符号库 和静态符号库，因此具有层次分明的优点；此外设计的符号较为形象、特色 鲜明，可以让人一目明了，具有通俗易懂、可视化效果好的优点。

标绘符号库管理则主要包括符号增加、符号存储、符号编辑以及符号删 除等操作，本发明中的应急对象主要是针对地震、洪水、地质灾害、城镇火 灾、交通事故、建筑物倒塌等各类自然灾害和公共突发事故，然而，因为灾 害的随机性以及突发性，设计符号增加功能可以增强系统的扩展性。

本实施例的实际应用中，所述协商标绘功能模块包括会议功能单元、通 讯功能单元、协同编辑与并发控制单元。

参见图7、图8、图9，所述会议功能单元用于控制客户端，使客户端的 可视界面中展示创建标绘小组界面、加入标绘小组界面、退出标绘小组界面。

所述会议功能单元还用于接收用户在客户端展示的创建标绘小组界面 的可视界面中的创建指令，并根据所述创建指令进行获取标绘小组。

所述标绘小组内各客户端的可视界面中的地图内容一致。

所述会议功能单元还用于接收用户在客户端展示的加入标绘小组界面 的可视界面中的进入会议指令，并根据所述进入会议指令进入所述标绘小 组。

所述会议功能单元还用于接收用户在客户端展示的退出标绘小组界面 的可视界面中的退出会议指令，并根据所述退出会议指令进行退出所述标绘 小组。

本实施例中会议协商功能单元将通过应急减灾负责专家进行协商会议 创建、邀请其他专家与会、多专家共同协商、统一应急预案等一系列操作流 程进行实现，该部分的主要功能为提供协商标绘环境，参见图10，做到多专 家在同一共享环境下协同标绘协商。

参见图11，本实施例中所述通讯功能单元用于接收用于在标绘小组中任 一客户端输入的标绘消息，并将所述标绘消息推送到标绘小组其他客户端。

本实施例中通讯功能单元主要为异地多专家共同协商标绘提供网络传 输，本发明将运用XML和WebSocket相结合的技术方案进行设计实现。在 异地多用户的情况下，实现将小组内某一专家的提议或者标绘消息网络同步 推送到其他浏览器端，让小组内的其他专家可以实时同步的感知标绘状态。

本实施例中创造性的将XML和WebSocket相结合，提出基于WebSocket 的标绘消息网络传输，通过常规的消息传输数据格式对比，提出将XML数 据格式做为地图标绘信息的载体，并运用WebSocket的网络传输方式进行消 息传输实现，从而实现协同感知和协商标绘重现。

标绘操作的消息传递机制是协同标绘得以实现的关键，所有关于图形操 作的消息都采用以“Operates”为根节点的XML，根据操作可以分成要素添加、 要素修改、要素删除、元素添加、元素删除、对象上锁六大类，根据这些在 子节点中添加“Operatetype”项，方便客户端接收到信息后做出不同处理。

对于服务器端操作，其唯一的功能就是将接收到的消息传递给工作组内 的其他成员，这与文字传输过程相类似。而客户端的封装过程相对比较复杂， 无论是要素还是元素都分为点线面三种形态，其空间信息也有所不同。由于 空间信息表达的复杂性，无法直接传递空间信息，系统需要将其压缩成字符 串形式，添加到XML中。空间信息最常见的存储形式就是存储坐标，点坐 标最为简单，线通过分解成点集的形式保存，面同样能够按照一定规律转化 成点集，这样一来点线面三种形态都可以以坐标形式存储到传输数据中。其次在XML子节点中还要添加基础信息、图形属性、图形定义、图形几何形 态属性、要素图层信息，方便组内成员客户端进行标绘重现。

本实施例中所述通讯功能单元用于获取用户在所述标绘小组中任一客 户端输入的标绘消息，并对所述标绘消息进行标绘消息封装获取封装后的信 息，并将接收到的所述封装后的信息传递给标绘小组内的其他客户端；

标绘小组内的其他客户端根据所述封装后的信息在工作地图上获取与 所述封装后的信息相应的标绘结果。

参见图12，本实施例中对所述标绘消息进行标绘消息封装获取封装后的 信息，具体包括：

构建XML文档，并将所述标绘消息采用以操作为根节点的XML。

添加操作类型XML子节点、要素修改操作类型XML子节点、要素删 除操标绘操作分成要素类型XML子节点、元素添加操作类型XML子节点、 元素删除操作类型XML子节点、对象上锁操作类型XML子节点。

所述要素和元素均具有点线面三种形态。

将元素或要素压缩成字符串形式，添加到XML子节点中，并在所述XML子节点中添加预先设定的基础信息、图形属性、图形定义、图形几何 形态属性、要素图层信息。

参见图13，本实施例中标绘小组内的其他客户端根据所述封装后的信息 在工作地图上获取与所述封装后的信息相应的标绘结果，具体包括：标绘小 组内的其他客户端根据所述封装后的信息在工作地图上获取添加元素或要 素的标绘结果、删除元素或要素的标绘结果、修改元素或要素的标绘结果。

本实施例中，标绘消息的解析和重绘实际上是通过代码一步完成，这里 以要素添加的标绘重现为例说明。要素添加：绘小组内的其他成员的客户端 对所述封装后的信息进行解析，获取要素几何信息、坐标信息、要素的属性 类型与基本定义将这些信息保存到结构体，开始重新进行标绘。

参见图14，点要素的添加，通过分隔符直接分隔出X坐标、Y坐标， 直接将X坐标Y坐标赋值给新的点对象。

参见图15，线要素的添加，在消息传输前被压缩成点集，转化过程中保 留了点的顺序，客户端首先通过分隔符将坐标转化成多对点坐标形式，保存 在字符串数组中，通过循环将点集组合成线段最后集合成多段线形式。

参见图16，面要素的添加，在消息传输前同样被压缩成点集，在这个过 程中点集仍然按规律保存，客户端收到消息后通过分隔符将其转化成存储点 坐标的字符串数组，最后将数组中所有点集合到一个几何形状。

要素删除，直接传递鼠标点击位置，其他客户端与修改用户做出相同操 作，选择周围要素并进行删除，参见图17。

要素修改，用新的几何形状代替原有几何形状，并且赋予对应要素新的 属性值，参见图18。

本实施例中，对于添加要素消息，客户端接收到消息后迅速解析数据， 解析核心主要是“Geometry”包含要素几何信息，分为点线面三类， “Coordinate”包含坐标信息，除此之外还有要素的属性类型与基本定义， 将这些信息保存到结构体，开始重新进行标绘。核心问题变成了如何通过一 系列的点来重新获取几何信息，点要素容易解决，通过分隔符直接分隔出 XY坐标，直接将XY坐标赋值给新的点对象即可；线要素在消息传输前被 压缩成点集，转化过程中保留了点的顺序，客户端首先通过分隔符将坐标转 化成多对点坐标形式，保存在字符串数组中，通过循环将点集组合成线段最 后集合成多段线形式；面要素在消息传输前同样被压缩成点集，在这个过程 中点集仍然按规律保存，客户端收到消息后通过分隔符将其转化成存储点坐 标的字符串数组，最后将数组中所有点集合到一个环(Ring)中，这个环实 际上就是重绘多边形的几何形状。获取了几何形状后与添加要素的步骤相 同，先建立要素缓存，将几何形状赋予要素并将标绘消息中传递过来GUID 标识符以及其他属性赋给字段，最后通过指针将要素插入要素类。

要素删除的标绘重现有两种方式，第一种将要删除的要素GUID传递到 其他组内成员客户端，然后通过GUID的比对进行要素删除。第二种直接传 递鼠标点击位置，其他客户端与修改用户做出相同操作，选择周围要素并进 行删除。本系统采用第二种方式，第一种方式在要素数据量比较大的时候仍 然对所有要素进行比对，较为花费时间，而第二种方式无需通过标识符比对 就即可删除要素，而且无需确定该要素位于哪一要素图层，统一进行删除操 作；但这种方式涉及到要素选取并从要素集中获取要素，过程较为复杂，需 要调用更多函数，比较消耗资源。

要素修改的实质其实就是用新的几何形状代替原有几何形状，并且通过 消息传递机制赋予对应要素新的属性值。简单介绍下分割操作后的标绘重 现，分割操作只能出现在面要素中，首先需要解析出原要素标识符信息以及 新要素的各种信息并将其保存在结构体中。分割操作的标绘重现可以分为两 步，第一步通过标识符比对删除要素类中相应要素，第二步根据新要素信息 实现要素添加，实现了非修改用户的要素同步。

在本实施例中标绘重现实际上是在回调函数OnReceive中完成的，该过 程相当于在客户端主线程之外开辟了新的线程，这时主线程中的控件无法被 运用到独立线程中。为此，首先取消控件是否进行跨线程使用检查，使一般 控件可以在新线程中使用，OpenLayers所提供的地图控件无法通过这种形式 调用，于是系统设计了全局委托，利用线程Invoke的方法对各类标绘重现处 理函数进行处理，在委托内的函数调用主线程所有控件，这实际上避免了控 件的跨线程使用。使用Timer控件隔段时间判断一些属性是否变化，从而调 用处理函数，这种方法也可以达到效果，但是Timer相当于在不停运行，多 了很多没有意义的判断，增加了计算机资源占用。

本实施例中协同编辑与并发控制单元用于用户在所述标绘小组中任一 客户端对所选定的要素进行编辑时，对所述要素进行上锁处理，获取所述要 素的上锁处理结果。

所述要素的上锁处理结果为标绘小组中其他客户端没有对所述要素进 行编辑的权限。

协同编辑与并发控制单元用于用户在所述标绘小组中任一客户端对所 选定的要素完成编辑时，对所述要素进行解锁处理，获取所述要素的解锁处 理结果。

所述要素的解锁处理结果为标绘小组中其他客户端具有对所述要素进 行编辑的权限。

本实施例中，协同编辑与并发控制单元主要实现多专家间的协同编辑和 并发控制功能，并设计解决异地多专家间协商标绘的冲突问题，为制定合理 高效的预案提供良好的支撑。

为解决多方应急专家在线协商标绘过程中遇到的并发控制问题，通过多 专家对应急协商标绘中并发控制关键点进行研究分析，对于并发控制则采用 “标绘锁”的解决方案，通过适当的设计，合理高效的解决了协商标绘过程中 的并发控制问题

在异地协同会商的多用户环境中，多用户之间的标绘操作互不影响，但 当多个协同标绘者同时对同一个图元要素进行编辑时，可能引起并发操作冲 突，所以需要提供并发控制策略以解决系统的并发冲突问题。

针对这个问题许多学者提出了解决方案：张俊升等人设计了标绘锁来决 定图形要素是否可以被操作，并采用“最近使用者优先”的方法以减少网络请 求次数，从而提高操作的响应速度。这类方法原理与操作都比较简单，效率 较高，但是一旦上锁其他人无法对图形进行编辑，减弱了用户友好性。

本系统采用的也是“标绘锁”方法，但具体实现有所不同，在要素类创建 的过程中添加一个“Enable”字段专门用于存放要素是否被上锁信息。当用户 选中要素开始编辑时，马上封装成根节点为“Lock”的XML，将消息发送到 工作组内其他成员客户端上，客户端根据GUID查找到对应要素编号，将其 “Enable”字段内容变成“不可编辑”，即该要素被上锁，其他用户无法对其进 行编辑、删除操作，当用户完成要素编辑后，在标绘重现的同时将“Enable” 字段初始化，这时所有用户均可对其进行编辑操作，其流程如图14所示。 这种并发控制策略效率较高、操作简单、无需人工干预即可完成并发冲突预 防。

本实施例中所述方案管理功能模块用于根据预先获取的发生灾害的具 体信息从预先设定的预案库里获取与所述预先获取的发生灾害的具体信息 匹配的历史应急预案信息；

历史应急预案信息包括历史应急灾害的处理方法信息；

所述方案管理功能模块还用于对制定的预案按照预先设定的规则进 行存储或备份或删除。

本实施例中，应急协商的最终目的是为了救灾减灾制定合理的减灾 方案，因此应急方案管理是必不可缺的一个重要部分，该部分的主要功 能包括预案匹配、预案制定、预案管理等三个主要功能。

预案匹配：在应急减灾制定预案过程中，预案匹配的目的是根据发 生灾害的具体信息从预案库里检索历史应急预案信息，为本次应急减灾 提供一个重要的参考，从而提高效率节约宝贵的救灾时间。预案库的数 据主要来源于历史应急灾害的处理方法。在系统中，我们把应急预案类 型分为：火灾、地震、洪水、地质灾害、交通事故、建筑物倒塌等。采用PostgreSQL对预案特征数据进行存储，将预案分为三部分描述，首先 是预案问题的描述，即预案的基本信息，包括灾害类型、灾害发生地点、 灾害发生时间、灾害的级别等。每种灾害类型的描述会存在区别，如火 灾需要考虑到不同的火灾类型，如固体物质火灾、液体及可融物火灾或 气体火灾等不同类型火灾；而地震、台风等则需要考虑到震源中心、台 风中心等，所以针对不同的预案类型需要设置不同的数据表进行基本信 息的存储。最终实现预案匹配功能。

预案制定：在协商标绘小组协商操作后，需要制定一个统一的预案 进行应急，一个完善的预案应包括灾害类型、灾害程度、灾害发生地、 受困人员数量等灾害信息，还要包括救灾减灾所需要的调配信息，如调 集物资数量、调集应急车辆数量、应急交通线路、应急撤离线路等应急 信息，若在预案匹配操作中能检索到相似的历史预案，则可以借鉴历史预案的内容进行原制定，若进行预案匹配时，从历史预案库里并未匹配 到对应的预案信息时，则需要为本次应急工作重新制定应急预案。

预案管理：针对不同地域、不同类型的灾害情况，制定的预案内容 各异，因此需要对预案进行分批次、分层次、分类型、分地域等的分类 管理。此外还有预案的备份、删除管理等，对于一些重要的预案则需要 进行备份管理、对于一些时间久远无用的、错误的预案则可以进行删除 操作。

常见的架构设计除了C/S架构还有B/S架构，两者的优劣对比如下 表所示：

C/S和B/S架构优劣对比

针对这种情况，结合WebGIS的便捷性、可扩展性和跨平台性，本 发明采用B/S的架构设计实现协同标绘工作，运用WebGIS的协同标绘 可以随时随地的参与会议、参与协商，可以有效的节约宝贵的救援时间， 为应急协商提供良好的方案支持。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统 或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实 施例，或结合软件和硬件方面的实施例的形式。而且，本发明可采用在 一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包 括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程 序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)和计算机程 序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实 现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方 框图中的流程和/或方框的结合。

应当注意的是，在权利要求中，不应将位于括号之间的任何附图 标记理解成对权利要求的限制。词语“包含”不排除存在未列在权利要 求中的部件或步骤。位于部件之前的词语“一”或“一个”不排除存在 多个这样的部件。本发明可以借助于包括有若干不同部件的硬件以及借 助于适当编程的计算机来实现。在列举了若干装置的权利要求中，这些 装置中的若干个可以是通过同一个硬件来具体体现。词语第一、第二、 第三等的使用，仅是为了表述方便，而不表示任何顺序。可将这些词语 理解为部件名称的一部分。

此外，需要说明的是，在本说明书的描述中，术语“一个实施例”、 “一些实施例”、“实施例”、“示例”、“具体示例”或“一些示例” 等的描述，是指结合该实施例或示例描述的具体特征、结构、材料或者 特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述 术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的 具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以 合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可 以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征 进行结合和组合。

尽管已描述了本发明的优选实施例，但本领域的技术人员在得知了 基本创造性概念后，则可对这些实施例作出另外的变更和修改。所以， 权利要求应该解释为包括优选实施例以及落入本发明范围的所有变更和 修改。

显然，本领域的技术人员可以对本发明进行各种修改和变型而不脱 离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发 明权利要求及其等同技术的范围之内，则本发明也应该包含这些修改和 变型在内。