做InSAR合成孔径雷达干涉测量的人几乎没人能绕开Sentinel-1。这颗C波段SAR卫星对地观测最大的贡献就是把SLC数据单视复数影像做成了免费开放、重访周期稳定、且可以直接用于干涉处理的标准化产品。但拿到SLC只是第一步你真要把它处理成干涉图、形变场通常还得同时备齐另外两样东西覆盖整个研究区的DEM数据以及SLC成像时刻对应的精密轨道数据。这三类数据凑齐了SNAP、ISCE2、GAMMA这些主流InSAR处理软件才能顺畅跑起来。搜“Sentinel”有时候会窜出Java微服务里那个同名限流组件但本文聊的是欧空局的哨兵卫星别搞混了。这篇文章我就把SLC下载、DEM下载拼接、精密轨道数据获取这三条线完整走一遍把平台、筛选逻辑、命名规则、批量下载脚本和常见坑都整理成可以直接参考的流程。1. 项目整体设计与思路拆解1.1 为什么InSAR流程绕不开SLC、DEM和精密轨道数据先理清一个基本问题为什么一定要用SLC而不是直接下载更容易获取的GRDGRDGround Range Detected是已经做过几何校正、多视处理的强度影像它在处理过程当中丢掉了重要的相位信息。而干涉测量靠的就是两景SLC之间的相位差只有SLC这种复数影像才同时保留幅度和相位。所以只要你的目标是形变场、像对相干性分析就必须在平台上下载Processing Level为SLC的产品这一步省不了。DEM的作用同样关键。两景SLC做干涉时得到的相位里既包含地形贡献也包含形变贡献。如果不先借助DEM模拟并去除地形相位干涉图会被密集的地形条纹淹没无法直接读出形变信号。反过来说DEM的精度越高地形相位模拟越准得到的差分干涉图越干净。对于Sentinel-1这种C波段数据30米分辨率的开源DEM在绝大多数地区已经够用甚至SRTM 90米在某些平坦区域也能对付只是边缘细节没那么好而已。精密轨道数据则是很多人前期最容易忽略、后期返工最痛苦的一环。SLC产品元数据里自带一套轨道状态向量但那其实是基于预报的粗轨位置误差或许能达到几米甚至十几米。粗轨误差会以长波长条纹的形式混入干涉图搞不好就把真实形变信号掩盖了或者让相位解缠失败。使用POEORB精确轨道数据后轨道误差可以降到厘米级甚至更优长波长误差基本被压制掉。简单说DEM解决“地形相位怎么扣”的问题精密轨道解决“轨道误差怎么消”的问题而SLC是这一切的输入原料。1.2 三类数据的关系与准备顺序从数据流角度看SLC、DEM、精密轨道三者并不完全独立轨道数据必须和SLC的成像时刻严格对应DEM则要求覆盖范围包含SLC影像区域。所以我的建议是固定一套准备顺序先确定研究区和时间范围再检索下载SLCSLC到齐以后读取每一景的覆盖范围来圈定DEM的包围盒统一下载并拼接最后根据每景SLC的开始时间去轨道数据库里匹配对应的.eof文件。按这个顺序走DEM不会下载得过大轨道文件也不会匹配错。在项目目录上我也建议一开始就按数据类别分好文件夹避免后续混在一起找不到文件。一个我常用的结构是这样project/ 01_slc/ 02_dem/ 03_orbits/ 04_processing/工程越到后面你会发现前期数据命名和目录管理越重要。SLC的SAFE文件夹名称一定不要改很多软件靠文件名解析轨道号和成像时间DEM和轨道文件也尽量保持原始命名方便回溯。2. Sentinel-1 SLC数据下载实操2.1 平台怎么选ASF DAAC还是Copernicus Data Space目前下载Sentinel-1 SLC主要有两个主流入口美国阿拉斯加的ASF DAACAlaska Satellite Facility和欧空局的Copernicus Data Space Ecosystem。老的Open Access Hub原scihub.copernicus.eu这几年逐步完成了迁移新用户和新接口基本都导向Data Space再用老的脚本去连scihub会遇到各种登录和API限制。所以我现在的习惯是日常人工检索、小批量下载首选ASF需要借助API批量执行存档任务时优先写适配Data Space或ASF搜库的脚本哪个通就用哪个。ASF DAAC最大的优势是检索界面好用支持多边形框选还可以直接通过结果列表导出CSV元数据方便归档。Copernicus Data Space则是官方数据源数据发布通常最早同时提供OData/STAC一类接口适合需要精确控制查询条件的用户。两者下载的数据本身没有差异都是同一颗卫星的产品选哪个主要看你更习惯哪种交互方式。如果只是普通项目用我的建议是先注册一个NASA EarthData账号再到ASF去搜省心。2.2 用ASF完成SLC检索与筛选打开ASF DAAC官网并登录后左侧会有一个地图窗口可以直接在地图上绘制多边形选区范围可以精确到研究区边界比单纯的经纬度矩形框更不容易漏掉边缘场景。画好范围后在Filters里逐项设置关键条件Platform勾选Sentinel-1A、Sentinel-1BProcessing Level务必选SLC如果选了GRD后面所有步骤都无法做干涉Beam Mode陆地区域InSAR基本都选IW干涉宽幅这是Sentinel-1默认的陆地区域成像模式Flight Direction升轨Asc或降轨Desc按项目需求选择Polarization通常选VVVH或者VV具体取决于研究目标Date Range设置起止日期。设置完点击搜索结果列表会列出所有符合条件的场景。列表里会显示轨道号、帧号、开始时间、结束时间等字段。我一般会先把结果按轨道号分组因为InSAR时间序列分析通常要求在同一个重复轨道上选择影像跨轨道组干涉处理起来比较麻烦。如果要长期跟踪某一区域建议把搜索结果导出成CSV保存记录好每一景的轨道号、时间和下载链接后面做像对选择时直接查表比翻网页快得多。2.3 批量下载与断点续传方案当检索结果比较多的时候一个个点网页上的下载图标会非常痛苦。ASF提供了一种生成批量脚本的方式在搜索结果页可以直接选择“Download All”它会生成一个包含所有下载链接的脚本或列表文件。配合wget或者aria2这类工具可以支持断点续传用起来很方便。我用得比较多的是Python的asf_search库直接写脚本先按多边形、时间、产品级别去搜索再逐条下载。它的好处是筛选逻辑可以写进脚本里重复执行重现性很强也方便把元数据一起归档。一个简化示例大概是这样的思路import asf_search as asf results asf.search( platformasf.PLATFORM.SENTINEL1, processingLevelSLC, beamModeIW, start2023-01-01T00:00:00Z, end2023-03-01T00:00:00Z, intersectsWithPOLYGON((120.0 30.0, 121.0 30.0, 121.0 31.0, 120.0 31.0, 120.0 30.0)) ) for result in results: print(result.properties[title], result.properties[url])下载大文件时一定要用支持断点续传的方式浏览器直接下载经常断在半路。我用wget时会给一串常用参数wget -c --retry-connrefused --tries0 --timeout60 -i download_list.txt这里-c表示断点续传--tries0是无限重试--timeout60避免长时间卡死。实测这些参数对于几十GB的SLC大场景下载很关键不然中途网络抖动一下前面几GB就白下了。顺带提醒一句Sentinel-1B在2022年12月已经正式停止回传数据。如果搜索时选了Sentinel-1B2023年之后的结果就会是空的这不是平台问题是卫星状态问题。2023年后新获取的数据只能等Sentinel-1C或只用Sentinel-1A。2.4 看懂SLC命名与成像模式SLC产品的命名看起来很长其实信息量很大。以常见的命名格式为例S1A_IW_SLC__1SDV_20230101T050332_20230101T050359_050674_061D5A_XXXX拆开看S1A是卫星标识IW说明是干涉宽幅模式SLC是产品级别1SDV表示双极化VVVH时间戳分别是传感数据采集的开始和结束时间后面是轨道号、片段编号等信息。处理软件经常直接从文件名里解析这些字段所以文件名不要随意改动。关于成像模式陆地InSAR项目绝大多数选择IW模式因为它的幅宽约250公里分辨率5米×20米兼顾覆盖范围和精度。SM条带模式分辨率更高但幅宽只有约80公里适合小范围重点区域EW超宽幅主要面向海洋和极地区域陆地区域形变研究很少用。文献里提到的SLC还有burst结构IW数据由多个子孔径段组成SNAP这类软件在处理时会自动拼接这一步对用户是透明的前期下载阶段不需要过多操心。3. DEM数据下载与拼接全流程3.1 常用开源DEM数据源怎么挑DEM相关术语有个地方容易混DEM是数字高程模型DSM是数字表面模型DOM是数字正射影像。本文里的InSAR地形模拟只需要地形高程信息也就是DEM不需要包含建筑物和树冠高度的DSM。目前开源数据里常用的主要有四种SRTM 1ArcSec30米USGS发布覆盖南北纬60度之间经典可靠很多InSAR软件的默认选项SRTM 3ArcSec90米同样来自航天飞机雷达地形测绘任务适合大范围低精度需求Copernicus DEM GLO-3030米基于TanDEM-X任务全球覆盖细节比SRTM更好山地效果明显ALOS AW3D3030米JAXA发布地形起伏区域表现也不错。对于Sentinel-1的C波段InSAR处理我自己的经验是30米分辨率足够。相比SRTMCopernicus GLO-30在中低纬度的细节保持更好特别是在植被稀疏、地形破碎的区域差分干涉的残差会小一些。但SRTM也有优势绝大部分处理软件都支持直接调用下载渠道成熟稳定。如果测区在北纬60度以上SRTM会缺失这时候Copernicus DEM或ALOS更合适。3.2 SRTM与Copernicus DEM下载实操SRTM 30米数据的常用下载平台是USGS EarthExplorer。注册账号后在地图上画好范围在Data Sets里找到SRTM 1ArcSec或SRTM v3 1arcsec搜索后会出现对应Tile直接下载GeoTIFF格式即可。EarthExplorer支持一次勾选多个Tile批量下载也可以导出下载链接给外部工具使用。Copernicus DEM GLO-30我一般不从欧空局网页逐块点而是走AWS Open Data存储桶数据以1度×1度的Tile组织文件名格式类似Copernicus_DSM_COG_10_N43_00_E003_00_DEM/Copernicus_DSM_COG_10_N43_00_E003_00_DEM.tif可以用AWS命令行直接列目录和下载aws s3 ls --no-sign-request s3://copernicus-dem-30m/ | head aws s3 cp --no-sign-request \ s3://copernicus-dem-30m/Copernicus_DSM_COG_10_N43_00_E003_00_DEM/Copernicus_DSM_COG_10_N43_00_E003_00_DEM.tif \ ./不用AWS环境的话也可以直接用wget访问该存储桶的HTTP公共入口只要知道Tile名称就可以下拉非常简单。下载前先根据研究区经纬度范围列出需要的Tile列表避免多下无关区域。3.3 DEM拼接裁剪GDAL命令行与ArcGIS双方案当测区跨多块DEM Tile时需要拼接。我优先推荐GDAL的命令行路线因为可脚本化、可复现、性能也稳定。处理思路是先建VRT虚拟栅格再统一转换、裁剪这样可以避免直接整块合并产生的大体积中间文件。# 先把需要拼接的Tile路径写入一个文本文件 ls Copernicus_DSM_COG_10_*.tif dem_tiles.txt # 建立虚拟栅格统一NoData值 gdalbuildvrt -vrtnodata -32768 dem_all.vrt dem_tiles.txt # 裁剪到研究区范围并转成最终GeoTIFF gdal_translate -projwin 120.0 31.0 121.0 30.0 \ -of GTiff -co COMPRESSDEFLATE -co TILEDYES \ dem_all.vrt dem_study.tifgdal_translate的-projwin参数顺序是左上角经度、左上角纬度、右下角经度、右下角纬度千万不要按minLon/minLat/maxLon/maxLat来输。我第一次用这个参数时就是按习惯写成了最小经度、最小纬度、最大经度、最大纬度结果出来了两个空文件检查了半天才发现是参数顺序问题。ArcGIS的操作逻辑类似但走的是图形界面。用Mosaic To New Raster工具像素类型选FloatNoData值建议统一设为-32768Mosaic Operator选Blend或First。要注意输入栅格的投影必须一致如果混入了UTM和经纬度坐标系的Tile拼接结果会有很大偏差。拼接后如果需要裁剪直接用Extract By Mask导出到研究区范围即可。3.4 DEM空洞修正与坐标配套SRTM在某些陡峭山区和低纬度森林区域会有空洞通常表现为黑色斑块或NoData值。InSAR处理时如果地形相位模拟落在NoData区那一片干涉图直接废掉。处理空洞有两种思路一是用gdal_fillnodata.py做插值填补二是换用Copernicus DEM数据源。插值适合小空洞大面积空洞建议直接换数据源。水深区域和海岸带也要特别留意。有些DEM产品在水体会出现NoData或0值陆地InSAR处理一般把海面作为低相干区0值影响不大但如果你把NoData填充到海域反而会引入错误的模拟相位。所以填充空洞前先确认NoData的范围是陆地还是水体。DEM和SLC的坐标配套问题在处理软件里有几个具体要求大多数InSAR工具要求DEM在WGS84经纬度坐标系下高程单位为米如果DEM是UTM投影需要先用gdalwarp -t_srs EPSG:4326转换。范围上DEM必须完全覆盖SLC影像区域否则干涉处理会在边缘产生大片无数据。我习惯在下载DEM时把范围比研究区外扩0.1到0.3度宁大勿小反正裁剪很快。4. 精密轨道数据下载方法4.1 RESORB与POEORB到底怎么选Sentinel-1的精密轨道产品按发布时间和应用阶段分成两类。RESORB的完整名称是Restituted Orbit卫星数据获取后大约3小时就能拿到精度在厘米级POEORB是Precise Orbit Ephemerides也就是最终精密轨道产品数据获取后约21天发布精度更高。对于学术级的InSAR处理推荐使用POEORB它能把长波长轨道误差控制在最低水平。但如果你拿到的SLC是最新几天的数据POEORB还没有生成这时候只能先用RESORB过渡等21天后再回过头用POEORB重新精化处理。有个容易被忽略的细节SLC自带的粗轨数据也有“轨道”但它不是RESORB也不是POEORB而是预报轨道。三者精度差异按量级来看大致是粗轨误差数米级RESORB误差分米级POEORB误差厘米级甚至更优。InSAR干涉测量对轨道误差非常敏感所以不要偷懒省略轨道精化这一步尤其是大范围、长条带的数据。4.2 轨道数据命名规则与匹配原理轨道数据文件名虽然长但信息和SLC文件名一样清晰。一个典型的POEORB文件名是S1A_OPER_AUX_POEORBT_OPOD_20230101T000000_V20261215T225942_20261217T005942.EOF这里S1A是卫星标识POEORBT代表精密轨道产品OPOD是轨道解算中心标识紧接着的时间是产品生成时间而V后面的两段时间才是关键它表示这份轨道产品有效覆盖的时间范围。我们匹配轨道文件时核心原则就是看SLC影像的开始时间是否落在轨道文件的_V..._两个时间戳之间。只要这个条件成立这份.eof文件就是可用的。注意所有时间都是UTC标准时间不要用本地时间去匹配。我见过有人用北京时间直接去比结果总是差8小时一会儿匹配不上一会儿匹配到错误轨道。轨道文件本身是一个XML格式的EOF文件SNAP这类软件可以直接读取。文件名里的卫星标识必须与SLC一致比如S1A的SLC只能配S1A的.eof千万不要把S1A轨道文件配给S1B影像会导致轨道状态向量和实际数据对不上。4.3 批量匹配下载脚本分享轨道数据的批量匹配非常适合脚本化。ASF镜像站上的目录结构按月份组织可以从月份目录拉取当月所有.eof文件名列表然后与本地SLC场景做时间交叉匹配。下面是一个实用的小脚本示例核心逻辑就是解析时间戳然后比较覆盖范围import re import glob from datetime import datetime # 读取本地SLC名称截取成像开始时间 scene_name S1A_IW_SLC__1SDV_20230101T050332_20230101T050359_050674_061D5A_XXXX.SAFE m re.match(r.*_(\d{8}T\d{6})_, scene_name) scene_start datetime.strptime(m.group(1), %Y%m%dT%H%M%S) # 解析每个.eof的有效时间范围 def parse_eof_time(eof_name): mm re.search(r_V(\d{8}T\d{6})_(\d{8}T\d{6})\.EOF$, eof_name) if not mm: return None start datetime.strptime(mm.group(1), %Y%m%dT%H%M%S) end datetime.strptime(mm.group(2), %Y%m%dT%H%M%S) return start, end # 在当前目录的所有.eof里找匹配项 for eof_path in glob.glob(*.EOF): eof_name eof_path.split(/)[-1] if not eof_name.startswith(S1A): # 确认卫星型号 continue t_range parse_eof_time(eof_name) if t_range and t_range[0] scene_start t_range[1]: print(f匹配轨道文件: {eof_name})写循环批量处理时只需要遍历一个SLC列表把每一景对应的轨道文件名输出到清单表里再统一用wget下载就行。下载轨道文件的地址也很常规我常用的是ASF镜像目录https://s1qc.asf.alaska.edu/aux_poeorb/2023/01/把年份和月份换成实际值目录下就是当月的POEORB文件。RESORB则放在aux_resorb对应目录下。直接在网页里按文件名排序浏览也不难但文件多了还是脚本更可靠。4.4 主流InSAR软件中的轨道数据配置SNAP中有一个名为Apply Orbit File的处理工具输入SLC后直接浏览选择下载好的.eof文件执行后产品会在内部元数据中更新轨道状态向量后续干涉就用新轨道算。ISCE2的topsStack流程则更倾向于自动匹配处理时会在配置路径下找aux_poeorb、aux_resorb一类的目录把轨道文件放进去之后它会按时间自动匹配场景。GAMMA的流程相对更手工一些需要先把.eof转换成自己可读取的轨道格式再在参数文件里调用新手阶段容易卡在它独特的接口风格上。不管用哪个软件底层逻辑都是相同的处理前先把轨道数据路径准备好。我的经验是每下载一批SLC就同步生成对应的.eof下载清单然后一次性全部下载好并分目录存放不要等到处理软件报错“orbit file not found”才想起来去找。5. 常见问题与排查技巧实录5.1 数据下载阶段的高频翻车点下载SLC时碰到最多的就是登录认证和下载中断问题。ASF使用NASA EarthData账号体系注册后有时会遇到Token过期表现为脚本报401或者403重新登录刷新凭证即可。Copernicus Data Space的注册流程相对繁琐如果遇到接口503或者429大概率是服务端限流换个时间段再试或者改用ASF镜像。下载中断是另一个大问题。浏览器直接下载大文件时一旦断网就得重来。稳妥方案是用wget或aria2做断点续传同时把下载列表保存下来。如果下载了几个GB然后校验不通过通常就是没有开启断点续传导致文件不完整。另外SLC的SAFE文件夹下载完成后建议检查目录里的manifest.safe文件是否存在如果缺失后续软件会直接拒绝读取。还有一种情况经常被忽略搜索SLC时没有过滤Processing Level默认搜出来一堆GRD占满了磁盘后发现根本不能用于干涉。所以在检索结果里务必检查产品级别这一列SLC和GRD的图标虽然看着相似但用途完全不同。5.2 DEM处理阶段的坑与修正DEM拼接最常见的坑是投影不一致。如果下载的Tile有的是WGS84经纬度有的是UTM投影直接用gdalbuildvrt强行合并输出的结果会错乱。解决办法是先用gdalinfo或者gdalwarp把所有Tile统一到同一坐标系。另外不同Tile之间的NoData值可能不一致有些是-32768有些是0合并前用gdalbuildvrt -vrtnodata统一指定比较保险。空洞处理还有一个容易踩的地方gdal_fillnodata.py对大面积空洞的插值结果只能说是“有值”并不一定真实反映地形尤其是在山谷地区插值可能会把山脊和沟谷抹平。所以如果空洞面积占比过大我建议直接换Copernicus DEM重新下载而不是强行插值。裁剪时如果发现输出全是黑边检查一下-projwin的两个角点顺序前面已经说过这是高频操作失误。另一个常见问题是使用经纬度范围裁剪时DEM是UTM投影坐标单位不匹配输出结果不仅会错位甚至可能空白。先确认投影再给参数这种问题能少掉一半。5.3 轨道数据时间匹配的边界情况轨道数据匹配的边界情况最容易出问题尤其是SLC时间正好落在轨道文件有效时间边缘附近时。有些处理软件解析轨道文件时对时间边界非常敏感可能差几秒就认为不匹配。稳妥的做法是选择有效时间范围完整覆盖SLC开始时间的.eof文件而且最好前后留出至少几分钟余量不要选那种只差几秒就出界的文件。如果SLC拍摄时间距离现在不足21天POEORB文件还没生成这时候切到RESORB目录下载对应产品。部分新手看到POEORB目录里没有当月文件就以为是平台数据不全其实只是还没发布。轨道文件下载时也要注意卫星标识S1A和S1B的轨道文件是分开的把S1B的.eof放在S1A的处理目录里软件可能不会立刻报错但在基线估计时会给出诡异的结果。还有国际日期变更线附近的数据SLC时间和.eof文件时间看起来会差一天其实只是时区显示不同只要统一用UTC时间比较就不会出问题。5.4 数据全流程管理的个人习惯最后分享一个我自己的整理习惯。每收到一批SLC我会建一个文本清单内容包括场景完整文件名、Satellite编号、成像开始UTC时间、轨道号、下载平台、对应.eof文件名、DEM覆盖范围。这张表既是像对筛选的底稿也是后续论文数据可回溯性的依据。项目做完后这个清单文件会和数据放在同一个根目录下归档时一目了然。磁盘空间管理也不能忽视。一景IW SLC产品约1到2GB100景就是一两百GBDEM合拼后通常只有几百MB到2GB轨道文件单个很小但数量多。我习惯把SLC数据放在单独的机械硬盘或者网络存储上处理中间产物放SSD这样能兼顾速度和容量。用du -sh定期检查目录大小及时删除掉重复下载和失效的临时文件能避免后面处理时磁盘被写满的尴尬。这三类数据的准备流程熟练以后整套InSAR处理其实就完成了一半。我踩过的最大一个坑就是第一版干涉图里长条纹满天飞折腾了很久最后发现是粗轨数据惹的祸换成POEORB之后条纹立刻消失。从那以后我养成了固定习惯不管多着急处理前一定先把精密轨道文件匹配好绝不会拿预报粗轨去跑正式结果。另一个体会是DEM范围真的宁大勿小多下载几块Tile成本极低但少一块导致边缘全是NaN返工成本反而高得多。这套流程整理成固定动作之后从原始数据到干净差分干涉图的速度会有明显提升。