基本信息
- 项目名称：
- 基于Google Maps的台风信息管理与服务系统研究与实现
- 来源：
- 第十二届“挑战杯”省赛作品
- 小类：
- 信息技术
- 大类：
- 科技发明制作B类
- 简介：
- 目前，WEBGIS大多是基于企业级GIS平台开发的，以这种形式开发的系统都普遍存在一些不足。本研究探讨了基于Google Maps等技术建立WebGIS系统。该系统集成了一个将台风信息数据表示、地图可视化表达、专题展示、查询、统计分析和信息发布与一体的，基于网络的管理与服务系统，为气象信息科学添加了新的研究内容，也能应用于实际的气象信息的共享和管理。
- 详细介绍：
- 一、研究背景 我国是一个台风灾害多发的国家，深受台风灾害所带来破坏的影响。随着计算机技术，网络技术和GIS等技术的发展，台风管理部门对台风信息的管理与服务的要求也越来越高。目前国内外已经有研究将网络地理信息系统（WebGIS）技术用于台风信息的共享与管理中，但是这些台风信息系统大多数都是基于成熟的企业级WEBGIS 平台开发的，这些系统虽然已经用于地理信息管理等服务中，但是它们都存在着不足。 本研究是基于Google Maps 的地图资源，将广为人知的Google 地图嵌入到网页中，利用其免费提供的API 研究的GIS，并应用AJAX 技术进行脚本的异步调用，使得用户可以不刷新整个页面，调用形成一种全新的WEBGIS，这在理论上是一种大胆的尝试与创新；本系统具有较强的现实意义，为台风信息的共享与管理起到了较好的作用。 二、系统设计与开发 （一）需求分析 基于Google Maps的台风信息管理与服务系统（在本文以下内容中，在不产生混淆的前提下，将其称为“台风信息管理与服务系统”）要能通过网络获取或人工输入等方式，对台风路径信息以及台风观测点信息等进行录入、管理与显示，并自动实时地将台风信息、风圈半径影响进行分析，将台风实况信息和预测信息综合显示于地理地图中，将数值信息予以可视化表达。能通过台风实况与预测路径、风圈半径与地理底图的叠加，能够为气象预报和防汛指挥部门提供科学决策依据。能实现台风基础信息服务，并提供台风专题信息以及台风知识等，能为公众提供精度更高、效果更直观、速度更快的高质量的气象服务。 （二）架构设计 由于台风信息管理与服务系统是基于Google Maps的地图资源，将Google地图这种网络资源嵌入到网页中，所有台风实况信息和预测信息都需要从台风信息数据库里读或者向台风信息数据库里写，然后在Google地图上实时可视化展示，故本系统整体上采用典型的三层WebGIS架构。 本研究要开发的WebGIS，选用ASP.NET平台下开发服务器端的动态Web程序，利用Google Maps API作为地图数据源，用于创建和配置WebGIS应用程序的一个部分。应用AJAX技术，减少了冗余请求和响应对服务器造成的负荷，实现客户端的异步数据读取。底层的数据层是台风信息数据库，由微软的SQL Server管理与维护；中间层即应用逻辑层，又由Web服务层和Google 地图服务器组成，由微软的IIS作为Web服务器，这里的Google地图服务器就相当于一般WebGIS当中的GIS服务器,使用LINQ技术读写到数据库；客户层即用户浏览器。 （三）功能模块设计 基于Google Maps的台风信息管理与服务系统要实现台风信息快速显示、台风专题、历史查询、统计与分析、信息发布、系统帮助等模块功能。 （四）数据库设计 通过对台风性质的研究，可以发现组成台风信息的元素众多，台风路径包括了台风编号、台风名、英文名、生成时间、生成位置、首次登录地点，每一条台风路径均包括了多个观测点，每个观测点的信息包括时间、中心位置、中心风力、最大风速、中心气压、移动速度、移动方向、七级风圈半径、十级风圈半径、预报台路径、强度类型。 由于Google Maps API对折线GPolyline提供一个函数fromEncoded()，可以不需要将若干对点的经度和纬度作为折线实体属性，而是通过将由若干对组成折线的点经纬度按序编码完的字符串和编码级别作为其属性来代替若干对经纬度表示折线，故可以将编码后的字符串和编码级别作为台风路径的两个属性，这样一条台风路径折线实体存储到关系数据库二维表的一个元组中，且均作为单个数据项。台风观测点也是空间实体信息，但是由于观测点的空间信息仅包括一对经纬度，且每个观测点的预测路径均可以通过上述编码方式来存储，故一个台风观测点也可以存储到关系数据库二维表的一个元组中。于是用一张表来存储台风路径信息，用另一张表存储台风观测点信息，再用一张表来存储特权用户的登录信息。 （五）系统开发 本系统选用了微软Visual Studio 2008集成开发环境下的ASP.NET 3.5平台进行开发，选用了C#语言作为系统服务器端程序的编写，用JavaScript语言作为系统客户端程序的编写，用微软SQL Server 2008 R2进行台风信息数据库的创建和管理。页面中基于.Net的控件全部采用第三方控件工具Developer Express v2010制作，其它控件由Adobe Dreamweaver CS4软件制作。 三、系统理论设计关键算法 （一）数据模型转化的算法 由于台风信息是地理空间信息，通过存多对坐标的方式来将一条台风路径折线实体存储到关系数据库二维表的一个元组中不现实，因为第二代关系数据库不支持嵌套与面向对象模型，并且折线点对的个数是不确定的，若将其存储于单个元组中将会带来数据项个数不确定，需要进行由面向对象的空间数据模型向关系数据模型转化，也就是要将若干个经纬度对转换为编码和编码级别的算法编程实现。 该编码算法的基本原理是将经纬度对以二进制的形式表现出来，再将这些二进制有序地转化为ASCII码存储，具体步骤如下： （1）取初始有符号值； （2）将其取十进制值乘以1 e 5，并取整 X； （3）将十进制值转换为二进制值，必须通过对二进制值求反并在结果中添加 1 的方法，使用负值的二补码来计算负值。 若X >= 0，则得32位二进制字符串 ∑ f ( i ) = b ( X )（其中f ( i ) = ” 0 ” 或 ” 1 ”，0 < i < 32，b ( X ) 为正数转为32位二进制数的函数）；若 X < 0，则得32位二进制字符串 ∑ f ( i ) = r ( b ( -X ) ) + “ 1 ” （其中r ( x ) 为二进制取反函数，0 < i < 32，∑表示字符串连接）； （4）将二进制值左移1位，即 ∑ f ( i ) = ∑ f ( i ) + ” 0 ”（0 < i < 32 ）； （5）如果原来的十进制值是负值，则对该编码求反，得 ∑ f ( i ) = ∑ r ( f ( i ) ) + ” 0 ”（0 < i < 32）； （6）将该二进制值分为5位一组的块（从右侧开始），得 ∑∑ F ( j , k ) = g ( a ( ∑ f ( i ) , ” 000 ” ) , 5 ) （其中 a ( x , y ) 为在 x 左边插入字符串 y，g ( x , y ) 为将字符串 x 按 y 个字符进行分组，得 0 < j < 7， 0 < k < 5）； （7）将这些 5 位一组的块倒序放置，得 ∑∑ F ( j , k ) = R ( ∑ F ( j ) ) （R ( x ) 为字符串倒置函数）； （8）如果后面还有一个位块，则将每个值与0x20进行“或” ( OR ) 操作，得∑∑ F ( j , k ) = OR ( ∑∑ F ( j , k ) , 0x20 )（其中0 < j < 7，0 < k < 5）； （9）将每个值转换为十进制值，得 ∑ f2 ( i ) = o ( ∑ F ( j ) )（其中f2 ( i ) 为十进制数，o ( x )为转换为十进制函数）； （10）将每个值加上63，得 ∑ f2 ( i ) = ∑ ( f2 ( i ) + 63 )； （11）将每个值转换为其 ASCII 对应值 ∑ f2 ( i ) = ∑ ( asc ( f2 ( i ) ) )（其中asc ( x )为数字转化ASCII值）； （二）台风风圈显示的算法 由于Google Maps API没有加载圆形空间实体的函数，故台风风圈的地图显示需要根据中心点的经纬度、风圈半径以及该点在地球上的位置算出相应的正100边形的上的100个点，正100边形已经可以近似等同于圆形了，具体步骤如下： （1）获取风圈半径 r ( km ) 和圆心的纬度 lat ( ° )、经度 lot ( ° )； （2）计算出该圆心的半径的长度相当于纬度的角度数Clat = r / ( C / 360° )，其中C为赤道的长度等于40075.04 km，Clat = r /111.32； （3）计算出该圆心的半径的长度相当于在该位置经度的角度数Clon = Clat / cos ( lat )； （4）正100边形共包含100个等腰三角形，每个三角形顶角为3.6°，故每个圆心到顶点的向量为 ( Clat * sin ( 3.6° * i ) , Clon * cos ( 3.6° * i ) )。 （三）台风路径预测的算法 台风相似性，在一定程度上反映了相似的台风影响，因此，与预台风台风未来的发展趋势可推断台风采样类似的路径，也就是说，点类似方法的基本观。本研究采用如下的算法如图5所示，P1，P2和P3分别为实时路径12小时，6小时和当前点记录；H1，H2和H3为落入相同的历史路径台风的P1，从P1，P2和P3的最近点P2和P3的缓冲区。根据获取的属性信息获取H1，H2和H1，H3的两个时间间隔的记录，得到两台风的移动速率比，假设H2、H3两点的时间间隔为12小时，可确定台风历史与台风中心的移动速度比率为1 /2。同理计算出H1和H3的速度比点的时间间隔为1 /2，如果两次结果不等则取平均值。根据比率选定H3后的点为48小时后的24小时台风预报的实时参考点。 获得相似的历史所需的参考点，台风预报后，用路径的相似度计算方法相结合，得到历史的权重相似的台风，得到所需的相似历史台风的预测参考点之后,再结合路径相似度算法的方法得到的各历史台风相似度的权重, 计算出了当前位置的未来台风的预报公式。 四、系统特点 （一）系统多层架构体系 系统多层架构体系，采用典型的基于B/S的客户层、业务逻辑层和数据层三层架构，分别管理界面显示、逻辑流转控制、数据处理，业务逻辑层又可以细分为Web程序服务层和Google Maps服务层，这样使得系统开发结构层次分明、功能分工明确。 （二）无需组织复杂的空间数据库 无需组织复杂的空间数据库，这是本系统最明显的特点。与传统的基于ArcIMS的WEBGIS 相比，本研究不需要设计和现实多层的、复杂的空间数据，这就大大降低了开发的成本。与此同时，数据库也是属性数据库，这样就可以将存坐标的空间数据库转化为存编码的属性数据库。 （三）可自定义用户界面 与传统的基于ArcIMS的WebGIS客户端标准界面相比，采用Google Maps API开发，首先从地图表现上，用户将会更加青睐皆为熟知的电子地图，本系统都是从用户业务和习惯的角度出发，按照方便、快捷与人性化原则来设计用户界面的。 （四）灵活运用组件和接口 为了获得系统的运行的高效性，在开发过程中编写和调用了一些组件，让它们直接独立地处理相关的逻辑业务。同时为了保持系统的可扩展性，系统中设计和预留了一些接口，为今后系统的扩展和更新作了充分的准备。 五、结语 基于Google Maps的WebGIS将Google Maps提供的API进行二次开发，并应用AJAX技术进行脚本的异步调用形成一种全新的WebGIS，这在理论上是一种大胆的尝试与创新。系统的实施为GIS 增添了台风信息系统研究的新内容，并能应用于台风气象灾害数据信息的管理与服务。
作品图片
作品专业信息
设计、发明的目的和基本思路、创新点、技术关键和主要技术指标
- 本作品将广为人知的Google地图嵌入到网页中，利用其免费提供的API研究的GIS，并应用AJAX技术进行客户端与服务器端的异步调用，并综合运用ASP.Net、SQL Server、LINQ、WebServices、C#、JavaScript、CSS、HTML等相关技术和编程语言建立WebGIS系统。
科学性、先进性
- 作品采用典型基于B/S 的客户层、业务逻辑层和数据层三层架构，分别管理界面显示、逻辑流转控制、数据处理，业务逻辑层又可以细分为Web 程序服务层和Google Maps 服务层，相比传统的C/S架构的系统，本作品开发结构层次分明、功能分工明确。 无需组织复杂的空间数据库，这是本作品最明显的特点。由于本系统的地图显示采用Google Maps提供的服务，所有的地图数据都来源于Google地图，与传统的基于ArcGIS Server的WEBGIS相比，本研究不需要设计和现实多层的、复杂的空间数据，这就大大降低了开发的成本。与此同时，数据库也是属性数据库，这样就可以将存坐标的空间数据库转化为存编码的属性数据库。 可自定义用户界面，与传统的WebGIS客户端标准界面相比，采用Google Maps API开发，首先从地图表现上，用户将会更加青睐皆为熟知的电子地图，并且无论是系统的基本操作还是业务功能操作，本系统都按照方便、快捷与人性化原则来设计用户界面的。
获奖情况及鉴定结果
- 作品参加本校第九届“创新杯”大学生课外科技学术作品竞赛获得科技发明制作类特等奖。 有关作品系统原理的论文于2010年9月参加<<中国高新技术企业>>杂志优秀学术论文征文活动，已发表见刊。
作品所处阶段
- 生产阶段
技术转让方式
- 现有技术的通过发表学术论文的形式供他人参考和引用，后期技术完全成熟后，以商业化的形式转让。
作品可展示的形式
- 实物、产品，磁盘，现场演示，图片，录像
使用说明,技术特点和优势,适应范围,推广前景的技术性说明,市场分析,经济效益预测
- 目前本作品的实施为地理信息科学增添了台风信息系统研究的新内容，并能应用于气象灾害数据信息的管理与服务，为公众提供精度更高、效果更直观的高质量气象服务。 有关本作品的系统结构和原理是值得推广的，本作品开发的WebGIS，选用ASP.NET平台下开发服务器端的动态Web程序，利用Google Maps API作为地图数据源。该系统的结构，可用于建立网络环境下的历史事件记录、灾害信息管理、地图向导系统等。 目前市面上的WebGIS大多采用基于成熟的企业级WEBGIS平台开发的，最典型就是ArcGIS Server，这但是它们都存在着这样的不足：开发平台购买价格昂贵；需要组织各种复杂的空间数据；地图显示信息与地图行为匮乏。目前ArcGIS Server高级版市场价是74万人民币，ArcSDE是13万，加上系统可能需要的各种空间数据库，一般都会超过100万人民币，如果系统不需要现实太多的空间分析，那么系统可以换用Google Maps，完全就可以省去这笔钱。
同类课题研究水平概述
- 通常B/S结构的WebGIS采用如下所述的三层架构。它以普通的浏览器作为客户端，将由应用程序开发、维护以及之间的服务调用组成的中间层放在相应的程序服务器上，将数据库的建立和管理放在另外的数据库服务器上，形成一个由客户表现层、中间应用逻辑层和底层数据层组成的三层体系结构，通常WebGIS系统中间业务逻辑层一般包括Web服务器和GIS服务器。这样的系统往往依托与企业级商用的WebGIS开发平台，成本很高，还需要维护花较高的成本去维护GIS服务器和配置各种复杂的空间数据。 基于Google Maps API的WebGIS国内外也有不少研究，大多数是重客户端，轻服务器端，服务端往往逻辑很简单，只是和数据层相连，有的甚至将Web服务器这一层给弱化了。这一来就导致AJAX技术重在客户端，技术上实现相对成本较高，而服务器端快速建立AJAX引擎技术的优势就没有很好的发挥出来。数据层往往是也是诸如MySQL这样的小型数据库，管理海量地理空间数据能力有限，有的甚至没有数据库，而用XML或是txt等格式的文件作为数据层，这样管理海量数据的能力就更差的了。也有小部分基于Google Maps API的WebGIS是C/S两层架构的，这样用户不仅要联网获取Web地图资源，而且还将繁杂的业务逻辑转换到用户的机器上，这样就增加了用户的负担，并且也没有将WebGIS大众化、随时随地获取的优势体现出来。 通常网络环境下的台风信息系统大多它们都实现了台风路径显示，台风信息显示，台风信息查询等基本功能，但使用的技术各不相同，有的没有使用WebGIS技术，而是采用静态图片、Applet、VML等技术，空间分析等功能难以实现；并且很少有对台风数据进行统计分析，更少有研究台风路径预测的算法，通过历史数据去推测台风路径的走势；多数系统都只在气象部门或相关部门内部使用，他们应用对象仅为某一地区的某一部门内部人员，仅作为内部人员预报台风走向，研究和管理台风信息用，不能推向网络，及时向社会和公众发布；在数据查询方面，这些系统大都未考虑将数据、业务逻辑和表现形式分离开来，系统维护和功能扩展会受限制。
