气象日值数据集V3.0处理与站点矢量数据关联实战指南

简介由处理软件与全国气象站点矢量数据共同组成的下载包面向使用中国地面气候资料日值数据集(V3.0)开展科研或应用开发的人员。处理软件基于C#编写需在Visual Studio 2019环境中编译运行当前支持气温和降水日值数据到月/年均值或总量的批量转换且提供源代码便于研究者根据实际需求自行调整算法。全国气象站点矢量数据则对应数据集内的总站点位置可直接用于GIS制图或空间分析。整包共41个文件体积仅239KB主要包括C#源码文件.cs、可执行文件.exe、站点矢量数据.shp、.dbf、.shx等、使用说明文档.docx及项目配置文件.sln、.csproj。目前已有1055人学习下载适合需要快速处理V3.0日值数据、获取站点空间信息的气象数据分析者。1. 日值数据还在拿 Excel 手工拼接这套 V3.0 处理软件和站点矢量数据能救你做气象、环境、农业或者交通气候评估的人大概率都蹲过中国气象数据网的下载页。中国地面气候资料日值数据集(V3.0) 是目前最常用的逐日地面观测数据一个站一年 365 条记录全国两三千个站点你要是靠 Excel 打开、筛选、拼接一个区域做下来就得耗掉整个周末。更麻烦的是V3.0 的原始文件不是常见的 CSV而是定宽或空格分隔的 TXT要素还拆成多个文件配套的全国气象站点矢量数据则帮你把“站点数字”落回地图上但拿到的 SHP 属性表和日值文件怎么关联又是一道坎。这篇笔记就顺着“数据格式 → 处理软件编译 → 站点矢量数据用法 → 踩坑”这条线把完整流程讲清楚适合正在做数据清洗、GIS 制图或气候统计分析的人直接照着做。2. 认识 V3.0 数据集的真实格式先搞清楚“日值”到底长什么样2.1 文件命名规则与要素拆分V3.0 不再是一站一年一个文件很多老用户是从旧版数据集转过来了那时一个站一个文件按站号命名一站一整年。V3.0 最大的变化是“按要素、按月”组织文件文件名通常长这样SURF_CLI_CHN_MUL_DAY_TEM_YYYYMM.txt气温、SURF_CLI_CHN_MUL_DAY_PRE_YYYYMM.txt降水其中YYYYMM是年月。也就是说你下载一个省一年 12 个月的气温数据拿到的不是 12 个文件而是 12 个按要素拆分的月文件每个文件里包含该月全国所有站点的逐日记录。这个组织方式带来的直接后果是做多年多要素分析前你得先把同一要素的几十个文件甚至上百个合并成一张大表再做透视或分组统计。如果你下载时选了“站点”粒度而不是“区域”粒度文件数量还会翻倍。我一般建议下载时直接按整个数据集范围拉取不要按单站下载然后本地统一清洗这样反而比单站下载省事因为你最终要建的是“站点 × 时间”的面板数据。2.2 逐行逐列解析固定宽度还是空格分隔决定你的解析脚本怎么写打开一个月文件看头部几行你会发现它既不是逗号分隔也不是严格的制表符分隔常见是“定宽 空格填充”的混排。比如一行里站号占 5 列年、月、日各占 4 列气温占 7 列降水占 6 列列与列之间可能补若干空格。定宽格式的好处是肉眼看着整齐坏处是你用split( )直接切会切出一堆空字符串。处理这类文件我个人建议直接按列宽切片而不是按分隔符切。先拿第一行数据数清楚每个字段的起始和终止位置然后固定line[start:end]去取再strip()去掉空格。别嫌这个方法土它是我做过几十个气象数据集中最稳的。用 Python 举例# -*- coding: utf-8 -*- # 解析 SURF_CLI_CHN_MUL_DAY_TEM_YYYYMM.txt 的定宽行 # 以某版本为例字段大致为站号(5) 年(4) 月(4) 日(4) 平均气温(7) ... # 注意列宽以你实际下载文件的 README 为准别照抄下面数值 with open(SURF_CLI_CHN_MUL_DAY_TEM_202401.txt, r, encodinggbk) as f: for line in f: line line.rstrip(\n) if not line.strip(): continue # 切片解析start:end 均按 README 里给的位置 station line[0:5].strip() year line[5:9].strip() month line[9:13].strip() day line[13:17].strip() temp line[17:24].strip() print(station, year, month, day, temp)这段代码的逻辑很直白按字符位置切成小块再各自去掉首尾空格。参数说明里最容易错的是列起点终点写错所以下载数据时一定要把同目录附带的A_SURF_CLI_CHN_MUL_DAY_XXX_YYYYMM.txt说明文件打开里面有一个字段说明表标明每个列的起始位置和长度。你宁可先花十分钟把列宽在草稿纸上标一遍也别直接猜否则一个字节的偏移就能让整年的温度序列全部错位。2.3 站点索引表的地位没有它V3.0 的降水记录只是一堆数字日值文件里只有站号没有站名、没有经纬度、没有海拔。你想知道54308是哪个站、在什么位置必须靠配套的“站点索引”或“台站信息”列表。这个表通常也是 TXT 或 Excel 格式包含站号、站名、省份、纬度、经度、海拔高度等字段。它就是你整个分析工作的主键表。处理流程中站点索引表有两个用途一是把站号转成可读的站名和地理坐标二是做质量检查——比如你统计出来的逐月累计降水如果某站的经纬度落在海面以外或者海拔为负就要怀疑是站号错位还是数据本身异常。站点索引表和日值数据的关系是一对多一个站对应多年多月的记录所以两表关联时一定要用站号做精确匹配不要用站名去关联因为站名存在重名和生僻字编码问题稍不注意就关联出脏数据。3. 在 VS2019 里把处理软件编译跑通环境配置与最小用法3.1 为什么是 VS2019老项目对 CRT 和新编译器的兼容性标题里明确写着“需要至少配备 VS2019”。这不是随便说的。这类处理软件大多是早年用 C/C 写的依赖的是旧版 C 运行时库比如msvcr120.dll、msvcp140.dll有些代码还用了strcpy、sprintf这类在 VS2019 下默认会报警告甚至报错的函数。如果你装的是 VS2022很多老工程文件.sln或.vcxproj能打开但编译时会遇到平台工具集不匹配、Windows SDK 版本过新导致头文件冲突等问题。VS2019 是兼容性最好的折中点它既保留了 VS2017 时代对老工程的兼容又支持 CMake 和较新的 C17 标准。如果你机器上只有 VS2022也不是完全没法用但要改两处平台工具集从v142改到v143Windows SDK 版本改成“10.0最新已安装版”。不过最省心的方案还是装 VS2019 Community 版社区版对个人和多数机构免费不用纠结产品密钥和许可问题直接官网下载安装即可。3.2 编译前必须改的三处配置字符集、_CRT_SECURE_NO_WARNINGS、平台工具集拿到处理软件源码包后别直接按 F5否则你会被铺天盖地的报错淹没。我一般先把三个配置改好再编译第一字符集。老代码里大量使用char*处理中文路径和中文字符串VS2019 默认的 Unicode 字符集会让你处处碰壁。在项目属性 → 配置属性 → 常规 → 字符集中改成“使用多字节字符集”。这一步不改后续所有中文字符串相关的函数全部得重写。第二预处理定义。在“C/C → 预处理器 → 预处理器定义”里加上_CRT_SECURE_NO_WARNINGS。VS2019 对strcpy、scanf这类函数默认当作错误抛出而这个宏能把这些“安全警告”屏蔽掉保住老代码的原样编译。这不是偷懒而是老项目做最小改动的常规手段。第三平台工具集。如果你是 VS2019工具集应该是v142如果你是 VS2022 打开的把工具集改成v143大概率能跑。改完之后先编译一次确认没有语法错误再做下一步。# 以命令行为例用 VS2019 开发者命令行编译 # 先打开 Developer PowerShell for VS 2019 或 x64 Native Tools Command Prompt # 然后执行 MSBuildRelease 和 Debug 二选一 msbuild WeatherDataProcessor.sln /p:ConfigurationRelease /p:Platformx64 /m这段命令的逻辑是调用 MSBuild 构建整个解决方案/p:ConfigurationRelease指定发布版/p:Platformx64指定 64 位目标/m启用多核并行编译以加快速度。参数说明如果你编译的是 32 位老程序把x64改成Win32如果编译报错提示 Windows SDK 版本问题在项目属性里把“Windows SDK 版本”改成“10.0最新已安装版”。编译成功的标志是输出窗口出现Build succeeded并在x64\Release目录下生成 exe 文件。3.3 跑通最小示例命令行传参启动批量转换编译成功后别急着拖一堆文件进去运行。处理软件通常是命令行工具你需要先看看它支持哪些参数。以常见的功能为例它至少支持输入目录、输出目录和要素类型这三个参数。最小用法如下# 把 2024 年 1 月到 12 月的气温日值文件全部处理并输出为 CSV WeatherDataProcessor.exe --input D:\climate\raw\TEM\2024 --output D:\climate\out\TEM_2024.csv --element TEM参数--input指向原始 TXT 所在目录--output指向输出 CSV 的完整路径--element指定要解析的要素代码TEM 代表气温PRE 代表降水RHU 代表相对湿度等。运行后观察控制台输出正常情况会显示每个文件的行数和成功写入的记录数。如果什么都不显示就退出了多半是路径或要素代码写错可以先在--input里只放一个月文件试试。跑通最小示例很重要因为你会立刻发现三个问题原始数据里有没有表头注释行、缺测值长什么样、年月日是不是按你预想的格式组织的。这些观察决定了后续清洗脚本怎么写千万别跳过这步直接上全量数据。4. 全国气象站点矢量数据的两种用法配图与空间提取4.1 SHP 里到底存了什么站号、站名、经纬度、海拔你拿到的全国气象站点矢量数据一般是一个 ESRI Shapefile核心文件至少包括.shp、.shx、.dbf三个.shx是索引.dbf存属性表。用 GIS 软件ArcGIS、QGIS打开后你会看到每个点要素代表一个气象站属性表里通常有站号、站名、省份、经纬度、海拔等字段。面状信息行政区不在这里你要做空间分布图时还需要额外准备省界或县界矢量。这份 SHP 的价值首先是制图。做“年均温空间分布”这类专题图时你先用日值数据算好每个站的年均值再通过站号关联到 SHP 属性表按“年均温”字段分级符号化就能出一张像样的分布图。其次是做空间查询——比如提取“海拔 1000 米以上站点”“穿过某条河流 5 公里范围内的站点”都可以直接基于点要素做缓冲区分析不用自己再排经纬度计算距离。4.2 用站点文件做数据 JOIN把日值 CSV 变成可分析表格拿到日值 CSV 和站点 SHP 后很多人卡在“怎么把两个表合在一起”。SHP 的属性表在 QGIS 或 ArcGIS 里可以直接打开但如果你想在 Python 里完成全部工作用 geopandas 读取 SHP、pandas 读取 CSV、再 on 站号进行 JOIN 是最顺滑的路径。下面这段代码是标准做法# -*- coding: utf-8 -*- # 将日值 CSV 与全国气象站点矢量数据按站号关联 import pandas as pd import geopandas as gpd # 1. 读取站点矢量数据 # encodinggbk 是因为属性表里的中文站名在多数流传版本里是 GBK 编码 stations gpd.read_file(全国气象站点.shp, encodinggbk) # 2. 读取处理软件输出的日值 CSV daily pd.read_csv(TEM_2024.csv, encodinggbk) # 3. 按站号做左连接保留日值全部记录 merged daily.merge(stations[[站号, 站名, 纬度, 经度, 海拔]], left_onstation_id, right_on站号, howleft) # 4. 检查关联失败记录 unmatched merged[merged[站名].isna()] print(f未匹配记录数: {len(unmatched)})这段代码的逻辑分四步先读 SHP 属性表再读 CSV然后以左连接方式把站点信息挂到日值数据上最后检查未匹配的记录。参数说明geopandas.read_file的encoding很关键流传较广的全国站点 SHP 多为 GBK 编码如果你用默认utf-8读站名会变成乱码merge里left_on写日值数据的站号列名right_on写 SHP 属性表的站号列名两列必须都是字符串类型否则类型不一致会造成关联失败。如果unmatched记录数超过预期先检查站号前导零有没有在 Excel 导入时被吞掉。4.3 借助矢量数据反查可疑记录站点缺失值的空间规律矢量数据还有一个容易被忽略的用途——做数据质控的“空间辅助判断”。日值数据里总有那么些站点在某段时间出现连续的高温或极端降水你会怀疑是数据错误。把异常站点在 GIS 里高亮显示再叠加地形和周边站点数据能快速判断是站点搬迁、传感器故障还是记录尺度问题。举个例子某年冬季某站连续 5 天气温在 35 度以上这在空间上完全不合理因为周边站点同期都是零下。这时候你可以在 SHP 里用地理坐标计算该站与周边站的距离再用插值工具验证。如果不做空间反查光看数字你根本看不出这是西南山区还是华北平原的站也就很难判断这个极端值是否可信。所以站点矢量数据不只是画图用的它本质上是你的质控参考层。5. 避坑记录编译、编码、坐标和缺测值五个坑依次说清5.1 VS2019 一运行就报“无法解析的外部符号 _strnicmp”现象编译时报错提示unresolved external symbol _strnicmp或类似 C 运行时函数找不到。原因老代码依赖的某些 CRT 函数在 VS2019 的默认链接配置里没有被正确引入常见于项目没有显式链接legacy_stdio_definitions.lib或ucrt.lib。解决在项目属性 → 链接器 → 输入 → 附加依赖项里加上legacy_stdio_definitions.lib重新编译。这个坑在从 VS2015 迁移到 VS2019 时格外常见属于环境兼容问题跟代码逻辑无关。5.2 输出 CSV 用 Excel 打开全乱码站名变成问号现象处理软件输出的 CSV 里中文站名全是???或者“锟斤拷”这类乱码。原因老代码写文件用的是系统 ANSI 编码中文环境下是 GBK而现代 Excel 默认按 UTF-8 猜或者你的代码里用了fprintf配合char*输出 UTF-8 字符串导致混乱。解决如果处理软件支持指定输出编码优先选 GBK如果只能在代码里改写文件时把编码显式设为 GBK 或 UTF-8 BOM。实际经验是给 Excel 用就输出 UTF-8 BOM给数据库用就输出 UTF-8 无 BOM。5.3 站点经纬度打在中国以外或点全部落在海面上现象在 GIS 里加载站点 SHP发现一部分点跑到邻国或海平面以下区域。原因最常见的是坐标字段顺序搞反——有的文件里先写纬度后写经度有的先写经度后写纬度还有一种是数据本身用了度分秒格式而你当成十进制度数加载了。解决先查 SHP 自带元数据或配套说明确认坐标系和字段顺序再在 GIS 里设置正确的投影。如果是一列数据写反了用矢量数据里的字段计算器把经纬度两列调换并转成十进制度数即可。这个坑最容易发生在你拿“全国站点图”去套别的项目时因为不同来源的站点文件坐标字段顺序并不一致。5.4 日值缺测不是 0是 32744、9999 这类哨兵值现象统计某站年降水量发现有的年份总和是天文数字或负数。原因V3.0 数据里缺测和微量降水是用哨兵值如 32744、9999、999990 等表示的不是 0。你直接求和哨兵值被当成真实数值参与计算结果自然错。解决写清洗逻辑时先把所有落在“缺测/无观测/微量”区间的值统一转成 NaN再做聚合。参数说明不同要素的哨兵值不同以你下载数据附带的 README 为准别拿气温的哨兵值套降水。这个坑我用“血泪经验”四个字来总结因为一旦算完才发现返工量几乎等于重做一遍。5.5 处理软件输入路径含中文直接闪退现象命令行运行时输入目录是D:\数据\气候\2024软件闪退或提示“找不到文件”。原因老 C 代码里用fopen这类函数处理路径ANSI 编码下中文路径在特定语言环境里会失效。解决第一优先是路径全用英文比如D:\climate\raw如果必须用中文目录试试在 VS2019 里把程序入口改成wmain并使用_wfopen或者将系统区域设置为“Beta使用 UTF-8 提供全球语言支持”。这个坑在 Windows 10/11 上最常见别跟它硬刚直接改英文路径最省事。6. 让处理软件真正好用批处理、要素合并与跨年“后悔药”6.1 批量循环把整个目录的月文件一键跑完处理软件一次只处理一个目录但实际工作中你可能要处理几十年的数据。我一般写一个简单的批处理脚本把每年 12 个月的目录逐个传给处理软件输出文件按年命名。用 Python 调子进程也行用for循环批处理也行关键是跑完后检查输出文件的行数——行数跟当年实际运行天数对不上就说明有问题。6.2 多要素合并与清洗从宽表到长表日值数据按要素拆开你最终做分析时往往要把降水、气温、湿度、风速合并到一张表里。常见做法是先让处理软件把每个要素单独输出 CSV再按“站号 年月日”做全连接最后把要素列折叠成“长表”站号、日期、要素名、数值。这里要注意降水缺测转 NaN 后某一行可能全部要素都缺失这样的记录建议直接删掉不然画时间序列会留下难看的断洞。6.3 验证输出的正确性抽一个站点、一年数据手工核对三五天这是我最想强调的习惯。处理软件跑完一批数据后别急着进入分析。我会随手抽一个站比如北京站54511把处理软件输出 CSV 的前 10 行跟原始 TXT 手工比对确认年月日、气温、降水都对得上。再跟中国气象数据网的“站点月值查询”或公开的月报交叉验证保证日值累加和月值一致。这个步骤看着笨但能避免你把一个系统性偏差引入后续所有分析。我早年吃过一次亏整批处理时把站点列偏移了一位导致所有温度序列整体错位一个站连出半年图才发现前期分析全部作废。从那以后无论多紧急我都保留这个“抽一年手工核对”的习惯。希望这套处理流程能帮你少熬夜、少返工把时间真正花在解读数据上。本文还有配套的精品资源点击获取