pbf/STEP_RECORD.md

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
• 已补项目协作约定文件：
  • AGENTS.md
  • .codex/README.md
  • .codex/SESSION_START.md
  • .codex/RESUME_PROMPT.md
• 已完成一次新的 delivery 审计，并确认哪条审计线可用
• 已把 Karatsu 20nm 的最新展示页和左右对比页切到更贴近旧视觉的 compare style
• 已确认 Karatsu 20nm 当前“和旧版差很大”的问题，既有 style 原因，也有 delivery 数据覆盖范围与旧版上下文不一致的原因

Latest Audit Status

0. Latest Visual Compare Adjustment

已完成：

• src/pbf/navsea-delivery-karatsu-20nm-latest.html
• 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
  • 背景从纯白改为海图区底色
  • 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 全关”更接近旧版
• 但它仍只是过渡收敛，不是最终解决

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

当前判断：

• 这两份结果不能直接作为真实对象级审计依据
• 原因是 /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
• 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
• 重点看：
  • 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 三组问题开始修。