简介：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 到 3，WRS-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_ROW | WRS-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(encoding="utf-8", errors="ignore") 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拆开来看：
LC08：Landsat 8 的 OLI/TIRS 载荷L1TP：Level-1 精密地形校正产品122041：WRS-2 的 path 122，row 4120200315：影像采集日期20200429：数据处理日期01：Collection 编号（Collection 2 产品这里通常是 02）T1：版型等级，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.51 | 30m | 真彩色合成 |
| B3 | 绿 | 0.53-0.59 | 30m | 真彩色合成 |
| B4 | 红 | 0.64-0.67 | 30m | 植被、真彩色 |
| B5 | 近红外 | 0.85-0.88 | 30m | NDVI、假彩色 |
| B6 | 短波红外1 | 1.57-1.65 | 30m | 干旱监测、岩性识别 |
| B7 | 短波红外2 | 2.11-2.29 | 30m | 矿物信息、云雪区分 |
| B8 | 全色 | 0.50-0.68 | 15m | 全色锐化 |
做真彩色合成时用 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", recursive=True)这种递归搜索方式，或者先把所有数据整理平铺到统一的目录里再处理，避免嵌套深度变化导致脚本意外中断。
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 校验值，解压后再对关键文件做一次大小和时间的范围检查。单机单项目的时候这步显得有点多余，但数据一多、时间一长，这份记录能在你追查数据源问题时省下大量时间。数据处理的每一步都会追溯，文件名和压缩包的完整性，就是这条链上的第一环。
本文还有配套的精品资源，点击获取
