pbf/STEP_RECORD.md

项目步骤记录

最后更新：2026-04-18 15:03 仓库：/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
• 已新增全国 AOI 截图 + diff 审计脚本：
  • navsea_full_aoi_visual_audit.py
• 已新增 AOI 配置：
  • tasks/pbf/NavSea_Full_AOI_Visual_Audit_2026-04-18.json

2. 全国人工审计页调整

• 已把全国人工审计页改为支持：
  • ?variant=full
  • ?variant=semantic
• 已同步部署：
  • 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
  • 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
• 用途：
  • 按全国固定 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
  • 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
  • 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-18 全国 full 重建进行中：分片重建 + staging 截图审计

1. 本轮页面与脚本调整

• 已把全国人工审计页继续扩成支持右侧 deliveryTileUrl 覆盖：
  • src/pbf/navsea-compare-full-audit.html
• 当前页面版本已提升到：
  • full-audit-r3-20260418-1546
• 已部署到：
  • /mnt/sda1/www/newpec/navsea-compare-full-audit.html
• 已把全国 AOI 截图审计脚本扩成支持只跑指定 variant：
  • navsea_full_aoi_visual_audit.py
  • 新增参数：
    • --variant full
    • --variant semantic

2. 全国 full 重建策略调整

• 因当前工作树中的 navsea_tile_builder.py 还混有语义版 sprite 迁移试验改动
• 本轮全国 full 重建没有直接用工作树文件
• 而是固定使用 HEAD 版本临时 builder：
  • /tmp/navsea_tile_builder_head_20260418.py
• 重建方式改为：
  • 以当前全国 full 目录为 reference footprint
  • 对 z0_8 / z9_10 / z11 / z12 分片重建
• 当前分片目录：
  • /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/z0_8
  • /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/z9_10
  • /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/z11
  • /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/z12

3. 并发策略修正

• 机器实际仅 4 核
• 本轮中途确认：
  • 之前直接对多分片同时开 24 / 96 worker 会造成严重过度并发
• 已改成当前更稳定的组合：
  • z12: workers=96
  • z11: workers=4
  • z9_10: workers=2
  • z0_8: workers=1
• 当前目标不是一次把机器打满
• 而是让 z12 热点风险先落盘，同时补齐其余 zoom

4. z12 staging 目录

• 为了在全国 rebuild 尚未全量完成前先做热点截图闭环
• 已创建 staging 根目录：
  • /home/wwwroot/pbf-delivery-full-20260418-staging-z12
• 方式：
  • 先复制当前 full
  • 再持续用已重建的 z12 新 tile 覆盖
• 用途：
  • 让右侧截图优先加载新 z12
  • 未重建到的地方仍由旧 full 兜底
  • 避免人工审计页因为“未生成到”而出现伪空白

5. 当前 staging 截图审计结果

• 冲绳 10nm z12 staging 复跑：
  • report/full_rebuild_staging_okinawa_z12_2026-04-18/full_aoi_visual_audit.md
  • report/full_rebuild_staging_okinawa_z12_r2_2026-04-18/full_aoi_visual_audit.md
  • 当前 changed_ratio = 0.786184
• 博多 / 唐津 z12 staging 复跑：
  • report/full_rebuild_staging_hakata_karatsu_z12_2026-04-18/full_aoi_visual_audit.md
  • 结果：
    • karatsu_5nm_full_z12 = 0.757473
    • hakata_10nm_full_z12 = 0.529882

6. 当前视觉判断

• 新 rebuild z12 覆盖后：
  • 唐津右图中此前那类“岛屿错位 / 大片空白”现象未再出现
• 当前 remaining diff 更像：
  • delivery full 与原始 newpec 的底图 / 道路 / 色彩 / 文本表达差异
• 也就是说本轮已经进一步确认：
  • “坏片几何问题”
  • 与
  • “整体样式表达差异” 应分开审计

7. 当前重建进度快照

• 截止本记录更新时：
  • z0_8 = 45
  • z9_10 = 1212
  • z11 = 2240
  • z12 = 16261
• 目标参考总量：
  • z0_8 = 344
  • z9_10 = 3969
  • z11 = 12279
  • z12 = 48556

8. 下一步

1. 继续把全国 full 四个分片全部跑完并合并成：
   • /home/wwwroot/pbf-delivery-full-20260418-rebuild
2. 对最终 rebuild 根目录跑：
   • extent / shift 审计
   • geometry / native 风险审计
3. 再用最终 rebuild 根目录做全国固定 AOI 的正式截图对比审计
4. 完成后再更新最终结论与 commit

2026-04-18 全国高 extent 错重编码根因钉实

1. 本轮新结论

• 当前全国 full / semantic 中反复出现的：
  • 岛礁附近整块空白
  • 海底等深线 / 陆域 / 海岸线整片缺失
• 根因不是 style 改图标本身
• 当前已用数值签名确认：
  • 是高 extent tile 在某条重写链里被按 4096 口径重编码

2. 关键证据

• 代表 source tile 正常 overflow：
  • 20480
• 对应生产坏 tile overflow：
  • 1064960
• 并且已通过复现实验确认：
  • 把 extent = 1048576 tile 重编码时故意写成 4096
  • 可稳定复现出同样的 1064960 错移签名

3. 本轮新增守卫与审计

• 已新增重编码守卫：
  • navsea_tile_reencode_guard.py
• 已新增错移根因审计脚本：
  • navsea_extent_shift_audit.py
• 已补充根因报告：
  • report/full_extent_shift_root_cause_2026-04-18.md

4. 本轮加固

• 已修改：
  • build_semantic_delivery_assets.py
• 当前语义版重写链要求：
  • decode 时保存原 layer extent
  • encode 时按原 extent 写回
  • 写完后立即做几何守卫校验
• 这样后续凡是“改图标 / 改属性”触发的语义版 tile 重写，
  • 不再允许静默把高 extent tile 写坏

5. 热点修前备份审计结果

• 对修前热点 full 备份审计：
  • 154 张里 42 张命中“高 extent 被按 4096 重编码”的签名
• 对修前热点 semantic 备份审计：
  • 154 张里 43 张命中同类签名
• 审计文件：
  • hotspot_backup_full_shift_audit_2026-04-18.json
  • hotspot_backup_semantic_shift_audit_2026-04-18.json

6. 当前下一步

1. 把当前热点修复扩大为：
   • 全国 full
   • 全国 semantic 的整树安全重建
2. 重建前后都跑：
   • navsea_extent_shift_audit.py
3. 把全国现网目录切换到通过守卫校验的新产物

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 之前对命中替换的瓦片做了：
  • 解码
  • 改属性
  • 再编码
• 若重编码时不显式带回原 layer extent
  • 会把高 extent 瓦片直接写坏

4. 本轮代码修正

• 已确认 build_semantic_delivery_assets.py 当前重写语义版瓦片时会：
  • 保留 feature id
  • 保留各 layer 原始 extent
• 已新增：
  • 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 中把：
  • 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
  • src/pbf/style.navsea-delivery-karatsu-20nm-final.json
  • 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
  • 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
  • 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 同步到 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 中继续修正 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 后，已确认今天几类错位的共同根因是：
  • 之前仍在用“归一语义字段优先”的方式补样式
  • 但原始 at 图层实际是“旧字段直驱”
• 本轮重新钉实的规则：
  • p航行危険障害物 / p投錨注意障害物：按 分類番号
  • p錨泊地等：按 分類番号
  • p施設・境界線等 点要素：按 分類番号
  • p航路標識群 主图标：按 表示用番号
  • p航路標識群フレア：按 形状分類番号
  • p陸上構造物：按 分類番号 直接拼 symbol-daytime-*

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

• 已修改 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：
  • FINAL_RELEASE_PROPERTY_ALLOWLIST 新增 shape_class_code
  • --release-minimal 口径现在也会保留 shape_class_code
• 已修改 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

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

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

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 从直接写死中文 label 的结构，调整为：
  • label_key
  • description_key
  • i18n
• 当前 key 命名已统一成：
  • pbf.group.xxx
  • pbf.preset.xxx
• 这样前端可以：
  • 先直接读同文件内的 i18n
  • 后续再平滑迁移到统一翻译系统

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

• 已继续给 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
• src/pbf/style.navsea-delivery-karatsu-20nm-final.json
• 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

2. 本轮生成方式

• 以 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 的瓦片地址改为：
  • 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

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 中新增：
  • 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 中新增：
  • 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 中新增：
  • 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
• 已复核当前全国候选 PBF：
  • /home/wwwroot/pbf-delivery-full-20260415
• 已复核线上 sprite 索引：
  • /mnt/sda1/www/newpec/sprite/sprite@2x.json
• 已复核 builder 里当前图标派生逻辑：
  • navsea_tile_builder.py

4. 本轮新增输出

• 已新增 task 草案：
  • 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

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
• 当前使用的 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

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
• 当前排序规则：
  • 先放 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

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 无法打开。

2. 本轮确认

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

3. 本轮新增输出

• 已新增兼容版：
  • 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
• 已生成手册对位版 Excel：
  • 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
• 已生成 Excel：
  • 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
• 已补生成 Excel：
  • 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
• 具体补入：
  • 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

3. 当前文档内容

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

4. 当前意义

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

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

1. 本轮用户需求

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

2. 本轮新增文档

• 已新增：
  • 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 中新增：
  • 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
• 具体调整为：
  • 把
    • 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 的“当前点击解读” 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