企业官网建设流程全解析

干过InSAR的人都知道，拿到一景Sentinel-1 SLC数据那一刻，真正的工作才刚刚开始。多数新手打开SNAP，把SLC文件拖进Product Explorer，屏幕上一片灰白，连地物轮廓都看不出来——当场就怀疑自己是不是数据下错了。其实SLC本来就是这个脾气，它保存的是一组组复数，振幅和相位混在一起，不像GRD那样开箱就是一张像样的雷达强度图。

这篇就围绕Sentinel-1 SLC数据在SNAP里的预处理全流程展开，把每一步的操作动机、参数设置和常见坑位讲透。内容面向正在做InSAR、D-InSAR、时序形变测量，或者只是被导师丢了一句话“你先把数据预处理了”的新手。读完你不仅能跑通流程，还能理解为什么要做TOPSAR Split、为什么要Deburst、为什么干涉之前必须先配准——这些“为什么”才是避坑的关键。

1. 为什么偏偏要拿SLC开头：SLC和GRD，差的不是分辨率，是相位

1.1 SLC不只是“更高清的GRD”

很多从光学遥感转过来的朋友有个直觉：SLC（Single Look Complex）和GRD（Ground Range Detected）的区别，无非是一个清晰一个模糊。这个理解会害死你。

GRD产品是经过多视处理、热噪声去除、辐射定标后的强度数据，每个像素只有一个代表后向散射强度的实数。你拿它做分类、做变化检测、做洪水淹没分析都没问题，因为它直观、好用、文件也不大。但它把相位信息彻底丢掉了。

SLC保存的是每个像素的复数回波信号，即实部加虚部，或者等效地表示为振幅和相位。振幅就是你熟悉的“亮度”，相位则记录了雷达波从卫星到地物再返回的精确路径长度，精度可以达到波长的几分之一。Sentinel-1是C波段雷达，波长约5.6厘米，这意味着相位信息对地面毫米级到厘米级的形变都是敏感的。

你如果只是把SLC显示成强度图（SNAP里选中Intensity或Amplitude波段），那它跟GRD看起来确实差不多，甚至更“脏”。但SLC的真正价值在相位，而这东西在GRD里已经不存在了。干涉测量的基本原理，就是拿两景不同时刻的SLC做共轭相乘，用相位差反演两次观测期间地表的位移。没有SLC，这一步根本无从谈起。

1.2 SLC预处理的最终目标：为干涉测量供数

那么“预处理”到底要处理到什么程度才算完？

不同任务差得挺远。如果是做常规的地表形变监测或者地震同震形变场反演，预处理的目标通常是输出一景合格的干涉图，也就是把主影像和辅影像配准、干涉、去地平效应之后的产品。如果你的目标是生成数字高程模型或者做更复杂的时序分析，那还要继续往下走，比如相位解缠、地理编码、SBAS或PS-InSAR流程。但无论如何，SNAP里的SLC预处理流水线是共同的：轨道校正、TOPSAR Split、Deburst、配准、干涉。

我用一个比喻帮新手建立整体概念：GRD相当于直接把拍出来的照片打印出来；SLC相当于保留原始底片（其实更准确的说法是保留了全部波形记录），而预处理就是“显影、裁剪、拼接底片”，干涉则是“拿两张底片叠在一起看差异”。你先把底片处理好，后面才能放大、测量、出图。

SLC的代价也很明显。一景IW模式SLC数据大约4到6GB，包含了3个幅宽接近的子带（subswath），每个子带又由一系列burst组成。这种极其冗余的存储结构是干涉测量必需的，但对计算机性能和磁盘空间都不太友好。所以预处理的另一个目标，就是尽可能把不关心的区域裁掉，只留下研究区对应的那部分数据，并且把离散的burst拼接成连续的影像。

2. 开工前先武装三轮：环境、轨道数据与产品结构

2.1 SNAP版本和内存分配：8GB是及格线

SNAP从7.0到9.0、10.0我都用过，目前稳定跑8.0以上版本基本没问题，但我建议直接装最新的稳定版，毕竟S1数据的更新偶尔会带来兼容性问题。安装完之后，第一件事不是急着打开数据，而是去改内存配置。

默认的SNAP堆内存很小，我记得6.x时代默认值连2GB都不到，拿这个跑SLC处理，跑到TOPSAR Split就给你脸色看。处理一景完整的IW模式SLC，8GB内存只是及格线，16GB会舒服很多。

具体修改方式：找到SNAP安装目录下的etc/snap.conf文件，打开后找到java.xmx这一项，把值改大：

<entry key="java.xmx">8g</entry>

注意这里没有任何单位后缀问题，8g就代表8GB。改完需要重启SNAP才生效。如果你习惯用命令行批处理，后面会再提到用gpt -J-Xmx8G这种方式临时指定。

另外提醒一句：如果你的电脑是32位Java，赶紧换成64位，否则堆内存一调大就启动失败。很多人改了snap.conf没生效，十有八九是Java位数不对。

2.2 哨兵1轨道数据去哪找、怎么选

预处理第一步要应用精确轨道文件，而这个东西很多新手压根没准备。SLC产品本身带一个初步轨道（基于预报星历），精度大概在10米量级，做干涉时不够用。轨道误差会直接转化为干涉图里的条纹误差，特别是在长基线情况下尤其明显，所以必须用精轨数据替换掉初始轨道。

Sentinel-1的轨道数据分两类：

• RESORB（快速轨道）：也叫Restituted Orbit，数据获取后几小时到一天内发布，精度约10厘米，适合处理近期数据。
• POEORB（精确轨道）：数据获取后大约21天发布，精度约5厘米，是干涉处理的首选。

下载途径有很多，我自己常用的是ESA的Sentinel-1 QC平台、Copernicus Data Space Ecosystem和ASF Vertex。检索方式很简单，输入卫星编号（Sentinel-1A或1B）、日期范围、数据类型（POEORB或RESORB），下载对应的.EOF文件即可。文件名里带有明确的起止时间，要和你的数据获取时间匹配。

下载好之后，把.EOF文件放到一个固定目录里。在SNAP的Preferences里可以设置轨道数据自动下载目录，让SNAP自己联网去拉。我更推荐手动下载，原因后面在避坑部分会细说——自动下载在网络状况差的时候会卡死整个界面。

2.3 认识一景SLC的文件夹结构

拿到SLC原始数据，解压后是一个.SAFE文件夹（现在也有.zip压缩包，SNAP能直接读）。里面几个关键部分有必要先认一遍：

• manifest.safe：产品清单，记录了数据格式、波段信息、轨道状态等元数据。SNAP打开产品时首先读的就是它。
• annotation/：每个子带每个极化的注释文件，XML格式，里面有空基线的几何参数，配准和干涉时会用到。
• measurement/：实际测量数据，是SLC的复数影像文件，通常用TIFF或者类似格式存储，一个文件对应一个子带的一个极化。
• preview/：快速预览图，就是那个你能直接看出地物轮廓的缩略图。

打开产品后，在SNAP的Product Explorer里展开Bands，你会看到类似Amplitude_IW1_VV、Intensity_IW2_VH这样的命名。带Amplitude的是振幅，带Intensity的是振幅的平方，后面跟着子带和极化方式。充分理解这些命名，后面选参数时才不会懵。

3. SNAP里SLC预处理的标准流水线：轨道校正、Split、Deburst、干涉图

3.1 第一步：打开产品并确认基本信息

打开SNAP，File → Open Product，选中.SAFE文件夹或者.zip压缩包。打开之后先别急着操作，看两个地方。

一个是Product Explorer里的Metadata，确认数据模式确实是IW、分辨率是5米×20米那种SLC，而不是GRD。另一个是查看GCP列表或者轨道信息，确认产品时间、轨道号和自己任务的预期吻合。

这个“看一眼”的习惯非常有用。我有一次做了半天预处理，输出干涉图后发现条纹方向不对劲，回头一查才发现主影像和辅影像用的是同一轨道的不同帧，根本不是同一个区域的观测——如果一开始就检查产品元数据里的坐标范围和轨道号，这半小时就不会白费。

3.2 第二步：应用轨道文件（Apply Orbit File）

这一步在SNAP菜单里是Radar → Apply Orbit File。界面会显示当前加载产品的卫星平台，你需要选择轨道来源：

• 如果已经手动下载了.EOF文件，选“File”方式，把文件路径指过去。
• 如果让SNAP自己下载，选“Auto”方式，它会尝试访问轨道数据服务器。

实际执行时，SNAP会把原产品的轨道信息替换成精轨信息，输出一个新文件。这一步的输出仍然是一个SLC产品，没有任何像素级别变化，只是元数据更精确了。

有一点很容易被忽略：轨道文件必须覆盖产品数据的完整时间范围。Sentinel-1 SLC的轨道编号、数据获取时间要和.EOF文件里标注的起止时间区间匹配。如果你的数据是最近几天获取的，POEORB还没发布，那就老老实实用RESORB，不要硬等精确轨道。

应用完轨道后，可以在Metadata里检查轨道状态是不是变成“POD Precise”或“POD Restituted”，确认替换成功再继续。

3.3 第三步：TOPSAR Split：把不需要的子带和burst裁掉

这是SLC预处理里第一个真正减少计算量的步骤。Sentinel-1在IW模式下采集时，用的是一种叫TOPSAR（Terrain Observation with Progressive Scans SAR）的技术：卫星用多个子带从不同角度扫描地面，每个子带内部又沿方位向分成多个burst。这样能得到大幅宽，但代价是数据组织非常破碎——一个SLC产品里有3个子带，每个子带有9到十几个burst，加起来是几十块独立的小影像。

而你做干涉研究时，研究区往往只落在其中一个子带、连续几个burst范围内，全处理不仅慢，而且没必要。

操作上对应Radar → Sentinel-1 TOPS → TOPSAR Split。关键参数：

• Subswath：选研究区最可能覆盖的那个子带。比如我国中部地区通常在IW2或IW1，沿海某些区域可能是IW1。选错了后面出的图会发现研究区完全不在里面，所以如果拿不准，可以先在preview里对照一下地物。
• Bursts：可以通过索引指定连续的一段burst，也可以点Select All保留全部。选择的原则是宁多勿缺，稍微向外扩一两个burst，因为后期配准和滤波操作会有边缘损失。
• Polarisations：按需勾选VV、VH等。如果做常规地表形变，通常只需要VV极化；如果还需要VH的强度信息做辅助分析，一起选上就是，代价是计算量增加。

TOPSAR Split执行完，输出的产品大小会比原始数据小很多。输出里已经只包含一个子带、你选的burst、你选的极化，这对后续所有步骤都是巨大的性能提升。很多人在这一步省事直接略过，然后发现后面Deburst要处理3个子带的数据，内存和磁盘双双爆炸，这就是没理解Split的意义。

3.4 第四步：Deburst：把碎片拼成连续影像

经过Split后，数据还是“一截一截”的，每个burst是一个独立的切片，彼此有重叠区域，直接看会看到明显的接缝。在做干涉之前，需要把它们拼成一整幅连续的影像。这个操作用Radar → Sentinel-1 TOPS → Deburst。

Deburst的原理是按burst的几何位置做拼接和重采样，最终输出一个各burst无缝衔接的SLC或强度产品。操作界面很简单，主要是选极化和是否输出强度。通常在干涉流程里，我们Deburst的输入仍是SLC复数数据，为后续配准和干涉做准备。

这里有个常见认知误区：Dividing the full-swath SLC into bursts是TOPSAR数据的固有特性，而Deburst之后数据虽然看起来是连续的一景，但它仍然包含复数信息。也就是说，Deburst不会把SLC降级成GRD。你仍然保留着相位，只是拼接方式变得“像一幅正常的影像”而已。

另外，如果用的SNAP版本较老，Deburst偶尔会出现输出范围比Split设定范围大一点的情况。别慌，这是拼接时的缓冲区造成的，正常情况下不影响后续干涉。

3.5 第五步：配准与生成干涉图：预处理模块的核心交付物

到了这一步，你已经把单景SLC从“原始底片”整理成了“干净的单张底片”。但如果要做干涉，还需要第二景（辅影像）参与。配准是整个预处理里最“硬核”的一环，目标是把主影像和辅影像的每个像素精确对齐到亚像元级别。

在SNAP里，常用的是Radar → Coregistration → Coregister SLC。界面里会让你设置主影像（master）和辅影像（slave），一般情况下选择影像质量更好、轨道误差更小的一景作为主影像。配准方式选择默认的基于轨道的粗配准加基于相干性的精配准即可。Sentinel-1因为是TOPS模式，配准精度要求比ScanSAR更严格，尤其方位向必须控制在千分像元级别，否则burst间会出现相位跳变。

配准完成后，紧接着是Radar → Interferogram → Interferogram Formation。这一步是把主辅影像共轭相乘，得到干涉相位图。界面上需要设定是否生成相干图、是否进行多视处理。如果只是看预处理结果，可以先不勾选多视，输出原始干涉图。

到这一步，SLC预处理的主线流程就走完了。后面你可能会继续做滤波、相位解缠、地理编码，但那已经属于干涉后处理范畴，不再算“预处理”。下面我用一个表格把这套流程串起来：

3.6 预处理之外的延伸：后面还有哪些工序

写完上面的主线，我怕有些人直接把干涉图当最终结果拿去写报告了。这里补一句：干涉图虽然看着花里胡哨，但里面的相位是被包裹的（wrapped），取值范围在-π到π之间，而且叠着平地相位、地形相位和大气延迟。你需要继续做：

• 去平（Remove Flat Earth Phase）：消除参考椭球面引起的相位变化。
• 滤波（Filter）：比如Goldstein相位滤波，压制斑点噪声和残余噪声。
• 相位解缠（Unwrapping）：把包裹相位恢复成连续相位，这一步是形变反演的关键。
• 地理编码（Terrain Correction）：把雷达坐标系下的结果投影到经纬度坐标系。

这部分如果展开又是好几篇的篇幅，本文不再详述。治学态度是，你得知道预处理流水线为后面这些工序准备好了什么：高质量的配准SLC、干净的干涉图、以及足够的相位信息。这才是SLC预处理真正的“交付物”。

4. 我踩过的坑，提前帮你填平

4.1 坑一：轨道数据下载不出意外地卡住了

轨道数据应用这步，出问题频率最高的不是SNAP本身，而是自动下载。SNAP内置的自动下载功能看起来挺美，但在某些网络条件下会长时间转圈，甚至直接把SNAP整个卡死。

我的做法是永远手动下载。打开轨道数据网站，输入日期范围，筛选POEORB或RESORB，下载后放到D:/Sentinel1_Orbits之类的固定目录。在SNAP的Preferences里把轨道数据目录指过去，这样Apply Orbit File时SNAP能直接从本地文件夹识别，不需要联网。

还有个小细节：轨道文件要和你的数据获取年份匹配。很多人输入日期的时候写成“2023-08-15”这种产品获取日期，但其实轨道检索界面要求的也是数据获取的时间区间，逻辑一致，注意别把起止时间填反了就行。

4.2 坑二：SLC打开一片灰白，不是数据坏了

前面提到了，SLC默认显示的是复数数据模板，SNAP在做强度显示之前需要你手动选择波段。打开产品后，如果在Bands下面看到的是好几个Amplitude_IW1_VV这种，双击它就能显示振幅图，看起来和雷达强度图类似。

如果你看到一片灰白，通常是你点开了某个相位相关的复杂显示，或者没有正确选择振幅波段。解决办法：在Product Explorer里找到Band列表，双击对应的Amplitude波段，或者用Window → Image Display手动切换。如果真的什么都没显示，检查一下是不是数据本身有问题，比如解压文件不完整。

这块实在不值得浪费半小时，但因为一头雾水的朋友太多，我还是写出来。

4.3 坑三：OutOfMemory，内存溢出的众生相

处理SLC时内存不够是最常见的崩法。症状是SNAP界面卡住、进度条长时间不动，然后弹出一段Java堆内存溢出异常。

除了修改snap.conf调大堆内存，还有几个实用小经验：

• 处理前用TOPSAR Split把数据量切小，这是最立竿见影的办法。完好的完整子带不做Split硬啃，16GB内存也可能吃力。
• 关掉不用的其他应用程序，尤其浏览器里一大堆标签页占内存的那种。
• 如果是在命令行跑gpt，可以用gpt -J-Xmx8G这样的参数单独指定内存，而不是改全局配置。

另外，SNAP的临时缓存默认在系统盘，如果你的C盘空间不大，建议在Preferences里把缓存目录换到一个剩余空间充足的盘。这个很多人不知道，SNAP跑大数据时会在缓存目录生成大量临时文件，C盘满了它比啥都崩得快。

4.4 坑四：TOPSAR Split选burst的教训

Split的最大坑不在“选哪个子带”，而在“选哪些burst”。

我之前做一组时序数据，想省时间，每个子带只选了3个burst，恰好覆盖研究区中心。前几景数据都很顺，但有一景数据的中心位置因为轨道偏移，3个burst没完全包住研究区，导致后面干涉图中心区域出现一大片无效值。回头排查了半天，才发现是Split的burst选择范围不够。

所以我的建议是：研究区边缘最好留出至少2个burst的缓冲。burst在方位向上的位置会随轨道变化有轻微移动，你不留余量，就容易在某景数据上翻车。多处理几秒钟，总比后面返工舒服。

4.5 坑五：生成干涉图时主辅影像时间基线“短”到离谱是怎么回事

有朋友跑核心步骤，生成的干涉图模糊得没法看，检查之后发现主辅影像选择有问题——选了同一轨道的相邻两景甚至同一天获取的重复轨道数据，时间基线为0或者几秒，根本观测不到形变条纹。

这个不算SLC预处理独有的问题，但一定要在这里提醒：主影像和辅影像必须满足一定的时空基线条件。在SNAP里打开产品列表后，确认两景数据的获取日期、轨道方向、以及是否来自同一轨道。理想情况下选同一轨道、同一方向的相邻周期数据做干涉，或者如果需要做长时序分析，按你的需求选择合适的时间间隔。

4.6 坑六：一处理就是大半天，急性子别硬刚GUI

SLC预处理在SNAP图形界面里一步步点，一景数据跑完可能要好几个小时。如果你有十几景甚至几十景数据要处理，手动点击显然不现实。

这时候就该上Graph Builder和命令行。其实SNAP的图形界面和命令行的底层算子完全一致，但命令行可以并行、可以循环脚本，还能断点续跑。下一章我就把Graph Builder的用法单独讲一下，这部分对中高级用户来说反而是最省时间的一步。

5. 把流水线固化进Graph Builder：批处理和命令行运行

5.1 在SNAP里搭建Graph：从点鼠标到搭流水线

SNAP的Graph Builder本质上就是一个可视化算子管道编辑器。你把预处理链路上的算子一个一个拖进画布，连起来，保存成XML文件。之后每次处理一景新的数据，只需要替换输入文件路径，就能一键从头跑到尾。

我在Graph Builder里最常用的一套流水线长这样：

• Read：读取SLC产品
• Apply-Orbit-File：应用轨道文件
• TOPSAR-Split：裁剪子带和burst
• Deburst：拼接burst
• Write：输出为Beam-DIMAP或GeoTIFF

如果你要做干涉，再加：

• Coregistration（配准）
• Interferogram（干涉图生成）
• Write输出

Graph Builder界面的操作不复杂：左侧是算子列表，搜索关键字拖到画布，连线，然后双击每个节点配置参数。配置参数时和GUI菜单里的选项一模一样，唯一要注意的是Read节点的文件路径要写对，那相当于整个流水线的入口。

5.2 用gpt命令行批量跑：效率翻倍的关键

Graph保存成.xml文件之后，用命令行运行才是真正的高效形态。SNAP安装目录下的bin文件夹里有个gpt（Graph Processing Tool），Windows下是gpt.bat。

基础命令格式如下：

gpt -J-Xmx8G D:/graphs/slc_preprocess.xml -Pinfile=D:/Sentinel1/S1A_IW_SLC__1SDV_20230815T153026_20230815T153054_012345_012345_0123.SAFE -Poutfile=D:/Sentinel1/out/slc_preprocessed.dim

这里用-J-Xmx8G单独给Java分配8GB堆内存，-P开头的参数是给Graph里的变量赋值，比如输入路径和输出路径。

如果你有几十景数据要处理，写一个简单的循环脚本就能全程自动跑。我一般会把输出路径按轨道号加日期命名，方便后面对照主辅影像，避免把同一个区域的预处理结果搞混。

5.3 一个适合直接抄作业的XML模板

下面这个模板是单景SLC预处理的最小可用方案，到Deburst为止，适合批量跑完再做配准干涉。如果你需要配准和干涉，在Deburst节点后面再串即可。

<graph id="SLC_Preprocess"> <version>1.0</version> <node id="Read"> <operator>Read</operator> <sources/> <parameters class="com.bc.ceres.binding.dom.XppDomElement"> <file>${infile}</file> </parameters> </node> <node id="Apply-Orbit-File"> <operator>Apply-Orbit-File</operator> <sources> <sourceProduct refid="Read"/> </sources> <parameters class="com.bc.ceres.binding.dom.XppDomElement"> <orbitType>Sentinel Precise</orbitType> <continueOnMissing>false</continueOnMissing> </parameters> </node> <node id="TOPSAR-Split"> <operator>TOPSAR-Split</operator> <sources> <sourceProduct refid="Apply-Orbit-File"/> </sources> <parameters class="com.bc.ceres.binding.dom.XppDomElement"> <subswath>IW1</subswath> <bursts>1-9</bursts> <polarisations>VV</polarisations> </parameters> </node> <node id="Deburst"> <operator>Deburst</operator> <sources> <sourceProduct refid="TOPSAR-Split"/> </sources> <parameters class="com.bc.ceres.binding.dom.XppDomElement"> <polarisations>VV</polarisations> </parameters> </node> <node id="Write"> <operator>Write</operator> <sources> <sourceProduct refid="Deburst"/> </sources> <parameters class="com.bc.ceres.binding.dom.XppDomElement"> <file>${outfile}</file> <formatName>BEAM-DIMAP</formatName> </parameters> </node> </graph>

你在实际使用时，把${infile}和${outfile}换成真实路径，或通过命令行参数传入都可以。需要注意bursts的写法，如果只是指定连续区间，像1-9就够了；如果是离散的几个burst，要用逗号分隔，比如1,3,5。这个细节特别容易错，写错了SNAP不一定报错，但输出影像里会发现有一节变得和预期不一样。

6. 写在后面：速度、仓位和你自己的习惯

最后聊点不太常出现在教程里、但实战中很要命的经验。

第一个是速度问题。SLC预处理的瓶颈往往不在算法而在磁盘IO。如果你的数据放在机械硬盘上，处理一景的时间可能比放在SSD上多出小一半。我的习惯是数据放SSD，中间产物放HDD，最终结果再回到SSD加速读取。听着有点绕，但实测下来整条流水线快很多。

第二个是仓位管理。SLC数据动辄几个GB，预处理中间产物、配准输出、干涉图叠在一起，一个项目几个月下来几百GB很常见。建议从一开始就建一个固定的目录结构：01_raw放原始SLC，02_orbits放轨道文件，03_preprocessed放预处理结果，04_interferograms放干涉输出，05_dem放辅助DEM。别小看这个习惯，等你要回溯某一次干涉图是怎么生成的，干净的目录结构能救你命。

第三个是尽量保留过程文件。有些人为了省磁盘空间，跑完一步就把中间结果删了。我不建议这么做。SLC预处理本身很耗时，一旦后面发现某个参数选错了，你还得从头跑。通常我会保留Split和Deburst这两个关键节点的输出，因为它们占据的磁盘不太大，却能让大部分返工节省一半以上时间。

SNAP处理Sentinel-1 SLC的门槛不在操作复杂，而在于你懂了原理、却能一头扎进各种参数和异常里。把这篇里提到的流程走一遍，再对照避坑部分踩过的坑自查一遍，剩下的事情就是耐心等待进度条走完。祝你的干涉图干净漂亮，相位解缠顺利出结果。