tei/pbf

Fork 0

Files

OpenAI Codex ac72c75593 Add pilot small-scope image audit method

2026-03-31 21:50:36 +08:00

32 KiB

Raw Blame History

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
- GIT_REMOTE_SWITCH_TO_NAS_2026-03-31.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
- 右侧样式从：
  - ./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
- 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
  - 结果与前一版 20nm refresh 基本完全一致
  - 这说明当前 20nm render audit 脚本对以下问题是“盲”的：
    - sprite 资源是否实际可加载
    - 浏览器里 symbol icon 是否真正渲染成功
  - 换句话说：
    - 当前 20nm 后台 render audit 更像“样式表达式审计”
    - 不是浏览器级最终出图审计

Strict Audit Unification

本轮已新增统一审计脚本：

它会把两部分合并到同一份报告里：

浏览器真实出图截图差异
当前 20nm backend render audit 摘要

但当前实际工作方式已经进一步收紧为：

后台 render audit 是主审计
小范围 AOI 图像审计是校准审计
不再只看整屏大 diff
只盯后台最容易误判的热点区域：
- 航标 / 灯塔 / 红绿标识
- 鱼礁 / 碍航点
- 远处 symbol / 小灯

当前产物：

当前 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 排名：

southwest_lighthouse_cluster
- changed ratio: 0.972315
takashima_main_harbor_marks
- changed ratio: 0.783759
takashima_inner_nearshore_hazards
- changed ratio: 0.744246
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

这条交付 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

代码链条：

navsea_tile_builder.py
- 从原始 newpec 瓦片读取 source feature
- 从 MySQL pbf_analysis 库读取 pbf_relayer_candidates
- 通过 navsea_mapping_registry.py 做 source-layer / render-rule / field-name 映射
- 输出 delivery PBF
tasks/pbf/mappings/navsea_field_name_rules_v1.yaml
- 控制哪些字段保留在 delivery
NavSeaMappingRegistry
- 控制 source_layer_jp -> output_layer
- 控制 render rule / field-name rule 的匹配

可高置信还原的构建形态是：

./.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
  - 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

原因：

20nm delivery 这批 PBF 已经丢失了对象级回对锚点
所以它可以做“看起来对不对”的粗审
但不能做可信的对象级 render audit

20nm Refresh Audit

本轮已重新刷新一份 20nm delivery render audit：

刷新结果延续原判断：

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

已完成：

当前这两个页面已经从：

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
- 背景从纯白改为海图区底色
- 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

后续视觉回归时，应该优先把它当成“最接近旧版的真实基线”来对照，而不是只看仓库当前的 recode 版本。

1. Karatsu 20nm delivery

已产出：

当前判断：

这两份结果不能直接作为真实对象级审计依据
原因是 /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

已产出：

这次使用了可回对口径：

--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 审计结果，优先处理：

baseline 相关
- P基本線ククリ
- P基本線
- L基本線
depth / bathymetry 相关
- L等深線
- L海底地形
- depth_numeric_missing
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
目的不是追求整屏 diff 立刻变小，而是让后台 render audit 对热点问题的判断逐步和肉眼一致

当前真正的下一步是：

把用户指出的新问题优先落进热点 AOI
用热点截图和点击拾取结果对照右侧实际图层与属性
再决定是继续修 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

实际构建命令：

./.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：

这次口径仍然是：

--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

虽然名字里仍是 10nm，但当前 20nm compare 右侧实际就是用它，因此：

后续继续收敛这一个 delivery style 文件
不再新增新的主 delivery style 文件来分散口径

本轮新增的小范围热点配置：

strict_audit_hotspots_20nm_pilot.json

它只保留 3 个最代表当前问题的热点：

takashima_main_harbor_marks
takashima_inner_nearshore_hazards
east_breakwater_marks

试验版输出：

本轮 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

当前认可的“可信审计方法”是：

20nm compare 肉眼审图
小范围 AOI 图像对比
compare 页点击拾取
10nm rerun 对象级 backend audit

而不是：

只看整屏图像 diff
或只看 20nm backend 总量数字

Quick Resume Prompt

下次开机如果要快速接上，可以先看这份文件，再按下面这句继续：

继续处理 STEP_RECORD.md 里记录的 20nm 固定 compare 基线，围绕 navsea-compare-karatsu-20nm.html 这一个页面和 pbf-delivery-karatsu-20nm 这套 PBF，按 strict audit 的热点 AOI 逐组修视觉问题，并用小范围图像审计去校准后台 render audit。

32 KiB Raw Blame History Unescape Escape

PBF Step Record

Current Checkpoint

Fixed Compare Baseline

Detail PBF JP Field Inventory

Latest PBF Batch Discovery

20nm Delivery Current Working Baseline

20nm Compare Page Root Cause Fix

20nm Content-Equivalence Clarification

20nm Visual Restore Round: Fishery + Nav Mark Findings

Strict Audit Unification

20nm Delivery JP Status

20nm Delivery Build Chain

Latest Audit Clarification

20nm Refresh Audit

Latest Audit Status

0. Latest Visual Compare Adjustment

0.1 Latest Visual Diagnosis

0.2 Domain-Compatible Baseline Discovery

1. Karatsu 20nm delivery

2. Karatsu 10nm delivery

Highest-Priority Problem Groups

Concrete Next Step

Important Notes

Delivery Field Policy

Karatsu 10nm Rerun Checkpoint

Visual Audit Baseline Clarification

Small Scope Image Audit Pilot

Quick Resume Prompt

32 KiB

Raw Blame History