简介这是一份来自NASA地球观测项目的美国区域地质数据包以Shapefile矢量格式打包三组分区数据适合地质科研人员、GIS学习者与规划从业者开展区域地质分析和制图。包内共19个文件涵盖shp几何图层、dbf属性表、prj投影坐标、sbn与sbx空间索引及xml元数据整体仅93KB传输与加载非常轻量。au45cg对应的三组编号分区可直接导入ArcGIS、QGIS等主流GIS软件查看地形高程、地质构造、土壤类型等属性信息并叠加遥感影像或其他专题图层。目前已有213人学习下载。借助完整的投影与索引配置使用者可确保地理坐标准确对齐快速检索并提取特定区域矢量要素适用于地质灾害风险初判、土地资源规划或区域地质对比研究等场景。1. NASA地质数据下载第一个批次“01”为什么值得当成管线来做拿到一份名为“NASA下载的美国地质数据01”的目录时多数人的第一反应是找个工具赶紧把文件拉下来。但真正跑过这类任务的人都知道NASA数据下载最耗时的地方根本不在网速上——认证、文件格式、坐标系三关至少能吃掉半天。我曾见过某开发者按一个SRTM链接清单开工两百多个文件下载完能正常打开的不到十个剩下的不是半截就是HTML错误页一整天全耗在排查上。这个标题的精髓不在“NASA”也不在“地质数据”而在最后的“01”。它意味着这是第一批次后面大概率还有“02”“03”。所以第一步不是下载而是把整个流程设计成可复用的管线怎么选产品、怎么圈定范围、怎么批量拉取、怎么校验完整性。这篇文章就按这个顺序讲透适合需要本地地形、地表覆盖或重力场数据的GIS开发者、遥感方向从业者和环境研究者。读完你不仅能跑通“01”还能让后续批次全部照抄这套方案。2. 选数据源先分家族SRTM、ASTER、MODIS与重力场怎么定2.1 SRTM还是ASTER先看你要地形还是地表成分SRTM是航天飞机雷达地形测绘任务的成果用干涉雷达测出的是地表高程单位是米输出通常是GeoTIFF全球陆地在北纬60度到南纬56度之间基本覆盖。ASTER则是多光谱被动影像记录的是地表的反射辐射特性适合做矿物填图、植被覆盖、地表温度反演。两者名字容易混因为都挂在NASA地球观测系统名下但一个回答“地面长什么样”一个回答“地面是什么做的”。判断选哪个我一般看一个问题你要分析的是地表形态还是地表物质。做坡度、流域、视域分析选SRTM做岩性区分、热异常、植被指数选ASTER。拿到候选文件后别急着下先用GDAL看一眼文件头确认数据类型和坐标系是否和你项目匹配# 检查一个SRTM或ASTER文件的基础信息 gdalinfo /path/to/SRTM_N45E001.tif | grep -E Size|Pixel Size|Coordinate System|Data Type这一行命令能同时确认三件事影像尺寸决定处理耗时像素尺寸告诉你真实分辨率坐标系决定要不要做投影转换。SRTM常见输出是WGS84经纬度坐标ASTER L1T则多为UTM投影这个差异后面会专门讲坑。先在这里记住检查文件头永远是第一步不要拿一个没确认过坐标系的数据往下做。2.2 MODIS的地表产品时间序列场景的默认选择如果研究目标是看一片区域的地表参数随时间怎么变比如植被指数、地表温度、积雪覆盖MODIS系列是默认选择。它搭载在Terra和Aqua两颗卫星上中等分辨率成像光谱仪空间分辨率在250米到1公里之间时间分辨率高基本每天都能过境。NASA把处理好的地表产品直接挂出来不用自己从原始辐亮度反演。选产品时认前缀MOD开头来自TerraMYD开头来自Aqua。两者传感器相同但过境时间不同做日尺度分析时会互补。这类产品大多是HDF格式里面同时携带科学数据集和元数据直接用rasterio读取时要注意选对子数据集名称不能像读GeoTIFF那样一把梭。MODIS适合粗粒度长时间序列不适合精细到米的局部地形研究这是选型时最容易误判的地方。2.3 GRACE与磁场数据被低估的小而冷门家族很多人做地质数据分析时忽略了一个重要家族GRACE及后续GRACE-FO重力卫星产品。它不给出影像给的是全球重力场模型的球谐系数或网格化产品常见格式是NetCDF。通过重力变化可以反演区域水储量变化、冰川消融、地下水消耗这些是SRTM和MODIS完全看不到的信息。这个家族的特点是数据量小、处理逻辑不同。下载下来通常不是一景影像而是一组时间序列需要xarray打开后做滤波和趋势分析。适合研究大尺度水文与地质过程的场景。如果“01”批次里混有这类文件注意别用遥感影像流程去处理NetCDF多维数组和二维栅格的读写、统计方式都不一样。2.4 用一张决策表结束选型纠结数据家族典型产品方向常见格式分辨率适合场景高程/地形SRTM/NASADEMGeoTIFF30米/90米坡度、流域、视域、切割地图地表多光谱ASTER L1T/L2HDF/GeoTIFF15-90米矿物填图、地表温度、植被中分辨率地表MODIS产品HDF250米-1公里长时间序列地表变化重力场GRACE系列NetCDF约300公里水储量、区域重力异常选型没有唯一正确答案但有一个固定的先后顺序先写清楚业务目标再倒推数据家族最后才打开下载界面。跳过这一步直接搜数据的人最常在ASTER和SRTM之间反复纠结浪费的时间比下载本身还多。3. 在Earthdata Search圈定数据从检索词到可用的批量下载链接3.1 注册Earthdata账号并生成App TokenNASA的Earthdata平台要求登录后才能下载绝大多数数据产品匿名访问只对部分预生成的公开文件开放。注册流程不复杂填邮箱、设置密码、验证邮箱即可。真正让人卡住的是后续认证方式命令行下载时服务器不认密码而是认一个叫App Token的令牌或者基于cookie的会话凭证。生成App Token的位置在个人账号的Application页面创建后会得到一个字符串。这个字符串和密码同等重要泄露了别人就能用你的配额下载数据。常见做法是把它写进netrc文件Unix系路径是~/.netrcWindows是%USERPROFILE%_netrc而不是直接暴露在命令行里# netrc文件格式machine填URS认证地址login和password分别填账号与App Token echo machine urs.earthdata.nasa.gov login 你的邮箱 password 你的AppToken ~/.netrc chmod 600 ~/.netrc最后一行权限设置很关键不收紧权限某些安全扫描工具会直接告警。有了netrcwget和curl就能用它自动完成认证不用在命令里明文带密码。3.2 用检索条件把数据量压到单批次Earthdata Search的检索框支持按产品名、时间范围、空间范围、云覆盖等多维条件过滤。常见做法是先在地图上拖出研究区域再把时间范围缩到任务需要的窗口最后把云覆盖阈值设到合理水平。这一套筛完数据量通常能少一个数量级。为什么要把“01”压成单批次因为批量下载的校验逻辑依赖“这一批应该有多少个文件、总共多大”。数据量太大一次拉取时间过长中途网络波动概率急剧上升数据量太小又浪费了管线搭建成本。我个人习惯是把单批控制在500个文件以内、总大小不超过20GB这个规模既能验证流程又不会让下载夜跑时心里没底。在界面上做完筛选后把结果全部加入购物车进入下载页面。Earthdata会生成一个下载链接列表文件每一行是一个文件的完整URL。这个列表就是后续一切操作的基础。3.3 从购物车导出链接列表购物车导出时通常有两种选择直接下载或生成脚本下载。直接下载适合文件数量少的场景生成脚本则适合批量。实际上生成的文件是一份文本清单每一行是一个带签名的下载地址有效期一般有几十个小时足够完成一批次下载。拿到清单后的第一件事不是直接跑而是只取其中一条URL单独试下载一次。这个习惯能挡住80%的无效劳动——如果这一条因为认证或格式问题拉不下来跑整份清单只会产生一堆垃圾文件。试通单条链接后再交给批量命令处理。3.4 跑通第一个wget下载命令单条测试用下面的命令最稳它在认证和文件名两个方面都做了针对性处理# 从下载列表里挑一条URL单独测试 wget --load-cookies ~/.urs_cookies \ --save-cookies ~/.urs_cookies \ --auth-no-challenge \ --keep-session-cookies \ --content-disposition \ https://example.nasa.gov/data/file.tif参数含义要理解透--load-cookies和--save-cookies让会话凭证在多次请求间延续避免下到一半认证失效--auth-no-challenge是NASA URS认证体系特有的需求——服务器有时不主动发起质询但客户端也要预先带上认证信息--keep-session-cookies保留会话级cookie这是NASA下载链接能持续使用几十个小时的关键--content-disposition则让文件保存为服务器指定的原始文件名因为很多下载链接本体是一串无意义的参数直接按URL命名会得到一堆乱码。如果这一步顺利跑通说明认证链路正常可以放心进入下一步批量下载。常见的失败点是401或403原因绝大多数是netrc没生效或App Token过期。4. 让下载脚本自己跑完wget断点续传、校验与三分钟检查4.1 断点续传与重试组合一个可过夜的下载命令批量下载会遇到两类典型故障网络抖动导致连接中途断开以及服务器限流导致短时间内并发请求被拒绝。对这两类问题wget有几个参数组合能很有效地兜底足以支撑过夜运行# 批量下载断点续传 失败重试适合丢后台跑过夜 wget --continue \ --tries5 \ --retry-connrefused \ --waitretry10 \ --random-wait \ --timeout60 \ --load-cookies ~/.urs_cookies \ --save-cookies ~/.urs_cookies \ --auth-no-challenge \ --keep-session-cookies \ --content-disposition \ -i download_links.txt \ -o download.log逐一说清楚--continue是断点续传开关文件已下载的部分不会重新拉取断线后再次运行就能接着走--tries5允许单个文件连续失败5次才放弃--retry-connrefused把“连接被拒绝”也计入可重试的失败类型--waitretry10表示每次重试前等待10秒防止重试太密反而触发风控--random-wait在请求之间加入随机延迟降低服务器限流概率--timeout60设60秒无响应即断开让--continue在下一次重试时从断点续传-o download.log把进度写进日志文件第二天只需看这个日志就能判断整夜发生了什么。这个命令比单纯的wget -c -i多做了三层防护但只要磁盘满或网络长时间中断仍可能出现部分文件损坏。所以下载完成只是第一步校验才是真正决定数据能不能用的环节。4.2 校验下载完整性用文件大小与gdalinfo双保险校验的第一层是文件大小。下载开始前先对链接列表做一次批量HEAD请求拿到服务器端的Content-Length存成一份“期望尺寸表”下载完成后逐个比对本地文件大小。这个做法能在几秒内发现被截断的文件绝不依赖肉眼去看文件列表# 从下载列表取一条URL获取服务器返回的真实文件大小 url$(head -1 download_links.txt) curl -sIL $url | grep -i content-length如果Content-Length和本地ls -l显示的大小不一致这个文件必坏无疑直接标记为待重下。大小一致也不能打包票——偶尔会有请求被中间设备改写但长度碰巧相同的情况所以第二层校验用gdalinfo它会真正打开文件头解析数据结构。一个结构完整的GeoTIFF或HDFgdalinfo能正常输出元数据半截文件通常直接报错或卡死在读取阶段。4.3 下载后的三分钟检查清单下载完成后我会按固定顺序做检查全程不超过三分钟第一步统计文件数量确认和链接列表里的行数一致。少了一个文件可能是--tries用尽或磁盘空间不足日志里会有记录。第二步抽查三到五个不同尺度的文件用gdalinfo确认可读。这一步能把损坏率从“猜测”变成“量化”。第三步记录这批数据的基本元信息坐标系、像元大小、文件名编码规则。比如SRTM的命名是N45E001这样按经纬度分块看看这批数据是否覆盖了目标区域四周的块。发现缺少边界的块及时补充下载比后面拼接时再发现缺一块省事得多。这三分钟看起来琐碎实际上就是后面所有分析的进场安检。跳过这个环节直接做业务分析一旦源头数据有问题返工成本是下载时间的十倍不止。5. 避坑指南NASA地质数据下载的六个典型翻车现场5.1 401 Unauthorized反复出现现象批量下载跑到一半日志里开始连续刷401。原因最普遍的是App Token过期或者cookie在长耗时下载中失效。某些服务器也会因为请求频率过高临时拒绝认证。解决先停止任务去Earthdata重新生成App Token并更新netrc如果是频率问题在wget命令中加大--waitretry值并保持--random-wait。不要反复手动试同一份链接那样只会加重限流。5.2 SRTM在北纬60度以北没有覆盖现象按图幅号拼了一批高纬度文件名结果下载时大量404。原因SRTM任务的设计覆盖范围只到北纬60度更北的区域没有数据链接自然不存在。解决换用覆盖极区的产品比如北极数字高程模型或ASTER GDEM补充如果不要求统一来源可以把高纬度区域切给其他产品做。这个坑最恶心的地方在于它不是下载环节报错而是等拼接时才发现地图上缺了一大块所以选型阶段就要看覆盖范围说明。5.3 下载到一半的文件“打不开”现象gdalinfo报错提示文件大小和预期不符或者直接卡死。原因下载时磁盘满了或者网络中断且wget退出前没有续传完成。解决用--continue重新拉取对应文件再用文件大小比对验证。如果文件反复损坏检查磁盘空间空间不足时--continue会静默失败日志里看不出来。5.4 UTM与经纬度坐标系混在一个项目里现象两景相邻ASTER数据在同一GIS工程里拼接错位好几公里。原因ASTER L1T按UTM分带输出不同带号的数据虽然相邻坐标系基准点不同直接拼接必然错位。解决统一投影到WGS84经纬度后再拼接# 把UTM投影的ASTER数据统一转成WGS84经纬度双线性重采样保留细节 gdalwarp -t_srs EPSG:4326 -r bilinear input_ASTER_UTM.tif output_WGS84.tif这个坑几乎每个用ASTER的人都会踩一次。选型时如果发现产品标着UTM就要评估后续有多少文件需要做投影转换。5.5 下载列表里混进了HTML错误页现象某个文件下载完成后只有几KB到几十KB用文本编辑器打开全是HTML标签。原因下载链接过期或签名校验失败服务器返回了一个错误提示页面但wget还按正常HTTP 200状态保存了下来。解决校验环节加一步过滤所有小于某阈值的文件并打开检查内容重新从购物车生成新的下载链接后再补这批文件。这个坑在大规模下载时非常常见手动检查很容易漏掉几十个碎片文件。5.6 文件名批量改名后元数据丢失现象把一批.HDF文件手动改成.TIF后缀结果常规工具全部打不开。原因格式是由文件内部结构决定的扩展名只是外壳。HDF文件内部可能包含多个子数据集强制改后缀后文件类型识别失败工具链全线罢工。解决用真正的转换工具处理# 将HDF中的某个子数据集转换为GeoTIFF gdal_translate -of GTiff HDF4_EOS:EOS_GRID:input.hdf:Grid:Data_Field output.tif记住一点文件名可以任性改元数据和格式结构改不了。任何“改个后缀就能统一格式”的想法都会浪费半天时间。6. 把“01”变成可复用的本地数据集索引、校验与快速验证6.1 写一个校验脚本把“01”批次归档下载和初次校验完成后我会把校验动作固化成脚本而不是每次都敲命令。一个简单的Python脚本就能把“文件大小对比”和“gdalinfo可读检查”串起来并把结果输出为一份状态清单import json from pathlib import Path # 读取下载前保存的期望尺寸表和本地文件逐一对比并输出状态 folder Path(./01_srtm) sizes json.loads(Path(server_sizes.json).read_text()) for name, meta in sizes.items(): p folder / name if p.exists() and p.stat().st_size meta[size]: meta[status] ok else: meta[status] corrupted print(f{name}: {meta[status]})这个脚本的价值在于“01”批次跑完后“02”“03”可以直接复用。把下载前的期望尺寸表保留好每次校验只需换目录路径。文件完整的状态会写进元数据后续分析时不用再回溯下载过程。6.2 用极简索引表管理批次的关键字段我一般会在每个批次目录里放一个索引表记录文件号、产品类型、覆盖范围、大小、状态这几个字段。不需要复杂数据库一个CSV或表格就够文件名产品类型覆盖范围投影大小(MB)状态N45E001.tifSRTM45-46N, 1-2EWGS8425.3okN45E002.tifSRTM45-46N, 2-3EWGS8424.8corrupted表虽简单却能在三种场景里救命有人问某区域有没有数据时10秒查完处理流程报错时快速定位是源数据问题还是算法问题批次多了以后一眼看清哪些文件该补下、哪些该重跑。6.3 快速验证数据可用性大文件先生成缩略图最后一步是生成一张缩略图快速确认数据内容在视觉上没有明显异常比如整片全黑、整片全白、条带断裂等。用rasterio加matplotlib几行代码就够import rasterio from rasterio.plot import show import matplotlib.pyplot as plt # 打开目标文件并输出缩略图到本地用于快速目检 with rasterio.open(01_srtm/N45E001.tif) as src: arr src.read(1) fig, ax plt.subplots(figsize(6, 6)) show(arr, cmapterrain, axax) fig.savefig(quick_check_N45E001.png, dpi100)缩略图不是给用户看的成果纯粹是给数据做“体检报告”。水文数据可以换成蓝色系高程数据用terrain色带判读速度极快。做这批数据最深的教训来自我的第一个批次任务当时跳过了文件大小校验直接做了拼接分析到最后出图才发现某几景数据在处理中途被截断返工重下的时间足够再做三个批次。从那以后每批数据落地都强制走一遍“大小比对、索引登记、缩略图目检”三步再急也不省。希望这篇能帮你在“01”批次上少走这一趟弯路。本文还有配套的精品资源点击获取
