企业官网建设流程全解析

1. RPC文件是什么：几何校正绕不开的那张“身份证”

先说个实际感受。做高分影像处理的人，应该都经历过这样的场景：从数据分发中心拿到一批高分一号或高分二号的原始影像，Level 1A级产品，打开一看，影像显示正常，但一叠加到GIS里就傻眼了——位置完全对不上，偏移几公里甚至几十公里都很正常。这个时候，RPC文件就是帮你把影像“放回”真实地理位置的钥匙。

RPC文件，全称是Rational Polynomial Coefficients，中文一般叫有理多项式系数文件。这个名字听起来学术味很重，但它的本质其实很简单：就是一组用来描述“地面点的经纬度+高程”和“影像像素坐标（行列号）”之间数学关系的系数。

为什么需要它？因为卫星在拍摄的时候，传感器是带着一定姿态角、在特定轨道位置上成像的，像元并不是“直上直下”地拍地面，而是有侧摆、有投影畸变的。要还原每个像素对应的真实地面位置，就需要知道成像时的几何关系。最严谨的做法是用卫星的轨道参数、姿态参数加上传感器模型做严密几何定位，但这套东西涉及大量星历数据，推广和使用都很麻烦。RPC模型的聪明之处，就是用一组有理多项式去“拟合”这种复杂的成像关系，精度上足够用，而且文件体积小、格式公开、通用性强。

一个标准的高分影像RPC文件，内容大概是这样的结构：

LINE_OFF: 10240.5 SAMP_OFF: 7680.5 LAT_OFF: 37.5243 LONG_OFF: 112.3187 HEIGHT_OFF: 800 LINE_SCALE: 10240.5 SAMP_SCALE: 7680.5 LAT_SCALE: 0.4521 LONG_SCALE: 0.3987 HEIGHT_SCALE: 500 LINE_NUM_COEFF: 20个系数 LINE_DEN_COEFF: 20个系数 SAMP_NUM_COEFF: 20个系数 SAMP_DEN_COEFF: 20个系数

你可能会问，这些OFF和SCALE是干嘛的？这是RPC模型的标准化方式。直接把经纬度和行列号放进多项式里算，数值量级差异太大，会带来严重的精度损失，所以RPC模型先把坐标做归一化处理：

L_n = (LAT - LAT_OFF) / LAT_SCALE P_n = (LON - LONG_OFF) / LONG_SCALE H_n = (H - HEIGHT_OFF) / HEIGHT_SCALE

这样经纬度和高程都被压到-1到1的区间内，再带入多项式计算。这也是为什么RPC文件里的四个多项式各有20个系数，它们分别负责行坐标和列坐标的计算，每个表达式都是分子分母两个多项式的比值，本质上是用有理函数去逼近传感器的成像几何关系。

高分系列影像的RPC文件，在不同级别产品里表现不一样。Level 1A级产品通常是一个独立的.rpb文件（注意后缀，有些软件识别.rpc，有些识别.rpb，内容格式是一样的），和原始TIFF放在同一个目录下。而Level 2级产品一般已经把几何校正做完了，影像自带坐标信息，不再需要RPC。所以做批处理时第一步就是搞清楚手头这批数据是什么级别的，别重复校正，也别漏掉校正。

2. 几何校正的思路与方案选型

2.1 有RPC和无RPC，校正路线完全不同

几何校正，说白了就是解决“影像上每个像元在地面上对应什么位置”的问题。高分影像的几何校正一般分两种路线：

第一种是严格几何校正，用卫星的轨道和姿态参数建立成像模型。这种精度理论上最高，但需要知道卫星的星历文件，而且不同卫星的数据格式还不一样，做批处理非常不友好。除非是做高精度定量遥感研究，一般项目不会走这条路。

第二种就是基于RPC的有理函数校正，这也是当前最主流的做法。它的输入只要原始影像加RPC文件，输出是带有地理坐标信息的正射影像或校正影像。GDAL、ENVI、PCI、ERDAS等主流软件都支持，而且RPC模型对不同卫星数据的适配性非常好，一个流程吃遍所有高分系列卫星。

还有一种情况是既没有RPC也没有严格轨道参数，那就只能用手工选地面控制点（GCP）的方式做多项式拟合校正。我试过几个项目，这种方式精度很大程度上取决于控制点的数量和分布，批处理时基本不可行，只适合单景数据应急用。

2.2 选GDAL还是选商业软件？

能做RPC几何校正的工具很多，我这个系列文章一直在强调“批处理”，所以工具选型考虑的就是能不能用代码批量跑、能不能自动化、能不能落地到生产环境。

商业软件方面，ENVI的RPC Orthorectification工具很成熟，也有Batch模式，但需要逐景配置参数，批量操作还是不够灵活。PCI和ERDAS类似，功能全面但授权成本高，而且命令行支持一般。

我最后选择的是GDAL，原因非常实际：

• 开源免费，不需要考虑授权问题
• Python绑定（osgeo.gdal）做批处理非常舒服，直接写for循环遍历
• gdalwarp命令行工具本身支持RPC校正，参数丰富且稳定
• 对大影像、大目录的处理效率很高，支持多线程
• 跨平台，Windows和Linux都能跑同一套脚本

CRITICAL：GDAL里做RPC校正，核心是把RPC参数写入影像元数据，然后调用gdalwarp时指定用RPC模型。具体来说，有两种方式：一种是用gdal_edit.py把.rpc文件内容写入TIFF的RPC元数据域；另一种是直接用GDAL API在内存中构建RPC模型。第一种更简单直接，适合批处理。

2.3 批处理设计的核心思路

批处理最忌讳的就是“一个脚本跑到底，中间看一眼都不看”。我们在设计几何校正批处理流程时，要考虑几个关键问题：

第一，数据组织。高分影像处理任务往往涉及几十甚至上百景数据，每景数据都对应一个原始TIFF和RPC文件，文件名可能是GF1_PMS1_E112.3_N37.5_20191012_L1A0000123456.tiff这种长字符串加乱码后缀结构，要靠正则去匹配RPC文件。

第二，分步执行与日志记录。不要试图一个脚本把下载、解压、校正、检查全部完成。我把流程拆成两步：第一步做预处理检查，把所有RPC文件读取出来、验证参数完整性、筛选出有效数据；第二步才真正执行校正。每一步都记录日志，方便排查。

第三，容错机制。批处理跑十几个小时，中间如果因为某一景数据的RPC文件格式异常导致整个流程中断，那损失太大了。所以脚本里要考虑异常捕获和断点续跑能力，让流程跳过坏数据，保证整体任务能跑完。

3. 实操全流程：基于GDAL的高分影像RPC批处理几何校正

3.1 环境准备与依赖安装

我的运行环境是Windows 10的WSL2下的Ubuntu 22.04，GDAL版本是3.6.2。如果你在Windows原生的Python环境里操作，推荐用conda安装gdal，能省去很多编译麻烦。

# 安装GDAL sudo apt update && sudo apt install -y gdal-bin python3-gdal # 验证版本 gdalinfo --version # 如果嫌系统包版本旧，也可以用conda装最新版 conda create -n gdal_env python=3.10 conda activate gdal_env conda install -c conda-forge gdal=3.6.2

需要说明的是，GDAL操作RPC校正时，最好有一个DEM数据提供高程信息。RPC模型本身需要高程值作为输入，如果不给DEM，默认会用RPC文件里的HEIGHT_OFF作为平均高程来算，这在平坦区域问题不大，但在山区会有明显误差。我用的高程数据是SRTM 30米的公开数据，覆盖范围广，精度对多数应用场景够用了。

3.2 单景影像校正：先把流程跑通

在做批处理之前，强烈建议先拿一景数据把单景流程彻底跑通。这样可以快速验证RPC文件是否正确、输出坐标系是否合理、重采样参数是否合适。

第一步，把RPC参数写入TIFF元数据。

gdal_edit.py -rpc "./原始影像/GF1_PMS1_E112.3_N37.5_20191012_L1A0000123456.tiff" "./RPC文件/GF1_PMS1_E112.3_N37.5_20191012_RPC.rpb"

这条命令没有显式地“写”什么，它读取RPC文件的内容，把RPC参数放进TIFF的元数据里。执行完以后可以用gdalinfo验证：

gdalinfo ./原始影像/GF1_PMS1_E112.3_N37.5_20191012_L1A0000123456.tiff

在输出的信息末尾，如果能看到类似RPC metadata:的段落，里面有LINE_OFF、SAMP_NUM_COEFF这些字段，就说明写入成功了。

第二步，调用gdalwarp做正射校正。

这里要把几个参数搞清楚。-t_srs指定输出坐标系，高分影像一般用WGS84经纬度或UTM投影。我的做法是直接用WGS84输出，因为它跨度不大时能保持简单的坐标参考。-rpc告诉gdalwarp用RPC模型来定位每个像素。-r指定重采样方法。-dstnodata把无值区域设成指定值。

gdalwarp -rpc -t_srs "EPSG:4326" -r cubic -dstnodata 0 -tr 0.00001 0.00001 -overwrite \ -dem "./DEM/SRTM_30m.tif" \ "./原始影像/GF1_PMS1_E112.3_N37.5_20191012_L1A0000123456.tiff" \ "./校正结果/GF1_PMS1_20191012_ortho.tiff"

这里解析一下关键参数的含义。-tr 0.00001 0.00001是输出分辨率，单位是度。高分一号PMS全色影像地面分辨率是2米，在纬度37度附近，0.00001度大约对应1.1米，实际使用时建议先算一下你要的分辨率对应多少度，或者直接用-tr配合-te指定输出范围。-r cubic是三次卷积重采样，画质比双线性好，但计算量大一些。

还有一个不容易注意到但很重要的参数是-refine_gcp，在做RPC校正时，GDAL会先算一个粗定位，再用影像匹配来精化RPC参数。不过它对地形起伏较大或者云量较多的影像有时会失败，所以默认我不开这个选项，等发现问题再针对处理。

第三步，验证校正结果。用gdalinfo查看输出影像的坐标系、范围和大小，然后加载到QGIS里叠加OSM底图，人工抽几个明显地物点检查对齐情况。

3.3 批量处理脚本：从单景到多景

单景跑通后，就可以把它套进批处理框架。我用Python写了一个批量校正脚本，核心逻辑是：遍历原始影像目录，找到每景影像对应的RPC文件，然后调用gdalwarp执行校正。

import os import sys import subprocess import logging from pathlib import Path # 配置日志 logging.basicConfig( level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s', handlers=[ logging.FileHandler('batch_rpc_ortho.log', encoding='utf-8'), logging.StreamHandler(sys.stdout) ] ) # 目录配置 input_dir = Path(r"./原始影像") rpc_dir = Path(r"./RPC文件") dem_path = Path(r"./DEM/SRTM_30m.tif") output_dir = Path(r"./校正结果") output_dir.mkdir(exist_ok=True) # 遍历所有TIFF文件 tiff_files = sorted(input_dir.glob("*.tiff")) + sorted(input_dir.glob("*.tif")) success_count = 0 fail_count = 0 for tiff_path in tiff_files: # 从文件名提取影像ID（这里假设文件名格式为 GF1_PMS1_*.tiff） image_id = tiff_path.stem logging.info(f"开始处理: {image_id}") # 尝试找到对应的RPC文件，支持两种常见命名方式 rpc_candidates = [ rpc_dir / f"{image_id}.rpb", rpc_dir / f"{image_id}.rpc", ] # 如果同文件名的RPC找不到，尝试模糊匹配 if not any(p.exists() for p in rpc_candidates): base_name = image_id.split('_')[0] + '_' + image_id.split('_')[1] rpc_candidates = list(rpc_dir.glob(f"{base_name}*")) rpc_path = None for p in rpc_candidates: if p.exists(): rpc_path = p break if rpc_path is None: logging.error(f"跳过{image_id}：未找到对应的RPC文件") fail_count += 1 continue # 输出文件名 output_path = output_dir / f"{image_id}_ortho.tiff" if output_path.exists(): logging.info(f"跳过{image_id}：输出文件已存在") continue # 第一步：将RPC参数写入TIFF元数据 edit_cmd = [ "gdal_edit.py", "-rpc", str(tiff_path), str(rpc_path) ] edit_result = subprocess.run(edit_cmd, capture_output=True, text=True) if edit_result.returncode != 0: logging.error(f"写入RPC失败: {image_id}, {edit_result.stderr[:300]}") fail_count += 1 continue # 第二步：执行正射校正 warp_cmd = [ "gdalwarp", "-rpc", "-t_srs", "EPSG:4326", "-r", "cubic", "-dstnodata", "0", "-tr", "0.00001", "0.00001", "-overwrite", "-dem", str(dem_path), str(tiff_path), str(output_path) ] logging.info(f"执行校正命令: {' '.join(warp_cmd)}") warp_result = subprocess.run(warp_cmd, capture_output=True, text=True) if warp_result.returncode != 0: logging.error(f"校正失败: {image_id}, {warp_result.stderr[:300]}") fail_count += 1 continue # 检查输出文件大小，排除空输出 if output_path.stat().st_size < 1024 * 100: logging.error(f"输出文件异常（可能为空）: {image_id}") output_path.unlink() fail_count += 1 continue success_count += 1 logging.info(f"完成: {image_id}") logging.info(f"全部处理完成。成功: {success_count}，失败: {fail_count}。")

写这个脚本时有几个细节值得强调。

gdal_edit.py修改TIFF元数据时，会把这景影像的RPC参数写入原始TIFF文件。如果原始文件很重要，担心被改坏，可以提前备份。更稳妥的做法是用gdal_translate生成一个新文件，把RPC元数据带过去，再对副本做校正。不过我实测GDAL写入RPC元数据很安全，不会动到影像像素数据，所以批量改原文件问题不大。

批处理脚本里我用subprocess.run调gdalwarp，而不是直接用Python的osgeo.gdal.Warp接口。原因很简单：gdalwarp命令行工具的参数行为和文档更一致，出了问题也更好查证。比如GDAL 3.x版本对RPC校正的有些细节处理会在不同版本里有调整，命令行工具反而更稳定。

输出文件命名这里，我保留了原始影像的ID加_ortho后缀。这样原始影像和校正结果能一一对应，不会混乱。实际生产中建议把结果放到单独目录，不要和原始影像混在一起，防止二次遍历时把结果当作输入。

3.4 输出质量检查

批量处理完以后，还有一个容易被忽略的环节：质量检查。几十上百景影像，如果只靠抽样看一眼可能漏掉问题。

我习惯写一个快速检查脚本，用GDAL读取每个输出文件的基础信息，自动判断几个关键指标：

from osgeo import gdal import sys gdal.UseExceptions() def check_ortho(filepath): ds = gdal.Open(filepath, gdal.GA_ReadOnly) if ds is None: return False, "无法打开文件" # 检查是否有GeoTransform信息 gt = ds.GetGeoTransform() if gt == (0.0, 1.0, 0.0, 0.0, 0.0, 1.0): return False, "GeoTransform无效" # 检查坐标系 proj = ds.GetProjection() if not proj: return False, "缺少投影信息" # 检查影像范围是否合理 width = ds.RasterXSize height = ds.RasterYSize if width < 1000 or height < 1000: return False, "影像尺寸异常" # 检查nodata值范围，粗看黑边比例 band = ds.GetRasterBand(1) nodata = band.GetNoDataValue() stats = band.ComputeStatistics(True) ds = None return True, "正常"

这个脚本的核心是用计算机自动筛选掉明显异常的影像，节省人工检查成本。但要注意，自动检查只能发现“格式级”的问题，真正的几何精度还是需要抽几景和底图叠加目视确认。

4. 常见问题与排查技巧实录

4.1 高程数据选不对，山区影像偏得离谱

我第一版脚本里没有指定DEM，GDAL默认使用RPC文件里的HEIGHT_OFF作为所有像素的统一高程。当时测试的是一批河北平原的数据，效果还行，看不出明显问题。后来换到甘肃陇南山区的高分二号数据，校正结果直接偏了快100米，和底图叠加时山体轮廓都错位了。

排查以后发现问题就出在高程假设上。RPC文件里HEIGHT_OFF是影像覆盖范围内的平均高程，而HEIGHT_SCALE是半个高程变化范围。在平原地区，高程变化不大，用一个平均高程来算所有像素的校正量误差很小。但在山区，高差可以达到几百甚至上千米，统一高程假设就会导致每个像素都带一个位置偏移。

加DEM以后误差明显下降。这里要留意DEM和影像的坐标系要一致，否则出现双重的坐标转换误差。我的做法是先把SRTM切到目标影像的范围，然后用WGS84经纬度输出，避免投影转换带来额外的精度损耗。

4.2 RPC文件找不到：命名规则混乱的坑

高分影像的RPC文件命名不是完全统一的。有的批次是GF1_PMS1_E112.3_N37.5_20191012_L1A0000123456.rpb，有的可能只有GF1_PMS1_20191012.rpb，还有的是压缩包里的名字已经做了简化。这就导致按文件名精确匹配很容易失败。

我的排查思路是两步走：先在脚本里做了模糊匹配，按卫星传感器加日期来匹配；再不行就写一个小工具，把RPC文件内容读出来，用文件里记录的经纬度范围去匹配影像的近似范围。

另外一个容易被坑的点是：有些厂家交付的RPC文件后缀是.rpc，有些是.rpb，虽然内容格式相同，但部分软件只认特定后缀。GDAL两个都认，但如果混淆了可能提示格式错误。拿到数据时建议先完整查看RPC文件内容，确认与你使用的软件要求一致。

4.3 校正后影像出现明显黑边

黑边几乎是每次几何校正都会遇到的。原因是原始影像经过旋转和重投影后，四个角会变成不规则的形状，超出原始影像范围的区域就没有像素值，默认显示为黑色。

处理方式有三种：

第一种是直接裁掉黑边。用gdalwarp加-te参数指定输出范围，这个范围的经纬度要控制好，裁完不能丢有效数据。这种方法对大部分数据有效，但如果原始影像本身有较大侧摆角，裁掉的范围会很大，丢失边缘有效信息。

第二种是保留黑边但设置-dstalpha，生成带透明通道的TIFF。这个方法适合后续做镶嵌时用，黑边部分会变成透明，不影响镶嵌效果。

第三种是不裁也不设透明，直接在后续的处理流程里用-dstnodata设置一个特殊的无值标记，比如-dstnodata 0用于只包含正值的数据。后续处理时算法层会忽略无值区域。

我个人的建议是：如果后续要做影像镶嵌，优先用-dstalpha；如果是单景分析用，直接裁掉黑边更干净。RPC校正后的黑边大小和原始影像的侧摆角有关系，侧摆角大时黑边可能占掉整景面积的10%甚至更多，所以不要一开始就把输出范围设得太大。

4.4 批处理中途意外中断

跑了50景数据，第47景的时候电脑休眠了，脚本停了，前面46景要重新跑一遍，这种经历我相信不少人都遇到过。

解决思路是让脚本具备“断点续跑”能力。我的实现方式是在脚本中遍历时先检查输出文件是否已经存在，如果存在且大小正常就直接跳过。同时用日志记录每一步的处理结果，即使脚本停了，重跑时它也能跳过已经完成的影像。

还有一个细节：gdalwarp如果输出文件已经存在，默认会报错而不是覆盖，所以脚本里加了-overwrite参数。但加了-overwrite以后，一旦某景的校正命令中途被Ctrl+C中断，很可能会留下一个半截的输出文件，下次重跑时会认为该文件已存在而跳过。为了避免这种情况，我通常建议先检查输出文件的大小是否达到预期，比如一个2米分辨率的PMS全色波段，输出一般不会低于50MB，如果小于某个阈值就删除，说明处理不完整。

4.5 检查完才发现精度不够：RPC校正的极限在哪

GDAL用RPC校正后的定位精度，在高分二号这类卫星的数据上，平原地带无地面控制点时大多能控制在15~30米的水平。这个精度对很多应用够了，但如果你做的是需要精确到亚像元级的工程测量，那就需要加入地面控制点做进一步精化。

GDAL的gdalwarp有一个-refine_gcp选项，可以在校正过程中用一定数量的GCP对RPC模型做残差最小化优化。但它在自动匹配GCP时对影像质量要求比较高，云多或者地物纹理单一的区域容易匹配出错误点，精度不升反降。

如果确实需要高精度几何校正，我建议换个思路：用ENVI的Orthorectification模块，手动选点，再做局部区域平差。这个流程就不能完全自动化了，批处理的效率会大幅下降。所以关键还是要明确项目的精度需求，不要盲目追求高精度而牺牲效率。

根据我的经验，用GDAL处理高分影像的RPC校正，核心逻辑非常清晰：准备好RPC、准备好DEM、选好重采样方式，剩下的就是批处理遍历的事了，最费时间的是排查各种异常数据和参数调优。这里再分享一个小技巧，如果你的原始影像文件名特别长（高分卫星的L1A产品文件名经常达到60个字符以上），在Windows系统上做批处理时要注意输出路径是否超过260字符的限制，一旦超限gdalwarp会报文件无法创建。解决办法是把输出目录设得短一些，或者映射到一个短路径目录下。

回看这个系列的上一回，我们把影像预处理中的辐射定标和大气校正流程走通了，这一回补充了RPC几何校正的整套处理方案。前后衔接起来，高分影像的批处理链条基本上贯通了。剩下最耗精力的往往不是算法选型，而是数据质量问题。每一景影像的成像条件都不同，不能指望一套参数打天下，在批处理过程中留出检查、干预、修复的接口，远比写一个“一键全自动”的脚本更靠谱。