tei/pbf

Fork 0

Files

OpenAI Codex 1a90927c26 Fix 20nm compare page to use delivery schema

2026-03-31 16:14:02 +08:00

19 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 页面
后续视觉比较统一只看上面这一张固定页面
对比页必须保持左右联动和点击拾取功能可用

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 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/domain/navsea-compare-legacy-domain-compatible.html 作为唯一视觉基线
以 src/Domain/style.domain-legacy-compatible-karatsu-10nm.deployed-2026-03-31.json 作为“最接近旧版”的右侧样式母版
在 Domain compatible 线上逐层确认：
- 哪些 layer 仍依赖 legacy 日文字段
- 哪些可以直接切到标准字段而不改变视觉
- 哪些需要加兼容映射才能保持视觉不变

当前真正的下一步不再是继续调 20nm compare 页面，而是：

把 deployed baseline style 中对 legacy 字段的依赖系统列出来
以固定 compare 页面做逐步替换验证
每次替换后只在这一个页面上检查视觉回归

Important Notes

当前仓库工作区仍然不是干净状态，存在其他未提交改动
继续提交时必须只暂存本次修改文件
nas 主机名在这台机器上已经可用，但依赖本机：
- /etc/hosts
- ~/.ssh/known_hosts

Quick Resume Prompt

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

继续处理 STEP_RECORD.md 里记录的固定 compare 基线，围绕 navsea-compare-legacy-domain-compatible.html 这一个页面，在 pbf-domain-karatsu-10nm 线上逐步去掉日文字段依赖，同时保持视觉尽量不变。

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

Quick Resume Prompt

19 KiB

Raw Blame History