简介这是一份以森林火灾预测为主题的数据分析与机器学习实战压缩包适合具备一定编程基础、希望了解环境科学方向建模流程的数据科学初学者与爱好者。包内共15个文件包含火灾历史数据CSV、多个Python算法脚本、模型可视化PNG及数据来源说明整体约190KB数据、脚本与结果图片分层存放便于复现实验。脚本覆盖XGBoost、K近邻、AdaBoost、支持向量机、随机森林与轻量梯度提升机等主流算法并配有数据预处理与探索性分析代码可帮助读者从数据清洗、可视化探索到模型训练与评估走通完整链路。随附的结果截图能直观对比不同模型表现其中集成类模型的对比尤其有助于理解算法差异与调参思路。已有200人学习下载对想通过真实案例掌握多个机器学习模型应用、扩展特征工程与模型调优思路的读者而言是一份紧凑实用的参考资料。1. 森林火灾分析.rar从气象因子到火险等级的一次完整落地拿到这个名为《森林火灾分析.rar》的资源时我第一反应是“又一个把CSV塞一起的压缩包”但解压后翻完目录结构发现它比我预想的要完整——它不是某高校课程的期末作业而是一个能直接复现的森林火险分析项目。森林火灾分析这件事核心不在于“温度高了会起火”这种直觉而在于把气象因子、可燃物状态和火点记录串成一条可量化的链路。这个压缩包里应该有历史气象站点数据、火点记录以及一批分析脚本目标是从数据清洗一路做到火险等级输出。适合谁正在做森林防火相关课题的从业者、想拿真实数据练手的地理信息或数据分析方向的人以及那些被“数据有了但不知道怎么分析”卡住的开发者。这资源解决的是从原始气象CSV到火险指数图表的最后一公里。2. 气象数据与火点记录的预处理先把“脏数据”收拾干净2.1 压缩包内数据结构的还原判断解压后我看到的目录层级大致是根目录下有data/、scripts/、output/三个文件夹。data/里通常存放的是站点气象观测数据温度、湿度、风速、降水加上一份按经纬度标记的火点记录scripts/是一组处理脚本output/预先放了几个示例图表和统计表。如果你手里的压缩包结构有出入问题不大因为这套分析流程的核心是数据格式的统一而不是目录名是否一致这一点在后面排错部分会展开。气象数据文件的命名一般形如station_101_2023.csv每行记录包含日期、时间、温度、相对湿度、风速、降水量火点记录则多为 MODIS 或同类遥感产品的提取结果字段通常有经度、纬度、日期、亮温、置信度。两套数据的关键关联键是时间和空间——时间对齐到日空间对齐到站点就近匹配。处理这样的数据最容易翻车的地方是日期格式不一致气象站用2023-04-05火点记录用2023/4/5直接合并必然报错。我一般会先写一个探查脚本把两份数据的列名和类型打印出来确认后再做清洗这比上来就写merge靠谱得多。import pandas as pd weather pd.read_csv(data/station_101_2023.csv, encodinggbk) fire pd.read_csv(data/fire_points_2023.csv, encodingutf-8) print(气象数据列名, weather.columns.tolist()) print(火点数据列名, fire.columns.tolist()) print(气象数据行数, len(weather), 火点记录行数, len(fire)) print(weather.dtypes) print(fire.dtypes)这段代码的作用是双重的一是确认两个文件是否能正常读入二是看列名和数据类型是否符合预期。encoding参数根据文件实际编码调整Excel 导出的 CSV 常用 gbk遥感产品导出多为 utf-8。打印出的dtypes如果发现日期列是 object 类型而非 datetime说明后面要做类型转换如果经度列出现字符串类型的空值清洗时要特别处理。2.2 时间格式统一与异常值剔除拿到原始文件后第一步总是把时间列转换成统一的 datetime 格式。常见做法是写一个标准化函数接收日期字符串尝试多种格式返回标准化的日期对象。这个步骤不能省因为后续聚合分析按周、按月统计火险指数完全依赖时间字段的正确排序。from datetime import datetime def parse_date(s): s s.strip() for fmt in (%Y-%m-%d, %Y/%m/%d, %Y%m%d, %Y.%m.%d): try: return datetime.strptime(s, fmt) except ValueError: continue return None weather[date_parsed] weather[date].apply(parse_date) fire[date_parsed] fire[acq_date].apply(parse_date) weather weather.dropna(subset[date_parsed]) fire fire.dropna(subset[date_parsed])这段代码的关键是dropna(subset...)——它做的是整行丢弃不是填充。为什么敢直接删因为气象观测数据的日期字段缺失通常意味着该行其他字段也多为异常填充反而会引入错误信号。参数说明%Y-%m-%d对应2023-04-05%Y/%m/%d对应2023/4/5而%Y%m%d对应的是无分隔符的20230405这种写法三种格式在野外数据里最常见。但这里有个容易被忽略的坑日期解析成功不等于数据可信。气象站偶发故障时温度列可能出现 99.9 这种填充值历史数据常用 99.9 或 999 代表缺测湿度可能超过 100%风速可能为负数。我见过有人不处理这些值直接拿去算火险指数结果输出图出现一条竖直的异常尖峰就是某一天湿度 135% 造成的。处理方式如下weather weather[ (weather[temperature] -30) (weather[temperature] 50) (weather[humidity] 0) (weather[humidity] 100) (weather[wind_speed] 0) ]这个过滤条件的逻辑很简单物理上不可能出现的值直接丢弃。温度下限设 -30°C 是因为该分析面向的是亚热带到温带的森林区域如果你手里是寒温带数据需要把下限放宽到 -50°C湿度超过 100% 的属于仪器误差风速为负则明显是单位换算或采集异常。参数怎么改取决于你的数据覆盖面但原则是“宁可少一行不要错一行”。3. 火险气象指数的计算三个核心因子怎么组合才不拍脑袋3.1 从气象因子到指数模型的映射逻辑森林火险不是一个可以直接测量的物理量它是气象条件、可燃物含水率、地形等因素的综合映射。现成的模型有很多加拿大的 FWI 系统、美国的 NFDRS、国内的《森林火险气象等级》行业标准。这套资源里采用的做法更接近国内标准的简化版——主要基于温度、相对湿度、风速和前期降水来推算可燃物含水率再映射成五个火险等级。为什么不直接套 FWI因为 FWI 需要连续多日的气象输入来计算湿度码DMC和干旱码DC对输入数据的连续性要求很高站点数据一旦缺测几天FWI 的计算结果会严重漂移。而国内标准思路更适合离散站点数据它把每个站点当作独立样本计算当日的火险指数。这个取舍很重要理解它你才知道为什么脚本里的公式长那个样子而不是问“为什么不用更复杂的模型”。可燃物含水率的简化估算公式通常写成def fuel_moisture(temperature, humidity, wind_speed, rain_24h): # 经验公式通过温度与湿度估算平衡含水率再根据风速修正 emc 0.5 * humidity / max(temperature 10, 1) 0.2 # 降水超过5mm时可燃物含水率显著上升 if rain_24h 5: emc 0.15 # 风速超过10m/s时含水率向下修正 if wind_speed 10: emc * 0.9 return round(min(max(emc, 0), 1), 4) print(fuel_moisture(25, 40, 12, 0)) print(fuel_moisture(25, 40, 12, 8))注释里已经写了公式的物理含义温度越高、湿度越低可燃物越干含水率越小降水是含水率的直接补充大风则加速水分蒸发对含水率做负修正。max(temperature 10, 1)防止除零min(max(emc, 0), 1)把输出限制在 0 到 1 之间。两个print分别模拟了无降水和大降水两种情况输出差异一看便知降水因子对含水率的修正幅度。3.2 火险等级的映射与输出有了可燃物含水率再结合温度和风速就能映射出火险等级。这套资源里的映射表大致如下含水率区间温度条件风速条件火险等级大于 0.6任意任意一级低0.4 ~ 0.6小于 20°C小于 5m/s二级较低0.4 ~ 0.6大于 20°C 或 大于 5m/s任一满足三级较高0.2 ~ 0.4任意任意四级高小于 0.2任意任意五级极高这个表的价值在于它把连续的气象变量变成了离散的等级信号。实际火险预警不需要精确到小数点的指数而是需要“今天哪些区域不能动火”这样的判断。映射逻辑写进脚本里通常是def fire_risk_level(moisture, temperature, wind_speed): if moisture 0.6: return 1 elif moisture 0.4: if temperature 20 and wind_speed 5: return 2 else: return 3 elif moisture 0.2: return 4 else: return 5 levels [] for row in weather.itertuples(): m fuel_moisture(row.temperature, row.humidity, row.wind_speed, row.rain_24h) levels.append(fire_risk_level(m, row.temperature, row.wind_speed)) weather[risk_level] levels这段代码的主体是fire_risk_level函数逻辑和上面的表完全一致。weather.itertuples()比iterrows()快不少数据量上万行时差距明显如果你测试时发现循环很慢换成itertuples通常是第一优化手段。计算完成后risk_level列被追加到原 DataFrame 里后续直接按这个字段做统计和出图。这里有一个常见争议为什么不直接套机器学习模型预测火险因为火险指数本质上是“规定动作”标准里怎么写就该怎么算模型输出的不可解释性让它无法通过防火部门的审核。你算出来的指数要能跟标准对照要能说清楚为什么今天是四级而不是三级可解释性在这里是第一位的。4. 站点聚合与可视化让火险分布看得见4.1 按站点和日期聚合的两种写法气象分析通常不止一个站点压缩包里应该有多份站点数据。处理多站点数据时我习惯把所有站点读入后合并成一个长表再按不同维度聚合。长表格式是每行一条记录包含站点 ID、日期、各类气象值、火险等级。合并的代码并不复杂import glob all_files glob.glob(data/station_*.csv) frames [] for f in all_files: df pd.read_csv(f, encodinggbk) df[station_id] f.split(_)[1] frames.append(df) all_data pd.concat(frames, ignore_indexTrue)glob.glob负责匹配所有以station_开头、.csv结尾的文件f.split(_)[1]从文件名station_101_2023.csv中提取站点编号 101作为该文件的站点标识。pd.concat把多个 DataFrame 纵向拼接ignore_indexTrue重置索引防止重复。拼完的长表就是我们做分析的主体——按站点分组看年均火险等级按日期分组看时间趋势都从这张表出发。聚合统计的常见需求有两个方向一是看看哪个站点火险等级最高空间维度二是看看哪个月份火险最集中时间维度。前者用groupby加mean后者需要把日期列拆出月份字段后再聚合。要注意的是mean对等级数值求平均在统计上不是严格的等级是定序变量不是定距变量但在火险分析实践中用均值做排序是普遍做法结果仅作参考。更严谨的做法是取众数或计算各级别占比脚本里一般两种都提供你可以按需选择。4.2 出图时的两个常见误用可视化是这套资源最容易出效果也最容易出问题的地方。常见的输出是三类图站点风险等级分布图、火险等级时间曲线、气象因子散点矩阵。时间曲线这类图相对安全散点矩阵很容易画成“看起来热闹但不知道在看什么”的废图。我见过最典型的误用是把散点图的数据点按日期顺序连成折线然后用不同颜色标注火险等级。看起来信息量很大实际上一堆点线交织在一起根本没法读。正确的做法是按月份做分组统计输出每个月各火险等级的天数占比柱状图。因为防火期和非防火期的分布差异非常大这样的图可以直接告诉决策者“四月高火险天数占比超过了百分之六十”这样的结论而不是一个只有自己能看懂的散点云。另一个误用是火险等级色阶用连续渐变色。从一级到五级用蓝色到红色渐变看起来很直观但在黑白打印场景下完全不可读。更稳妥的方案是固定色板一级用淡绿、二级用黄、三级用橙、四级用深红、五级用褐保证色差可辨识。import matplotlib.pyplot as plt import matplotlib.colors as mcolors colors [#8bc34a, #ffeb3b, #ff9800, #d32f2f, #4e342e] cmap mcolors.ListedColormap(colors) level_counts all_data.groupby([station_id, risk_level]).size().unstack(fill_value0) level_counts.plot(kindbar, stackedTrue, colormapcmap, figsize(12, 6)) plt.xlabel(站点编号) plt.ylabel(天数) plt.legend(title火险等级) plt.tight_layout() plt.savefig(output/risk_by_station.png, dpi150)这段代码的核心是两级处理一是用groupby加size()统计每个站点的各等级天数unstack(fill_value0)把等级转成列空值填 0二是用ListedColormap指定固定色板保证图例与等级对应关系始终一致。dpi150是打印或者汇报演示的最低清晰度要求低于这个值投影出来会有明显锯齿。5. 避坑与排查跑不出结果时先检查这五个位置5.1 编码错误导致读入失败现象pd.read_csv报UnicodeDecodeError文件读不进来。原因气象站导出的 CSV 在 Windows 系统上常见为 GBK 编码而 pandas 默认用 utf-8 读取。解决读入时指定encodinggbk如果仍然报错打开文件前几行确认编码名。更稳妥的做法是写一个自动检测编码的小函数依次尝试 gbk、utf-8、latin1谁先成功用谁。这在处理多个来源数据时特别实用。5.2 日期列被解析成字符串现象聚合时报TypeError: string indices must be integers检查后发现日期列类型是 object。原因原始数据中日期格式混杂部分行是2023-04-05部分行是2023/4/5pandas 无法自动统一。解决不要依赖 pandas 的自动解析按 2.2 节的parse_date函数手动转换。转换后务必执行dropna(subset[date_parsed])否则残留的失效行会在后续聚合时产生不可预知的脏数据。5.3 站点编号提取错误现象合并后的长表中所有站点数据全部堆到一个站点名下。原因f.split(_)[1]在文件名是station_101_2023.csv时返回 101但如果文件名是station101_2023.csvsplit 结果完全不同。解决提取前先打印all_files的前几个文件名确认命名规律后再写提取逻辑。如果命名不统一用正则表达式re.search(r\d, f).group()提取第一个连续数字串更安全。5.4 降水字段为空导致含水率计算异常现象算出来的含水率全部集中在 0.99 附近火险等级全是一级。原因降水列在多数非雨季天气里为空值代码用rain_24h 5判断时会跳到降水不足的逻辑分支但如果空值被 pandas 读成NaN参与运算时导致含水率被异常抬高。解决计算前统一处理降水列空值weather[rain_24h].fillna(0, inplaceTrue)。这个动作必须放在含水率计算之前否则公式里的if rain_24h 5永远不会触发雨天场景完全失效。5.5 出图中文乱码现象图上的站点编号、轴标签全变成方块。原因Matplotlib 默认字体不包含中文字形。解决脚本开头加上字体设置plt.rcParams[font.sans-serif] [SimHei, Microsoft YaHei] plt.rcParams[axes.unicode_minus] False如果这两行不生效说明系统里没有这两个字体换成 Linux 下的WenQuanYi Zen Hei或Noto Sans CJK SC。我处理过的环境里这个坑出现频率非常高几乎是每次换机器都要踩一次。6. 进阶用法从静态分析到时间滑动窗口预警算完火险等级只是第一步真正能用于防火值班的是动态预警。静态分析告诉你“这个区域总体风险偏高”动态预警告诉你“这三天风险在爬升需要加强巡防”。进阶用法是对气象序列做滑动窗口计算提取连续多天的火险等级变化趋势当窗口内高火险天数占比超过阈值时标记为预警日。滑动窗口的实现思路对每个站点按日期排序取前 7 天包含当天的数据计算这 7 天中四级及以上火险等级的天数占比当占比大于等于 4/7 时给当天打上预警标签。这个逻辑比单日指数更有实战价值因为它捕捉的是“连续高火险累积”的状态而这种状态才是森林火灾最容易发生的条件。def warning_flag(series, window7, high_levels(4, 5), threshold0.5): flags [] for i in range(len(series)): start max(0, i - window 1) win series.iloc[start:i1] high_ratio win.isin(high_levels).mean() flags.append(1 if high_ratio threshold else 0) return pd.Series(flags, indexseries.index) for sid, group in all_data.groupby(station_id): group_sorted group.sort_values(date_parsed) all_data.loc[group_sorted.index, warning] warning_flag(group_sorted[risk_level])这段代码里最关键的是win.isin(high_levels).mean()它在统计窗口内高火险等级的占比用布尔值序列的均值来计算比例是一种简洁高效的写法。window7表示取一周的数据threshold0.5表示高火险天数占一半以上就预警。参数怎么调如果你的区域防火期短、降雨频繁阈值可以调到 0.6 避免误报如果是干旱区域0.3 就应该触发预警。验证这套流程是否可靠我习惯在跑完所有脚本后做一次“回溯测试”拿过去五年的数据重新跑一遍把标记的预警日和历史火灾记录做个对比计算命中率。如果命中率低于百分之六十我会检查等级映射阈值是否需要调整。这不是书上的形式化要求而是我实际工作中判断“这套分析值不值得上报”的核心依据。这个压缩包下载下来解压后建议先跑一遍原始脚本看默认输出再按你的站点数据调整参数。调整时重点关注三处降水阈值默认 5mm 是否适合你的气候区、风速修正强度默认 0.9 是否过于保守、预警窗口天数默认 7 天是否匹配你的防火值班周期。这三处调好整套分析才真正贴合你的业务场景。我第一次拿到类似资源时没有先做数据探查就直接跑结果输出的图表看着正常直到回溯测试才发现命中率只有三成排查了一个小时才发现是降水空值没处理。从那以后我每次处理新的气象数据都强制先检查缺失值分布再动计算逻辑。希望这套流程和坑位清单帮你在森林火灾分析上少走几段弯路。本文还有配套的精品资源点击获取
