简介WRS2_descending.rar 是一份针对 Landsat TM 传感器的 WRS-2 降轨模式 shapefile 数据压缩包主要面向遥感、地理信息系统GIS领域的研究人员、学生及工程应用者用于解决 TM 影像缺少行列号定位信息时的空间参考与地理编码问题。压缩包共包含 9 个文件核心部分由 .shp、.shx、.dbf 组成分别存储几何要素、索引与属性数据另有 .prj 定义投影坐标系、.xml 保存元数据信息整体仅 3.45MB可直接在 ArcGIS、QGIS 等软件中加载使用。目前已有 232 人学习浏览。借助该数据用户可以将 WRS-2 全球参考系统下的降轨观测位置与 TM 多光谱波段对应起来开展地物分类、土地利用变化检测、环境灾害评估等典型分析同时它也为初学遥感与 GIS 的人提供了一个理解 Shapefile 文件结构与轨道投影概念的具体示例。这份遥感辅助数据集轻量实用是开展空间分析和学习数据组织的良好起点。 我第一次拿到这包数据的时候文件名就一行WRS2_descending.rar。没有配套说明没有 readme也没有人来口头交代这是什么。对这种来路我的习惯是先不急着双击解压而是把文件名当成第一份元数据来读——WRS2 是 Landsat 系列卫星所用的 WRS-2 全球参考网格系统descending 表示降轨数据后面的 .rar 只是分发时的压缩壳。把这层皮剥掉这包数据的基本身份就清楚了它大概率是一景按 WRS-2 网格编号组织的、由北向南过境成像的 Landsat 影像压缩包。这篇文章就围绕这个文件名展开。我会从命名解读、解压前检查、解压后的文件确认到接入实际处理流程最后分享几个我踩过的坑。适合刚接触遥感数据下载与预处理的同学也适合需要批量整理 Landsat 影像、但每次都被“只发来一个压缩包”这种交付方式折磨的从业者。1. WRS2 的一半信息在文件名里解读降轨与网格编号1.1 WRS-2 网格path 和 row 在说什么WRS 的全称是 Worldwide Reference System世界参考系统。Landsat 用过的有两代WRS-1 用于早期的 Landsat 1 到 3WRS-2 从 Landsat 4 之后一直沿用到今天的 Landsat 9。说白了它就是一个把地球表面切分成固定格子的编址方案。WRS-2 把地球划分为 233 个 path 和 122 个 row。path 可以理解为轨道号控制经度方向的轨迹位置row 是行号控制纬度方向的覆盖位置。两者交叉出来的一个格子就是“一景”影像地面覆盖范围大致是 185km × 180km 见方的区域。每个格子的编号是固定的比如 122/041就代表 WRS-2 网格里第 122 条 path 和 41 行交叉出的那块地面。这个固定编号的价值在于同一块地面只要 path/row 一致无论你是 2013 年拍的还是 2023 年拍的这两景影像在空间上就是同一块区域。时间序列分析、变化检测、植被指数趋势这些活儿全依赖这套稳定的空间基准。拿到 WRS2 命名的压缩包第一反应应该是去查它的 path/row 落在哪而不是先纠结 “这个编号为什么长这样”。1.2 descending 与 ascending 的实际区别descending 和 ascending 描述的是卫星在轨道上的飞行方向。Landsat 系列是太阳同步轨道卫星它在下降段——也就是由北向南飞行、太阳在观测区东侧的时候开机成像当地时间通常是上午十点左右。这个方向采集到的数据就是 descending 降轨数据。因为成像时段在白天所以降轨数据的太阳高度角相对稳定光照条件比较统一这也是 Landsat 大多数可见光影像以降轨为主的原因。反过来ascending 升轨数据是卫星由南向北飞行时获取的时间一般在夜间或轨道另一侧。对光学影像来说夜间数据几乎没有可用性所以当你看到一个数据包如果标了 ascending就要多留个心眼。它可能包含的是热红外数据也可能是某个特殊任务编排的地表参数处理思路和常规降轨数据完全不同。后面章节我会专门讲一个因为升轨降轨判断失误导致几何配准问题的例子这里先记住一个结论descending 不等于“质量好”但它代表了一类“光照条件可预期”的常规数据。2. 动手解压前我先做了三次检查2.1 压缩包完整性测试不能省r 压缩包在传递过程中损坏的概率远比你想象的高。尤其经过网盘中转、微信传输、U盘拷贝之后rar 包出现单字节错误并不罕见。如果你跳过检查直接解压到一半报错或者更糟——解压出来几个 tif 文件表面看没问题实际某个波段数据已经损坏那后面处理起来才是真正的灾难。我每次拿到这种包第一步一定是测试完整性而不是直接解压。WinRAR 和 7-Zip 都有测试功能命令行环境下更简单unrar t WRS2_descending.rar7z t WRS2_descending.rar如果包带有恢复记录.rev 文件损坏时可以尝试修复unrar r WRS2_descending.rar测试通过再解压。这一步没有技术含量但能在后面省下大量排查时间。我见过太多人跳过这一步最后处理到一半发现是数据源损坏结果前面所有流程全部重跑那一整天的效率就这么没了。2.2 磁盘空间和目录规范一景 Landsat 原始影像解压后体积通常在 700MB 到 1GB 左右如果这个包是 Level-2 地表反射率产品可能超过 1GB。而 rar 的压缩率又比较高压缩后可能只有 300-500MB所以解压后的体积大约是压缩包的 2 到 3 倍。拿到包先看一眼压缩包体积心里估一下解压后的所需空间至少留出预计体积两倍以上的剩余磁盘空间再用解压命令。同时我强烈建议从一开始就建立规范的目录结构data/ raw/ # 原始压缩包和解压后的原始文件 processed/ # 处理产物 metadata/ # 从 MTL 提取的索引信息这样做的好处是任何一步出错都能明确知道是 raw 层的问题还是 processed 层的问题不至于混淆原始数据和中间产物。这在批量处理几十景影像时尤其重要否则两三天之后你看着一屏相似的文件名根本分不清哪份是原始数据、哪份已经处理过、哪份已经做了云掩膜。2.3 跨平台解压工具的选择Windows 下用 7-Zip 或 WinRAR 都行Linux 环境我一般用 unrar 或 unar因为某些发行版自带的 unrar-free 对于部分 rar4 版本支持不完整特别是带恢复记录的分卷包在这种精简实现下可能解压失败。macOS 下可以用 The Unarchiver 或 Keka对 rar 格式兼容性都不错。还有一个容易忽略的细节是中文文件名乱码。如果压缩包内部文件名包含中文字符某些 Windows 压缩工具默认使用本地代码页编码在 Linux 下解压出来就是一堆乱码。遇到这种情况可以先用ls -la看下解压后的文件名如果发现乱码用unar或7z指定编码重新解压是相对稳妥的处理方式。虽然 Landsat 官方产品的文件名通常都是纯英文数字但第三方打包者经常在内部加上自己的中文备注这种细节在批量脚本处理时就容易突然跳出来绊你一下。3. 解压后不是直接打开影像而是先读 MTL 确认身份3.1 一个 Landsat 产品包里的文件家族解压完成后你会看到一堆文件而不是只有一个 tif。以 Collection 2 的 Level-1 产品为例一个标准的 Landsat 产品包通常包含这些成员*_MTL.txt元数据文件产品身份的核心几乎所有关键信息都在这里*_ANG.txt几何定标角文件做高精度几何处理时才需要B1_B.TIF到B11_B.TIF各波段 GeoTIFF 影像QA_PIXEL.TIF逐像元质量控制波段记录云、云阴影、雪、水体等分类信息QA_RADMET.TIF辐射测量相关的质量波段很多初学者解压后第一件事是双击打开那个真彩色的 tif 看一看这没问题但看完之后建议立刻回到 MTL 文件上。它才是整个数据包真正的大脑。3.2 MTL 里最值得看的字段们MTL.txt 是纯文本直接用编辑器打开就能看。对于一景数据我最关注这几个字段字段含义为什么重要SPACECRAFT_ID卫星编号如 LANDSAT_8决定波段设置和处理参数SENSOR_ID传感器类型如 OLI_TIRS同一个卫星不同传感器处理细节不同WRS_PATH/WRS_ROWWRS-2 网格编号用于和归档体系对应确认空间位置DATE_ACQUIRED影像采集日期时间序列分析的关键索引CLOUD_COVER整景云量百分比快速判断该场景是否值得继续处理UTM_ZONE投影区带号打开和拼接影像时必须一致读取 MTL 可以用任何文本编辑器也可以写一个简单脚本批量提取。下面这个 Python 函数是我在处理大量场景时常用的能把 MTL 里的键值对直接变成字典from pathlib import Path def read_mtl(mtl_path): vals {} text Path(mtl_path).read_text(encodingutf-8, errorsignore) for line in text.splitlines(): if in line: key, value line.split(, 1) vals[key.strip()] value.strip().strip() return vals mtl read_mtl(LC08_L1TP_122041_20200315_20200429_01_T1_MTL.txt) print(mtl[SPACECRAFT_ID], mtl[WRS_PATH], mtl[WRS_ROW], mtl[CLOUD_COVER])注意一点CLOUD_COVER是整景影像的云量估算只是一个全局统计值。如果你的研究区只占整景的一小块这个数值的参考价值就非常有限很可能整景云量只有 5%但恰好你的研究区就是那片云。所以后续还是需要用 QA 波段做局部筛查。3.3 产品标识符拆解示例文件名往往比 MTL 里的信息更浓缩。比如LC08_L1TP_122041_20200315_20200429_01_T1拆开来看LC08Landsat 8 的 OLI/TIRS 载荷L1TPLevel-1 精密地形校正产品122041WRS-2 的 path 122row 4120200315影像采集日期20200429数据处理日期01Collection 编号Collection 2 产品这里通常是 02T1版型等级T1 代表经过良好几何控制的地形校正数据看明白这套规则之后哪怕拿到一个完全陌生的 Landsat 数据包扫一眼文件名就能判断出它的卫星、处理级别、空间位置、采集时间。这比打开 GIS 软件再慢慢查要快得多也是批量筛选数据时的基本功。4. 把降轨影像接进实际处理流程的几个固定动作4.1 先统一坐标系和投影Landsat 产品默认输出的坐标系是 UTM 投影具体区带号在 MTL 里已经有记录。但这里有一个新手几乎必犯的误区WRS-2 里的 path/row 编号和 UTM 区带号没有一一对应关系。path 是卫星轨道轨迹编号UTM zone 是地图投影分带两套体系不能混用。看到WRS_PATH 122不要想着“那 UTM zone 是不是 122”UTM zone 只到 60这种换算根本不存在。在 QGIS 或 ArcGIS 里打开影像后先检查工程文件的投影设置是否与影像本身的 UTM zone 一致。如果批量处理多个不同 zone 的场景建议先把所有影像统一重投影到一个共同坐标系或者使用合适的拼接策略否则后面做镶嵌和切片时会因为投影不一致出现莫名的接边位置偏移。4.2 波段选择与合成影像Landsat 8/9 的 OLI 传感器共有 9 个波段加上 TIRS 两个热红外波段波段数量不少每个波段都有不同用途。最常用的几个波段类型波长范围约地面分辨率典型用途B2蓝0.45-0.5130m真彩色合成B3绿0.53-0.5930m真彩色合成B4红0.64-0.6730m植被、真彩色B5近红外0.85-0.8830mNDVI、假彩色B6短波红外11.57-1.6530m干旱监测、岩性识别B7短波红外22.11-2.2930m矿物信息、云雪区分B8全色0.50-0.6815m全色锐化做真彩色合成时用 B4-B3-B2 三个波段按 RGB 顺序组合想突出植被信息时用 B5-B4-B3 假彩色组合植被在这种组合下会呈现明显的红色调。QGIS 里直接用波段合成工具加载即可命令行方式用 GDAL 也很方便gdalbuildvrt -separate rgb.vrt B4_B.TIF B3_B.TIF B2_B.TIF我这里只列了最常用的几个波段如果做地表温度研究还需要用到 B10 和 B11 热红外波段做气溶胶或水色研究才需要 B1 海岸波段。波段选择不是越多越好而是根据研究目标来决定盲目的“全波段下载、全波段处理”会白白浪费磁盘和算力。4.3 QA 波段与初步云量筛查MTL 里的CLOUD_COVER只是全局粗略估计。真正逐像元判断有没有云要用QA_PIXEL波段。这个波段每个像素的数值不是简单的灰度值而是按位编码的位元信息。一个常见做法是把 QA_PIXEL 的二进制位解析出来判断某个像素是否被云覆盖。以 USGS 的位定义文档为准其中 bit 3 通常用于标识云像素。用 Python 检查某像素是否为云写法大致是import rasterio import numpy as np with rasterio.open(..._QA_PIXEL.TIF) as src: qa src.read(1) cloud_mask (qa (1 3)) ! 0这个cloud_mask就可以用来做后续的云掩膜或者在统计区域均值时排除云像素。这里务必注意不同 Collection 版本的位定义可能略有调整使用前先看对应版本的文档不要拿着旧版的说明硬套新数据。5. 处理这些数据包时我踩过的坑和现在的习惯5.1 升轨、降轨对应错位导致的几何问题有一回我处理一个第三方数据源发来的数据集文件夹里既有 descending 也有 ascending 的数据文件名标注得很清楚但我当时没有留意到升轨数据的存在直接把它们按同一批规则做了几何配准。结果到了后续叠加分析阶段发现一部分影像的方位角和其他影像对不上检查太阳方位角和传感器方位角才发现升轨数据被混进来了。升轨和降轨数据在太阳方位角、观测方位角上的差异是系统性的不同轨道方向的数据混用在地形阴影校正、BRDF 修正等环节会产生明显误差。现在我在批量处理之前一定会先按文件名里的 descending/ascending 字段把数据分成两个分组分别建立批次绝不混在一个流水线里。5.2 嵌套压缩和目录深坑第三方打包的数据经常出现“压缩包里还有一个同名文件夹文件夹里又套了一层压缩包”的结构。我第一次处理 WRS2_descending.rar 时也遇到了解压后第一层是一个文件夹进去之后又是一个文件夹再往下一层才看到 MTL 和 tif 文件。这种嵌套本身不复杂但在写批量处理脚本时必须意识到路径深度不固定不能写死raw/影像目录/*_MTL.txt这样的路径。我现在习惯用glob(**/*_MTL.txt, recursiveTrue)这种递归搜索方式或者先把所有数据整理平铺到统一的目录里再处理避免嵌套深度变化导致脚本意外中断。5.3 改名的后果与我的命名习惯如果你习惯把下载的数据按自己的方式重命名比如把LC08_L1TP_122041_20200315_20200429_01_T1改成Landsat8_20200315_tile1短期内可能觉得很清晰但时间一长尤其是当你需要回溯某个结果到底来自哪景影像时丢失原始产品标识符会非常痛苦。因为很多元数据平台和数据说明文档只认官方产品 ID一旦文件夹里只剩下你自己的“好记名字”溯源就断了。我现在的做法是解压后保留原始文件名原封不动额外建立一个索引文件里面记录“我的编号”和“官方产品 ID”的映射关系。这样既方便记忆又不丢失原始溯源信息。如果你处理的数据量很大建议从 MTL 里自动提取信息生成一个索引表归档一个场景就登记一行半年后你会感谢当时的自己。5.4 WRS-1 和 WRS-2 不要混用处理早期 MSS 数据时要注意Landsat 1 到 3 时代用的是 WRS-1 网格它的 path/row 划分边界和 WRS-2 并不相同。如果你从老资料里查到某个研究区的 path/row然后直接拿这个编号去 Landsat 8 的数据目录里搜很可能搜到的是完全不同的区域。现在主流分发平台一般都会标注 WRS-2但遇到几十年前的历史文献一定要先确认对方引用的是哪套网格体系否则数据检索这一步就会跑偏。最后说一个我自己一直在坚持的细节不管从哪个渠道拿到这种 rar 包我会先给压缩包本身计算并记录一份 SHA256 校验值解压后再对关键文件做一次大小和时间的范围检查。单机单项目的时候这步显得有点多余但数据一多、时间一长这份记录能在你追查数据源问题时省下大量时间。数据处理的每一步都会追溯文件名和压缩包的完整性就是这条链上的第一环。本文还有配套的精品资源点击获取