ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

IGS精密星历备用下载地址与批量获取脚本实战

IGS精密星历备用下载地址与批量获取脚本实战 简介全球定位系统IGS精密星历备用下载地址指南是一份面向测绘、导航定位、地球物理及气象科研人员的实用参考文档。IGS精密星历是高精度GPS数据处理的关键基础实际工作中因网络波动、防火墙限制或主站临时维护常需多源备选下载通道。文档系统整理了IGS Final Orbits、Rapid Orbits以及UltraRapid Orbits12小时和00小时版本三大类产品的FTP备用地址来源覆盖NASA、UCSD、GSFC、IGN等权威机构并保留了%GGGG%等通配符格式便于配合TBC等软件自动批量获取对应日期文件包内仅含1个docx文件共314KB轻量易用可直接对照配置。内容还包含Internet Download Manager添加新站点、设置FTP/HTTP协议的具体说明能够帮助用户快速建立稳定可靠的星历获取通道减少因单一源故障造成的数据中断或项目延误。目前已有439人学习下载适合需要长期保障数据连续性和可靠性的高精度定位项目团队及科研人员参考使用。1. 为什么IGS精密星历常常需要备用下载地址GPS定位的精度上限很多时候不取决于接收机而取决于你手里拿到的那份星历质量。IGS国际GNSS服务发布的精密星历能把GPS卫星轨道精度从广播星历的米级压到厘米级做精密单点定位、卫星钟差评估或者天线相位中心标定时第一步都是把SP3或CLK文件正确下载到本地。问题是IGS的数据中心和所有公开科学数据设施一样会有维护窗口、迁移甚至访问策略调整某个常用入口可能在最需要数据的时候失效。这时候备用下载地址就不是“多一个选择”而是流程能否继续的底线。下面这套流程按单日下载、批量拉取、事后检查三段展开适合做GPS高精度解算的工程师和大地测量方向的研究生直接参照。2. IGS精密星历下载前要弄懂的产品分级和文件名规则GPS精密星历的下载看似是网络问题实际上一多半的失败源于文件名和路径拼错。在写下载命令之前先把IGS产品分级、SP3命名规则和目录结构对齐后面所有脚本都能少报几个错。2.1 三种产品怎么按时间延迟和精度选型IGS对外发布最终、快速、超快速三档精密星历。最终产品每天发布一次观测结束后大约12到18天对外提供GPS卫星轨道精度在2.5厘米上下快速产品延迟17到41小时精度和最终产品基本接近超快速产品又分预报和实测两部分实测部分延迟3到9小时轨道精度约3到5厘米。做事后处理的精密单点定位默认用最终产品因为它的轨道和钟差都经过了更充分的多系统联合解算做准实时质量评估或短时延解算才值得用快速或超快速。选型时还要看软件配置。比如RTKLIB的精密星历设置里可以选择brdc、igs、igr、igu选成igr后文件名前缀也必须是igr否则软件在星历匹配阶段会跳过文件。所以下载脚本里的文件前缀不是随意写的要跟着处理软件的要求走。2.2 SP3文件名里的GPS周、星期几和时间系统IGS精密星历文件名按igs20740.sp3.Z这类格式命名。igs表示最终产品紧接着四位数字2074是GPS周最后一位0表示星期几0是周日1是周一依此类推。快速产品前缀是igr超快速是igu。钟差文件用相同的主文件名只是扩展名不同例如igs20740.clk.Z高采样率版本会在clk后面多一段采样间隔标识。GPS周的零点在1980年1月6日每个整周从周日开始。手动用公历日期心算很容易踩跨年月坑最稳妥的办法是用时间戳算。下面这段bash函数可以直接复制到下载脚本里gps_epoch1980-01-06 target2024-10-01 days$(( ( $(date -d $target %s) - $(date -d $gps_epoch %s) ) / 86400 )) week$(( days / 7 )) dow$(( days % 7 )) printf igs%04d%d.sp3.Z\n $week $dow脚本先把两个日期转成Unix秒差值除以86400得到天数再分别对7取整除和余数。因为1980年1月6日正好是周日余数0就对应周日省去了单独的星期映射表。这段代码依赖GNU date在Linux发行版上直接可用macOS需要把date -d换成date -j -f %Y-%m-%d $target %s这种BSD写法。2.3 数据中心目录为什么按年和GPS周两级存放各数据中心的IGS产品目录基本都按products/年份/GPS周/文件结构存放例如2024年第2074个GPS周的文件放在products/2024/2074/下。每个周目录内的文件数量有限通常是一个周内每天一个SP3、一个CLK加上轨道摘要和质量报告归档和删除策略可以按周做磁盘配额管理也简单。实现脚本时要特别留意跨年周。一个GPS周可能跨两个公历年而目录路径里的年份用的是该GPS周所属年份不是观测日期所在的年份。GPS周和ISO周一样按包含该周周四的那一年来归属。如果脚本简单用系统日期拼年份年尾或年头就会出现大量404。2.4 主要数据中心和备用地址速查表IGS官方数据产品会同步到多个数据中心内容基本一致。下面这几个是我日常会用到的入口它们的产品更新取决于各中心同步节奏但最终产品归档都比较完整数据中心归属产品目录入口访问特点CDDISNASAhttps://cddis.nasa.gov/archive/gnss/products/归档最全需要Earthdata账号认证BKG德国联邦制图与大地测量局https://igs.bkg.bund.de/root_ftp/IGS/products/HTTPS匿名可访问欧洲延迟低IGN法国地理信息测绘院https://igs.ign.fr/pub/igs/products/历史数据保留时间长GFZ德国地学研究中心https://fs.dgfi.tum.de/gnss/products/欧洲备用节点目录结构和BKG接近CDDIS的匿名FTP通道在Earthdata账号体系启用后逐步收紧很多从旧教程里复制来的ftp://cddis.nasa.gov写法已经失效。我一般会把BKG或IGN放在curl脚本的第二个候选位置主站返回认证错误时直接切换不用人工干预。3. 单日IGS精密星历的备用下载命令与重试参数单日下载是所有批量任务的基础。单独把一天的文件抓到本地验证地址、参数、解压都正常再扩大到一周或一个月能省去后面反复排查的错误。3.1 先用HEAD请求确认备用地址可用在写进脚本之前建议先用HEAD请求把目录是否可访问确认一遍。下面这条命令访问BKG镜像的某个SP3文件-I让curl只取响应头不下载文件体curl -I -L --max-time 15 \ https://igs.bkg.bund.de/root_ftp/IGS/products/2024/2074/igs20740.sp3.Z正常情况会返回HTTP/1.1 200 OK响应头里的Content-Length可以顺便确认文件体积。返回403时先检查镜像是否启用了认证返回404时优先核对GPS周和年份目录是否跨年。这一条命令的成本很低但能提前暴露掉90%的路径拼接错误。3.2 curl下载单日文件参数按这个标准来确认地址可用后用下面这段命令完成单日下载year2024 week2074 dow0 basehttps://igs.bkg.bund.de/root_ftp/IGS/products/${year}/${week} curl -fSL \ --connect-timeout 30 \ --max-time 300 \ --retry 3 \ --retry-delay 5 \ -o igs${week}${dow}.sp3.Z \ ${base}/igs${week}${dow}.sp3.Z-f会让curl在HTTP返回4xx或5xx时直接以非零状态退出不把错误页面存成本地文件-S把服务端错误信息打到屏幕上-L跟随数据中心返回的重定向。--connect-timeout 30控制TCP连接等待--max-time 300限制整个下载时间适合容易挂起的网络环境。--retry 3 --retry-delay 5是在临时网络错误时重试重试间隔5秒。如果想把主站和备用站串起来可以再包一层循环for mirror in \ https://cddis.nasa.gov/archive/gnss/products \ https://igs.bkg.bund.de/root_ftp/IGS/products \ https://igs.ign.fr/pub/igs/products; do url${mirror}/${year}/${week}/igs${week}${dow}.sp3.Z echo trying: ${url} if curl -fSL --retry 2 -o igs${week}${dow}.sp3.Z $url; then break fi done循环里只要某个镜像下载成功就立刻break避免后续镜像重复请求。这个写法对临时切换入口很有用但要注意CDDIS现在需要账号认证如果已经带上认证信息记得放在每个候选地址上都有效的位置。3.3 wget的断点续传和重试怎么配合有些老旧服务器脚本还依赖wgetwget也可以完成同样的任务wget -c -t 3 -T 60 -O igs20740.sp3.Z \ https://igs.bkg.bund.de/root_ftp/IGS/products/2024/2074/igs20740.sp3.Z-c开启断点续传文件已经存在且服务器支持Range时会从断点继续适合下载一半被中断的情况-t 3是重试3次-T 60是每个连接的超时时间。需要说明的是断点续传并不总是节省流量部分数据中心对Range请求会让客户端重新传一遍所以下载几十KB的SP3文件时直接重新下载反而更快。3.4 备用地址切换的判断依据切换镜像不能靠猜要按HTTP状态码区分原因。我一般按下面这张表来判断HTTP状态码出现原因处理方式401/403访问需要认证或策略拒绝换BKG、IGN等免登录镜像404路径或文件不存在检查GPS周和年份计算429请求频率过高加大sleep间隔退避重试500/502/503服务端临时故障等待后重试或切换备用地址CDDIS的HTTPS服务在未认证时返回401的可能性高于403BKG和IGN对匿名HTTPS的支持更友好。脚本里遇到401或403直接跳到下一个镜像不要在同一镜像上反复重试否则可能触发更严格的限流。4. 批量下载IGS精密星历的脚本与SP3自检方法单日命令跑通后批量下载的核心问题变成了两个日期和文件的对应关系以及下载完的文件是否能直接进入解算。本节用一个可复用的脚本把这两件事一次做完。4.1 把GPS周计算封装成函数按日期生成文件列表要批量下载先得让程序知道目标日期属于哪个GPS周。把第2章那段计算过程封装成两个函数一个算周和星期几一个算归属年份calc_gps_week() { local target$1 local days$(( ( $(date -d $target %s) - $(date -d 1980-01-06 %s) ) / 86400 )) printf %d %d $(( days / 7 )) $(( days % 7 )) } gps_week_year() { local target$1 local wk dow read wk dow $(calc_gps_week $target) if [ $dow -le 4 ]; then date -d $target $((4 - dow)) day %Y else date -d $target - $((dow - 4)) day %Y fi }calc_gps_week输出两个数分别是GPS周和星期几gps_week_year用该周周四所在的公历年份作为目录年份。这样处理跨年周时URL里的年份不会和观测日期冲突。4.2 循环下载过去30天的SP3文件有了上述函数循环体就简洁了start2024-10-01 for i in $(seq 0 30); do d$(date -d $start $i day %Y-%m-%d) read wk dow $(calc_gps_week $d) year$(gps_week_year $d) mirrorhttps://igs.bkg.bund.de/root_ftp/IGS/products mkdir -p products/${wk} fileigs${wk}${dow}.sp3.Z outproducts/${wk}/${file} if [ ! -s $out ]; then curl -fSL --retry 2 -o $out ${mirror}/${year}/${wk}/${file} sleep 1 fi echo $d - ${wk} ${dow} ${out} done-s判断文件存在且大小非零所以脚本重复执行时不会重新下载已完成的文件sleep 1把请求间隔压到每秒一个避免触发数据中心的频率限制。如果任务覆盖几个月把seq 0 30换成seq 0 90或按需调整即可。4.3 扩展名切换把SP3和CLK一起纳入批量任务如果下游解算需要钟差文件循环里再套一个ext层for ext in sp3 clk; do fileigs${wk}${dow}.${ext}.Z outproducts/${wk}/${file} if [ ! -s $out ]; then curl -fSL --retry 2 -o $out ${mirror}/${year}/${wk}/${file} fi doneCLK文件的体积通常比SP3大一个数量级高采样钟差有时还会带clk_30s之类的后缀。下载前先通过curl -I确认该镜像是否提供对应变体避免脚本在404上反复打转。4.4 用Python解析SP3检查GPS卫星坐标是否完整下载完成后立刻做解析检查比等到解算报错再回头找原因高效得多。下面这段Python按SP3格式解析每颗GPS卫星的位置import re from pathlib import Path sp3_re re.compile(rP([GJREC])(\d{2})\s([-\d.])\s([-\d.])\s([-\d.])) def read_sp3(path): epoches {} current None with Path(path).open(encodingutf-8, errorsignore) as f: for line in f: if line.startswith(*): current line.strip() epoches[current] {} else: m sp3_re.match(line) if m: prn m.group(1) m.group(2) x, y, z map(float, m.groups()[2:5]) epoches[current][prn] (x, y, z) return epoches data read_sp3(products/2074/igs20740.sp3) for epoch, sat in list(data.items())[:3]: print(epoch, len(sat), sat.get(G01))代码按SP3的位置记录行做正则匹配提取系统名、PRN编号和三个坐标分量。SP3里的坐标单位是千米G01这类键就是GPS卫星的PRN号。输出中历元卫星数如果低于25颗就要怀疑文件是否被截断。4.5 批量下载并发不要开太高IGS备用镜像没有商业CDN的保护过高的并发会直接压出429或5xx。我一般用串行加sleep 1或者用xargs -P 4控制总并发数不超过4。批量任务持续时间本来就长没必要为省几分钟把镜像打挂。5. 下载后的SP3检查、解压与日志留底文件下载完并不等于数据可用。把SP3检查压缩到30秒内完成再顺手留一条下载日志能避免几天后重跑时翻旧账。5.1 解压并检查SP3文件头uncompress igs20740.sp3.Z head -5 igs20740.sp3SP3文件头里以#开头的第一行记录时间系统和历元##行通常给出GPS周、星期几和当天秒以开头的行列出本文件包含的卫星编号。检查时重点看行里是否包含G01到G32的编号如果卫星列表不全说明产品本身有问题或文件在传输中被截断。5.2 用轨道半径快速判断文件是否损坏SP3坐标原点是地心GPS卫星轨道半径稳定在26560千米附近。用一条awk命令就能读第一个位置记录计算半径awk /^PG01/{printf %.3f km\n, sqrt($2*$2$3*$3$4*$4); exit} igs20740.sp3正常结果应该落在26000到27000千米之间。如果算出几千或几十万基本可以判定文件损坏、坐标单位错乱或者记录行没有正确解析。这个检查对批量下载后的抽检非常划算。5.3 确认最后一个历元覆盖了观测时段下载完成后还要确认星历的时间跨度覆盖了你的观测数据。SP3里的每个历元都以*开头直接取最后一个历元grep ^\* igs20740.sp3 | tail -3看输出里的日期和秒数最后一个历元应该不早于观测时段的结束时刻。IGS最终产品是整天的完整文件正常情况下会覆盖到当天最后一秒如果末尾缺了一段说明文件不完整需要补下或换镜像。5.4 每次下载都留一条MD5日志把下载完成文件的MD5值追加到按日期命名的日志里md5sum igs20740.sp3.Z download_$(date %F).log下次补数据时先查日志已经存在且Hash一致的文件就不用重新下载。配合第4章里if [ ! -s $out ]的判断整个下载流程就是幂等的重跑多少次都不会产生重复流量。本文还有配套的精品资源点击获取
返回列表