直接开门见山说结论:做区域土壤水分、干旱监测或者水文相关的研究,AMSR-2数据基本是绕不开的一个数据源。但真正开始动手下载的时候,你会发现这门“小事”里坑不少——JAXA官方的数据分发系统和NASA那边的GES DISC是完全两套玩法,LPRM算法产品和JAXA官方L2/L3产品的数据结构、单位、投影也都不一样。我去年做西北一个区域的土壤水分反演验证时,光是数据准备就折腾了快一周,期间踩过的坑包括配额限制、ESDL token过期、批量下载脚本崩掉……这篇文章就是把我最终趟通的全流程整理出来,从数据源、算法选择、下载实操到效率优化一次讲清楚,给准备入坑AMSR-2的人省点时间。
1. AMSR-2数据全景:官方产品与LPRM算法产品的本质区别
1.1 先搞清楚AMSR-2能提供什么
AMSR-2(Advanced Microwave Scanning Radiometer 2)搭载在JAXA的GCOM-W1卫星上,2012年发射,设计寿命虽然早已超过,但到现在依然在稳定传数据。它属于被动微波辐射计,靠接收地表自身发射的微波辐射来反演地球物理参数。跟光学卫星不一样,微波数据最大的优势是几乎不受云影响,夜里也能观测,这在多云地区做时序分析时太关键了。
从观测频率上看,AMSR-2涵盖了6.93、7.3、10.65、18.7、23.8、36.5、89.0 GHz等通道。不同频率对应的地表信息深度和空间分辨率差别非常大:低频如6.9 GHz对土壤水分更敏感,穿透能力更强,但分辨率粗,像元分辨率在60公里左右;89 GHz分辨率能做到5公里左右,但主要反映的是地表壳温和大气信息,对土壤水分反演基本帮不上忙。所以做土壤水分研究,你关注的通道基本集中在C波段和X波段。
JAXA基于这些原始观测,生成了一套从L1到L3的产品线:
- L1A/L1R:亮度温度(Brightness Temperature,Tb),是反演一切地球物理参数的基础输入;
- L2:沿轨道(轨道扫描条带)的地球物理参数产品,比如土壤水分(L2SM)、积雪深度(L2SN)、海面温度(L2SST)、降水量(L2PR)等;
- L3:在L2基础上投影到等经纬度网格的时空合成产品,标准网格是0.1度和0.25度,分日、旬、月合成。
值得注意的是,JAXA官方产品里你还可以拿到“几何校正后的Tb”(L1R),这在很多研究里反而是最稳的选择——如果你打算自己跑反演模型,而不是直接使用官方地球物理参数,那L1R数据才是你的核心输入。
1.2 JAXA官方产品与NASA LPRM产品的关系
很多新手会问:既然JAXA官方已经发布了土壤水分产品,为什么还要费劲去下载LPRM?这里面的门道在于,LPRM全称Land Parameter Retrieval Model,是NASA这边基于AMSR-2亮度温度独立反演的一套土壤水分、植被光学厚度和地表温度产品,并不等于JAXA官方产品。
两套数据在反演算法、辅助数据、时间覆盖和产品分发渠道上完全不同。JAXA官方L2SM主要基于陆面微波辐射传输模型和单通道/多通道组合算法,产品由G-Portal分发;LPRM产品则由NASA的GES DISC分发,它使用的反演框架在学界应用非常广泛。不同的算法选择会直接影响数据结果和后续分析。
另外需要留心的是:JAXA官方L2/L3产品并不默认使用统一的植被参数,而LPRM亮点之一就在于它是一个完整的陆面参数反演系统——它从同一组微波Tb同时反演土壤水分、植被光学厚度和地表温度,三个变量在物理上自洽,这就避免了你只取土壤水分时忽略植被影响带来的误差。
1.3 两个来源怎么选:需求决定渠道
我个人的选型经验可以总结成一句话:你要做“研究级”的土壤水分分析,优先考虑LPRM;你要做传感器定标、通道特征分析或自己跑辐射传输模型,那就去JAXA拿L1R;你要用积雪、海冰、降水等官方成熟产品,留在JAXA体系内效率更高。
| 对比维度 | JAXA G-Portal | NASA GES DISC(LPRM) |
|---|---|---|
| 数据层级 | L1R/L2/L3 | L2/L3(以土壤水分、植被光学厚度、地表温度为主) |
| 典型网格 | 0.1°/0.25°等经纬度 | EASE-Grid(0.25°为主) |
| 账号体系 | JAXA G-Portal账号 | NASA Earthdata账号(URS统一认证) |
| 下载限制 | 有配额限制,按体积计算 | 无显式配额但有过期凭证机制 |
| 适用人群 | 需要官方Tb/冰雪/海温产品的用户 | 陆面水文、农业干旱、植被监测研究 |
2. JAXA G-Portal落地实操:从注册到拿到第一幅影像
2.1 账号申请与基础认证
去JAXA G-Portal下载数据,第一步就是注册账号。打开G-Portal网站后,从登录入口进入注册流程,需要填机构邮箱、姓名、所属机构、研究用途等信息。这里有个实操建议:机构邮箱尽量填完整,用途描述不要随便写“test”“study”之类太模糊的词,因为JAXA审核人员会人工过一遍申请,用途写清楚是“for soil moisture validation in academic research”这类具体描述,通过速度明显更快。我见过同行用个人邮箱申请被卡了一个多月的,所以这块别偷懒。
注册完成后,登录系统。G-Portal的界面是全英文的,左侧是数据产品树,右侧是地图预览区。整体逻辑跟大多数卫星数据门户类似,但有几个交互细节初次用会懵:一是数据产品的“版本号”藏在产品名称后面的括号里;二是在地图上拉框选择研究区时,系统会自动在查询条件里生成多边形经纬度坐标,但默认的坐标精度会影响之后出现的文件数量;三是JAXA对每条数据记录提供的是“购物车式”批量勾选,而不是单个文件的即时下载链接。
2.2 检索条件设置
我第一次在G-Portal上检索AMSR-2 L3土壤水分产品(L3SM)时,因为条件设置太宽,结果返回了上万个文件,页面几乎卡死。后来总结出合理的检索设置顺序:
- 产品层级:先选L3,再选L3SM(日合成);
- 时间范围:逐月或者逐旬框选。G-Portal对单次检索能返回的文件数有限制,时间范围拉太长会被系统直接拦截或截断;
- 空间范围:使用地图拉框,或者手动输入经纬度边界。手动输入时注意经度范围不要跨过180度线,跨日期变更线时要拆成两次查询;
- 版本:优先选择最新版本(比如产品修订版),因为修订版会修复算法参数和地理定位误差;
- 输出格式:G-Portal默认给HDF5(.h5)格式,AMSR-2官方产品大多以HDF5组织。
检索结果会以列表形式出现,每一行包含文件名、时间、空间覆盖、数据大小。这里我给一个常见坑:列表里每条记录后面有个“DL”按钮,但那个按钮常常被浏览器拦截弹窗或者因为文件较大而超时,所以不要挨个去点,尽量用“Select All”加入购物车,然后在购物车里生成批量下载脚本。
2.3 利用脚本化方式从G-Portal批量下载
G-Portal的批量下载本质上是在“购物车”页面生成一个自定义的下载链接集。你可以把购物车里的文件清单导出成文本,然后通过wget一类的工具进行批量获取。实际操作时,认证信息需要附加到URL里,格式大致如下:
wget -q -O L3SM_20230101.h5 "https://gportal.jaxa.jp/download/GCOM-W/GCOM-W.AMSR2.L3SM.20230101.h5?user_id=你的ID&user_password=你的密码"这里要注意:把密码直接放在命令行里有泄露风险,如果是个人电脑做一次性下载问题不大,但如果放在共享服务器上,建议改用下载列表加用户交互输入的方式。另外,JAXA下载服务器对请求头里的User-Agent比较敏感,默认wget的UA可能被拒,加一个--user-agent="Mozilla/5.0"往往就能解决。
从G-Portal批量下载时,最让人头疼的是配额限制。JAXA的配额不是按文件个数算的,而是按累计数据量算的。所以当下载到一半突然报错,HTTP状态码返回403或者503时,大概率就是配额用完了。解决方法是等配额定时重置后再继续,或者把下载任务拆成小批次,分时段执行,避免一次性把配额打满。
还有一个细节容易被忽略:G-Portal提供的文件名里隐含了产品版本号,下载后改名要谨慎。因为后续做数据处理时,轨道号、采集时间、版本信息都能从文件名里解析出来,改名等于给自己埋雷。我在实际项目中就把下载脚本里的原文件名完整保留,本地目录另外建一套便于阅读的软链接,这样两头都不误。
3. 为什么我改用LPRM产品:算法选择背后的逻辑
3.1 LPRM反演逻辑与官方算法到底差在哪
LPRM是一种基于物理模型的陆面参数反演算法。它的核心思想是利用微波辐射传输的物理关系式,将地表亮温表示为地表温度、发射率和植被透过率的函数,然后同时反演这三个变量。具体到土壤水分,LPRM通过发射率模型(如植被介电常数模型)将土壤介电常数与土壤体积含水量联系起来,这是一个从“亮温-发射率-介电常数-含水量”的完整链条。
JAXA官方L2SM产品在算法上也在不断演进,但它更多服务于“系统化业务产品”这一定位,数据传输链路、定标参数和业务化快速生产的需求导致其在某些地表条件下存在明显的不确定性,特别是在植被茂密区和山区。LPRM则更适合研究场景,因为它允许你用多个频率的Tb做交叉验证,并且产品自带质量标识(数据质量标志),在使用时可以按质量筛选。
我在西北半干旱区的实验中发现,裸地和稀疏草地场景下,LPRM的土壤水分产品与站点实测数据的相关系数明显高于JAXA官方L2SM在同一时期的对应值。但在森林覆盖度高的区域,两套产品的误差都变大,这主要是微波在高植被覆盖区的饱和效应在起作用,跟算法本身关系不大。这种对比并不代表LPRM一定更好,而是说明在不同应用场景下,算法选择一定要结合你的研究区下垫面特征。
3.2 GES DISC检索LPRM产品的具体操作
NASA的GES DISC已经全面迁移到Earthdata体系。你现在下载LPRM产品,需要走的是NASA Earthdata账号。如果你是第一次用,流程大致是:
- 提前在Earthdata官网注册用户(URS统一认证),用一个常用邮箱即可;
- 回到GES DISC的Earthdata Search界面,在搜索框输入“AMSR2 LPRM”;
- 结果列表会出现多个LPRM产品,例如土壤水分、植被光学厚度(VOD)、地表温度(LST)等不同参数组合;
- 选择你要的参数集,进入集合页面;此时页面会提供日期范围选择、空间范围选择(可绘制多边形或输入包围盒);
- 提交查询后进入文件列表,选中需要的文件,加入下载购物车;
- 下载数据时,可以选择直接以HTTPS方式下载文件,也可以生成脚本以Bulk Download方式批量获取。
GES DISC的数据下载界面不像JAXA那样需要用“附加在URL里的临时参数”,而是基于Bearer Token机制。直接在浏览器里点击文件链接、登录后就能完整下载;但如果用wget或脚本程序不带token去访问,就会碰到401错误。因此如果你打算写程序批量拉取,比较省事的方式是使用Earthdata提供的Python库来管理登录会话,代码大概长这样:
import earthaccess import xarray as xr # 触发登录,会在本机缓存凭证 auth = earthaccess.login() results = earthaccess.search_data( short_name="<你搜到的LPRM产品Short Name>", bounding_box=(-110, 35, -100, 40), temporal=("2023-06-01", "2023-06-30"), ) files = earthaccess.download(results, "./amsr2_lprm")这段代码看起来简单,其实已经把“搜索数据-解析文件链接-带凭证下载”整个链路封装好了。earthaccess库会自动处理token刷新,比手工带token的wget命令稳太多。
3.3 数据格式与检验清单
LPRM产品下载下来是HDF5或NetCDF格式,这取决于具体产品版本。不同版本命名规则也有差异,但常见变量包括soil_moisture(m³/m³)、vegetation_optical_depth(无量纲)、surface_temperature(K)等。
拿到文件后,我建议在正式进入处理流程前先做一遍快速检查:
- 打开文件,检查
soil_moisture数值范围是否在0~0.6 m³/m³之间。如果出现大量负值或大于0.7的离群值,多半是地表有水体或者射频干扰(RFI)影响; - 检查经纬度变量是否存在缺失或边界错位。EASE-Grid投影与等经纬度网格的坐标转换容易出现整体偏移,如果研究区边界在山地有几十公里的位移,要检查投影参数;
- 检查数据是否包含
_FillValue属性,很多水文分析工具在遇到填充值时如果不设置自动过滤,统计结果会错得离谱。
我一般会在下载完成之后写一个非常短的脚本批量扫描本地文件,输出每个文件的最小/最大/均值、时间覆盖和像元数。这个做法看起来多了一步,但能在后续省下大量排查时间。
4. 批量下载效率优化:从逐个点按到一句话跑完
4.1 时间维度裁剪与请求拆分
AMSR-2数据从2012年到现在,日产品文件数以万计。如果你需要的是长时间序列,一次性发起全时段检索,无论是JAXA还是GES DISC几乎都会“不响应”或超时。我用的方式是按年份拆请求,每个月再拆成若干批次。比如要做2015到2023年的土壤水分数据,就写一个循环,让程序逐年去搜索、下载,这样即使某一年因为网络原因失败了,重跑也只影响那一段。
时间裁剪本身在GES DISC的检索界面里就有对应参数,JAXA G-Portal则更依赖用户在检索条件里手动填“Start Time”和“End Time”。无论哪个平台,请求粒度都不要小于“天”级,尤其JAXA对短时间窗口的请求反而会处理得更慢——因为它内部是先把底层文件索引过一遍,再对时间字段做过滤。
4.2 空间裁剪:不要盲目下载全球数据
AMSR-2原始轨道数据或L3全球网格数据,一个日文件的体量在几十MB到上百MB之间。如果你只做某一个区域的研究,下载全球数据纯属浪费存储和带宽。LPRM在GES DISC里支持空间裁剪(Subset),你可以只下载研究区范围内的像元,这会让下载体积缩小到原来的几十分之一。
但要注意,GES DISC的空间裁剪逻辑是“对请求时间范围的每个文件都做一次切割”,所以当你把整个时间序列都做空间裁剪提交时,请求数量依然巨大。我的经验是:先做时间裁剪拿到文件清单,再把清单按空间范围裁剪后生成的URL脚本保存下来,最后通过脚本批量下载,而不是在交互页面上反复点。
另外,在JAXA G-Portal里则没有这么灵活的空间裁剪功能,它提供的L3数据都是全球格网。如果你必须用JAXA数据又不想下全球范围,就只能在本地预处理时加载全球文件、再裁剪目标区域。这种情况下,建议使用xarray或gdal完成裁剪,因为HDF5文件自带地理坐标信息,裁剪本身不会太难。
4.3 并发、断点续传与重试策略
批量下载AMSR-2数据,最大的效率瓶颈往往不是带宽,而是单线程模式下“请求-等待下载-写盘”的串行浪费。常用的优化方法是多线程并发。我测试过采用aria2或Python的concurrent.futures做并发下载,3到4个并发就能把链路带宽用满,更高的并发反而会触发服务器的限流,得不偿失。
并发下载的关键是断点续传。无论是wget还是curl都支持-c参数,Python的requests库则需要自己处理Range头。实际使用中,aria2是最省心的方案,它天生支持分段下载、断点续传和最大连接数限制:
aria2c -x 4 -s 4 -c -i urls.txt --dir=./amsr2_lprm --retry-wait=30这里-x 4表示每个服务器最多建立4个连接,-s 4表示按4段进行分段下载,-c开启断点续传,--retry-wait在下载失败后等待30秒再重试。还需要加一个最大尝试次数的参数,比如--max-tries=5,防止单个坏文件导致整个任务挂在某一点上。
对于GES DISC用token下载的场景,aria2直接读带token的URL列表时可能因为token过期导致失败,这时候token过期会在日志中体现为401错误。处理办法是把earthaccess下载获得的新鲜URL写入文件后立刻启动aria2,并且把批量脚本拆成多个小批次,每批300到500个URL,这样即使一批失败,重跑本批时重新获取token即可,整体影响可控。
4.4 文件校验与归档
下载完成后的校验这步,很多人图省事会跳过,但AMSR-2数据因为体量大、来源多,传输中偶尔出现文件损坏是正常的。我在批量下载后统一做一遍HDF5文件完整性测试:
import h5py import glob files = glob.glob("./amsr2_lprm/*/*.h5") for f in files: try: with h5py.File(f, "r") as ds: _ = ds[list(ds.keys())[0]][:10] except Exception as e: print("corrupt:", f, e)这个逻辑很简单:尝试打开文件并读取第一个数据集的少量数据,如果抛异常就说明文件不完整,需要重新下载。批量转换时建议把下载文件的原始文件名保留好,以便重新请求。归档目录建议按年份/月份分层,文件命名统一为“简称_时间戳_版本号”格式,这能为后续处理省掉非常多的时间。
5. 常见问题排错实录:配额、凭证与数据质量
5.1 G-Portal下载配额耗尽与请求频率过快的表现
JAXA G-Portal出现配额耗尽时,常见报错包括HTTP 403、页面提示“Quota exceeded”或下载链接返回一个很小的HTML错误页面而不是目标文件。遇到这个情况不要反复点重试,因为配额是按时间段滚动的,短时间内反复请求不会让配额恢复,反而可能触发临时封禁。
另一个容易忽视的是请求频率过快导致封禁。无论JAXA还是NASA,对来自同一IP的高频请求都比较敏感。建议在批量下载脚本里加入随机延时,比如每50到100个文件之间sleep 3到5秒。这个操作不会显著拖慢整体速度,却能明显降低被封的概率。
5.2 NASA Earthdata凭证过期与401错误
从GES DISC下载LPRM文件时,最常见的是401 Unauthorized。原因是Earthdata的token有效期不是永久性的,甚至部分生成的HTTPS下载链接会在一段时间后失效。解决方式就是使用earthaccess或Earthdata提供的token刷新机制生成新鲜链接。
在写脚本时,我的做法是先把文件清单检索出来,然后统一调用earthaccess的download接口,由它内部自动处理凭证。如果一个文件下载失败,捕获异常后单独记录到失败列表中;全部跑完后,重新初始化会话,再针对失败列表单独重试。这个模式在处理几千个文件时非常稳。
5.3 空间范围与实际轨道覆盖不符导致文件缺失
有段时间我检索LPRM在某个区域的日数据,明明时间范围和研究区都没问题,但就是有几个日期找不到文件。后来排查才发现,GES DISC的产品集合有几个不同的版本和网格版本,比如按轨道扫描数据和格点化数据是分开的集合,检索条件里没有选择正确的网格版本时,文件列表就会“看似缺失”。
还有一种情况是:AMSR-2的升轨和降轨数据分开展示。对中纬度地区来说,升轨大约在地方时下午1点半过境,降轨大约在凌晨1点半过境,两轨的数据文件是分开的。如果你做日尺度土壤水分反演,可能只需要降轨数据,但检索时如果不注意轨道方向,就会把升轨数据也包含进去,既浪费存储又增加处理负担。JAXA产品和LPRM产品都能看到轨道方向说明,通常在文件名里有A(Ascending)或D(Descending)标记。
5.4 数据质量标志与负值的处理
LPRM产品自带质量标识字段,不同版本中它可能叫quality_flag或者类似的变量名。建议在预处理时分两步:第一步按质量标识过滤像元,把不可靠像元设为NaN;第二步设置合理的物理范围,比如土壤水分不小于0且不高于0.6 m³/m³,超出范围的按无效处理。
做时序分析时,负的土壤水分值在下雨或地表水体影响下偶尔会出现。如果只是个别像素出现负值,直接过滤掉即可;但如果某个轨道大量像元整体异常(例如大片负值或统一近似一个常数),那多半是轨道定位偏差或地表水体污染,需要直接剔除该时间段。处理时保留一张“剔除明细表”,这对文章方法和数据说明部分很有用。
6. 少有人提但很实用的经验
最后再分享两个属于“做了才知道”的细节。
第一个是磁盘空间规划。AMSR-2的L3全球日产品每个文件在几十MB的量级,一年下来少说也有几十GB,如果同时下载JAXA全球产品和LPRM多变量产品,几百GB的消耗非常正常。下载前先看你剩余空间,再按“原始文件-预处理文件-分析输出”三个目录分层。工作到一半磁盘写满,比下载失败更让人崩溃。
第二个是保留数据获取日志。我建议把下载脚本的日志统一保留成文本,记录每个文件的URL、下载时间、大小和校验结果。后续如果审稿人要求提供数据版本说明,或者你发现某个时段的异常需要回溯数据源头,这些日志就是最重要的线索。我自己就靠这份日志定位过一次LPRM版本更新后土壤水分均值漂移的问题,否则根本不知道数据是什么时候换的版本。
AMSR-2数据下载这事,看一遍文档觉得简单,真正操作才会遇到各种平台细节。希望这篇实战记录能帮你少走一段弯路。