CM95/docs/CM95_全球计划暂停与Japan_PBF低Zoom航标修复上下文_v1.md

CM95 全球计划暂停与 Japan PBF 低 Zoom 航标修复上下文 v1

1. 文档目的

本文用于把 NavSea 侧已经确认的事实、CM95 Japan PBF 暴露的问题，以及后续应由 CM95 项目承担的工作边界正式交接到 CM95 项目。

本文是上下文与状态交接文档，不是实现报告，也不代表 Japan PBF 修复已经完成。

后续 CM95/PBF 工作以 X220 上的实际仓库为唯一开发和生产事实源：

机器：X220
仓库：/root/sourceserver/cm95

CARBON7i 上曾做过的 PBF 实验只能作为调查线索，不作为正式实现、生产基线或最终结论。

---

2. 当前正式决定

2.1 全球 CM95 计划暂停

从现在开始：

Global CM95 Production = PAUSED

暂停原因：

Japan 区域已经确认存在与 Zoom 有关的助航对象保留缺陷。若在修复前继续扩展全球 PBF，很可能把同一生成缺陷复制到全球数据，之后产生大规模返工。

因此，在 Japan 修复、验证和冻结完成之前：

• 不继续扩大全球 CM95 生成范围；
• 不把当前 Japan 的 PBF scale/generalization 策略直接推广到全球；
• 不将当前 Japan 的低 Zoom 行为视为全球可接受基线。

2.2 Japan PBF 优先修复

当前 CM95 项目优先级改为：

Japan PBF correctness
→ Japan multi-region validation
→ Japan production freeze
→ 再评估 Global CM95 resume

---

3. NavSea 侧当前架构结论

NavSea 端已经重新收敛到以下架构：

CM95 PBF
  ↓
NavSea canonical source-layer / property contract
  ↓
NavSea canonical Style
  ↓
现有 1/2/3/4 挡
现有 Pickup
现有 ChartDangerAlarmSource

禁止继续走下面的方向：

CM95 raw S-52 Style
  ↓
让 NavSea 为 CM95 特别修改挡位 / Pickup / 报警

结论：

CM95 Provider 应负责把自己的数据生产为 NavSea 已定义好的 canonical Layer / property contract；NavSea 业务模块不应该理解 CM95 特有 Layer。

---

4. NavSea 真机已经验证通过的部分

测试机：

192.168.200.145

4.1 1/2/3/4 挡

已经实际验证：

3 → 2 → 1 → 4

均正常切换。

同时观察：

MapLibre resource cancel count = 0
ParseStyle error = 0
resourceUrl error = 0

说明当前挡位已经回到原 NavSea existing-layer visibility 热切换，不再通过重建整张 Style/MapView 实现。

4.2 Pickup

连续点击多个 CM95 航标，现有链路可以直接返回 NavSea 标准 Pickup 信息。

现有正式链路：

runNavSeaPickupJson
→ pickupInterpreter
→ CrossCursor

实际返回过：

• 小灯；
• 航路標識灯；
• red / green / white；
• omni；
• 距离与方位。

因此 Pickup 不需要增加 CM95 专用逻辑。

4.3 海图报警

现有 ChartDangerAlarmSource 仍使用 NavSea canonical render layer 和 canonical properties。

已经确认 CM95 canonical PBF 中存在相关：

• navigation_hazard_point；
• navigation_marks；
• baseline_area；
• facility / land / coast / structure 等标准 source-layer。

动态浅水报警 danger-depth-overlay 继续通过当前 Provider 的 analysisSourceId + baseline_area 生成。

CM95 的 baseline_area 已观察到标准深度分区，例如：

depth_zone_0-2m
depth_zone_0-5m
depth_zone_0-10m
depth_zone_2-5m
depth_zone_5-10m
depth_zone_10-20m
...

因此 ChartDangerAlarmSource 不应为了 CM95 改业务逻辑。

---

5. Canonical Style 已经排除为“丢灯”根因

在福冈湾真实 CM95 PBF 上做过逐对象检查。

对 PBF 中已经存在的灯类 navigation_marks feature，逐个执行 NavSea canonical Style 的灯标 filters。

结果：

unmatched = 0

也就是说：

只要 CM95 PBF 中已经存在该灯标，NavSea canonical Style 可以匹配并显示。

所以剩余的“低 Zoom 丢灯”问题发生在 Style 之前：

CM95 source
→ PBF Builder / scale selection / generalization / retention
→ PBF
→ NavSea canonical Style

当前不应继续通过修改 NavSea Style filter 来补偿。

---

6. 已确认的低 Zoom 现象

在固定福冈湾区域做过跨 Zoom 审计。

CM95 灯类对象在 Zoom 降低时存在明显减少。

特别是 z12 → z11：

• z12 中存在的一部分灯标在 z11 消失；
• 主要缺失对象中包含 minor_light；
• 使用空间匹配方式时，CM95 z12→z11 的保留率显著低于 Current NavSea。

曾观察到大致：

CM95 z12 → z11
50m 内保留率约 85%
100m 内保留率约 87%

而同类 Current NavSea 对照接近：

z12 → z11 ≈ 100%

因此 z11 已经可以明确视为 Japan PBF 的一个重点修复 Zoom。

z10 以下也存在更激进的数据缩减，但不应简单假设所有 z12 对象都必须无条件保留到全部低 Zoom；需要由 CM95 项目建立明确的安全对象 retention policy。

---

7. Current 与 CM95 原始数据并非完全一致

Current 与 CM95 是不同数据源。

已观察到类似差异：

Current: breakwater_lighthouse
CM95 附近对象: light_beacon

以及：

Current: harbor_lighthouse
CM95: coastal_lighthouse_over_15m

还存在几十米乃至更大的坐标差异。

因此禁止用以下方式修复：

距离很近
→ 认为是同一个对象
→ 自动把 CM95 类型改成 Current 类型

航标 canonical 分类必须依据 CM93/CM95 自身语义事实，例如：

• object class；
• relation/group；
• native scale；
• S-52 lookup；
• 原始 attributes；
• 已冻结的 mapping contract。

空间邻近只能用于审计和发现异常，不能作为生产语义改判依据。

---

8. CARBON7i 曾做过的调查线索

以下内容是在确认“X220 才是实际 CM95/PBF 工作机器”之前，在 CARBON7i 副本上做的实验。

这些内容只能作为 X220 调查线索，必须在 X220 当前真实代码、配置和数据上重新验证。不得直接复制实验代码。

8.1 一个强候选根因

CARBON7i 副本中的 Japan policy 曾显示类似：

z11:
50k
100k
200k
...

z12:
7.5k
20k
50k
100k
...

同时福冈区域数据库中大量 LIGHTS 存在于：

20k
50k
100k
...

由此得到一个需要在 X220 正式重新验证的强候选：

z12 会读取 20k LIGHTS
z11 从 50k 开始
→ 20k 独有灯标在 z11 被整体排除

8.2 不应把整个 z11 提升为 20k full detail

CARBON7i 的实验还显示，如果简单把整个 z11 scale ladder 改为包含 20k：

代表 tile 曾出现：

旧 z11:
约 3906 features

整个 z11 加入 20k:
约 6851 features

约增加 75%。

原因是 20k 中不仅有灯标，还包含大量：

• seabed text；
• area；
• line；
• label；
• 港区细节；
• 其他 feature。

因此不建议把整个 z11 直接升级为 20k/full detail。

8.3 值得在 X220 重新验证的设计方向

CARBON7i 实验曾验证一个更合理的方向：

为安全助航对象建立独立的 scale retention ladder，例如：

普通 z11 海图内容:
50k → 100k → 200k → ...

navigation_marks z11:
7.5k → 20k → 50k → 100k → ...

只针对助航组件，例如：

LIGHTS
BCNLAT
BCNSPP
BOYSPP
RTPBCN
TOWERS
_extgn

使用细尺度 quilt。

其他 source-layer 仍按正常 z11 ladder 生成。

CARBON7i 实验曾得到过以下结果：

单代表 tile：

z12 → z11 navigation_marks stable FID retention:
约 16.8% → 100%

总 feature:
3906 → 3933

PBF 体积:
约 +1%

非 navigation_marks layer count:
0 差异

福冈 12 张 z11 tile 实验曾得到：

z12 navigation_marks FID retention:
约 35.8% → 100%

非 navigation layer count 差异:
0

总 PBF 体积:
约 +1.1%

hard gate:
0

encoder drop:
0

这些只是实验线索。

正式 CM95 项目必须在 X220 当前实际 builder、policy、mapping、manifest、release 上重新实现和验证。

---

9. X220 当前事实源

后续开发机器：

X220

正式仓库：

/root/sourceserver/cm95

本文建立时观察到的分支：

main

本文建立前调查时观察到的 HEAD：

ed53864598f3059f524841fbe25dcd488fc1301a

注意：X220 当前 worktree 自身已经存在未提交修改。

因此后续任务必须：

1. 先读当前实际 diff；
2. 不覆盖现有未提交工作；
3. 只做本任务相关最小修改；
4. 不把无关文件一起提交；
5. 以 X220 当前实际文件为准，不使用 CARBON7i 副本替代。

X220 中已经确认存在：

/root/sourceserver/cm95/config/pbf/
/root/sourceserver/cm95/src/cm95pbf/
/root/sourceserver/cm95/build/production/
/root/sourceserver/cm95/build/releases-s52-v2/
/root/sourceserver/cm95/scripts/
/root/sourceserver/cm95/tools/

并存在 Japan production plan：

build/production/cm95_s52_japan_production_plan_v1.json

---

10. CM95 项目后续正式工作

10.1 第一阶段：X220 重新确认根因

必须基于 X220 当前实际版本重新检查：

config/pbf/cm95_tile_policy_japan_full_detail_v1.yaml
src/cm95pbf/builder.py
src/cm95pbf/production.py
build/production/cm95_s52_japan_production_plan_v1.json

至少回答：

• z11 实际 scale ladder；
• z12 实际 scale ladder；
• LIGHTS / beacon / buoy 等助航对象的 native scale 分布；
• z12 中存在但 z11 消失的对象主要来自哪些 native scale；
• 20k LIGHTS 是否确实是主要来源；
• 当前 builder 是如何做 scale-region quilt 和 finer-scale coverage suppression 的。

10.2 不修改 importer

当前问题属于 PBF production 阶段。

除非出现新的直接证据，否则不要修改：

CM93 parser
geometry normalization
MySQL importer
raw source records

10.3 优先研究 navigation aid 独立 retention

优先方向：

navigation_marks 使用独立 scale ladder

而不是：

整个 z11 直接启用 20k/full detail

实现时应保持：

• stable FID 不变；
• composite relation 语义不变；
• 多 LIGHTS 合成逻辑不变；
• S-52 presentation 字段不退化；
• trace / report / hard gate 继续准确；
• 其他 source-layer 不被细尺度数据无意放大。

10.4 单 Tile A/B 验证

至少比较：

旧 z11
候选修复 z11
对应 z12 四个 child tiles

指标：

• navigation_marks stable FID retention；
• canonical_object_type 分布；
• 非 navigation layer feature count；
• PBF byte size；
• duplicate FID；
• hard gate；
• encoder drop；
• build report；
• trace consistency。

10.5 Japan 多区域抽样

正式冻结前至少抽样：

• 函馆；
• 仙台；
• 东京湾；
• 大阪湾；
• 广岛湾；
• 福冈；
• 唐津；
• 长崎；
• 那霸。

不能只凭福冈一片区域通过就宣布 Japan 修复完成。

10.6 Japan 全量重建

不要边全国构建边修改 policy。

应先冻结：

builder contract
Japan tile policy
mapping
audit tool
acceptance thresholds

然后再生成正式 Japan production plan 并全量构建。

---

11. Global CM95 恢复条件

Global CM95 不因为 Japan 局部修复通过就立即恢复。

建议至少满足：

1. Japan z11 navigation aid retention 根因确认；
2. Japan 修复实现完成；
3. stable FID 不破坏；
4. composite navigation aids 无重复；
5. 非 navigation layer 无非预期变化；
6. hard gate PASS；
7. encoder drop = 0；
8. PBF 体积增长在可接受范围；
9. 多区域抽样通过；
10. Japan 全量 production audit 通过；
11. Japan release 完成；
12. NavSea 真机低 Zoom 显示回归通过。

达到以上条件后，才允许讨论：

Global CM95 Production = RESUME

即使恢复全球计划，也应先把 Japan 修复抽象成 provider-neutral / production-safe contract，再逐区域扩大，不应直接把 Japan 特例硬编码到全球路径。

---

12. NavSea 项目边界

CM95 修复期间，NavSea 项目不要再修改以下模块来补偿 CM95 数据：

1/2/3/4 挡
Pickup
ChartDangerAlarmSource
CrossCursor
PbfLayerGroupConfig
MapLibre query compatibility

CM95 最终交付的 PBF 应满足现有 NavSea canonical Layer / property contract。

NavSea 只消费，不承担 CM95 PBF 数据补全和 zoom retention。

---

13. 当前状态摘要

NavSea CM95 canonical 接入：
  基本通过

NavSea 1/2/3/4 挡：
  真机通过

NavSea Pickup：
  真机通过

NavSea ChartDanger contract：
  已核对

Canonical Style filter 漏灯：
  已排除

CM95 Japan z11 低 Zoom 航标保留：
  已确认存在问题

Global CM95：
  PAUSED

Japan PBF：
  下一优先修复目标

实际工作机器：
  X220

正式仓库：
  /root/sourceserver/cm95