ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

气象日值数据集V3.0处理软件与全国站点矢量数据应用指南

气象日值数据集V3.0处理软件与全国站点矢量数据应用指南 简介面向中国地面气候资料日值数据集(V3.0)的处理工具与配套全国气象站点矢量数据适用于需要批量计算气温、降水月/年均值或总量的科研与工程项目可显著简化原始站点数据的格式转换与统计汇总流程帮助用户高效获取可直接用于分析的气象指标。软件基于C#编写需在VS2019环境中运行当前版本支持气温和降水两类要素输出结果可在月/年平均与总量之间选择代码以完整源代码形式提供便于用户自行扩展至其他气象要素或调整统计逻辑。压缩包共41个文件体积约239KB以cs源文件、exe可执行程序及docx使用说明书为核心同时收录shp、shx、prj等全国气象站点矢量数据文件核心文件与说明文档一应俱全。整体结构清晰易查已有1055人浏览学习适合具有一定编程基础的气象数据处理人员。用户可获得完整的VS2019项目源码、已编译程序、操作说明及站点矢量数据大幅减少前期环境配置和站点匹配工作量直接聚焦数据提取与结果分析也可参照源码实现自定义处理工具。1. 气象日值数据集的最后一公里这套V3.0处理软件到底解决什么问题中国地面气候资料日值数据集V3.0几乎是国内做气候变化、水文模拟、农业气象研究绕不开的基础数据但真正下载过的人都知道从中国气象数据网拿到原始文件之后才是痛苦的开始。站点下的日值文件是固定列宽文本不是CSV用Excel打开直接串列字段对不齐、缺失值标识看不懂、负气温被截断折腾一晚上也得不到一张干净的数据表。这套资源把V3.0配套处理软件和全国气象站点矢量数据打包在一起解决的就是从原始文本到可用结构化数据的最后一公里问题。处理软件负责解析固定列宽、按要素抽取、质量控制标记识别矢量数据则解决站点坐标匹配和成果上图。适合被原始数据折磨过的气象专业研究生、做水文模型和农业气象分析的工程师以及任何需要快速把日值数据清洗成面板数据的人。2. 摸清V3.0的文件底细目录结构、列宽设计与编码方案决定处理思路2.1 文件名里藏着全部元信息站点、年份、要素与数据格式在动手跑软件之前先把V3.0的文件形态看清楚。中国地面气候资料日值数据集V3.0按站点组织每个站点的数据文件以固定命名规则存放典型形式是SURF_CLI_CHN_MUL_DAY_XXX_YYYY.txt之类的结构其中XXX是区站号YYYY是年份。文件内部是固定列宽记录不是逗号或制表符分隔每个字段的起始列和结束列在数据说明文档里有严格定义。常见字段依次是区站号、经纬度、观测海拔、年月日然后接平均气温、最高气温、最低气温、降水量、平均相对湿度、平均风速、日照时数等要素列。固定列宽带来的第一坑是直接用read_csv或Excel打开必然错位。比如气温字段如果定义为第30到36列其中第34列是小数点那么低于-10度的值会占用更多字符位这时候如果按逗号分割整行数据全部错位。V3.0对缺测值的标识也有讲究一般用特定数字如32744、32766表示缺测或可疑不同要素的缺测标识还不一样需要对照数据说明逐个确认。处理软件存在的意义就是把这些固定列宽的解析规则、缺测值翻译和单位换算一次性封装好。我一般会建议在跑处理软件之前先用文本编辑器打开一个原始文件确认三件事文件是GBK还是ASCII编码、每行末尾是\r\n还是只有\n、日期字段是连续占位还是带分隔符。这三项直接决定后续解析模板怎么写也是排错时最先要检查的地方。2.2 处理软件的四步链路读取、索引、质量控制标记与输出这套处理软件的完整工作链路可以拆成四步理解了每一步输出的中间产物才知道参数怎么调。第一步是按站点读取原始日值文本把固定列宽解析成内部数据结构。这一步最容易出的问题是列宽映射表与数据说明不一致比如气压字段说明是五位数带一位小数但实际文件里高海拔站点会写成六位。常见做法是软件提供“解析映射配置文件”运行前先检查配置里的列宽定义是否和手头数据版本一致。第二步是建立站点索引。把区站号、经纬度、海拔提取出来和全国气象站点矢量数据做关联的准备工作在这一步完成。V3.0里站点编号是五位数但注意有些站在编号前有字母前缀比如用于区分基准站和一般站处理时要把前缀剥离或者统一映射否则后面和shp做空间连接时对不上。第三步是质量控制标记识别。V3.0数据里每个要素除了数值本身还可能伴随质量控制码标识该观测值是否正常、可疑还是错误。处理软件会把质量控制码翻译成人可读的状态列而不是直接删除可疑值——这个设计很关键保留标记比删除数据更稳妥研究者可以自己决定是否剔除可疑记录。第四步是格式输出。软件支持输出纯文本表格、CSV或直接生成带站点元数据的合并表。输出参数里有几个值得关注的选项日期格式是YYYY-MM-DD还是YYYYMMDD气温单位是0.1摄氏度还是摄氏度降水量是否保留四位有效位数输出编码是GBK还是UTF-8。这些选项在第一次运行时就要定下来中途切换会导致下游脚本全部重跑。3. 在VS2019里把这套软件跑起来环境搭建与编译细节3.1 为什么要求VS2019工具集版本、MFC依赖与字符集是硬门槛这套处理软件对Visual Studio 2019有明确要求不满足版本条件编译阶段就会卡住。原因有三个层面。第一是C运行时库版本软件源码基于较新的C17标准编写VS2015的编译器对部分语法支持不完整而VS2022虽然也能编译但工程文件的平台工具集默认指向v143和源码依赖的v142库存在二进制兼容问题常见表现是链接时疯狂的LNK2038或LNK1104错误。第二是界面层用了MFCVS2019安装时默认不装MFC组件需要额外勾选否则打开工程会直接提示找不到afxwin.h。第三是字符集设置源码里大量使用TCHAR宏和宽字符API工程属性里必须把字符集设为“使用Unicode字符集”改成多字节字符集后部分中文字符串会乱码。这三个问题叠加导致VS2015、VS2017、VS2022打开这个工程都会遇到程度不同的报错。最省事的路径是安装Visual Studio 2019 Community安装时通过Visual Studio Installer勾选“使用C的桌面开发”工作负载然后在右侧摘要里确认包含“MSVC v142 - VS 2019 C x64/x86生成工具”和“Windows 10 SDK”如果要用界面功能还必须在“单个组件”标签里搜MFC并勾选最新版。3.2 从.sln到首次跑通编译步骤与命令行参数说明拿到源码包后按下面步骤操作。假设源码目录解压到D:\climate_v3_tool里面应该包含一个.sln解决方案文件、src源码目录和config配置目录。cd D:\climate_v3_tool # 先检查目录结构确认sln文件名 dir *.sln确认解决方案文件名后用VS2019打开。首次打开如果弹出“需要重定向项目”的提示选择“确定”让VS自动把平台工具集从旧版本映射到v142。这里要注意自动重定向通常只改工具集不保证所有依赖项都正确最好手动确认一遍。# 在VS菜单里操作项目 - 属性 - 配置属性 - 常规 # 平台工具集选择Visual Studio 2019 (v142) # 字符集选择使用 Unicode 字符集 # 配置选择Release平台选择x64配置完成后生成解决方案。如果编译过程中报错MSB8036: 找不到 Windows SDK 版本说明本机没有安装VS2019对应的SDK回到Visual Studio Installer里勾选“Windows 10 SDK (最新版本)”组件补装即可。编译成功后命令行运行方式如下。这个软件支持无界面批处理模式参数依次是指定配置文件、原始数据路径、输出路径。D:\climate_v3_tool\bin\Release\ClimateV3Tool.exe ^ --config D:\climate_v3_tool\config\station_map.ini ^ --input D:\climate_v3_data\SURF_CLI_CHN_MUL_DAY_54511_2020.txt ^ --output D:\climate_v3_processed\54511_2020_daily.csv ^ --format csv --encoding utf-8参数说明如下。--config指向站点映射配置里面定义了站点编号和经纬度的对应关系--input是原始日值文件路径一次处理一个站点--output指定输出CSV文件的完整路径--format支持csv和fixed两种输出格式csv适合后续用Python或R读取--encoding可选utf-8或gbk建议优先utf-8但要注意Excel直接打开UTF-8的CSV会乱码需要导入而不是双击打开。4. 处理参数的核心配置站点映射、要素编码与批量输出设置4.1 站点映射配置经纬度、海拔与站号的匹配规则处理软件能正常工作关键在配置文件写得对不对。站点映射配置通常是一个文本文件每行一个站点包含五要素站号、站名、经度、纬度、观测场海拔。V3.0原始数据里的经纬度是度分秒格式还是十进制度格式直接影响后期与全国站点矢量数据的空间连接建议在映射文件里统一转成十进制度。下面是站点映射配置的一个典型片段# 站点映射示例站号 站名 经度(度) 纬度(度) 海拔(米) 54511 北京 116.4667 39.8000 31.5 58362 上海 121.4333 31.1667 4.5 59287 广州 113.3333 23.1667 41.0这里有个容易踩的坑原始V3.0文件里的站号是字符串类型有的站点编号带字母前缀如用于标识区域站的A、B前缀但站点映射文件里通常只有数字编号。处理软件内部会做一次类型转换如果原始文件的区站号是54511映射文件也是54511能正常匹配如果原始文件出现A5451这种变体映射就对不上最终结果是输出文件里站点名为空。我一般的做法是拿到原始数据后先做一个站号唯一性检查把所有文件的第一个字段去重后看有没有非纯数字的站号。如果有在映射文件里增加别名规则或者在处理前批量替换原始文件头。4.2 要素编码与输出模板你要哪个要素就配哪一列V3.0日值文件的要素是按固定位置排列的处理软件通过要素编码表告诉解析器每一列对应什么物理量。一套典型的要素编码如下字段位置要素编码物理量单位缺测标识5TEM_AVG平均气温0.1℃327446TEM_MAX最高气温0.1℃327447TEM_MIN最低气温0.1℃327448PRE降水量0.1mm327009RHU_AVG平均相对湿度1%3276610WIN_AVG平均风速0.1m/s32766配置方法是在处理软件的配置文件里指定需要输出的要素列表。举例如果只要平均气温和降水量配置如下[output] variable_list TEM_AVG, PRE missing_value_policy keep_flag date_format YYYY-MM-DDmissing_value_policy这个参数在首次运行时容易忽略。keep_flag表示缺测值保留原始标识码同时在输出文件里额外加一列质量控制状态drop表示直接删除缺测记录。做气候平均统计时建议选drop做极端值分析时必须选keep_flag否则无法区分真实低温和缺测导致的数值异常。4.3 批量处理一整年数据命令行循环与结果合并处理软件一次只处理一个文件如果要把全国800多个站点的一年数据全部清洗完手工跑不现实。常见做法是写一个批处理脚本循环调用我习惯用Python的subprocess模块比批处理文件更好做日志记录和断点续跑。import subprocess from pathlib import Path tool_path Path(rD:\climate_v3_tool\bin\Release\ClimateV3Tool.exe) config_path Path(rD:\climate_v3_tool\config\station_map.ini) input_dir Path(rD:\climate_v3_data) output_dir Path(rD:\climate_v3_processed) output_dir.mkdir(exist_okTrue) for raw_file in input_dir.glob(SURF_CLI_CHN_MUL_DAY_*.txt): output_csv output_dir / f{raw_file.stem.replace(SURF_CLI_CHN_MUL_DAY_, )}.csv cmd [ str(tool_path), --config, str(config_path), --input, str(raw_file), --output, str(output_csv), --format, csv, --encoding, utf-8 ] result subprocess.run(cmd, capture_outputTrue, textTrue, encodinggbk) if result.returncode ! 0: print(fFAILED: {raw_file.name} - {result.stderr}) else: print(fOK: {raw_file.name} - {output_csv.name})这段代码的核心逻辑是遍历原始数据目录下所有匹配SURF_CLI_CHN_MUL_DAY_*.txt的文件逐条调用处理软件。注意encodinggbk是必要的因为处理软件在Windows下输出日志走的是GBK编码用UTF-8解码会导致报错信息乱码影响排错。跑完后检查输出目录里的CSV文件数量和原始文件数量是否一致不一致就逐个看报错日志。批处理跑完后还需要把所有站点C SV合并成一张大表方便后续分析和空间连接。这一步在Python里用pandas就能解决。5. 避坑手册V3.0处理软件运行中的常见问题与排查记录5.1 输出CSV用Excel打开全是乱码现象处理软件正常跑完生成的CSV文件用记事本打开是正常的但用Excel双击打开中文站名和列名全部变成锟斤拷。原因软件设置的是UTF-8编码输出而Excel默认以ANSIGBK解码CSV文件编码不匹配导致乱码。解决两种方案任选。输出时指定--encoding gbk直接生成Excel友好的编码或者保留UTF-8输出在Excel里通过“数据→自文本”导入编码选“65001: Unicode (UTF-8)”。从那以后我默认输出UTF-8导入时走文本导入向导这个习惯能少踩很多次乱码的雷。5.2 处理到某个站点时程序崩溃提示“内存不足”现象批量运行时前面几十个站点正常跑到某个大站时程序直接退出任务管理器看到内存占用飙升到接近上限。原因处理软件默认把整个日值文件一次性读入内存。某些高原站点的文件里包含大量缺测标记和异常值记录内部存储结构膨胀占用内存超过默认上限。解决在配置文件里增加分段读取参数把按年读取改成按月读取。一般配置read_chunk_month True就能解决。如果软件版本不支持分块就把原始文件按上半年和下半年拆成两个文件分别处理再用脚本拼接结果。5.3 编译时提示LNK2038: mismatch detected for RuntimeLibrary现象用VS2019打开解决方案编译Release x64模式下报LNK2038运行时库不匹配链接失败。原因工程里部分源文件引用了外部静态库如libcurl、zlib这些静态库是用MDd多线程调试DLL编译的而主工程设置的是MD多线程DLL。调试版和发行版的运行时库拼在了一起属于典型的配置不一致问题。解决检查项目属性“C/C → 代码生成 → 运行时库”统一改成/MDRelease或/MDdDebug。特别注意vendor或third_party目录下如果有预编译的.lib文件需要确认它们对应的运行时库模式和当前工程一致。这个报错我遇到不下五次每次都是先从运行时库找原因基本一击即中。5.4 站点经纬度全部对不上矢量数据的坐标系差异现象处理软件输出的站点经纬度和全国气象站点矢量数据在GIS软件里叠加后点位全部偏移几公里到几十公里。原因V3.0文本数据里的经纬度是度分秒记录的处理软件输出时转成了十进制度但转换用的公式是简单的度 分/60 秒/3600没有做四舍五入处理而矢量数据里的站点坐标是经过投影转换的平面坐标或者高精度十进制度两者存在舍入误差。更大的可能是矢量shp文件本身是GCS_WGS_1984坐标系而文本数据的基准面是CGCS2000两者在部分区域偏差可达几十米。解决先确认矢量数据的坐标系。在QGIS或ArcGIS里查看shp文件属性如果坐标系是GCS_WGS_1984把处理软件输出的经纬度转成WGS84如果shp是CGCS2000_GK_Zone_*这种投影坐标不能直接和经纬度叠图要先对shp做Define Projection和Reproject统一到GCS_WGS_1984后再做空间连接。5.5 负气温变成短横线或解析成空值现象输出文件里1月的最低气温字段大量显示-或者空白和原始文件对比发现负值全没了。原因固定列宽解析时负号被当成了字段分隔符或无效字符。原始数据里气温列如果定义的是第30到36列-15.2摄氏度实际占6个字符但解析器按正数的宽度去切分负号就被截断丢弃了。解决检查解析映射配置里气温字段的列宽定义把字段宽度加1位预留负号位置。或者查看处理软件有没有“允许负号”的开关选项一般在字段定义里加一个allow_negative true即可。这个坑在第一次处理北方站点数据时最容易暴露南方站点全年最低气温很少低于零下问题被掩盖直到混入北方数据才爆发。6. 把站点矢量数据用起来日值结果与全国气象站点shp的空间连接与校验处理完日值数据后最后一步是把站点信息落到空间上。全国气象站点矢量数据通常是shp格式包含Province、StationID、Latitude、Longitude、Elevation这些属性字段。做空间连接的核心是让CSV里的站点编号和shp里的StationID对上然后才能进行后续的空间插值、站点密度分析。第一步是检查两边站点编号的数据类型。CSV里是字符串shp里可能是字符串也可能是整数如果不一致整张表关联后全是空值。第二步是做坐标范围校验中国区域经度范围在73到135之间纬度范围在18到54之间如果合并后的表里有超出这个范围的记录说明原始坐标或矢量数据有脏数据。下面是一段标准的校验代码import geopandas as gpd import pandas as pd # 读取处理好的日值汇总表和站点矢量数据 daily pd.read_csv(rD:\climate_v3_processed\all_stations_daily.csv) stations_gdf gpd.read_file(rD:\station_shp\china_weather_stations.shp) # 统一站号字段为字符串 stations_gdf[StationID] stations_gdf[StationID].astype(str).str.strip() daily[station_id] daily[station_id].astype(str).str.strip() # 空间连接按站号匹配 merged daily.merge(stations_gdf, left_onstation_id, right_onStationID, howinner) # 坐标范围校验剔除异常点 invalid merged[ (merged[Latitude] 18) | (merged[Latitude] 54) | (merged[Longitude] 73) | (merged[Longitude] 135) ] if not invalid.empty: print(f发现 {len(invalid)} 条坐标异常记录请检查源数据)这段代码里有几个容易被忽略的细节。astype(str)是必须的直接用整型匹配会遇到前导零丢失问题——站号04511在整数类型里会变成4511字符串匹配就会失败。strip()用于处理文件里可能存在的空格和换行符。howinner会把没有矢量点匹配的站排除掉如果想保留未匹配站用于排查换成howleft。空间连接完成后用print(stations_gdf.geometry.total_bounds)看一眼整体范围是否符合预期。如果最小经度小于73或最大纬度大于54多半是矢量数据里混入了周边国家的站点。处理完就能得到一份带经纬度、海拔、日值数据全齐的表直接用于geopandas插值或者导出给GIS软件做进一步分析。从那以后我每次拿到新站点数据都先强制跑一遍站号唯一性检查坐标范围校验shp点数量对账这三步再进处理流程这套校验逻辑帮我挡掉了至少五版脏数据。希望帮到你。本文还有配套的精品资源点击获取
返回列表