224 lines
7.9 KiB
Markdown
224 lines
7.9 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，与仓库当前同名文件并不一致
|
||
|
||
## 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
|
||
|
||
下次继续时，建议直接从这一组开始：
|
||
|
||
- 先排查 [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
|
||
- 重点看：
|
||
- `baseline_outline`
|
||
- `baseline_area`
|
||
- `depth_contour`
|
||
- `bathymetry_line`
|
||
- `navigation_marks`
|
||
|
||
目标：
|
||
|
||
- 先把 `baseline` 组的大头 mismatch 压下去
|
||
- 再修 `depth_numeric_missing`
|
||
- 最后修 `safety_icon_missing`
|
||
- 同时继续拆分 `20nm` 的视觉差距：
|
||
- 哪些能靠 style 收敛
|
||
- 哪些必须回到 delivery 数据覆盖范围本身去补
|
||
|
||
## Important Notes
|
||
|
||
- 当前仓库工作区仍然不是干净状态，存在其他未提交改动
|
||
- 继续提交时必须只暂存本次修改文件
|
||
- `nas` 主机名在这台机器上已经可用，但依赖本机：
|
||
- `/etc/hosts`
|
||
- `~/.ssh/known_hosts`
|
||
|
||
## Quick Resume Prompt
|
||
|
||
下次开机如果要快速接上，可以先看这份文件，再按下面这句继续：
|
||
|
||
`继续处理 STEP_RECORD.md 里记录的下一步，从 Karatsu 10nm delivery 审计的 baseline / depth / navigation marks 三组问题开始修。`
|