2. 电子海图数据格式与标准解析
ECDIS 能“读懂”海图，靠的不是屏幕本身，而是背后一整套由 IHO（国际水道测量组织）定义的数据标准。维护人员如果只把海图当成“文件拷贝”，遇到物标缺失、属性异常、更新失败时就无从下手。本节从数据封装、物标编码、标准演进三条线索切入，把 S-57、S-63、S-100 三套标准的关系讲清楚，并落到维护工作中的实际判断依据。
一、三套标准各管什么
很多初学者会把 S-57 和 S-63 混为一谈，其实二者职责完全不同：
- IHO S-57：规定电子海图数据的内容与结构——用什么物标、什么属性、什么几何形状来描述真实世界，以及数据如何组织成交换集（Exchange Set）。它是“海图说什么”的标准。
- IHO S-63：规定电子海图的加密与许可——数据如何加密（Blowfish 算法）、如何用 Cell Permit（单元许可）和 User Permit（用户许可）授权、如何做数据签名校验。它是“谁能看、数据是否被篡改”的标准。
- IHO S-100：新一代通用海道测量数据模型框架，采用 ISO 19100 系列地理信息标准与 UML 建模，是 S-101（新一代电子海图）、S-102（水深格网）、S-104（水位）、S-111（表面流）等一系列产品规范的上位框架。它是“未来所有海洋空间数据如何统一表达”的标准。
二、S-57 的数据封装结构
S-57 数据以“交换集”为单位分发。一个典型交换集包含：CATALOG.031（目录文件，描述本交换集包含哪些单元）、若干 .000 基础单元文件、对应的 .031 更新文件，以及 README.TXT 等辅助文件。每个 .000 文件内部按 ISO/IEC 8211 封装，逻辑上分为特征记录（Feature Record，描述物标）和空间记录（Spatial Record，描述几何坐标），二者通过记录标识号（RCID）关联。
特征记录的核心是“物标 + 属性”。例如一个灯标，物标类为 LIGHTS，属性可能包括 COLOUR（颜色）、LITCHR（灯质）、SIGPER（周期）、HEIGHT（高度）、VALNMR（射程）。属性值不是自由文本，而是受控编码，比如 COLOUR=3 表示绿色。维护时若发现灯标颜色显示错误，就要回到属性编码层面核对，而不是在显示设置里反复调。
三、物标编码与属性定义的实际意义
S-57 定义了约 180 多个物标类（如 BOYLAT 侧面标、DEPARE 水深区、OBSTRN 障碍物、RESARE 禁航区）和数百个属性。物标之间存在继承关系：例如 LIGHTS 继承自 LIGHTS 相关的抽象类，共享部分属性。这种面向对象式的建模，使得同一属性可以在多个物标中复用。
对维护工作的直接影响有三点：其一，属性缺失或越界会导致 ECDIS 显示异常或报警，例如 DEPARE 的 DRVAL1/DRVAL2（深度范围）若颠倒，安全等深线判断就会出错；其二，几何类型不匹配（点/线/面）会造成物标无法渲染，比如把面状禁航区误编码为线；其三，物标间关系（如灯标与航标、障碍物与水深区）依赖 RCID 与集合关系维护，更新时若关系断裂，会出现“灯标悬空”现象。
四、S-63 的加密与许可链路
S-63 的维护要点集中在“许可”和“完整性”两条链路上。数据提供方用 Cell Permit 对每个单元加密，用户端 ECDIS 用 User Permit（由硬件指纹生成）申请并安装许可。每次更新后，系统会用数据签名（基于 SA 证书体系）校验数据是否被篡改。维护中常见的“更新包无法安装”“许可不匹配”“签名校验失败”，分别对应许可文件与单元不匹配、User Permit 变更（如更换硬件）、数据在传输中被破坏三类原因。
五、标准演进对维护工作的影响
S-57 自 2000 年冻结 3.1 版后基本稳定，但它的局限也日益明显：仅支持二维矢量、属性模型较老、难以承载格网与时间序列数据。S-100 正是为解决这些问题而生，它引入通用要素模型、 portrayal（显示）与 portrayal 分离、以及基于 Web 服务的分发方式。对维护人员而言，这意味着三方面变化：
- 数据类型从单一走向多元：未来 ECDIS 上会同时叠加 S-101 矢量、S-102 水深格网、S-104 水位等，维护不再只是“更新 .000 文件”，而要管理多产品、多版本的数据集。
- 显示与数据解耦：S-100 的 portrayal 规则独立于数据，同一份数据在不同显示模式下表现不同，排障时要区分“数据问题”还是“显示规则问题”。
- 过渡期并存：当前大量船舶仍以 S-57 + S-63 为主，新造船逐步引入 S-100 产品。维护策略必须兼容两套体系，不能一刀切。
六、一个可执行的维护核对示例
假设某轮收到一份新的 ENC 更新包，安装后某灯标颜色显示为白色而非绿色。可按以下顺序核对（示例参数为教学假设）：
| 核对项 | 检查内容 | 判断依据 |
|---|---|---|
| 交换集完整性 | CATALOG.031 是否列出该单元及更新号 | 缺失则更新未生效 |
| 物标属性 | LIGHTS 的 COLOUR 编码是否为 3（绿） | 编码错误需回退或报数据方 |
| RCID 关联 | 灯标与航标、空间记录是否对应 | 关系断裂会导致渲染异常 |
| 许可状态 | Cell Permit 是否覆盖该单元及有效期 | 过期则数据不可用 |
| 签名校验 | 更新包签名是否通过 | 失败说明传输损坏或被篡改 |
这套核对顺序的价值在于：它把“显示不对”这一模糊现象，拆解为可逐项验证的标准层问题，避免维护人员在显示设置里盲目尝试。掌握 S-57 的内容结构、S-63 的许可链路、S-100 的演进方向，才能在数据维护中做到“知其然，更知其所以然”。