# 项目步骤记录

最后更新：`2026-04-18 14:18`
仓库：`/root/sourceserver/pbf`
远端：`ssh://git@nas:2222/tei/pbf.git`

## 文档规则

- `STEP_RECORD.md` 必须使用中文
- 后续新增输出文档必须使用中文
- 后续新增审计报告必须使用中文

## 当前固定基线

唯一固定使用的视觉审计页面：

- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`

当前页面版本：

- `HTML: compare-r19-20260402-1203`
- `Style: karatsu-final-style-r15-20260402-1203`
- `PBF: karatsu-final-pbf-20nm-20260402-1156-fullrefresh1`

## 2026-04-18 全国 full / semantic 逻辑审计与 AOI 图像审计启动

### 1. 本轮新增入口

- 已新增全国几何 / native 风险审计脚本：
  - [`navsea_geometry_native_audit.py`](/root/sourceserver/pbf/navsea_geometry_native_audit.py)
- 已新增全国 AOI 截图 + diff 审计脚本：
  - [`navsea_full_aoi_visual_audit.py`](/root/sourceserver/pbf/navsea_full_aoi_visual_audit.py)
- 已新增 AOI 配置：
  - [`tasks/pbf/NavSea_Full_AOI_Visual_Audit_2026-04-18.json`](/root/sourceserver/pbf/tasks/pbf/NavSea_Full_AOI_Visual_Audit_2026-04-18.json)

### 2. 全国人工审计页调整

- 已把全国人工审计页改为支持：
  - `?variant=full`
  - `?variant=semantic`
- 已同步部署：
  - [`src/pbf/navsea-compare-full-audit.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-full-audit.html)
  - `/mnt/sda1/www/newpec/navsea-compare-full-audit.html`
- 这样同一张页面就可以直接做：
  - 原始 `newpec vs full`
  - 原始 `newpec vs semantic`
  的固定 AOI 截图审计

### 3. 全国 z12 extent 逻辑审计结果

- 当前先聚焦全国最敏感的：
  - `z12`
- 抽查和目录统计确认：
  - `/home/wwwroot/pbf-delivery-full-20260415`
  - `/home/wwwroot/pbf-delivery-full-semantic-20260416`
  中都存在一批 `z12` 瓦片 extent 错退成 `4096`
- 修前统计：
  - `full z12`：
    - 总瓦片 `48556`
    - `1048576`：`47366`
    - `4096`：`1190`
  - `semantic z12`：
    - 总瓦片 `48556`
    - `1048576`：`47296`
    - `4096`：`1260`

### 4. 本轮逻辑修复

- 已先做硬链接备份，便于快速退回：
  - `/home/wwwroot/pbf-delivery-full-20260415-backup-20260418-preextentfix`
  - `/home/wwwroot/pbf-delivery-full-semantic-20260416-backup-20260418-preextentfix`
- 已按原始 `newpec` 同 tile 的 source extent 回写当前错片：
  - `full repaired = 1183`
  - `semantic repaired = 1215`
- 修后复核：
  - `full z12`：`48556 / 48556` 全部为 `1048576`
  - `semantic z12`：`48556 / 48556` 全部为 `1048576`

### 5. 当前视觉 AOI 审计结果

- 已跑全国固定 AOI 截图 + 图像 diff 报告：
  - [`report/full_aoi_visual_audit_2026-04-18_r1/full_aoi_visual_audit.md`](/root/sourceserver/pbf/report/full_aoi_visual_audit_2026-04-18_r1/full_aoi_visual_audit.md)
  - [`report/full_aoi_visual_audit_2026-04-18_r1/full_aoi_visual_audit.json`](/root/sourceserver/pbf/report/full_aoi_visual_audit_2026-04-18_r1/full_aoi_visual_audit.json)
- 当前固定 AOI：
  - 博多港中心 `10nm`
  - 东京湾 `10nm`
  - 大阪 `10nm`
  - 冲绳 `10nm`
  - 唐津 `5nm`
- 当前固定 zoom：
  - `10`
  - `12`

### 6. 当前视觉结论

- 当前差异最大的 case 不是 `semantic` 独有问题
- 而是：
  - `full`
  - `semantic`
  在同一 AOI 上同时大幅偏离原始 `newpec`
- 当前 top diff 主要集中在：
  - `冲绳 10nm z12`
  - `唐津 5nm z12`
- 代表 changed ratio：
  - `okinawa full z12 = 0.861954`
  - `karatsu full z12 = 0.859021`
  - `okinawa semantic z12 = 0.850170`
  - `karatsu semantic z12 = 0.847223`

### 7. 当前判断

- 这轮已经确认并修掉的是：
  - 全国 `z12 extent` 错片问题
- 这轮尚未收口的是：
  - 全国 `full / semantic` 与原始 `newpec` 的视觉等价性
- 且当前视觉差异更像：
  - `full / semantic` 共用的主线 style / PBF 问题
  - 不只是语义版单独引入的回退

### 8. 下一步

1. 继续按当前 AOI diff 排序，从：
   - `唐津 5nm z12`
   - `冲绳 10nm z12`
   开始逐张定位具体 layer / 对象组差异
2. 优先把：
   - `full` 和 `semantic` 同时异常的主线问题
   从语义版专项问题中剥离出来
3. 每修一类问题后，直接复跑同一组 AOI 截图，直到 diff 明显收敛

## 2026-04-18 全国热点 AOI 旧坏 tile 重建修复

### 1. 这轮补充确认

- 用户指出唐津热点截图右侧仍有明显大片空白
- 继续下钻后确认：
  - 上一轮修掉的只是 `extent = 4096` 错退片
  - 但当前全国 `full / semantic` 热点里还有另一类更深的问题：
    - 几何坐标本身被旧构建产物写坏

### 2. 已定位到的根因

- 在问题 tile 例如：
  - `12/3526/1643.pbf`
  上：
  - 原始 `newpec` 的正常 buffer 只约为 `±20480`
  - 但当前 delivery 旧 tile 的多层几何 `min_y` 已被写到约 `-1064960`
- 这不是 source 原始 PBF 自带的问题
- 因为用当前 builder 对同一 tile 临时重建后：
  - 几何最大 overflow 可回到正常的 `20480`
- 因此当前判断为：
  - 线上全国 `full / semantic` 里混有一批旧坏 tile
  - 需要直接按当前 builder 重建

### 3. 本轮新增重建脚本

- 已新增：
  - [`navsea_rebuild_hotspot_tiles.py`](/root/sourceserver/pbf/navsea_rebuild_hotspot_tiles.py)
- 用途：
  - 按全国固定 AOI 热点枚举 tile
  - 先用当前 builder 重建 `full`
  - 再以重建后的 full tile 为底稿刷新 `semantic`
  - 同时生成备份和修复报告

### 4. 本轮实际修复

- 已对当前固定 AOI 热点 tile 做一次重建修复：
  - 博多港中心 `10nm`
  - 东京湾 `10nm`
  - 大阪 `10nm`
  - 冲绳 `10nm`
  - 唐津 `5nm`
- 覆盖 zoom：
  - `10`
  - `12`
- 实际重建并部署：
  - `154` 张热点 tile 到 `full`
  - `154` 张热点 tile 到 `semantic`
- 备份目录：
  - `/tmp/navsea_hotspot_rebuild/backup_full`
  - `/tmp/navsea_hotspot_rebuild/backup_semantic`
- 修复报告：
  - [`report/full_hotspot_rebuild_2026-04-18/full_hotspot_rebuild.md`](/root/sourceserver/pbf/report/full_hotspot_rebuild_2026-04-18/full_hotspot_rebuild.md)
  - [`report/full_hotspot_rebuild_2026-04-18/full_hotspot_rebuild.json`](/root/sourceserver/pbf/report/full_hotspot_rebuild_2026-04-18/full_hotspot_rebuild.json)

### 5. 当前复核

- 已再次复核问题 tile：
  - `/home/wwwroot/pbf-delivery-full-20260415/12/3526/1643.pbf`
  - `/home/wwwroot/pbf-delivery-full-semantic-20260416/12/3526/1643.pbf`
- 当前两边都已从：
  - `max_overflow = 1064960`
  修回到：
  - `max_overflow = 20480`

### 6. 唐津 z12 单点复跑结果

- 已单独复跑：
  - [`report/karatsu_hotspot_verify_2026-04-18/full_aoi_visual_audit.md`](/root/sourceserver/pbf/report/karatsu_hotspot_verify_2026-04-18/full_aoi_visual_audit.md)
  - [`report/karatsu_hotspot_verify_2026-04-18/full_aoi_visual_audit.json`](/root/sourceserver/pbf/report/karatsu_hotspot_verify_2026-04-18/full_aoi_visual_audit.json)
- 结果：
  - `karatsu full z12`
    - 修前 `0.859021`
    - 修后 `0.761277`
  - `karatsu semantic z12`
    - 修前 `0.847223`
    - 修后 `0.751505`
- 说明：
  - 右侧大片空白已明显收敛
  - 但当前视觉 diff 仍偏高，表示主线风格 / 文本 / 细节匹配仍未收口

### 7. 当前下一步

1. 继续对：
   - `唐津 z12`
   - `冲绳 z12`
   做第二轮逐层定位
2. 先把“旧坏 tile”与“主线 style 差异”两类问题彻底拆开
3. 之后再决定是否把这套 rebuild 从热点 AOI 扩到全国更大范围

## 2026-04-17 Karatsu 20nm final Native ParseTile 异常定位

### 1. 用户现象

- native 端出现大量：
  - `MapLibre error [ParseTile]: Could not get geometries: paths outside valid range of coordinate_type`
- 同时画面出现局部几何缺失 / 轮廓异常

### 2. 本轮确认结果

- 当前问题不能只归因于 style
- `pbf-delivery-karatsu-20nm-final` 本身存在对 native 不友好的高精度几何编码：
  - `z12` 瓦片 layer `extent` 普遍为 `1048576`
  - 且几何仍带有约 `±20480` 的 buffer 坐标
- 这套编码在浏览器 compare 页里仍可能勉强通过
- 但在 MapLibre Native 下会更容易触发：
  - `paths outside valid range of coordinate_type`

### 3. 本轮顺手发现的附带问题

- [`build_semantic_delivery_assets.py`](/root/sourceserver/pbf/build_semantic_delivery_assets.py)
  之前对命中替换的瓦片做了：
  - 解码
  - 改属性
  - 再编码
- 若重编码时不显式带回原 layer `extent`
  - 会把高 extent 瓦片直接写坏

### 4. 本轮代码修正

- 已确认 [`build_semantic_delivery_assets.py`](/root/sourceserver/pbf/build_semantic_delivery_assets.py)
  当前重写语义版瓦片时会：
  - 保留 feature `id`
  - 保留各 layer 原始 `extent`
- 已新增：
  - [`navsea_normalize_tile_extents.py`](/root/sourceserver/pbf/navsea_normalize_tile_extents.py)
- 用途：
  - 把现有高 extent 瓦片按比例归一到标准 `4096` 网格
  - 作为 native 兼容修复入口

### 5. 当前判断

- 这次“大量 ParseTile 报错”更接近：
  - delivery/final PBF 几何编码口径与 native 解析器兼容性不一致
- 下一步优先：
  - 先把 `pbf-delivery-karatsu-20nm-final` 归一化到 `4096`
  - 再回到 native 端复核是否还会持续抛同类 ParseTile 错误

当前仍使用同一张 HTML 做两个 profile：

1. 唐津 20 海里
   - `style.navsea-delivery-karatsu-20nm-final.json`
   - `pbf-delivery-karatsu-20nm-final`
2. 九州
   - `style.navsea-delivery-kyushu.json`
   - `pbf-delivery-kyushu-reencoded`

## 当前结论

- 当前主视觉问题不再优先怀疑 compare HTML 切错。
- 当前主问题分成两类：
  - `style` 过滤条件写错或过宽
  - 线上仍在使用较早生成的 `20nm final` 瓦片，部分关键对象没有 `class_code / display_code`

## 2026-04-16 灯弧缺失修复

### 1. 用户反馈

- 全国人工审计页右侧语义版中，灯标的光弧没有显示
- 左侧原始 `newpec` 可见，右侧 delivery / semantic 不可见

### 2. 本轮排查结果

- 不是 `sprite-semantic` 缺图块：
  - `arc-daytime-04027289`
  - `arc-daytime-m1`
  - `arc-daytime-m2`
  - `arc-daytime-m3`
  以及：
  - `light-daytime-1/2/3`
  在 `/mnt/sda1/www/newpec/sprite-semantic/sprite*.json` 中都还存在
- 当前真正根因是 delivery style 中：
  - `nav-light-arc`
  这一层被写成了：
  - `"visibility": "none"`
- 且页面脚本没有再把它切回可见
- 因此只要命中该层，最终仍会被整层隐藏

### 3. 本轮修复

- 已把以下样式中的：
  - `nav-light-arc`
  从隐藏改为可见
- 已修改：
  - `src/pbf/style.navsea-delivery-full.json`
  - `src/pbf/style.navsea-delivery-full-semantic.json`
  - `src/pbf/style.navsea-delivery-karatsu-20nm-final.json`
  - `src/pbf/style.navsea-delivery-karatsu-10nm.json`
  - `src/pbf/style.navsea-delivery-kyushu.json`

### 4. 页面版本提示

- 已同步更新全国人工审计页显示的语义版 style 版本号为：
  - `full-semantic-style-r2-20260416-2148`

### 5. 当前结论

- 这次“光的弧没有了”不是：
  - `PBF` 缺字段
  - 或 `sprite` 缺资源
- 而是 delivery style 把光弧层整层隐藏了
- 修完后，右侧 delivery / semantic 应恢复与左侧原始版同类灯弧显示

## 2026-04-16 投锚注意障害物图标缺失修复

### 1. 用户反馈

- 全国人工审计页中，`p投錨注意障害物`
  的一部分右侧语义版图标缺失
- 用户截图示例对象：
  - 左侧原始版 `fid = 15002075`
  - `分類番号 = 420`

### 2. 本轮排查结果

- 当前问题不是：
  - `sprite-semantic` 缺图
- 已核实：
  - `foul_ground`
  - `symbol-daytime-420`
  在语义版 sprite 中都存在
  - 且对应图块像素完全一致
- 同时已核实该区域 delivery / semantic `PBF` 中对象数量并未少：
  - 原始 `p投錨注意障害物` 当前 tile 为 `12` 个
  - delivery `anchor_caution_hazard_point` 当前 tile 也是 `12` 个
- 但当前 delivery 数据里这批对象的 `chart_icon_image` 仍普遍回落成：
  - `symbol-daytime-428`
- 因此在当前“语义版 style + 旧编号 icon 回落数据”混用阶段，
  - `anchor-hazard-points-428` 这层继续强行使用新语义 key
  - 风险高于收益

### 3. 本轮修复

- 已把语义版 style 中：
  - `anchor-hazard-points-428`
  这一层
- 从语义 key 映射临时回退为原始稳定的：
  - `symbol-daytime-*`
  映射
- 这样可保证：
  - 右侧语义版在这条危险物图标链上先恢复与原始版一致
  - 不继续依赖当前尚未完全收口的语义 key 图标链

### 4. 页面版本提示

- 已同步更新全国人工审计页显示的语义版 style 版本号为：
  - `full-semantic-style-r3-20260416-2210`

### 5. 当前结论

- 这次“图标丢失”更接近：
  - 语义版危险物图标映射链在当前过渡阶段不够稳
- 当前先按“恢复原始表现优先”处理
- 后续若要继续推进这条危险物图标的语义 key 迁移，
  - 应先把 builder / PBF 输出里的 `chart_icon_image` 也一并收口

## 2026-04-16 危险物图标 builder 正式修复与局部 PBF 回写

### 1. 本轮继续处理目标

- 不再只停留在 style 兜底
- 继续把：
  - `p投錨注意障害物`
  - `p航行危険障害物`
  的图标问题收回到 builder / PBF 输出层

### 2. 当前确认的根因

- `navsea_tile_builder.py` 里危险物 `chart_icon_image` 的派生逻辑此前只看：
  - `canonical_object_type`
  - `chart_symbol_code`
  - `hazard_class`
- 没有把：
  - `class_code / 分類番号`
  纳入优先判定
- 结果就是：
  - `420`
  - `434`
  这类对象会被粗暴回落成：
  - `symbol-daytime-428`

### 3. builder 侧正式修复

- 已在：
  - `navsea_tile_builder.py`
  中新增危险物：
  - `class_code -> icon`
  正式映射表
- 当前 `infer_chart_icon_image()` 已改为：
  - 对 `p投錨注意障害物 / p航行危険障害物`
  先按 `class_code` 精确出图标
  - 再回退旧的粗语义判断

### 4. 当前样本验证

- 直接验证 builder 推断结果已变为：
  - `420 -> foul_ground`
  - `428 -> fish_reef`
  - `434 -> subsea_installation_outfall_intake`

### 5. 当前 PBF 局部回写

- 由于全国全量危险物瓦片回写耗时过长，本轮没有继续强行等完全量收口
- 当前先对用户截图所在区域的局部 `z12` 瓦片做了就地回写
- 本轮实际改动到的 delivery 瓦片：
  - `12/3549/1624.pbf`
  - `12/3551/1622.pbf`
  - `12/3551/1623.pbf`
- 与其硬链接共享的语义版目录中的对应瓦片也同步生效

### 6. 当前关键抽样结果

- 已复核：
  - `/home/wwwroot/pbf-delivery-full-20260415/12/3550/1623.pbf`
  - `/home/wwwroot/pbf-delivery-full-semantic-20260416/12/3550/1623.pbf`
- 当前 `anchor_caution_hazard_point` 中的图标值已变为：
  - `420 -> foul_ground`
  - `428 -> fish_reef`
  - `434 -> subsea_installation_outfall_intake`

### 7. 页面版本提示

- 已把全国人工审计页显示的语义版 `PBF` 版本号更新为：
  - `full-semantic-pbf-r2-20260416-2248-hazardfix`

### 8. 当前状态

- 当前：
  - style 兜底已补
  - builder 正式修复已落地
  - 用户当前审计区域的局部瓦片已完成回写
- 尚未完成的部分：
  - 全国全量危险物相关瓦片的完整重放 / 回写

## 2026-04-16 全国语义版 PBF 缺瓦片补齐

### 1. 用户指出的问题

- 用户反馈：
  - `src/pbf/style.navsea-delivery-full-semantic.json` 指向的全国语义版 `PBF` 不完整

### 2. 本轮排查结果

- 样式文件本身的 `tiles` 路径没有缺项：
  - `src/pbf/style.navsea-delivery-full-semantic.json`
  - 当前仍指向：
    - `http://192.168.200.184/pbf-delivery-full-semantic-20260416/{z}/{x}/{y}.pbf`
- 实际缺口出在语义版全国 `PBF` 输出目录：
  - 源目录 `/home/wwwroot/pbf-delivery-full-20260415` 共 `65148` 张瓦片
  - 语义目录 `/home/wwwroot/pbf-delivery-full-semantic-20260416` 共 `65145` 张瓦片
- 当前确认缺失的 3 张瓦片：
  - `12/3659/1567.pbf`
  - `12/3661/1548.pbf`
  - `8/223/101.pbf`

### 3. 根因判断

- 当前 `build_semantic_delivery_assets.py` 的生成逻辑是：
  - 先 `cp -al` 整树复制
  - 再并行重写命中旧 sprite key 的瓦片
- 这次语义版目录里少 3 张，更像是生成过程中个别目标瓦片未最终落盘
- 因而需要在重写完成后补一轮“输出目录完整性回填”，不能只假设整树复制一定 100% 留存

### 4. 本轮修复

- 已修改：
  - `build_semantic_delivery_assets.py`
- 新增收口逻辑：
  - 重写完成后，遍历源目录
  - 对输出目录中不存在的 `.pbf` 自动补硬链接 / 复制
  - 并输出：
    - `tiles_backfilled`
    - `tiles_total_after_backfill`
- 已把当前缺失的 3 张瓦片直接补回：
  - `12/3659/1567.pbf`
  - `12/3661/1548.pbf`
  - `8/223/101.pbf`

### 5. 当前状态

- 当前 `/home/wwwroot/pbf-delivery-full-semantic-20260416` 已与 `/home/wwwroot/pbf-delivery-full-20260415` 对齐到同样的瓦片总数：
  - `65148`
- `style.navsea-delivery-full-semantic.json` 对应的全国语义版 `PBF` 现已补齐，不再少这 3 张瓦片

## 2026-04-02 本轮关键发现

### 1. 航标紫色圈“又回来了”的原因

- 问题层：`nav-light-flare`
- 根因：这一层的过滤条件写得过宽，几乎所有带 `light_color_code` 的对象都会被套上 flare。
- 直接表现：
  - 一些本来不该带圈的航标、浮标又被画成紫色圈
  - 例如 `31300003` 这类脚手架浮标不应再命中 flare
- 现已修正：
  - `nav-light-flare` 只对原始样式允许的那几类灯标生效
  - 不再给普通浮标乱套圈

### 2. “眼睛”图标回来的原因

- 问题层：`anchor_caution_hazard_point`
- 根因不是对象丢失，而是线上旧 `20nm final` 瓦片里很多对象没有 `class_code`。
- 一旦 `class_code` 缺失，样式只能退回：
  - `chart_icon_image = symbol-daytime-428`
- 直接表现：
  - `420` 这类投锚注意危险物又被画成眼睛图标
- 实际核对结果：
  - 用当前 builder 只重建 `11/1765/820` 这一张瓦片后，同一批对象已经恢复：
    - `class_code = 420`
  - 同时对应浮标对象也恢复：
    - `display_code = 31300003`
    - `chart_icon_image = symbol-daytime-327`

### 3. 为什么会出现“我们改过了，怎么又错了”

- 之前改对的是 `style` 逻辑
- 但 compare 页底下继续使用的是较早生成的 `20nm final` 瓦片
- 这批旧瓦片缺少关键码值字段
- 所以一旦样式依赖这些字段，就会退回错误兜底图标

一句话总结：

- 这次回退不是“代码白改了”
- 而是“新 style 压在旧 PBF 上跑”，导致修正无法完整生效

### 4. `pパイロットステーション` 丢失的原因

- 这个对象不是 PBF 丢了。
- 实际核对结果：
  - 原始对象在 `z12/3530/1641`
  - 原始层：`pパイロットステーション`
  - 原始 `fid = 9002206`
  - `分類番号 = 500`
- 当前 final PBF 里也存在对应对象：
  - `source-layer = pilot_station_point`
  - `class_code = 500`
  - `chart_symbol_code = pilot_station`
- 真正问题：
  - final style 之前没有 `pilot_station_point` 这一层
  - 所以右侧页面虽然有对象，但完全没画出来
- 现已修正：
  - 新增 `pilot-station-points`
  - 固定使用 `symbol-daytime-500`

## 当前已落地的修正

- 已修正 `nav-light-flare` 过滤逻辑
- 已上线新的 compare 页版本号显示
- 已完成 `20nm final` 全量重生并切到线上
- 当前整套 `20nm final` 都是当前 builder 生成的新版本，不再是只修单瓦片

## 2026-04-03 canonical_object_type 去日文推进

### 1. 本轮代码侧已完成

- 在 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py) 中把：
  - `canonical_object_type` 的内部原值
  - 和最终 release 输出值
  分开处理
- 保留内部旧值给：
  - DB render rule
  - field value rule
  - 现有 builder 语义推断
- 最终输出到 delivery / final PBF 的 `canonical_object_type` 改为稳定 ASCII 值
- 已同步改：
  - [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
  - [`src/pbf/style.navsea-delivery-karatsu-20nm-final.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-20nm-final.json)
  - [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
- 当前 style 中原先直接依赖的日文 `canonical_object_type` 过滤值，已切到对应 ASCII 值。

### 2. 10nm 临时副本结果

- 临时副本目录：
  - `/tmp/pbf-delivery-karatsu-10nm-canonical-20260403`
- 当前结果：
  - `canonical_object_type` 非 ASCII 复扫结果已经降到：
    - `non_ascii_distinct = 0`
- 说明：
  - 唐津 10 海里这条可信 backend baseline 上，`canonical_object_type` 去日文已经跑通到 0 残留。

### 3. 10nm 渲染审计结果

- 新报告：
  - [`report/render_audit_10nm_canonical_type_2026-04-03.md`](/root/sourceserver/pbf/report/render_audit_10nm_canonical_type_2026-04-03.md)
  - [`report/render_audit_10nm_canonical_type_2026-04-03.json`](/root/sourceserver/pbf/report/render_audit_10nm_canonical_type_2026-04-03.json)
- 结果统计与 2026-03-31 trusted rerun 一致：
  - `exact_match = 121855`
  - `mismatch = 12912`
  - `missing_in_engineering = 5`
- 结论：
  - 本轮 `canonical_object_type` 去日文没有引入新的 10nm backend render 回退。

### 4. 20nm 对象保真审计结果

- 新报告：
  - [`report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.md`](/root/sourceserver/pbf/report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.md)
  - [`report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.json`](/root/sourceserver/pbf/report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.json)
- 结果：
  - `tiles compared = 154`
  - `raw objects = 4165`
  - `preserved = 4165`
  - `missing / wrong_relayer / identifier_lost / identifier_mismatch = 0`
- 结论：
  - 20nm final 在对象保真口径上没有因为本轮 `canonical_object_type` 清理出现对象级退化。

### 5. 当前未收完的部分

- 20nm 临时副本：
  - `/tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403`
- 已经完成过一轮旧映射 replay，也完成了对象保真审计
- 但在映射表补第二批 / 第三批尾项后，20nm 全量 ASCII replay 还没有完整重新跑完并做最终非 ASCII 复扫
- 因此当前真实状态是：
  - `10nm backend trusted baseline` 已完成去日文和审计
  - `20nm object preservation` 已完成审计
  - `20nm canonical_object_type 全量去日文复扫` 仍差最后一步 replay + rescan

## 当前未完成项

- 继续按同一张 compare 页回扫其他依赖 `class_code / display_code` 的细分类图标
- 继续做热点截图复核，确认没有新的样式回退
- 完成 `/tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403` 的全量 replay
- 对 20nm canonical 副本补做最终 `non_ascii canonical_object_type` 复扫

## 2026-04-04 全量 PBF 按最新逻辑重建启动

### 1. 本轮启动前确认

- 已按仓库续接要求复读：
  - `STEP_RECORD.md`
  - `PROJECT_HANDOFF_2026-03-31.md`
  - `NavSea_Delivery_Preflight_Audit_Spec.md`
  - `NavSea_Audit_Logic_And_Evolution_2026-04-01.md`
- 已确认当前远端仍是：
  - `ssh://git@nas:2222/tei/pbf.git`
- 已确认当前 builder 里的“最新逻辑”包含：
  - `navsea_tile_builder.py` 中 `RELEASE_CANONICAL_OBJECT_TYPE_MAP`
  - delivery / final 输出会把 `canonical_object_type` 物化为最新 ASCII 发布值

### 2. 启动过程中发现的阻塞

- 直接用脚本默认参数启动会失败：
  - `RuntimeError: navsea mapping registry is empty`
- 已核实数据库当前实际存在的规则 bundle 只有：
  - `bundle_id = navsea-core`
- 因此本轮全量重建统一改为：
  - `--bundle-id navsea-core`

### 3. 当前已启动的重建会话

- 为避免 `reference_tile_root` 和输出目录互相清空，已先把现有瓦片集合复制到：
  - `/tmp/pbf-refsets/karatsu10-delivery`
  - `/tmp/pbf-refsets/karatsu10-engineering`
  - `/tmp/pbf-refsets/karatsu20-delivery`
  - `/tmp/pbf-refsets/karatsu20-final`
  - `/tmp/pbf-refsets/kyushu-delivery`
  - `/tmp/pbf-refsets/kyushu-engineering`
- 当前正在运行的 builder 会话：
  - `karatsu10 delivery`: session `72703`
  - `karatsu10 engineering`: session `33691`
  - `karatsu20 delivery`: session `9519`
  - `karatsu20 final`: session `97913`
  - `kyushu delivery`: session `79176`
  - `kyushu engineering`: session `88222`
- 统一使用：
  - `--fid-key thisMyWorld@2026`
  - `--bundle-id navsea-core`
- delivery / final 口径统一附带：
  - `--release-minimal`
- engineering 口径统一附带：
  - `--engineering`

### 4. 本轮目标

- 把当前活跃的 builder 产物统一按最新逻辑重放：
  - `/home/wwwroot/pbf-delivery-karatsu-10nm`
  - `/home/wwwroot/pbf-engineering-karatsu-10nm`
  - `/home/wwwroot/pbf-delivery-karatsu-20nm`
  - `/home/wwwroot/pbf-delivery-karatsu-20nm-final`
  - `/home/wwwroot/pbf-delivery-kyushu-reencoded`
  - `/home/wwwroot/pbf-engineering-kyushu`

### 5. 下一步

1. 持续轮询 6 个 builder 会话，确认没有新的运行时异常
2. 待会话完成后复核各目录瓦片数是否回到原集合规模
3. 如需要，再补做 `canonical_object_type` 非 ASCII 复扫与对象保真 / render 审计

## 2026-04-05 九州 compare 图标问题收口

### 1. 新确认的问题类型

- 九州 profile 中出现的“红 X 变鱼礁 / 航标 icon 不对”，本轮确认不属于前一轮唐津那种：
  - `旧 PBF 缺 class_code / display_code`
  - 导致样式退回兜底图标
- 本轮在九州对应瓦片中核实到：
  - `class_code`
  - `display_code`
  - `canonical_object_type`
  - `chart_symbol_code`
  这些关键字段本身是存在的
- 因此当前九州问题的真实根因是：
  - `style.navsea-delivery-kyushu.json` 仍停留在较早的粗分类图标逻辑
  - 没有同步到 `karatsu 20nm final` 已经收好的精细图标分支

### 2. 危险物图标根因

- 旧原始样式对：
  - `409`
  - `420`
  - `425`
  - `428`
  - `434`
  都是按 `分類番号` 分开画不同图标
- 但九州 delivery 样式之前：
  - `navigation_hazard_point` 只吃 `chart_icon_image`
  - `anchor_caution_hazard_point` 里 `obstruction / hazard_mark / fish_reef` 又被统一压进 `symbol-daytime-428`
- 所以视觉上会出现：
  - 红 X / 障碍物 / 鱼礁混成一类 icon

### 3. 航标图标根因

- 九州 delivery 样式之前的 `navigation_marks` 图标分支太粗：
  - `light_beacon` 固定画 `symbol-daytime-310`
  - 普通 `nav-marks` 也没有按 `display_code` 细分浮标 / 灯标样式
- 所以像 `312` 这类灯浮标、以及更细的 `311xxx / 312xxx / 323xxx / 325xxx` 都会回成粗图标

### 4. 已完成修正

- 已把 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) 同步到 `karatsu 20nm final` 的图标口径：
  - `hazard-points` 改为优先按 `class_code` 精确分图标
  - `anchor-hazard-points-428` 改为优先按 `class_code` 精确分图标
  - `nav-light-flare` 改为和 `display_code` / `minor_light` 口径一致
  - `nav-marks-light-beacons` 改为按 `display_code` 细分 `311xxx`
  - `nav-marks` 改为按 `display_code` 细分 `312/313/323/325/327/328` 等图标
  - 并补上 `lattice_buoy / pillar_buoy / can_buoy` 的 canonical fallback
- 已继续补上 `facility_boundary_point` 的设施点图标逻辑：
  - 不再固定画 `symbol-daytime-520`
  - 改为按 `class_code` 区分：
    - `505 / 510 -> symbol-daytime-505`
    - `520 -> symbol-daytime-520`
    - `530 -> symbol-daytime-530`
    - `540 -> symbol-daytime-540`
    - `550 -> symbol-daytime-550`

### 5. 已部署

- 已部署新的九州样式到：
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`
- 已同步 bump compare 页版本并部署：
  - HTML 版本：`compare-r22-20260405-0910`
  - 九州 style 版本：`kyushu-style-r4-20260405-0910`
  - HTML 路径：`/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`

### 6. 继续补到的小灯图标问题

- 新发现九州还有一类 `minor_light` 小灯点位图标不对
- 代表点位：
  - `display_code = 30600000`
  - delivery 中当前对象属性显示为：
    - `canonical_object_type = minor_light`
    - `chart_symbol_code = light_beacon`
    - `chart_icon_image = symbol-daytime-310`
- 旧原始样式中：
  - `30600000 -> symbol-daytime-303`
- 说明：
  - 这类点位不只是 style 旧逻辑问题
  - 也暴露出 builder 对部分 `minor_light` / `light_beacon` 的图标推断偏粗
- 当前先在九州 style 层做了旧版兼容兜底：
  - `nav-marks-small-lights` 改为按 `display_code` 细分：
    - `303xxx`
    - `305xxx`
    - `306xxx`
    - `307xxx`
    - `308xxx`
    - `309xxx`
  - 先恢复到原始样式的图标表现

### 7. builder 侧已继续收口

- 已在 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py) 中继续修正 `navigation_marks` 的图标生成逻辑：
  - 新增一组按旧 `display_code` 直接映射图标的 builder 内部表
  - 当前先覆盖：
    - `303xxx`
    - `305xxx`
    - `306xxx`
    - `307xxx`
    - `308xxx`
    - `309xxx`
- 已把原始 `canonical_object_type = 灯 (Lt)` 的语义判断单独识别为：
  - `chart_symbol_code = minor_light`
  不再先落到 `light_beacon`
- 单瓦片验证结果已确认：
  - `display_code = 30600000`
  - 现在 builder 直接产出：
    - `chart_symbol_code = minor_light`
    - `chart_icon_image = symbol-daytime-303`

### 8. 当前已重跑的 builder 会话

- 已重新启动：
  - `kyushu delivery`: session `80537`
  - `kyushu engineering`: session `73505`
- 目的：
  - 让九州现网 compare 不只依赖 style 兜底
  - 同时把新的 builder 图标推断真正写回 delivery / engineering PBF

## 下一步

1. 在固定 compare 页上复查：
   - 浮标不再被错误套圈
   - `420` 不再回成眼睛图标
2. 继续清理其他依赖 `class_code / display_code` 的细分类图标问题
3. 继续完成 20nm canonical 副本的全量 replay，并确认：
   - `canonical_object_type` 非 ASCII 残留归零或收敛到明确尾项
4. 如需上线这轮 canonical 去日文结果：
   - 先决定是否同时重放 20nm final PBF
   - 再决定是否同步部署 compare 用 style / 页面版本号

## 快速续接提示

下次继续时，先做这几件事：

1. 确认页面顶部版本仍然是 `compare-r18 / style-r14 / pbf-fullrefresh1`
2. 继续从博多港和中央航路这类热点回扫细分类图标
3. 优先检查仍依赖 `display_code / class_code` 的对象组

## 2026-04-05 九州 `at` 规则回扫

### 1. 对今天几类错位的统一判断

- 本轮重新对了原始 [`style.json`](/root/sourceserver/pbf/src/pbf/style.json) 后，已确认今天几类错位的共同根因是：
  - 之前仍在用“归一语义字段优先”的方式补样式
  - 但原始 `at` 图层实际是“旧字段直驱”
- 本轮重新钉实的规则：
  - `p航行危険障害物` / `p投錨注意障害物`：按 `分類番号`
  - `p錨泊地等`：按 `分類番号`
  - `p施設・境界線等` 点要素：按 `分類番号`
  - `p航路標識群` 主图标：按 `表示用番号`
  - `p航路標識群フレア`：按 `形状分類番号`
  - `p陸上構造物`：按 `分類番号` 直接拼 `symbol-daytime-*`

### 2. 本轮已修改的 delivery / style 逻辑

- 已修改 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)：
  - `anchorage-symbols` 改为优先按 `class_code` 直出 `719/720/721/724`
  - `nav-light-flare` 改为优先按 `shape_class_code` 命中原始 flare 允许集合，仅在缺字段时退回旧兼容分支
  - `nav-marks-harbor-lighthouses` / `nav-marks-breakwater-lighthouses` / `nav-marks-small-lights` / `nav-marks-light-beacons`
    - 过滤条件改为优先按 `display_code` 前缀分层
    - 仅在缺 `display_code` 时退回 `canonical_object_type`
  - `nav-marks` 主层过滤同步改为排除这些 `display_code` 前缀，而不再只靠 `canonical_object_type`
  - `facility-points` 保持按 `class_code` 分图标，并补上 `icon-ignore-placement`
  - 补回 `pilot-station-points`
  - `landmark-points` 改为优先按 `class_code` 直接拼 `symbol-daytime-*`
  - `landmark-point-fallback` 只对缺 `class_code` 且不在已知旧图标类中的对象保留圆点兜底

### 3. 本轮已修改的 builder / 字段保留逻辑

- 已修改 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py)：
  - `FINAL_RELEASE_PROPERTY_ALLOWLIST` 新增 `shape_class_code`
  - `--release-minimal` 口径现在也会保留 `shape_class_code`
- 已修改 [`tasks/pbf/mappings/navsea_field_name_rules_v1.yaml`](/root/sourceserver/pbf/tasks/pbf/mappings/navsea_field_name_rules_v1.yaml)：
  - `形状分類番号 -> shape_class_code` 改为 `keep_in_delivery: true`
- 目的：
  - 让 delivery PBF 重新具备支撑原始 `at` 规则的最小旧字段
  - 不再让 `航路標識群フレア` 只能靠 `display_code + canonical_object_type` 猜

### 4. 本轮已部署版本

- compare HTML 已 bump 并部署：
  - `HTML: compare-r23-20260405-1533`
  - 路径：`/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`
- 九州 style 已 bump 并部署：
  - `Style: kyushu-style-r5-20260405-1533`
  - 路径：`/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`

### 5. 本轮已重新启动九州重建

- 使用仓库虚拟环境 `.venv/bin/python`
  - 直接用系统 `python3` 会报：
    - `ModuleNotFoundError: No module named 'mapbox_vector_tile'`
- 已重新启动：
  - `kyushu delivery`: session `6078`
  - `kyushu engineering`: session `63691`
- 当前目标：
  - 把新的 `shape_class_code` 与 `at` 修正真正写回九州 delivery / engineering PBF

### 6. 下一步

1. 等待九州两套 builder 完成
2. 抽查热点瓦片，确认 delivery 内已出现 `shape_class_code`
3. 在固定 compare 页继续复查今天提到的几类同源错位点

## 2026-04-05 九州 delivery 双用途图层整理

### 1. 本轮新增整理文档

- 已新增：
  - [`NavSea_九州_Delivery_双用途图层分类_2026-04-05.md`](/root/sourceserver/pbf/NavSea_九州_Delivery_双用途图层分类_2026-04-05.md)

### 2. 本轮整理目标

- 不再只按旧样式/旧图层名字理解九州 delivery
- 改为按两个业务目标重新归类当前实际图层：
  1. 航海用
  2. 钓鱼用

### 3. 本轮整理结论

- 航海用的核心方向已明确为：
  - 危险物优先
  - 障碍物优先
  - 导助航优先
  - 净空/设施/锚地等通航约束优先
  - 水深细节退后
- 钓鱼用的核心方向已明确为：
  - 海底地形优先
  - 水深细节优先
  - 底质优先
  - 鱼礁 / 穴 / 海底结构优先
  - 安全层只保底不抢主视觉

### 4. 当前建议的实施方式

- 建议后续不要继续只维护一套 delivery style
- 而是同一套 PBF 下拆成两个 profile：
  1. `delivery-navigation`
  2. `delivery-fishing`
- 先拆 style，不急着拆数据

## 2026-04-07 九州 delivery 按对象属性分组整理

### 1. 本轮新增整理文档

- 已新增：
  - [`NavSea_九州_Delivery_对象属性分组_2026-04-07.md`](/root/sourceserver/pbf/NavSea_九州_Delivery_对象属性分组_2026-04-07.md)

### 2. 本轮整理目标

- 不再按“航海用 / 钓鱼用”分
- 改为按对象属性相同的 group 整理当前九州 delivery
- 目标是给后续 style 重排、profile 拆分、专题层拆分打基础

### 3. 本轮已整理的主要 group

- 等深线
- 鱼礁
- 灯塔
- 港口灯
- 渔网 / 渔具
- 海上标识
- 陆地设施
- 桥梁 / 跨空线
- 海底质
- 海底危险物
- 锚地
- 引航 / 航海服务
- 陆海背景与海岸线
- 地名与定位参考

### 4. 本轮结论

- 当前最值得继续细拆的 group 已确认是：
  1. 海底危险物
  2. 海上标识
  3. 陆地设施
  4. 海底质
- 这四组最适合作为下一步 style 结构重排和多 profile 组织的主切口

## 2026-04-07 九州 delivery 前端图层分组消费配置

### 1. 本轮新增配置文件

- 已新增：
  - [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json)

### 2. 本轮配置目的

- 给前端一个可直接消费的图层分组配置
- 不再让前端直接理解 style 内部的全部 render layer
- 让前端只面对：
  - 基础底图
  - 可切换业务 group
  - 航海 / 钓鱼 / 自定义预设

### 3. 当前配置内容

- 已包含：
  - `base_groups`
  - `groups`
  - `presets`
- 当前主要业务 group 包括：
  - 鱼礁/海底危险物
  - 海上标识
  - 锚地/引航
  - 港口与设施
  - 桥梁/净空
  - 等深线
  - 海底地形
  - 渔网/渔具
  - 海底质
  - 地名

### 4. 当前建议的前端消费方式

- 前端用 group 配置驱动 UI，不直接暴露底层 render layer
- 实际切换时，通过：
  - `map.setLayoutProperty(layerId, "visibility", "visible" | "none")`
- 建议用户入口只暴露：
  - 航海模式
  - 钓鱼模式
  - 自定义

### 5. 本轮 i18n 结构调整

- 已把 [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json) 从直接写死中文 `label` 的结构，调整为：
  - `label_key`
  - `description_key`
  - `i18n`
- 当前 key 命名已统一成：
  - `pbf.group.xxx`
  - `pbf.preset.xxx`
- 这样前端可以：
  - 先直接读同文件内的 `i18n`
  - 后续再平滑迁移到统一翻译系统

### 6. 本轮前端配置字段扩展

- 已继续给 [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json) 增加：
  - `sort_order`
  - `icon_key`
  - `feature_flag`
- 当前作用：
  - `sort_order`
    - 控制前端菜单展示顺序
  - `icon_key`
    - 让前端图标系统不必写死在代码里
  - `feature_flag`
    - 方便做灰度、AB、权限或版本开关控制

## 2026-04-08 全国 delivery 候选构建与严格审计启动

### 1. 当前目标

- 用户要求：
  - 生成全国范围 delivery 版本
  - 严格审计
- 本轮采取的口径：
  - 先生成全国候选目录
  - 不直接覆盖现网旧目录
  - 先跑对象保真 + render-hit 两层严格审计
  - 审计过后再决定是否切正式目录

### 2. 当前确认的全国构建方式

- `navsea_tile_builder.py` 已确认支持：
  - `--all-tiles`
- 当前全国原始源目录文件总量是：
  - `/home/wwwroot/newpec/exported_auto/tile.mapple-on.jp__newpec-mvt-20260106__z___x___y_.pbf/tiles`
  - 全量文件数：`79229`
- 当前旧全国目录状态：
  - `/home/wwwroot/pbf`：`65148`
  - `/home/wwwroot/pbf-engineering-full`：`65148`
- 说明：
  - 旧全国 full 目录不是当前源集合的完整重放结果
  - 因此本轮不能直接把旧目录当作可交付全国版

### 3. 本轮全国候选输出目录

- delivery 候选：
  - `/home/wwwroot/pbf-delivery-full-20260408`
- engineering 候选：
  - `/home/wwwroot/pbf-engineering-full-20260408`

### 4. 本轮已启动的全国构建会话

- 使用仓库虚拟环境：
  - `.venv/bin/python`
- 已启动：
  - 全国 delivery：session `8644`
  - 全国 engineering：session `60378`
- 使用参数：
  - `--all-tiles`
  - `--fid-key thisMyWorld@2026`
  - `--bundle-id navsea-core`
  - delivery 附带：`--release-minimal`
  - engineering 附带：`--engineering`

### 5. 当前已观察到的风险信号

- builder 已确认拿到的全国 tile job 数：
  - `79229`
- 但构建过程中已出现大量：
  - `skipped z/x/y`
- 这说明：
  - 全国源瓦片不等于全国 delivery 可写出瓦片
  - 严格审计第一层就必须先检查文件集合与对象保真
  - 很可能会暴露出：
    - 数据库候选缺失
    - 某些原始瓦片无可输出 rows
    - 全量覆盖不完整

### 6. 本轮严格审计计划

- 第一层：
  - 文件集合 / 覆盖率检查
- 第二层：
  - 全国对象保真审计
- 第三层：
  - 全国 render-hit 审计
- 当前说明：
  - 现有审计脚本默认口径偏 10nm / 20nm / kyushu
  - 本轮会在全国候选目录构建完成后，按全国路径重定向运行
  - 审计输出文档仍需单独整理成中文放行报告

### 7. 下一步

1. 等待全国 delivery / engineering 候选构建完成
2. 先做全国文件集合对齐检查
3. 运行全国对象保真审计
4. 运行全国 render-hit 审计
5. 输出中文严格审计报告并给出是否可交付结论

## 2026-04-08 delivery style sprite 统一

### 1. 本轮调整

- 按用户要求，把 delivery style 的 sprite 地址统一改为：
  - `http://192.168.200.184/newpec/sprite/sprite?v=111`

### 2. 当前已修改的仓库文件

- [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
- [`src/pbf/style.navsea-delivery-karatsu-20nm-final.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-20nm-final.json)
- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)

### 3. 当前说明

- 仓库内源文件已完成统一
- 线上 `/mnt/sda1/www/newpec/domain/` 下的部署文件尚未在本轮同步
- 后续如需页面立即生效，还需要再做一次部署同步

## 2026-04-08 全国 delivery style 草稿

### 1. 本轮新增文件

- 已新增：
  - [`src/pbf/style.navsea-delivery-full.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-full.json)

### 2. 本轮生成方式

- 以 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) 为底复制
- 仅调整：
  - `name -> NavSea Delivery Full`
  - `tiles -> http://192.168.200.184/pbf-delivery-full-20260408/{z}/{x}/{y}.pbf`

### 3. 当前说明

- 这是当前全国 delivery 候选 PBF 的配套 style 草稿
- 当前尚未单独部署到线上公开路径
- 当前也还没有配套的全国单屏 HTML / compare 页面

## 2026-04-08 全国 delivery style / HTML 部署

### 1. 本轮部署文件

- 已部署 style：
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json`
- 已部署 HTML：
  - `/mnt/sda1/www/newpec/navsea-final-delivery-full.html`

### 2. 当前可访问 URL

- style：
  - `http://192.168.200.184/newpec/domain/style.navsea-delivery-full.json`
- 单页查看：
  - `http://192.168.200.184/newpec/navsea-final-delivery-full.html`

### 3. 当前说明

- 全国版 style 现已不只是仓库草稿，已同步到线上公开路径。
- 当前 HTML 为单屏查看入口，不是 compare 页面。

## 2026-04-08 磁盘风险全量快照提交

### 1. 触发原因

- 用户反馈当前电脑硬盘可能存在问题
- 为避免本地未提交代码与文档因磁盘异常丢失，本轮优先执行一次仓库内全量快照提交

### 2. 本轮执行前确认

- 已按仓库续接要求复读：
  - `STEP_RECORD.md`
  - `PROJECT_HANDOFF_2026-03-31.md`
  - `NavSea_Delivery_Preflight_Audit_Spec.md`
  - `NavSea_Audit_Logic_And_Evolution_2026-04-01.md`
- 已确认当前远端仍是：
  - `ssh://git@nas:2222/tei/pbf.git`
- 已确认当前工作区包含大量：
  - 已修改代码
  - 新增 Domain 原型文件
  - 新增审计报告
  - 新增页面与 style 草稿

### 3. 本轮处理原则

- 本轮目标是“先保全当前仓库进展”
- 因用户明确要求提交所有代码，本轮采用全量暂存与提交
- 本轮提交不额外声称：
  - 已完成新的全国审计
  - 已完成新的交付放行结论

### 4. 当前说明

- 提交完成后，仓库历史中应保留一份可回溯的本地快照
- 若后续硬盘继续异常，优先再确认远端可推送与备份介质状态

## 2026-04-08 数据库完整备份

### 1. 备份原因

- 当前 PBF 生成链路不只依赖：
  - 旧 PBF
  - 代码仓库
- 还依赖数据库中的规则与映射数据

## 2026-04-15 全国 PBF 全量重建启动

### 1. 本轮目标

- 用户要求：
  - 把全日本海域的 PBF 都生成出来
- 本轮执行口径：
  - 沿用当前仓库可用的全国生成入口 `navsea_tile_builder.py --all-tiles`
  - 同时生成全国 `delivery` 与 `engineering`
  - 不覆盖 `2026-04-08` 旧候选目录，改为新日期目录

### 2. 启动前确认

- 已按仓库续接要求复读：
  - `STEP_RECORD.md`
  - `PROJECT_HANDOFF_2026-03-31.md`
  - `NavSea_Delivery_Preflight_Audit_Spec.md`
  - `NavSea_Audit_Logic_And_Evolution_2026-04-01.md`
- 已确认当前远端仍是：
  - `ssh://git@nas:2222/tei/pbf.git`
- 已确认当前 builder 仍需使用：
  - `--bundle-id navsea-core`
  - `--fid-key thisMyWorld@2026`

### 3. 本轮输出目录

- 全国 delivery：
  - `/home/wwwroot/pbf-delivery-full-20260415`
- 全国 engineering：
  - `/home/wwwroot/pbf-engineering-full-20260415`

### 4. 本轮计划命令

- delivery：
  - `.venv/bin/python navsea_tile_builder.py --all-tiles --output /home/wwwroot/pbf-delivery-full-20260415 --fid-key thisMyWorld@2026 --bundle-id navsea-core --release-minimal`
- engineering：
  - `.venv/bin/python navsea_tile_builder.py --all-tiles --output /home/wwwroot/pbf-engineering-full-20260415 --fid-key thisMyWorld@2026 --bundle-id navsea-core --engineering`

### 5. 下一步

1. 启动全国 delivery / engineering 全量构建
2. 等待两条构建跑完
3. 回填实际 tile 数、mapping audit 输出与目录状态

### 6. 2026-04-15 中途方向变更

- 用户随后要求：
  - `engineering` 版本暂停
- 已执行：
  - 全国 `engineering` 构建会话已人工中断
- 当前保留半成品目录：
  - `/home/wwwroot/pbf-engineering-full-20260415`
- 中断时已写出文件数：
  - `1485`
- 当前继续保留运行中的仅有：
  - 全国 `delivery` 全量构建

### 7. 2026-04-15 delivery 转后台持续运行

- 由于全国 `delivery` 全量构建耗时较长，本轮没有继续占用交互会话等待收尾
- 已把 `delivery` 改为后台进程持续运行
- 后台父进程：
  - `PID 74539`
- 实际 builder 子进程：
  - `PID 74548`
- 日志文件：
  - `/root/sourceserver/pbf/logs/full_delivery_20260415.log`
- 当前输出目录：
  - `/home/wwwroot/pbf-delivery-full-20260415`
- 切后台并重新启动后，builder 会先清空目标目录再重建
- 本次后台重启后首轮确认状态：
  - 已开始持续写入
  - 首次复核文件数：`91`

### 8. 当前下一步

1. 等后台 `delivery` 全量构建完成
2. 复核全国 delivery 实际输出文件数
3. 补看 `mapping_audit.json / .md`
4. 再决定是否需要全国对象保真 / render-hit 审计

## 2026-04-15 全国 style 指向修正

### 1. 本轮问题确认

- 用户反馈全国页面在 `zoom < 10` 时看起来“没有数据”
- 代表示例：
  - `/9/441/205.pbf`
- 本轮实际核对结果：
  - 新全国 delivery 目录中的该瓦片实际存在：
    - `/home/wwwroot/pbf-delivery-full-20260415/9/441/205.pbf`
  - 文件大小：
    - `78486`
  - 直接访问新目录 URL 返回：
    - `HTTP 200`
  - 旧 style 仍指向：
    - `http://192.168.200.184/pbf-delivery-full-20260408/{z}/{x}/{y}.pbf`
  - 同一路径在 `20260408` 目录下返回：
    - `HTTP 404`

### 2. 根因判断

- 不是全国 `delivery` 在 `zoom 10` 以下没生成
- 而是全国 style 还连着旧的 `20260408` 候选目录
- 因此前端请求到旧目录缺失瓦片时，会表现成低层级“没有数据”

### 3. 本轮已完成修正

- 已把仓库内全国 style：
  - [`src/pbf/style.navsea-delivery-full.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-full.json)
  的瓦片地址改为：
  - `http://192.168.200.184/pbf-delivery-full-20260415/{z}/{x}/{y}.pbf`
- 已同步更新线上部署文件：
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json`
- 已同步把全国单页查看入口文字从：
  - `Full 20260408`
  改为：
  - `Full 20260415`

### 4. 当前说明

- 这次修正解决的是：
  - 全国 style 与实际生成目录不一致
- 这不等于：
  - 全国严格审计已经完成
- 全国对象保真 / render-hit / 放行结论仍需后续单独收口
- 因用户担心硬盘风险，本轮补做数据库完整 dump 备份

### 2. 当前确认的数据库信息

- 当前项目主库：
  - `pbf_analysis`
- 当前连接方式：
  - `root`
  - `unix_socket = /tmp/mysql.sock`
- 本轮核对到的库体量约：
  - `19343.42 MB`

### 3. 本轮备份方式

- 使用：
  - `mysqldump --single-transaction --quick --routines --events --triggers --databases pbf_analysis`
- 输出为压缩文件：
  - `gzip`
- 备份时间戳：
  - `20260408_194631`

### 4. 本轮备份落点

- 第一份：
  - `/mnt/sda1/pbf_backup_20260408_194631/pbf_analysis_20260408_194631.sql.gz`
- 第二份：
  - `/home/tei/pbf_backup_20260408_194631/pbf_analysis_20260408_194631.sql.gz`

### 5. 校验结果

- 两份文件 `sha256` 一致：
  - `4cdb7d5c943b6223220a92f923ac718fccb73c7bc99c1007207cd60541a6f25a`
- `gzip -t` 校验通过：
  - `/mnt/sda1` 备份通过
  - `/home/tei` 备份通过

### 6. 当前说明

- 现阶段已同时保全：
  - 仓库代码与文档历史
  - PBF 生成所需主数据库快照
- 若后续还要进一步降风险，下一步可考虑：
  - 再做一份离机备份
  - 额外导出数据库表清单与建表结构摘要

## 2026-04-09 物体统一判定与点击查询设计收口

### 1. 本轮目标

- 按当前 `NavSea` 项目真实目标，整理一份可落地的物体模型设计文档
- 目标明确收口为三件事：
  - 点击物体后能知道“这是什么”以及关键细节
  - 能和 `NewPEC` 原体系稳定对回并审计“不丢对象”
  - 能渲染出与 `NewPEC` 等价的图标和文字语义

### 2. 本轮设计结论

- 不再尝试用单一字段同时承担：
  - 身份追踪
  - 本体分类
  - 渲染控制
- 统一改为三层职责：
  - `identity / trace`
  - `object semantics`
  - `render semantics`
- `canonical_object_type` 可以作为统一语义子类名的重要字段
- 但当前不应把它当成唯一主分类或唯一审计锚点
- `class_code / display_code` 仍要保留，并通过映射进入 NavSea 自有分类体系

### 3. 本轮新增文档

- 新增：
  - `NavSea_物体统一判定_点击查询_审计设计.md`

### 4. 文档重点

- 明确了 `native MapLibre` 点击拾取的结果模型
- 明确了 `NewPEC -> NavSea` 的码值映射思路：
  - `native_code_type`
  - `native_code_value`
  - `object_domain`
  - `object_class`
  - `object_subclass`
- 明确了两条硬审计线：
  - 物体不丢
  - 渲染结果一致
- 同时补充：
  - 字段完整性审计
  - 可查询性审计
  - AOI / 视觉审计

### 5. 下一步建议

1. 先把文档中的目标字段模型补进工程版 PBF 输出
2. 再补一版交付版最小字段清单，确认哪些查询字段必须保留
3. 为 `class_code / display_code -> NavSea object taxonomy` 建正式映射表
4. 在现有对象保真审计和 render audit 脚本上补：
   - 分类映射审计
   - 查询字段完整性审计

## 2026-04-09 首版语义定义草案补充

### 1. 本轮讨论结论

- 当前已经可以基于：
  - `Karatsu 20nm final` 实际标准层
  - `Chart Domain v1`
  给出一版 `NavSea` 首版语义定义草案
- 这版草案不再把问题停留在抽象层，而是直接回答：
  - 当前每个标准层在业务上是什么
  - 哪些层已经接近稳定业务对象层
  - 哪些层仍属于容器层 / 支撑层 / 待收敛层

### 2. 本轮文档更新

- 已在：
  - `NavSea_物体统一判定_点击查询_审计设计.md`
  中新增：
  - `21. 首版语义定义草案`

### 3. 当前首版定义重点

- 新增 `object_domain` 首版集合：
  - `navigation_mark`
  - `hazard`
  - `depth`
  - `clearance`
  - `anchorage`
  - `route`
  - `facility`
  - `landsea`
  - `seabed`
  - `toponym`
  - `fishery`
  - `support`
  - `pending`
- 已把当前主要标准层按上述域逐层定义

### 4. 当前已可视为稳定业务对象层

- `navigation_marks`
- `navigation_hazard_point`
- `anchor_caution_hazard_point`
- `depth_contour`
- `depth_contour_overview`
- `clearance_limit_point`
- `clearance_limit_line`
- `anchorage_area`
- `anchorage_point`
- `route_outline`
- `pilot_station_point`
- `place_label_sea`
- `place_label_land`
- `seabed_text_point`
- `land_area`

### 5. 当前仍待收敛层

- `baseline_area`
- `baseline_line`
- `baseline_outline`
- `facility_boundary_area`
- `facility_boundary_outline`
- `bathymetry_line`
- `hole_area`
- `depth_zone_739`
- `depth_zone_741`
- `clip_outline_754`

### 6. 下一步建议

1. 先把首版语义定义落成 builder 可输出字段：
   - `object_domain`
   - `object_class`
   - `object_subclass`
2. 再按 `source_layer + native code` 建正式 taxonomy 规则表
3. 在审计脚本中补：
   - 语义定义覆盖率审计
   - `pending/support` 漏入正式交付审计

## 2026-04-09 核心规则、20nm 调整判断与 pickup 消费方案

### 1. 本轮进一步收口的规则

- 对象主键继续固定为：
  - `fid`
- `NewPEC fid` 与 `NavSea fid` 视为同一主键的两种编码形式
- 当前正式口径继续坚持：
  - `1 raw object -> 1 primary feature`
- pickup、CPA、安全判断与渲染继续消费同一个统一对象载荷
- 不再为 query / CPA / render 设计三套不同对象模型

### 2. 当前对 20nm final 的判断

- 当前 `Karatsu 20nm final` 不建议推倒重写
- 当前更适合在现有标准层和现有 style 基线上做增量调整
- 优先补的是：
  - `object_domain`
  - `object_class`
  - `object_subclass`
- 当前不建议拆出独立 query API 取代统一对象载荷

### 3. 当前对 style 的判断

- 当前 style 主结构不建议大改
- compare 主视觉基线不切换
- 若要改动，优先改：
  - pickup 聚合逻辑
  - 面板展示结构
  - 左右按 `fid` 对照

### 4. pickup 消费方案

- native 端点击后应：
  1. 用小范围 `queryRenderedFeatures`
  2. 先按 `feature.id` 聚合
  3. 再按对象优先级挑代表对象
  4. 返回统一对象结构：
     - `fid`
     - 统一语义
     - 查询属性
     - 渲染命中信息
- 当前 compare 页现有 `features[0]` 逻辑只适合临时 inspect，不适合作为正式 pickup 口径

### 5. 当前阻塞说明

- 本轮尝试直接抽样解码 `/home/wwwroot/pbf-delivery-karatsu-20nm-final` 瓦片
- 但当前宿主缺少：
  - `python`
  - `python3 mapbox_vector_tile`
- 因此本轮关于 `20nm final` 字段现状的确认，主要仍依据：
  - builder 输出白名单
  - style 依赖
  - 现有对象保真报告

## 2026-04-09 20nm final 实际瓦片字段抽样确认

### 1. 本轮确认方式

- 已改用仓库内：
  - `.venv/bin/python`
- 已直接解码：
  - `/home/wwwroot/pbf-delivery-karatsu-20nm-final`
  中的真实 `.pbf` 瓦片

### 2. 当前确认结果

- 当前 `20nm final` 的对象 identity 确实主要走：
  - `feature.id`
- 示例：
  - `baseline_area` 抽样对象：
    - `id = 924902528`
    - `properties = canonical_object_type, chart_fill_style, class_code`
- 当前 `properties` 明显是瘦载荷，不再保留 engineering 风格的大量 trace 字段

### 3. 关键对象抽样结果

- `navigation_marks`
  - 保留：
    - `canonical_object_type`
    - `chart_icon_image`
    - `chart_label_position_code`
    - `chart_label_subtext`
    - `chart_label_text`
    - `chart_symbol_code`
    - `chart_text_color`
    - `chart_text_style`
    - `display_code`
    - `light_color_code`
    - `light_sector_mode`
    - `name_ja`
- `depth_contour`
  - 保留：
    - `canonical_object_type`
    - `chart_label_text`
    - `chart_text_color`
    - `chart_text_style`
    - `class_code`
    - `least_depth_m`
- `anchor_caution_hazard_point`
  - 保留：
    - `canonical_object_type`
    - `chart_icon_image`
    - `chart_symbol_code`
    - `class_code`
- `navigation_hazard_point`
  - 保留：
    - `canonical_object_type`
    - `chart_icon_image`
    - `chart_symbol_code`
    - `class_code`
- `clearance_limit_point`
  - 保留：
    - `canonical_object_type`
    - `chart_label_text`
    - `chart_text_style`
    - `class_code`
    - `clearance_height_m`
    - `name_ja`

### 4. 当前结论修正

- 当前 `Karatsu 20nm final` 不是“仅保留 style 最低限度字段”的纯渲染壳
- 它实际已经保留了一批：
  - pickup 可直接消费的关键字段
  - 渲染所需字段
  - 关键原生码值字段
- 但它也还没有补：
  - `object_domain`
  - `object_class`
  - `object_subclass`

### 5. 对后续设计的影响

- 当前更不建议拆出独立 query 数据源
- 更合理的方向仍然是：
  - 在现有统一对象载荷上继续增量补统一语义字段
- native pickup 继续围绕：
  - `feature.id`
  - 当前 `properties`
  做聚合和解释是可行的

## 2026-04-09 pickup 规则字典与解释器落地

### 1. 本轮目标

- 用户明确选择：
  - 不增加 PBF 容量
  - 前端基于 pickup 后拿到的 feature 信息自行判读
- 因此本轮落地：
  - 规则字典
  - 薄解释器

### 2. 本轮新增文件

- 新增：
  - `src/pbf/navsea-pickup-rules.v1.json`
  - `src/pbf/navsea-pickup-interpreter.js`

### 3. 当前规则字典内容

- 已覆盖当前主要标准层
- 已声明：
  - `object_domain`
  - 默认 `object_class`
  - 主分类码字段
  - pickup 标题字段优先级
  - 明细字段
  - render 回显字段
  - `support / broad / pending` 状态

### 4. 当前解释器职责

- 输入：
  - `queryRenderedFeatures` 候选数组
- 处理：
  1. 按 `feature.id` 聚合
  2. 按 `source_layer_std` 规则解释
  3. 生成统一 pickup 结果
- 输出：
  - `primary`
  - `candidates`

### 5. 当前更新规则

- 当前已明确：
  - 不是每次纯视觉微调都要改 pickup 规则字典
- 但以下情况必须同步更新：
  - PBF 标准层变化
  - 关键分类字段变化
  - style 主渲染字段依赖变化
  - 新增正式 pickup 层

## 2026-04-09 Native MapLibre React Native pickup 实现说明

### 1. 本轮目标

- 用户明确要求输出一份给前端团队直接实现的 Markdown 文档
- 前端目标环境：
  - `native MapLibre`
  - `React Native`

### 2. 本轮新增文档

- 新增：
  - `NavSea_Native_Pickup_ReactNative_MapLibre_实现说明.md`

### 3. 文档内容重点

- 明确当前 `native pickup` 返回三类结果：
  - `object`
  - `info`
  - `context`
- 明确：
  - 主对象层
  - 信息层
  - 默认屏蔽层
- 明确：
  - `feature.id` 作为对象主键
  - 空白水域返回深度上下文
- 明确：
  - 规则字典与解释器如何接入 RN 前端
- 已补：
  - `queryRenderedFeaturesInRect` 的官方方法参考

### 4. 当前实现建议

- RN 前端优先：
  1. 接规则字典 JSON
  2. 迁移/复用解释器
  3. 先做对象 + 信息 pickup
  4. 再补空白水域上下文

### 5. 当前说明

- 本轮没有再改 PBF / style
- 本轮输出重点是：
  - 让前端团队可按统一口径直接实现 pickup

## 2026-04-09 pickup 规则字典 r2 与 TS 解释器补齐

### 1. 本轮目标

- 用户明确要求把前端效率再提一步：
  1. 补更适合 `React Native` 的 TS 解释器版本
  2. 把 pickup 规则字典收成前端更容易直接消费的结构

### 2. 本轮已完成

- 已把：
  - `src/pbf/navsea-pickup-rules.v1.json`
  从首版规则升级为 `r2` 结构
- 已新增：
  - `src/pbf/navsea-pickup-interpreter.ts`
- 已同步更新：
  - `src/pbf/navsea-pickup-interpreter.js`
  - `NavSea_Native_Pickup_ReactNative_MapLibre_实现说明.md`
  - `NavSea_物体统一判定_点击查询_审计设计.md`

### 3. 规则字典结构变化

- 规则字典新增：
  - `render_layer_groups.primary`
  - `render_layer_groups.info`
  - `render_layer_groups.ignore`
- 原先较模糊的：
  - `feature_priority`
  已明确改为：
  - `pickup_priority`
- 同时为每个标准层补入：
  - `interaction_role`
  - `semantic_status`

### 4. 当前解释器变化

- JS / TS 两份解释器现在统一支持：
  - `getRenderLayerGroups`
  - `pickup_priority`
  - `interaction_role`
- 解释器仍保持“薄解释器”原则：
  1. 按 `feature.id` 聚合
  2. 按 `source_layer_std` 匹配规则
  3. 输出统一 pickup 结果

### 5. 对前端实现的直接收益

- RN 前端不需要再硬编码：
  - 主对象层数组
  - 信息层数组
  - 默认屏蔽层数组
- 只需读取规则字典中的：
  - `render_layer_groups`
- 这样后续若 style / pickup 规则变化，前端通常只需同步规则文件，不必手改代码

### 6. 本轮校验情况

- 已通过：
  - `jq . src/pbf/navsea-pickup-rules.v1.json`
  - `node --check src/pbf/navsea-pickup-interpreter.js`
- 当前未能完成：
  - `tsc` 编译校验
- 原因：
  - 当前环境没有可直接使用的 TypeScript 编译器，`npx tsc` 不可用

### 7. 当前结论

- 当前已可把：
  - `navsea-pickup-rules.v1.json`
  - `navsea-pickup-interpreter.ts`
  直接交给 `React Native + native MapLibre` 前端团队接入
- 当前不需要为这一步再改：
  - PBF
  - style

## 2026-04-10 pickup 解释器缺 layer 信息兜底修复

### 1. 本轮问题

- 用户提供了一条实际 `React Native` pickup 结果
- 现象是：
  - 对象能被拿到
  - 但 `source_layer_std = ""`
  - `object_domain = unknown`
  - `object_class = unknown`
  - 标题退化成了泛化的：
    - `灯标`

### 2. 根因判断

- 当前问题不是“排序把对象拿错了”
- 真正原因是：
  - RN 返回的 feature 中缺少 `sourceLayer / layer.source-layer`
  - 解释器无法命中 `navigation_marks` 规则
  - 于是只能走无规则 fallback
- 在旧逻辑里，一旦无规则：
  - `title` 会退到 `canonical_object_type`
  - `details` 会变空
  - `interaction_role` 只能落到默认值

### 3. 本轮修复

- 已在：
  - `src/pbf/navsea-pickup-interpreter.ts`
  - `src/pbf/navsea-pickup-interpreter.js`
  中补入两类兜底能力

第一类：

- 当 `source_layer_std` 缺失时，按属性推断标准层
- 当前已覆盖的典型规则包括：
  - `display_code / light_color_code / light_sector_mode / light_beacon` -> `navigation_marks`
  - `clearance_height_m` -> `clearance_limit_point / clearance_limit_line`
  - `least_depth_m / depth_value_m` -> `depth_contour / depth_contour_overview`
  - 危险物常见 `canonical_object_type` -> `navigation_hazard_point`

第二类：

- 当没有命中 layer 规则时，不再直接退成泛化标题
- 统一优先使用：
  - `name_ja`
  - `chart_label_text`
  - `canonical_object_type`
- 同时补通通用：
  - `details`
  - `render fields`
  fallback

### 4. 当前样本修复结果

- 用户提供的灯标样本：
  - `fid = 3305109497`
  修复后已能解释为：
  - `source_layer_std = navigation_marks`
  - `object_domain = navigation_mark`
  - `object_class = beacon`
  - `object_subclass = light_beacon`
  - `title = 博多港中央航路第2号灯標`
  - `primary_code_field = display_code`
  - `primary_code_value = 31135102`

### 5. 当前仍保留的说明

- 若 RN 侧能把原始 query 返回中的：
  - `feature.layer.id`
  - `feature.sourceLayer`
  完整保留传入解释器
- 则仍优先使用原始 layer 信息
- 当前属性推断仅作为：
  - 丢 layer 信息时的兜底恢复机制

## 2026-04-10 可见区域 pickup 分组与精确点查方案

### 1. 本轮问题

- 用户反馈一条实际 pickup 结果：
  - 当前画面上肉眼最明显的是紫色斜线渔业/渔具区域
  - 但 pickup 返回成了附近的 `beacon`
- 这说明当前问题不是对象分类本身，而是：
  - 可查询 render layer 分组不合理
  - 查询流程过于偏向“小框补捞点对象”

### 2. 根因判断

- 当前规则字典把：
  - `fishery-areas`
  这类明显可见的业务面层放进了 `ignore`
- 同时前端文档里只建议：
  - 先查 `primary` 点层
  - 再查 `info` 层
- 结果就是：
  - 用户点在渔网斜线面上
  - query 仍可能从小范围框内捞到附近灯标点
  - 于是出现“看起来像渔网，却返回灯标”的误判

### 3. 本轮修正

- 已在：
  - `src/pbf/navsea-pickup-rules.v1.json`
  中新增：
  - `render_layer_groups.area`
- 当前纳入的典型可见区域层包括：
  - `navigation-hazard-polygons`
  - `fishery-areas`
  - `anchorage-areas`
  - `facility-zones`
  - `submerged-structures`
  - `bridge-area`
- 同时把这些层从 `ignore` 口径中移出

### 4. 当前推荐查询流程更新

- 前端不应再只做“小框查主对象点层”
- 当前推荐改为：

1. 先做精确点查：
   - `area + primary + info`
2. 若精确点查未命中，再做小范围补查：
   - `primary + info`
3. 最后再回落到：
   - `context`

### 5. 当前文档更新

- 已同步更新：
  - `NavSea_Native_Pickup_ReactNative_MapLibre_实现说明.md`
  - `NavSea_物体统一判定_点击查询_审计设计.md`
- 当前文档里已明确：
  - 可见区域层属于正式 pickup 入口
  - `queryRenderedFeaturesAtPoint` 应先于小框补查

### 6. 附加调整

- 已补：
  - `display_name_overrides.beacon = 标柱`
- 避免无名称时标题直接显示生硬英文：
  - `Beacon`

### 7. 当前结论

- 对海图 pickup，不能只偏向“小点符号”
- 只要用户肉眼明确看到的是：
  - 渔网斜线面
  - 锚地区
  - 危险区面
  - 桥区
  这类可见业务区域
- 就应优先让这些区域对象进入 pickup 主候选

## 2026-04-10 同分候选按点击距离优先

### 1. 本轮问题

- 用户继续反馈：
  - pickup 返回的对象类型看起来对
  - 但返回的中心经纬度与实际点击附近图标相差很远
- 当前样例中出现的是：
  - 同一小框内命中了多个 `beacon`
  - 它们分数完全相同
  - 解释器按原始返回顺序取了第一个

### 2. 根因判断

- 当前问题不是 icon 自身做了大位移
- `nav-marks` 图标层核对结果：
  - 没有 `icon-offset`
- 真正问题是：
  - 多个同分点对象同时命中时
  - 解释器缺少“离点击点最近优先”的 tie-break

### 3. 本轮修复

- 已在：
  - `src/pbf/navsea-pickup-interpreter.ts`
  - `src/pbf/navsea-pickup-interpreter.js`
  中新增：
  - `click_lnglat` 可选输入
- 解释器现在会：
  1. 读取点击经纬度
  2. 计算点对象与点击点的球面距离
  3. 当两个候选 `score` 相同时，优先选距离更近者

### 4. 前端接入要求

- RN 前端在调用：
  - `interpretRenderedFeatures`
  时，应同步传入：
  - `click_lnglat`
- 否则对于同分候选，解释器仍只能退回到原始返回顺序

### 5. 本轮验证结果

- 已用两条同分 `beacon` 样本做本地验证
- 当点击点位于第二个对象上时：
  - 解释器已能正确优先返回更近的 `fid`
- 测试结果显示：
  - 最近对象 `distance_m = 0`
  - 远处对象约 `764.5m`
  - 返回对象已切换为最近者

## 2026-04-10 pickup 独立测试页

### 1. 本轮目标

- 用户明确要求提供一个独立 `pickup test` URL
- 用于直接排查：
  - exact point 命中
  - bbox 命中
  - 解释器 primary / candidates
  - 点击点与返回对象点之间的距离

### 2. 本轮新增文件

- 新增：
  - `src/pbf/navsea-pickup-test-karatsu-20nm.html`

### 3. 页面特性

- 使用：
  - `style.navsea-delivery-karatsu-20nm-final.json`
  - `pbf-delivery-karatsu-20nm-final`
- 页面会同时展示：
  - `exact point` 原始命中
  - `bbox` 原始命中
  - 解释器最终 `primary`
  - `candidates`
- 页面会在地图上画出：
  - 点击点
  - 返回对象点
  - 二者之间的连线

### 4. 相关部署

- 已部署页面：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`
- 已同步部署依赖：
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-interpreter.js`
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-rules.v1.json`

### 5. 当前访问 URL

- `http://192.168.200.184/newpec/navsea-pickup-test-karatsu-20nm.html`

### 6. 本轮校验

- 已通过：
  - `node --check src/pbf/navsea-pickup-interpreter.js`
- 已确认部署文件存在：
  - HTML
  - 规则字典 JSON
  - JS 解释器

### 7. 页面增强

- 已追加调试能力：
  - `BBox` 半径切换
  - 屏幕上的 `BBox` 可视框
  - 未过滤 query 命中面板
- 已补顶部摘要：
  - `Exact` 数量
  - `BBox` 数量
  - `Raw` 数量
  - `Raw render layer`
- 现在能更快区分两类问题：
  - 当前 `render_layer_groups` 漏层
  - 点击点/半径本身没命中任何 rendered feature

## 2026-04-10 危险区面层白名单漏层修复

### 1. 本轮定位结果

- 用户在 pickup test 页点击某危险区可见区域后，顶部摘要显示：
  - `Exact = 0`
  - `BBox = 0`
  - `Raw > 0`
- Raw 命中层明确包括：
  - `hazard-polygons`
  - `anchor-danger-outline`
  - `bathymetry-support`
  - `sea-area-fill`

### 2. 结论

- 当前问题不是点偏
- 也不是没有 rendered feature
- 真正根因是：
  - `hazard-polygons` 没有被纳入 `render_layer_groups.area`
- 该层在 style 中对应：
  - `source-layer = anchor_caution_hazard_area`

### 3. 本轮修复

- 已在：
  - `src/pbf/navsea-pickup-rules.v1.json`
  的 `render_layer_groups.area` 中补入：
  - `hazard-polygons`
- 已同步重新部署：
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-rules.v1.json`

### 4. 当前意义

- 这次结果进一步验证：
  - pickup test 页的 `Raw` 摘要是有效的
  - 它能很快区分“白名单漏层”和“点击点没打到对象”两类问题

## 2026-04-10 区域面与附近点图标的优先级修正

### 1. 本轮用户反馈

- 在同一位置存在两个对象：
  - `fish_reef` 鱼礁点图标
  - `anchor_caution_hazard_area` 投锚注意危险区域面
- 用户预期是：
  - 点击鱼图标附近时，应优先返回鱼礁
  - 不应被禁锚/危险区域面抢走

### 2. 本轮判断

- 单纯做“exact 命中的区域面优先”不符合海图使用直觉
- 更合理的口径是：
  - 若 `exact` 命中的是区域/次级对象
  - 但小框补查又命中了 nearby `primary` 点对象
  - 则优先返回该点对象

### 3. 本轮修复

- 已在 `pickup test` 页中补入：
  - `exact secondary` 与 `bbox primary` 的优先级切换
- 当前口径变为：
  - `exact primary` 仍优先
  - `exact area/secondary` 不再压过 nearby `primary` 点图标

### 4. 同步补充

- 已为规则字典补入：
  - `navigation_hazard_area`
  - `anchor_caution_hazard_area`
  两个 area layer 规则
- 避免未来点到这些区域面时仍只显示：
  - `unknown`

### 5. 当前意义

- pickup 现在更接近海图使用直觉：
  - 小而明确的点图标优先于大范围的区域面
  - 但区域面在附近没有更具体点对象时，仍可被正常选中

## 2026-04-10 pickup 展示字段命名修正

### 1. 本轮问题

- 用户指出：
  - `chinese_semantic` 这个字段名不对
  - 当前 PBF 原始数据并没有中文语义字段

### 2. 本轮结论

- 这个判断是对的
- 当前 pickup 里的该字段不是 PBF 原始字段
- 它只是规则字典中的本地展示标签
- 因此不应继续命名为：
  - `chinese_semantic`

### 3. 本轮修复

- 已把 pickup 相关资产统一改为：
  - `semantic_label`
- 已更新：
  - `src/pbf/navsea-pickup-rules.v1.json`
  - `src/pbf/navsea-pickup-interpreter.js`
  - `src/pbf/navsea-pickup-interpreter.ts`

### 4. 当前说明

- `semantic_label` 现在表示：
  - pickup 规则字典里的本地展示标签
- 它不表示：
  - PBF 原始字段
  - NewPEC 官方字段
  - 原始日文字段

### 5. 同步部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-interpreter.js`
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-rules.v1.json`

## 2026-04-10 空白水域点击回退到深度上下文

### 1. 本轮用户要求

- 用户明确指出：
  - 对这类点击，应该返回该区域的水深
- 也就是：
  - 不应只返回 `未命中对象`
  - 应进入 `context` 口径

### 2. 本轮实现

- 已在：
  - `src/pbf/navsea-pickup-test-karatsu-20nm.html`
  中新增：
  - `Depth Context` 面板
- 当前最小实现逻辑：
  1. 若对象 pickup 未命中
  2. 则查询附近可见深度相关层：
     - `bathymetry-depth-labels`
     - `depth-contour-labels`
     - `depth-contours-major-labels`
     - `depth-contours`
     - `depth-contours-major`
  3. 返回距离点击点最近的深度数字/等深线标签

### 3. 当前说明

- 这不是“真实底模插值”
- 当前只是：
  - 基于海图当前可见表达
  - 返回最近的深度上下文
- 但它已经比单纯的：
  - `未命中对象`
  更符合海图使用逻辑

### 4. 当前部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`

## 2026-04-11 海底地形与钓鱼判读文档整理

### 1. 本轮用户需求

- 用户希望把当前 `NavSea PBF` 里和海底情况相关的辅助信息整理成一份中文 `md`
- 重点不是抽象讨论，而是回答：
  - 当前 PBF 里哪些层和海底形态有关
  - 能否看出“槽、脊、坎、坑、突起”
  - 对钓鱼到底有什么帮助

### 2. 本轮新增文档

- 已新增：
  - [`NavSea_海底地形解读_钓鱼参考.md`](/root/sourceserver/pbf/NavSea_海底地形解读_钓鱼参考.md)

### 3. 本轮收口结论

- 当前 `NavSea PBF` 没有一个现成字段直接把海底形态定义成：
  - 槽
  - 脊
  - 坎
  - 坑
- 但已经具备足够的图面表达，可以基于：
  - `depth_contour`
  - `depth_contour_overview`
  - `bathymetry_line`
  - `seabed_text_point`
  - `submerged_reef_area`
  等层去做判读

### 4. 本轮补充说明

- 文档中已额外整理当前 PBF 可直接消费的相关字段：
  - `least_depth_m`
  - `depth_value_m`
  - `chart_label_text`
  - `canonical_object_type`
  - `class_code`
- 并明确说明：
  - `seabed_line` 目前应理解为“海底线表达”
  - 不能直接等同于“只有海底电缆”

### 5. 当前意义

- 这份文档可以直接作为：
  - 前端做空白水域深度上下文和地形提示的说明依据
  - 后续做钓鱼结构提示时的规则输入说明

## 2026-04-11 pickup test 页新增海底地形解读函数与面板

### 1. 本轮用户要求

- 用户希望按当前已经确认的设计思想：
  - 做一个“海底地形解读”函数
  - 再做一个对应显示 panel
- 目标是把当前图面可见的海底结构解释直接放进 pickup test 页，便于前端和业务一起看结果

### 2. 本轮实现

- 已在：
  - [`src/pbf/navsea-pickup-test-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-pickup-test-karatsu-20nm.html)
  中新增：
  - `buildTerrainInterpretation(event, depthContext)`
  - “当前海底地形解读” panel

### 3. 当前函数口径

- 当前实现仍然是规则版解释器
- 它不做：
  - 底模插值
  - 正式地貌分类确权
- 它只基于当前可见图面去综合判读：
  - `depth-contours`
  - `depth-contours-major`
  - `depth-contour-labels`
  - `bathymetry-support`
  - `bottom-material-labels`
  - `submerged-structures`
  - `fishery-areas`
  等图层

### 4. 当前输出内容

- panel 当前会显示：
  - 主判断
  - 结构提示
  - 深度跨度
  - 底质
  - 附近结构
  - 可信度
- JSON 输出里会保留：
  - `primary_judgement`
  - `local_depth_range_m`
  - `contour_density`
  - `seabed_material`
  - `nearby_structures`
  - `hints`

### 5. 当前判读原则

- 典型输出是：
  - `疑似明显坡折/陡坡`
  - `疑似缓到中等坡折`
  - `疑似槽/沟一侧或较深落差带`
  - `疑似脊/隆起一侧或浅高点边缘`
  - `局部地形相对平缓`
  - `疑似底质变化带`
  - `礁体边缘结构位`
- 所有文案都明确保持为：
  - `疑似`
  - `当前图面判读`
  不冒充“系统已确认地貌对象”

### 6. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`
- 页面版本已更新为：
  - `pickup-test-r2-20260411-1028`

## 2026-04-11 pickup 结果改为面向普通钓鱼人的简明解释

### 1. 本轮用户要求

- 用户进一步明确：
  - 如果点击的是露出海面或海面上的具体对象
    - 例如灯塔、渔网、标识、暗礁等
    - 就直接返回这个具体东西
  - 如果点击的是海底相关信息
    - 就返回水深
    - 物体名（有的话）
    - 海底形状的简单解读
- 并强调：
  - 文案要简单明了
  - 不要堆太多普通钓鱼人不熟悉的专业术语

### 2. 本轮实现

- 已在：
  - [`src/pbf/navsea-pickup-test-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-pickup-test-karatsu-20nm.html)
  中新增：
  - `buildFriendlyClickInterpretation(primary, depthContext, terrainResult)`
- 并把原来偏调试口径的“当前海底地形解读” panel 改成：
  - “当前点击解读”

### 3. 当前页面口径

- 当前点击结果会先分成两类：
  - `海面/露出物`
  - `海底信息`
- 判断逻辑大致是：
  - 航标、灯塔、可见渔具区、可见设施等
    - 优先按具体物体解释
  - 等深线、底质、海底线、潜礁、海底危险物等
    - 优先按海底信息解释

### 4. 当前海底解读文案

- 当前海底解读不再直接甩：
  - `坡折`
  - `槽`
  - `脊`
  这类专业词给终端用户自己消化
- 而是改成更口语化的话术，例如：
  - `这里水底起伏比较明显，像一道坎。`
  - `这里像水底一条沟的边上。`
  - `这里像水底一个小包或小凸起边上。`
  - `这里水底看起来比较平。`
  - `这附近像礁边，鱼容易沿边活动。`

### 5. 当前 panel 显示项

- 新 panel 当前显示：
  - 结果类型
  - 主显示
  - 当前水深
  - 物体名
  - 水底情况
  - 补充提示
- 同时保留 JSON：
  - 上层友好解释结果
  - 底层 `terrain_debug` 调试结构

### 6. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`
- 页面版本已更新为：
  - `pickup-test-r3-20260411-1056`

## 2026-04-11 “附近”口径改为真实米制范围

### 1. 本轮问题

- 用户指出：
  - 如果“附近”直接按 `px` 半径算
  - 那么它会和 `zoom` 强相关
  - 放大时实际范围变小
  - 缩小时实际范围变大
- 这不适合做正式业务口径

### 2. 本轮结论

- 这个判断是对的
- `px` 半径只适合调试 query 手感
- 不适合定义：
  - `100 米内算附近`
  这种稳定业务规则

### 3. 本轮修复

- 已在：
  - [`src/pbf/navsea-pickup-test-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-pickup-test-karatsu-20nm.html)
  中新增：
  - `screenRadiusForMeters(lngLat, meters, minPixels)`
- 当前实现改为：
  1. 先把点击点附近 `100m` 换算成当前 zoom 下对应的屏幕半径
  2. 用这个半径做 `queryRenderedFeatures`
  3. 再用真实 `distance_m` 二次过滤
  4. 只有 `distance_m <= 100` 的对象，才会进入：
     - `nearby_structures`
     - `附近有什么`

### 4. 当前意义

- 现在“附近”已经不再是：
  - 模糊的像素范围
- 而是：
  - 稳定的真实距离口径
- 即使缩放变化：
  - `附近 = 100 米内`
  这个业务语义不变

### 5. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`

## 2026-04-16 style 生成错误清理

### 1. 本轮判定口径

- 用户明确要求，若 style 中出现以下内容，一律视为生成错误：
  - `background-color: #f5f1e6` 或其他浅色底
  - `raster-opacity < 1`
  - `raster-saturation < 0`
  - 为低 zoom 单独增加 `wash / fog / skin / overview overlay`

### 2. 本轮已清理内容

- 已把命中的 style 统一修正为：
  - `background-color = rgba(255,255,255,1)`
  - `raster-opacity = 1`
  - `raster-saturation = 0`
- 已移除各类 `depth_contour_overview` 低 zoom 概略叠层
- 已同步处理仓库内和 `/mnt/sda1/www/newpec/domain` 下当前仍在使用或仍可能被引用的生成 style

### 3. 本轮已修正文件

- 仓库内：
  - `src/pbf/style.navsea-delivery-full.json`
  - `src/pbf/style.navsea-delivery-karatsu-10nm.json`
  - `src/pbf/style.navsea-delivery-karatsu-20nm-final.json`
  - `src/pbf/style.navsea-delivery-kyushu.json`
  - `src/pbf/style.navsea-engineering-karatsu-10nm.json`
  - `src/pbf/style.navsea-v2.json`
  - `src/pbf/style.karatsu-10nm-v2.json`
  - `src/pbf/style.navsea-redesign.json`
  - `src/pbf/style.navsea-semantic-only.json`
- 已部署目录：
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-10nm.json`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-20nm-final.json`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`
  - `/mnt/sda1/www/newpec/domain/style.compare-delivery-karatsu-10nm.json`
  - `/mnt/sda1/www/newpec/domain/style.domain-karatsu-10nm.json`
  - `/mnt/sda1/www/newpec/domain/style.domain-land-sea-karatsu-10nm.json`
  - `/mnt/sda1/www/newpec/domain/style.domain-legacy-compatible-karatsu-10nm.json`

### 4. 复核结果

- 已对以下目录做规则复扫：
  - `src/pbf/style*.json`
  - `/mnt/sda1/www/newpec/domain/style*.json`
- 当前复扫结果：
  - `TOTAL 0`
- 表示上述目录中已不存在本轮定义的四类 style 生成错误

### 5. 下一步

1. 若后续还要继续做 style 生成链路治理，应把同样规则前移到生成脚本/模板层
2. 在你确认后，再继续处理 sprite 语义 key 重命名与裁剪

## 2026-04-16 BASIS=T 命名建议整理

### 1. 本轮目标

- 用户已在 sprite 审计 Excel 中对部分 `new_sprite_key` 人工填写了：
  - `basis = T`
- 本轮任务是把这批人工命名再收敛一遍，整理成可审核的正式 key 建议表

### 2. 本轮输入

- 基础 Excel：
  - `tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.xlsx`
- 过滤范围：
  - `used` sheet
  - `basis = T`

### 3. 本轮输出

- CSV：
  - `tasks/pbf/NavSea_Sprite_Basis_T_建议修正表_2026-04-16.csv`
- Markdown：
  - `tasks/pbf/NavSea_Sprite_Basis_T_建议修正表_2026-04-16.md`

### 4. 当前结论

- 共整理：
  - `33` 条
- 当前最主要的问题集中在：
  - 空格 / 连字符未统一
  - `fille / varian / easte / sourth` 等拼写问题
  - `bang / tu_b / t_object` 这类临时 token 语义不够稳定
- 当前建议表中已保留：
  - 原写法
  - 建议正式 key
  - 简短原因

### 5. 下一步

1. 由用户审核这份 `BASIS=T` 建议修正表
2. 用户确认后，再批量回写：
   - sprite key 对照表
   - sprite json / png
   - style / pbf 语义 key

## 2026-04-16 全国人工审计对比页

### 1. 本轮目标

- 用户要求两件事：
  - 明确说明接下来如何审计当前这套 `pbf / style / png`
  - 提供一张可直接人工对比 `newpec` 的页面

### 2. 本轮新增页面

- 仓库源码：
  - `src/pbf/navsea-compare-full-audit.html`
- 已部署页面：
  - `/mnt/sda1/www/newpec/navsea-compare-full-audit.html`
- 访问地址：
  - `http://192.168.200.184/newpec/navsea-compare-full-audit.html`

### 3. 页面口径

- 左侧固定：
  - 原始 `style.json`
  - 原始 `newpec` 瓦片
- 右侧固定：
  - `style.navsea-delivery-full.json`
  - `/pbf-delivery-full-20260415`
  - 当前 `newpec/sprite/sprite`
- 页面版本：
  - `full-audit-r1-20260416-1548`

### 4. 本轮新增文档

- 审计口径文档：
  - `tasks/pbf/NavSea_全国_PBF_Style_Sprite_人工审计口径_2026-04-16.md`

### 5. 当前说明

- 本轮没有改动主 `20nm compare` 基线页
- 采用单独新增全国人工审计页的方式，避免影响现有视觉基线
- 当前新页已保留：
  - 双屏联动
  - 点击取数
  - HTML / Style / PBF / Sprite 版本提示

### 6. 下一步

1. 用户在新页面上做人工审计
2. 按具体差异把问题归类到：
   - `PBF`
   - `style`
   - `sprite`
3. 再进入正式的 sprite key 重命名与未使用 png 清理

## 2026-04-16 全国语义版 sprite / style 生成

### 1. 本轮目标

- 在用户确认 `BASIS=T` 建议表后，开始生成一版可直接人工审计的：
  - 语义版 sprite atlas
  - 语义版 style
  - 语义版全国 PBF 目录

### 2. 本轮新增文件

- 生成脚本：
  - `build_semantic_delivery_assets.py`
- 语义 key 对照表：
  - `src/pbf/semantic_sprite_key_map_2026-04-16.json`
- 语义版 style：
  - `src/pbf/style.navsea-delivery-full-semantic.json`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full-semantic.json`

### 3. 本轮新增 sprite 输出

- 输出目录：
  - `/mnt/sda1/www/newpec/sprite-semantic`
- 已生成：
  - `sprite.json`
  - `sprite.png`
  - `sprite@2x.json`
  - `sprite@2x.png`

### 4. 当前 sprite 口径

- 当前语义版 atlas 已只保留“使用中 sprite 图块”的图像打包
- 为了让语义版 style 在旧值 / 新值混用阶段也能正常显示：
  - `sprite-semantic/*.json` 中同时保留：
    - 新语义 key
    - 与其共用同一图块坐标的旧 key alias
- 因此当前阶段：
  - 图像 atlas 已做裁剪
  - key 已可双兼容过渡

### 5. 当前语义版全国 PBF 目录

- 已建立新目录：
  - `/home/wwwroot/pbf-delivery-full-semantic-20260416`
- 当前做法：
  - 先基于 `20260415` 全国 delivery 做整树硬链接复制
  - 再只重写命中旧 sprite key 的候选瓦片
- 候选瓦片量级已确认约：
  - `4370`

### 6. 当前状态说明

- 本轮已完成并可直接使用的部分：
  - 语义版 sprite
  - 语义版 style
  - 全国人工审计 compare 页已切到语义版 style / sprite / PBF 路径
- 本轮尚未在本次交互内完整收口的部分：
  - 全国 `PBF` 的属性级语义 key 全量重写尚未全部跑完
- 因此当前语义版 PBF 目录虽然路径已建立、瓦片已可访问，但其中大部分瓦片暂仍保留原始旧 key 属性值
- 由于语义版 sprite atlas 当前保留了旧 key alias：
  - 页面渲染仍可正常工作
  - 可以先开始人工视觉审计

### 7. 当前 compare 页

- 页面：
  - `src/pbf/navsea-compare-full-audit.html`
  - `/mnt/sda1/www/newpec/navsea-compare-full-audit.html`
- 当前版本：
  - `full-audit-r2-20260416-1504`
- 右侧当前指向：
  - `style.navsea-delivery-full-semantic.json`
  - `/pbf-delivery-full-semantic-20260416`
  - `/newpec/sprite-semantic/sprite`

### 8. 下一步

1. 继续完成全国语义版 PBF 的属性级重写
2. 在重写完成后，抽样验证：
   - `chart_icon_image`
   - `chart_fill_pattern`
   是否已从旧 key 变为新语义 key
3. 再决定是否移除语义 sprite atlas 中的旧 key alias

## 2026-04-16 tide 点位缺失定位

### 1. 现象

- 用户在全国 compare 页指出：
  - 左侧原始版能看到 `tide` 点位
  - 右侧 delivery 缺失

### 2. 本轮定位结果

- 该对象并不来自 `newpec` 主 PBF 的原始 layer 映射
- 原始 `newpec/style.json` 另有一条独立 source：
  - `tide`
  - `https://tile.mapple-on.jp/tide-mvt/{z}/{x}/{y}.pbf?ver=20251001`
- 原始图层：
  - `#d#tide`
  - `source = tide`
  - `source-layer = tide`
  - `icon-image = tidespot-daytime`
- 因此右侧缺失的根因不是：
  - builder 漏接 raw layer
- 而是：
  - `style.navsea-delivery-full*.json` 没有把 `tide` 外部 source 一并挂入

### 3. 本轮修复

- 已在以下 style 中补入：
  - `tide` vector source
  - `tide-spots` symbol layer
- 已修文件：
  - `src/pbf/style.navsea-delivery-full.json`
  - `src/pbf/style.navsea-delivery-full-semantic.json`
- 已同步部署：
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full-semantic.json`

### 4. 当前结论

- 这类点位不应继续追到 `navsea_tile_builder.py` 的 raw layer 接入
- 正确处理方式是：
  - 在 delivery style 中保留原始 `tide-mvt` 外部 source
  - 让右侧 style 与左侧原始版保持同一条潮流点位数据源

## 2026-04-16 sprite key 语义化迁移任务草案

### 1. 本轮背景

- 用户提出希望把当前：
  - `PBF`
  - `sprite.json`
  - sprite 资源引用
  统一改成“有语义的 key”，而不是继续使用：
  - `symbol-daytime-410`
  - `symbol-daytime-301`
  这类编号式命名。
- 当前先不直接改代码，先出可审核的 task 文档。

### 2. 本轮确认的方向

- 迁移目标应当是：
  - `PBF` 输出语义图标 key
  - style 直接消费语义 key
  - `sprite.json` 使用语义 key
- 其中：
  - `sprite.png` 本身不是命名载体
  - 真正承载名字的是 `sprite.json`
  - `sprite.png` 需要做的是按新 key 重新打包索引

### 3. 本轮已完成的资料核对

- 已复核全国候选 style：
  - [`src/pbf/style.navsea-delivery-full.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-full.json)
- 已复核当前全国候选 PBF：
  - `/home/wwwroot/pbf-delivery-full-20260415`
- 已复核线上 sprite 索引：
  - `/mnt/sda1/www/newpec/sprite/sprite@2x.json`
- 已复核 builder 里当前图标派生逻辑：
  - [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py)

### 4. 本轮新增输出

- 已新增 task 草案：
  - [`tasks/pbf/NavSea_Sprite_语义_Key_迁移任务_2026-04-16.md`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_语义_Key_迁移任务_2026-04-16.md)

### 5. 当前草案内容

- 文档中已给出：
  - 第一版迁移目标
  - 命名原则
  - 当前全国候选已用 key 的对照表
  - `pattern` 类资源的第一版对照
  - 高确认度 / 待确认项
- 当前特意把两类内容分开：
  - 已能直接落成语义 key 的对象
  - 仍需保留变体编号尾巴的对象

### 6. 当前下一步

- 先等用户审核：
  - 对照表命名是否认可
  - 哪些 key 需要改名
  - 哪些变体需要先做图样人工核对
- 待用户确认后，再决定是否进入：
  - style / builder / sprite.json 的正式迁移实现

## 2026-04-16 sprite key 使用计数 CSV

### 1. 本轮需求

- 用户要求基于当前线上：
  - `/mnt/sda1/www/newpec/sprite/sprite@2x.json`
  输出一个 CSV，列为：
  - `old_sprite_key`
  - `new_sprite_key`
  - `count`
- 其中要求：
  - 以 `sprite.json` 的 key 为基表
  - 统计当前全国候选 PBF 中实际出现次数
  - `PBF` 中没有用到的图标不填写 `new_sprite_key`

### 2. 本轮统计口径

- 当前使用的 PBF 目录：
  - `/home/wwwroot/pbf-delivery-full-20260415`
- 当前统计方式：
  - 不逐条做 feature 级 decode
  - 直接扫描 `PBF` 原始字节中的 sprite key ASCII 字符串
  - 只对：
    - `sprite@2x.json` 中存在的 key
    做计数
- 该口径适合回答：
  - 哪些 sprite key 当前确实进入了全国候选 PBF
  - 大致进入了多少次

### 3. 本轮新增输出

- 已生成：
  - [`tasks/pbf/NavSea_Sprite_Key_Usage_2026-04-16.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Key_Usage_2026-04-16.csv)

### 4. 当前结果摘要

- `sprite@2x.json` 总 key 数：
  - `476`
- 当前全国候选 PBF 中实际命中的 key 数：
  - `23`
- 当前计数最高的几个 key：
  - `symbol-daytime-428 = 3322`
  - `symbol-daytime-301 = 2830`
  - `symbol-daytime-303 = 1581`
  - `symbol-daytime-405 = 1286`
  - `symbol-daytime-310 = 927`
  - `fill-daytime-428 = 899`
  - `symbol-daytime-320 = 810`

### 5. 当前说明

- 这份 CSV 主要用于帮助用户先看：
  - 哪些旧 sprite key 目前真的在用
  - 哪些 key 值得优先进入语义化迁移
- 当前未在 PBF 中出现的 key：
  - `new_sprite_key` 留空

## 2026-04-16 sprite 审计口径修正

### 1. 本轮发现

- 用户指出：
  - `arc-daytime-04022307`
  这类灯弧资源虽然在上一份 CSV 中是 `0`，但在 style 里能看到相关灯弧资源引用。
- 这说明上一份 CSV 的统计口径只适合回答：
  - `PBF` 中有没有直接出现这个 sprite key
- 但不适合回答：
  - 当前 style 是否真的在使用该资源

### 2. 本轮口径修正

- 新增一份更适合审计和删图判断的联合 CSV：
  - 同时统计 `style` 直接引用次数
  - 和 `PBF` 中出现次数
- 当前使用的 style 基线：
  - [`src/pbf/style.navsea-delivery-full.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-full.json)
- 当前使用的 PBF 基线：
  - `/home/wwwroot/pbf-delivery-full-20260415`
- 当前输出字段：
  - `old_sprite_key`
  - `used_in_style`
  - `used_in_pbf`
  - `usage_note`
  - `new_sprite_key`

### 3. 本轮新增输出

- 已生成：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16.csv)

### 4. 当前结果摘要

- `sprite.json` 总 key 数：
  - `476`
- 当前 style 直接引用到的 key 数：
  - `76`
- 当前 PBF 中出现过的 key 数：
  - `23`
- 当前 style / PBF 任一侧命中的总 key 数：
  - `81`

### 5. 当前验证到的关键结论

- 灯弧资源不是“没用”，而是典型的：
  - `style_only`
- 当前全国候选 style 里实际命中的灯弧 key 包括：
  - `arc-daytime-04027289`
  - `arc-daytime-m1`
  - `arc-daytime-m2`
  - `arc-daytime-m3`
- 而：
  - `arc-daytime-04022307`
  当前只在 `sprite@2x.json` 中存在
  - 目前没有在当前全国候选 style 中命中

### 6. 当前用途

- 这份联合 CSV 更适合服务用户当前三个目标：
  - 审计当前哪些资源真的在用
  - 判断哪些 PNG 图块可以考虑删除
  - 识别哪些仍在使用的 key 需要继续语义化迁移

## 2026-04-16 sprite 审计 CSV 重排与图样标记

### 1. 本轮需求

- 用户要求把联合审计 CSV 重新生成一次：
  - 当前完全没有命中的 key 放到最下面
  - 通过看图识别出的语义 key 需要做标记

### 2. 本轮处理

- 已重写：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16.csv)
- 当前排序规则：
  - 先放 `style` 或 `PBF` 任一侧命中的 key
  - 完全未命中的 `unused_in_current_full` 放到文件尾部
  - 已命中部分再按：
    - `used_in_style + used_in_pbf` 总量降序
    - 同总量下按 key 名排序

### 3. 图样识别标记规则

- 对当前主要依赖 sprite 图样外观推断语义的 key：
  - 在 `new_sprite_key` 后追加：
    - `[img]`
- 当前已这样标记的包括：
  - `symbol-daytime-720 -> anchorage_designated [img]`
  - `symbol-daytime-721 -> restriction_general [img]`
  - `symbol-daytime-724 -> anchoring_prohibited [img]`

### 4. 当前结果说明

- 经过这次重排后：
  - CSV 顶部更适合直接做“当前在用资源”审计
  - CSV 底部更适合直接看“候选可删资源”

## 2026-04-16 sprite 审计 Excel 输出

### 1. 本轮需求

- 用户要求把各个 sprite 图标直接放进 Excel 文件中，便于人工审核。

### 2. 本轮输出

- 已生成：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16.xlsx)

### 3. 当前 Excel 内容

- `summary` sheet：
  - 统计口径说明
  - style / PBF / sprite 基线
- `used` sheet：
  - 当前在 style 或 PBF 中命中的 key
  - 含图标预览
- `unused` sheet：
  - 当前全国候选下完全未命中的 key
  - 含图标预览

### 4. 当前生成结果

- Excel 已嵌入 sprite 预览图：
  - `476` 张
- 当前文件大小约：
  - `2.1M`

### 5. 当前用途

- 这份 Excel 适合直接用于：
  - 看图核语义
  - 审核哪些 key 仍在使用
  - 判断哪些资源可进入删图候选

## 2026-04-16 sprite 审计 Excel 兼容版

### 1. 本轮问题

- 用户反馈原始：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16.xlsx)
  无法打开。

### 2. 本轮确认

- 已核实原始 Excel 并非空壳：
  - 内含 `476` 张嵌入图片
  - 本机 `LibreOffice` 可正常读取与转换
- 初步判断：
  - 更可能是用户侧表格客户端对“大量嵌入图片 + 单工作簿”兼容性较差

### 3. 本轮新增输出

- 已新增兼容版：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16_compat.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16_compat.xlsx)

### 4. 兼容版处理方式

- 缩小预览图尺寸
- 拆成多个 sheet：
  - `used_1`
  - `used_2`
  - `unused_1`
  - `unused_2`
- 保留 `summary` 页说明

### 5. 当前结果

- 原始版大小约：
  - `2.1M`
- 兼容版大小约：
  - `605K`
- 兼容版也已用本机 `LibreOffice` 验证可读

## 2026-04-16 Mapple 手册对位版 sprite 审计

### 1. 本轮输入来源

- 用户提供官方手册页：
  - `https://info.mapple-on.jp/newpecs/manual/1-15_inlink.html`
- 已进一步解析确认：
  - 该页实际加载的是 `guide115_01` 到 `guide115_11` 的 JPG 凡例页
  - 关键符号对位页主要是：
    - `guide115_01`
    - `guide115_02`
    - `guide115_03`
    - `guide115_04`
    - `guide115_07_20260120`
    - `guide115_08`

### 2. 本轮新增输出

- 已生成手册对位版 CSV：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16_manual.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16_manual.csv)
- 已生成手册对位版 Excel：
  - [`tasks/pbf/NavSea_Sprite_Audit_2026-04-16_manual.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_2026-04-16_manual.xlsx)

### 3. 本轮新增字段

- 手册对位版相较原审计表，新增：
  - `manual_label_ja`
  - `basis`
  - `source_page`

含义：

- `manual_label_ja`
  - 来自 Mapple 凡例页的日文名称
- `basis`
  - `manual`
  - `manual?`
  - `style`
- `source_page`
  - 对应凡例页编号

### 4. 本轮关键纠偏

- 按手册口径确认后，当前若干 key 的语义与现有 builder fallback 并不完全一致。
- 当前已先把手册语义写入对位版表，不在本轮直接改代码。
- 代表性条目包括：
  - `symbol-daytime-719 -> 検疫錨地`
  - `symbol-daytime-720 -> 錨泊（指定）地`
  - `symbol-daytime-721 -> 制限区域・航路横断等禁止区域・航泊禁止区域（共通）`
  - `symbol-daytime-724 -> 錨泊禁止区域`
  - `symbol-daytime-428 -> 魚礁`
  - `symbol-daytime-429 -> 魚礁（危険なもの）`

### 5. 当前用途

- 手册对位版更适合：
  - 用官方凡例口径审核 sprite 命名
  - 识别当前 style / builder 中的语义偏差
  - 作为下一步 key 语义化迁移的依据

## 2026-04-16 改用 newpec/style.json 重做 sprite 审计表

### 1. 本轮原因

- 用户指出此前按仓库内生成的 style 做图标预览，结果看起来可能有问题。
- 已进一步确认：
  - `/mnt/sda1/www/newpec/style.json` 声明的 sprite 不是本机 `newpec/sprite/...`
  - 而是官方远端：
    - `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite`

### 2. 本轮调整

- 当前改为直接使用：
  - style 基线：
    - `/mnt/sda1/www/newpec/style.json`
  - sprite 基线：
    - `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite@2x.json`
    - `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite@2x.png`

### 3. 本轮新增输出

- 已生成 CSV：
  - [`tasks/pbf/NavSea_Sprite_Audit_newpec_style_2026-04-16.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_newpec_style_2026-04-16.csv)
- 已生成 Excel：
  - [`tasks/pbf/NavSea_Sprite_Audit_newpec_style_2026-04-16.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_newpec_style_2026-04-16.xlsx)

### 4. 当前结果

- 当前 `newpec/style.json` 直接命中的 sprite key 数：
  - `120`
- 当前未命中的 key 数：
  - `356`
- 新表中的图标预览已统一改为：
  - 与 `newpec/style.json` 声明一致的官方 sprite 图集

### 5. 当前用途

- 这份新表更适合直接回答：
  - `newpec/style.json` 当前到底用了哪些 sprite key
  - 对应图标在官方 sprite 图集中长什么样

## 2026-04-16 newpec style + PBF 双列版 sprite 审计

### 1. 本轮补充原因

- 用户指出上一版：
  - `NavSea_Sprite_Audit_newpec_style_2026-04-16.*`
  只有 `style` 使用列，没有把 `PBF` 使用列一并列出。

### 2. 本轮新增输出

- 已补生成 CSV：
  - [`tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.csv`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.csv)
- 已补生成 Excel：
  - [`tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.xlsx`](/root/sourceserver/pbf/tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.xlsx)

### 3. 当前统计口径

- style 基线：
  - `/mnt/sda1/www/newpec/style.json`
- sprite 基线：
  - `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite`
- PBF 基线：
  - `/home/wwwroot/pbf-delivery-full-20260415`

### 4. 当前结果摘要

- `used_in_newpec_style` 命中的 key 数：
  - `120`
- `used_in_pbf` 命中的 key 数：
  - `23`
- 两侧任一侧命中的 key 数：
  - `120`

### 5. 当前用途

- 这份双列版适合直接回答：
  - 哪些 key 仅 style 在用
  - 哪些 key 同时进了 style 和 PBF
  - 哪些 key 当前完全没有命中

## 2026-04-12 15:51 红点对位测试页

### 1. 背景

- 用户提供了一组 native 点击参数：
  - `gps = 130.12021422800144, 33.564027696216417`
  - `screen_point = 872.12158203125, 265.0388488769531`
  - `camera.center = 130.09748008398487, 33.56207182800527`
  - `camera.zoom = 13.35437870025635`
- 当前目标不是继续改 pickup 逻辑，而是先做一个最小对位页：
  - 在同一套 `Karatsu 20nm final` 图面上
  - 把这个 GPS 点直接画成红点
  - 方便用户亲自点击这个点，观察 web pickup 命中情况

### 2. 本轮新增页面

- 新增文件：
  - `/root/sourceserver/pbf/src/pbf/navsea-click-target-karatsu-20nm.html`
- 页面特性：
  - 使用 `style.navsea-delivery-karatsu-20nm-final.json`
  - 使用 `pbf-delivery-karatsu-20nm-final`
  - 相机固定到用户提供的 native `center/zoom`
  - 目标 GPS 固定绘制为一个红色圆点
  - 页面左上角额外展示：
    - 目标经纬度
    - 相机中心
    - 缩放级别
    - native 屏幕点

### 3. 部署

- 已部署到：
  - `/mnt/sda1/www/newpec/navsea-click-target-karatsu-20nm.html`
- 可访问 URL：
  - `http://192.168.200.184/newpec/navsea-click-target-karatsu-20nm.html`

### 4. 用途说明

- 该页面是“位置对位工具页”，不是 pickup 主测试页
- 主要用途：
  - 先确认 native 给出的 GPS 点在 web 图面上的真实位置
  - 再让用户直接点这个红点，观察是否能稳定命中目标对象
  - 用于后续继续排查：
    - native `queryRenderedFeaturesAtPoint`
    - native `queryRenderedFeaturesInRect`
    - web `queryRenderedFeatures`
    的差异

### 5. 本轮增强

- 已继续增强红点对位页：
  - 点击地图后，页面右侧直接显示三组查询结果
  - 分别为：
    - `Exact Point 命中 fid`
    - `BBox 命中 fid`
    - `Raw 命中 fid`
- 当前每组结果都会输出：
  - 命中数量
  - `fid` 数组
  - 简化后的 feature 摘要
- 同时也会在浏览器 `console.log` 打印同样内容，便于和 native 日志逐条对照

### 6. 当前版本

- 红点对位页当前版本：
  - `click-target-r2-20260412-1558`

## 2026-04-12 16:09 红点对位页切换第二组 native 参数

### 1. 本轮目的

- 用户提供了第二组 native 点击参数，要求继续使用同一个红点对位页做对照
- 本轮没有改 pickup 判定逻辑，只替换测试输入参数

### 2. 本轮更新

- 页面：
  - `/root/sourceserver/pbf/src/pbf/navsea-click-target-karatsu-20nm.html`
- 已切换为以下参数：
  - `gps = 130.11327934763205, 33.55533344042364`
  - `camera.center = 130.11779893907284, 33.55552020187967`
  - `camera.zoom = 15.158083915710451`
  - `screen_point = 447.72021484375, 467.4805908203125`
  - `projected_click_point = 298.4801330566406, 311.6537170410156`

### 3. 页面补充

- 左侧信息面板已补充：
  - `投影屏幕点`
- 这样可以同时对照：
  - native 事件里的 `screen_point`
  - native 相机投影出来的 `projected_click_point`

### 4. 当前版本

- 红点对位页当前版本：
  - `click-target-r3-20260412-1608`

## 2026-04-11 建筑物/地标点 pickup 主入口补全

### 1. 本轮问题

- 用户继续指出：
  - 当前点击逻辑还是明显偏海底
  - 对建筑物的注意不够

### 2. 本轮根因

- 当前规则虽然已经把：
  - `land-area`
  - `land-structures-area`
  等面/线层拉回正式 pickup
- 但真正用于可见建筑/地标点表达的：
  - `landmark-points`
  - `landmark-point-fallback`
  之前没有进入 `primary`
- 这会导致：
  - 用户眼前看见了建筑/地标点
  - 但 pickup 主入口没有优先命中它
  - 页面仍容易滑回海底解释

### 3. 本轮修复

- 已更新：
  - [`src/pbf/navsea-pickup-rules.v1.json`](/root/sourceserver/pbf/src/pbf/navsea-pickup-rules.v1.json)
- 具体补入：
  - `landmark-points`
  - `landmark-point-fallback`
  到 `render_layer_groups.primary`
- 并把：
  - `coast-structures-area`
  也正式补入 `render_layer_groups.area`

### 4. 当前意义

- 现在可见建筑/地标点不再只是：
  - style 上画出来
  - 但 pickup 不关注
- 而是已经进入正式主点击入口
- 页面在建筑物附近点击时，应更容易优先返回：
  - 建筑物 / 地标 / 防波堤 / 栈桥
  而不是海底兜底

### 5. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-rules.v1.json`
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`

## 2026-04-11 当前 pickup 测试页状态确认

### 1. 当前用户反馈

- 用户确认：
  - `现在看起来很好`

### 2. 当前已达到的状态

- 当前 `pickup test` 页已经基本收口到用户可接受状态
- 页面当前能较稳定地区分：
  - 海面上/露出水面的具体对象
  - 海底信息解释
- 对用户可见的：
  - 航标
  - 灯标
  - 渔具/鱼礁
  - 危险物
  - 陆地
  - 建筑物
  - 地标点
  - 防波堤/栈桥等岸上或岸边结构
  已经比前几轮更容易返回正确对象，而不是错误滑入海底兜底

### 3. 当前海底解释口径

- 当前海底解释已具备：
  - `当前水深`
  - `物体名（有的话）`
  - `简单水底情况`
  - `判断理由`
- 并已统一为：
  - `100 米` 近邻证据口径
- 当前文案也已收敛到偏普通钓鱼人可理解的表达，不再直接把专业术语甩给终端用户

### 4. 当前可作为后续实现基线

- 当前页面：
  - `http://192.168.200.184/newpec/navsea-pickup-test-karatsu-20nm.html`
  已可作为后续前端实现 pickup 行为的测试基线
- 当前规则字典与页面逻辑可继续作为：
  - RN 前端落地参考
  - 后续解释器抽离的基础版本

## 2026-04-11 新增 React + MapLibre 迁移用 Codex 指令文档

### 1. 本轮用户需求

- 用户希望把当前 `pickup` 的“当前点击解读”逻辑迁移到：
  - `React + MapLibre (NavSea)`
- 并要求：
  - 提供一份中文 `md`
  - 这份文档要能直接作为 `Codex` 执行指令使用

### 2. 本轮新增文档

- 已新增：
  - [`Codex_指令_NavSea_Pickup_当前点击解读_迁移到_React_MapLibre.md`](/root/sourceserver/pbf/Codex_指令_NavSea_Pickup_当前点击解读_迁移到_React_MapLibre.md)

### 3. 当前文档内容

- 这份指令文档已明确写清：
  - 目标行为
  - 当前唯一参考来源文件
  - 主键与图层口径
  - `100 米` 附近口径
  - `exact + bbox` 双阶段查询
  - 当前点击解读的两种模式
    - `海面/露出物`
    - `海底信息`
  - 必须保留的 `判断理由`
  - 不要做的事
  - 产出要求
  - 验收标准

### 4. 当前意义

- 现在不仅已有：
  - pickup test 页
  - pickup 规则字典
  - pickup 解释器
- 也已经补上一份：
  - 可直接交给前端或另一个 Codex 执行的中文任务书

## 2026-04-11 新增可直接复制给 Codex 的纯 Prompt 版

### 1. 本轮用户需求

- 用户希望在已有详细 `md` 指令之外，再补一份：
  - 可以直接复制到聊天框
  - 更短
  - 更像真正执行口令
  的版本

### 2. 本轮新增文档

- 已新增：
  - [`Codex_Prompt_版_NavSea_Pickup_当前点击解读_迁移.md`](/root/sourceserver/pbf/Codex_Prompt_版_NavSea_Pickup_当前点击解读_迁移.md)

### 3. 当前文档作用

- 这份文档比详细任务书更短
- 但仍保留了关键约束：
  - 必须阅读的参考文件
  - `海面/露出物` 与 `海底信息` 两种模式
  - `100 米` 附近口径
  - `exact + bbox` 双阶段查询
  - `判断理由`
  - 建筑物/地标不能被海底解释吞掉
  - 验收标准

## 2026-04-11 pickup test 页补入 MapLibre 调用参数 console.log

### 1. 本轮用户要求

- 用户明确要求：
  - 在 web 的 `console.log` 里
  - 把调用 MapLibre 的函数参数都显示出来
- 并补充说明：
  - 这里就是要改 `pickup test` 的 html

### 2. 本轮实现

- 已在：
  - [`src/pbf/navsea-pickup-test-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-pickup-test-karatsu-20nm.html)
  中新增：
  - `logMapLibreCall(method, payload)`

### 3. 当前已记录的 MapLibre 调用

- 当前页面会在控制台输出这些调用参数：
  - `new maplibregl.Map`
  - `map.addSource`
  - `map.addLayer`
  - `source.setData`
  - `map.project`
  - `map.queryRenderedFeatures`
  - `map.addControl`
  - `map.jumpTo`
  - `map.setStyle`
  - `map.easeTo`

### 4. 当前作用

- 现在浏览器控制台里可以直接看到：
  - 每次点击到底传给了哪些 `queryRenderedFeatures` 参数
  - `100m` 是怎么换算成屏幕半径的
  - `style` 重载、地图初始化、回到默认视角时具体传了什么
- 便于前端后续把同样的调用迁移到：
  - `React + MapLibre`

### 5. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`
- 页面版本已更新为：
  - `pickup-test-r6-20260411-1216`
- 页面版本已更新为：
  - `pickup-test-r4-20260411-1105`

## 2026-04-11 陆地与建筑物点击误落入海底解释修复

### 1. 本轮问题

- 用户反馈：
  - 陆地点击错了
  - 建筑物点击也错了
- 实际现象是：
  - 用户点击了清晰可见的陆地或陆上构造物
  - 页面却返回了：
    - `海底信息`
    - 或海底地形解释兜底

### 2. 本轮根因

- 当前规则字典里：
  - `land-area`
  - `land-structures-area`
  仍然被放在 `ignore`
- 导致这些可见对象没有进入正式 pickup 白名单
- 页面对象未命中后，就错误掉入：
  - `depth context`
  - `terrain interpretation`
  的兜底路径

### 3. 本轮修复

- 已更新：
  - [`src/pbf/navsea-pickup-rules.v1.json`](/root/sourceserver/pbf/src/pbf/navsea-pickup-rules.v1.json)
- 具体调整为：
  - 把
    - `land-area`
    - `land-structures-area`
    - `land-structures-line`
    - `coast-structures-line`
    从 `ignore` 调整为正式可点 `area`
- 并补了显示名覆盖：
  - `land_area -> 陆地`
  - `building -> 建筑物`
  - `breakwater -> 防波堤`
  - `floating_facility_pier -> 浮动设施/栈桥`

### 4. 同步补强

- 已更新 pickup test 页逻辑：
  - 新增 `shouldPreferBBoxPrimary(exactPrimary, bboxPrimary)`
- 当前规则变为：
  - 对危险区这类 broad area，仍允许 nearby primary 抢回
  - 但对：
    - `land_area`
    - `onshore_structure_area`
    - `onshore_structure_line`
    - `bridge_structure`
    这类可见陆地/构造物，不再被 bbox 里的 nearby primary 轻易抢走

### 5. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/domain/navsea-pickup-rules.v1.json`
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`

## 2026-04-11 pickup 面板新增“判断理由”

### 1. 本轮用户要求

- 用户指出：
  - 同样一类图面，有时会显示“像一道坎”
  - 有时会显示“变化但不特别强”
- 希望页面直接显示：
  - 这次判断到底依据了什么

### 2. 本轮实现

- 已在：
  - [`src/pbf/navsea-pickup-test-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-pickup-test-karatsu-20nm.html)
  的“当前点击解读” panel 中新增：
  - `判断理由`
- 并新增：
  - `buildDecisionReasonText(terrainResult)`

### 3. 当前展示内容

- 现在海底信息解释会额外显示：
  - `100米内深度大约 Xm 到 Ym，跨度 Zm`
  - `附近共有 N 条等深线，海底辅助线 M 条`
  - `附近结构`
  - `附近底质`
- 对海面/露出物点击，也会明确显示：
  - `当前点击已直接命中可见对象，所以不再按海底规则兜底解释。`

### 4. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`
- 页面版本已更新为：
  - `pickup-test-r5-20260411-1126`

## 2026-04-11 海底判断证据口径统一

### 1. 本轮问题

- 用户通过截图指出一个关键矛盾：
  - `当前水深` 显示为 `20m`
  - 但 `判断理由` 却写成：
    - `100米内深度大约 25m 到 25m，跨度 0m`
  - 同时还给出了：
    - `这里水底看起来比较平`
- 这说明当前页面里：
  - `当前水深`
  - `海底形状判断`
  还不是完全使用同一套证据

### 2. 本轮根因

- `当前水深` 原先使用的是一套较宽松的可见深度 query
- `地形判断` 使用的是另一套 `100m` 近邻样本
- 再加上“平缓”规则之前会被少量 `bathymetry-support` 误触发
- 于是就会出现：
  - 水深看起来是 20m
  - 但理由统计只剩 25m 辅助线样本
  - 最终误说成“比较平”

### 3. 本轮修复

- 已把 `buildDepthContext(event)` 改为同样使用：
  - `NEARBY_DISTANCE_M = 100`
- 当前 `当前水深` 和 `附近/地形判断` 已统一到同一个 `100m` 口径
- 同时收紧了“平缓”判定：
  - 只有真正存在足够的等深线/标签证据时，才允许说：
    - `这里水底看起来比较平`
- 如果只是少量 `bathymetry-support` 被扫到，当前会改成：
  - `当前位置只有少量海底辅助线证据，暂不判断明显坎沟。`

### 4. 当前新增说明

- `terrain_interpretation.contour_density` 里已补入：
  - `contour_evidence`
- `判断理由` 里现在会优先显示：
  - `当前水深取最近可见深度，约 Xm`
  - `100米内样本深度大约 Ym 到 Zm，跨度 Wm`
  - `附近共有 N 条等深线，深度标签 K 个，海底辅助线 M 条`

### 5. 本轮部署

- 已重新部署：
  - `/mnt/sda1/www/newpec/navsea-pickup-test-karatsu-20nm.html`