1134 lines
37 KiB
Markdown
1134 lines
37 KiB
Markdown
# PBF Step Record
|
||
|
||
Last Updated: 2026-03-31
|
||
Repo: `/root/sourceserver/pbf`
|
||
Remote: `ssh://git@nas:2222/tei/pbf.git`
|
||
|
||
## Current Checkpoint
|
||
|
||
当前已经完成：
|
||
|
||
- Git 远端已切换到 `nas`
|
||
- 已补交接文档：
|
||
- [`PROJECT_HANDOFF_2026-03-31.md`](/root/sourceserver/pbf/PROJECT_HANDOFF_2026-03-31.md)
|
||
- [`GIT_REMOTE_SWITCH_TO_NAS_2026-03-31.md`](/root/sourceserver/pbf/GIT_REMOTE_SWITCH_TO_NAS_2026-03-31.md)
|
||
- 已补项目协作约定文件：
|
||
- [`AGENTS.md`](/root/sourceserver/pbf/AGENTS.md)
|
||
- [`.codex/README.md`](/root/sourceserver/pbf/.codex/README.md)
|
||
- [`.codex/SESSION_START.md`](/root/sourceserver/pbf/.codex/SESSION_START.md)
|
||
- [`.codex/RESUME_PROMPT.md`](/root/sourceserver/pbf/.codex/RESUME_PROMPT.md)
|
||
- 已完成一次新的 delivery 审计，并确认哪条审计线可用
|
||
- 已把 `Karatsu 20nm` 的最新展示页和左右对比页切到更贴近旧视觉的 compare style
|
||
- 已确认 `Karatsu 20nm` 当前“和旧版差很大”的问题，既有 style 原因，也有 delivery 数据覆盖范围与旧版上下文不一致的原因
|
||
- 已确认 `domain-compatible` 线上“最接近旧版”的那份 style，与仓库当前同名文件并不一致
|
||
- 已正式确定：下面开展工作的视觉复原基准线，统一使用 `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
- 用户于本轮再次明确重定向：下一步视觉复原重新以 `/home/wwwroot/pbf-delivery-karatsu-20nm` 为目标 PBF，并继续结合 render audit 推进
|
||
|
||
## Fixed Compare Baseline
|
||
|
||
从现在开始，下面开展工作的固定比较基线是：
|
||
|
||
- 页面：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
- 目标 PBF：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- `http://192.168.200.184/pbf-delivery-karatsu-20nm/{z}/{x}/{y}.pbf`
|
||
|
||
这条线的定义是：
|
||
|
||
- 后续视觉复原统一围绕 `20nm delivery` 继续推进
|
||
- render audit 的粗审排差，也统一以这条线配合当前对比页来使用
|
||
|
||
工作规则：
|
||
|
||
- 不再新增新的 compare 页面
|
||
- 后续视觉比较统一只看上面这一张固定页面
|
||
- 对比页必须保持左右联动和点击拾取功能可用
|
||
- 对比页每次可见修改都必须 bump 版本号，并显示在“重新加载”按钮附近
|
||
- 当前固定对比页版本号：
|
||
- `20nm-r7-20260331-2044`
|
||
- 这个版本号同时作为 style / tile reload 的 cache-busting 基准
|
||
|
||
## Detail PBF JP Field Inventory
|
||
|
||
已对 `pbf-domain-karatsu-10nm/detail` 全量 47 个瓦片做扫描。
|
||
|
||
结论：
|
||
|
||
- `detail` 包里现在仍然有日文字段
|
||
- 不只是属性值里有日文，属性键名里也还有日文
|
||
- 此外还有一批“标准英文键名，但值仍是日文”的追踪/语义字段
|
||
|
||
当前确认的“日文属性键名”如下：
|
||
|
||
- `bathymetry_line`
|
||
- `水深値(m)`
|
||
- `facility_boundary_area`
|
||
- `分類番号`
|
||
- `facility_boundary_outline`
|
||
- `分類番号`
|
||
- `facility_boundary_point`
|
||
- `Sガイドページ`
|
||
- `分類番号`
|
||
- `名称`
|
||
- `place_label_land`
|
||
- `分類番号`
|
||
- `日本語地名`
|
||
- `縮尺選択コード`
|
||
- `英文字地名`
|
||
- `表示重要度`
|
||
- `place_label_sea`
|
||
- `分類番号`
|
||
- `日本語地名`
|
||
- `縮尺選択コード`
|
||
- `英文字地名`
|
||
- `表示重要度`
|
||
- `seabed_line`
|
||
- `分類番号`
|
||
- `seabed_text_point`
|
||
- `分類番号`
|
||
- `名称`
|
||
- `表示位置`
|
||
|
||
另外，以下英文键名目前也仍大量承载日文值：
|
||
|
||
- `source_layer_jp`
|
||
- `canonical_object_type`
|
||
- `render_layer`
|
||
- `semantic_key`
|
||
- `detection_key`
|
||
- `at`
|
||
- `chart_label_text`
|
||
|
||
这说明后续“去掉 PBF 里的日文字段”不能只删日文键名，还要区分：
|
||
|
||
- 纯追踪字段是否保留
|
||
- 样式当前真正依赖的是哪些日文字段
|
||
- 哪些日文值需要先有标准字段映射后才能安全移除
|
||
|
||
## Latest PBF Batch Discovery
|
||
|
||
按 `/home/wwwroot` 目录修改时间梳理，当前机器上几组关键 PBF 的时间顺序是：
|
||
|
||
- `2026-03-25 17:57:29 +0800`
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- 文件数：`154`
|
||
- `2026-03-25 11:05:38 +0800`
|
||
- `/home/wwwroot/pbf-delivery-kyushu-reencoded`
|
||
- 文件数：`7617`
|
||
- `2026-03-25 09:15:01 +0800`
|
||
- `/home/wwwroot/pbf-delivery-karatsu-10nm`
|
||
- 文件数：`59`
|
||
- `2026-03-18 10:48:30 +0800`
|
||
- `/home/wwwroot/pbf-domain-karatsu-10nm/safety`
|
||
- 文件数：`59`
|
||
- `2026-03-18 10:48:35 +0800`
|
||
- `/home/wwwroot/pbf-domain-karatsu-10nm/detail`
|
||
- 文件数：`47`
|
||
|
||
当前判断：
|
||
|
||
- 如果按“这台机器上最后做出来的一批唐津相关 PBF”来理解，最像的是：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- 如果按“当前固定 compare 基线正在使用的 PBF”来理解，则是：
|
||
- `/home/wwwroot/pbf-domain-karatsu-10nm/safety`
|
||
- `/home/wwwroot/pbf-domain-karatsu-10nm/detail`
|
||
|
||
## 20nm Delivery Current Working Baseline
|
||
|
||
用户本轮已明确：
|
||
|
||
- 下一步视觉复原，先按：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- 配套左右对比页继续复用：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
- 这张页面就是下面开展工作的基准线
|
||
|
||
当前确认：
|
||
|
||
- 这张页面已经具备点击拾取功能
|
||
- 点击左右任一地图对象，都可以查看：
|
||
- `source`
|
||
- `source-layer`
|
||
- `render layer`
|
||
- feature properties
|
||
- 因此这张页面可以继续作为 `20nm delivery` 线的人工视觉审查页
|
||
|
||
本轮生成的对比截图：
|
||
|
||
- `/tmp/navsea-compare-karatsu-20nm-review.png`
|
||
|
||
截图结论：
|
||
|
||
- 右侧 `20nm delivery` 目前仍与左侧原始版差距明显
|
||
- 差异仍主要集中在：
|
||
- `baseline / bathymetry / depth contour`
|
||
- 陆域/道路上下文层次
|
||
- 标注与航标文本/图标
|
||
|
||
### 20nm Compare Page Root Cause Fix
|
||
|
||
本轮已经定位并修正了一个关键问题：
|
||
|
||
- 之前 `navsea-compare-karatsu-20nm.html` 右侧使用的是：
|
||
- `style.compare-delivery-karatsu-10nm.json`
|
||
- 这份 compare style 大量读取：
|
||
- `class_code`
|
||
- `display_code`
|
||
- `label_position_code_legacy`
|
||
- `depth_value_m_legacy`
|
||
- 但 `20nm delivery` 这批 PBF 实际提供的主字段是：
|
||
- `chart_*`
|
||
- `canonical_*`
|
||
- `place_name_*`
|
||
- `name_ja`
|
||
|
||
结论：
|
||
|
||
- 右侧此前“大面积只剩线、不见面、不见符号”的主因，是样式读取字段与 PBF 实际 schema 不匹配
|
||
|
||
本轮已修正：
|
||
|
||
- [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html)
|
||
- 右侧样式从：
|
||
- `./domain/style.compare-delivery-karatsu-10nm.json`
|
||
- 切回：
|
||
- `./domain/style.navsea-delivery-karatsu-10nm.json`
|
||
|
||
修正后结果：
|
||
|
||
- 右侧海区面、陆域面、道路和主要符号层已恢复显示
|
||
- 当前差距虽然仍然明显，但已经从“schema 读错导致的整体失真”回到“正式 delivery style 本身与原始版仍有视觉差距”的层面
|
||
|
||
这意味着下一步可以更聚焦地修：
|
||
|
||
- `style.navsea-delivery-karatsu-10nm.json`
|
||
- 而不是继续在不兼容的 compare style 上浪费时间
|
||
|
||
### 20nm Content-Equivalence Clarification
|
||
|
||
关于“`20nm delivery` 和原始 `newpec` 的内容是不是一致、现在看起来不同是不是因为 style”，当前可以做如下判断：
|
||
|
||
- 不能严格说“已经证明对象级完全一致”
|
||
- 但可以说：主要对象覆盖和实例规模是高度对应的
|
||
|
||
当前依据：
|
||
|
||
- 刷新的 20nm render audit 里：
|
||
- 原始 feature 实例数 = `258317`
|
||
- delivery feature 实例数 = `258317`
|
||
- 抽样瓦片 `11/1761/821` 中，关键层实例数一一对应：
|
||
- `P基本線 = 95` ↔ `baseline_area = 95`
|
||
- `P基本線ククリ = 175` ↔ `baseline_outline = 175`
|
||
- `L海底地形 = 210` ↔ `bathymetry_line = 210`
|
||
- `L等深線 = 86` ↔ `depth_contour = 86`
|
||
- `P陸域 = 23` ↔ `land_area = 23`
|
||
|
||
因此：
|
||
|
||
- 从“主要几何/对象覆盖有没有带上”这个角度看，`20nm delivery` 与原始 `newpec` 是高度对应的
|
||
- 当前视觉差距，style 的确是主因，而且是当前最值得优先修的部分
|
||
|
||
但仍需保留一条实话：
|
||
|
||
- 不能把它简化成“100% 只有 style 问题”
|
||
- 因为 builder 的 mapping audit 里仍有大量：
|
||
- `render_rule_unresolved`
|
||
- 这说明 delivery 端的一些 `chart_*` 语义生成仍然存在启发式/未完全命中规则的情况
|
||
|
||
一句话结论：
|
||
|
||
- 当前更接近真实情况的表述是：
|
||
- `20nm delivery` 的主要内容大体和原始版对上了
|
||
- 当前看起来差很多，主因是 style
|
||
- 但不是已经排除所有 data / semantic 映射问题
|
||
|
||
### 20nm Visual Restore Round: Fishery + Nav Mark Findings
|
||
|
||
本轮针对用户肉眼指出的两类问题做了定点排查：
|
||
|
||
- 红圈里的港区/灯标类标识大量“看起来像丢了”
|
||
- 鱼礁/渔具定置区视觉表达明显丢失
|
||
|
||
当前确认：
|
||
|
||
- 这些对象并不是没进 `20nm delivery` PBF
|
||
- 它们大多已经在瓦片里，但在样式层和部分编码层被“画错了”
|
||
|
||
抽样瓦片：
|
||
|
||
- `11/1763/821`
|
||
- `11/1764/821`
|
||
|
||
确认结果：
|
||
|
||
- 原始 `p航路標識群` 与 delivery `navigation_marks` 数量对应
|
||
- 原始 `P漁具定置箇所` 与 delivery `fixed_fishing_gear_area` 数量对应
|
||
- 原始 `p投錨注意障害物` 与 delivery `anchor_caution_hazard_point` 数量基本对应
|
||
|
||
关键诊断：
|
||
|
||
- `fixed_fishing_gear_area` 之前只被画成了绿色半透明面
|
||
- 这和原始 `P漁具定置箇所` 的 `fill-daytime-910` 图案填充 + 紫色边线差异很大
|
||
- 这正是“鱼礁看起来都没了”的主因之一
|
||
- `navigation_marks` 里大量对象被 builder 粗归并成：
|
||
- `lighthouse`
|
||
- `light_beacon`
|
||
- `buoy`
|
||
- 原始图则是按 `表示用番号` 精细区分图标
|
||
- 例如：
|
||
- `港湾灯台` 对应 `symbol-daytime-301`
|
||
- `防波堤灯台` 对应 `symbol-daytime-302`
|
||
- `灯 (Lt)` 常见为 `symbol-daytime-303`
|
||
- delivery 之前把这些类型大量画成通用 `301 / 310`
|
||
- 所以肉眼会感觉“标识丢了”或“和原图不像”
|
||
|
||
本轮已做的样式修复：
|
||
|
||
- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
|
||
- `fixed_fishing_gear_area`
|
||
- 改回 `fill-daytime-910` 图案填充
|
||
- 新增紫色 outline，贴近原始 `P漁具定置箇所`
|
||
- `navigation_marks`
|
||
- `港湾灯台 -> symbol-daytime-301`
|
||
- `防波堤灯台 -> symbol-daytime-302`
|
||
- `灯 (Lt) -> symbol-daytime-303`
|
||
- `沿岸灯台 (15M over) -> symbol-daytime-300`
|
||
- `r4` 版本附加修复：
|
||
- 关闭 `nav-light-flare`
|
||
- 关闭 `nav-light-arc`
|
||
- 即不再显示灯塔外侧的环/扇形
|
||
- `nav-marks / anchor-hazard-points / hazard-points` 增加 `icon-ignore-placement`
|
||
- 目的：优先保证灯塔、小灯和碍航点符号本体出图
|
||
- `r6` 版本关键修复：
|
||
- render-based 对比确认：右侧大面积 icon 缺失不是肉眼误判
|
||
- 根因定位为 delivery style 的 sprite 与左侧原始版不一致
|
||
- 左侧线上原始样式使用：
|
||
- `https://tile.mapple-on.jp/newpec-symbols-20251001/sprite`
|
||
- 右侧 delivery style 原先使用本地：
|
||
- `http://192.168.200.184/newpec/sprite/sprite?v=111`
|
||
- 将 delivery style 的 sprite 切到与左侧同一套后，`r6` 渲染截图已确认：
|
||
- 灯塔/小灯/大量点图标明显恢复
|
||
- 本轮用于机器复核的截图：
|
||
- `/tmp/navsea-compare-r6.png`
|
||
- `r7` 版本修正：
|
||
- 用户确认“不要灯塔外圈，但红绿标识仍要保留”
|
||
- 因此前一轮把 `nav-light-flare` 和 `nav-light-arc` 一起关闭属于误伤
|
||
- 当前策略改为：
|
||
- 恢复 `nav-light-flare`
|
||
- 继续关闭 `nav-light-arc`
|
||
- 即保留红绿小标识，不恢复灯塔环/扇形
|
||
- 当前后台审计状态补充：
|
||
- 已用当前 `r7` 样式重新跑：
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.r7.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.r7.md)
|
||
- 结果与前一版 `20nm refresh` 基本完全一致
|
||
- 这说明当前 `20nm` render audit 脚本对以下问题是“盲”的：
|
||
- sprite 资源是否实际可加载
|
||
- 浏览器里 symbol icon 是否真正渲染成功
|
||
- 换句话说：
|
||
- 当前 20nm 后台 render audit 更像“样式表达式审计”
|
||
- 不是浏览器级最终出图审计
|
||
|
||
### Strict Audit Unification
|
||
|
||
本轮已新增统一审计脚本：
|
||
|
||
- [`navsea_strict_audit.py`](/root/sourceserver/pbf/navsea_strict_audit.py)
|
||
- [`strict_audit_hotspots_20nm.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm.json)
|
||
|
||
它会把两部分合并到同一份报告里：
|
||
|
||
- 浏览器真实出图截图差异
|
||
- 当前 20nm backend render audit 摘要
|
||
|
||
但当前实际工作方式已经进一步收紧为：
|
||
|
||
- 后台 render audit 是主审计
|
||
- 小范围 AOI 图像审计是校准审计
|
||
- 不再只看整屏大 diff
|
||
- 只盯后台最容易误判的热点区域：
|
||
- 航标 / 灯塔 / 红绿标识
|
||
- 鱼礁 / 碍航点
|
||
- 远处 symbol / 小灯
|
||
|
||
当前产物：
|
||
|
||
- [strict_audit_summary.md](/root/sourceserver/pbf/report/strict_audit/strict_audit_summary.md)
|
||
- [strict_audit_summary.json](/root/sourceserver/pbf/report/strict_audit/strict_audit_summary.json)
|
||
- [compare_full.png](/root/sourceserver/pbf/report/strict_audit/compare_full.png)
|
||
- [compare_left.png](/root/sourceserver/pbf/report/strict_audit/compare_left.png)
|
||
- [compare_right.png](/root/sourceserver/pbf/report/strict_audit/compare_right.png)
|
||
- [compare_diff.png](/root/sourceserver/pbf/report/strict_audit/compare_diff.png)
|
||
- [report/strict_audit/hotspots](/root/sourceserver/pbf/report/strict_audit/hotspots)
|
||
|
||
当前 `r7` strict audit 结论：
|
||
|
||
- compare version:
|
||
- `20nm-r7-20260331-2044`
|
||
- visual changed ratio:
|
||
- `0.899848`
|
||
- changed pixels:
|
||
- `230361 / 256000`
|
||
- backend render audit 总体仍是：
|
||
- `extra_in_engineering = 258317`
|
||
- `missing_in_engineering = 258317`
|
||
|
||
当前热点 AOI 排名：
|
||
|
||
1. `southwest_lighthouse_cluster`
|
||
- changed ratio: `0.972315`
|
||
2. `takashima_main_harbor_marks`
|
||
- changed ratio: `0.783759`
|
||
3. `takashima_inner_nearshore_hazards`
|
||
- changed ratio: `0.744246`
|
||
4. `east_breakwater_marks`
|
||
- changed ratio: `0.617833`
|
||
|
||
这份统一审计的意义是：
|
||
|
||
- 以后不再只靠整屏图像差异判断问题
|
||
- 可以用少量热点小框去校准后台 render audit 的盲区
|
||
- 当用户肉眼说“这里还不对”时，可以直接把那个区域加入热点审计并复跑
|
||
|
||
线上已同步：
|
||
|
||
- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-10nm.json`
|
||
|
||
仍需继续确认/修的点：
|
||
|
||
- `灯標` 等对象仍然只有较粗语义字段，无法仅靠当前 style 完全恢复原始 `表示用番号` 级别图标
|
||
- 如果这轮样式修复后仍有明显“标识不像原图”的对象，下一步需要回到 builder：
|
||
- 保留/补出更细的 legacy display code
|
||
- 再重建 `pbf-delivery-karatsu-20nm`
|
||
|
||
## 20nm Delivery JP Status
|
||
|
||
已对 `/home/wwwroot/pbf-delivery-karatsu-20nm` 全量 `154` 个瓦片做扫描。
|
||
|
||
结论：
|
||
|
||
- 这批 `20nm delivery` PBF 不是“几乎没有日文”
|
||
- 更准确地说：
|
||
- 日文字段键名已经清理得比较干净了
|
||
- 但日文属性值仍然很多
|
||
|
||
当前确认：
|
||
|
||
- 日文属性键名：`0`
|
||
- 但含日文值的字段：`139` 组
|
||
|
||
典型仍含日文值的字段包括：
|
||
|
||
- `canonical_object_type`
|
||
- `detection_key`
|
||
- `semantic_key`
|
||
- `chart_label_text`
|
||
- `name_ja`
|
||
- `name_subtext_ja`
|
||
- `place_name_ja`
|
||
|
||
典型例子：
|
||
|
||
- `baseline_outline.canonical_object_type = P基本線ククリ`
|
||
- `bathymetry_line.canonical_object_type = L海底地形`
|
||
- `place_label_land.place_name_ja = 佐賀県 / 長崎県 / 佐賀市`
|
||
- `navigation_marks.name_ja = 長崎県大島大橋橋梁灯 / 鷹島肥前大橋橋梁灯`
|
||
|
||
一句话判断：
|
||
|
||
- `20nm delivery` 已经基本摆脱“日文键名”
|
||
- 但还远没有摆脱“日文语义值”
|
||
|
||
## 20nm Delivery Build Chain
|
||
|
||
当前已经查明，这套：
|
||
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
|
||
是由：
|
||
|
||
- [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py)
|
||
|
||
这条交付 builder 代码链生成的。
|
||
|
||
直接证据：
|
||
|
||
- 存在构建审计文件：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm.mapping_audit.json`
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm.mapping_audit.md`
|
||
- 其中明确记录：
|
||
- `bundle_id = navsea-core`
|
||
- `output_root = /home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- `tile_jobs = 154`
|
||
- `written_tiles = 154`
|
||
|
||
代码链条：
|
||
|
||
1. `navsea_tile_builder.py`
|
||
- 从原始 `newpec` 瓦片读取 source feature
|
||
- 从 MySQL `pbf_analysis` 库读取 `pbf_relayer_candidates`
|
||
- 通过 [`navsea_mapping_registry.py`](/root/sourceserver/pbf/navsea_mapping_registry.py) 做 source-layer / render-rule / field-name 映射
|
||
- 输出 delivery PBF
|
||
2. `tasks/pbf/mappings/navsea_field_name_rules_v1.yaml`
|
||
- 控制哪些字段保留在 delivery
|
||
3. `NavSeaMappingRegistry`
|
||
- 控制 `source_layer_jp -> output_layer`
|
||
- 控制 render rule / field-name rule 的匹配
|
||
|
||
可高置信还原的构建形态是：
|
||
|
||
```bash
|
||
./.venv/bin/python navsea_tile_builder.py \
|
||
--center-lat 33.4425 \
|
||
--center-lon 129.9697 \
|
||
--radius-nm 20 \
|
||
--zmin 0 \
|
||
--zmax 14 \
|
||
--output /home/wwwroot/pbf-delivery-karatsu-20nm \
|
||
--fid-key 'thisMyWorld@2026' \
|
||
--fid-key-id navsea-fid-key-v1 \
|
||
--bundle-id navsea-core
|
||
```
|
||
|
||
说明：
|
||
|
||
- 上面这条命令是依据 builder 参数、Karatsu 中心点、输出目录、mapping audit 结果做的高置信还原
|
||
- 当前 shell history 里没有直接留下这次 `20nm delivery` 的完整原始命令行，所以这部分属于“高置信重建”，不是逐字历史回放
|
||
|
||
## Latest Audit Clarification
|
||
|
||
关于“最新审计是否就是拿这批 PBF 做的”，需要分两层说：
|
||
|
||
- 是：
|
||
- `2026-03-31` 确实产出了基于 `Karatsu 20nm delivery` 的审计文件：
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md)
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md)
|
||
- 但不是当前最可靠、最可采信的继续修复基线：
|
||
- 当前最可靠的仍然是：
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md)
|
||
|
||
原因：
|
||
|
||
- `20nm delivery` 这批 PBF 已经丢失了对象级回对锚点
|
||
- 所以它可以做“看起来对不对”的粗审
|
||
- 但不能做可信的对象级 render audit
|
||
|
||
### 20nm Refresh Audit
|
||
|
||
本轮已重新刷新一份 `20nm delivery` render audit：
|
||
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.md)
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.refresh.json)
|
||
|
||
刷新结果延续原判断：
|
||
|
||
- `extra_in_engineering = 258317`
|
||
- `missing_in_engineering = 258317`
|
||
|
||
仍然说明：
|
||
|
||
- 这份审计可以继续作为“粗审 / 分层排查”参考
|
||
- 但由于缺少对象级回对锚点，不能把它当成严格可信的对象级等价审计
|
||
|
||
当前最值得作为视觉复原优先级的 20nm 问题组：
|
||
|
||
- `baseline_outline` / `P基本線ククリ`
|
||
- `87709`
|
||
- `baseline_area` / `P基本線`
|
||
- `50421`
|
||
- `depth_contour` / `L等深線`
|
||
- `36460`
|
||
- `bathymetry_line` / `L海底地形`
|
||
- `35940`
|
||
- `onshore_structure_line` / `L陸上構造物陸`
|
||
- `10544`
|
||
- `land_area` / `P陸域`
|
||
- `7961`
|
||
|
||
Style 语义专项里仍最重要的是：
|
||
|
||
- `depth_numeric_missing` on `L海底地形`
|
||
- `24168`
|
||
- `depth_numeric_missing` on `L等深線`
|
||
- `11929`
|
||
- `safety_icon_missing` on `p航路標識群`
|
||
- `1885`
|
||
|
||
## Latest Audit Status
|
||
|
||
### 0. Latest Visual Compare Adjustment
|
||
|
||
已完成：
|
||
|
||
- [`src/pbf/navsea-delivery-karatsu-20nm-latest.html`](/root/sourceserver/pbf/src/pbf/navsea-delivery-karatsu-20nm-latest.html)
|
||
- [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html)
|
||
|
||
当前这两个页面已经从：
|
||
|
||
- `style.navsea-delivery-karatsu-10nm.json`
|
||
|
||
切到：
|
||
|
||
- `style.compare-delivery-karatsu-10nm.json`
|
||
|
||
目的：
|
||
|
||
- 先用现成的“兼容旧视觉”样式，把 20nm 右侧画面尽快拉近原始版
|
||
- 在不强行覆盖当前 delivery style 主文件的前提下，先验证视觉方向
|
||
|
||
当前线上页面：
|
||
|
||
- `http://192.168.200.184/newpec/navsea-delivery-karatsu-20nm-latest.html`
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
|
||
说明：
|
||
|
||
- 这一步优先解决“肉眼差距太大”的问题
|
||
- 下一步仍要把有效改动逐步收敛回正式 delivery style
|
||
|
||
### 0.1 Latest Visual Diagnosis
|
||
|
||
这一步又补做了两轮验证：
|
||
|
||
- 抽查 `20nm delivery` 瓦片后，确认它并非缺层；样例瓦片包含 19 个语义层，包括：
|
||
- `land_area`
|
||
- `baseline_area`
|
||
- `baseline_outline`
|
||
- `depth_contour`
|
||
- `navigation_marks`
|
||
- 使用 headless Chrome 抓取了最新左右对比页截图，确认“视觉差距大”不是猜测，而是可以稳定复现
|
||
|
||
当前结论：
|
||
|
||
- 如果把 compare style 里的 raster 全关掉，右侧会失去旧版那种陆地道路与陆域上下文，显得过于“空”
|
||
- 如果 raster 全强度打开，又会变成偏白、偏现代的底图，看起来仍明显不像左侧原始版
|
||
- 这说明 `20nm delivery` 的问题不是单一样式开关，而是：
|
||
- style 侧：底图强度、海陆底色、线面层级
|
||
- data/coverage 侧：旧版陆域上下文比当前 delivery `land_area` 更完整
|
||
|
||
当前已收敛到一个折中版：
|
||
|
||
- [`src/Domain/style.compare-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/Domain/style.compare-delivery-karatsu-10nm.json)
|
||
- 背景从纯白改为海图区底色
|
||
- raster 保留，但柔化为弱底图：
|
||
- `raster-opacity: 0.42`
|
||
- `raster-saturation: -0.45`
|
||
- `raster-brightness-min: 0.15`
|
||
- `raster-brightness-max: 0.92`
|
||
- `raster-contrast: -0.12`
|
||
|
||
当前判断：
|
||
|
||
- 这版比“raster 全开”更接近旧版
|
||
- 也比“raster 全关”更接近旧版
|
||
- 但它仍只是过渡收敛，不是最终解决
|
||
|
||
### 0.2 Domain-Compatible Baseline Discovery
|
||
|
||
今天又确认了一个非常关键的事实：
|
||
|
||
- 用户指出最接近旧版的是：
|
||
- `http://192.168.200.184/newpec/domain/navsea-compare-legacy-domain-compatible.html`
|
||
- 这张页面右侧使用的是：
|
||
- `style.domain-legacy-compatible-karatsu-10nm.json`
|
||
- 但线上 deployed 的这份 style，和仓库当前的同名文件并不是同一份内容
|
||
|
||
当前已确认的差异方向：
|
||
|
||
- 线上 deployed 版仍大量保留旧样式风格：
|
||
- legacy layer id
|
||
- legacy 字段名
|
||
- 例如 `分類番号`、`英文字地名`、`日本語地名`
|
||
- 仓库当前版则已经 recode 成标准命名：
|
||
- `class_code`
|
||
- `place_name_en`
|
||
- `place_name_ja`
|
||
|
||
这意味着：
|
||
|
||
- “最接近旧版”的那张图，并不是我们最近在调的 `delivery compare style`
|
||
- 它本质上更接近“旧样式最小改动映射到 Domain PBF”的验证线
|
||
- 这也是为什么直接沿着 `20nm delivery + compare-delivery style` 去调，视觉上总对不上用户记忆里的“最佳版本”
|
||
|
||
为避免这个基线丢失，已经把线上 deployed 版快照回收到仓库：
|
||
|
||
- [`src/Domain/style.domain-legacy-compatible-karatsu-10nm.deployed-2026-03-31.json`](/root/sourceserver/pbf/src/Domain/style.domain-legacy-compatible-karatsu-10nm.deployed-2026-03-31.json)
|
||
|
||
后续视觉回归时，应该优先把它当成“最接近旧版的真实基线”来对照，而不是只看仓库当前的 recode 版本。
|
||
|
||
### 1. Karatsu 20nm delivery
|
||
|
||
已产出：
|
||
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.md)
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_20nm_2026-03-31.fidonly.md)
|
||
|
||
当前判断：
|
||
|
||
- 这两份结果不能直接作为真实对象级审计依据
|
||
- 原因是 `/home/wwwroot/pbf-delivery-karatsu-20nm` 里的交付瓦片已经没有：
|
||
- `fid`
|
||
- `fid_legacy_raw`
|
||
- `source_layer_jp`
|
||
- 现有审计脚本失去对象回对锚点后，会出现全量：
|
||
- `missing_in_engineering`
|
||
- `extra_in_engineering`
|
||
|
||
结论：
|
||
|
||
- `20nm delivery` 现在是“可交付口径”，但不是“可审计口径”
|
||
|
||
### 2. Karatsu 10nm delivery
|
||
|
||
已产出：
|
||
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.md)
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.json)
|
||
|
||
这次使用了可回对口径：
|
||
|
||
- `--fid-key 'thisMyWorld@2026'`
|
||
- `--match-on-fid-only`
|
||
|
||
审计结果：
|
||
|
||
- `exact_match`: `118747`
|
||
- `mismatch`: `12721`
|
||
- `missing_in_engineering`: `3304`
|
||
- `extra_in_engineering`: `3299`
|
||
|
||
当前可采信判断：
|
||
|
||
- `Karatsu 10nm delivery` 是当前最可靠的继续修复基线
|
||
|
||
## Highest-Priority Problem Groups
|
||
|
||
按当前 10nm 审计结果，优先处理：
|
||
|
||
1. `baseline` 相关
|
||
- `P基本線ククリ`
|
||
- `P基本線`
|
||
- `L基本線`
|
||
|
||
2. `depth / bathymetry` 相关
|
||
- `L等深線`
|
||
- `L海底地形`
|
||
- `depth_numeric_missing`
|
||
|
||
3. `navigation marks` 相关
|
||
- `p航路標識群`
|
||
- `safety_icon_missing`
|
||
|
||
## Concrete Next Step
|
||
|
||
下次继续时，建议按这个顺序推进：
|
||
|
||
- 固定只用：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
作为唯一视觉基线
|
||
- 固定只用：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
作为当前 delivery PBF
|
||
- 先围绕 strict audit 热点逐组修：
|
||
- `southwest_lighthouse_cluster`
|
||
- `takashima_main_harbor_marks`
|
||
- `takashima_inner_nearshore_hazards`
|
||
- `east_breakwater_marks`
|
||
- 每修一轮就重跑：
|
||
- [`navsea_strict_audit.py`](/root/sourceserver/pbf/navsea_strict_audit.py)
|
||
- 目的不是追求整屏 diff 立刻变小，而是让后台 render audit 对热点问题的判断逐步和肉眼一致
|
||
|
||
当前真正的下一步是：
|
||
|
||
- 把用户指出的新问题优先落进热点 AOI
|
||
- 用热点截图和点击拾取结果对照右侧实际图层与属性
|
||
- 再决定是继续修 [`style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)，还是回到 builder 补更细的 delivery 语义字段
|
||
|
||
## Important Notes
|
||
|
||
- 当前仓库工作区仍然不是干净状态，存在其他未提交改动
|
||
- 继续提交时必须只暂存本次修改文件
|
||
- `nas` 主机名在这台机器上已经可用，但依赖本机：
|
||
- `/etc/hosts`
|
||
- `~/.ssh/known_hosts`
|
||
|
||
## Delivery Field Policy
|
||
|
||
本轮已进一步明确字段处置原则：
|
||
|
||
- 总目标：
|
||
- `尽可能减少日文`
|
||
- 处理策略不是“一律删除”，而是区分：
|
||
- 业务语义字段
|
||
- 审计/追踪字段
|
||
|
||
当前建议：
|
||
|
||
- `canonical_family`
|
||
- 保留
|
||
- 已经是英文值，例如 `surface`
|
||
- `canonical_object_type`
|
||
- 不直接删除
|
||
- 改成稳定英文值
|
||
- 例如：
|
||
- `P陸域 -> land_area`
|
||
- `semantic_key`
|
||
- 若进入正式交付版，优先删除
|
||
- 若保留在审计版，则值也必须改成英文
|
||
- 例如：
|
||
- `source:P陸域 -> source:land_area`
|
||
- `detection_key`
|
||
- 若进入正式交付版，优先删除
|
||
- 若保留在审计版，则值也必须改成英文
|
||
- 例如：
|
||
- `surface:P陸域 -> surface:land_area`
|
||
|
||
因此当前项目对这类字段的理解是：
|
||
|
||
- `有业务语义的字段尽量英文化`
|
||
- `纯审计追踪字段尽量从 release PBF 删除`
|
||
- `如果 audit PBF 仍要保留追踪字段，也不能再保留日文值`
|
||
|
||
## Karatsu 10nm Rerun Checkpoint
|
||
|
||
本轮已按当前 builder 代码，重新构建：
|
||
|
||
- `/home/wwwroot/pbf-delivery-karatsu-10nm`
|
||
|
||
实际构建命令：
|
||
|
||
```bash
|
||
./.venv/bin/python navsea_tile_builder.py \
|
||
--center-lat 33.4425 \
|
||
--center-lon 129.9697 \
|
||
--radius-nm 10 \
|
||
--zmin 0 \
|
||
--zmax 14 \
|
||
--output /home/wwwroot/pbf-delivery-karatsu-10nm \
|
||
--fid-key 'thisMyWorld@2026' \
|
||
--fid-key-id navsea-fid-key-v1 \
|
||
--bundle-id navsea-core
|
||
```
|
||
|
||
构建结果：
|
||
|
||
- `tile_jobs = 59`
|
||
- `wrote = 59`
|
||
- `skipped = 0`
|
||
- 最新 mapping audit：
|
||
- `/home/wwwroot/pbf-delivery-karatsu-10nm.mapping_audit.json`
|
||
- `/home/wwwroot/pbf-delivery-karatsu-10nm.mapping_audit.md`
|
||
|
||
线上可直接查看：
|
||
|
||
- 最终交付页：
|
||
- `http://192.168.200.184/newpec/navsea-final-delivery-karatsu-10nm.html`
|
||
- 瓦片：
|
||
- `http://192.168.200.184/pbf-delivery-karatsu-10nm/{z}/{x}/{y}.pbf`
|
||
|
||
本轮还补跑了一份可回对的对象级 render audit：
|
||
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.md`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.md)
|
||
- [`NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.json`](/root/sourceserver/pbf/NavSea_Original_vs_Delivery_Render_Audit_Karatsu_10nm_2026-03-31.rerun.json)
|
||
|
||
这次口径仍然是：
|
||
|
||
- `--fid-key 'thisMyWorld@2026'`
|
||
- `--match-on-fid-only`
|
||
|
||
当前结果：
|
||
|
||
- `exact_match = 121855`
|
||
- `mismatch = 12912`
|
||
- `missing_in_engineering = 5`
|
||
- `extra_in_engineering = 0`
|
||
|
||
这说明：
|
||
|
||
- 10nm 当前这次重建后的对象规模与原始版是一一对上的
|
||
- 旧版那种成千上万 `missing/extra` 的问题当前不再是主要矛盾
|
||
- 现在 10nm 更像是“视觉/语义 mismatch 修复”阶段，而不是“对象丢失/多出”阶段
|
||
|
||
当前仍然最大的 mismatch 组：
|
||
|
||
- `P基本線ククリ = 7873`
|
||
- `P基本線 = 2876`
|
||
- `L基本線 = 619`
|
||
- `p航路標識群 = 574`
|
||
- `p投錨注意障害物 = 374`
|
||
- `p航行危険障害物 = 296`
|
||
|
||
本轮抓取的页面实渲染截图：
|
||
|
||
- `/tmp/navsea-final-delivery-karatsu-10nm-20260331.png`
|
||
|
||
## Visual Audit Baseline Clarification
|
||
|
||
用户本轮再次明确：
|
||
|
||
- 视觉审计仍然固定使用：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
|
||
这意味着：
|
||
|
||
- `20nm compare` 继续是唯一视觉审计基线
|
||
- 本轮重建的 `10nm` 结果只用于：
|
||
- builder 验证
|
||
- 对象级 backend render audit
|
||
- 不能因为 `10nm` 审计更严格，就把视觉基线自动切走
|
||
|
||
后续默认分工：
|
||
|
||
- `20nm compare`
|
||
- 肉眼审图
|
||
- 点击拾取
|
||
- AOI 热点校准
|
||
- `10nm rerun`
|
||
- 严格对象级 render audit
|
||
- 检查 `missing / extra / mismatch`
|
||
|
||
## Small Scope Image Audit Pilot
|
||
|
||
本轮已把“小范围图像对比测试”正式跑通，目的有两个：
|
||
|
||
- 整理出当前继续收敛的唯一 `style.json`
|
||
- 建立一个更可信的视觉审计方法
|
||
|
||
当前固定的 style source of truth：
|
||
|
||
- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
|
||
|
||
虽然名字里仍是 `10nm`，但当前 `20nm compare` 右侧实际就是用它，因此：
|
||
|
||
- 后续继续收敛这一个 delivery style 文件
|
||
- 不再新增新的主 delivery style 文件来分散口径
|
||
|
||
本轮新增的小范围热点配置：
|
||
|
||
- [`strict_audit_hotspots_20nm_pilot.json`](/root/sourceserver/pbf/strict_audit_hotspots_20nm_pilot.json)
|
||
|
||
它只保留 3 个最代表当前问题的热点：
|
||
|
||
1. `takashima_main_harbor_marks`
|
||
2. `takashima_inner_nearshore_hazards`
|
||
3. `east_breakwater_marks`
|
||
|
||
试验版输出：
|
||
|
||
- [`report/strict_audit_pilot/strict_audit_summary.md`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.md)
|
||
- [`report/strict_audit_pilot/strict_audit_summary.json`](/root/sourceserver/pbf/report/strict_audit_pilot/strict_audit_summary.json)
|
||
- [`report/strict_audit_pilot/hotspots`](/root/sourceserver/pbf/report/strict_audit_pilot/hotspots)
|
||
|
||
本轮 pilot 结果：
|
||
|
||
- `takashima_main_harbor_marks`
|
||
- changed ratio: `0.783759`
|
||
- `takashima_inner_nearshore_hazards`
|
||
- changed ratio: `0.744246`
|
||
- `east_breakwater_marks`
|
||
- changed ratio: `0.617833`
|
||
|
||
当前判断：
|
||
|
||
- 这 3 个热点足够小，也足够稳定
|
||
- 它们比整屏 diff 更适合指导 style 迭代
|
||
- 其中：
|
||
- `takashima_main_harbor_marks` 适合作为第一主观察点
|
||
- `east_breakwater_marks` 适合作为回归保护点
|
||
|
||
本轮也补了一份方法文档：
|
||
|
||
- [`NavSea_20nm_Small_Scope_Audit_Method.md`](/root/sourceserver/pbf/NavSea_20nm_Small_Scope_Audit_Method.md)
|
||
|
||
当前认可的“可信审计方法”是：
|
||
|
||
- `20nm compare` 肉眼审图
|
||
- 小范围 AOI 图像对比
|
||
- compare 页点击拾取
|
||
- `10nm rerun` 对象级 backend audit
|
||
|
||
而不是：
|
||
|
||
- 只看整屏图像 diff
|
||
- 或只看 `20nm` backend 总量数字
|
||
|
||
## 20nm Regression Root Cause Check
|
||
|
||
本轮用户再次反馈：
|
||
|
||
- 当前 `20nm compare` 右侧看起来又有退化
|
||
- 主要体感是：
|
||
- 鱼礁丢了
|
||
- 灯的标识又丢了
|
||
|
||
本轮已做排查，结论是：
|
||
|
||
- 当前问题不是最近重建 `20nm pbf` 导致的
|
||
- 也不是 compare HTML 最近又被切到了别的页面
|
||
- 当前最应优先怀疑的是：
|
||
- `style.navsea-delivery-karatsu-10nm.json` 里的图标/过滤表达式
|
||
|
||
排查依据：
|
||
|
||
1. 线上部署时间
|
||
- `/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`
|
||
- `2026-03-31 20:45:52 +0800`
|
||
- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-karatsu-10nm.json`
|
||
- `2026-03-31 20:45:52 +0800`
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
|
||
- `2026-03-25 17:57:29 +0800`
|
||
|
||
2. 这说明
|
||
- `20nm pbf` 没有在这之后被重新构建
|
||
- 当前线上 compare 仍然是 `r7`
|
||
- 当前右侧仍然使用：
|
||
- `./domain/style.navsea-delivery-karatsu-10nm.json`
|
||
|
||
3. 直接解码当前 20nm 瓦片后确认：
|
||
- 鱼礁对象还在
|
||
- 灯塔/灯台对象还在
|
||
|
||
典型样本：
|
||
|
||
- `/home/wwwroot/pbf-delivery-karatsu-20nm/11/1762/821.pbf`
|
||
- `anchor_caution_hazard_point`
|
||
- 存在：
|
||
- `canonical_object_type = 魚礁`
|
||
- `chart_symbol_code = fish_reef`
|
||
- `navigation_marks`
|
||
- 存在：
|
||
- `canonical_object_type = 港湾灯台`
|
||
- `chart_symbol_code = lighthouse`
|
||
- `name_ja = 鷹島灯台`
|
||
|
||
因此当前判断：
|
||
|
||
- `鱼礁/灯标对象并没有从 20nm pbf 里消失`
|
||
- `HTML` 这边也没有把页面切错
|
||
- 问题主要在当前 delivery style 的具体表达方式
|
||
|
||
当前 style 里和这两组最相关的层：
|
||
|
||
- 鱼礁 / 障害点：
|
||
- `anchor-hazard-points`
|
||
- `anchor-hazard-points-428`
|
||
- `fishery-areas`
|
||
- `fishery-areas-outline`
|
||
- 灯 / 灯台：
|
||
- `nav-light-flare`
|
||
- `nav-light-arc`
|
||
- `nav-marks-harbor-lighthouses`
|
||
- `nav-marks-breakwater-lighthouses`
|
||
- `nav-marks-small-lights`
|
||
- `nav-marks-light-beacons`
|
||
- `nav-marks`
|
||
|
||
当前最值得注意的一点：
|
||
|
||
- 鱼礁点目前在 style 里被并到：
|
||
- `anchor-hazard-points-428`
|
||
- 统一使用：
|
||
- `symbol-daytime-428`
|
||
- 这很可能就是“数据还在，但视觉上不像原图、看起来像丢了”的直接原因之一
|
||
|
||
一句话结论：
|
||
|
||
- 这轮退化不是最近改坏了 `20nm pbf`
|
||
- 主问题仍然是当前 `style.navsea-delivery-karatsu-10nm.json`
|
||
- 下一步应继续优先修：
|
||
- 鱼礁 icon 选择
|
||
- 灯/灯台图标和 flare 的具体表达
|
||
- 而不是先回头怀疑 HTML 或重新构建 20nm pbf
|
||
|
||
## Same Compare Page For Kyushu
|
||
|
||
用户已明确：
|
||
|
||
- 继续使用同一张 compare 页做视觉确认
|
||
- 不新增新的 compare 页面
|
||
|
||
本轮已将：
|
||
|
||
- [`src/pbf/navsea-compare-karatsu-20nm.html`](/root/sourceserver/pbf/src/pbf/navsea-compare-karatsu-20nm.html)
|
||
|
||
升级为“同一张页面支持区域切换”。
|
||
|
||
当前行为：
|
||
|
||
- 默认仍是：
|
||
- `唐津 20 海里`
|
||
- 同页新增：
|
||
- `九州`
|
||
|
||
当前线上页面仍是：
|
||
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
|
||
但现在支持：
|
||
|
||
- 默认：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
|
||
- 九州模式：
|
||
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html?profile=kyushu`
|
||
|
||
页面可见版本号已提升为：
|
||
|
||
- `20nm-r8-20260331-2208`
|
||
|
||
本轮也已把九州 style 对齐到当前唐津 `r7`/`r8` 这套表达：
|
||
|
||
- [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
|
||
|
||
当前这份九州 style 的关键变化：
|
||
|
||
- sprite 已不再沿用旧本地 sprite
|
||
- 直接对齐当前唐津 delivery style 的图层表达
|
||
- 只保留：
|
||
- `name = NavSea Delivery Kyushu`
|
||
- 九州 tile URL：
|
||
- `http://192.168.200.184/pbf-delivery-kyushu-reencoded/{z}/{x}/{y}.pbf`
|
||
|
||
线上已部署：
|
||
|
||
- `/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`
|
||
- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`
|
||
|
||
一句话理解：
|
||
|
||
- 以后还是用同一个 compare URL
|
||
- 只是这张页面现在能切：
|
||
- 唐津 20 海里
|
||
- 九州
|
||
|
||
### Compare Page Version Visibility
|
||
|
||
本轮继续增强了同一张 compare 页的版本可见性。
|
||
|
||
当前页面除了 compare 版本号外，还会直接显示：
|
||
|
||
- 当前 delivery style 版本
|
||
- 当前 delivery pbf 版本
|
||
|
||
也就是页面顶部现在可见：
|
||
|
||
- `版本: 20nm-r9-20260331-2210`
|
||
- `Style: ...`
|
||
- `PBF: ...`
|
||
|
||
当前规则：
|
||
|
||
- 唐津模式显示：
|
||
- `Style: style.navsea-delivery-karatsu-10nm.json`
|
||
- `PBF: pbf-delivery-karatsu-20nm`
|
||
- 九州模式显示：
|
||
- `Style: style.navsea-delivery-kyushu.json`
|
||
- `PBF: pbf-delivery-kyushu-reencoded`
|
||
|
||
这样后续视觉确认时，不需要再猜“页面到底连的是哪套 style / pbf”。
|
||
|
||
## Quick Resume Prompt
|
||
|
||
下次开机如果要快速接上，可以先看这份文件，再按下面这句继续：
|
||
|
||
`继续处理 STEP_RECORD.md 里记录的 20nm 固定 compare 基线，围绕 navsea-compare-karatsu-20nm.html 这一个页面和 pbf-delivery-karatsu-20nm 这套 PBF，按 strict audit 的热点 AOI 逐组修视觉问题，并用小范围图像审计去校准后台 render audit。`
|