S-125：让海图知道"航标还正常吗"

S-101 电子海图里的航标有个隐含假设：它画的是计划状态——浮标在设计位置上、灯标按通告的灯质发光。但出海的人都知道，航标是海面上最"脆弱"的设施：灯会灭、浮体会漂、船会撞、台风过后整排标可能集体失踪。从"标不正常了"到"恢复原状"，这个窗口以小时和天计。

窗口期里航海事靠什么？传统答案是通告与广播：航标失常 → 发通告 → 印刷/广播 → 驾驶员手改海图。S-125（航标 AtoN 产品规范）把这条链路数字化：航标的状态本身变成一条数据流，叠加在 S-101 底图上。上一篇 S-64 里练的更新用例，应用的就是这种"变化"——只不过那时是演习数据，S-125 把它变成了日常。它的要素目录（FC 1.0.0，2026 年 3 月）收了 53 个要素类型——从灯浮、立标、日标到雷达应答器、灯船、分道指示线，海面上"帮你看路"的设施基本都在册（范围只管海上和港口，内河水道排除在外）。

它和 S-124 是一对搭档

S-124 航行警告说的是"有事发生"——以消息为中心，正文承载细节；S-125 说的是"哪个对象变成了什么状态"——以航标对象为中心，每个报告就是一次状态更新（S-124 的拆解见 S-124 航行警告那篇）。

拿一个典型场景串起来：某轮夜里撞沉了一个灯浮。

• S-124 视角：发布一条航行警告——"XX 水域某灯浮灭没"，带几何区域和正文，提醒过往船舶
• S-125 视角：该灯浮的对象状态更新为"失常/灭没"，附最后报告位置和时效

同一个事件，两个产品各管一层：S-124 告诉你发生了什么，S-125 维护着那个航标对象的"当前值"。渲染端两个图层都要接，缺一个就会出现"警告里说灯浮没了，海图上灯标还亮着"的自相矛盾。

虚拟航标：纸质时代不可想象的东西

S-125 里最颠覆直觉的概念是虚拟航标——要素目录里的正式名字就叫 Virtual AIS Aid to Navigation：一个物理上并不存在的标，靠 AIS 报文"广播"出来。

场景：深更半夜一艘船沉了，沉船标志的实体浮标最快也要天亮才能布设。这几个小时里，过往船舶怎么办？虚拟航标的答案：在电子海图上直接"设"一个标——它不在水面上，只在数据里和屏幕上，但效果和真标一样：有位置、有类型、有提醒。目录甚至为它单独定义了"熄灭（extinguished）"和"因技术故障或维护而不可靠（unreliable）"的状态——连假标也会坏，状态机一个不少。

这在纸质海图时代是不可想象的——图是印刷品，不能给不存在的东西留位置。电子海图显示的是"当前你应该知道的信息"，而不是"海面上有什么实体"，观念一换，航标体系多了一种全新的工具。相应地，渲染端必须把虚拟标和实体标明确区分——把虚拟标画得和真浮标一样，驾驶员找过去了就是人命问题。

渲染端要处理的三件事

• 状态可视化：同一个航标，正常/灭没/移位状态下的符号表达要有可感知的区分——"灭没的灯标"如果照常发光，比不画还危险
• 位置时效：漂移类航标的位置是"最后报告位置"，数据里带时间，显示上要让"这个位置有多新鲜"可感知
• 叠加纪律：和 S-124 一样，AtoN 状态层压在 S-101 底图之上，且不能遮蔽底图上的关键航行要素——覆盖信息与基础信息在显示层的关系，S-100 体系有明确的层次约定

三条的共同点：数据的"新鲜度"和"可信度"本身成为渲染要表达的信息。这是动态图层家族给渲染工程带来的新命题——S-104/111 时代是"值在变"，到 S-125 这里，连"这个值还算不算数"都要画出来。

家族拼图

至此动态与治理图层的主角都露过面了：S-104 水位、S-111 流场、S-124 警告、S-125 航标，加上底图 S-101 与水深 S-102——一个 S-101 ECDIS 要同时伺候的可变数据源已经不少，而这还没算 S-127 交通管理和 S-129 吃水净空。颜色这条线也没停：夜航的海图为什么是黑的——S-52 五套色板的逻辑，已经在路上。

---

我是夜航海图，做海图与地图渲染开发的工程师。博客「航图笔记」同步更新全部文章，欢迎 RSS 订阅；如果内容帮到了你，也欢迎在爱发电请我喝杯咖啡。