VIIRS火点数据这事儿，我前后折腾了差不多三年，从最开始只会在地图上点几下看个热闹，到后来要给业务侧做逐日的火点核查清单，中间踩过的坑基本能写满一页纸。最近又有一波同行问起来，索性把整套流程重走一遍，把"实时监测"和"历史回溯"这两条线彻底捋清楚。这篇东西面向的是需要在最短时间内把数据拿到手、并且能直接拿去用的人：做秸秆焚烧巡查支撑的、做森林草原火险研判的、做工业热源排查的，也包括刚开始接触遥感火点产品的学生和转岗朋友。我会把产品谱系、下载渠道、脚本写法、字段含义、以及那些官方文档里不太会写的坑，一条一条摊开讲。看完之后你应该能做到：知道某个需求该选哪个产品、能在半小时内把一周的数据批量拖下来、能在打开文件之后判断出哪些火点是真火、哪些是砖窑和沙漠自己"烧"起来的。
1. 火点判识这件事，为什么我一直优先选VIIRS而不是MODIS
1.1 375米这条分辨率线到底改变了什么
MODIS的火点产品是1公里分辨率，这个数字在图上看起来还算体面，但落到地面就很尴尬：一个像元一平方公里，一个村子烧两亩地的秸秆，在这块面积里只占千分之几，中红外通道的亮温抬升会被大量背景地表"稀释"掉。我做过一个粗略的对比统计，同一个区域、同一段时间，MODIS能报出来的点大概只有VIIRS 375米产品的一半多一点，剩下那部分基本都散在中小型火源上。VIIRS的I4波段是3.74微米，空间分辨率375米，像元面积只有MODIS的十四分之一左右，同样热量的火源在像元里占比高得多，亮温差更容易越过阈值。
但它并不是简单地"把像素切小了"。VIIRS的火点算法用的是I4（3.74μm）和I5（11.45μm）两个通道的亮温组合，本质上还是经典的中红外—热红外双通道判识思路：高温目标在中红外的辐射增量远大于热红外，两者之间的亮温差就是火点的指纹。不同的是375米产品在背景窗口的选取上更依赖局部邻域统计，对小型、孤立热源的敏感度明显提高，代价是对比度低的地表（比如大面积裸地、沙地）更容易被误判。这一点后面讲避坑的时候会重点展开，因为这是新手最容易栽跟头的地方。
还有一点常被忽略：VIIRS有5个I波段和16个M波段，火点产品用I波段做375米，但云掩膜、亮温辅助判断这些环节仍然会用到M波段。所以你拿到的HDF5文件里，一部分字段的空间尺度跟火点字段并不一致，混着用会出错。
1.2 双星甚至三星组网之后的过境时间窗
单看一颗星的过境频次，其实没有想象中那么美好。以最早那颗搭载VIIRS的极轨卫星为例，它的降轨白天过境在当地太阳时13:30左右，升轨夜间过境在01:30左右，一天对同一地点有效覆盖两次，其中白天那次是最有用的。问题在于，火着起来是不挑时间的，下午两点到第二天下午两点之间这二十四小时，可能已经烧掉了几百亩。
现在的局面好很多。第二颗和第三颗同系列卫星陆续入轨之后，三星组网把白天的观测窗口往前推了一截，三颗星的降轨过境时间大致落在地方时13:20到13:40这个窄带里，彼此间隔十几分钟到二十分钟不等。这个间隔看着不大，但对火点判识有实际意义：十几分钟的时间差，可以让一处快速发展的火场在两景影像里呈现不同的FRP（火灾辐射功率）值，两次观测的差值某种程度上能反映火势的扩张速度。我在做火情态势的时候，会把三星的结果叠在一起看，同一位置连续两个过境时刻都被判出来、且FRP在涨，那基本可以确认是活跃火线，而不是某个恒定热源。
要注意的是，轨道是会漂移的。卫星在轨时间越长，降交点地方时漂移越明显，几年前的资料里写的13:30，现在可能已经是13:2x。所以别死记某个固定时刻，判断昼夜还是老老实实看数据里的时间字段。
| 对比维度 | MODIS火点产品 | VIIRS 375米火点产品 | VIIRS 1公里火点产品 |
|---|---|---|---|
| 星下点分辨率 | 1 km | 375 m | 750 m |
| 主判识通道 | 4μm + 11μm | I4 3.74μm + I5 11.45μm | M13 4μm + M15 11μm |
| 小型火源敏感度 | 一般 | 高 | 中等 |
| 单景幅宽 | 约2330 km | 约3060 km | 约3060 km |
| 误报倾向 | 相对低 | 裸地/工业热源上偏高 | 介于两者之间 |
| 近实时可用性 | 有 | 有 | 有 |
| 适合场景 | 大范围长时序统计 | 中小火源、精细核查 | 与历史产品衔接 |
这张表是我自己在选型的时候反复看的几个维度。实际经验是：做大尺度、跨十年的趋势分析，MODIS的连续性更好，毕竟人家服役时间长；做区域级的日常火点核查，375米那档几乎是默认选项；如果只是要一份跟已有成果对齐的历史序列，1公里产品反而更省事。
2. 产品谱系先理清楚，不然下载下来就是一堆不能用的文件
2.1 近实时产品和归档产品根本不是一个东西
这是我最开始犯的错。看到"火点数据"四个字就随手点了个下载，拉回来一堆文件名长得差不多的HDF5，结果发现不同时间下的同一个区域，火点数量对不上，一度怀疑是自己代码写错了。
后来才搞明白，火点产品在分发上是分成两条独立流水线的。一条叫近实时，卫星过境之后三小时左右就能出结果，靠的是简化处理流程和快速定标，目的是抢时间；另一条叫归档标准产品，等定标参数稳定、几何精度复核完成之后再统一重处理，通常是过境之后一到两周才放出。两条线用的算法核心是一样的，但输入的定标系数、云掩膜版本、几何定位参数都可能有细微差别，导致同一景影像在两条线上的火点数量和位置存在差异。
这个差别在实际工作里的影响非常具体。如果你做的是当日火情通报，只能用近实时产品，晚几个小时就没有意义了；如果你做的是年度统计、论文分析、责任追溯，必须用归档标准产品，因为它是可复现、可引用的。最要命的情况是拿近实时数据去做长期统计，因为近实时产品在后期会被重处理替换，你今天跑出来的统计结果，一个月后拿同样流程再跑一遍就对不上了。
我把两条线的差异整理成了下面这样，方便快速决策：
| 维度 | 近实时产品 | 归档标准产品 |
|---|---|---|
| 数据延迟 | 过境后约3小时 | 过境后1至2周 |
| 定标参数 | 快速定标，可能后续微调 | 精确定标，已固化 |
| 几何精度 | 可用 | 更高 |
| 是否会被重处理替换 | 会 | 版本固定 |
| 典型用途 | 当日火情通报、应急 | 统计分析、成果发表、责任核查 |
| 版本号特征 | 文件名中带NRT字样 | 版本号稳定，如001、002 |
记住一条铁律：任何要对外发布或者要留档的结果，都必须在文档里写清楚用的是近实时还是归档、哪一版Collection。否则三个月后你自己都复现不出来。
2.2 活跃火点和过火面积是两码事，别拿错
第二个常见的混淆是"火点"和"过火迹地"。活跃火点产品（Active Fire）标记的是卫星过境那一瞬间正在燃烧的像元，本质是一个瞬时快照；过火迹地产品（Burned Area）标记的是一段时间内被烧过的区域范围，通常是月尺度的合成产品。两者用途完全不同。
我见过有人拿活跃火点去做过火面积估算，直接把火点像元数乘以0.375×0.375平方公里，得出一个数字。这个做法在特定条件下勉强能用，但会系统性低估，因为卫星一天只过境两三次，很多火在两次过境之间就烧完了，根本没被拍到；而且火场内部已经烧过的区域温度已经降下来，不会被判为活跃火点。
反过来也有人在需要快速响应的时候去下过火迹地产品，结果发现最新一期是一个月前的，完全没法用。
我的做法是分场景：应急响应、当日核查，一律用活跃火点；灾后评估、面积统计、碳排放估算，用过火迹地；两者都需要的时候，用活跃火点定位火线走向，用过火迹地圈定影响范围，互为补充。
2.3 文件名里那串字符其实是解码表
火点产品的文件名看起来像随机字符串，其实每个字段都有含义。最典型的结构是这样：产品短名 + 采集时间标识 + 处理时间标识 + 版本号 + 扩展名。采集时间标识以字母A开头，后面跟的是年积日，再往后四位是UTC的小时和分钟。
举个例子，看到类似VNP14IMG.A2024135.0340.002.2024136041823.hdf这样的名字，你应该能立刻读出来：这是375米活跃火点标准产品，2024年第135天（也就是5月中旬）UTC时间03:40采集，Collection版本002，文件是2024年第136天04:18:23处理完成的。
学会读这个能省很多事。比如批量下载的时候，你可以直接按文件名过滤出你要的时间段，不用先下载再筛选；比如排查数据缺失的时候，你能一眼看出是某个时段没有过境，还是过境了但处理失败。我有一段时间天天对着文件名找缺失，练出来之后基本扫一眼就知道哪天的数据有问题。
还有个小细节：同一景影像的不同版本文件名只有版本号那一段不同，批量下载脚本如果不加判断，很容易把同一个granule的两个版本都拖下来，白白翻倍占空间。
3. 三条下载路径，各自适合什么活
3.1 网页检索界面：抽样验证和临时取数最顺手
如果只是要看某一天某个省的火点分布，或者临时取几景数据验证一下读取代码，用网页检索界面是最快的。这类界面通常支持按产品、时间范围、地理范围（画框或者输经纬度）检索，结果以列表形式呈现，可以勾选后打包下载。
这类界面的优势在于零门槛，不用配环境、不用写脚本，检索完直接点下载。缺点是明显的：一次检索的时间跨度有限制、结果条数有上限、批量打包下载的速度很不稳定。我试过在一个工作日的下午拖一整个月的全国数据，压缩包下到一半断掉，重来又是从头开始。
所以我现在的用法是：只在两种情况下开网页。一是新接触一个产品，先下两三景看看结构、确认字段名；二是给不写代码的同事准备一份"傻瓜包"，让他们自己点。真正要批量干活的时候，一律走脚本。
另外这类界面通常会配一个简单的在线浏览功能，能直接把火点叠在底图上。这个功能做初步的真假火判断其实挺好用，尤其是看那些固定在工厂烟囱位置、一年四季都在报的点，一眼就能认出来。
3.2 脚本批量拉取：真正干活靠这条
批量下载的完整链路大概是：注册账号并同意数据使用条款 → 配置身份凭证 → 构造URL列表 → 用下载工具批量拉取 → 校验完整性。
身份凭证有两种常见形式。一种是用户名密码直接写在配置文件里，另一种是申请一个长期有效的令牌，在请求头里带上。前者配置简单但安全性差，后者适合放在服务器上跑定时任务。我自己的习惯是本地机器用配置文件，服务器上用环境变量注入令牌，避免凭证被误提交到代码仓库。
配置文件的写法大致是这样，注意权限一定要收紧：
# 本地凭证配置，Linux/macOS下放在用户主目录 cat > ~/.netrc << 'EOF' machine <数据门户主机名> login <你的用户名> password <你的密码> EOF # 权限必须收紧，否则部分下载工具会拒绝读取 chmod 600 ~/.netrc令牌方式则更干净，适合脚本化：
# 把令牌写进环境变量，不要硬编码进脚本 export EARTHDATA_TOKEN="<你的长期令牌>" # 请求时带上即可 curl -L -H "Authorization: Bearer ${EARTHDATA_TOKEN}" \ -o sample.hdf \ "https://<数据门户域名>/archive/allData/5200/VNP14IMG/2024/135/VNP14IMG.A2024135.0340.002.2024136041823.hdf"构造URL列表这一步是批量下载的核心。归档目录的组织方式基本都是按年、按年积日分层，所以你可以用循环拼出每一天的目录，再把目录页里的文件名抓下来。下面这段是我常用的写法，用Python生成URL清单：
import datetime as dt BASE = "https://<数据门户域名>/archive/allData/5200/VNP14IMG" def build_urls(start: dt.date, end: dt.date): urls = [] d = start while d <= end: year, doy = d.year, d.timetuple().tm_yday # 归档目录按 年/年积日 分层 day_dir = f"{BASE}/{year}/{doy:03d}/" urls.append(day_dir) d += dt.timedelta(days=1) return urls if __name__ == "__main__": for u in build_urls(dt.date(2024, 5, 1), dt.date(2024, 5, 7)): print(u)拿到目录列表之后，用递归下载工具一次性拉下来。这里有个参数必须注意，就是目录层级的裁剪。如果不加--cut-dirs，下载下来的文件会带着一长串嵌套目录，后期处理的时候路径长得没法看。
wget --load-cookies ~/.urs_cookies \ --save-cookies ~/.urs_cookies \ --keep-session-cookies \ --auth-no-challenge=on \ -r -np -nH --cut-dirs=5 \ -R "index.html*,*.tmp" \ --tries=3 --waitretry=5 \ -i url_list.txt几个参数值得单独说：--cut-dirs=5是砍掉URL里前五层目录，具体数字要看你拼的URL结构，砍多了会把年月日全砍掉导致文件重名覆盖，砍少了路径太深；--tries和--waitretry是应对服务端限流的关键，火点数据门户在高峰时段会限速，不加等待重试很容易被直接掐断；-R排除掉索引页和临时文件，不然会拖一堆无用的HTML回来。
3.3 云端平台：不想落盘的时候的另一条路
如果你的最终目的是 статистика、出图、做个简单的时序曲线，其实完全可以把数据留在云端。这类平台已经把火点产品整理成了可以直接调用的数据集，选定区域和时间范围，几行代码就能拿到筛选后的结果，不用管文件结构、不用管投影。
// 云端平台上按区域和时间筛选火点，取回表格 var fc = ee.FeatureCollection('projects/<项目名>/assets/<火点数据集名>') .filterBounds(geometry) .filterDate('2024-05-01', '2024-05-08')) .filter(ee.Filter.gte('confidence', 70)); print(fc.size()); Export.table.toDrive({collection: fc, description: 'fire_points_202405'});这种用法最大的好处是快，省掉了下载、读取、解析的整条链路。坏处也很明显：字段是被平台重新整理过的，跟原始HDF5里的字段不完全对应；不同数据集的版本更新节奏不一致；而且一旦你需要的字段平台没提供，就得回头去下原始文件。
我自己的取舍是：探索性分析、快速出图、给别人做个示意，用云端；要做严谨的统计、要控制版本、要把结果固化下来存档，老老实实下原始文件。两者之间并不是替代关系，很多时候是先用云端快速看一眼数据长什么样，确认没问题了再走批量下载。
4. 那些年踩过的坑，逐条拆开看
4.1 火点整体偏移：投影没对上，全盘皆输
这是最典型也最隐蔽的坑。表现得很有迷惑性：火点位置看着"差不多"，但叠到行政边界或者高分底图上，会整体偏移几百米到几公里，而且偏移量在不同纬度还不一样。
我当时的做法是把数据读出来之后，自己按正弦投影（Sinusoidal）的瓦片规则去反算经纬度，算完发现偏了。查了大半天，最后发现产品文件里本来就带好了每个火点像元的经纬度字段，直接读那个字段就完事了，根本不需要自己投影。
这件事的教训很实在：火点产品里的经纬度是产品生成阶段算好的，用的是当时的几何定位参数，精度远高于你事后拿投影参数反算的结果。任何自己重新投影的操作，都是在引入误差。
具体到字段，火点相关的经纬度字段通常带FP_前缀（FP是fire pixel的意思），跟整景影像的经纬度网格字段是两套东西。整景网格字段的长度是完整的行列数（三千多万个值），而火点字段的长度只等于检出的火点像元数量（可能只有几个、几十个）。这两者绝对不能混用，我见过有人拿火点数组去索引整景网格的经纬度，结果出来的位置完全随机。
还有一个衍生问题：如果你要把火点跟其他栅格数据做叠加分析，不要试图把火点"栅格化"到某个投影网格上再做统计，直接按点做空间查询或者空间连接会稳妥得多。
4.2 时间字段是UTC，别当成当地时间直接用
火点数据里的时间字段，采集日期和采集时间基本都是UTC。如果你的业务流程是按北京时间划日界，直接用UTC的日期去聚合，结果一定是错的：北京时间早上八点之前的火点，在UTC里还属于前一天。
这个错误在做日统计的时候尤其致命。比如某天凌晨两点发生的一场火，UTC时间还是前一天下午六点，按UTC聚合会被算到前一天去。如果你在做逐日火点数量考核，这个错位会直接导致两天的数字都失真。
我的处理方式是在入库的时候就统一转换：读出来之后立刻按UTC时间构造完整的时间戳，再统一转成目标时区，后续所有统计都按转换后的时间走。JSON或者CSV导出的时候，务必保留原始的UTC字段和转换后的本地时间字段各一份，方便回溯核对。
import pandas as pd df = pd.DataFrame({ "acq_date": dates, # 形如 2024-05-15 "acq_time": times, # 形如 340，表示UTC 03:40 }) # 先把UTC时间拼出来 df["utc_dt"] = pd.to_datetime(df["acq_date"]) + \ pd.to_timedelta(df["acq_time"] // 100, unit="h") + \ pd.to_timedelta(df["acq_time"] % 100, unit="m") # 再转成目标时区 df["local_dt"] = df["utc_dt"].dt.tz_localize("UTC").dt.tz_convert("Asia/Shanghai")顺便提一句，采集时间字段是四位数字，前两位是小时、后两位是分钟。直接当整数比较会出问题，比如 55 和 105，按整数比 105 大，但实际 0105 是凌晨一点零五分，55 应该是 0055 也就是凌晨零点五十五分。分列处理才是对的。
4.3 置信度字段的理解偏差，直接导致大面积漏报和误报
火点产品的置信度字段，是我见过被误解最多的一个。原因是同一个产品体系里，不同分辨率的产品用的表达方式不一样：一种用低、中、高三档字母，另一种用0到100的百分比数值。如果你把两套规则混着用，比如给百分比数值套上"大于等于高"的判断，结果就是全被过滤掉。
我踩这个坑的时候是这么发现的：跑完脚本发现某天全国只有个位数的火点，明显不对，去原始文件里一查，数值全是七八十、九十几，而我的过滤条件是跟字母比较。
正确的处理是先把两种表达统一化。百分比数值直接按阈值切，字母档位映射成数值区间。业界比较通行的做法是：百分比大于等于80视为高置信，50到80视为中，低于50的谨慎使用或者直接丢弃。做严格的火情核查，我一般只留高置信；做趋势统计或者找疑似点，会放宽到中置信，但会标注出来。
不过置信度不是万能的。高置信的火点也可能是固定热源误报，低置信的火点也可能是真火（被薄云遮挡导致亮温差被削弱）。所以我从来不单靠置信度做最终判断，都是把它当成第一道粗筛，后面再叠加别的条件。
4.4 近实时数据被重处理，昨天的结果今天变了
这个坑最让人抓狂的地方在于"迟发性"。你今天用近实时数据跑出一份报告，数据合理、逻辑自洽，交出去了。两周之后有人拿着同样的流程重跑一遍，数字变了，然后来问你为什么。
原因前面提过：近实时产品在归档重处理之后，文件会被替换，版本号和部分字段值都会变。如果你没有记录当时用的具体文件名和版本，根本无从解释。
我现在的做法是：任何用近实时数据产出的结果，都随结果保存一份源文件清单，包含文件名、版本号、下载时间、文件校验值。同时在报告里明确标注"本结果基于近实时产品，后续可能因重处理发生变动，正式用途请以归档标准产品为准"。这个动作看着繁琐，但救过我至少两次。
还有一个衍生问题：如果你在做增量更新，比如每天拉一次最新数据追加到数据库，一定要用文件名或版本号做去重，不能只按时间戳判断。否则同一景数据被重处理替换之后，会出现两条记录，统计翻倍。
4.5 区域查询被截断、请求被限流
用接口按区域拉火点时，很容易碰到两个限制。一个是查询范围的限制：单次请求的经纬度范围有面积上限和天数上限，超出之后接口要么直接报错，要么更阴险地只返回部分结果而不报错。另一个是频率限制：短时间内连续请求会被拒，返回空的或者错误码。
吃过一次亏之后，我固定了两个习惯。第一，任何区域查询都先拆成小格子，按格子分别请求再合并，格子大小控制在查询上限的七成左右，留出余量。第二，批量请求之间强制加延时，并且对返回结果做校验——如果某次请求返回的记录数恰好等于接口的常见上限值，就当作可疑结果，换个更小的范围重试一遍确认。
# 按接口规则构造区域查询URL，请求之间加延时 for day in 1 2 3 4 5; do curl -s -o "fire_${day}.csv" \ "https://<火点接口域名>/api/area/csv/<你的MAP_KEY>/<产品标识>/<西>,<南>,<东>,<北>/${day}" sleep 2 done # 简单校验：记录数异常少或异常整齐都要人工看一眼 wc -l fire_*.csv接口还有一个细节：返回的经纬度精度和字段顺序，跟网页端下载的CSV可能不完全一致。做自动化处理的时候，别假设字段顺序固定，老老实实按表头名取值。
5. 数据到手之后：读取、筛选、核验的完整动作
5.1 HDF5结构速览和读取的坑
火点产品的主流封装格式是HDF5，层级是HDF-EOS的点结构。用Python读的时候，h5py是最省事的，不用装额外的地理信息库。
import h5py import numpy as np def read_fire_points(path, conf_min=80): with h5py.File(path, "r") as f: # 火点经纬度直接用产品算好的，不要自己投影 lat = f["FP_latitude"][:] lon = f["FP_longitude"][:] conf = f["confidence"][:] mask = f["fire mask"][:] frp = f["FRP"][:] b_i4 = f["brightness"][:] # I4 亮温 b_i5 = f["bright_t31"][:] # I5 亮温 keep = conf >= conf_min return { "lon": lon[keep], "lat": lat[keep], "confidence": conf[keep], "fire_mask": mask[keep], "frp": frp[keep], "bt_i4": b_i4[keep], "bt_i5": b_i5[keep], }读的时候有几个坑必须提醒。第一个是字段名的大小写和下划线，不同产品的命名规范不完全统一，有的叫fire mask带空格，有的叫fire_mask，读之前最好先打印一下层级结构看看。第二个是数值填充值，很多字段用了一个很大的负数当无效值标记，不做过滤直接统计会算出离谱的均值。第三个是压缩方式，个别文件用了比较新的压缩算法，老版本的库读不了，报错信息还很隐晦，遇到读不出来的情况先升级库试试。
打印结构这件事我再强调一遍，一行业务代码都不用写，先把目录树打出来看一眼：
import h5py with h5py.File("VNP14IMG.A2024135.0340.002.hdf", "r") as f: f.visititems(lambda name, obj: print(name, getattr(obj, "shape", "")))这一个动作能帮你省掉至少半天的瞎猜时间。
5.2 一套用顺手的筛选规则
原始火点数据从来不能直接用。我的筛选链大概是这样的，按顺序过，每一步都能砍掉一批噪声：
第一道是置信度粗筛。前面说过，严格核查用高置信门槛，统计分析可以放宽。
第二道是火点掩膜类别。产品里的这个字段会把像元分成若干类，包括确定有火、可能有火、云遮挡下的疑似、水体、海岸、裸地等。只保留确定有火和可能有火这两类，其余全丢。
第三道是亮温合理性检查。真火的I4亮温通常在三百多开尔文以上，I5也会同步偏高，两者差值是正的且有一定幅度。如果某个点I4亮温很高但I5几乎没反应，大概率是小面积的高温工业源或者单个像元的异常值。
第四道是固定热源排除。做法是把多年的火点数据叠在一起，统计每个位置被报出来的频次。某些位置一年三百六十五天有三百天都在报，那基本可以确定是水泥厂、钢铁厂、窑炉这类恒定热源，建个黑名单剔掉就行。这个黑名单我维护了好几年，现在积累了上千个点位，效果比任何算法都直接。
| 筛选步骤 | 判据 | 典型剔除比例 | 风险 |
|---|---|---|---|
| 置信度 | 百分比低于阈值 | 20%到40% | 阈值过高会漏掉弱火 |
| 掩膜类别 | 排除云、水、海岸 | 5%到15% | 薄云下的真火会被误删 |
| 亮温合理性 | I4与I5亮温差为负 | 1%到5% | 极小火源可能被误删 |
| 固定热源黑名单 | 多年高频出现位置 | 5%到20% | 新出现的真火不会误伤 |
| 时空一致性 | 孤立单点且无相邻点 | 3%到10% | 真实的小火也可能被删 |
第五道是时空一致性。一场真实的火灾，很少只在一个像元、一个时刻被拍到。如果某个点孤立存在、周围八邻域全无反应、前后两个过境时刻也都没有，那它更可能是噪声。这一步用简单的邻域计数就能实现，不需要复杂算法。
5.3 结果合理性核验的几个土办法
数据筛完之后，怎么判断结果靠不靠谱？我的方法都很土但管用。
第一是看总数的量级。同区域同季节的火点数量应该在一个稳定区间里波动，如果某天突然翻了三倍，先别急着报喜，大概率是云量特别低导致大量裸地被误判，或者是那天的定标参数有问题。
第二是看空间分布的形状。真实的农业焚烧是成片出现的，沿着农田呈现条带状或者簇状；工业热源是点状且位置固定；误报往往呈现随机散布，或者沿着某种地形边界（比如沙漠边缘、山脉阴影线）排列。这个用眼睛看分布图就能判断，比任何统计指标都直观。
第三是拿另一个数据源做交叉验证。同一时段的另一套火点产品，如果两套都报出来了，可信度大幅提升；如果只有一套报了，就需要人工核对。交叉验证不用做得很复杂，按0.01度网格做空间连接，统计重合率就行。
第四是回头看历史。把当前结果的每个点，去历史数据里查一下这个位置过去有没有被报过。报过的，可信度上升；从没报过的，重点关注。这个操作听着麻烦，但建好索引之后一次查询也就几毫秒。
6. 长期跑监测任务，我固定下来的几个习惯
6.1 目录结构和命名，一开始就要定死
这个习惯是被逼出来的。早期我按日期建文件夹，文件名保持原样，结果一年之后想找某个区域某个时段的数据，得写脚本遍历几万个文件去匹配，慢得要命。后来改成按产品、按年月分层，文件名保留原始名但另外维护一张索引表，情况就好了很多。
现在的目录大概是这个结构：顶层按产品短名分，第二层按年月分，第三层放文件，另外在顶层放一个索引数据库，记录每个文件的路径、版本、下载时间、覆盖范围、火点数量。有了这个索引，任何查询都是数据库里走一圈，几百毫秒出结果，完全不用碰文件系统。
索引表里我最看重的是覆盖范围字段。火点产品的单景幅宽很大，但有效覆盖范围跟地理位置有关，存一下四至坐标，后续按区域查数据的时候能直接过滤，避免把全国的数据全读一遍再筛。
6.2 增量拉取和断点续传，别每次都从头来
批量下载最怕的就是中断。一次拉几个月的量，跑到一半断了，从头开始又得几个小时。我的做法是把任务拆成"清单生成"和"清单执行"两步，清单落盘，执行的时候按行读，每成功一个就在清单里打个标记。
下载工具本身其实带断点续传能力，关键参数是续传开关和超时设置。数据文件动辄几十上百兆，超时设得太短，网速一波动就断，设得太长，遇到真的不存在的文件又会卡很久。我的经验值是连接超时设二十秒左右，单次读取超时设三到五分钟，配合三次重试，稳定性能接受。
增量拉取则是靠文件名比对。每次运行先把已有文件的文件名集合读出来，再跟目标清单做差集，只下缺的那部分。这个逻辑简单但极其有效，尤其适合每天定时跑的任务。
6.3 数据留档和版本记录，事后救命
前面反复提到版本问题，这里说具体怎么落。我的做法是每个批次的数据下载完之后，生成一份清单文件，记录这次下载的所有文件名、版本号、文件大小、校验值、下载时刻。清单文件本身也纳入版本管理，跟原始数据放在一起。
为什么这么较真？因为火点数据是要拿来做结论的。一份说"某地某天有三十七个火点"的报告，如果拿不出对应的源文件清单，这个结论就是不可复核的。我遇到过需要回溯半年前一份报告的情况，靠的就是当时留下的清单，五分钟就定位到了原始文件，重新跑了一遍流程，数字完全一致。
还有一点：归档标准产品虽然版本固定，但并不意味着永远不变。数据提供方可能会因为算法缺陷发布新版本，旧版本保留但不再推荐使用。所以留档的时候，除了文件名，还要记一下当时官方推荐的版本号是什么，方便后续判断自己的数据是不是需要更新。
6.4 关于时效和精度的取舍，最后说几句实在话
做了这么久，我最深的一点体会是：火点数据从来不是"下载下来就能用"的东西，它更像是一份线索清单，告诉你哪里可能有问题，需要你去看。指望它百分之百准确，一定会失望；但用得好，它能把人工巡查的范围从几百平方公里压缩到几个具体点位，这个价值是巨大的。
我个人的做法是永远保留一个人工复核环节。算法筛完之后，把疑似点位按置信度、FRP大小、邻域一致性排个序，高分的直接确认，中分的调底图看一眼，低分的留档观察。这个流程跑下来，一天处理几百个点位毫无压力，而且误报率能压到很低。
如果非要说一个最容易上手也最容易出效果的优化点，那就是建固定热源黑名单。这件事没有任何技术门槛，就是积累，但收益立竿见影。我建议任何长期做火点监测的人，从第一天就开始建这张表，每确认一个误报就记一条，一年之后你会发现数据干净了不止一个档次。
