pbf/tasks/route/Q1_answer.md

NavSea 航线规划 Q1 答复

本文基于当前仓库内已经落地的 builder、域模型、样式、审计报告和步骤记录来回答 Q1.md。

本文刻意区分三种口径：

• 仓库已证实：当前代码、文档或审计报告已经能直接证明
• 当前谨慎判断：从现有实现可以较强推断，但还没有单独审计报告把它钉死
• 仍需上游 PBF 生产侧确认：当前仓库里没有找到足够证据，不能替对方承诺

0. 结论先行

先给结论：

1. 当前多 zoom PBF 设计首先是为交付渲染服务，但并不只是“显示专用”。
   • 仓库文档把 delivery tiles 的用途写成：正式渲染、检索、碰撞检测，而不是只服务样式显示。tasks/pbf/NavSea_tile_generation_pipeline_v2.md
2. 当前 NavSea builder 本身没有额外做面/线/点的低 zoom 特化删减、聚合、合并或几何简化逻辑。
   • 它是按现有 z/x/y 原始瓦片读入，再把 feature 映射到新 layer，并明确要求“不改变 feature geometry”“保持原 layer extent 不变”。tasks/pbf/NavSea_tile_generation_pipeline_v2.md tasks/pbf/NavSea_tile_generation_pipeline_v2.md
3. 但是，这不等于低 zoom 一定适合规划。
   • 当前 builder 继承的是“上游原始多 zoom 瓦片”本身的内容；如果上游原始 z5/z6/z7/z8 已经做过 generalization、筛选或省略，当前仓库不会把它恢复回来。
4. 站在当前仓库证据上，给航线规划的保守建议是：
   • 统一规划可用 zoom 区间：z10-z12
   • 最保守可靠：z12
   • 低于 z9：不建议作为单独规划依据
5. land_area 可以作为陆地主判定层，但 onshore_structure_*、baseline_* 不能替代 land_area 做陆海二分。
   • 这是域模型里的硬规则。NavSea_Chart_Domain_Model_v1.md
6. 当前最应该警惕的不是“画得像不像”，而是“对象有没有丢、ID 有没有丢、低 zoom 有没有被上游省略”。
   • 当前正式审计口径第一优先级是 object preservation。NavSea_Audit_Logic_And_Evolution_2026-04-01.md

1. 对总原则问题的回答

1.1 当前 PBF 多 zoom 设计主要是为显示服务，还是也考虑规划/空间分析？

回答：

• 仓库已证实：当前主目标是交付渲染链路，但并未把数据用途限定为“只给样式显示”。
• 仓库已证实：delivery tiles 的目标还包括检索和碰撞检测。tasks/pbf/NavSea_tile_generation_pipeline_v2.md
• 当前谨慎判断：这说明当前数据结构已经部分考虑了“显示以外的消费”，但还没有形成一套正式的“规划专用数据视图”。
• 仍需上游确认：上游原始多 zoom 瓦片是否在生产阶段明确考虑过路径规划/空间分析，目前仓库里没有直接说明。

1.2 对航线规划，是否存在“关键障碍语义完整可用”的 zoom 范围？

回答：

• 当前谨慎判断：当前最稳妥的工作区间是 z10-z12。
• 当前谨慎判断：如果只能给一个最保守值，建议用 z12。
• 依据：
  • 当前交付/Domain 矢量源都提供到 maxzoom=12。src/pbf/style.navsea-delivery-karatsu-10nm.json src/Domain/style.domain-karatsu-10nm.json
  • 当前仓库内部 AOI 视觉审计重点也是 zoom 10 / 12。STEP_RECORD.md
  • 当前危险点对象在 final_20nm 审计样区中已验证可按对象回对且 ID 未丢。report/object_preservation_20nm/object_preservation_final_20nm.md
• 仍需上游确认：land_area 在低 zoom 是否会封死狭水道、小港口入口、小岛间通道，单靠当前仓库无法替上游作最终承诺。

1.3 是否可以提供“规划可用数据视图”或“规划专用规则”？

回答：

• 仓库已证实：当前正式生产线里还没有一条稳定发布的“规划专用输出”。
• 仓库已证实：Domain 线路已经把安全层和细节层拆成 safety/detail 两包，这为规划专用视图打下了结构基础。NavSea_Chart_Domain_Model_v1.md src/Domain/build_chart_domain_tiles.py
• 当前谨慎判断：最容易落地的方向不是重做一套新格式，而是在现有 safety 包基础上增加“规划保真规则”。
• 建议优先级：
  • 第一优先：给关键规划层加“不得因显示优化而消失”的保真规则
  • 第二优先：额外出一套 planning-safe 视图
  • 第三优先：至少对外给出明确的 min usable zoom

2. 当前仓库能确认的 zoom/过滤/几何规则

先说最重要的一条：

• 不要把“样式里的 minzoom”误当成“数据在该 zoom 以下不存在”。
• 当前样式里的 minzoom 只说明“这个符号/文字从哪个级别开始画出来”，不能反推数据层已经被删掉。
• 当前 builder 给 feature 赋的 chart_visibility_min/max 也是渲染可见性语义，不是上游瓦片生产的删减规则。navsea_tile_builder.py

对你关心的目标 layer，当前仓库能直接确认的是：

1. builder 侧没有发现针对这些 layer 的“按最小面积删面”“按最小长度删线”“按重要性删点”的单独规则。
2. builder 侧没有发现“近邻点聚合”“小面合并成大面”“重新简化 polygon 边界”的逻辑。
3. builder 侧编码输出时直接复用源 feature geometry，并保留源 layer extent。navsea_tile_builder.py
4. 因此，如果低 zoom 出现对象消失、边界封口、细小危险区没了，当前更应该先怀疑“上游原始多 zoom 瓦片”的生产规则，而不是当前 NavSea 重映射 builder。

3. 逐层答复

下表回答的是“当前仓库角度下，哪些已证实、哪些仍待上游确认，以及给规划的使用建议”。

layer	当前仓库已证实	规划建议	仍需上游确认
land_area	是陆海二分唯一主来源；builder 不额外改几何、不改单层 extent	作为陆地主阻塞来源使用；规划建议 z10-z12，保守用 z12	低 zoom 是否封死狭水道、抹平港口入口、小岛通道消失
navigation_hazard_area	属于 safety_core；builder 未见额外删面/合面规则	面状危险区规划建议 z10-z12	低 zoom 原始源瓦片是否已对小面危险区做省略
navigation_hazard_point	属于 safety_core；final_20nm 点对象保全审计已验证样区内对象/ID 保留	点状危险物建议至少 z10，保守用 z12	低 zoom 原始源瓦片是否删小点或按重要性筛掉
anchor_caution_hazard_area	属于 safety_extended；当前未见 builder 额外删面	如纳入阻塞，建议与核心危险层同样按 z10-z12 使用	上游是否对小面积注意区做低 zoom 省略
anchor_caution_hazard_point	final_20nm 点对象保全审计已验证样区内对象/ID 保留	至少 z10，保守 z12	低 zoom 是否按重要性省略
submerged_reef_area	属于 safety_core；语义上应视为危险地形	近岸规划建议 z10-z12，优先 z12	低 zoom 是否因 generalization 造成边界退化或小面消失
fixed_fishing_gear_area	属于 safety_core；当前未见 builder 额外删面/合面	如要避让渔具区，建议 z10-z12	低 zoom 是否省略小面积渔具区
onshore_structure_area	属于 safety_extended；不是陆海主判定层	只做岸边环境辅助，不做陆地主阻塞替代	上游低 zoom 是否保留完整、是否有结构物简化

4. 对 land_area 的重点回答

4.1 land_area 是否可能因 generalization 导致狭水道被封死？

回答：

• 当前谨慎判断：存在这个风险，尤其是在 z9 以下。
• 不是因为当前 NavSea builder 在做额外封口，而是因为当前链路继承了上游原始多 zoom 瓦片。
• 当前仓库没有找到专门的“狭水道保护”“港口入口保护”“细缝通道保护”规则。
• 所以在没有上游明示承诺之前，不应把低 zoom land_area 当作狭水道通航判定依据。

4.2 从哪个 zoom 开始，land_area 适合用于航线规划？

回答：

• 当前谨慎判断：
  • z12：最保守可靠
  • z10-z12：当前建议的规划工作区间
  • z9 及以下：不建议单独作为陆地主判定依据

4.3 是否存在专门保护规则避免错误封口？

回答：

• 仓库已证实：当前仓库里没有找到这类保护规则。
• 仍需上游确认：如果上游原始瓦片生成器有 land generalization 保护策略，需要由对方明确说明规则。

5. 对危险障碍物的重点回答

5.1 小面积危险区、点状危险物在低 zoom 会不会省略？

回答：

• builder 侧：没有看到额外省略规则。
• 上游原始多 zoom 源：当前仓库不能替其承诺“不省略”。
• 所以正确表述应是：
  • “当前 NavSea 重映射层没有再删一遍”
  • “但低 zoom 是否已经在上游源中被删减，仍需生成侧明确答复”

5.2 是否存在“显示上可省略，但规划上不能省略”的对象？

回答：

• 是，明确存在。
• 至少这些对象属于这类：
  • navigation_hazard_point
  • navigation_hazard_area
  • submerged_reef_area
  • fixed_fishing_gear_area
  • anchor_caution_hazard_point
  • anchor_caution_hazard_area
• 原因：
  • 它们在域模型中被归为 safety_core 或 safety_extended，本身就是航行安全相关对象。NavSea_Chart_Domain_Model_v1.md

5.3 是否能给出“关键危险物语义完整可用”的 zoom 起点？

回答：

• 当前谨慎判断：建议对外先给 z10-z12。
• 如果必须给单点：给 z12。
• 其中：
  • z10 可作为工程上可操作的最小候选起点
  • z12 是当前最保守的规划使用级别

6. 对象 ID 与跨 zoom 一致性

6.1 同一对象在不同 zoom 下是否有稳定 feature id？

回答：

• 仓库已证实：当前系统极度依赖 fid 做对象回对和审计。NavSea_Delivery_Preflight_Audit_Spec.md
• 仓库已证实：输出时如果 fid 可解析，builder 会把它写成输出 feature 的 id。navsea_tile_builder.py navsea_tile_builder.py
• 仓库已证实：engineering 模式还支持可逆的 NavSea fid。navsea_tile_builder.py
• 当前谨慎判断：同一实体跨 zoom 能否始终稳定对齐，前提仍然是该 zoom 的上游源里这个对象没有被删掉、拆掉或聚掉。

6.2 当前实证状态

回答：

• final_20nm 的点类关键层对象保全审计里，p航行危険障害物->navigation_hazard_point 和 p投錨注意障害物->anchor_caution_hazard_point 都已经显示 identifier lost = 0。report/object_preservation_20nm/object_preservation_final_20nm.md
• 但旧 delivery_20nm 曾经出现过 identifier lost = 4165，说明“有无稳定 ID”不是天然成立的，需要明确约束产线。report/object_preservation_20nm/object_preservation_delivery_20nm.md

6.3 结论

• 可以要求规划侧依赖稳定 fid/source id
• 但必须把“关键规划层不得丢 ID”写成生产要求，而不是默认假设

7. area / outline / point 对应关系

回答：

1. 当前这些层更像“并列语义层”，不是一个完整的主从模型。
2. area、outline、point 在当前仓库里没有看到统一的稳定关系字段可直接一一对应。
3. 当前没有证据证明：
   • 某个 area 缺失时，一定还能靠 outline 闭合重构 polygon
4. 因此规划侧应采用：
   • area 作为面阻塞主来源
   • point 作为点阻塞主来源
   • outline/boundary 只做辅助参考

结论：

• 不要依赖 outline 反构 polygon。
• 这条在当前仓库证据下应该直接写死。

8. 推荐给规划使用的最小 zoom

当前建议如下：

layer	建议规划使用区间	最保守级别	不建议使用区间
land_area	z10-z12	z12	z9 及以下
navigation_hazard_area	z10-z12	z12	z8 及以下
navigation_hazard_point	z10-z12	z12	z8 及以下
anchor_caution_hazard_area	z10-z12	z12	z8 及以下
anchor_caution_hazard_point	z10-z12	z12	z8 及以下
submerged_reef_area	z10-z12	z12	z8 及以下
fixed_fishing_gear_area	z10-z12	z12	z8 及以下

说明：

• 这张表是“当前仓库视角下的保守工程建议”，不是对上游瓦片生产规则的最终签字。
• 如果要对外给一个单一口径，建议写成：
  • NavSea 当前规划最小可用 zoom 建议为 z10；最终保守使用 z12。

9. PBF 侧最应该支持的能力

建议优先顺序如下。

9.1 最优方案

提供规划专用保真规则或 planning-safe 视图，至少保证这些层在规划 zoom 上不因显示优化而消失：

• land_area
• navigation_hazard_area
• navigation_hazard_point
• anchor_caution_hazard_area
• anchor_caution_hazard_point
• submerged_reef_area
• fixed_fishing_gear_area

9.2 次优方案

继续用现有多 zoom PBF，但由生成侧明确给出：

1. 每个关键 layer 的最小可用 zoom
2. 这些 zoom 上不会删关键危险物
3. 这些 zoom 上关键属性和 fid 完整保留

9.3 最低可接受方案

至少增加三条规则：

1. 关键 hazard point 强制保留
2. 关键小面积 hazard area 不做低 zoom 删除
3. land_area 增加狭水道/港口入口保护，避免封口

10. 如果后续加水深

当前仓库已经有水深相关语义字段和层：

• depth_contour
• depth_contour_overview
• depth_value_m
• least_depth_m

相关字段归一化在 pipeline 里已经进入设计目标。tasks/pbf/NavSea_tile_generation_pipeline_v2.md

但对规划来说，当前仍然缺：

1. 一个明确的“深度规划采样视图”
2. 不同 zoom 下深度对象是否被上游筛选/简化的正式说明
3. 适合最小水深约束计算的统一口径

11. 最终建议发给 PBF 负责人的一句话版本

可以这样收口：

NavSea 当前重映射 builder 不会再额外简化、聚合或删减关键规划对象，但它继承了上游原始多 zoom 瓦片的内容差异。因此，我们当前建议把 z10-z12 作为规划工作区间、z12 作为最保守级别，并请 PBF 生成侧明确承诺关键 land/hazard 语义在该区间不被省略、fid 稳定保留、outline 不能被当作 polygon 重建替代。

12. 当前可直接执行的工程口径

如果要马上开始做 MVP，而不是继续等口径，建议先按下面执行：

1. 只用 land_area 做陆地主阻塞，不用 onshore_structure_area 替代。
2. 面阻塞使用：
   • land_area
   • navigation_hazard_area
   • anchor_caution_hazard_area
   • submerged_reef_area
   • fixed_fishing_gear_area
3. 点阻塞使用：
   • navigation_hazard_point
   • anchor_caution_hazard_point
4. 规划主工作 zoom 先固定在 z12。
5. 如果为了性能需要降一级，先试 z10-z12 混合，但不要降到 z9 以下。
6. outline/boundary 一律只做辅助参考，不参与构面。
7. 所有规划结果解释、调试和缓存键尽量挂到 fid。