简介这是一份基于WRS-2全球参考系统的Landsat TM影像下行轨道矢量数据面向遥感与地理信息科学的学习者和工程师方便快速获取卫星下降轨道对应区域的土地覆盖信息。压缩包内共包含九个文件以Shapefile标准格式组织分别承担几何要素、属性记录、空间索引、投影坐标及元数据说明等不同功能整个资源包大小仅3.45MB。目前已有235人下载学习该数据包适合初阶与中阶用户上手实践。数据将TM传感器提供的多光谱波段与地理坐标绑定解压后可直接放入ArcGIS、QGIS等软件打开用于地物识别、土地利用分类、植被长势分析等典型任务。对刚接触遥感数据组织的初学者该压缩包还提供了完整的Shapefile文件构成样例可借此理解WRS-2分幅规则及各辅助文件的具体作用。1. WRS2_descending.rar 是什么遥感分幅查询里最常被跳过的那张底图拿到 WRS2_descending.rar 的人多半会把它当成一个普通矢量压缩包解压、打开、看一眼图层就放着吃灰。其实这个包一旦用对能把“这个坐标属于哪个 Path/Row”的查询时间从分钟级压到秒级。它装的是 WRS-2全球参考系统第二版的降轨分幅网格几乎覆盖全球陆地对应 Landsat 这类极轨卫星白天由北向南过境时的标准轨道编号。凡是做影像自动化检索、任务规划、大范围覆盖统计的人都该把它放进自己的底图工具箱。真正让它值钱的不是那张能画出来的网格图而是把经纬度与 Path/Row 在本地彻底打通的那套处理流程本文就按这个流程展开。2. WRS-2 分幅系统底层逻辑为什么 descending 方向是 Landsat 工作流的默认选项2.1 Path/Row 机制233 条轨道与行号的编排逻辑WRS-2 的核心思想并不复杂把一颗太阳同步轨道卫星的重复周期拆成一套标准网格。网格的东西方向用 Path路径编号南北方向用 Row行编号两者组合成一个唯一值用来指代某一景影像的“格子”。极轨卫星在约 16 天的回归周期里把地球表面遍历一遍每条地面轨迹按时间顺序编号这就是 Path 1 到 Path 233 的来源。Row 则是沿轨道方向按纬度切出来的行多数资料里写的是 248 行但不同分发版本对极区边缘的处理略有差异。我第一次查 WRS-2 路径编号规则时也绕了弯路。网上口径不一有些说路径从东到西排有些说从西到东排其实把矢量多边形加载进来一看就明白编号是按轨道经过次序递增的而不是按经度大小排列。日常使用里你基本不需要手工推算编号只要让空间索引直接告诉你答案。但有两个数字最好记在心里Path 总数 233单景跨度约 185km 乘 180km。这两个值直接决定了后续判断“一个点会不会落到两个景里”以及“一个区域最少要覆盖几景”。另一个容易忽略的细节是 WRS-2 网格里的多边形并非标准矩形。因为卫星轨道有倾角地球在成像的同时也在自转所以每一景的实际地面轮廓是一个倾斜的平行四边形部分版本里还带弧边。这意味着你不能用简单的经纬度加减法去判断点在不在景内必须老老实实做多边形空间关系运算。理解了这一点你也就理解了为什么一个几百 KB 的矢量压缩包能比一堆在线查询页面可靠得多。2.2 为什么 descending 是白天的默认主力Descending 指的是卫星从北向南飞行的过境段也就是入轨段成像。对 Landsat 这类太阳同步轨道卫星来说descending 过境时间通常落在当地上午 10 点到 11 点之间。这个时间段太阳高度角适中地物阴影短地表反射特征稳定是光学遥感最舒服的观测窗口。所以你看到的绝大多数光学影像底图、做地表覆盖分类的训练样本、以及批量下载的 L1 级数据都来自 descending 轨道。选它是业务惯性更是物理条件决定的。相比之下ascending 方向是卫星从南往北飞过境时间在夜间可见光通道基本拿不到有效信号只有热红外或其他对光照不敏感的传感器才会优先考虑。如果某个数据源里的场景编号看起来正确但成像时刻和太阳高度对不上先怀疑是不是方向选错了。对比项descending 降轨ascending 升轨飞行方向北向南南向北过境时间当地上午当地夜间光照条件太阳高度角适中无有效可见光主要用户光学/多光谱业务热红外/夜间遥感数据量占比绝大多数少量这样一来WRS2_descending.rar 这个名字本身就等于一层筛选条件它已经替你框定了“白天、光学、标准网格”这个子集。后边所有处理都围绕 descending 展开千万别拿成同名 ascending 版本。2.3 压缩包内部通常是什么文件清单与字段体检先讲最常见的包内结构。一整套 Shapefile 至少由 .shp几何、.shx空间索引、.dbf属性表三个文件组成规范分发时还会带 .prj坐标系描述和 .cpg字符集描述。如果少了其中一个后边的工程就会出现坐标系错乱、属性读不出来、字段乱码这类问题。拿到压缩包的第一件事不是直接解压到工作目录而是先看清单# 基于 Debian/Ubuntu 的系统先装 unrar sudo apt update sudo apt install -y unrar # 只列出压缩内容不实际解压先做“体检” unrar l WRS2_descending.rarunrar l 的输出能看到文件名、体积和压缩路径。如果列出的文件只有 WRS2_descending.shp 而没有对应的 .dbf 和 .shx就要提高警惕这个包多半是别人从 GIS 里只导出了几何、没带属性表。没有 .dbf 的矢量还能画图但查不到 Path/Row等于废包。.prj 缺失则更隐蔽在 QGIS 里打开会显示在海里或非洲西海岸附近后面第 5 章会专门讲。完整的 WRS-2 降轨矢量解压后属性表里通常会有类似下面的字段命名可能略有差异但语义基本一致常见字段含义使用注意PATH路径编号1~233整型输出别丢前导零ROW行编号1~248整型不同版本极区有差异PRPATH 与 ROW 拼接值建议拆开或补零后再用SCENE_ID景标识字符串仅用于核对不做关联键拿到字段清单后心里要有个数这个包到底是“官方完整版”还是“别人整理过的简约版”。有些精简版为了减小体积把边界做了抽稀多边形顶点少画起来很干净但做空间查询时边界偏差可能达到百米级。对大多数点查场景影响不大对精确覆盖分析就不够用了。我一般优先保留原始版抽稀版只用于预览和示意图。3. 解压 WRS2_descending.rar 并整理成 GeoJSON从压缩包到可查询底图3.1 解压前先摸底unrar 列目录与加密包识别.rar 格式和 .zip 不一样Python 标准库的 zipfile 处理不了它必须依赖外部解压工具。我的习惯是先用 unrar 做两步操作先列内容再解压。列内容的目的是确认包内文件齐全也顺便看有没有加密标志。如果压缩包带密码unrar l 时输出行里会有明显标记解压时也会提示输入密码或直接报错。工作中遇到加密的分幅包我一般直接放弃因为没办法验证数据来源是否可靠为一个小矢量包去猜密码不值得。# 解压到工作目录保留包内目录结构 unrar x WRS2_descending.rar -d wrs2_data/ # 确认四个核心文件是否齐全 ls -l wrs2_data/实际输出应该能看到至少四个文件.shp、.shx、.dbf、.prj。如果只看到 .shp 和 .dbf说明 .prj 可能丢了如果连 .dbf 都没有那这个包基本只能当背景图用做不了属性查询。这里多说一句unrar 的 x 参数会保持压缩包内的目录结构不会把文件全部摊平这对后续处理反而更好能避免同名文件互相覆盖。3.2 用 Python 做内容体检坐标系、字段、重复要素解压完成后不要急着导入 GIS先用 Python 做一次快速体检。GeoPandas 读取 Shapefile 只需要一行重点看三个信息坐标系、字段列表、要素数量。import geopandas as gpd # 读取降轨分幅矢量 gdf gpd.read_file(wrs2_data/WRS2_descending.shp) # 三个最重要的体检项 # 1. 坐标系是否为 WGS84 或某投影带 print(坐标系:, gdf.crs) # 2. 字段是否有 PATH / ROW print(字段:, gdf.columns.tolist()) # 3. 要素数量是否和预期一致一般应有两千多个景多边形 print(要素数:, len(gdf)) # 检查是否有同一 PATH/ROW 重复出现的要素 print(gdf.groupby([PATH, ROW]).size().head(10))如果 crs 打印出来是 None说明 .prj 文件缺失这时的几何坐标可能是投影坐标也可能是经纬度完全靠猜后边所有空间匹配都不可信。如果字段列表里没有 PATH 和 ROW而是只有一个 PR也别慌后边可以拆。要素数量能给你一个粗筛依据WRS-2 全球覆盖的分幅通常有两千多个多边形如果只有几百个大概率是裁剪过局部区域的版本只适用于小范围项目不能拿去做全球任务规划。3.3 统一坐标系并导出 GeoJSON绕开 Shapefile 的三个老毛病Shapefile 在工程里有两个先天不足字段名最长 10 个字符超了会被截断属性表对日期和特殊字符支持差。GeoJSON 没有这些限制字段名可以写得很清楚还能直接在 Web 地图工具里用。所以我的习惯是把 WRS2_descending 整理成一份标准化 GeoJSON作为后续所有脚本的统一输入。# 统一到 WGS84 经纬度坐标方便与任意来源的坐标点做空间连接 gdf_wgs gdf.to_crs(EPSG:4326) # 顺手把属性字段精简一下只留有用字段 gdf_wgs gdf_wgs[[PATH, ROW, geometry]] # 导出为 GeoJSON解决 Shapefile 字段名截断和编码问题 gdf_wgs.to_file(wrs2_descending.geojson, driverGeoJSON)这里有两个操作容易被忽略。第一to_crs(EPSG:4326) 必须执行哪怕原数据已经是经纬度执行一次也没坏处至少能保证后续 join 时不会因为坐标系不一致翻车。第二字段精简后文件更小匹配时内存占用也更低。如果包里的 PATH/ROW 列名是大写导出后会原样保留后续代码里别写错大小写。GeoJSON 导出后的文件可以直接拖进 QGIS、Figma 或者各种 Web 地图框架查看。到这一步你已经把原始的 rar 压缩包变成了一份干净的、可查询的底图文件。下一步就是拿它来做真正的坐标匹配。4. 用 WRS2_descending 做坐标匹配经纬度批量反查 Path/Row 的落地脚本4.1 为什么不用经纬度公式直接算而是做空间连接有人可能会问Path/Row 是不是能用经纬度直接算理论上可以但工程上不建议。WRS-2 网格的边界线是倾斜的行号与纬度的关系不是线性映射还要考虑参考椭球和轨道参数。即使你能背下公式边界上的点也极易因为四舍五入产生误差。与其重复造轮子不如直接依赖多边形空间关系点落在哪个多边形内部它就属于哪个景。GeoPandas 的 sjoin 底层自带空间索引几十万个点匹配两千多个多边形耗时通常是秒级完全没有性能压力。4.2 单点匹配先验证底图数据正确性在跑批量之前我习惯先拿一个已知坐标的示例点做单点验证。比如取东经 116.4、北纬 39.9 附近的某个点先用 Point 构造几何再用 contains 判断归属。from shapely.geometry import Point import geopandas as gpd # 读取之前导出的标准底图 wrs gpd.read_file(wrs2_descending.geojson) # 构造一个测试点 test_point Point(116.4, 39.9) # 找出包含该点的所有分幅多边形 hits wrs[wrs.geometry.contains(test_point)] if len(hits) 0: print(hits[[PATH, ROW]].to_dict(records)) else: print(无命中先检查坐标系是否一致)这段代码的关键参数是坐标系一致性。wrs 已经统一到 EPSG:4326而 test_point 默认也是经纬度坐标所以匹配才能成立。如果 test_point 是经过投影转换的坐标比如 UTM 坐标必须先把坐标点转成经纬度否则结果为空是必然的。单点验证通过后再进批量能省掉大量排查时间。4.3 批量匹配十万个坐标点的 sjoin 写法批量场景下数据通常是 CSV 或 GeoJSON 格式的坐标点集合。先把点表读成 GeoDataFrame再与分幅底图做 sjoin一次性输出每个点对应的 PATH 和 ROW。import geopandas as gpd wrs gpd.read_file(wrs2_descending.geojson) points gpd.read_file(task_points.geojson) # 两边统一坐标系以底图坐标系为准 if points.crs ! wrs.crs: points points.to_crs(wrs.crs) # howleft 保留未命中的点predicatewithin 表示点在多边形内部 matched gpd.sjoin(points, wrs, howleft, predicatewithin) # 只输出需要的列 matched[[id, PATH, ROW]].to_csv(matched_result.csv, indexFalse)参数说明howleft 是以点表为主表没有命中的行 PATH/ROW 会是 NaN这样后续能统计出哪些点不在任何 WRS-2 景范围内比如岛屿或高纬度边缘区域。predicatewithin 表示点在多边形内部才匹配如果点位正好落在边界线上可能被漏掉。针对这种情况我一般会先对点做极小的 buffer或者改用 predicateintersects代价是边界上的点可能匹配出两三个结果需要额外去重。性能方面sjoin 内部用的是 R-tree 空间索引十万级点对两千多边形的匹配通常在数秒到十几秒之间。如果你的点表达到百万级建议分批读取和匹配每批十万条最后 concat 结果避免内存占用过高。另外一个参数值得留意sjoin 结果里如果出现一个点对应多行的记录说明点落在了相邻景的重叠区域这是 WRS-2 网格的正常现象去重策略见下一章。4.4 结果校验抽样对比真实条带号脚本跑完不等于结果正确。我每次都会随机抽 20 个匹配记录找一两个有代表性的点与在线分幅查询结果做人工比对。重点看两点一是 PATH 是否一致二是 ROW 是否一致。如果 PATH 对但 ROW 差一两个数字多半是底图行编号与查询服务用的版本不同需要确认你这份 WRS2_descending 的版本来源。如果 PATH 都不对那基本可以断定点位坐标系或底图本身出了问题直接回查 crs。校验这一步看似费时间实际上是整个流程里最值的投资。因为你一旦把底图版本确认下来后续几千几万个点的匹配结果就都可信了。跳过校验直接全量跑最后返工的成本远高于现在花掉的十分钟。5. WRS2_descending.rar 使用避坑指南五个让我返工到深夜的细节5.1 坐标明明在陆地上却查不到任何 Path/Row现象sjoin 之后结果里全是 NaN连一个命中都没有。点表坐标看起来完全正常经纬度也对。原因大概率是坐标系不一致。最常见的情况是分幅底图的坐标是投影坐标系比如 UTM 或兰勃特等面积投影而点表是 EPSG:4326 经纬度。两者不统一时点在多边形空间里实际落在完全错误的位置自然无命中。还有一种隐蔽情况点表的经纬度被错误地当作投影坐标读取导致数值量级差了十万八千里。解决匹配前统一坐标系没有例外。用points.to_crs(wrs.crs)把点表转到底图坐标系再做 sjoin。如果转换后仍然无命中检查底图本身的 crs 是否为 None如果是先把底图投影关系确认清楚再谈匹配。5.2 一个点匹配出两个 Path/Row现象sjoin 返回结果里某个点出现了两行分别对应不同的 PATH 或 ROW。第一反应是数据出错了。原因不是错误。WRS-2 相邻景之间本来就有小幅重叠尤其是在相邻 Path 的跨轨方向。另外使用 predicateintersects 时边界线上点也容易同时命中两个相邻多边形。这是空间数据的正常特征不处理才会真正影响结果。解决对重叠命中的点按“该点多边形质心距离最近”的原则去重。处理逻辑是先给每个点一个唯一 pidsjoin 后按 pid 分组在组内计算点到多边形质心的距离保留距离最小的那条记录。# 先给点表加唯一标识 points[pid] range(len(points)) # 构造 pid - 点几何 的字典用于距离计算 point_geom dict(zip(points[pid], points.geometry)) # 与底图做 inner 连接只保留有命中的行 matched gpd.sjoin(points, wrs, howinner, predicatewithin) # 计算每个命中记录中点到该景多边形质心的距离 matched[dist] matched.apply( lambda r: point_geom[r[pid]].distance(r.geometry.centroid), axis1 ) # 同一个 pid 只保留质心距离最近的一行 dedup matched.sort_values(dist).groupby(pid).head(1)这段代码有两个地方值得说明。第一r.geometry.centroid 拿到的是分幅多边形的质心不是实际影像中心但对去重足够有效。第二sort_values(dist).groupby(pid).head(1) 的组合实现了组内排序后取第一条是整个去重的核心比 groupby 后 apply 更直观。若你的点表里没有 pid 字段记得在 sjoin 之前加上否则去重时无法区分重复行。5.3 ROW 编号前导零被吃掉导致和场景号对不上现象匹配结果是 PATH123、ROW3而你在数据目录里看到的场景编号是 003怎么都匹配不上。原因Shapefile 的 .dbf 属性表里路径号能精确对应。6. 进阶技巧把 WRS-2 降轨边界栅格化成覆盖掩膜做区域任务统筹6. 进阶技巧把 WRS-2 降轨边界栅格化成覆盖掩膜做区域任务统筹6.1 用 rasterio 把多边形权重赋给每个像元前面几章解决的是“点与景”的关系进阶一点的问题是“一块区域到底被哪些景覆盖覆盖完整度如何”。这种需求用矢量多边形逐个点查效率太低更好的办法是把 WRS-2 降轨边界栅格化成一张掩膜图。掩膜图的每个像元值代表该位置是否落在某个分幅景内后续做区域统计时可以按像元求和几秒钟就能算出覆盖面。import rasterio from rasterio.features import rasterize # 读取一景已有影像作为参考基准确保掩膜与影像严格对齐 with rasterio.open(scene_2023.tif) as ref: mask rasterize( [(geom, 1) for geom in wrs.geometry], out_shape(ref.height, ref.width), transformref.transform, fill0, dtypeuint8, ) with rasterio.open( wrs2_mask.tif, w, driverGTiff, heightref.height, widthref.width, count1, dtypeuint8, crsref.crs, transformref.transform, ) as dst: dst.write(mask, 1)这段代码的关键是参考影像的选择。掩膜的网格完全跟随 scene_2023.tif 的分辨率和范围所以要求这张参考影像与你要做覆盖分析的影像来自同一坐标系和同一空间范围。rasterize 默认只把多边形中心落在像元内的位置标记为 1如果你希望边界处的像元尽量保留可以加参数 all_touchedTrue代价是掩膜边界会外扩一圈。实际做任务统筹时我一般用 all_touchedTrue因为宁可多算一些边缘也不能漏掉可用的像元。掩膜生成后配合一个区域矢量就能快速统计覆盖情况。比如有一个项目区多边形把它栅格化成另一张二值图与 wrs2_mask.tif 做像元乘法然后对结果求和就能算出项目区内被 WRS-2 降轨景覆盖的像元比例。这个数字可以直接用来回答“这个区域需要几个相邻景才能拼齐”的问题比人工数多边形靠谱得多。这类覆盖分析的方法同样可以推广到其他分幅系统比如把 WRS-2 换成其他卫星的条带范围只要保持“矢量边界 栅格掩膜 像元统计”这个框架换数据源只是改一行读取路径的事。我做项目有个习惯任何分幅或 AOI 矢量到手先花十分钟检查坐标系、重复要素和字段格式再进正式流程。这十分钟看起来是浪费时间实际是后期返工最便宜的保险。栅格化这一步也是同理掩膜一旦生成后续每次都复用不用重新匹配。把底图准备做得足够干净整个任务链的稳定性就会大幅提升希望帮到你。本文还有配套的精品资源点击获取