气候志分析统计的设计与实现

舒秦

摘要：按照《民用航空气象资料管理办法》，具有五年或者五年以上24小时或者13小时气象观测资料的机场气象台或者机场气象站应当编写《民用机场航空气候志》，并应逐年更新机场气候表，每五年续编一次。该文系统采用B/S架构，根据观测报表系统收集的存储观测数据，生成规定格式的气候志统计结果，用于气候志的分析与编写。

关键词：气象报表；观测数据；B/S架构；气候志

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）03-0010-03

The Design and Implement of Aeronautical Climatic Annals

SHU Qin

（Meteorological Databse of Meteorological Center of Southwest Air Traffic Management Bureau， Chengdu 610202， China）

Abstract：According to the relevant instruments for meteorology information management of CAAC， the meteorological stations， which have at least five years records of meteorological observational data for twenty-four hours or thirteen hours， should make the aeronautical climatic annals of the related civil airport. The meteorological stations should update climatic annals every years， and recognize it every five years. In this paper， a software system based on B/S systematic structure which present by compile meteorological data from meteorological report system， will be used for make and analyze the aeronautical climatic annals.

Key words：meteorological reports； observational data； B/S systematic structure； climatic annals

1 概述

按照《民用航空气象资料管理办法》，具有五年或者五年以上24小时或者13小时气象观测资料的机场气象台或者机场气象站应当编写《民用机场航空气候志》，并应逐年更新机场气候表，每五年续编一次。编写过程中设计大量数据统计与分析，使用人工方式不仅极大增加编写人员的劳动强度和负担，而且存在不同人数据处理方式不一致等风险。本系统按照《中华人民共和国民用航空行业标准，民用航空气象第7部分：气候资料整编与分析》，利用观测报表系统收集的观测资料，生成规定格式的气候志统计结果，用于气候志的分析与编写。大大减轻了气候志编写的劳动强度。在数据更新后，或是需要续编气候志时，根据收集的数据，重新运行计算即可，避免了数年之后统计方式上的差异，保持计算的一致性。系统同时以文件系统格式保存和维护已生成的气候志统计结果，只要能连上服务器，即可下载浏览，方便使用。统计结果以word格式的气候志附表形式保存，气候志编写人员可下载即使用，不需在进行格式的转换。同时，由于客户端为浏览器，在维护和管理上也很方便。

2开发环境

软件架构在已有的观测报表系统之上，使用观测报表系统收集整理的气象观测资料，但由于气候志分析统计比观测报表要求更高更细致，在原有报表系统数据库结构上进行了扩展，以满足新的统计需求。

本系统由vs2008.net开发，数据库使用oracle10g，采用B/S模式，具有易于维护升级，方便管理的优点。网站服务器部署在气象中心数据库室机房，网站数据库建立在气象中心数据库室现有oracle服务器上，气候志统计在服务器端统一生成，同时，生成的气候志附表提供全表word格式、分表Word和分表数据txt格式压缩包、分表数据txt格式压缩包三种方式下载。由于生成的附表总计有100多张，网页预览速度较慢，省去了网页预览的方式。当结果有疑问需要修改时，用户可对下载的文件进行修改。

3系统设计

整个系统采用标准的B/S架构，如图1所示。

图1 气候志分析系统整体架构图

系统以气象观测报表系统数据库为基础，在不改变已有结构的前提下，进行扩展。数据集中存放于服务器端的Oracle数据库中，客户端不保存任何业务数据和数据库连接信息，安全性较高。同时由于数据是集中存放的，不存在数据一致性问题。日常维护通常只需维护WEB服务器即可，所有客户端只是浏览器，升级应用软件时一般无需对客户端做任何修改，因此其维护和升级也比较方便，基本上不影响用户使用。

3.1 数据库扩展

由于气候志数据统计比年月报表更为细致，同时也数据统计范围也更广，原有的支持年月报表统计的数据分解表不能很好地满足气候志统计的需求。如能见度低于某一范围的最长持续时间，雷暴的最长持续时间等。因此，需要对数据库在原有基础上进一步扩展。

细化后增加的数据表包含：cloudDetailtable（云况细节表）、cloudlist（云状定义表）、weathersign（天气现象定义表）。

[字段名＼&存储内容＼&NAME＼&中文天气现象集合名＼&NAME_PINYIN＼&中文天气现象集合名的拼音＼&CODE＼&天气现象列表，以”|“隔开＼&]

云状定义表包含了《民用航空气象地面观测规范》附录七中所定义的云状。只有在该表中出现的天气现象记录中的代码视为云状，其他为天气现象。后两张为系统参数配置，用于调整统计对象。后文会进一步说明。

改动的数据表包含：nengjianduyanbian（能见度演变表）、leibaoyanbian（雷暴演变表）、weatheryabian（天气现象演变表）。在各表中增加了转换为北京时的时次段。由于原记录时次为世界时，而分段时次为北京时，因此，需要对时次进行转换，以简化统计。转换时，需要注意对日界的处理，当1600处于开始时次时，转换后应为0000，否则视为2400。

3.2 统计结果

统计结果以word和文本两种格式输出。其中标准统计以word和txt两种格式输出，word格式的输出可直接附在气候志正文后，以附表形式直接使用。具体内容可查看先关规范。。。。。扩展统计仅以txt输出，用于辅助进行气候分析，包括逐年降水量、逐年各风向段（30°内）出现频率、累年平均逐时段能见度低于规定值的频率、能见度在800以内，且持续时间超过12小时的起止时间、持续时间超过6小时的雷暴等，主要是针对附表中已有统计数据在统计时间范围上的扩展。

3.3 根据需求设计类结构

因为txt仅作为word输出的扩展，依附于word格式的输出。因此，在系统设计上，以word为主要对象，后续进行扩展到txt。

分析word格式输出要求可得，最终结果由26类数据表构成，每类数据表可能包含1-12个数据表。采用简化的工厂模式，设计数据表的类。加上其他用于统计分析、用户交互、结果输出等类，最终主要类结构如图2所示。

图2 主要类结构图

BiaoA1到BiaoA26对应气候志附表要求的26类表，都实现了抽象类SingleTable的getData（）方法。各表数据输出方法基本上一致，output（）方法的实现放在SingleTable类中。制作气候志附表时，只需根据需要生成相应表的实例，调用getData（）方法生成数据，然后调用output（）方法输出数据，如图3所示。

图3 气候志附表的生成

COMMFUN和StaticParas为静态类，前者包含各种时间制式的转换、数据文本格式输出、月份天数计算等功能，后者主要包含数据格式、Word模板位置、生成结果位置、能见度标准等参数及数值。DBOper封装了所有对数据库的操作，如建立连接、事务管理、数据查询更改等。WDA_SingleDay用于对当日天气现象的处理。QueryStrCreator提供了气候志所有统计的sql语句，是数据分析和提取的核心类，当某类统计方法发生变更时，修改该类中相应方法即可。

3.4 系统参数配置设置

分析气候志附表要求可知，统计需要定义中文天气现象的简字集合，如图4所示。故需要建立表weathersign。

图4 气候志附表表1局部

云的演变也以类似天气现象的格式记录在天气现象演变中，在信息提取时需要与天气现象区分开来。云状数量较少，且规则单一无变化，因此增加cloudlist表，存储所有云状，不在该表中天气现象演变记录代码均视为天气现象。图5为系统提供的修改云状信息的用户界面，图6为修改中文定义天气现象与天气现象简字的对应表，每一种天气现象简字以“|”分开。

图5 云状修改页面

图6 天气现象修改页面（局部）

拥有气候志附表管理员权限的角色，可以在该界面中直接进行编辑，而不需要修改程序。普通用户和站点气候志制作用户只能进行浏览，即气候志附表的制作方式统一由附表管理员制定，保证附表制作方式上不同站点的一致性。

3.5 额外统计

额外统计包括累年能见度分段频率、持续时间大于6小时的雷暴信息、各段能见度出现频率等。该类统计由于行业标准并未要求在气候志附表中列出，因此只以txt的形式提供给气候志编写人员分析。

3.6 持续时间的统计

需要注意的是对天气现象演变信息的分析统计。能见度的变化记录，依附于天气现象的记录，天气现象演变的记录格式为每类天气现象一行，分开记录。

以能见度为例，要注意的是由于天气现象演变的记录方式，不同类天气现象可能同时或交替地出现，在持续时间上存在叠加部分。能见度的改变可能由于一类天气现象的终止而暂停记录，但在另一类天气现象中又得以延续，且在不同天气现象的记录中，起止点也常常落在另一天气现象之间而非起止时间上。即能见度的变化段存在相互叠加的情况。因此，在连续性的统计上，必须注意起止时间是一个区间而非一个点，即不能以该段的结束时间作为下一段的开始时间。图7中显示了雷暴出现时间段互相叠加的情况。

以统计能见度小于800m的持续时间段为例，统计流程如图8所示。条件一的判断将会用到当前记录的前一条记录，即如果当前记录的起始时间，晚于前一条记录的结束时间，则当前记录视为新持续段的起始时间。否则，根据处理顺利可知，该段已被统计到上一持续段之中。条件二的判断将会用到当前记录的后一条记录，即如果当前记录的结束时间晚于下一条记录的起始时间，则以两条记录中较晚的结束时间作为新的结束时间，继续判断。

图7 雷暴演变节选

图8 能见度持续时间统计

3.7 用户管理

由于多个站点可共用该系统进行气候志相关资料的分析统计，本系统在用户管理上分为三个用户组：系统用户、高级用户和普通用户。

系统用户拥有对生成的气候志附表参数进行调整的权利，但不能制作气候志附表。高级用户必然属于某一个气象站点，仅可制作该站点的气候志附表，并拥有普通用户的权限，但不能对相关参数进行调整。普通用户是权限最低的用户，仅可浏览下载其所属站点的气候志附表，查看相关参数定义等，不能对系统作任何的修改。

图9 高级用户和普通用户菜单

图10 系统用户菜单

同时，系统用户和高级用户只能单点登录，普通用户由于不存在对系统的修改，不做此限制。

4 结束语

气候志的制作，是一个比较复杂的过程，数据信息的有效提取，是气候分析的必不可少的前提。本文所实现的系统，能够满足气候志所需数据信息的提取，可供多个气象站点使用，且以气候志附表的格式直接输出结果，使用简便。系统架构的设计，也便于后续的算法变更和扩展。

参考文献：

[1] 民航局空管办.民用航空气象地面观测规范[M].北京：中国民用航空局空管行业管理办公室，2012：3，5-6，9-12，24-28，32-39，45-63，91-93，99-103，107，110-140.

[2] 中国民用航空总局.中华人民共和国民用航空行业标准[S].民用航空气象.2008.

[3] [美]Jason Price.Oracle Database 11g SQL开发指南[M]. 史新元，北英.译.北京：清华大学出版社，2008：25-58，83-118，115-191，237-258.

[4] John Sharp. Mmicrosoft Visual C# 2010 Step by Step[M]. America：Microsoft Press，2010：535-564，566-583.

[5] 明日科技.C#开发经验技巧宝典[M].北京：人民邮电出版社，2007：119-128，221-244，293-310，389-404，405-444，501-548，549-579.

[6] 马军.精通ASP.NET2.0网络应用系统开发[M].北京：人民邮电出版社，2006.

[7] 李海翔.数据库查询优化器的艺术：原理解析与SQL性能优化[M].北京：机械工业出版社，2014.