From bc3155243740cc4c38a55c4d2ce32ad97481e380 Mon Sep 17 00:00:00 2001 From: OpenAI Codex Date: Sat, 18 Apr 2026 21:13:39 +0800 Subject: [PATCH] =?UTF-8?q?=E5=8E=8B=E7=BC=A9=E6=AD=A5=E9=AA=A4=E8=AE=B0?= =?UTF-8?q?=E5=BD=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- STEP_RECORD.md | 3945 ++---------------------------------------------- 1 file changed, 104 insertions(+), 3841 deletions(-) diff --git a/STEP_RECORD.md b/STEP_RECORD.md index e1a677f..c40ee1b 100644 --- a/STEP_RECORD.md +++ b/STEP_RECORD.md @@ -1,3881 +1,144 @@ # 项目步骤记录 -最后更新：`2026-04-18 15:03` +最后更新：`2026-04-18` 仓库：`/root/sourceserver/pbf` 远端：`ssh://git@nas:2222/tei/pbf.git` -## 文档规则 +## 保留原则 -- `STEP_RECORD.md` 必须使用中文 -- 后续新增输出文档必须使用中文 -- 后续新增审计报告必须使用中文 +- 只保留最近 3 天里真正会反复回看的内容 +- 重点保留三类信息： + - pickup 相关 + - 图标改进相关 + - 所有审计的方法 +- 详细过程、反复试跑、临时中间值尽量不写，统一指向报告或脚本 ## 当前固定基线 -唯一固定使用的视觉审计页面： +- 视觉人工审计页： + - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` +- 全国 full/semantic 审计页： + - `http://192.168.200.184/newpec/navsea-compare-full-audit.html` -- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html` +## 最近 3 天摘要 -当前页面版本： +### 2026-04-16 图标改进与语义迁移 -- `HTML: compare-r19-20260402-1203` -- `Style: karatsu-final-style-r15-20260402-1203` -- `PBF: karatsu-final-pbf-20nm-20260402-1156-fullrefresh1` +- 完成了新旧 sprite / 图标键的梳理与迁移准备 +- 形成了语义版图标映射和审计材料： + - `src/pbf/semantic_sprite_key_map_2026-04-16.json` + - `src/pbf/style.navsea-delivery-full-semantic.json` + - `tasks/pbf/NavSea_Sprite_Audit_2026-04-16.*` + - `tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.*` +- 相关目标： + - 让 full / semantic 的图标来源、命名和可审计性对齐 + - 方便后续对比新旧 style 时追查具体 icon 差异 -## 2026-04-18 全国 full / semantic 逻辑审计与 AOI 图像审计启动 +### 2026-04-17 pickup 相关 -### 1. 本轮新增入口 +- 补了 pickup 解释链与点击定位链路： + - `src/pbf/navsea-pickup-interpreter.ts` + - `src/pbf/navsea-pickup-interpreter.js` + - `src/pbf/navsea-pickup-rules.v1.json` + - `src/pbf/navsea-click-target-karatsu-20nm.html` + - `src/pbf/navsea-pickup-test-karatsu-20nm.html` +- 目标： + - 让当前点选对象的解释、迁移、回放更稳定 + - 方便把 pickup 规则直接纳入人工审计页 -- 已新增全国几何 / 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) +### 2026-04-18 全国审计与重建 -### 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： +- 建了全国 full / semantic 的几何、extent、native 风险审计 +- 建了全国固定 AOI 的截图对比审计 +- 把全国人工审计页改成可切换 `variant=full / semantic` +- 支持右侧 `deliveryTileUrl` 覆盖，便于直接拿 rebuild 产物做对比 +- 已确认并修掉两类问题： + - `extent=4096` 的错退片 + - 旧坏 tile 的几何坐标漂移 +- 已做 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` +### 1. 物体保全审计 -### 7. 当前判断 +- 脚本： + - `navsea_object_preservation_audit.py` +- 用法要点： + - 优先看对象是否被保留、合并、丢失 + - delivery 侧尽量用可追溯字段做比对 +- 经验基线： + - `Karatsu 10nm` + - `--fid-key 'thisMyWorld@2026'` + - `--match-on-fid-only` -- 这轮已经确认并修掉的是： - - 全国 `z12 extent` 错片问题 -- 这轮尚未收口的是： - - 全国 `full / semantic` 与原始 `newpec` 的视觉等价性 -- 且当前视觉差异更像： - - `full / semantic` 共用的主线 style / PBF 问题 - - 不只是语义版单独引入的回退 +### 2. render 审计 -### 8. 下一步 +- 脚本： + - `navsea_render_audit.py` +- 作用： + - 看 delivery 与 source 的渲染结果是否一致 + - 先排除对象被错误合并/丢失，再看视觉 -1. 继续按当前 AOI diff 排序，从： - - `唐津 5nm z12` - - `冲绳 10nm z12` - 开始逐张定位具体 layer / 对象组差异 -2. 优先把： - - `full` 和 `semantic` 同时异常的主线问题 - 从语义版专项问题中剥离出来 -3. 每修一类问题后，直接复跑同一组 AOI 截图，直到 diff 明显收敛 +### 3. AOI 截图对比审计 -## 2026-04-18 全国热点 AOI 旧坏 tile 重建修复 +- 脚本： + - `navsea_full_aoi_visual_audit.py` +- 页面： + - `src/pbf/navsea-compare-full-audit.html` +- 方法： + - 左右截图 + - 取固定 AOI + - 计算图像 diff + - 重点看 `zoom 10 / 12` -### 1. 这轮补充确认 +### 4. extent / native 风险审计 -- 用户指出唐津热点截图右侧仍有明显大片空白 -- 继续下钻后确认： - - 上一轮修掉的只是 `extent = 4096` 错退片 - - 但当前全国 `full / semantic` 热点里还有另一类更深的问题： - - 几何坐标本身被旧构建产物写坏 +- 脚本： + - `navsea_geometry_native_audit.py` + - `navsea_extent_shift_audit.py` + - `navsea_tile_reencode_guard.py` +- 目的： + - 先抓 `extent=1048576` 相关回退、错重编码、几何越界 + - 再把视觉差异与真正的几何风险分开 -### 2. 已定位到的根因 +### 5. 热点重建审计 -- 在问题 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-18 全国 full 重建进行中：分片重建 + staging 截图审计 - -### 1. 本轮页面与脚本调整 - -- 已把全国人工审计页继续扩成支持右侧 `deliveryTileUrl` 覆盖： - - [`src/pbf/navsea-compare-full-audit.html`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/navsea_full_aoi_visual_audit.py) - - 新增参数： - - `--variant full` - - `--variant semantic` - -### 2. 全国 full 重建策略调整 - -- 因当前工作树中的 [`navsea_tile_builder.py`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/navsea_tile_reencode_guard.py) -- 已新增错移根因审计脚本： - - [`navsea_extent_shift_audit.py`](/root/sourceserver/pbf/navsea_extent_shift_audit.py) -- 已补充根因报告： - - [`report/full_extent_shift_root_cause_2026-04-18.md`](/root/sourceserver/pbf/report/full_extent_shift_root_cause_2026-04-18.md) - -### 4. 本轮加固 - -- 已修改： - - [`build_semantic_delivery_assets.py`](/root/sourceserver/pbf/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`](/root/sourceserver/pbf/report/hotspot_backup_full_shift_audit_2026-04-18.json) - - [`hotspot_backup_semantic_shift_audit_2026-04-18.json`](/root/sourceserver/pbf/report/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`](/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` +- 脚本： + - `navsea_rebuild_hotspot_tiles.py` +- 目的： + - 对固定 AOI 热点先重建 full，再刷新 semantic + - 用来确认坏 tile 是历史产物还是当前 builder 问题 ## 当前结论 -- 当前主视觉问题不再优先怀疑 compare HTML 切错。 -- 当前主问题分成两类： - - `style` 过滤条件写错或过宽 - - 线上仍在使用较早生成的 `20nm final` 瓦片，部分关键对象没有 `class_code / display_code` +- `full / semantic` 的 `z12 extent` 错退问题已修正 +- 旧坏 tile 的几何漂移已定位并重建 +- 当前 AOI 高 diff 主要是 full / semantic 与原始 `newpec` 的整体表达差异 +- 视觉审计继续优先看： + - 图标是否对 + - pickup 是否对 + - AOI 截图是否仍有几何级异常 -## 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` +- pickup 相关文件优先看： + - `src/pbf/navsea-pickup-interpreter.ts` + - `src/pbf/navsea-pickup-rules.v1.json` + - `src/pbf/navsea-click-target-karatsu-20nm.html` +- 图标相关文件优先看： - `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` + - `tasks/pbf/NavSea_Sprite_Audit_2026-04-16.*` +- 审计相关文件优先看： + - `navsea_object_preservation_audit.py` + - `navsea_render_audit.py` + - `navsea_geometry_native_audit.py` + - `navsea_extent_shift_audit.py` + - `navsea_full_aoi_visual_audit.py` + - `navsea_rebuild_hotspot_tiles.py` -### 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`