简介：面向从事高精度GPS定位、GNSS数据处理与地球科学研究的科研人员和测绘工程技术人员，这份文档汇总了国际GNSS服务（IGS）精密星历的备用下载地址，用于主通道不稳定或紧急取数时快速切换数据源。内容按IGS Final、Rapid、UltraRapid（含12小时与00小时）轨道产品分类，列出NASA、UCSD、GSFC、IGN等机构提供的FTP链接，并标注TBC默认地址及站点配置所需字段，便于在TBC等软件中调用。文档以产品类别组织，地址覆盖多个地理区域镜像，便于按可用性快速比对，减少反复搜索与验证链接的时间。压缩包仅含1个docx文件，约314KB，轻便易归档，适合离线查阅或随项目资料保存。目前已有440人学习。读者可据此建立多来源星历获取清单，降低单点下载失败对基线解算、精密单点定位和科研数据连续性的影响，也能更清楚地区分不同轨道产品的更新时效、精度层级与适用场景。

1. 主站一抽风，精密星历就断供：用分层备用地址把补数时间压下来

某天跑全球定位系统后处理，脚本按惯例从默认节点抓当天的 IGS 精密星历，日志里只剩一行行连接超时。基线解算就差这一个输入，硬生生卡了半天。IGS 精密星历的获取并不是只有一条路——Final、Rapid、UltraRapid 三类产品，加上分在不同数据中心的四五个 FTP 镜像，本身就是一张冗余网，备用下载地址就是这里的第二道保险。这份指南要解决的是主通道不可用时，怎么在几分钟内换一条通道把数据拿到。做高精度 GPS 后处理、GNSS 气象、地壳形变监测，或者把星历下载写进流水线的人，都可以直接照着用。

2. IGS 产品分层：Final、Rapid、UltraRapid 的时延差与 SP3 文件结构

2.1 三类轨道产品的时延、精度与适用场景

IGS 同时发布三档轨道产品，不是为了凑数，而是对应三种不同的时间预算。Final 是事后精化结果，等得最久，但精度最高；Rapid 是快速解，隔一天左右就能拿到；UltraRapid 是超快解，几个小时内就有，但含有预测段，精度最粗。把这三档放在一起看，选型的逻辑其实很朴素：应急补数优先选能最快拿到的，能把精度扛住的就往下退一档，只有等不起又必须高精度的场景才两头为难。

下表是我按业务里常见用法整理的一份对照，具体数值以 IGS 当期发布说明为准，但量级关系不会变：

选型时经常有人问“能不能全用 Final”，答案是不能。Final 的时延以周计，流水线等它等到黄花菜都凉了。反过来“能不能全用 UltraRapid”也不行，预览段里有预测卫星位置，拿来做毫米级静态解就是自己给自己挖坑。我一般会按这样的顺序退让：正式平差必须 Final；如果 Final 还没出，用 Rapid 先跑一版中间结果；只有实时或准实时监测才碰 UltraRapid，而且要在报告里标注“含预测段”。

还有一个容易被忽略的细节：三个档位的文件覆盖时段不一样。Final 和 Rapid 一般覆盖整周，UltraRapid 的_00和_12是按发布时刻命名的，数据从发布时刻往前推 24 小时，再往后外推一段预测。所以拿到igu文件的时候，不要把它当成“整天的数据”，否则解算时段的截取会错位。这一点在后面避坑章里还会单独拎出来讲。

2.2 打开一个 SP3 文件能看到什么

SP3 是 IGS 精密星历的通用载体，扩展名.sp3，老版本还会在末尾加.Z做 Unix compress 压缩。解压后是纯文本，用head翻前几十行就能判断这份文件是不是你要的那一周、那一天。

下面是我随手截的一段头段（数值仅用于示意格式，不代表真实卫星坐标）：

#cP2024 06 01 00 00 00.00000000 96 ORBIT IGS20 HLM IGS ## 2316 518400.00000000 900.00000000 58043 0.0000000000000 + 32 G01G02G03G04G05G06G07G08G09G10G11G12G13G14G15G16G17 + G18G19G20G21G22G23G24G25G26G27G28G29G30G31G32 + 0.0000000000000 0.0000000000000 0.0000000000000 %c M cc GPS ccc cccc cccc cccc cccc ccccc ccccc ccccc ccccc %c cc cc ccc ccc cccc cccc cccc cccc ccccc ccccc ccccc ccccc /* 头段结束，下面是历元块 */ * 2024 6 1 0 0 0.00000000 PG01 -12345.678901 -23456.789012 3456.789012 123.456789 PG02 -23456.789012 -34567.890123 4567.890123 234.567890

逐块看这几行：

第一行#cP是版本与文件类型标记，c代表 SP3-c，P代表位置；后面跟着历元日期、96是这一天的历元数量、ORBIT和参考框架标识（这里是IGS20）。

第二行##是整份文件的索引行，字段顺序通常是“GPS 周、周内秒、采样间隔（秒）、该时段卫星总数、精度指数”。上面这条2316 518400.00000000 900.00000000 58043读出来就是：GPS 周 2316、周内秒 518400（对应周六）、采样间隔 900 秒、卫星总数 58（含各系统）。

+开头的行是卫星清单，把每颗卫星的 PRN 编号紧凑地排在一起；%c行是精度字符说明，告诉你每个历元坐标后面那串字符怎么解读。头段结束以后，每个*行标志一个历元，紧跟着的PGxx行才是具体坐标，单位是千米，最后几列是钟差和钟差变化率。

这套结构的意义在于，你可以完全不依赖外部元数据，光靠head就能判断一份文件对不对：周号对不上，说明下错了；历元数少了一大截，说明文件被截断；卫星清单里缺了你关心的那颗卫星，说明这一周该星在轨状态有变化。后处理流水线里做自动校验，我一般就抓这三样。

2.3 文件命名：igs / igr / igu 与 WWWWD 的拆解

命名规则不复杂，但新人最容易在这一步翻车。以igs23166.sp3.Z为例：

• igs：产品档位前缀，Final 是igs，Rapid 是igr，UltraRapid 是igu。
• 2316：GPS 周号，四位补齐。
• 6：历元日，从 0 到 6，0 对应周日，6 对应周六。
• .sp3：格式扩展名。
• .Z：Unix compress 压缩，不是 gzip。

UltraRapid 还会在历元日后再接一段_00或_12，代表发布时刻（UTC 零点或十二点），例如igu23166_12.sp3.Z。_00和_12这两份文件的区别不是“谁更新”，而是发布时刻不同、数据覆盖窗口不同，下载时要按你的时段需求挑，不要看哪份新就下哪份。

前面 2.1 表格里提到的“时延”，直接决定了你在某个时间点该去抓哪一档。举例来说，如果今天是 GPS 周 2316 的周六，你想要这一周周五的 Final 数据，大概率是拿不到的——Final 还没攒够解算周期。这时候要么退到 Rapid，要么再退到 UltraRapid 先补个洞，等 Final 出来再回填。

3. 备用地址模板拆解：%GGGG% 和 %GGGGT% 到底填什么

3.1 四类产品对应的地址清单

原始资料里给的是模板形式，把 GPS 周号和历元日先用占位符代替。这样写的好处是一份清单管所有周，坏处是第一次用的人容易把两个占位符搞混。先把清单按产品档位摊开，注意每条地址里路径段和文件名段分别用了不同的占位符：

Final 轨道（文件前缀igs）：

Rapid 轨道（文件前缀igr）：

UltraRapid，发布时刻_12：

本文还有配套的精品资源，点击获取