参考站不测地震 — NOAA CORS 的 RINEX 观测档案

一份 GNSS 档案最容易引起的错觉，是把它当成「一堆已经算好的点位」。方向正好相反。这里每一份文件记录的只是某一台接收机在那一天听到的卫星信号相位，连它自己站在哪里都不是精确已知。

要得到坐标，必须先把它和附近的参考站一起做基线解算；要得到形变，还必须跨越十几年、换过好几次参考框架。这中间每一步都不在档案里。

下面先拆清楚它究竟存了什么、以什么粒度存、边界在哪里，再谈那些让解析器静默出错的坑。

项目	数值	依据
全名	NOAA 连续运行参考站网络 RINEX 观测档案	官方页标题与正文
维护方	NOAA 国家大地测量局（NGS）	官方页
分发渠道	NOAA 开放数据发布计划（NODD）的对象存储桶	数据说明页顶部公告
最早可见观测文件	1994 年第 170 日前后（1994-06-19）	桶内逐日列举
观测文件命名	ssssDDD0.YYd.gz 与 ssssDDD0.YYo.gz	官方命名规则表
单日观测文件数	1,806 份（903 站 × 两格式）	2026 年第 302 日清单
单日出现观测的站点	1,795 个	同日清单去重
坐标文件登记站点	2,600 个（含已退役）	ITRF2020 汇总表
观测文件粒度	站 × UTC 日	目录结构
访问门槛	匿名可读，无需注册与密钥	直接请求即返回数据
许可	页面为免责条款，无公共领域或知识共享标识	数据说明页底部

§1 速览：它是什么，不是什么

1.1 一句话定义

NOAA CORS 是一份以「站-日」为单位的原始观测档案：每一份文件对应一台地面接收机在一个 UTC 日里记录下来的全部卫星信号，格式是 RINEX，内容是伪距、载波相位、多普勒与信噪比。

这个定义里有两个词决定了后面所有的坑。「原始」意味着没有解释——没有点位、没有位移、没有质量标记之外的第二道判断。「站-日」意味着主键是 (站点代号, 年份, 年积日)，不是站，也不是事件。想按站点批量分析，得先自己做一次按站聚合；想按时间分析，得先自己做一次按日拼装。

1.2 它凭什么值得单独写一条

全球的 GNSS 观测档案不止这一家。国际 GNSS 服务的全球站网更权威，欧洲的 EUREF 覆盖更密，日本的 GEONET 站数更多。它在四个条件上同时成立，才值得被当作一个独立对象来读。

第一，它是连续运行的。站不是为了某次观测临时架起来的，而是常年不断电、不断网。这让它天然产生一条时间序列，而不是一堆离散的观测活动。连续性本身是资产：一个站连续记录二十年，等价于一次长达二十年的定点测量。

第二，它覆盖整片国土。单个 GNSS 站的用处有限，一片均匀分布、共同支撑同一套坐标基准的站网才有意义。站与站之间的相对位置被反复解算、反复更新，构成一张可以相互校验的网。

第三，它开放得彻底。不需要注册、不需要密钥、不需要申请。一个 HTTP 请求就能取走任何一天任何一站的文件，也没有公布每日配额。

第四，它不是某一家的私产。站由数百个政府、学术与商业机构分别拥有和运营，各自把观测与元数据交给 NGS，由 NGS 统一处理与分发。这意味着档案里天然带着多机构的差异——设备不同、采样率不同、延迟不同。

1.3 三十秒决策卡：你的处境，它能帮你什么

你的处境	它能帮你什么
手里有一台测量级接收机的静态观测，想算出它在国家坐标基准下的位置	不用自己找基准站，配套的在线解算服务可以直接吃下 RINEX 返回坐标
想研究某条断层几十年尺度的缓慢形变	站的时间序列正是为此而生，但必须先做基线解算与框架统一
想反演一次大地震的同震位移或破裂过程	1 赫兹档的站能提供秒级采样，近震区的站往往震后仍在记录
想给别的卫星产品做地面几何校验	站坐标与速度是现成的高精度地面控制点
想拿一份「接收机元数据 + 设备变更史」的样例	设备变更总表把每站每次换机换天线都记成一行
想拿来直接训练模型	给不了，它没有标签、没有划分、也没有统一的数值口径

1.4 不适合谁

如果需求是瞬时地震波场，这份档案不合适。采样率与仪器响应都是为定位优化，用它做常规地震监测等于用卷尺量心跳。

如果需求是已经算好的点位表，会失望。坐标要经过解算才出现，而且随参考框架更新整体平移。

如果需求是全球均匀覆盖，它做不到。站网以美国为中心，海外只有零星合作站。做全球板块运动研究应去国际 GNSS 服务的组合产品。

如果需求是长时间跨度的连续位移序列，档案本身给不出。它给的是观测，位移序列是另一个产品，且那个产品的口径随历次重处理整体改写。

1.5 案例：路易斯安那州立大学站

后文会反复回到同一个站，先把它的底细交代清楚。

站点代号 1lsu，全称路易斯安那州立大学站，位于美国路易斯安那州，北纬约 30.41 度、西经约 91.18 度。它在站点总表里登记的开始日是 2003 年第 113 日。设备从一台旧型号接收机起步，此后换过若干次机型，天线也在 2008 年换过一次。

它最适合当贯穿样本，是因为它把这份档案的每一类结构都占全了：有闰年之外的普通日文件、有差分压缩与未压缩两版、有每日遥测的 1 秒档文件与压缩副本的 30 秒档文件、有按新框架发布的坐标文件、有设备变更史、还有一份按日刷新的短周期质量曲线图。

一个站，六种产物。看懂它，等于看懂整个桶的组织方式。

§2 数据构成：一个桶里装了六样东西

2.1 顶层只有六个分区

桶的根目录下，除了一张静态索引页之外，只有六个首级分区。这个数量值得记住：它不是按数据类型随意堆出来的，而是按「谁在用」分出来的。

分区	装什么	粒度
rinex/	逐日观测文件、广播星历、精密轨道、质量摘要	年 / 年积日
raw/	站内原始遥测数据	年 / 年积日 / 站
coord/	已发布坐标与速度	参考框架 / 站
station_log/	站点元数据与设备变更史	站
Plots/	质量曲线图	站
cors/	一份历史镜像目录	年 / 年积日

六个分区里，日常取数只会用到前四个。后两个一个是给人看的图，一个是历史遗留的副本树，都不适合进流水线。

2.2 rinex/ 的键结构：年积日，不是月日

路径是 rinex/YYYY/DDD/，DDD 是年积日，从 001 起算到 365 或 366。2026 不是闰年，序号到 365 为止；目录里另有一个 hold_sum 子目录存放暂挂的摘要，不带日期。

用月日组织会更直观，但年积日有一个实际好处：它把「一年有多少天」变成「一年有多少个键」，不用处理大小月与闰年。代价是所有外部日期都要先转成序日，转换规则一旦写错，整整一年的文件都会错位一天。2 月 29 日只存在于闰年，把它当固定存在去遍历，在平年会直接拿到空结果。

每一级目录下还会有若干非站点的散文件，它们与站点文件混在同一层：

文件	含义	出现频率
brdcDDD0.YYn.gz	一日合并的广播星历，后缀 n 指 GPS 导航电文	每日
brdcDDD0.YYg.gz	同上，但只含格洛纳斯	部分日
YYY.DDD.files.list	该日全部对象的清单，含路径、写入时间与字节数	每日
summary.YYYY.DDD.fileinfo	该日全部观测文件的逐站质量摘要	每日
igsWWWWD.sp3.gz	短名精密轨道	每日
igrWWWWD.sp3.gz	快速轨道	每日
iguWWWWD_HH.sp3.gz	超快轨道，每天四个时段	每日
IGS0OPSRAP_*.SP3.gz	长名快速轨道，与国际命名规范接轨	每日

清单文件是这一层最有用的东西。它一次性给出当天所有对象的大小与时间，不必逐个 HEAD 请求。2026 年第 296 日那份清单 535,930 字节，七千余行；第 100 日那份 599,807 字节。清单本身不是数据，但它是唯一能在一个请求里看清整天的入口。

2.3 站点文件名：三段编码

站点文件名的规则在官方页写得很清楚：ssssDDD0.YYd.gz 与 ssssDDD0.YYo.gz。四段分别是站点代号、年积日、日序号、两位年份，再跟上扩展名与压缩后缀。

扩展名只有两种含义，但有两种写法：

• d 表示 Hatanaka 差分压缩后的 RINEX。它本身还需要一次 gzip 解压才能变成字节流，再经过一次差分还原才是文本。
• o 表示未做差分的原始 RINEX 文本，同样用 gzip 包了一层。

所以 1lsu2960.26d.gz 的完整读取链是：gzip 解压 → 差分还原 → 得到 RINEX 文本。缺任何一步都不会报错，只会得到乱码或错位字符。

§1.5 的案例里那两份同名不同后缀的文件，字节数分别约 5.9 兆与 1.3 兆，恰好反映差分的压缩比在四倍上下。这个比值在整站网里大致稳定，可以作为粗略估算的依据。

2.4 观测文件的内部结构：头部与历元

任何一份 RINEX 观测文件都分两段：头部与观测值块。头部是定宽 80 列的文本，每行最后 20 列写标签；观测值块按历元块排列，每个历元先写一行时间戳与卫星清单，再按卫星逐块写观测值。

拿 §1.5 的案例里那份未压缩文件开场，头部读出来是这样几件事：

头部标签	这一份写的是什么	为什么重要
版本与类型行	2.11，观测数据，混合星座	决定后面怎么解析
程序 / 运行者	质量检核软件与管理员账号，附生成时刻	说明文件是转出来的，不是接收机直出
站点名与站点号	两行都是同一个四字符代号	与目录名一致，可做校验
观测者 / 机构	一个姓名与一个两字母机构码	对应站点的运营方
接收机	序列号、型号、固件版本	设备变更史的另一处来源
天线	序列号、型号、罩型	解算时必须配对天线校正模型
近似位置	三个地心坐标分量，单位米	只是近似，误差可达米级
波长因子	L1 与 L2 各一个	老文件里用于相位平滑
观测类型	十一个两字母码，跨行续写	决定每个卫星有多少列
采样间隔	15.0000 秒	名义值，与实际可能不符
首观测时刻	年月日时分秒与时间系统	与文件名里的序日应对得上

十一个观测类型码是这份文件的灵魂。它们是 L1 L2 L5 C1 P1 C2 P2 C5 S1 S2 S5：三个频点的载波相位、五个码观测、三个信噪比。同一颗卫星的一行观测值，就是按这个顺序排列的十一个浮点数，再带上两个失锁标志位。

2.5 同一个站的两份文件，间隔不一样

把 §1.5 的案例里那两份文件对照，会看到一件反直觉的事：以 o 结尾的那份写 15 秒，以 d 结尾的那份写 30 秒，正文注释里还多了一行「强制降采样到 30 秒」。

两个文件描述的是同一天同一个站，间隔却不同。原因在于它们的定位不同：遥测版保留相对高的频率，压缩副本按分发策略降采样，以控制存储与带宽。这不是错误，而是两条流水线的产物。

这条差异对使用者的直接后果：不能假设同一站同一天的 d 与 o 逐历元一一对应。真要拼接，必须按首观测时刻与间隔重建时间轴，而不是按行号对齐。按行号对齐的做法在两者间隔一致时毫无问题，一旦不一致就整段错位，而且不会报错。

2.6 coord/：按参考框架分目录的坐标

坐标分区不是一年一个目录，而是一个框架一个目录。目录名是 coord_ 加两位数字，目下按站一份文本，外加若干份汇总表。

以第 296 日的站站为例，那份坐标文件读出来分四段：框架与站名抬头、天线参考点的地心坐标与经纬高、速度分量、以及同一站在国家平面基准下的对应值与速度。每一段都写明「用截至第几个 GPS 周的数据、在什么时候算的」。

这个设计的关键在抬头两行。它们告诉使用者：这份坐标属于哪个框架、哪个历元、哪次解算。少了这两行，一个看起来精确到毫米的数就没有意义。

2.7 station_log/：把设备变更写成一张表

设备变更总表约 1.1 兆，2026 年 10 月 28 日生成，七千余行，覆盖七百多个站点。每行是一次「会话」：同一台接收机配同一副天线、在同一组参数下连续工作的那段时间。

字段有站点名、开始与结束时刻、天线高与高度码、接收机型号与固件、接收机序列号、天线型号与罩型、天线序列号。一行的结束时刻是下一行的开始时刻，整表本质上是一个区间集合。

这张表的价值在于它把「站变过什么」显式化了。解算软件要选天线校正模型，靠的就是这里的天线型号；查一次历史断档，也要靠这里的区间拼接。表里没出现的时段就是没有可用设备的时段。

2.8 raw/ 与 Plots/：两个容易走错的分区

raw/ 里放的是站内遥测的原始拷贝，按年、年积日、站号三层组织，起点比 rinex/ 晚得多。同一个站同一个日子在两处的文件扩展名不同，raw/ 里出现的是老式压缩后缀，rinex/ 里出现的是 gzip 加差分后缀。

两者的差别不只是压缩方式。rinex/ 是转码产物：经过格式转换、质量检核、按策略降采样，头部会多出若干条处理痕迹注释。raw/ 是转码之前的形态，设备写什么就存什么。要复现某一次转码的影响，必须同时看两边；只看转码后的文件，无法判断某一段数值是设备给的还是转码改的。

Plots/ 里是每站两张质量曲线图：一张短周期，覆盖最近一段时间；一张长周期，覆盖该站的全部历史。它们是位图，不是数据。用途只有一个——在打开文件之前先看一眼这个站最近有没有异常。把它当数据源去解析，方向就错了。

两个分区共同的坑在于命名相似。raw/2010/114/ 与 rinex/2010/114/ 看起来像同一个东西的两份拷贝，实际一个是原始遥测、一个是转码档案，结构完全不同。批量脚本按目录名做前缀匹配时，很容易把两者混进同一个循环。

§3 拿到手之后：从文件到坐标的距离

3.1 主键到底是什么

(站点代号, 年积日) 是唯一可靠的定位方式。站点代号是四字符、大小写不敏感但官方一律小写；年积日三位补零。除此之外没有第二个稳定键。

不能用的：文件名整体。原因是同一站同一天会有三份文件（差分版、原始版、质量摘要），文件名不同但指向同一条记录。用文件名当键，一条记录会被数三次。

也不能用的：站号加日期加间隔。间隔会在同一天内因分发策略变化，§2.5 那个站就是例子。

3.2 一次请求能拿到什么，拿不到什么

一个 HTTPS 请求可以拿到一份文件。这听起来理所当然，但决定了很多工程细节。

拿得到：单份文件、单日清单、单站坐标、单站设备表、汇总坐标表。拿不到：某站的完整时间序列、某站某月的合并文件、某区域某日的子集。桶是对象存储，不是查询接口——没有范围筛选，没有按站聚合，只有「给键取对象」和「按前缀列举」。

要做按站聚合，只能自己列举目录再拼。列举本身有上限：单次最多返回一千个键，超过要接着上次的游标翻页。一天一千八百份文件，一次列举拿不全，必须翻两次以上。

3.3 下游依赖的是谁的坐标

这是整条链路里最容易搞混的一环。

档案本身不提供解算。要做基线解算，得自己找软件、自己选参考站、自己定处理策略。NGS 确实发布了一套权威解算结果，就是坐标分区里的坐标与速度，但那是一套长期解的汇总，不是逐日时间序列。

也就是说，档案与坐标之间隔着一个解算层。想得到「某站逐日坐标」，要么自己做，要么去找别的机构已经做好的日解产品，档案本身只提供原料。

这条边界决定了两种完全不同的用法：只想要一个点位，去坐标分区；想要一条曲线，必须自己搭解算，或者接别人的解。

3.3.1 解算这一步到底在做什么

把两个站同一历元的观测值相减，是整条链路的核心动作。载波相位里同时含有卫星到接收机的真实几何距离、卫星与接收机的钟差、电离层与对流层的延迟、模糊度整数、以及多路径误差。两个站相距不太远时，卫星钟差几乎完全相同，电离层与对流层的延迟也高度相关，相减之后大部分被抵消，剩下的几何项就能解出基线向量。

这段描述里有两个词决定了所有下游结果。一个是「不太远」：基线越长，延迟的相关性越弱，抵消得越差，必须引入外部改正模型。另一个是「模糊度整数」：相位观测的小数部分可以测到毫米，但整周数一开始是未知的。能不能把它正确解成整数，直接决定结果是厘米级还是分米级。

所以同一份文件，用不同参考站、不同高度角、不同模糊度策略去解，会得到不同的坐标。这些差异不代表哪一家算错，只代表问题的解不唯一。坐标文件抬头写的「用截至第几个 GPS 周的数据算的」，就是这个解的说明书。

3.4 配套的在线解算服务

NGS 提供一套在线服务，把「上传一个文件、返回一个坐标」这件事做成了网页。它用的是同一套处理软件，也就是算国家控制点与算站坐标的那一套。

官方对它的说明很具体，值得逐条记住：

• 输入必须是双频 GPS 的全波长载波相位观测，静态，天线在观测期间不能移动。
• 时长下限 15 分钟、上限 48 小时，且不能跨过两个 UTC 午夜。
• 两小时以内的文件必须同时含 P2 与 P1 或 C1。
• 采样间隔必须是 1、2、3、5、10、15 或 30 秒之一。
• 只吃 GPS 观测量，即使文件里带着别的星座。
• 一律降采样到 30 秒，仰角只用到 10 度以上。
• 2 到 48 小时走静态处理，取三条独立单基线的平均；15 分钟到 2 小时走快速静态，对数据连续性与几何更挑剔。

天线的选择被单独强调：选错型号，高度误差可达数十厘米级，水平误差也在厘米量级。原因在于不同天线的相位中心偏移不同，校正模型配错，误差直接进结果。

3.5 两份文件必须一起取

官方在站点日志与坐标那一段写了一句很强的话：日志里和 RINEX 头部里的位置都应视为近似，下载数据时应同时取走该站的已发布坐标文件。

这句话把「取数据」这个动作拆成了两半。只取观测文件，等于拿到一份没有起点的测量；只取坐标文件，等于拿到一个没有证据的结论。两者合起来才是一份可用的档案。

对 §1.5 的案例里那个站，头部近似位置与坐标文件里的正式值差了几毫米到几厘米不等，这个差距本身就在提醒：头部那个数不能直接用于精密工作。

§4 坐标层：参考框架会换，站不会动

4.1 一个站有两套数

坐标文件里同一站会给出两套位置。第一套是国际地面参考框架下的地心坐标与经纬高，第二套是国家平面基准下的对应值，并注明「由国家框架变换而来」。两套数还各自带一套速度。

这不是重复，是两种用途。做全球尺度的板块运动，用前者；做本地测量与国家基准衔接，用后者。混用两套数算位移，得到的是框架间的定义差，不是地壳运动。

4.2 框架换代的真实含义

2022 年 10 月，国际 GNSS 服务发布了新一代参考框架的实现，作为 2020 年版国际地面参考框架的实现。从那时起，旧框架的产品不再更新，所有更新都转到新框架下。

NGS 随后做了自己的重处理：把 1996 年到 2022 年的逐日观测全部重算了一遍全国站网，并与国际重处理结果融合，对齐到新框架，通过相对全球九十七个站的十四参数变换完成。这套结果在 2025 年 6 月发布，取代了上一版多年解。

对使用者，这段历史的三个后果都是硬的：

第一，坐标文件的目录名会换。旧目录不会消失，会以 coord_ 加年份的形式留存，新目录叫 coord_20。按目录名硬编码去取，跨年就在旧目录里打转。

第二，同一站在新旧文件里的数值不同。差异来自框架实现与解算策略，不来自站位变化。把它当成形变读，会得到一个几十毫米的「位移」，而真实年速度可能只有几毫米。

第三，旧文件不是错的。它忠实记录了当时的框架与当时的解。引用时带框架名，就仍然有效；不带框架名，就不可比。

4.3 分母不是「现在的站数」

坐标汇总表里两千六百行，不等于两千六百个正在工作的站。按末列状态拆分，会看到五种：

状态	含义
运行中	当前有数据、可参与解算
已退役	曾运行，现已停止
非运行	存在但当前不产出可用数据
暂停	临时中止，可能恢复
国际站但不在本网络	属于国际网络、不是本地网络成员

其中运行中的约占六成三。剩下四成里，已退役的又占了近三成。这个结构说明一件事：归档是历史的，站表是当下的，两者永远对不上。用归档里的文件数除以站表的行数，得到的比值没有意义。

4.4 名义间隔与实际间隔

站表里每站有一列采样间隔与一列延迟。这两列是运营方申报的值，不是文件里的真实值。

实际文件头里写的间隔，可能是申报值的另一种表达，也可能被分发策略改写。§2.5 那个站申报的间隔与两份文件里的值就对不上，原因在策略，不在申报。

稳妥的读法是：站表的那一列用来做筛选（哪些站可能给到秒级数据），文件头的那一列用来做解析（每历元跨度多少秒）。两列不一致时，以文件头为准，因为它描述的是这份文件本身。

4.5 完整性只在站-日的层级上定义

「这份档案完整吗」这个问题没有统一答案，因为完整的标准随用途变化。

对做定位的人，一个有坐标、有设备表、有当日观测的站-日就算完整。
对做时间序列的人，中间缺一天就是缺口，得看缺口是设备故障、数据延迟，还是这份档案本身就没有收进来。
对做形变的人，完整性的标准更严：不仅要文件在，还要解算能收敛、天线没换、参考框架一致。

档案本身只回答第一种。后两种要靠自己搭检查。

§5 工具层：RINEX 的两代格式与三个静默失败

5.1 RINEX 是什么，为什么需要它

不同厂商的接收机内部格式各不相同，有的是二进制、有的是厂商私有文本。要做跨站处理，必须先有一个公共交换格式。RINEX 就是那个格式：纯文本、定宽列、按头部声明自描述。

它是交换格式，不是处理格式。这一点常被误读：RINEX 的目的从来不是让人高效计算，而是让不同机器写出的数据彼此可读。所以它选择文本、选择定宽列、选择把元数据塞进头部。

5.2 两代格式的结构差异

2.x 与 3.x 之间不是版本号递进，是两套几乎不相容的语法。

维度	2.x	3.x
卫星标识	一个字母加两位数字，密集排列在一行里	三字符标识，每行最多若干颗，续行用独立标记
观测类型	两字母码，写在头部的类型清单里，最多跨两行	三字母码，分星座写在头部，每个系统一块
历元记录	时间行加卫星清单行，可跨多行	时间行以 > 开头，卫星清单紧随其后可跨多行
观测值块	每个卫星若干行，列宽固定 16 字符，缺测为空格	分系统组织，列宽相同但分组顺序变
数值格式	定点，丢失的小数位直接省略	仍是定点，但对齐规则有细微差别
观测类型顺序	由头部清单唯一确定	由头部每系统的清单唯一确定

最关键的一条是最后两行：2.x 的列顺序只由一份清单决定，3.x 的列顺序由「每个星座各自的清单」决定。同样是十一个观测类型，2.x 里是一个扁平序列，3.x 里是几条分星座的序列首尾相接。

5.3 第一个静默失败：用 3.x 解析器读 2.11

这是最常见的一种。表现是：程序不报错，读出来的浮点数也在合理范围内，但历元时间与观测值都错位。

原因很具体。2.x 的历元时间行没有 > 前缀，3.x 解析器按「大于号开头的行是历元」去扫，于是一个历元也扫不到；如果它退而用「包含年月日的行」去匹配，就会把卫星清单行的某些片段误判成时间。两条路都不会抛异常。

判断方法很简单：读头部第一行前十个字符，2.11 开头就交给 2.x 分支，3. 开头交给 3.x 分支，两分支互不复用。写死一条路径的代码，早晚会在某一年份的文件上静默出错。

5.4 第二个静默失败：两字母码与三字母码互相当真

RINEX 2 里 L1 指一号频点的载波相位，C1 指一号频点的码观测，P2 指二号频点的精密码，S1 指一号频点的信噪比。

RINEX 3 里同一个量被写成 L1C、C1C、C2W、S1C。多出来的第三个字母是「信号通道」：C 是民用通道，W 是加密精密码，X 是导频与数据复合，L 是导频等。

把 L1 与 L1C 当成同一个量是错的。在 2.x 里，L1 只是「一号频点相位」，具体是哪个通道，由那台接收机当时能跟踪到的通道决定；在 3.x 里，通道被显式写进代码。同一站、同一天、跨版本的两份文件，L1 与 L1C 极可能不是同一信号。

对做差分定位的人，这个区别影响几厘米到几十厘米；对做载波平滑的人，它会直接改变平滑窗口的有效性。

5.5 第三个静默失败：伪距当相位用

观测值块里，伪距与载波相位在字面上非常像：都是十几位有效数字，都是浮点，都带着失锁标志。

区别在量级与物理意义。载波相位是「从起始时刻到该历元累计的周数加上小数部分」，数值可以到上亿；伪距是「信号传播时间的等效距离」，数值在几千万到几万公里之间。以一号频点为例，伪距约在两万公里上下，相位约在一点一亿周上下，两者只差一个波长倍数。

这个倍数关系让错误特别隐蔽：把相位当伪距，算出来的位置会在几万公里外，程序照样给出收敛结果；把伪距当相位，周跳检测会疯狂报警然后被平滑调掉。都不抛异常。

唯一的防线是显式记录列索引，并在读完之后做一次量级断言——一号频点的数值超过某个阈值就说明取错了列。

5.6 差分压缩：第四层要剥的皮

以 d 结尾的文件有两层封装，不是一层。

第一层是 gzip，标准算法，解压后得到 CRINEX 文本。第二层是差分压缩，把相邻历元之间高度相关的数值表达成差分，并约定初值、阶数与特殊转义。

按第七版算子的结构，解压端要按顺序做三件事：读首行拿到压缩机版本、读 RINEX 头部、按历元处理正文。正文里第一行以 & 开头，是这一历元的完整参考值；后续行以转义字符开头，末尾附一个整数表示这一卫星的文本长度。

两个容易踩的点。其一，RINEX 头部末尾那行之后立刻就是正文，中间没有空行，空行出现在正文内部用于分隔卫星。其二，正文里有些字段缺失，差分算子对这些缺失有专门的占位约定，把整行按空白切分再按下标取，会把占位符当数值。

5.7 一个可直接运行的头部读取脚本

下面这段只做一件事：把任意一份 RINEX 观测文件的头部解析成字典，并自动判断版本。它同时处理 d 与 o 两种封装。

#-- 依赖标准库;对 d 文件只解到 RINEX 头部为止,不做完整差分还原
import gzip
import io
import re
import urllib.request

BASE = "https://noaa-cors-pds.s3.amazonaws.com/rinex"


def open_text(key: str):
    """取对象并按 gzip 解压;d 文件解出的是 CRINEX 文本(含头部)"""
    req = urllib.request.Request(f"{BASE}/{key}", headers={"Range": "bytes=0-262143"})
    raw = urllib.request.urlopen(req, timeout=60).read()
    return gzip.GzipFile(fileobj=io.BytesIO(raw)).read().decode("latin-1")


def read_header(text: str) -> dict:
    """头部:每行末 20 列是标签,标签之前是值;遇 END OF HEADER 停"""
    head, crinex = {}, None
    for line in text.splitlines():
        if len(line) < 60:
            continue
        label, value = line[60:].strip(), line[:60].strip()
        if label == "CRINEX VERS   / TYPE":
            crinex = value
        if label == "END OF HEADER":
            break
        head.setdefault(label, []).append(value)
    head["_crinex"] = crinex
    first = head.get("RINEX VERSION / TYPE", [""])[0]
    head["_rinex"] = float(first.split()[0]) if first else None
    return head


if __name__ == "__main__":
    for key in ("2026/296/1lsu/1lsu2960.26o.gz", "2026/296/1lsu/1lsu2960.26d.gz"):
        h = read_header(open_text(key))
        print(key, "| RINEX", h["_rinex"], "| CRINEX", h["_crinex"],
              "| 间隔", h.get("INTERVAL"), "| 观测类型数",
              len(h.get("      # / TYPES OF OBSERV", [])))

输出的最后两列是关键：_rinex 给出该走哪个解析分支，_crinex 给出该套哪一版差分算子。两个版本号必须一起读，缺一个就只能靠猜。

5.7.1 历元块怎么切

头部读完之后，正文的切分规则要按版本分两套。2.x 是「一行时间加若干行卫星清单，然后每颗卫星若干行观测值」；3.x 是「大于号开头的一行时间与卫星数，接着若干行卫星清单，然后每颗卫星若干行观测值」。

两套的共同点是：每组观测值的行数由头部声明的观测类型数算出，而不是由数据本身的空格位置决定。观测类型十一项、每行最多五项的规则下，每颗卫星要占三行。切错行数，后面的历元会整体错位，错位之后的所有数值仍然落在合法范围内，看不出异常。

一条可靠的校验办法是回读每一个历元的时刻，检查相邻历元的时间差是否等于头部声明的间隔。如果在某个历元处差值突然变成两倍、三倍或负数，就说明此前有一次切分错误。这个检查只多花一遍扫描，却能挡住绝大多数静默错位。

另一个校验点是历元总数。一天按某个间隔采样，理论历元数是固定的；实际历元数略少于理论值，因为个别时刻接收机会丢历元。若实际值明显大于理论值，几乎必定是把卫星清单行误判成了新的时间行。

5.8 列举、分页与游标

对象存储的列举是按键字典序返回的，单次最多一千个。要拿全一天的对象，得接游标翻页。

#-- 列举某日全部对象键;单次一千条,超出用返回的游标续翻
import re
import urllib.parse
import urllib.request

def list_day(year: str, doy: str):
    prefix = f"rinex/{year}/{doy}/"
    token, keys = None, []
    while True:
        q = {"list-type": "2", "prefix": prefix, "max-keys": "1000"}
        if token:
            q["continuation-token"] = token
        url = "https://noaa-cors-pds.s3.amazonaws.com/?" + urllib.parse.urlencode(q)
        body = urllib.request.urlopen(url, timeout=60).read().decode()
        keys += re.findall(r"<Key>([^<]*)</Key>", body)
        m = re.search(r"<NextContinuationToken>([^<]*)</NextContinuationToken>", body)
        if not m:
            return keys
        token = m.group(1)

注意 continuation-token 里的加号会被转义成 %2B 之外的形式，务必用 urlencode 交给它处理，手拼字符串会把游标拆坏。拆坏之后服务端不会报错，只会从头再列一遍，表现为死循环。

§6 规模与边界：能数清的是站-日

6.1 规模的可数单位

这份档案的规模有三个层次，每个层次的可数性完全不同。

层次	可数性	说明
单日文件数	可数	由当日清单直接给出
单日站点数	可数	同日清单按站去重
全库总量	官方未公布，逐日累加才能得知	三十余年 × 每日变动

2026 年第 296 日的清单显示，全天共七千二百四十行，其中站点目录下的观测文件约一千八百份，覆盖约一千七百九十五个站点。第 100 日那份清单更大，近六千行到七千行量级，说明单日体量与季节、站点活跃度都有关。

按一天一千八百份、平均每份两兆估，单日约三到四吉字节。一年三百六十五天，量级在太字节上下。这个估算只覆盖 rinex/ 分区里的站点文件，不含 raw/ 的遥测数据。

6.2 相邻两天可能差很多

第 302 日的对象列表里只有六件东西：一份清单、两份广播星历、三份超快轨道。没有站点文件。

这不是数据丢失，是索引层面的延迟。桶里的对象列表是「已经写进来的」，而某一天的站点文件可能还在各站巡检、转换、入库的过程中。清单文件本身出现得早，观测文件出现得晚。

这条现象对任何做增量同步的流水线都是硬约束：不能假设某一天在日历翻过之后就完整了。判断完整必须看清单里的文件数，或者看观测文件是否已覆盖到预期站数，而不是看日期。

6.3 早期年份的目录里没有观测文件

1994 年的目录从第 001 日起就有，但第一季度的日目录下只有两份到三份文件：广播星历、精密轨道、质量摘要。站点观测文件要到第 170 日前后才出现，稳定成文件从 6 月中起。

这与官方说明页那句「1994 年 2 月 9 日以来采集的全部数据」并不矛盾——采集起点与档案里可见的起点是两个概念。但对外引用时若只写前者，读者去查第 40 日只会看到空目录。

档案的时间下界因此有两个版本：口径上是 1994 年 2 月 9 日，可见观测文件是 1994 年 6 月 19 日前后。

6.4 命名规则本身的容量上限

文件名用四字符站点代号，理论上有极大的组合空间，实际全部由小写字母与数字构成，且大量是缩写与机构代码。历史上确实出现过代号重复、需要加数字后缀的情形。

对使用者的实际含义：站号不是自解释的，必须查表。看到一个陌生代号，别指望从字面判断它在哪个州。

6.5 时间方向的边界

档案往前到 1994 年，往后是持续写入。写入的速度由各站实时上传决定，官方说明大多数数据在记录后一小时内可见，少数站延迟一天。小时级文件只保留两天，日文件长期保留。

这条保留策略意味着：想要高频数据，只能在两天窗口内取；过了窗口，只剩降采样后的日文件。任何依赖小时级数据的流水线，必须有本地留存，不能指望回头再取。

§7 评价框架：它不该按什么标准被评价

7.0 读这一节之前要接受的一件事

这份档案不是数据集，是原料仓库。用数据集的尺子量它，会得出「没有标签、没有清洗、没有划分、没有统一样本表」的结论；用数据库的尺子量它，会得出「没有查询接口、不能聚合、只能按键取对象」的结论。两个结论都成立，也都没解释为什么它撑起了整个国家的测量基础设施。

合适的尺子只有一把：作为一份持续三十余年的原始观测记录，它的可复现性够不够。可复现性的意思是：任何一条从它出发得到的坐标或位移，能不能顺着记录回到「哪一份文件、哪一版处理、哪一个框架」。

按这把尺子，做得好的一面是文件本身自带完整元数据：版本、程序、设备、天线、近似位置、时间系统，全都写在头部，不依赖外部说明。做得不够的一面是「哪一版处理」这一环在档案之外——解算软件、参数、参考站选择都不记录。

7.1 三种常见的评价错位

错位	表现	应该怎么想
拿静态表的完整性标准套它	抱怨「没有一张总表」	它按站-日组织，总表是列举出来的，不是给定
拿机器学习基准的标签标准套它	抱怨「没有目标变量」	目标变量是你的建模决策，档案只给观测量
拿 API 的便利标准套它	抱怨「不能按坐标范围筛」	它是对象存储，不是查询服务；筛选要在客户端做

7.2 DAIMS 二十四项逐条对照

#	检查项	状态	说明
1	宽格式	✅	RINEX 观测值是典型的宽表：一行一历元，一列一观测量
2	唯一标识	✅	站号加年积日，全局稳定
3	特殊字符	✅	定宽 ASCII，无编码歧义
4	重复行	⚠️	同一站-日有差分版与原始版两份，语义重复
5	缺失编码	⚠️	缺测为空列，非空值即缺失；差分版另有占位约定
6	标签标识	❌	无任何分类标签
7	罕见类分组	⚠️	星座覆盖差异大，部分站只跟踪 GPS
8	偏倚评估	❌	站分布不均，无官方偏倚说明
9	数据字典	✅	格式由公开规范定义，头部自描述
10	信息性缺失解释	⚠️	站点断档原因不在文件里，要去设备表与日志找
11	设备记录	✅	头部写接收机与天线，另有独立设备变更表
12	共线性	⚠️	伪距与相位同源但量级不同，相关性极高
13	编码映射	⚠️	两代观测类型码无官方对照表
14	时间戳处理	✅	全 UTC，头部声明时间系统
15	划分建议	❌	无；时序切分是事实标准
16	泄漏讨论	❌	无；但连续观测天然存在前后相关
17	标签分布	❌	无标签，不适用
18	测量偏倚	⚠️	多路径、天线更换、遮挡都会在序列上留痕
19	外部验证建议	⚠️	可与国际站网产品交叉，官方未给方案
20	版本记录	✅	坐标文件写明框架、历元、解算时间
21	预处理脚本	⚠️	官方有解算服务，无批处理脚本
22	合规要求	⚠️	只有免责条款，无许可标识
23	多模态对齐	⚠️	观测、星历、坐标三类产物时间基准一致但结构各异
24	去标识化	✅	无个人数据；运营方姓名公开但属机构联系人

DAIMS 七项满分、十一项半分、六项零分，折算约 12.5 分（满分 24）。零分项集中在「面向建模」那一侧，满分项集中在「观测档案」该做好的地方。这个分布不是缺陷，是定位。

7.3 逐条局限

局限	具体表现	后果
坐标不在档案里	观测文件只给近似位置	必须自己做解算或接别人的日解
框架换代	新旧坐标文件不可直接相减	跨框架序列要先统一
两代格式并存	2.x 与 3.x 语法不相容	解析必须分支，不能一套通吃
间隔不一致	差分版与原始版间隔可能不同	按行对齐会整段错位
早期目录无观测	1994 年前半年只有星历与轨道	时间下界有两种口径
当日不完整	索引早于站点文件	增量同步要按清单判断完整
小时文件不长期保留	两天窗口后只剩日文件	高频研究必须自建留存
无许可标识	只有免责条款	引用时不能替官方补写

7.4 外部验证与泛化

可做的交叉验证有三类。

与国际站网的产品比对，可以检验解算层的一致性。但要注意两者用的参考站集合不同，差异不能全归给数据。

与地震学的地面运动记录比对，可以检验同震位移的可靠性。这类比对在近二十年的文献里有不少，结论是同震位移与地震仪反演在大地震上能相互印证。

与本地测量控制点的重复观测比对，可以检验坐标文件的实用性。这类比对最直接，也最受地理条件限制。

7.5 用对了是什么样子

一份用对了的研究，通常在方法部分能看到四件事。

第一，框架与历元写清。用了哪一版坐标、哪一次解算、哪个历元，缺一样别人就无法复现。

第二，解算策略写清。用了哪些参考站、什么截止高度角、什么电离层模型、有没有做模糊度固定。

第三，间断处理写清。设备更换、天线更换、数据缺失各出现在什么时段，被怎么处理。天线更换尤其关键，它会让坐标序列出现一个跳变，这个跳变不是形变。

第四，快照可复现。源文件是会变的（同一份文件名下的对象可能被替换），要么存文件哈希，要么存取数时刻。

§8 生态位：原始观测、目录与产品

8.1 三层结构里的位置

第三层  坐标与位移产品     已发布坐标、多年解、逐日解算结果
第二层  原始观测档案       逐日 RINEX、星历、轨道、设备表
第一层  采集与物理          接收机、天线、电源、网络、站点

这份档案站在第二层：往上是解释，往下是硬件。它的所有质量问题的根源都在这一层——它不生成解释，所以解释的不确定性全留给下游；它依赖硬件，所以设备更换会原样写进数据。

8.2 与地震目录的分工

同属地壳形变研究，这份档案与地震目录是两把尺子。

维度	观测档案	地震目录
测什么	站点相对基准的持续位置	事件的时间、位置、震级
采样	秒级到分钟级，连续	事件级，离散
单元	站-日	事件
长于什么	震间缓慢累积	震时瞬时释放

前者测「震间」，后者测「震时」。把两者接起来，才能同时看到长期积累与瞬间释放。库内那份地震目录提供了事件的时间锚点，这份档案提供了事件前后的连续位置，中间的桥是「在事件时刻对两个产品做对齐」。

8.3 与再分析资料的分工

再分析资料给的是大气的连续四维场，格点化、已经插值、口径统一。这份档案给的是地面上的离散点、未插值、口径随设备而变。

两者在气象学上有接点：GNSS 观测可以反演大气可降水量，因为信号穿过对流层的延迟与水汽含量相关。这条链路让站网同时具备大地测量与气象两种用途，站表里也确有一列专门标注哪些站带独立气象传感器。

8.4 与遥感影像档案的分工

遥感影像档案给的是面，这份档案给的是点。面能覆盖，点能定标。影像的几何精度要靠地面控制点来检验，而这份档案的站恰恰是可以直接当控制点用的高精度地面位置。

它靠什么活着

一个跑了三十余年、每天被全球脚本轮询的服务，为什么没有在预算周期里消失。

第一层是法定职能。站网支撑的是国家空间参考系统，是法律意义上测量成果的基准。它不是一个可选的数据产品，是测量体系的地基。

第二层是下游依赖的刚性。测量、测绘、导航增强、气象、地壳形变、无人机定位，多个行业的标准作业流程都指过来。换掉它意味着同时改掉这些行业的作业规范。

第三层是多机构分摊成本。站由数百个机构自建自维，NGS 只做汇聚与处理。运营成本被拆散到各个机构的日常预算里，不集中在一处。

三层叠加，让它不需要「被商业化」也能持续。这也是它得以彻底开放的底气：开放不增加它的边际成本。

§9 使用指引：三条路径与一份最小实现

9.1 三种角色，三条路

角色	路径	关键动作
只想要一个点位	在线解算服务	上传静态观测，选对天线型号与天线高
想要一段时间的观测	逐日文件直下	先查清单确认当日完整，再按键取对象
想要坐标时间序列	自建解算或接外部日解	先统一框架与历元，再处理设备跳变

9.2 在流水线中的位置

站点采集 → 上传与转换 → 归档入库（档案从这里开始）
                          ↓
                    取观测 + 取坐标 + 取设备表
                          ↓
                    基线解算 / 框架统一 / 跳变处理
                          ↓
                    坐标时间序列 → 形变分析

这张图要说明一个常见误用：把档案当成「已经处理好的位置表」。它不是。从文件到序列之间隔着解算这一整层，而这一层档案完全不承担。

9.3 一份最小可跑的取数脚本

下面这段按站-日直取，自动跳过当日尚未写入的站点，并把头部元数据落成一行记录。它不依赖任何 GNSS 库。

#-- 依赖标准库;按站-日取数,缺文件不算错,只记缺失
import csv
import gzip
import io
import re
import urllib.error
import urllib.request

BASE = "https://noaa-cors-pds.s3.amazonaws.com/rinex"


def head_fields(key: str):
    """只取前 256 KB 解头部,避免整份下载"""
    req = urllib.request.Request(f"{BASE}/{key}", headers={"Range": "bytes=0-262143"})
    try:
        raw = urllib.request.urlopen(req, timeout=60).read()
    except urllib.error.HTTPError as e:
        return None if e.code == 404 else {"_err": e.code}
    text = gzip.GzipFile(fileobj=io.BytesIO(raw)).read().decode("latin-1")
    out, crinex = {}, None
    for line in text.splitlines():
        if len(line) < 60:
            continue
        label, value = line[60:].strip(), line[:60].strip()
        if label == "CRINEX VERS   / TYPE":
            crinex = value.split()[0]
        elif label == "END OF HEADER":
            break
        elif label in ("INTERVAL", "# / TYPES OF OBSERV"):
            out[label] = value
        elif label == "RINEX VERSION / TYPE":
            out["ver"] = value.split()[0]
    out["crinex"] = crinex
    return out


stations = ["1lsu", "1nsu", "1ulm"]
rows = []
for s in stations:
    for doy in ("292", "293", "294", "295", "296"):
        for ext in ("o", "d"):
            k = f"2026/{doy}/{s}/{s}{doy}0.26{ext}.gz"
            h = head_fields(k)
            if h is None:
                rows.append([s, doy, ext, "", "", "", "missing"])
            elif "_err" in h:
                rows.append([s, doy, ext, "", "", "", f"http{h['_err']}"])
            else:
                rows.append([s, doy, ext, h.get("ver", ""), h.get("crinex") or "",
                             h.get("INTERVAL", ""), "ok"])

with open("cors_head.csv", "w", newline="", encoding="utf-8") as fh:
    w = csv.writer(fh)
    w.writerow(["station", "doy", "ext", "rinex", "crinex", "interval", "status"])
    w.writerows(rows)
print(len(rows), sum(1 for r in rows if r[6] == "ok"))

三个细节值得注意。Range 请求只取头部，两兆的文件只需一百多 KB 就能拿到全部元数据。404 与其它错误码必须分开记，前者是当日没写入，后者是真故障。o 与 d 两行并排，正好把 §2.5 那个间隔差异摆在表里。

9.4 评估时最少要报的四件事

要报的	为什么	怎么报
参考框架与历元	框架不同，坐标不可比	写清框架名与历元年
解算策略	决定精度与系统偏差	写清参考站、高度角、模糊度处理
设备与天线变更时段	会在序列上造出假跳变	列出变更日期清单
取数时刻	同一键名下的对象可能被替换	写明日期，或存对象哈希

9.5 给做时间序列的人的一条建议

如果只记一件事：先看设备表，再看数据。

原因是坐标序列上最容易被误当成形变的东西，是天线更换造成的相位中心偏移。§1.5 的案例里，那个站在 2008 年换过一次天线，那一刻的坐标跳变量级，可能远超该站一整年的真实位移。不查设备表，就会把它写成一次「地表抬升」。

9.6 星历选用：精度与延迟的取舍

观测文件本身不含卫星位置。要算卫星在哪，必须配星历。仓里同时提供三档。

产品	延迟	精度量级	适用
广播星历	实时	米级	快速定位、粗解算
超快轨道	数小时	分米级	近实时应用
快速轨道	约一天	厘米级	日常精密解算
最终轨道	约两周	厘米级	事后精算

同一份观测配不同星历，得到的坐标可以差几个厘米。这条差异不是档案的错误，是「用哪一档」这个选择的结果。写方法时若只说「用了精密星历」，别人无法复现——精密到什么程度，取决于用了哪一档。

§10 AI 使用声明

项目	内容
数据性质	公开的工程测量观测档案，非个人数据
建议用途	定位解算、形变分析、大气水汽反演、地面控制点、格式解析的工程范例
不建议用途	作为常规地震监测的波形源、作为已清洗的位置表、作为统一口径的全球数据集
伦理注意	站点对应真实设施，引用站名时应按机构公开信息处理
引用要求	引用 NGS 的站网说明页与所用坐标解的发布说明，写明框架与历元
版本锁定	档案无版本号；复现须记录取数日期、文件名与坐标文件抬头
页面状态	已发布，最后核对 2026-10-30

常见误读

常见说法	实际情况	证据
「下载一个文件就能得到站点坐标」	文件里只有近似位置，官方明言应视为近似	数据说明页建议同时下载已发布坐标文件
「RINEX 3 是 RINEX 2 的新版本，换个解析器就行」	两代语法几乎不相容，历元行前缀、卫星标识、观测类型写法全不同	同一站在两代格式下的头部结构对照
「同一站同一天的文件间隔一样」	差分版与原始版间隔可能不同，头部注释会写明降采样	§1.5 的案例两份文件分别写 15 秒与 30 秒
「坐标变了说明站移动了」	多数是参考框架换代，抬头会写框架与历元	坐标文件抬头两行
「1994 年 2 月起就有观测数据」	采集起点是那天，档案里最早的观测文件在 6 月中	1994 年第 40 日与第 170 日目录对照
「当天文件当天齐」	索引先出现，站点文件后写入，某天可能只有星历	2026 年第 302 日只有六件对象
「站表里两千六百个站就是站网规模」	其中约六成三在运行，其余为退役、非运行、暂停	坐标汇总表的状态列
「两字母码 L1 就是三字母码 L1C」	后者显式写了信号通道，前者由接收机当时跟踪的通道决定	两代观测类型清单
「相位和伪距长得像，混着用也没事」	量级差一个波长倍数，取错列不报错但结果全错	一号频点两种观测量数值量级
「页面说公有领域」	页面只有免责条款，未见公共领域或知识共享标识	数据说明页底部的使用条款段
「小时文件随时能补取」	只保留两天，之后只剩降采样的日文件	数据说明页关于保留策略的段落
「许可没写就是随便用」	未声明不等于授权，引用时应如实说明官方只给了免责条款	同一条款的原文表述

附录 A 参数速查

项目	取值	说明
站号长度	4 字符	目录名小写
年积日	001–365/366	三位补零
日序号	0	当日全天
年份后缀	两位	扩展名前的部分
扩展名	d / o	差分压缩 / 未压缩
压缩	gzip	两种都要先过这一层
压缩算法版本	CRINEX 1.0 / 3.0 等	写在 d 文件首行
采样间隔候选	1 / 2 / 3 / 5 / 10 / 15 / 30 秒	站表申报值
星历后缀	n / g	GPS / 格洛纳斯
精密轨道前缀	igs / igr / igu	最终 / 快速 / 超快
坐标目录	coord_20 等	数字对应框架版本
单次列举上限	1000 键	超出需游标续翻
小时文件保留	2 天	之后仅剩日文件
日文件降采样	30 天后降到 30 秒	分发策略

附录 B 术语表

术语	含义
GNSS	全球导航卫星系统，涵盖 GPS、格洛纳斯、伽利略、北斗等
CORS	连续运行参考站，常年运行、位置已知的地面接收站
RINEX	与接收机无关的交换格式，GNSS 观测的通用文本容器
载波相位	从起始时刻累计到该历元的载波周数，含小数部分
伪距	由信号传播时间折算的等效距离
失锁标志	相位连续性被判定中断的标记
Hatanaka 压缩	利用历元间相关性做差分压缩的 RINEX 专用算法
CRINEX	Hatanaka 压缩后的容器格式名
SP3	卫星精密轨道与钟差的交换格式
广播星历	由卫星播发的轨道与钟参数，精度较低但实时可得
天线相位中心	天线实际接收信号的等效原点，与几何中心不重合
天线参考点	天线几何基准点，坐标文件里给出的位置就是这个点
参考框架	定义坐标系统的一组基准站与解算约定
历元	参考框架所对应的时刻，坐标在这一时刻有效
多年解	把多年观测一起处理得到的单一坐标与速度
基线解算	用两个站的同步观测差分解出相对位置
同震位移	地震发生瞬间造成的地表永久位移
数据延迟	从观测时刻到文件可下载之间的时间

附录 C 引用与许可

引用建议同时给出站网说明页与所用坐标解的发布说明。说明页里给出了重处理的年份范围、对齐方式与发布时刻，这几项是复现坐标的必要条件。

许可方面需要说清三件事。其一，数据说明页底部给出的是免责条款，措辞是「已尽力保证准确可靠，但不对数据错误导致的损害负责、不作任何担保、使用风险自负」，这不是许可标识。其二，页面通篇未见公共领域声明，也未见知识共享协议名称，因此这里不替官方写具体条款。其三，站的产权分散在数百个机构手里，各机构的贡献条款未被统一声明，商用前宜逐个确认。

编辑说明

核验时间 2026 年 10 月 30 日。方法：直接调用对象存储的列举接口，逐层核对桶的六个首级分区与 rinex/ 的年份、日目录结构；下载 2026 年第 296 日与第 100 日的两份逐日清单，统计文件数与站点数；用字节范围请求取回 1lsu 当日两份观测文件与一份广播星历、一份快速轨道，逐行解析头部与历元结构；读取坐标汇总表与单站坐标文件全文；读取设备变更总表全文并统计站点数与会话数；读取站点排序表并统计状态、采样间隔与延迟列；读取数据说明页、站网首页、在线解算服务首页与其说明页全文。

未覆盖的部分：未下载任何完整观测文件做全量解码，差分还原只解到第三个历元，未验证全文件的还原正确性；未订阅任何站点的逐日解算产品，因此「坐标时间序列」的实际可得性只有定性判断；未统计全库总对象数，只逐日估算；未打开质量曲线图，图内信息未核。

与候选调研底稿不符处，已在正文中更正，主要有五处。其一，底稿称历史自 1994 年 2 月 9 日起即「每日分卷存在」，实际第 001 至 170 日的日目录下只有广播星历与精密轨道，最早的站点观测文件在 1994 年第 170 日附近，稳定成文件约在 6 月中。其二，底稿称单日 8,086 个文件、单文件 1.25 至 2.92 兆，实际 2026 年第 296 日清单为七千二百四十行、观测文件约一千八百份，同日同一站的两份文件实测约 5.9 兆与 1.3 兆，量级与底稿不同。其三，底稿称采样为「15 秒或 30 秒」，实际站表申报档位有 1、5、10、15、30 秒五种，运行中的站里 1 秒档最多。其四，底稿称许可为「公有领域、NOAA 联邦作品」，实际数据说明页只给出免责条款，未见公共领域声明，也未见 SPDX 标识。其五，底稿未提及 2026 年 11 月 1 日起旧站点路径退役、分发主体迁往开放数据发布计划这一变动，也未提及坐标分区按参考框架分目录、新框架为 2020 版这一结构。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• ndbc-buoy — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• era5-single-levels — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• oisst-v2-1 — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• ibtracs — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• argo-gdac-floats — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• jhu-csse-covid-19 — 共享标签：公共卫生与流行病学 / 疾病监测 / 时序数据
• aqs — 共享标签：公共卫生与流行病学 / 疾病监测
• our-world-in-data — 共享标签：公共卫生与流行病学 / 时序数据
• mics — 共享标签：公共卫生与流行病学 / 疾病监测
• bts-on-time-performance — 共享标签：公共卫生与流行病学 / 时序数据

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。