Files
pbf/docs/报告/20261013_NavSea_PBF全国Full生产链溯源调查_v1.md

12 KiB
Raw Permalink Blame History

NavSea PBF 全国 Full 标准生产链溯源调查 v1

  • 调查日期:2026-10-13
  • 调查环境:X220 / Ubuntu Linux;工程目录 /root/sourceserver/pbf
  • 调查性质:只读追溯历史生产代码、原始分片、合并目录及公网交付物;未重建、未替换生产 PBF、未切换 Git 分支或 Worktree
  • 当前工程仓库:main,调查起点 HEAD 1fef4c6dd12a21d4228b39d67d569a660b149a03,远端 ssh://git@nas:2222/tei/pbf.git
  • 权威标准决定:2026-10-13 用户明确指定公网全国 Full PBF 为 NavSea PBF 标准,必须找到实际生成该公网数据的生产链,不得仅凭名称选择最新脚本或本地同名目录。

一、最终结论(优先阅读)

正确的历史生产流水线为 2026-04-18 全国 Full 四段分片生成流水线。

  1. 代码属地:/root/sourceserver/pbf;历史生成代码固定在 Git commit 6d72340f364ee0c9020df8de7ede6a2e1a0621b0,主要程序 navsea_tile_builder.py、navsea_mapping_registry.py、tasks/pbf/mappings/。
  2. 输入原始数据:/home/wwwroot/newpec/exported_auto/tile.mapple-on.jp__newpec-mvt-20260106__z___x___y_.pbf/tiles。
  3. 语义数据:MySQL pbf_analysis;映射规则包 navsea-core。
  4. Reference footprint:/home/wwwroot/pbf-delivery-full-20260415;只指定 z/x/y 覆盖范围,不是新瓦片几何或业务属性的内容来源。
  5. 实际生产原始分片目录(保留至今):/home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/,包含 z0_8/、z9_10/、z11/、z12/。
  6. 2026-04-18 合并交付目录原为 /home/wwwroot/pbf-delivery-full-20260418-rebuild/。用户确认最终版本从此工程生产后被复制至公网。
  7. 真正的公开对照:https://pbf.jpcn.ccwu.cc/pbf/pbf-delivery-full-20260418-rebuild/{z}/{x}/{y}.pbf。
  8. 当前同名本地合并目录中部分文件已发生后续变化;对照公网应优先取原始 .parts 分片,不能直接以当前同名合并目录为“2026-04-18 原始字节基线”。

结论证据包含:完整的 2026-06-11 历史重建说明、STEP_RECORD 历史记录、4 份分片 mapping audit、现存分片文件、8 个公网/原始分片 SHA-256 一致样本,以及 2026-08-08 hardlink inode 检查。尚未逐一下载/比较全国 65,148 张公网瓦片,不能声称全量字节一致。

二、2026-04-18 生产流水线

X220 /root/sourceserver/pbf
  历史代码:Git 6d72340
  ├─ navsea_tile_builder.py
  ├─ navsea_mapping_registry.py
  └─ tasks/pbf/mappings/
             │
NewPEC 全国原始 PBF ─┬─ MySQL pbf_analysis / navsea-core
                     │
20260415 reference ──┴──仅约束输出瓦片覆盖坐标
                     │
              四段独立生成
                     │
/home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/
  ├─ z0_8/   (344)
  ├─ z9_10/  (3,969)
  ├─ z11/    (12,279)
  └─ z12/    (48,556)
                     │
        按相互不重叠的 zoom 合并
                     │
/home/wwwroot/pbf-delivery-full-20260418-rebuild/
          (历史合并目录,现已部分变化)
                     │
              用户复制发布
                     │
https://pbf.jpcn.ccwu.cc/pbf/
pbf-delivery-full-20260418-rebuild/{z}/{x}/{y}.pbf

历史重建入口权威文档:NavSea_全国完整PBF重建流水线说明.md(最后确认 2026-06-11)。

该文档固定的共同参数为:--strip-legacy-japanese-delivery、--release-minimal、--fid-key、--bundle-id navsea-core,且固定历史代码。FID key 的实际历史参数值应从上述受控源文档或受控执行配置取得,不在新文档重复扩散。

原工程里的 navsea_rebuild_hotspot_tiles.py 只用于 AOI 热点定位,不是正式全国生产入口;后续 src/Domain/、semantic unified、九州测试和 Provider Package 都不能未经批准替代这一生产基线。

分片数量与审计原文件

分片目录 实际 mapping audit 记录 written_tiles 对应审计文件
z0_8 344 z0_8.mapping_audit.json、.md
z9_10 3,969 z9_10.mapping_audit.json、.md
z11 12,279 z11.mapping_audit.json、.md
z12 48,556 z12.mapping_audit.json、.md
合计 65,148 历史全国 Full 范围

以上 4 套实际审计文件保存在 /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/,其中 bundle_id=navsea-core 且 output_root 指向对应实际分片目录。

历史合并后 zoom 分布:z0=1、z5=10、z6=27、z7=76、z8=230、z9=813、z10=3156、z11=12279、z12=48556;z1–z4 未生成相应瓦片。

三、公网文件反向校验(2026-10-13)

比较方法:在 X220 上对公开 HTTP GET 响应和本地 .parts 文件分别做 SHA-256;使用相同 z/x/y.pbf。抽查覆盖全部有输出的 zoom 段中的多个等级。

瓦片 所属原始分片 公网与原始分片 SHA-256
0/0/0.pbf z0_8 MATCH 32d19b773a93ef038c13766b8e36fd586d9919d5c524c68e39468b7d54445d41
5/27/14.pbf z0_8 MATCH 281788adf614be91fe8b8801438f2f9a4ee15d1efdefec49d2f2527ca63e8c54
8/234/91.pbf z0_8 MATCH 3e108574b386081de755ee81ca572e9d5988f655935c770a8b201c2cbb58a4e1
9/431/216.pbf z9_10 MATCH 4b2d5032be354cce7eab24693377f7ace1351666f324b3229ad9c32697edd3c7
10/910/441.pbf z9_10 MATCH 5243fe8af421224cde897044546c0edc70cc972717f621713f81a308f0539eec
11/1764/859.pbf z11 MATCH a044b23d56bb6a9ecebff7c9ab63fb25a7928d450fb4c5991f887aa46ca06263
12/3632/1620.pbf z12 MATCH 34ca18e6a27ffc4db4dd759ca0baf64eb83da51bc28ccef4ebe74493c405db8b
12/3525/1643.pbf z12 MATCH 0386cc54d8db71b9af77300267bad75148fc7a125976067335bb9645f9b35be4

额外确认:12/3525/1643.pbf 在 pbf-delivery-full-20260418-staging-z12 与 pbf-delivery-full-20260408 的本地样本也与公网一致;仅凭单个文件一致不能认定这些更早目录就是最终生产路径。有完整 4 分片审计与文档支撑的生产源仍是 20260418-rebuild.parts。

当前同名目录为什么不可作原始字节对照

样本 12/3525/1643.pbf:

  • 公网:98,160 bytes,SHA-256 0386cc54…。
  • 原始 .parts/z12/:98,160 bytes,SHA-256 0386cc54…,文件 mtime 为 2026-04-18。
  • 目前 /home/wwwroot/pbf-delivery-full-20260418-rebuild/:98,149 bytes,SHA-256 794fc6e9…,文件 mtime 为 2026-08-08 22:48:33 (+08:00)。
  • 当前合并目录该样本与 /home/wwwroot/pbf-delivery-full-semantic-unified-20260808/ 样本 inode 均为 14055745,link count=2,确认二者是硬链接。
  • navsea_reencode_unified_semantic_pbf.py 定义以同名合并目录为 BASE_ROOT,以 semantic-unified-20260808 为 OUTPUT_ROOT,并通过 cp -al 建立硬链接,再对选中目标解除链接重编码。这证明两套目录之间存在共享 inode 风险,但不能仅凭样本反推每一次实际修改由哪个进程写入。
  • 对 8 个样本进行 .parts 与当前合并目录比较:8/234/91.pbf 和 12/3525/1643.pbf 已不同;其他 6 个一致。因此“部分改变”有直接证据,而非推测。

历史重建文档所述的“业务结构等价”不要求 SHA-256 全相同,但这次反向找生产路径采取字节一致校验,辨识实际仍存的原始分片。二者不是矛盾的验收标准。

四、历史沿革(已查证节点)

  1. 2026-04-08 前后:存在更早的 pbf-delivery-full-20260408 与工程版,是本轮溯源中的前驱/对照,不自动作为正式四段流水线。
  2. 2026-04-15:全国 pbf-delivery-full-20260415 留作 reference footprint;后续不能误写成正式重建内容源。
  3. 2026-04-18:历史固定代码 6d72340 修复高 extent reencoding 风险;基于 NewPEC + MySQL + navsea-core,按四段重建并合并全国 65,148 张,执行几何、native 和固定 AOI 审计。
  4. 2026-06-11:写成 NavSea_全国完整PBF重建流水线说明.md,固定代码、数据源、分片参数、审计顺序和候选目录发布法;明确不覆盖原基线。
  5. 2026-08-06~08:在既有 Full PBF 上进行语义图标、Style、Sprite 分析与 semantic-unified-20260808 派生;此阶段发生的硬链接共享和当前本地样本 mtime 提示原合并目录不再是可靠的原始字节快照。
  6. 2026-10-13:用户指定已发布的公网全国 Full 为权威标准;反向调查以多个缩放等级的 SHA-256 校验定位到现存 .parts 原始分片,澄清“同名本地合并目录”与“公网实际交付内容”的差异。

说明:公网部署采用何种 cp/rsync 具体命令、实际复制时间及服务器磁盘目标位置,当前缺乏独立的命令日志;“从此工程生成后 copy 到公网”是用户确认的事实,不应伪造进一步的部署路径。

五、历史验收与未来修改门禁

相关现存审计入口:

  • navsea_object_preservation_audit.py:对象保全(FID/对象类型/几何来源需可追溯)。
  • navsea_render_audit.py:渲染命中、Style 消费及语义对照。
  • navsea_geometry_native_audit.py、navsea_extent_shift_audit.py、navsea_tile_reencode_guard.py:几何/extent/native 风险。
  • navsea_full_aoi_visual_audit.py:全国 AOI 截图和差异。
  • report/full_rebuild_final_geometry_2026-04-18/ 与 report/full_rebuild_final_aoi_visual_2026-04-18/:历史生成期间的审核资料。
  • src/pbf/style.navsea-delivery-full-semantic-extentfix.json、/newpec/sprite-semantic/sprite:2026-08-06 文档确立的全国 Full 显示组合;Style/Sprite 与 PBF 生产流水线是不同层次,不能把较新 UI 样式当成较新 PBF 生产源。

必须按 对象保全 → Render/geometry/extent → 全国 AOI 人工视觉 的顺序验收。需要新生产版本时:

  1. 先确认历史固定 Git 树与实际 DB/原始数据是否仍可用;不要用当前 HEAD navsea_tile_builder.py 覆盖历史含义,后续修改的功能必须单独验证。
  2. 先把基线与候选的 Style、规则包、原始 PBF、数据库状态、参考覆盖清单固定;数据库未做本轮只读一致性查询,不能声称当前数据库与 2026-04-18 完全相同。
  3. 只在新的候选目录生成。Builder 会清理目标目录旧 PBF,绝不可指向正式交付目录或现存 .parts。
  4. 对象、properties、geometry、extent、source-layer、NavSea FID 和截图对照均通过后,提交新版本审计报告给用户确认;未经用户批准不替换正式 URL、Style 或硬链接目录。
  5. 不在没有用户批准的情况下执行仓库新建/切换分支或 Worktree,不执行重建/覆盖生产数据。
  6. 不把工程目录 src/pbf 下的大量生成 GeoJSON、out/ SQLite/BIN、原始 ZIP 或全国 PBF 瓦片加入 Git;它们是数据、临时输出或生产结果,不能代替历史可复现源码与文档。

六、与 PbfProvider 项目的边界

2026-10-13 已有 PBF_PROVIDER_MIGRATED.md 明确:Provider 自己的 PBF/Style/Sprite 分析、视觉确认与 Package 生产迁出至独立仓库 https://git.eyaku.jp/tei/PbfProvider。这是新架构的职责划分,不改变本报告追溯的 pbf 仓库在 2026-04-18 生成 NewPEC 全国 Full PBF 的历史事实。不得从当前 Provider Package 反推它才是该公网 PBF 的生产路径。

七、证据、限制与交接要点

证据文件:

  • 8 份原始分片 mapping audit 已按原字节复制归档:docs/报告/20261013_全国Full生产分片历史审计证据/(4 段 × JSON/Markdown,SHA-256 已与原文件逐份核对);源文件仍留在 /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/。
  • NavSea_全国完整PBF重建流水线说明.md
  • STEP_RECORD.md:2026-04-18、2026-06-11、2026-08-06、2026-08-08 各阶段记录
  • /home/wwwroot/pbf-delivery-full-20260418-rebuild.parts/*.mapping_audit.json 及配套 Markdown
  • navsea_reencode_unified_semantic_pbf.py
  • Git 原提交 6d72340 与现有 main HEAD 历史

本次未进行:全量公网 65,148 文件比较、数据库重建/一致性验证、实际重新构建、MySQL 变更、生产部署、Git Worktree 切换。历史报告中的对象审计覆盖范围也不能无条件等同于全部要素。

下次继续工作的最短读法:先读本报告 → NavSea_全国完整PBF重建流水线说明.md → STEP_RECORD.md 历史相关段落 → 4 份 mapping audit → 在公开 URL 与原始 .parts 上做新样本核验 → 再决定是否修改代码。切勿把更名后的本地同名目录当成未经修改的字节金本位。