ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

哨兵一号数据下载全攻略:从官网到API脚本的实用方法

哨兵一号数据下载全攻略:从官网到API脚本的实用方法 哨兵一号数据的下载前几年还是一件挺折腾的事。我印象最深的是第一次做InSAR地表形变监测需要在网页端把几百个场景一个个勾选下载结果下到一半网络断了又得从头来。后来慢慢摸清了欧空局的新旧平台、ASF镜像、API脚本下载这些路子才算是把数据这条线彻底理顺。这篇文章就围绕哨兵一号数据下载这件事把我踩过的坑、验证过的方法和目前最实用的几种操作路径一次说清楚。无论你是刚入门的遥感学生还是做科研、做工程需要长期批量取数的老手这里面的内容应该都能帮你省下不少时间。1. 先别急着下三个数据入口的现状与差异很多人以为哨兵一号数据只有在欧空局官网下载实际完全不是这样。目前能拿到哨兵一号数据的主流渠道有三个各自的使用场景和稳定性差别很大。我在不同阶段都试过先说说它们的真实情况。1.1 欧空局官方平台从SciHub到Copernicus Data Space欧空局ESA最早的数据分发平台是Sentinel Scientific Data HubSciHub老用户对这个域名应该很熟悉注册、搜索、下载的流程用了快十年。但从2023年起欧空局逐步把哨兵数据的下载服务迁移到了Copernicus Data Space EcosystemCDSESciHub的新数据检索接口基本已经停止更新虽然老的下载链接在部分场景下还能用官方推荐路径已经明确指向CDSE。CDSE最大的变化是下载方式更多了。网页端支持按框选区域、时间范围、卫星编号直接检索下载可以用浏览器直链也可以用他们所提供的API接口走脚本批量拉取。另外它还内置了OData查询语法这让程序化检索数据变得非常方便。但有一个比较实际的槽点——注册流程稍显繁琐需要邮箱验证部分区域访问速度时快时慢我自己的经验是白天高峰期明显慢凌晨时段速度能快不少。需要注意的是CDSE上哨兵一号的数据并不仅限于最近几年的新数据历史存档包括2014年以来的所有Level-1和Level-2产品也在上面。有一个Opera Subset功能可以直接在云端做数据裁剪这对只需要小范围数据的用户来说是个福音省去了下载完整场景再在本地裁剪的过程。1.2 ASF DAACNASA的重要镜像如果欧空局平台访问速度不理想阿拉斯加卫星设施ASF DAAC几乎是第二选择。ASF是NASA下属的数据分发中心它把哨兵一号的数据完整镜像了一份界面友好程度甚至超过ESA原站。我记得ASF的Vertex检索界面有个很贴心的设计可以直接在底图上画多边形框选兴趣区而不像很多平台只能拉矩形。另外它支持按极化和轨道方向筛选这对干涉测量用户尤其重要——如果你做InSAR经常需要区分升轨和降轨数据ASF的筛选字段比欧空局默认界面更直观。ASF还有一个优势是它的文件下载走的是AWS的CDN整体速度和稳定性在某些地区表现不错而且不支持断点续传这件事倒不存在它用的是标准的HTTPS下载配合脚本工具可以随时续传。这里有个小坑ASF的下载链接是带有时效性的临时URL过期之后需要重新生成对于长时间挂机下载的场景需要注意。1.3 国内云平台和节点特定场景下的备选国内有些机构会镜像哨兵一号数据到自己的云平台比如部分高校和科研单位的内部存储或者一些商业云平台提供的公开数据集。如果你的项目对网络环境有特殊要求或者需要高频次重复下载同一区域的数据使用国内节点确实能省很多事。但使用国内镜像时要注意数据的完整性和时效性有些镜像只同步了部分时段或部分区域的影像而且产品级别可能不全比如只有GRD没有SLC。我的建议是在大规模使用前先随机抽几个时间和欧空局官网的产品列表做比对确认覆盖范围没有明显缺失再全量依赖。2. 选对产品类型比选对区域更重要Level-1与Level-2怎么取舍下载哨兵一号数据之前首先要想清楚你要的是哪种产品。很多人第一次操作时直接在全分辨率产品里一顿乱选下回来一堆用不上的数据既浪费时间也浪费硬盘空间。这里我按自己的使用经验把产品类型做了个简单拆解。2.1 四种产品类型SLC、GRD、OCN、RAW的适用场景哨兵一号的标准产品分为Level-0、Level-1和Level-2三个级别。Level-0是原始压缩数据普通人用不上也不建议下载Level-1又分为SLCSingle Look Complex单视复数和GRDGround Range Detected地距多视Level-2则是经过了地球物理参数反演的产品主要包含海洋相关的风场、波浪谱等信息。我用一个表格来对比这样看起来更清楚产品类型全称分辨率/规格典型用途数据量参考SLCSingle Look Complex保留相位信息约5m x 20mInSAR、相干性分析、地表形变监测单景4-8GBGRDGround Range Detected多视处理消除斑点噪声约10m x 10m或更高地物分类、洪水监测、船只检测、土地利用单景1-3GBOCNOcean包含风场、波浪等反演产品海洋学研究几百MBRAW原始数据Level-0特殊算法研究极大一般不碰如果你要做的方向和形变有关比如地震同震形变场、地面沉降监测、冰川运动速度观测那么必须选SLC。GRD数据已经把相位信息抹掉了虽然看着清晰但做不了干涉。反过来如果只是做地物识别、变化检测这类强度图分析GRD完全够用数据量还小得多。2.2 极化方式的选择VV/VH与HH/HV哨兵一号是C波段SAR卫星默认的成像模式是干涉宽幅IWInterferometric Wide Swath在这个模式下同时接收VV和VH两种极化信号。部分波束模式下也有HH和HV极化。对大部分陆地区域的应用VV极化是主力VH极化作为补充常用于水体识别和植被参数反演。做形变监测时一般只用VV极化就够了下载时不需要把所有极化都选上每次多勾一个极化数据量就多一倍没必要的存储和传输成本完全可以省掉。需要注意的是哨兵一号的StripMapSM模式支持HHHV极化这个模式主要用于应急管理和海上船舶监测空间分辨率较高5m x 5m左右但覆盖幅宽只有80km和IW模式的250km相比小了不少。挑选数据时如果不是对分辨率有特殊要求IW模式的VVVH通常是最稳妥的选项。2.3 2022年之后的时间序列变化这里有一个很容易被忽略但非常关键的时间节点2022年8月哨兵一号B星在轨发生故障退役整个星座从原本的双星交替运行回到了单星运行状态。这意味着什么原本A星和B星组合运行可以让同一区域的重访周期从12天缩短到6天B星退役后重访周期被迫回到12天。对数据下载的直接影响是同样是2021年和2023年的时间序列前者拿到的场景密度是后者的两倍。做形变监测或者时序分析的时候如果跨越了这个时间节点数据处理时数据量的跳变会很明显需要提前在方案设计上做出调整。另外部分数据处理软件在处理B星退役前后的数据时基准轨道的编号体系也需要单独统一这个在下载时就要注意否则后面配准环节容易出错。3. 网页端检索的核心操作从框选区域到筛选组合网页端检索虽然看起来简单但检索结果的高低直接影响最终下载的数据质量。很多人直接在地图上画个矩形就开始下载结果回来的数据覆盖范围不对、轨道方向不对、甚至卫星编号都混在一起后面处理数据的时候才追悔莫及。这里把我平时用的检索流程拆开来说。3.1 兴趣区设置的常见误区在地图上框选兴趣区时有两个常见误区。第一个是框选得太小特别是做时序分析时如果只框了研究区的最小外接矩形后面影像配准时可能会因为覆盖范围不足导致边缘区域无效最终获得的有效数据面积大打折扣。我的习惯是在核心研究区外围再留出至少10%-15%的buffer。第二个误区是只用了矩形框选。哨兵一号的影像幅宽是250km如果你的研究区跨越了两条相邻轨道矩形框选会把很多不需要的场景也框进来。我建议先到轨道预报网站上查清楚你的研究区对应的是哪几条轨道号然后直接用轨道号筛选再配合区域框选做二次确认这样检索结果会精准得多。3.2 时间范围与轨道方向的组合条件时间范围的设定取决于你的应用场景。如果是做差分干涉需要找到尽可能时间间隔短、空间基线小的影像对那么检索时要把时间范围放宽再通过轨道号和成像时间排序来挑选最优的像对。如果是做长时间序列的地表形变监测比如城市地面沉降那需要的是等间隔的时间序列数据检索时按固定周期比如每月或每12天逐一确认数据是否存在。轨道方向ascending/descending也是检索时的一个关键参数。SAR卫星是极轨卫星成像时有升轨和降轨之分对于InSAR而言视线向形变对升轨和降轨数据的敏感方向不同。如果要做二维形变分解通常需要同时获取升轨和降轨两个方向的数据检索时应该分别检索并把两个方向的场景匹配时间错开控制在合理范围内。3.3 网页面板上容易被忽略的字段CDSE和ASF的网页检索面板上有几个容易忽略的字段我列一下重点关注卫星编号A星还是B星、产品级别、极化方式、轨道号、相对轨道号Path和绝对轨道号Frame、云量SAR数据其实没有云量这一说但平台上部分产品会有这个字段忽略即可。还有一个相对轨道号Path的最佳实践建议记住研究区对应的Path和Frame编号下次无论换哪个平台直接输入编号检索比每次在地图上重新框选高效很多。用Path和Frame这两个字段组合检索还有一个好处——可以避免重复下载同一景影像的不同版本。哨兵一号的数据在重新处理后会更新版本号如果只用时间范围检索很可能同一场景下载到两个不同版本的数据白白增加存储压力。4. 批量下载的正确姿势API脚本与自动化工具的实战细节当需要下载的数据量超过几十景时网页端逐个点击的方案基本不可行。我自己的记录是曾有一次为了做全省范围的形变监测总共需要下载1200多景SLC数据用网页下载完全不现实最终靠API脚本跑了三天把数据全部拉完。自动化的甜头体验过一次就回不去了。4.1 理解CDSE的OData查询语法CDSE的API是基于OData协议的不复杂但语法细节需要适应。一个常规的查询URL格式是这样的https://catalogue.dataspace.copernicus.eu/odata/v1/Products?$filterCollection/Name eq SENTINEL-1 and OData.CSC.Intersects(areageographySRID4326;POLYGON((...))) and ContentDate/Start gt 2023-01-01T00:00:00Z and ContentDate/Start lt 2023-02-01T00:00:00Z这个查询语句的意思是在SENTINEL-1数据集合里找与某个多边形相交、且成像时间在2023年1月到2月之间的产品。这个语法本身并不难但有几个容易写错的地方OData.CSC.Intersects是空间查询的函数括号前不能有空格多边形坐标的格式是经度 纬度多个坐标对用逗号分开最后一个坐标要和第一个坐标闭合ContentDate/Start是成像开始时间ContentDate/End是成像结束时间检索时建议两者都用上避免边缘场景。实际使用中我建议先用网页端确认某个区域的Path/Frame编号然后在API查询里直接用产品名例如S1A_IW_SLC__1SDV_20230101T……模糊匹配这种方法比多边形相交查询更快更稳定。4.2 用Python脚本实现搜索加下载一体化我写了一个相对通用的小脚本功能是输入区域经纬度、时间范围、产品类型自动搜索并下载所有匹配的哨兵一号数据。核心逻辑很简单就是先查产品清单再逐个生成下载链接然后调用下载。import requests import json import time base_url https://catalogue.dataspace.copernicus.eu/odata/v1/Products query $filterCollection/Name eq SENTINEL-1 and OData.CSC.Intersects(areageographySRID4326;POLYGON((116.0 39.0,117.0 39.0,117.0 40.0,116.0 40.0,116.0 39.0)))) and ContentDate/Start gt 2023-06-01T00:00:00Z and ContentDate/Start lt 2023-07-01T00:00:00Z url f{base_url}?{query}$top50 headers {Authorization: Bearer YOUR_TOKEN} resp requests.get(url, headersheaders) data resp.json() for item in data.get(value, []): print(item[Name], item[Id])脚本里的YOUR_TOKEN需要先从CDSE平台申请申请入口在用户中心按提示操作即可。拿到token之后可以用一个简单的函数把下载链接拼出来download_url fhttps://catalogue.dataspace.copernicus.eu/odata/v1/Products({product_id})/$value4.3 ASF的命令行批量下载工具如果你更习惯用ASF的镜像它们的批量下载工具也挺好使。ASF提供了一套基于Python的命令行工具叫asf_search支持接收一个GeoJSON文件作为搜索范围然后自动搜索并批量下载。pip install asf_search然后写一个简单的Python脚本import asf_search as asf results asf.geo_search( platform[asf.PLATFORM.SENTINEL1], intersectsWithpath/to/area.geojson, start2023-01-01, end2023-06-30, processingLevelSLC ) for product in results: product.download(path./downloads, sessionasf.ASFSession().auth_with_creds(username, password))这里要注意的是ASF的geo_search支持的GeoJSON文件需要包含有效的地理坐标信息。你可以用QGIS或者在线工具把KML转成GeoJSON格式不复杂但坐标一定要是WGS84经纬度。用ASF的好处是搜索和下载走的是同一套认证不需要手动处理token对不熟悉API的人来说上手门槛更低。缺点是ASF的镜像有时比欧空局原站更新慢个一两天如果对数据时效性要求极高还是要以CDSE为准。4.4 并行下载与限速管理批量下载时的另外一个问题是速度。CDSE对单个IP有一定的速率限制强制开几十个线程反而不稳定我实测比较合适的并发数是3到4个连接同时下载整体速度通常在10MB/s到30MB/s之间不同时段差异较大。我建议用aria2或者wget配合下载列表文件来实现轻度并发aria2c -i download_list.txt -x 4 -s 4 -c其中-c是断点续传参数-x 4表示每个文件最多开4个连接。下载列表里的每一行是一个完整的下载URL。如果中途网络断了重新执行命令会自动续传已经下载的部分不用从头开始。这里有一个值得注意的细节CDSE生成的下载链接有时效性一般几小时到一天不等。如果下载文件特别大一个场景4-8GB网络稍有波动就可能导致链接过期。我遇到过好多次下到一半链接失效的情况后来摸索出一个经验——用脚本定期刷新token并把下载URL即时更新到下载列表里再配合aria2的自动重试机制基本能保证大文件顺利下载完成。5. 下载中断、限速与断点续传我踩过的那些坑数据下载看起来是个体力活但真正操作过的人都知道这里面的坑远比你想象的多。这里专门用一个部分来讲我实际遇到的问题和对应的解决办法。5.1 大文件下载一半链接失效如前所述CDSE的下载链接有时效性而且大文件下载非常耗时。一个SLC场景网络一般的情况下要下载20到40分钟。如果链接在39分钟失效所有进度直接清零。这个坑我踩过不下五次最后总结出的方案是下载前先把token刷新到最新下载过程中设置定时器每30分钟重新获取一次新的下载链接并手动替换正在下载的任务URL。当然这个方案有点笨更偷懒的办法是用支持断点续传的下载工具配合定期从API获取新链接的脚本。我看到很多同行用aria2的--auto-file-renamingfalse参数加外部轮询脚本这套组合可以很好地解决链接过期问题。5.2 部分场景搜索不到或无法下载搜索不到数据的情况主要发生在长时间跨度检索时。2022年之前的哨兵一号B星数据在部分区域存在覆盖缺口尤其是高纬度地区和部分海域。另外欧空局对哨兵一号数据的版本更新很频繁旧版本的数据在平台上的保留规则是滚动式的有些时间较早的场景只能拿到新版本新版本和旧版本的产品名会有一串追加字符比如_V002这样的后缀下载后建议把版本号记录在文件目录里方便追溯。另一种情况是虽然搜索到了产品但点击下载后总是报错。这个问题大概率出在产品本身的完整性上。处理办法是在CDSE上先把该产品的Checksum字段调出来下载后用md5sum命令校验文件完整性。如果校验值不匹配说明文件损坏建议直接删除重新下载。5.3 存储空间规划这个坑虽然和下载本身关系不大但和长期下载数据的体验密切相关。哨兵一号单景SLC数据4-8GB100景就是400-800GB。存储空间不够的情况下下载中途磁盘写满轻则浪费半天时间重则文件系统损坏导致之前下载的数据全部报废。我的建议是分目录管理按区域-时间-产品类型三级目录结构存放。同时保留一个下载清单.csv记录每个文件的URL、下载时间、校验值、对应的区域和时间范围。这样虽然前期多花一点时间但后面查找数据和处理数据时会省下大量力气。5.4 不要忘记数据的许可协议最后一条同时也是很多人忽略的一条哨兵一号数据的许可协议要求在使用时注明数据来源并且在实际发表成果时要对数据源进行公开致谢。具体来说就是说明数据的提供方是包含了Copernicus Sentinel data这一行说明同时在研究中注明数据年份和版本号。很多期刊对这方面的要求越来越严格如果不在原始数据阶段就做好标注后面补起来非常麻烦。我自己的经验是在数据下载的同一时间就把来源信息写进一个METADATA.txt文件放进同一级目录这样无论过了多久都能快速找到对应的数据出处。6. 总结我自己常用的下载流程说了一大堆最后把我的日常下载流程做一个完整的梳理。如果你现在需要下载哨兵一号数据可以按照这个流程走能避开大部分无效操作。第一明确需求。先回答几个问题做什么方向需要SLC还是GRD需要哪些极化和轨道方向时间跨度多大预计涉及哪些Path和Frame第二确认数据覆盖。用ASF或CDSE的网页端先做一次快速检索查看研究区在目标时间段内有多少可用场景特别留意2022年8月之后B星退役导致的场景稀疏问题。第三优先走API脚本批量下载。数据量低于10景用网页端没问题超过这个量就直接上Python脚本或aria2配合断点续传减少人工操作。第四下载完成后立刻校验文件完整性。检查文件大小是否和平台标注一致或用校验值比对宁可多花几分钟也不要把坏数据留到处理阶段。第五归档整理。把数据按区域、时间、产品类型分目录存放记录来源信息和许可协议要求为后续处理和论文写作做好准备。我个人的偏好是同时注册CDSE和ASF两个平台下载时间敏感的数据用CDSE下载历史存档数据用ASF两边互为补充整体效率和稳定性都有保障。这套流程在我自己的多个项目中已经跑通了希望对你有帮助。
返回列表