基于多元平臺洪災報警系統設計與實現

王星捷,劉華春,李春花

(成都理工大學 工程技術學院，四川 樂山 614007)

基于多元平臺洪災報警系統設計與實現

王星捷,劉華春,李春花

(成都理工大學 工程技術學院，四川 樂山 614007)

隨著終端平臺和媒體軟件的豐富化應用，傳統的洪災報警系統信息的單一傳輸方式已不能滿足當前多元平臺的需求。為此，應用了一種新的開發模式對洪災報警系統進行設計和實現，采用物聯網、移動通信、微信平臺和WEBGIS技術相結合的方式，建立了多元平臺的洪災報警系統。該系統利用物聯網技術實現數據采集，應用移動通信技術實現數據傳輸，以異步處理技術實現自動監測，使用GIS技術進行水淹分析，通過WEBGIS生成Web災情專題圖，采用微信平臺實現微信災情專題圖。運行實驗結果表明，所建系統能實時快速地生成風險圖、預警信息、災害評估等內容，并能在多元平臺中實時傳輸，信息交互性較好，為實時預警、搶險救災和災后救援工作提供了重要的決策參考，為洪災報警系統的設計與應用提供了一種新的技術開發思路。

多元平臺；WEBGIS；物聯網；微信公眾平臺

0 引 言

隨著信息技術的飛速發展，國內大部分的洪災監控系統正在向信息化轉變，逐步替代了傳統的人員值守進行監測的方式，極大地減少了人力物力的浪費。物聯網及3G/4G通信技術的發展，多元化的終端平臺以及媒體軟件的廣泛運用，使得當前的信息化洪災監控系統多為信息數據的呈現，終端依靠短信或者電話的方式進行傳輸，信息數據單一，與當前豐富的媒體呈現技術不協調，也無法滿足人們對災情數據更直觀、更豐富的呈現需求。

采用一種新開發模式進行洪災報警系統的設計與研究，采用物聯網、移動通信、微信平臺和WEBGIS技術[1]相結合的方式建立多元平臺的洪災報警系統。該系統利用物聯網技術設計了數據采集系統，應用移動通信技術設計實時數據傳輸，以異步處理方式設計數據自動處理和預警，使用GIS技術進行水淹分析，對比歷史數據和警戒數據，通過WEBGIS生成災情專題圖，最終采用微信平臺通信接口，實現微信災情專題圖的實時終端通信。

1 多元平臺洪災報警系統設計

預警平臺主要分為三大模塊：數據采集、數據處理、數據展示。

數據采集是實時地自動接收各水文監測站的水位、流量等數據，這些水文站終端都是基于物聯網技術的傳輸模塊，不需要人為干預即可自動通過GPRS/3G/4G網絡上傳數據。

數據處理需要借助GIS方法，對監測站傳輸回來的數據和已有的地形、數字高程、歷史數據等基礎數據進行分析處理，采用淹沒分析算法，計算出洪水影響范圍，通過ArcGIS Server發布在服務器端[2]。

數據展示包括兩個部分，一個是Web端的訪問，指將分析處理的結果數據發布到互聯網上，供用戶查閱；另一個是終端展現部分，是利用目前主流的媒體交互平臺—微信平臺進行數據展示，分為系統主動推送和用戶主動查詢。系統主動推送是針對關注過微信的用戶，實時發布災情專題圖；用戶查詢是用戶輸入相關的指令數據進行查詢和推送數據。

系統自下而上分別為數據層、服務層、業務層、表現層[3]。數據層按數據的類型分為空間數據和非空間數據，服務層按服務器的功能分為Web服務和GIS服務，業務層根據系統的需求分為不同的業務流程，最終用戶看到的就是表現層，表現層是用戶與系統進行交互的窗口。具體架構如圖1所示。

圖1 系統架構圖

數據層主要包括空間數據和非空間數據(屬性數據)的存取。非空間數據使用SAE平臺提供的MySQL數據庫存儲，空間數據使用ArcGIS個人地理數據庫存取。

服務層主要用來提供服務，包括Web服務和GIS服務，Web服務部署在新浪云服務平臺，使用微軟的IIS實現，GIS服務使用ArcGIS Server 10.1實現。Web服務主要是提供網頁展示和非空間數據讀取相關服務，GIS服務則提供基礎地圖服務、網絡數據服務、幾何服務以及其他的分析服務。

各種業務功能主要由業務層實現，主要實現了數據操作、信息查詢、高級操作以及高級分析功能。

表現層是用戶與系統交互的入口，是用戶可以直觀感受到的，包括Web瀏覽器和微信客戶端，采用ArcGIS API for JavaScript接口開發[4]，主要包括地圖組件、業務交互組件和緩存管理組件。使用這套接口最大的好處就是通用性高，與Sliverlight和Flex接口最大的區別就是用戶的瀏覽器不需要安裝任何插件即可使用。然后采用微信提供的開發接口進行數據的異步傳輸，微信客戶端用戶通過關注提供的微信公眾號即可使用平臺提供的功能。

2 系統通信框架設計

系統通信包括硬件通信和軟件通信[5]，硬件通信是基于數據的采集設計，軟件通信重在上層數據的傳輸，表現層的傳輸設計。

2.1 硬件通信設計

基于物聯網技術設計的水文站通過專業的傳感器自動獲取當前的水位、流量等數據，通過GPRS/3G/4G網絡實時地將數據上傳到遠程數據庫，采用新浪云數據庫實現。然后預警平臺利用上述水文數據，通過GIS服務器進行淹沒分析，最后通過客戶端(瀏覽器、微信)進行結果呈現。具體通信流程如圖2所示。

圖2 硬件通信設計圖

2.2 軟件通信設計

預警平臺的上層數據訪問和傳輸形式主要通過Http協議，客戶端采用Ajax異步請求的方式，服務器端根據請求的參數進行處理分析后返回客戶端需要的數據。

3 數據模型設計及制作

洪災數據模型的數據非常復雜，涉及的因素較多，受天氣、地形等多種因素的影響，在洪災數據中起決定性作用的有兩個因素，一個是洪災因素(上游潰壩或降雨)，另一個是受災區域的地形地貌。無論是哪種，洪災數據既是一個動態的也是一個變化的過程。

洪災數據模型[6]主要包括待分析區域的空間數據、水文數據和其他輔助數據(例如區域連通性調查數據)。其中空間數據又包括該區域的基礎電子地圖數據、DEM數據[7]、人口分布數據等。水文數據主要包括遍布在待分析區域及上游的自動水文監測站(至少包括自動水位計和自動雨量計)實時上報的數據，以及當地歷史洪災數據。

基礎電子地圖數據包括待分析區域基本的道路網、建筑、農田、人口分布等必要的地理性要素。這類的基本地理數據最簡單的方法是通過百度地圖、谷歌地圖、天地圖等公開的地圖服務商獲取，但是無法滿足系統平臺的需求，因此借助ArcGIS地圖制作軟件，通過遙感影像數據進行矢量化，然后根據平臺需求，添加各種地理要素屬性[8]。

最重要的數據就是數字高程模型(DEM)，而通過網絡獲取的DEM數據，分辨率只有30 m，達不到實際的數據要求，需要進行數據重新制作。利用ArcGIS工具先轉換成等高線，然后通過等高線插值(通過在相鄰的等高線中間插入一條平均值等高線)，最后再轉換回DEM數據。通過這樣的處理，最后的DEM數據的分辨率能高于10 m，得到的數據能夠滿足需求。

4 數據分析處理

數據分析處理主要是對洪災的數據進行淹沒分析，通過淹沒分析的結果來體現災情的情況、受災范圍和預警專題圖。淹沒分析分為兩種：一種是無源淹沒，另一種是有源淹沒。分析方法主要是依靠ArcMap平臺完成，運用已知流域中各水文站的水文數據來確定洪水位，淹沒面積的確定是由DEM數據和已知的洪水水位計算得出。

ArcGIS提供了一個地理處理任務的框架(ToolBox)，在ToolBox工具箱中包含了幾百個基本的地理處理任務，使用其中的某一個工具可以實現某項功能，但ToolBox最大的優勢是可以通過模型構建器建立復雜的模型，這樣就可以組合多個工具來滿足系統處理的需求，把定制好的地理處理工具打包成一個腳本或者自己的一個工具箱，這樣可以進行復用。

分析方法主要通過ArcGIS軟件在ArcToolBox中建立分析模型，然后通過設定模型需要的外界參數和模型運行環境即可，利用ArcGIS Server將工具箱發布到GIS服務器，客戶端可以直接進行調用。工具箱處理流程如圖3所示。

圖3 工具箱處理流程

5 系統實現

5.1 發布服務

需要發布的數據有兩個，一個是工具箱，包括了用于淹沒分析的模型(工具)，通過調用這個服務可以進行淹沒分析，提高了服務器處理的速度；另一個是地圖服務，用于展示當前位置的基本地圖數據，這里發布的地圖數據是以切片的形式存在，切片的好處是可以大大提高地圖的訪問速度，同時降低服務器端的壓力[9]。

切片是將各個比例尺的地圖數據進行預讀處理，將顯示的圖像切割為固定大小的圖片集合(如256×256或512×512)，按一定的規則存儲在磁盤陣列上。

5.2 Web端數據交互

Web端數據交互，主要利用JavaScript、dojo技術實現，通過ajax異步提交與服務器進行數據通信，獲取基礎地理信息、水淹分析結果、路徑分析等數據信息。

基礎地理信息數據獲取核心方法如下：

var MyTiledMapServiceLayer=new esri.layers.ArcGISTiledMapServiceLayer(mapserver,{id:"底圖數據"});

//加載切片數據

MyMap.addLayer(MyTiledMapServiceLayer);

水淹分析數據獲取核心方法如下：

//定義工具箱處理服務

var gp=new Geoprocessor(gpflood);

//異步處理方法

gp.submitJob(params,completeCallback,statusCallback);

//獲取異步處理數據

gp.getResultData(jobId,"result",addResults);

路徑分析數據獲取核心方法如下：

MyMap.graphics.add(solveResult.result.routeResults[0].route.setSymbol(routeSymbol));

5.3 通信平臺數據交互

數據采集層采用GPRS模塊進行數據的采集和通信，采用Socket通信的方式進行數據發送，在Web端采用WebSocket技術[10]進行數據的接收存儲和顯示。

WebSocket技術的優點是能有效接收底層Socket通信層傳來的數據[11]，實時接收，能更方便地直接將數據顯示在Web頁面以及存儲在后臺數據中。

5.4 微信平臺數據交互

微信公眾平臺提供各種消息發送接口，可根據系統的需求設計自動回復和滿足用戶個性化需求的訂制，自動回復需在后臺定義好需要回復的消息信息(包括文本、聲音、圖片和視頻等)，通過二次開發接口，還可通過自定義菜單的方式與用戶直接交互[12]。

主要是通過文本和圖片進行消息的發布，將生成的災情警報專題圖[13]以微信圖片的方式通過新浪云服務上部署的Web服務發送到關注的客戶微信，具體的內容設計格式如下：

其中，PicUrl為生產災情警報專題圖的地址；Url為點擊后連接的具體鏈接地址。

6 系統實驗與分析

系統的實驗平臺為ArcGIS Server10.1,IIS 7.0服務器，新浪云服務，MySQL服務器，微信軟件，GPRS發送模塊，等等。對實現的系統進行了全面測試，通過多臺PC機對基礎數據和水淹分析數據的訪問進行實驗，結果表明數據交互效果較好，如圖4所示。

圖4 水淹分析數據交互

通過多個手機終端微信對系統的關注，通過客戶端發送消息訂閱[14]災情專題圖和系統實時主動發送災情專題圖的實驗，表明數據實時、準確、展現的效果好[15]，能滿足在微信端的信息需求，如圖5所示。

圖5 微信平臺數據交互

7 結束語

在當前多元平臺下，為了滿足洪災報警信息實時傳輸的需求，結合物聯網、WebGIS、移動通信和微信平臺等多種技術平臺設計了多元平臺的洪災報警系統。采用地圖切片技術減少服務器的壓力，提高數據處理效率；充分利用云服務優勢對微信平臺數據進行傳輸；采用了WebSocket技術，既能及時存儲后臺數據庫，又能實時在頁面上進行更新，提高了數據處理能力。解決了傳統洪災報警系統信息傳輸單一的問題。實驗證明，在Web端、移動終端和微信端等平臺，用戶能獲取洪災信息，顯示效果更加直觀、實時，多樣化和交互性強，為洪災報警系統提供了一種新的技術參考。

[1] 應 申,靳鳳攢,李 霖,等.基于ArcGIS Engine的矢量數據分層分塊技術研究[J].測繪地理信息,2014,39(6):50-53.

[2] 王星捷,楊 森.ArcGIS Server分布式技術實現與優化[J].計算機工程與設計,2012,33(9):3432-3436.

[3] 劉小洋,伍民友.車聯網:物聯網在城市交通網絡中的應用[J].計算機應用,2012,32(4):900-904.

[4] 吳 彤,倪紹祥,張春暉,等.基于ArcGIS Server的氣象設備監控系統的設計與實現[J].地球信息科學學報,2011,13(1):80-87.

[5] 鄭貴林,章志福.基于ZigBee信標網絡的水情測報系統設計[J].自動化與儀表,2012,27(4):27-30.

[6] 席 楠,姜立新.基于ArcGIS Server的地震應急數據與服務共享研究[J].地震,2011,31(1):135-145.

[7] 劉曉慧,劉永偉，劉 永.ArcGIS Server分布式體系結構研究與服務器部署策略[J].測繪科學,2011,36(4):205-207.

[8] 楊 斌,張衛冬,張利欣,等.基于SOA的物聯網應用基礎框架[J].計算機工程,2010,36(17):95-97.

[9] 丁克奎,鐘凱文,周旭斌,等.基于WebSocket和GeoJSON的WebGIS的設計與實現[J].測繪通報,2015(2):109-112.

[10] Liu Shujin,Zhu Guoqing.The application of GIS and IOT technology on building fire evacuation[J].Procedia Engineering,2014,71:577-582.

[11] Meng Xiangrui,Wang Junhao,Gao Zhaoning.Research on coal seam floor water inrush monitoring based on perception of IoT coupled with GIS[J].Engineering,2012,4(8):467-476.

[12] Wang Wei,Wu Jianping.Development and inspection of Wechat electronic service quality scale[J].International Business and Management,2014,9(2):92-99.

[13] Ma K,Sun R Y,Lee J H.Introducing websocket-based real-time monitoring system for remote intelligent buildings[J].International Journal of Distributed Sensor Networks,2013,14(2):135-143.

[14] Mediero L,Kjeldsen T R.Regional flood hydrology in a semi-arid catchment using a GLS regression model[J].Journal of Hydrology,2014,514:158-171.

[15] Xie Zuotao,Yang Fangli,Fu Xiaoli.Mathematical model for flood routing in Jingjiang river and Dongting lake network[J].Water Science and Engineering,2012,5(3):259-268.

Design and Implementation of Flood Warning System with Multi-platform

WANG Xing-jie，LIU Hua-chun，LI Chun-hua

(College of Engineering Technology,Chengdu University of Technology,Leshan 614007,China)

With large application of terminal platform and media software,the traditional flood alarm system cannot meet current needs for multi-platform.Therefore,a new development mode has been applied to design and implement flood alarm system.A multi-platform flood alarm system has been established through the Internet of Things,mobile communications,WeChat platform and WEBGIS,by which data acquisition is realized by the IoT,data transmission is achieved by mobile communication,automatic monitoring is realized by the asynchronous processing,analysis of water flooding is realized by GIS,the Web disaster thematic map is generated through WEBGIS,and the WeChat disaster thematic map is generated by WeChat platform.The verification experiment shows that the established system can quickly generate real-time risk maps,early warning information,and disaster assessment etc. and that it can provide a reference for the real-time early warning and disaster relief work as well as a new technical reference for flood alarm system.

multi-platform；WEBGIS；Internet of Things；WeChat

2016-04-06

2016-08-10

時間：2017-02-17

2014年度四川省教育科研項目(14ZB0351)

王星捷(1980-)，男，碩士，副教授，研究方向為數字城市、智慧城市、三維空間數據處理、大數據應用；劉華春，碩士，副教授，研究方向為智能信息處理、機器學習。

http://www.cnki.net/kcms/detail/61.1450.TP.20170217.1623.012.html

TP319

A

1673-629X(2017)04-0196-04

10.3969/j.issn.1673-629X.2017.04.044