Files
pbf/STEP_RECORD.md
2026-04-08 19:32:25 +08:00

772 lines
28 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 项目步骤记录
最后更新:`2026-04-08 19:32`
仓库:`/root/sourceserver/pbf`
远端:`ssh://git@nas:2222/tei/pbf.git`
## 文档规则
- `STEP_RECORD.md` 必须使用中文
- 后续新增输出文档必须使用中文
- 后续新增审计报告必须使用中文
## 当前固定基线
唯一固定使用的视觉审计页面:
- `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
当前页面版本:
- `HTML: compare-r19-20260402-1203`
- `Style: karatsu-final-style-r15-20260402-1203`
- `PBF: karatsu-final-pbf-20nm-20260402-1156-fullrefresh1`
当前仍使用同一张 HTML 做两个 profile
1. 唐津 20 海里
- `style.navsea-delivery-karatsu-20nm-final.json`
- `pbf-delivery-karatsu-20nm-final`
2. 九州
- `style.navsea-delivery-kyushu.json`
- `pbf-delivery-kyushu-reencoded`
## 当前结论
- 当前主视觉问题不再优先怀疑 compare HTML 切错。
- 当前主问题分成两类:
- `style` 过滤条件写错或过宽
- 线上仍在使用较早生成的 `20nm final` 瓦片,部分关键对象没有 `class_code / display_code`
## 2026-04-02 本轮关键发现
### 1. 航标紫色圈“又回来了”的原因
- 问题层:`nav-light-flare`
- 根因:这一层的过滤条件写得过宽,几乎所有带 `light_color_code` 的对象都会被套上 flare。
- 直接表现:
- 一些本来不该带圈的航标、浮标又被画成紫色圈
- 例如 `31300003` 这类脚手架浮标不应再命中 flare
- 现已修正:
- `nav-light-flare` 只对原始样式允许的那几类灯标生效
- 不再给普通浮标乱套圈
### 2. “眼睛”图标回来的原因
- 问题层:`anchor_caution_hazard_point`
- 根因不是对象丢失,而是线上旧 `20nm final` 瓦片里很多对象没有 `class_code`
- 一旦 `class_code` 缺失,样式只能退回:
- `chart_icon_image = symbol-daytime-428`
- 直接表现:
- `420` 这类投锚注意危险物又被画成眼睛图标
- 实际核对结果:
- 用当前 builder 只重建 `11/1765/820` 这一张瓦片后,同一批对象已经恢复:
- `class_code = 420`
- 同时对应浮标对象也恢复:
- `display_code = 31300003`
- `chart_icon_image = symbol-daytime-327`
### 3. 为什么会出现“我们改过了,怎么又错了”
- 之前改对的是 `style` 逻辑
- 但 compare 页底下继续使用的是较早生成的 `20nm final` 瓦片
- 这批旧瓦片缺少关键码值字段
- 所以一旦样式依赖这些字段,就会退回错误兜底图标
一句话总结:
- 这次回退不是“代码白改了”
- 而是“新 style 压在旧 PBF 上跑”,导致修正无法完整生效
### 4. `pパイロットステーション` 丢失的原因
- 这个对象不是 PBF 丢了。
- 实际核对结果:
- 原始对象在 `z12/3530/1641`
- 原始层:`pパイロットステーション`
- 原始 `fid = 9002206`
- `分類番号 = 500`
- 当前 final PBF 里也存在对应对象:
- `source-layer = pilot_station_point`
- `class_code = 500`
- `chart_symbol_code = pilot_station`
- 真正问题:
- final style 之前没有 `pilot_station_point` 这一层
- 所以右侧页面虽然有对象,但完全没画出来
- 现已修正:
- 新增 `pilot-station-points`
- 固定使用 `symbol-daytime-500`
## 当前已落地的修正
- 已修正 `nav-light-flare` 过滤逻辑
- 已上线新的 compare 页版本号显示
- 已完成 `20nm final` 全量重生并切到线上
- 当前整套 `20nm final` 都是当前 builder 生成的新版本,不再是只修单瓦片
## 2026-04-03 canonical_object_type 去日文推进
### 1. 本轮代码侧已完成
- 在 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py) 中把:
- `canonical_object_type` 的内部原值
- 和最终 release 输出值
分开处理
- 保留内部旧值给:
- DB render rule
- field value rule
- 现有 builder 语义推断
- 最终输出到 delivery / final PBF 的 `canonical_object_type` 改为稳定 ASCII 值
- 已同步改:
- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
- [`src/pbf/style.navsea-delivery-karatsu-20nm-final.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-20nm-final.json)
- [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
- 当前 style 中原先直接依赖的日文 `canonical_object_type` 过滤值,已切到对应 ASCII 值。
### 2. 10nm 临时副本结果
- 临时副本目录:
- `/tmp/pbf-delivery-karatsu-10nm-canonical-20260403`
- 当前结果:
- `canonical_object_type` 非 ASCII 复扫结果已经降到:
- `non_ascii_distinct = 0`
- 说明:
- 唐津 10 海里这条可信 backend baseline 上,`canonical_object_type` 去日文已经跑通到 0 残留。
### 3. 10nm 渲染审计结果
- 新报告:
- [`report/render_audit_10nm_canonical_type_2026-04-03.md`](/root/sourceserver/pbf/report/render_audit_10nm_canonical_type_2026-04-03.md)
- [`report/render_audit_10nm_canonical_type_2026-04-03.json`](/root/sourceserver/pbf/report/render_audit_10nm_canonical_type_2026-04-03.json)
- 结果统计与 2026-03-31 trusted rerun 一致:
- `exact_match = 121855`
- `mismatch = 12912`
- `missing_in_engineering = 5`
- 结论:
- 本轮 `canonical_object_type` 去日文没有引入新的 10nm backend render 回退。
### 4. 20nm 对象保真审计结果
- 新报告:
- [`report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.md`](/root/sourceserver/pbf/report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.md)
- [`report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.json`](/root/sourceserver/pbf/report/object_preservation_20nm_canonical_type_2026-04-03/object_preservation_final_20nm.json)
- 结果:
- `tiles compared = 154`
- `raw objects = 4165`
- `preserved = 4165`
- `missing / wrong_relayer / identifier_lost / identifier_mismatch = 0`
- 结论:
- 20nm final 在对象保真口径上没有因为本轮 `canonical_object_type` 清理出现对象级退化。
### 5. 当前未收完的部分
- 20nm 临时副本:
- `/tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403`
- 已经完成过一轮旧映射 replay也完成了对象保真审计
- 但在映射表补第二批 / 第三批尾项后20nm 全量 ASCII replay 还没有完整重新跑完并做最终非 ASCII 复扫
- 因此当前真实状态是:
- `10nm backend trusted baseline` 已完成去日文和审计
- `20nm object preservation` 已完成审计
- `20nm canonical_object_type 全量去日文复扫` 仍差最后一步 replay + rescan
## 当前未完成项
- 继续按同一张 compare 页回扫其他依赖 `class_code / display_code` 的细分类图标
- 继续做热点截图复核,确认没有新的样式回退
- 完成 `/tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403` 的全量 replay
- 对 20nm canonical 副本补做最终 `non_ascii canonical_object_type` 复扫
## 2026-04-04 全量 PBF 按最新逻辑重建启动
### 1. 本轮启动前确认
- 已按仓库续接要求复读:
- `STEP_RECORD.md`
- `PROJECT_HANDOFF_2026-03-31.md`
- `NavSea_Delivery_Preflight_Audit_Spec.md`
- `NavSea_Audit_Logic_And_Evolution_2026-04-01.md`
- 已确认当前远端仍是:
- `ssh://git@nas:2222/tei/pbf.git`
- 已确认当前 builder 里的“最新逻辑”包含:
- `navsea_tile_builder.py``RELEASE_CANONICAL_OBJECT_TYPE_MAP`
- delivery / final 输出会把 `canonical_object_type` 物化为最新 ASCII 发布值
### 2. 启动过程中发现的阻塞
- 直接用脚本默认参数启动会失败:
- `RuntimeError: navsea mapping registry is empty`
- 已核实数据库当前实际存在的规则 bundle 只有:
- `bundle_id = navsea-core`
- 因此本轮全量重建统一改为:
- `--bundle-id navsea-core`
### 3. 当前已启动的重建会话
- 为避免 `reference_tile_root` 和输出目录互相清空,已先把现有瓦片集合复制到:
- `/tmp/pbf-refsets/karatsu10-delivery`
- `/tmp/pbf-refsets/karatsu10-engineering`
- `/tmp/pbf-refsets/karatsu20-delivery`
- `/tmp/pbf-refsets/karatsu20-final`
- `/tmp/pbf-refsets/kyushu-delivery`
- `/tmp/pbf-refsets/kyushu-engineering`
- 当前正在运行的 builder 会话:
- `karatsu10 delivery`: session `72703`
- `karatsu10 engineering`: session `33691`
- `karatsu20 delivery`: session `9519`
- `karatsu20 final`: session `97913`
- `kyushu delivery`: session `79176`
- `kyushu engineering`: session `88222`
- 统一使用:
- `--fid-key thisMyWorld@2026`
- `--bundle-id navsea-core`
- delivery / final 口径统一附带:
- `--release-minimal`
- engineering 口径统一附带:
- `--engineering`
### 4. 本轮目标
- 把当前活跃的 builder 产物统一按最新逻辑重放:
- `/home/wwwroot/pbf-delivery-karatsu-10nm`
- `/home/wwwroot/pbf-engineering-karatsu-10nm`
- `/home/wwwroot/pbf-delivery-karatsu-20nm`
- `/home/wwwroot/pbf-delivery-karatsu-20nm-final`
- `/home/wwwroot/pbf-delivery-kyushu-reencoded`
- `/home/wwwroot/pbf-engineering-kyushu`
### 5. 下一步
1. 持续轮询 6 个 builder 会话,确认没有新的运行时异常
2. 待会话完成后复核各目录瓦片数是否回到原集合规模
3. 如需要,再补做 `canonical_object_type` 非 ASCII 复扫与对象保真 / render 审计
## 2026-04-05 九州 compare 图标问题收口
### 1. 新确认的问题类型
- 九州 profile 中出现的“红 X 变鱼礁 / 航标 icon 不对”,本轮确认不属于前一轮唐津那种:
- `旧 PBF 缺 class_code / display_code`
- 导致样式退回兜底图标
- 本轮在九州对应瓦片中核实到:
- `class_code`
- `display_code`
- `canonical_object_type`
- `chart_symbol_code`
这些关键字段本身是存在的
- 因此当前九州问题的真实根因是:
- `style.navsea-delivery-kyushu.json` 仍停留在较早的粗分类图标逻辑
- 没有同步到 `karatsu 20nm final` 已经收好的精细图标分支
### 2. 危险物图标根因
- 旧原始样式对:
- `409`
- `420`
- `425`
- `428`
- `434`
都是按 `分類番号` 分开画不同图标
- 但九州 delivery 样式之前:
- `navigation_hazard_point` 只吃 `chart_icon_image`
- `anchor_caution_hazard_point``obstruction / hazard_mark / fish_reef` 又被统一压进 `symbol-daytime-428`
- 所以视觉上会出现:
- 红 X / 障碍物 / 鱼礁混成一类 icon
### 3. 航标图标根因
- 九州 delivery 样式之前的 `navigation_marks` 图标分支太粗:
- `light_beacon` 固定画 `symbol-daytime-310`
- 普通 `nav-marks` 也没有按 `display_code` 细分浮标 / 灯标样式
- 所以像 `312` 这类灯浮标、以及更细的 `311xxx / 312xxx / 323xxx / 325xxx` 都会回成粗图标
### 4. 已完成修正
- 已把 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) 同步到 `karatsu 20nm final` 的图标口径:
- `hazard-points` 改为优先按 `class_code` 精确分图标
- `anchor-hazard-points-428` 改为优先按 `class_code` 精确分图标
- `nav-light-flare` 改为和 `display_code` / `minor_light` 口径一致
- `nav-marks-light-beacons` 改为按 `display_code` 细分 `311xxx`
- `nav-marks` 改为按 `display_code` 细分 `312/313/323/325/327/328` 等图标
- 并补上 `lattice_buoy / pillar_buoy / can_buoy` 的 canonical fallback
- 已继续补上 `facility_boundary_point` 的设施点图标逻辑:
- 不再固定画 `symbol-daytime-520`
- 改为按 `class_code` 区分:
- `505 / 510 -> symbol-daytime-505`
- `520 -> symbol-daytime-520`
- `530 -> symbol-daytime-530`
- `540 -> symbol-daytime-540`
- `550 -> symbol-daytime-550`
### 5. 已部署
- 已部署新的九州样式到:
- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`
- 已同步 bump compare 页版本并部署:
- HTML 版本:`compare-r22-20260405-0910`
- 九州 style 版本:`kyushu-style-r4-20260405-0910`
- HTML 路径:`/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`
### 6. 继续补到的小灯图标问题
- 新发现九州还有一类 `minor_light` 小灯点位图标不对
- 代表点位:
- `display_code = 30600000`
- delivery 中当前对象属性显示为:
- `canonical_object_type = minor_light`
- `chart_symbol_code = light_beacon`
- `chart_icon_image = symbol-daytime-310`
- 旧原始样式中:
- `30600000 -> symbol-daytime-303`
- 说明:
- 这类点位不只是 style 旧逻辑问题
- 也暴露出 builder 对部分 `minor_light` / `light_beacon` 的图标推断偏粗
- 当前先在九州 style 层做了旧版兼容兜底:
- `nav-marks-small-lights` 改为按 `display_code` 细分:
- `303xxx`
- `305xxx`
- `306xxx`
- `307xxx`
- `308xxx`
- `309xxx`
- 先恢复到原始样式的图标表现
### 7. builder 侧已继续收口
- 已在 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py) 中继续修正 `navigation_marks` 的图标生成逻辑:
- 新增一组按旧 `display_code` 直接映射图标的 builder 内部表
- 当前先覆盖:
- `303xxx`
- `305xxx`
- `306xxx`
- `307xxx`
- `308xxx`
- `309xxx`
- 已把原始 `canonical_object_type = 灯 (Lt)` 的语义判断单独识别为:
- `chart_symbol_code = minor_light`
不再先落到 `light_beacon`
- 单瓦片验证结果已确认:
- `display_code = 30600000`
- 现在 builder 直接产出:
- `chart_symbol_code = minor_light`
- `chart_icon_image = symbol-daytime-303`
### 8. 当前已重跑的 builder 会话
- 已重新启动:
- `kyushu delivery`: session `80537`
- `kyushu engineering`: session `73505`
- 目的:
- 让九州现网 compare 不只依赖 style 兜底
- 同时把新的 builder 图标推断真正写回 delivery / engineering PBF
## 下一步
1. 在固定 compare 页上复查:
- 浮标不再被错误套圈
- `420` 不再回成眼睛图标
2. 继续清理其他依赖 `class_code / display_code` 的细分类图标问题
3. 继续完成 20nm canonical 副本的全量 replay并确认
- `canonical_object_type` 非 ASCII 残留归零或收敛到明确尾项
4. 如需上线这轮 canonical 去日文结果:
- 先决定是否同时重放 20nm final PBF
- 再决定是否同步部署 compare 用 style / 页面版本号
## 快速续接提示
下次继续时,先做这几件事:
1. 确认页面顶部版本仍然是 `compare-r18 / style-r14 / pbf-fullrefresh1`
2. 继续从博多港和中央航路这类热点回扫细分类图标
3. 优先检查仍依赖 `display_code / class_code` 的对象组
## 2026-04-05 九州 `at` 规则回扫
### 1. 对今天几类错位的统一判断
- 本轮重新对了原始 [`style.json`](/root/sourceserver/pbf/src/pbf/style.json) 后,已确认今天几类错位的共同根因是:
- 之前仍在用“归一语义字段优先”的方式补样式
- 但原始 `at` 图层实际是“旧字段直驱”
- 本轮重新钉实的规则:
- `p航行危険障害物` / `p投錨注意障害物`:按 `分類番号`
- `p錨泊地等`:按 `分類番号`
- `p施設・境界線等` 点要素:按 `分類番号`
- `p航路標識群` 主图标:按 `表示用番号`
- `p航路標識群フレア`:按 `形状分類番号`
- `p陸上構造物`:按 `分類番号` 直接拼 `symbol-daytime-*`
### 2. 本轮已修改的 delivery / style 逻辑
- 已修改 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
- `anchorage-symbols` 改为优先按 `class_code` 直出 `719/720/721/724`
- `nav-light-flare` 改为优先按 `shape_class_code` 命中原始 flare 允许集合,仅在缺字段时退回旧兼容分支
- `nav-marks-harbor-lighthouses` / `nav-marks-breakwater-lighthouses` / `nav-marks-small-lights` / `nav-marks-light-beacons`
- 过滤条件改为优先按 `display_code` 前缀分层
- 仅在缺 `display_code` 时退回 `canonical_object_type`
- `nav-marks` 主层过滤同步改为排除这些 `display_code` 前缀,而不再只靠 `canonical_object_type`
- `facility-points` 保持按 `class_code` 分图标,并补上 `icon-ignore-placement`
- 补回 `pilot-station-points`
- `landmark-points` 改为优先按 `class_code` 直接拼 `symbol-daytime-*`
- `landmark-point-fallback` 只对缺 `class_code` 且不在已知旧图标类中的对象保留圆点兜底
### 3. 本轮已修改的 builder / 字段保留逻辑
- 已修改 [`navsea_tile_builder.py`](/root/sourceserver/pbf/navsea_tile_builder.py)
- `FINAL_RELEASE_PROPERTY_ALLOWLIST` 新增 `shape_class_code`
- `--release-minimal` 口径现在也会保留 `shape_class_code`
- 已修改 [`tasks/pbf/mappings/navsea_field_name_rules_v1.yaml`](/root/sourceserver/pbf/tasks/pbf/mappings/navsea_field_name_rules_v1.yaml)
- `形状分類番号 -> shape_class_code` 改为 `keep_in_delivery: true`
- 目的:
- 让 delivery PBF 重新具备支撑原始 `at` 规则的最小旧字段
- 不再让 `航路標識群フレア` 只能靠 `display_code + canonical_object_type`
### 4. 本轮已部署版本
- compare HTML 已 bump 并部署:
- `HTML: compare-r23-20260405-1533`
- 路径:`/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html`
- 九州 style 已 bump 并部署:
- `Style: kyushu-style-r5-20260405-1533`
- 路径:`/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json`
### 5. 本轮已重新启动九州重建
- 使用仓库虚拟环境 `.venv/bin/python`
- 直接用系统 `python3` 会报:
- `ModuleNotFoundError: No module named 'mapbox_vector_tile'`
- 已重新启动:
- `kyushu delivery`: session `6078`
- `kyushu engineering`: session `63691`
- 当前目标:
- 把新的 `shape_class_code``at` 修正真正写回九州 delivery / engineering PBF
### 6. 下一步
1. 等待九州两套 builder 完成
2. 抽查热点瓦片,确认 delivery 内已出现 `shape_class_code`
3. 在固定 compare 页继续复查今天提到的几类同源错位点
## 2026-04-05 九州 delivery 双用途图层整理
### 1. 本轮新增整理文档
- 已新增:
- [`NavSea_九州_Delivery_双用途图层分类_2026-04-05.md`](/root/sourceserver/pbf/NavSea_九州_Delivery_双用途图层分类_2026-04-05.md)
### 2. 本轮整理目标
- 不再只按旧样式/旧图层名字理解九州 delivery
- 改为按两个业务目标重新归类当前实际图层:
1. 航海用
2. 钓鱼用
### 3. 本轮整理结论
- 航海用的核心方向已明确为:
- 危险物优先
- 障碍物优先
- 导助航优先
- 净空/设施/锚地等通航约束优先
- 水深细节退后
- 钓鱼用的核心方向已明确为:
- 海底地形优先
- 水深细节优先
- 底质优先
- 鱼礁 / 穴 / 海底结构优先
- 安全层只保底不抢主视觉
### 4. 当前建议的实施方式
- 建议后续不要继续只维护一套 delivery style
- 而是同一套 PBF 下拆成两个 profile
1. `delivery-navigation`
2. `delivery-fishing`
- 先拆 style不急着拆数据
## 2026-04-07 九州 delivery 按对象属性分组整理
### 1. 本轮新增整理文档
- 已新增:
- [`NavSea_九州_Delivery_对象属性分组_2026-04-07.md`](/root/sourceserver/pbf/NavSea_九州_Delivery_对象属性分组_2026-04-07.md)
### 2. 本轮整理目标
- 不再按“航海用 / 钓鱼用”分
- 改为按对象属性相同的 group 整理当前九州 delivery
- 目标是给后续 style 重排、profile 拆分、专题层拆分打基础
### 3. 本轮已整理的主要 group
- 等深线
- 鱼礁
- 灯塔
- 港口灯
- 渔网 / 渔具
- 海上标识
- 陆地设施
- 桥梁 / 跨空线
- 海底质
- 海底危险物
- 锚地
- 引航 / 航海服务
- 陆海背景与海岸线
- 地名与定位参考
### 4. 本轮结论
- 当前最值得继续细拆的 group 已确认是:
1. 海底危险物
2. 海上标识
3. 陆地设施
4. 海底质
- 这四组最适合作为下一步 style 结构重排和多 profile 组织的主切口
## 2026-04-07 九州 delivery 前端图层分组消费配置
### 1. 本轮新增配置文件
- 已新增:
- [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json)
### 2. 本轮配置目的
- 给前端一个可直接消费的图层分组配置
- 不再让前端直接理解 style 内部的全部 render layer
- 让前端只面对:
- 基础底图
- 可切换业务 group
- 航海 / 钓鱼 / 自定义预设
### 3. 当前配置内容
- 已包含:
- `base_groups`
- `groups`
- `presets`
- 当前主要业务 group 包括:
- 鱼礁/海底危险物
- 海上标识
- 锚地/引航
- 港口与设施
- 桥梁/净空
- 等深线
- 海底地形
- 渔网/渔具
- 海底质
- 地名
### 4. 当前建议的前端消费方式
- 前端用 group 配置驱动 UI不直接暴露底层 render layer
- 实际切换时,通过:
- `map.setLayoutProperty(layerId, "visibility", "visible" | "none")`
- 建议用户入口只暴露:
- 航海模式
- 钓鱼模式
- 自定义
### 5. 本轮 i18n 结构调整
- 已把 [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json) 从直接写死中文 `label` 的结构,调整为:
- `label_key`
- `description_key`
- `i18n`
- 当前 key 命名已统一成:
- `pbf.group.xxx`
- `pbf.preset.xxx`
- 这样前端可以:
- 先直接读同文件内的 `i18n`
- 后续再平滑迁移到统一翻译系统
### 6. 本轮前端配置字段扩展
- 已继续给 [`src/pbf/layer-groups.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/layer-groups.navsea-delivery-kyushu.json) 增加:
- `sort_order`
- `icon_key`
- `feature_flag`
- 当前作用:
- `sort_order`
- 控制前端菜单展示顺序
- `icon_key`
- 让前端图标系统不必写死在代码里
- `feature_flag`
- 方便做灰度、AB、权限或版本开关控制
## 2026-04-08 全国 delivery 候选构建与严格审计启动
### 1. 当前目标
- 用户要求:
- 生成全国范围 delivery 版本
- 严格审计
- 本轮采取的口径:
- 先生成全国候选目录
- 不直接覆盖现网旧目录
- 先跑对象保真 + render-hit 两层严格审计
- 审计过后再决定是否切正式目录
### 2. 当前确认的全国构建方式
- `navsea_tile_builder.py` 已确认支持:
- `--all-tiles`
- 当前全国原始源目录文件总量是:
- `/home/wwwroot/newpec/exported_auto/tile.mapple-on.jp__newpec-mvt-20260106__z___x___y_.pbf/tiles`
- 全量文件数:`79229`
- 当前旧全国目录状态:
- `/home/wwwroot/pbf``65148`
- `/home/wwwroot/pbf-engineering-full``65148`
- 说明:
- 旧全国 full 目录不是当前源集合的完整重放结果
- 因此本轮不能直接把旧目录当作可交付全国版
### 3. 本轮全国候选输出目录
- delivery 候选:
- `/home/wwwroot/pbf-delivery-full-20260408`
- engineering 候选:
- `/home/wwwroot/pbf-engineering-full-20260408`
### 4. 本轮已启动的全国构建会话
- 使用仓库虚拟环境:
- `.venv/bin/python`
- 已启动:
- 全国 deliverysession `8644`
- 全国 engineeringsession `60378`
- 使用参数:
- `--all-tiles`
- `--fid-key thisMyWorld@2026`
- `--bundle-id navsea-core`
- delivery 附带:`--release-minimal`
- engineering 附带:`--engineering`
### 5. 当前已观察到的风险信号
- builder 已确认拿到的全国 tile job 数:
- `79229`
- 但构建过程中已出现大量:
- `skipped z/x/y`
- 这说明:
- 全国源瓦片不等于全国 delivery 可写出瓦片
- 严格审计第一层就必须先检查文件集合与对象保真
- 很可能会暴露出:
- 数据库候选缺失
- 某些原始瓦片无可输出 rows
- 全量覆盖不完整
### 6. 本轮严格审计计划
- 第一层:
- 文件集合 / 覆盖率检查
- 第二层:
- 全国对象保真审计
- 第三层:
- 全国 render-hit 审计
- 当前说明:
- 现有审计脚本默认口径偏 10nm / 20nm / kyushu
- 本轮会在全国候选目录构建完成后,按全国路径重定向运行
- 审计输出文档仍需单独整理成中文放行报告
### 7. 下一步
1. 等待全国 delivery / engineering 候选构建完成
2. 先做全国文件集合对齐检查
3. 运行全国对象保真审计
4. 运行全国 render-hit 审计
5. 输出中文严格审计报告并给出是否可交付结论
## 2026-04-08 delivery style sprite 统一
### 1. 本轮调整
- 按用户要求,把 delivery style 的 sprite 地址统一改为:
- `http://192.168.200.184/newpec/sprite/sprite?v=111`
### 2. 当前已修改的仓库文件
- [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json)
- [`src/pbf/style.navsea-delivery-karatsu-20nm-final.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-20nm-final.json)
- [`src/pbf/style.navsea-delivery-karatsu-10nm.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-karatsu-10nm.json)
### 3. 当前说明
- 仓库内源文件已完成统一
- 线上 `/mnt/sda1/www/newpec/domain/` 下的部署文件尚未在本轮同步
- 后续如需页面立即生效,还需要再做一次部署同步
## 2026-04-08 全国 delivery style 草稿
### 1. 本轮新增文件
- 已新增:
- [`src/pbf/style.navsea-delivery-full.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-full.json)
### 2. 本轮生成方式
- 以 [`src/pbf/style.navsea-delivery-kyushu.json`](/root/sourceserver/pbf/src/pbf/style.navsea-delivery-kyushu.json) 为底复制
- 仅调整:
- `name -> NavSea Delivery Full`
- `tiles -> http://192.168.200.184/pbf-delivery-full-20260408/{z}/{x}/{y}.pbf`
### 3. 当前说明
- 这是当前全国 delivery 候选 PBF 的配套 style 草稿
- 当前尚未单独部署到线上公开路径
- 当前也还没有配套的全国单屏 HTML / compare 页面
## 2026-04-08 全国 delivery style / HTML 部署
### 1. 本轮部署文件
- 已部署 style
- `/mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json`
- 已部署 HTML
- `/mnt/sda1/www/newpec/navsea-final-delivery-full.html`
### 2. 当前可访问 URL
- style
- `http://192.168.200.184/newpec/domain/style.navsea-delivery-full.json`
- 单页查看:
- `http://192.168.200.184/newpec/navsea-final-delivery-full.html`
### 3. 当前说明
- 全国版 style 现已不只是仓库草稿,已同步到线上公开路径。
- 当前 HTML 为单屏查看入口,不是 compare 页面。
## 2026-04-08 磁盘风险全量快照提交
### 1. 触发原因
- 用户反馈当前电脑硬盘可能存在问题
- 为避免本地未提交代码与文档因磁盘异常丢失,本轮优先执行一次仓库内全量快照提交
### 2. 本轮执行前确认
- 已按仓库续接要求复读:
- `STEP_RECORD.md`
- `PROJECT_HANDOFF_2026-03-31.md`
- `NavSea_Delivery_Preflight_Audit_Spec.md`
- `NavSea_Audit_Logic_And_Evolution_2026-04-01.md`
- 已确认当前远端仍是:
- `ssh://git@nas:2222/tei/pbf.git`
- 已确认当前工作区包含大量:
- 已修改代码
- 新增 Domain 原型文件
- 新增审计报告
- 新增页面与 style 草稿
### 3. 本轮处理原则
- 本轮目标是“先保全当前仓库进展”
- 因用户明确要求提交所有代码,本轮采用全量暂存与提交
- 本轮提交不额外声称:
- 已完成新的全国审计
- 已完成新的交付放行结论
### 4. 当前说明
- 提交完成后,仓库历史中应保留一份可回溯的本地快照
- 若后续硬盘继续异常,优先再确认远端可推送与备份介质状态