# 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，与仓库当前同名文件并不一致
- 已正式确定：当前“去掉 PBF 里的日文字段，同时视觉保持尽量不变”的主工作线，不再以 `20nm delivery compare` 为主，而改用固定的 `domain-compatible` 对比页

## Fixed Compare Baseline

从现在开始，这轮工作的固定比较基线是：

- 页面：
  - `http://192.168.200.184/newpec/domain/navsea-compare-legacy-domain-compatible.html`
- 目标 PBF：
  - `http://192.168.200.184/pbf-domain-karatsu-10nm/safety/{z}/{x}/{y}.pbf`
  - `http://192.168.200.184/pbf-domain-karatsu-10nm/detail/{z}/{x}/{y}.pbf`

这条线的定义是：

- 目标不是先追 `20nm delivery` 交付口径
- 目标是先在 `Karatsu 10nm Domain compatible` 这条线上，完成：
  - PBF / style 对日文字段依赖的移除
  - 同时保持视觉尽量贴近旧版

工作规则：

- 不再新增新的 compare 页面
- 后续视觉比较统一只看上面这一张固定页面
- `20nm delivery` 仍可保留为交付线参考，但不再作为当前这轮视觉回归的主页面

## 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 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` 已经基本摆脱“日文键名”
- 但还远没有摆脱“日文语义值”

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

## 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/domain/navsea-compare-legacy-domain-compatible.html`
  作为唯一视觉基线
- 以 [`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)
  作为“最接近旧版”的右侧样式母版
- 在 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 线上逐步去掉日文字段依赖，同时保持视觉尽量不变。`