气象数据分析系统

气象数据分析系统（精选6篇）

篇1：气象数据分析系统

摘要 数据存储技术经历了从手工管理到文件管理、再到数据库管理系统3个阶段，数据库技术中关系数据库占据了主要地位。针对气象行业a文件所存储的历史数据的管理和共享问题，应用visual studio、c#语言的开发环境，利用sql server 2008数据库技术实现信息共享，建立详细的历史资料数据库，将a文件数据进行统一入库，实现各类天气情况的历史查询、统计、显示、导出，为以后气候分析、气象灾害风险评估等提供基础数据支撑。

关键词 气象基础数据；支撑系统；数据库；软件设计；甘肃临夏

中图分类号 p409 文献标识码 a 文章编号 1007-5739（2016）09-0241-03

现在社会经济飞速发展，对气象要素、各种气象极值及气象服务产品的质量要求越来越高。气象是为当地政府及农业生产服务的，目前提供预报服务产品还是靠传统的手工抄录资料、手工计算等。制作起来不仅慢，还存在不准确、繁琐、气象产品供给性不及时等现象。气象信息的传递与经济飞速发展及农业生产实际需求存在差距。缺少多样性和针对性，这与越来越精细化的农业生产管理要求极不相适应。因此，再按老套路的办法手工抄录资料、手工计算等制作服务产品，势必跟不上形势发展的需要，这就要求气象工作者改变现状，制作出一套既快又便捷的制作服务产品的系统，依靠科技进步改善气象信息的准确性。

临夏州气象灾害占到自然灾害的86%以上，主要是干旱、晚霜冻、冰雹、雷阵雨、大风、大（暴）雨等，其发生的频率高，危害的范围广，特别是对农业生产、农业设施、水资源、生态系统造成巨大的影响，因此随着气象灾害风险评估的需求日益增长，建立一个详细的历史资料数据库（资料来源是各县市a文件数据），将a文件数据进行统一，实现各类天气情况的历史查询、统计、导出，为以后气候分析、气象灾害风险评估提供基础数据支撑具有重大的意义[1-2]。开发环境与开发语言

应用visual studio、c#语言的开发环境。利用sql server 2008将结构化、半结构化和非结构化文档的数据直接存储到数据库中。对数据进行查询、搜索、同步、分析和导出操作。数据整理和软件设计

2.1 a文件结构分析

a文件是气象部门以文本格式存储每月气象数据的文件，1个a文件存储1个站点1个月的气象数据，是气象上最早存储气象资料的方式之一，这种方式直到目前还在使用。它从手工制作到自动化形成大体分3个阶段：第一阶段是1951―1980年，这个阶段主要是以手工制作为主，主要存储的是每天3次观测（8：00、14：00、20：00）的数据及一些日数据；第二阶段是1980―2005年，是手工制作向自动化推进的发展阶段，主要存储的是每天4次观测（2：00、8：00、14：00、20：00）的数据及一些日数据、最值；第三阶段为2006年到现在，这个阶段其格式正式规范化、精细化，制作进入纯自动化，主要存储的是每个小时观测的数据以及一些日数据、最值及其出现时间。a文件经过了以上3个阶段改革在格式上有着很大的不同，如果要将这些宝贵的数据存储到统一的数据库中，对分析历年a文件存储格式至关重要[3]。

从表1可以看出，a文件格式上虽有着很大不同，但是它却有着很强的规律性，总体来看它的数据存储可以分成2类，第一类是小时数据存储，存储的是特定某个小时的数据，它的变化规律是从定时化向着每小时化变化，总的趋势是从8：00、14：00、20：00到2：00、8：00、14：00、20：00再向00：00―23：00变化的；第二类是日数据，即1 d只有1个观测数据，如每天的最大值、最小值、蒸发、日照等要素数据。下面归类了这2类数据的成员组成：小时数据包括气压、气温、降水、相对湿度、水汽压、露点温度、风、地温、深层地温、云、日照、能见度等。日数据包括蒸发、日照、雪、冻土、天气现象、最值出现时间、夜晚降水、白天降水、日降水等。结合上述，如何把3次（8：00、14：00、20：00）、4次（2：00、8：00、14：00、20：00）及24 h观测的数据进行统一，就要把a文件格式变化分成2个阶段：一个是3次观测；另一个是4次和24 h观测。由此格式转换上就有了很清晰的思路，首先可以通过年代判断是3次观测阶段还是4次或24 h观测阶段；然后确定好a文件中所包含的信息量，设定好时间；最后通过符号所代表的气象要素及其格式读取相应的数据，对照表1和2类数据的各要素组成把数据放入到相应的数据存储空间。

2.2 数据库设计

sql server 2008在microsoft的数据平台上发布，可以组织管理任何数据[4]。可以将结构化、半结构化和非结构化文档的数据直接存储到数据库中。可以对数据进行查询、搜索、同步、报告和分析之类的操作。数据可以存储在各种设备上，从数据中心最大的服务器一直到桌面计算机和移动设备，它都可以控制数据而不用管数据存储在哪里。在这里通过a文件的结构分析结果建立相应的数据库。分析a文件格式，a文件中存在2种类型数据，一类是小时数据，一类是日数据，并且这2类数据由不同气象要素组合，根据不同数据类型设计合理的数据存储空间结构。

2.2.1 小时数据。小时数据项组成：站点编号、日期、气压、气温、降水、相对湿度、水汽压、露点、温度、2 min风向、2 min风速、10 min风向、10 min风速、0 cm地温、5 cm地温、10 cm地温、15 cm地温、20 cm地温、40 cm地温、80 cm地温、160 cm地温、320 cm地温、云状、总云量、低云量、日照、能见度等。数据表id：dbo.per_day_data。数据来源：a文件。数据入库方式：应用软件转换入库。简述：4次观测，每天4组数据；每小时观测，每天24组数据。

2.2.2 日数据。日数据项组成：站点编号、日期、蒸发、日照、雪深、雪压、第一冻土层上限、第一冻土层下限、第二冻土层上限、第二冻土层下限、天气现象、最大气压、最大气压出现时间、最小气压、最小气压出现时间、最高气温、最高气温出现时间、最低气温、最低气温出现时间、最小相对湿度、最小相对湿度出现时间、10 min最大风风向、10 min最大风风速、10 min最大风出现时间、10 min极大风风向、10 min极大风风速、10 min极大风出现时间、0 cm地温最高、0 cm地温最高出现时间、0 cm地温最低、0 cm地温最低出现时间、夜晚降水、白天降水、降水日合计等。数据表id：dbo.per_day_data。数据来源：a文件。数据入库方式：应用软件转换入库。简述：一天一组数据，以天为周期[5-6]。

2.3 软件功能制作

随着气象观测的自动化，数据文件的规范化、详细化，作为存储观测数据的a文件已经不方便进行数据查询统计了；除此之外，规范前的a文件数据格式和规范后的a文件数据格式有着很大的差异，以前的一些查询统计软件已经不能够实现一些关键性的功能，因此开发一个新的应用平台来实现数据的整理（建立一个的专门的数据库来存储a文件的数据）、查询、统计、导出等功能是很有必要的。

2.3.1 a文件转换与入库。1950―2004年的a文件，格式上有着或多或少的变化，2005年以后随着a文件的规范化和数据的详细化，文件格式又有大的变化，因此把a文件数据格式进行转换入库是本平台的基本功能，也是核心功能之一（图1）。

a文件数据转换入库功能模块：一是实现a文件数据的读取，统一数据格式并把统一后的数据在表格中显示；二是把统一后的数据导入到建立好的数据库中；三是制作管理员的权限，即当用户只能在登录上管理员后才能应用这个功能。模块界面如图2～4所示。

2.3.2 查询、统计、显示、导出。查询：通过sql语言，根据设定的站点、时间从数据库中查询符合条件的数据并存入表格。统计：第1种方式是直接通过查询出来的数据，做合计、筛选、归类、降序、升序处理得出所需要的结果；第2种方式是在数据库中直接检索结果数据。显示：数据以表格的格式显示，以柱状图、折线图、曲线图、玫瑰图直观显示数据发展趋势。导出：存在表格中的数据可以导出到excel中，便于以后处理。表2详细叙述了平台实现的功能。结语

建立了易于存取、查询、检索的数据库，实现对数据的统一管理。把a文件数据无差错的转换导入到了建立好的数据库中，更好地保存了这些数据。为了能够方便运用这些数据，制作了相应的应用软件实现各类气象数据的查询、统计、显示、导出等功能，为以后气候分析、气象灾害风险评估等工作提供了很好的数据支撑和方便。

篇2：气象数据分析系统

高空气象探测系统现状分析与未来发展

1 引言 中国作为世界气象组织(WMO,World Meteorological Organization)成员国的一个气象大国,在全国多部门共建有4000多个各类气象台站,其中气象部门占65%.截至到底,气象部门在全国布设了146部新一代天气雷达、120个探空站、10部风廓线仪、2416个国家级气象观测站、202个GPS/MET站、325个雷电监测站、34个大气成分观测站、317个酸雨观测站、640个生态与农业观测站.

作 者：李柏 李伟  作者单位：中国气象局气象探测中心 刊 名：中国仪器仪表 英文刊名：CHINA INSTRUMENTATION 年，卷(期)： “”(6) 分类号： 关键词： 

篇3：民航气象数据库系统发布

由于工作需要, 民航气象数据库系统外部设备接入过多, 导致数据库系统面临各种安全威胁。外网用户可以通过防火墙直接读取数据库, 首先频繁的直接存取操作容易导致数据库错误, 其次终端用户的误操作, 可能造成数据库损坏, 同时外部用户的入侵、非授权的访问、病毒、木马等都可能造成数据库系统运行瘫痪, 进而影响气象对外服务工作。有效的解决办法就是建立合理的网络拓朴和气象数据库系统发布并与民航数据库系统进行松藕合, 对各种民航气象资料进行统一、汇总、入库发布, 以便更好地为航空用户提供服务。

2 开发的主要内容

2.1 物理架构设计

物理架构描述了民航气象数据库系统发布的部署结构, 强调了各种应用的部署和运行环境以及相互之间的物理连接状况, 系统的物理架构如图1所示。

按着民航局空管局的三级安全要求, 进行内网与外网物理隔离, 因此此逻辑架构分为内网区、停火区、外网区。

内网区指的是民航数据库系统的网络, 内网是指气象台管理的所有业务系统, 包括气象数据库及气象台内部的各信息系统, 是已有设备。

停火区是用来隔离内网与外网的, 主要的设备为内网通信机、网闸、外网通信机、交换机、防火墙等物理设备。软件包括网闸资料交换子系统、气象资料分发子系统。

外网是指气象台外部用户的接入网络, 包括管制、航空公司、机场等外部系统。

2.2 资料获取

民航气象数据库系统是由通讯子系统、数据库子系统、信息服务平台等系统组成。气象资料在此系统上进行交换、存储、展示, 是民航业务主要的系统之一。数据库采用oracle 10G数据库。本套系统的资料获取就是通过此系统提供的接口进行数据传输, 经过大量的实践验收, 我们采用松耦合方式, 此方式是通过MQ (FTP为辅) 的方式, 通过民航气象数据库系统的通信子系统增加新的线路与队列进行数据交换。

(1) 增加线路。修改线路表mssini.ini文件, 以增加新的线路;添加DB03线路名称以及配置。如图2所示。

(2) 定义转发目录。修改critical文件, 增加FTP辅助线路, 添加DB03如下的配置:

(3) 配置FTP参数。添加FTP线路的用户名与密码, 修改.netrc文件, 添加如下记录, 其中用户名与密码为通信服务器密码。

(4) 创建MQ队列。把mqdef_comm.db复制到/home/comm目录下。

运行如下命令:runmqsc

再运行如下命令:runmqchl-c ZLLL.TO.DB03&

2.3 网闸交换子系统

网闸资料交换子系统主要是负责把资料实时地从内网通信机资料接引到外网通信机。

为了更加简明的对内外网数据同步问题进行阐述, 用内外网数据同步数据流程图的方式展示出来, 可以直观地反映出数据同步的原理和方法, 如图3:

数据流程说明:

内网通信机将通过民航数据库MQ线路以文件的方式把资料收集到标准的目录结构下, 内网通信机与外网通信机通过网闸处理程序, 进行资料的同步通讯, 外网通信机将接收到的数据以文件的方式存储到标准的目录结构下, 并通过FTP与入库程序存储到应用服务器的数据库下, 从而实现内外网数据的同步。

2.4 资料分发子系统

(1) 线路管理。

用户登录系统后, 选择线路管理->FTP线路管理, 进入FTP线路管理页面。系统分页列出已定义的线路, 线路可以连接上显示已连接, 否则显示未连接。点击添加, 显示添加线路页面, 录入线路信息, 点击保存, 添加一条新的线路, 在操作列点击查看, 点击可以查看此线路上运行的发送、获取进程列表以及启停状态。在操作列点击删除, 已使用线路会有提示不允许删除;未使用线路则可正常删除。

(2) 资料规则。

发送规则:用户登录系统后, 选择资料规则->发送规则, 进入发送规则管理页面。系统分页列出已定义的发送规则。点击添加, 进入规则添加页面, 输入规则信息, 可正常添加规则。操作列点击“启动”或“停止”, 进行启停线程的操作。进程可以正常启动;启动进程后资料按照规则定义将本地资料通过定义线路发送到远程机器。进程可以正常停止, 停止后此进程指定的资料不再发送。操作列点击删除进行规则删除操作, 已启动进程的规则会有提示, 停止状态的规则可以正常删除。

获取规则:用户登录系统后, 选择资料规则->获取规则, 进入获取规则管理页面。系统分页列出已定义的获取规则。点击添加, 进入规则添加页面, 输入规则信息, 可正常添加规则。操作列点击“启动”或“停止”, 进行启停线程的操作。进程可以正常启动;启动进程后资料按照规则定义进行远程资料获取到本地目录。进程可以正常停止, 停止后此进程指定的资料不再获取远程资料到本地。操作列点击删除进行规则删除操作, 已启动进程的规则会有提示, 停止状态的规则可以正常删除。

(3) 日志管理。

发送日志:用户登录系统后, 选择日志管理->发送日志, 进入发送日志管理页面, 系统列出日志文件列表。在日志列表操作列点击查看, 可查看当前日志的最新100行记录。在日志列表操作列点击下载, 可下载当前日志。

获取日志:用户登录系统后, 选择日志管理->获取日志, 进入获取日志管理页面, 系统列出日志文件列表。

操作日志:用户登录系统后, 选择日志管理->操作日志, 进入操作日志管理页面, 系统列出日志文件列表。

(4) 系统管理。

用户管理:用户登录系统后, 选择系统管理->用户管理, 进入用户管理页面, 系统列出用户列表。点击添加, 录入用户信息, 添加新的用户。点击修改, 可以修改用户密码。点击删除, 可以删除用户。

系统参数:用户登录系统后, 选择系统管理->系统参数, 进入系统参数管理页面。可以设置trash保留小时数, 设置结果可以生效。

2.5 数据库子系统

本套系统的数据库系统担负定期储存、管理资料的功能, 与原来相比, 资料的种类及数量都有很大的增加。目前数据库拥有的资料有:飞行气象情报 (包括例行天气报告及特选报、机场预报及订正报、区域预报和航线预报、重要气象情报等) , 常规天气图 (包括高空天气图、地面天气图) 、剖面天气图及温度-压力对数图 (T-LOG P) 等图形产品资料, 常规报文资料及要素场形式的资料, 格点资料及传真图形式的各个不同时次的数值预报产品及数值诊断分析产品自动观测系统和气象雷达的探测资料, 以及气象卫星云图产品。

根据用户的需求应用库中的数据要定期进行压缩归档, 同时将资料存入历史库。归档后的压缩文件, 解压缩后重新恢复到数据库的临时历史库上。对于应用库和历史库中超过期限的气象资料要进行清除。对于数据库的复制、清除、归档、恢复等操作都要进行日志记录。基于用户数据在库中存储时间上的区别, 我们在数据库结构设计上要充分考虑, 以满足系统功能上的需要。

3 研制的意义

建立合理的网络拓扑, 保护核心数据库, 利用计算机通讯技术将兰州空管气象台现有民航气象数据库系统中的气象资料发布到标准目录区, 由系统获取到本地数据库, 以丰富其航空公司气象资料;系统采用先进成熟的技术满足当前的业务需求, 兼顾其他相关的业务需求, 尽可能采用先进的技术, 使整个系统在一段时期内保持技术的先进, 并具有良好的发展潜力, 以适应未来业务的发展和技术升级的需要;系统设计实现时需要保证本系统的安全性, 采用相关的软硬件技术提供较强的管理机制、控制手段和事故监控和网络安全等技术措施, 提高网络系统的安全性。系统软硬件配置要合理、精炼, 并充分利用已有资源。

摘要：民航气象数据库系统是民航气象业务的核心系统之一, 承担着提供飞行气象情报及气象资料的交换、备供、存储等重要任务, 其服务子系统具备航空气象用户查询和检索飞行气象情报、打印飞行气象文件、查询自动气象观测、气象雷达、气象卫星资料等功能。同时该系统还承担对外提供相关服务的航空气象信息服务任务, 因此数据库的安全运行尤为重要。文章介绍了如何建立合理的网络拓扑, 保护核心数据库。

关键词：数据库,安全,IBM,MQ

参考文献

[1]甘荃, 娄丽军.IBM Websphere MQ基础教程[M].北京:电子工业出版社, 2004

篇4：气象数据分析系统

关键词：数据库；通信分系统设计

0 引言

在中国民用航空领域中，航空气象数据库系统需要具有飞行气象情报及气象资料的交换、备供、存储等能力，由相关网络设施、通信分系统及数据库分等部分组成。石家庄正定国际机场目前使用的该系统，与民航北京气象中心联网，接收并汇交相关气象情报及资料，向其汇交本地雷达、自观、报文等气象资料，同时接收其下发的国内、国际飞行所需的综合航空气象情报信息，为石家庄航空安全提供保障。下面将以通信分系统为例，以软件设计角度对系统需求、概要、详细设计等三个阶段进行简单解析，从而更加容易理解该系统的通信分系统。

1 系统整体结构设计

由上图所示，石家庄机场的航空气象数据库系统主要由气象数据收集处理和信息应用组成，展示时气象信息使用用户通过局域网，以web网页或飞行文件综合方式获取航空中所需气象情报。

业务处理部分主要包括气象数据库和通信分系统，可通过通信系统收集处理民航报告、常规报告、自动观测资料（AWOS）、风温廓线仪、自动站资料、Bufr资料、Grib资料、Fax资料、卫星云图资料、本地图形图像资料、多媒体资料、雷达等资料，随后，通过预报综合平台及网页版的形式进行气象信息业务的展示。数据库管理子系统采用客户机服务器方式，可对资料处理、数据库等进行实时监控和管理。有资料处理子系统和数据库管理子系统。

2 通信分系统需求设计

通信分系统是航空气象数据库系统中最重要的组成部分，它负责全系统的气象资料接收、检查与处理、发送，及请求的应答。本通信分系统分为通信系统以及监控维护操作平台。为数据库分系统和数据交换服务器提供数据源，支持一个数据源同时向多个本地相同数据库提供数据的功能。在系统设计时满足了以下需求。

2.1 在通信分系统中需要配备一个通信前置机，数据传输同时支持AFTN、PSTN和网络传输模式。

2.2 以安全可靠为重点，监控系统对监控的内容出现异常的情况下，以声音、闪烁或者不同颜色进行告警。

2.3 对气象资料的处理达到准确、及时，保证地区中心通信主机与地区中心数据交换服务器上的数据实时、完整、一致。

2.4 充分考虑操作的方便，将监控和操作与通信分系统整合到一起，开发以鼠标为主、键盘为辅的图形化操作界面。应有详尽的联机操作手册，界面设计合理，逻辑清晰，使用方便，颜色的搭配应美观大方。

2.5 与其他分系统间的接口要尽量简单，使各分系统故障时不影响其他分系统为基本考虑，并易于界定故障点。

2.6 利用通信中间件的开放性，与其他分系统的信息传输，尽量采用通信中间件。

2.7 通信分系统应用软件应设有守护程序，确保通信应用软件的主进程不间断运行。

3 通信分系统概要设计

通信分系统在概要设计时要求有以下约束条件。

3.1 安全可靠为重点，对气象资料的处理达到准确、及时。

3.2 充分考虑操作的方便，将监控和操作与通信分系统整合到一起，开发以鼠标为主、键盘为辅的图形化操作界面。应有详尽的联机操作手册，界面设计合理，逻辑清晰，使用方便，颜色的搭配应美观大方。

3.3 与其他分系统间的接口要尽量简单，使各分系统故障时不影响其他分系统为基本考虑，并易于界定故障点。

3.4 利用通信中间件的开放性，与其他分系统的信息传输，尽量采用通信中间件。通信分系统应用软件应设有守护程序，确保通信应用软件的主进程不间断运行。

4 通信分系统详细设计

通信分系统的详细设计，是根据上述功能需求书、功能规格说明书和概要设计说明书完成的，对通信分系统各个进程间的控制流程和数据流程，说明了组成各个进程的主要模块，每个模块的具体功能、输入、输出参数和数据流程，以及通信分系统与数据库分系统、图形图象制作分系统之间的接口、输入输出、数据流程。

4.1 系统程序结构

通信分系统的业务处理部分，包括通信主机上的通信软件和通信分系统的监视、维护和操作界面。业务处理部分是实时系统，负责不同气象要素收集、发送缺漏报文图形文件要报处理，通过MQ管道技术和多进程方式，提高数据处理效率，通过内消息队列管理，交换进程间信息及参数。异步线路资料的发送接收；气象资料的检查与处理；电报公报报告信息处理；监控、维护维修监控平台综合化；MQ通道管理报文处理发送；数据库落地文件的生成等，都是该通信子系统所包括的功能。

4.2 通信业务处理结构示意图（图2）

4.3 通信业务处理部分功能列表

4.4 通信分系统起始程序（inimss）

以系统起始程序为例，该程序对整个分系统使用的全程区进行起始，并按起始表格文件（$homw/ini/mssini.ini）的指定，在全程区生成所有表格，同时本程序还要起始作为信息交换的工作区（即各子分区）。

在本分系统中，大部分进程需要使用全程区进行控制信息（排队）及数据信息交换。为了方便全程区的使用，在每个使用全程区的程序中需要生成一个程序头，存放全程区各个表格的指针。对于该表格的生成，本分系统提供一个函数xmapse.c。xmapse.c的输入参数为全程区的名字，结果是将程序头进行起始，而该程序头的指针是pgl。

4.5 监控导航

依据航空气象用户尤其是设备保障用户的需求，提高监控维护的直观性和高效性，需要将运行状态、维护维修界面图形化，以监控部分导航条项为例，它提供监控功能的总导航，包括进程状态、线路状态、缓冲区及文件系统状态、排队状态、MQ队列及通道状态，操作系统状态。加载并显示相关界面，并将通过通信链路接收到的后台程序定时发送的监视信息显示在相关界面上。

5 结束语

通信分系统软件是航空气象数据库系统工程中的一个重要系统，在设计开发过程中，从用户的功能需求、非功能需求和系统的外部接口关系为设计依据，遵循工程的总体概念、体系结构和总体布局，完成了通信分统软件进行功能分解和部件级（CSC）模块等设计。

通过对通信分系统的解读思路，更可以完成对整个航空气象数据库系统的分析，通过深入解读分析系统的办法，提高了系统安全，因为这是深入做该系统安全保障的重要手段。

参考文献：

篇5：气象数据分析系统

随着信息网络的`快速发展,自动气象站已经普及、自动化观测也已经成为气象观测的必然趋势.但网络传输虽方便快捷,但也存在着不稳定性.如正点未采集生成数据文件或传输数据时网络中断而不能及时传送数据文件,不仅影响自动站的传输质量,且加大观测员的工作量.开发制作“自动气象站数据采集、传输报警系统”以缓解以上问题.

作 者：金丽娜 贾毅萍 JIN Li-na JIA Yi-ping 作者单位：金丽娜,JIN Li-na(临潼区气象局,陕西临潼,710600)

贾毅萍,JIA Yi-ping(西安市气象局,西安,710016)

篇6：气象信息系统网络路由设计

1主路由协议选择

对于省级气象广域网络系统来说，网络设备一般在两百到三百台以上，在这种情况下，全网使用静态路由协议显然是不现实的。要保证网络路由的同步性和稳定性，必须在网络系统内部启用动态路由协议。目前在动态路由协议方面有两种：IGP(内部网关协议)，用于在自治系统内部交换路由信息，包括RIP、IGRP、EIGRP、OSPF等路由协议；EGP(外部网关协议)，用于在不同自治系统之间交换路由信息，其代表就是BGP(边界网关协议)。根据省级气象信息广域网的规模，所有网络设备可划分在一个自治系统内，使用内部网关协议，应用RIP、IGRP、EIGRP、OSPF等动态路由协议。在网络协议及路由规划上不仅考虑路由协议的开放性、网络的拓扑结构、网络节点数量、管理和安全上的要求。而且还要考虑路由是否按需选径，路由算法是否具有鲁棒性、快速收敛性、灵活性、路由信息安全因素和对路由交换的限制策略管理等。要满足这些需求，就目前行业内的应用效果来看，省级气象信息广域网系统内的动态路由协议选择OSPF比较适合，0SPF协议承载宽带网路由器内部路由，能确保网络的可达性和稳定性。2辅助路由协议的应用

对于一个业务量较大的信息网络系统，必要的辅助路由协议是必不可少的。对于系统外行业用户单位，需要访问气象信息资源，但是又不可能完全地把他们的网络接入气象信息广域网络内部，这时就需要应用静态路由，指定特定资源的访问路径。静态路由还有一个最大的作用就是指定默认路由，对于信息网络系统内动态路由协议生成的路由表及辅助静态路由表没有明确描述的路由，全部根据默认路由进行转发，通常应用在访问互联网资源上。

3路由的引入