pbf/STEP_RECORD.md

# 项目步骤记录

最后更新：`2026-06-16`
仓库：`/root/sourceserver/pbf`
远端：`ssh://git@nas:2222/tei/pbf.git`

## 保留原则

- 只保留最近 3 天里真正会反复回看的内容
- 重点保留三类信息：
  - pickup 相关
  - 图标改进相关
  - 所有审计的方法
- 详细过程、反复试跑、临时中间值尽量不写，统一指向报告或脚本
- 详细审计结论索引：
  - [`report/REPORT_INDEX_2026-04-18.md`](/root/sourceserver/pbf/report/REPORT_INDEX_2026-04-18.md)

## 当前固定基线

- 视觉人工审计页：
  - `http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html`
- 全国 full/semantic 审计页：
  - `http://192.168.200.184/newpec/navsea-compare-full-audit.html`

## 最近 3 天摘要

### 2026-08-06 九州语义图标测试版 r2 修复红框纹理漏画

- 用户在九州左右对比页红框指出：左侧原始 newpec 的 `P漁具定置箇所` 紫色斜线填充区域，在右侧语义图标测试版缺失。
- 根因不是 PBF 对象丢失，而是测试版 sprite 生成时只保留了语义化图标/灯弧 key，误删了 `fill-pattern` / `line-pattern` 依赖的非图标纹理。
- 已将测试页版本升为 `kyushu-semantic-icon-v1-20260806-r2`，右侧 style 改为引用：
  - `/newpec/sprite-kyushu-semantic-icon-v1-20260806-r2/sprite`
- 已修复 `navsea_build_kyushu_semantic_icon_test.py`：
  - 语义替换只改名图标/灯弧；
  - `pattern_fill_*`、`fill-daytime-*`、`fill_*`、`special_pattern_*` 等非图标纹理从 semantic sprite 原样保留；
  - 规范化两个不存在的动态纹理名：
    - `anchor_caution_hazard_area class_code=420`：`fill-daytime-405` -> `fill-daytime-420`
    - `navigation_hazard_area class_code=427`：`fill-daytime-405` -> `fill-daytime-427`
- 已同步更新对象审计脚本 `navsea_audit_kyushu_semantic_icon_test.py`，按同一规范化规则比较源/目标，避免把明确修复误判为对象属性错误。
- 已更新并部署：
  - `/mnt/sda1/www/newpec/navsea-compare-kyushu-semantic-icon-v1.html`
  - `/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu-semantic-icon-v1.json`
  - `/mnt/sda1/www/newpec/sprite-kyushu-semantic-icon-v1-20260806-r2/`
- 已重写测试 PBF 中相关纹理字段：
  - 第一轮：`123` 张瓦片、`408` 个 feature
  - 第二轮：`11` 张瓦片、`16` 个 feature
  - 当前 `/home/wwwroot/pbf-delivery-kyushu-semantic-icon-v1-20260806` 中 `fill-daytime-405` 原始字符串计数为 `0`
- 审计结果：
  - 对象/几何/图标审计：`4707/4707` 瓦片，错误瓦片 `0`，结论 `PASS`
  - sprite 图标与纹理闭合审计：扫描 `4707` 张瓦片，使用 key `62`，sprite key `98`，缺失 key `0`，旧 `symbol-daytime-* / arc-daytime-*` key `0`，结论 `PASS`
- 部署检查：
  - HTML 返回 `kyushu-semantic-icon-v1-20260806-r2`
  - delivery style metadata 返回 `kyushu-semantic-icon-v1-20260806-r2`
  - r2 sprite 中 `pattern_fill_fishery_or_fish_reef_area`、`fill-daytime-420`、`fill-daytime-427`、`fill-daytime-754` 均存在
- 备注：本机 headless Chrome 截图因 WebGL context 创建失败为空白，不能作为视觉确认依据；需在实际浏览器里刷新 r2 页面人工复核红框区域。

### 2026-08-06 九州语义图标测试版 r2 修复灯标本体掉失

- 用户继续指出：`navigation_marks` 中一处灯标对象左侧原始版有黑色灯标本体，右侧语义版只剩黄色 flare，本体符号缺失。
- 点击信息：
  - `source-layer = navigation_marks`
  - 右侧命中的 render layer 是 `nav-light-flare`
  - 对象属性包含：
    - `shape_class_code = 311`
    - `display_code = 31135504`
    - `canonical_object_type = light_beacon`
    - `icon_id = lt_bcn`
- 根因分两层：
  - `nav-marks-light-beacons` 对 `31135504` 使用的不是 `lt_bcn`，而是 style 里直接写死的旧 sprite key：`light_beacon_east_cardinal_variantt`
  - r2 sprite 之前只保留了 `icon_id/arc_id` 驱动的 key，没有把 style 里直接写死的 `light_beacon_*` / `buoy_*` / `light_up_*` 等 variant key 一起带入
- 进一步发现 builder 的 style transform 还把部分 `canonical_object_type` 过滤值误替换成了 sprite 短 key：
  - `harbor_lighthouse -> lt_hbr`
  - `breakwater_lighthouse -> lt_bkw`
  - `light_beacon -> lt_bcn`
  - 这会破坏无 `display_code` 分支和 `nav-marks` 排除条件
- 已修复 `navsea_build_kyushu_semantic_icon_test.py`：
  - sprite 构建改为按 `style` 实际引用的真实 sprite key 保留 literal icon/pattern 依赖，不再只保留 `icon_id/arc_id`
  - `navigation_marks` 相关 layer 的 `canonical_object_type` 过滤值恢复为业务语义值：
    - `harbor_lighthouse`
    - `breakwater_lighthouse`
    - `light_beacon`
- 修复后确认：
  - `style.navsea-delivery-kyushu-semantic-icon-v1.json` 中 `31135504 -> light_beacon_east_cardinal_variantt`
  - `/newpec/sprite-kyushu-semantic-icon-v1-20260806-r2/sprite.json` 中 `light_beacon_east_cardinal_variantt` 已存在
  - 闭合审计已刷新为：
    - 扫描瓦片 `4707`
    - 使用 key `83`
    - sprite key `119`
    - 缺失 key `0`
    - 旧 `symbol-daytime-* / arc-daytime-*` key `0`
    - 结论 `PASS`
- 备注：由于当前环境 headless Chrome 无法建立 WebGL context，未能在本机截图直接看到修复后的地图画面；需在真实浏览器里刷新 r2 页面确认该灯标本体已恢复。

### 2026-08-06 九州语义图标测试版 r2 修复灯标图标映射错误

- 用户继续指出另一处灯标对象图标不对：
  - 左侧原始版不是通用灯标，而是专用 variant
  - 右侧语义版却画成了普通 `light_beacon`
- 现场对象属性：
  - `source-layer = navigation_marks`
  - `render layer = nav-marks-light-beacons`
  - `display_code = 31135102`
  - `canonical_object_type = light_beacon`
  - `icon_id = lt_bcn`
- 对照原始 `style.json` 确认：
  - `31135001 -> symbol-daytime-311350`
  - `31135102 -> symbol-daytime-311351`
- 当前 `style.navsea-delivery-full-semantic-extentfix.json` 原先错误地把这两项都降成了通用：
  - `31135001 -> light_beacon`
  - `31135102 -> light_beacon`
- 已修复为：
  - `31135001 -> light_beacon_port_lateral_variantt_311350`
  - `31135102 -> light_beacon_starboard_lateral_variantt_311351`
- 已更新语义映射表：
  - `symbol-daytime-311350 -> light_beacon_port_lateral_variantt_311350`
  - `symbol-daytime-311351 -> light_beacon_starboard_lateral_variantt_311351`
- 已重新生成并部署九州测试版右侧 style / sprite：
  - `style.navsea-delivery-kyushu-semantic-icon-v1.json`
  - `/newpec/sprite-kyushu-semantic-icon-v1-20260806-r2/sprite`
- 现已确认：
  - style 中 `31135102 -> light_beacon_starboard_lateral_variantt_311351`
  - style 中 `31135001 -> light_beacon_port_lateral_variantt_311350`
  - r2 sprite 已包含这两个 key
- 刷新后的闭合审计结果：
  - 扫描瓦片 `4707`
  - 使用 key `91`
  - sprite key `121`
  - 缺失 key `0`
  - 旧 `symbol-daytime-* / arc-daytime-*` key `0`
  - 结论 `PASS`
- 备注：这次修复的是 style 显式 display_code -> sprite key 映射，不涉及 PBF 对象或几何重写。

### 2026-08-06 当前 Full PBF 与 style 显示消费关系调查

- 调查对象：`/home/wwwroot/pbf-delivery-full-20260418-rebuild`，共 `65148` 张 PBF；对照当前 Full extent-fix / semantic-extent-fix style。
- 当前 `release-minimal` PBF 的属性白名单共 `22` 个字段，四套 Full style 实际通过 `get/has` 读取其中 `20` 个。
- 明确未被当前 Full style 直接读取的字段：
  - `clearance_height_m`：z12 出现 `858` 次
  - `least_depth_m`：z12 出现 `127401` 次
- 这两个数值仍可能被 `chart_label_text` 的已生成文字间接表现；当前结论是“未被 style 直接消费”，不是“业务上绝对无价值”。
- z12 全量解码发现 PBF 有 `53` 个 source-layer，而 Full style 对 `navsea_delivery` 实际声明 `38` 个 source-layer；以下 `16` 个 source-layer 当前没有 style layer，不会被当前 Full style 绘制：
  - 深度类：`depth_contour_overview`、`depth_zone_700`、`depth_zone_702`、`depth_zone_725`、`depth_zone_740`、`depth_zone_748`、`depth_zone_749`
  - 航路/导标类：`route_area`、`route_outline`、`route_axis_line`、`route_boundary_point`、`leading_line_outline`
  - 辅助边界类：`clip_outline_721`、`clip_outline_730`、`facility_boundary_area_transparent`、`hazard_boundary_line`
- 当前未删除上述字段或 source-layer；它们可能用于点击回查、未来 style、其他版本样式或业务数据保真。若要做瘦身，必须先完成对应对象保真和全版本 style 影响审计。

### 2026-08-06 Full style 灯弧 sprite 调查

- 当前 Full style 的 `nav-light-arc` 实际只引用 4 个 `arc-daytime-*`：
  - `arc-daytime-m1`：绿色环
  - `arc-daytime-m2`：红色环
  - `arc-daytime-m3`：黄/白色环
  - `arc-daytime-04027289`：较大的开口黄/白扇弧
- sprite 审计清单共有 `255` 个 `arc-daytime-*` 条目，其中 `251` 个标为 `unused_in_current_full`；当前不需要保留全部 arc sprite。
- style 选择规则：`navigation_marks + chart_symbol_code=lighthouse + light_color_code` 才进入灯弧层；绿色/红色/其他颜色分别使用 `m1/m2/m3`，只有 `coastal_lighthouse_over_15m + light_sector_mode=sector` 使用开口扇弧 `04027289`。
- 当前没有将 `arc-*` 图片名写入 PBF；PBF 只保存灯色和灯弧语义，图片由 style 动态选择。
- 结论：可以清理 251 个当前 Full 未引用的 arc sprite；当前实际引用的 4 个不能仅因视觉相近而合并，尤其不能把开口扇弧与黄/白闭环视为等价。若要进一步减少灯弧显示，应单独做原始 style 对照和导航安全对象审计。

### 2026-08-06 Full style `symbol-daytime-*` sprite 调查

- 当前 Full extent-fix style 明确引用 `67` 个具体 `symbol-daytime-*`，并另有一条按 `class_code` 动态拼接 `symbol-daytime-<class_code>` 的规则。
- 当前全国 Full PBF 中实际编码的 `chart_icon_image` 有 `21` 个 `symbol-daytime-*` 值；其中包括航标、灯标、危险物、鱼礁、设施和部分浮标图标。
- 现有 sprite 审计清单共 `171` 个 `symbol-daytime-*`：`18` 个标为 style_and_pbf、`3` 个标为 pbf_only_data_driven、`49` 个标为 style_only、`101` 个标为 unused_in_current_full。
- 结论：`symbol-daytime-*` 仍是当前 Full 的主图标体系，不能整体删除。只有已确认 `unused_in_current_full` 且不被其他 style / 页面使用的条目，才适合清理；`style_only` 不能仅凭当前 PBF 扫描直接删除，因为 style 仍然引用或可由 class_code 动态生成。

### 2026-08-06 Full compare 当前 style / sprite 实际引用确认

- `src/pbf/navsea-compare-full-audit.html` 默认 `variant=semantic`，实际加载：
  - style：`style.navsea-delivery-full-semantic-extentfix.json`
  - PBF：`/pbf-delivery-full-20260418-rebuild/{z}/{x}/{y}.pbf`
  - sprite：`/newpec/sprite-semantic/sprite`，对应 `sprite.json`、`sprite.png`、`@2x` 文件
- compare 页使用 `variant=full` 时加载：
  - style：`style.navsea-delivery-full-extentfix.json`
  - sprite：`/newpec/sprite/sprite?v=111`
- `navsea-final-delivery-full.html` 仍引用未 extentfix 的 `style.navsea-delivery-full.json`，其 style 内部仍指向旧的 `pbf-delivery-full-20260415`，不是当前 20260418 rebuild 基线。
- HTTP 检查发现普通 `/newpec/sprite/sprite.json` 和 `sprite.png` 当前返回 `404`，但 `/newpec/sprite/sprite@2x.json` 可访问；语义 sprite 的 1x/2x 文件均可访问。普通 Full variant 的非高分屏 sprite 资源需要后续单独修复或确认 Nginx 映射。

### 2026-08-06 全国 Full 讨论基线统一

- 后续全国 Full 的所有讨论、审计和图标/style 判断统一以以下组合为准：
  - style：`style.navsea-delivery-full-semantic-extentfix.json`
  - sprite：`/newpec/sprite-semantic/sprite`
  - PBF：`/home/wwwroot/pbf-delivery-full-20260418-rebuild`
- 不再将普通 `style.navsea-delivery-full*.json`、普通 `/newpec/sprite/sprite` 或旧 `pbf-delivery-full-20260415` 作为当前全国 Full 的默认判断依据，除非明确进行历史兼容对照。

### 2026-08-06 语义 Full 基线 arc / symbol sprite 重新盘点

- 唯一基线：`style.navsea-delivery-full-semantic-extentfix.json` + `/newpec/sprite-semantic/sprite` + `pbf-delivery-full-20260418-rebuild`。
- `arc-*`：semantic sprite 共 `255` 个；当前 style 明确引用并实际需要 `4` 个：`arc-daytime-04027289`、`arc-daytime-m1`、`arc-daytime-m2`、`arc-daytime-m3`。PBF 不直接携带 `arc-*` 图片名，灯弧由 style 根据灯标属性选择。其余 `251` 个是当前基线的删除候选，但删除前需确认旧 semantic style 不再使用同一 sprite。
- `symbol-*`：semantic sprite 共 `171` 个；当前基线实际活跃集合约 `42` 个，来源分三类：
  - style 危险物 class_code 映射：`401/404/405/409/410/412/413/420/421/422/424/425/427/428/429/431/432/433/434`
  - 陆上点 class_code 动态映射：当前实际出现 `640/650/660/661/680/681/682/698`
  - PBF `chart_icon_image` 动态消费：`301/303/30500001/30500002/30500003/30700003/308/310/320/321/323/325/327/335359/719`
- 当前 semantic sprite 中其余约 `129` 个 symbol 是当前基线的删除候选，但必须确认旧 semantic PBF / 页面不再复用同一 sprite。
- 发现缺口：当前 PBF 的 `onshore_structure_point` 有 `289` 个 `class_code=662`，style 会动态请求 `symbol-daytime-662`，但 semantic sprite 没有该 key；该项应作为缺图问题处理，不能当作可删除项。

### 2026-08-06 `class_code=662` 语义确认

- 从当前 Full PBF 的真实 `onshore_structure_point` 要素抽查确认：`class_code=662` 的 `canonical_object_type` 是 `customs_office`，即“海关/海关办公设施”类陆上地标。
- 因此 `symbol-daytime-662` 预计应是海关设施图标；它不是灯弧，也不是可以直接删除的无用 symbol。
- 当前 semantic sprite 缺少 `symbol-daytime-662`，而 style 的动态拼接规则会请求它；后续应补图标或为 662 增加明确的安全回退映射，并做视觉核对。

### 2026-08-06 语义图标替换表 v1

- 已生成设计表：[`tasks/pbf/NavSea_语义图标替换表-v1.md`](/root/sourceserver/pbf/tasks/pbf/NavSea_语义图标替换表-v1.md)
- 覆盖当前 Full 基线实际使用的灯弧、`chart_icon_image`、危险物 class_code、陆上地标 class_code 和现有 style 别名。
- 目前仅生成替换表，尚未改写 PBF、style 或 sprite；待表确认后一次性全量重建。

### 2026-08-06 语义图标改名方案的审计与反向追溯要求

- 后续可将 PBF 中的图标引用改为短语式语义 ID，例如 `lm_customs`、`hz_wreck`；sprite JSON 使用完整语义 key，例如 `landmark-customs-office`。
- 语义 ID 不得替代原始对象身份。转换结果必须保留 `source_fid / source_class_code / source_layer` 等紧凑追溯字段，或生成与 PBF 版本绑定的外部审计索引。
- 映射关系必须独立版本化，至少记录：输入字段条件、语义 ID、sprite key、style 消费规则和映射版本；支持语义 ID 反查一个或多个原始类别。
- 后续每次原始 PBF 转自用 PBF 都应执行三层审计：对象是否保留、style 是否应该命中、语义 sprite 是否存在。报告要区分“对象丢失”“被 style 过滤/缩放隐藏”“图标缺失”三类问题。
- 当前仅讨论设计，尚未修改 PBF、style 或 sprite。

### 2026-06-16 P陸域 独立 z4-9 tileset 生成入口

- `navsea_tile_builder.py` 新增了通用参数：
  - `--source-layer-include`
- 现在可以按 legacy `source_layer` 白名单导出瓦片，不再只能整层整图输出。
- 新增固定封装脚本：
  - [`navsea_build_land_area_z4_9.py`](/root/sourceserver/pbf/navsea_build_land_area_z4_9.py)
- 这个封装入口默认：
  - 只包含 `P陸域`
  - 只生成 `z4-9`
  - 输出到 `/home/wwwroot/pbf-delivery-land-area-z4-9`
  - 复用现有 `P陸域 -> land_area` 语义，不做几何简化
- 已完成基础验证：
  - `./.venv/bin/python -m py_compile navsea_tile_builder.py navsea_build_land_area_z4_9.py`
  - `./.venv/bin/python navsea_tile_builder.py --help`
  - `./.venv/bin/python navsea_build_land_area_z4_9.py --help`
- 已实际生成一次数据：
  - 输出目录：`/home/wwwroot/pbf-delivery-land-area-z4-9`
  - 实际写入 `417` 个 PBF
  - 实际覆盖 `z5-z9`
  - `z4` 目录存在，但当前源数据里没有可写瓦片，所以为空

### 2026-06-11 固化全国 Full PBF 重建流水线节点

- 新增中文节点文档：
  - [`NavSea_全国完整PBF重建流水线说明.md`](/root/sourceserver/pbf/NavSea_全国完整PBF重建流水线说明.md)
- 文档明确了当前全国 Full 基线 `/home/wwwroot/pbf-delivery-full-20260418-rebuild` 的完整重建方法：
  - 固定 Git 代码节点 `6d72340`
  - 使用原始 `newpec-mvt-20260106` 全国 PBF
  - 使用未修改的 MySQL `pbf_analysis` 语义数据和 `navsea-core` 规则包
  - 以 `/home/wwwroot/pbf-delivery-full-20260415` 作为 reference footprint
  - 按 `z0-8 / z9-10 / z11 / z12` 四段生成后合并
  - 按对象保真、渲染/几何、AOI 视觉顺序完成审计
- 文档同时明确：
  - `navsea_rebuild_hotspot_tiles.py` 只用于热点验证，不是全国生成 pipeline
  - 重建必须先写候选目录，不直接覆盖当前正式基线
  - 验收以业务内容和解码后结构等价为主，不强制要求 PBF 二进制 SHA256 相同
- 后续重新生成全国 Full PBF 时，以该文档作为固定入口节点。

### 2026-05-10 coast wall viewer 空白页修复

- `src/pbf/navsea-coast-wall-z12-viewer.html` 已升到 `v2.1`。
- 修复方向：
  - 先尝试本地化 MapLibre 后仍可复现“先有地图、随后底图消失/空白”的现象。
  - 最终将查看页底图从 MapLibre/WebGL 切换为本地 Leaflet，阻断墙 bin 解析与 canvas 绘制逻辑保持不变。
  - 新增本地静态资源：
    - `src/pbf/vendor/leaflet-1.9.4/leaflet.css`
    - `src/pbf/vendor/leaflet-1.9.4/leaflet.js`
  - HTML 改为引用 `vendor/leaflet-1.9.4/...`，并带 `coast-wall-viewer-v2.1` cache-busting。
  - 保留本地资源缺失时的可见错误提示，避免静默空白。
- 已同步部署到：
  - `/mnt/sda1/www/newpec/navsea-coast-wall-z12-viewer.html`
  - `/mnt/sda1/www/newpec/vendor/leaflet-1.9.4/`
- 已验证：
  - `node -e ...` 检查 `src/pbf/navsea-coast-wall-z12-viewer.html` 内联 JS 语法通过。
  - `curl http://192.168.200.184/newpec/navsea-coast-wall-z12-viewer.html?v=coast-wall-viewer-v2.1` 可看到 `v2.1` 与本地 Leaflet vendor 引用。
  - Chrome headless 截图 `/tmp/navsea_v21.png` 确认底图可见。

### 2026-05-07 v2 hazard_50m 排除沙波/急潮波纹/涡流/海草

- `coastline/navgrid_v2/build_hazard_50m_mysql.py` 已调整 50m 障碍格口径：
  - 不再把 `sand_wave` / 沙波作为障碍物写入 `hazard_50m`
  - 不再把 `tide_rips_overfalls` / 急潮・波紋・激潮作为障碍物写入 `hazard_50m`
  - 不再把 `eddy_whirlpool` / 渦流作为障碍物写入 `hazard_50m`
  - 不再把 `seaweed` / `seagrass` / 海草作为障碍物写入 `hazard_50m`
  - 兼容过滤字段包括 `class_code=421/422/424/425`、`chart_symbol_code`、`chart_icon_image`、`canonical_object_type`、`class_name`
- `HAZARD_DESCRIPTION` 已标注“排除沙波/急潮波纹/涡流/海草”。
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/navgrid_v2/build_hazard_50m_mysql.py`
  - 内联 smoke 断言确认 `421/422/424/425`、`sand_wave`、`tide_rips_overfalls`、`eddy_whirlpool`、`seaweed/seagrass`、`symbol-daytime-421/422/424/425`、`サンドウェーブ/急潮・波紋・激潮/渦流/海草` 会被排除，`427` 与 `breakwater` 不会被误排。

### 2026-05-06 v2 阻断墙支持可调 zoom / 墙 cell

- `coastline/navgrid_v2/build_coast_wall_z12_bin.py` 已从固定 `z12 + 40x40` 扩展为可参数化：
  - `--zoom`
  - `--grid-size`
  - `--grid-w`
  - `--grid-h`
  - `--sparse-threshold`
- 默认行为保持为原来的 `--zoom 12 --grid-size 40`。
- `--coast-cell-size-m` 仍表示输入海岸线层大小，例如 `coast_200m/coast_100m/coast_50m`；新加的 `--zoom/--grid-size` 表示最终墙自身的输出 cell 大小。
- 追加规则：当 `--coast-cell-size-m < 20` 时自动跳过 `fish_port_20m`，因为输入海岸线层已经比渔港 20m 更细。
  - 例如 `--zoom 14 --grid-size 80 --coast-cell-size-m 10` 会使用 `hazard_50m + coast_10m`，不再读取渔港 20m。
  - `.meta.json` 会记录 `include_fish_port_20m=false`。
- 输出文件名在非默认墙参数下会带上墙形态，例如：
  - `coast_wall_param_smoke_z11_g80_200_50_20.bin`
- 默认 `--out out/navmask/coast_wall_z12.bin` 在非默认墙参数下会自动去掉旧 stem 里的 `z12`，避免出现 `coast_wall_z12_z14_g80_...` 这类误导命名。
  - 例如 `--zoom 14 --grid-size 80 --coast-cell-size-m 10` 输出为 `coast_wall_z14_g80_10_50.bin`。
- `src/pbf/navsea-coast-wall-z12-viewer.html` 已升到 `v1.8`，读取 bin header 自动识别 `zoom/grid`，不再只能看固定 z12/40x40。
- 预览页已同步部署到：
  - `/mnt/sda1/www/newpec/navsea-coast-wall-z12-viewer.html`
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/navgrid_v2/build_coast_wall_z12_bin.py`
  - `./.venv/bin/python coastline/navgrid_v2/build_coast_wall_z12_bin.py --help`
  - `./.venv/bin/python coastline/navgrid_v2/build_coast_wall_z12_bin.py --self-test --zoom 11 --grid-size 80 --bbox 130,33,130.2,33.2 --out out/navmask/coast_wall_param_smoke.bin --progress-every 0`
  - `./.venv/bin/python coastline/navgrid_v2/build_coast_wall_z12_bin.py --self-test --zoom 11 --grid-w 80 --grid-h 40 --bbox 130,33,130.2,33.2 --out out/navmask/coast_wall_param_rect_smoke.bin --progress-every 0`
  - `./.venv/bin/python coastline/navgrid_v2/build_coast_wall_z12_bin.py --zoom 14 --grid-size 80 --coast-cell-size-m 10 --bbox 130,33,130.2,33.2 --out out/navmask/coast_wall_skip_fish_smoke.bin --progress-every 0`
  - `./.venv/bin/python coastline/navgrid_v2/build_coast_wall_z12_bin.py --zoom 14 --grid-size 80 --coast-cell-size-m 10 --bbox 130,33,130.2,33.2 --progress-every 0`
  - 已检查该 smoke 的 meta：`include_fish_port_20m=false`，`fish_port_20m` 行数为 `0`
  - `node -e ...` 检查 `src/pbf/navsea-coast-wall-z12-viewer.html` 内联 JS 语法通过
- v2 中文说明已同步到：
  - `coastline/navgrid_v2/NavSea_v2_使用说明.md`

### 2026-05-04 三类数据拆分为 v2 新目录脚本

- 新增 v2 脚本目录：
  - `coastline/navgrid_v2/`
- 当前 v2 脚本包括：
  - `build_coast_grid_mysql.py`
  - `build_fish_port_20m_mysql_resume.py`
  - `build_hazard_50m_mysql.py`
  - `export_coast_grid_mysql_assets.py`
  - `export_navgrid_mysql_assets.py`
  - `export_prc20_test_assets.py`
  - `export_fish_port_debug_assets.py`
  - `build_coast_wall_z12_bin.py`
- 当前 v2 验证页包括：
  - `src/pbf/navsea-coastline-fukuoka-saga-200m-v2.html`
  - `src/pbf/navsea-fish-port-debug-v2.html`
  - `src/pbf/navsea-fish-port-prc50-test-v2.html`
- 海岸线 v2 cell 已补更明确的来源字段：
  - `source_code`
  - `source_path`
  - `source_name`
- v2 海岸导出页已改为读取新表并输出来源字段
- v2 共用导出脚本已改为从三套分表读取并生成 national 资产
- 这次不做迁移脚本，仍然是重建式路线
- v2 独立使用说明已放到：
  - `coastline/navgrid_v2/NavSea_v2_使用说明.md`

### 2026-05-04 全国海岸 50x50 支持从指定包续跑

- `coastline/build_japan_coast_grid_mysql.py` 已增加续跑参数：
  - `--resume`
  - `--start-code`
- 用途：
  - 全国 `50x50` 海岸线格子如果已完成前序包，例如日志显示 `C23-06_12` 已完成、卡在 `C23-06_13`，可以保留已入库的 `coast_50m`，直接从 `C23-06_13` 继续。
- 推荐续跑命令：
  - `./.venv/bin/python coastline/build_japan_coast_grid_mysql.py --cell-size-m 50 --layer-name coast_50m --out-dir out/coastline/japan_coast_50m_mysql --resume --start-code 13`
- 行为说明：
  - 带 `--resume` 时不会清理当前 `layer_name`
  - 不带 `--resume` 时仍是完整重建，会先删除当前目标 `layer_name` 的旧记录
  - 每个包写入统计前会先删除同一 `layer_name + source_code` 的旧统计，避免续跑造成包统计重复
- 进度日志已加时间戳心跳：
  - 包开始、几何构造、分批落库、包完成都会打印 `YYYY-MM-DD HH:MM:SS`
  - 处理大包时还会按扫描格数和时间间隔输出中途进度
- 中文说明已同步到：
  - `NavSea_全国三层数据生成与查看说明.md`

### 2026-05-04 全国海岸 50x50 扫描逻辑改为粗筛+细扫

- `coastline/build_japan_coast_grid_mysql.py` 已从“整包大 bbox 暴力逐格判断”改为：
  - 按每条海岸线分别生成局部 `buffer`
  - 先用更大的粗框做候选筛选
  - 只对命中的粗框做 50m 细扫
  - 每条线结束后就把当前命中的格子写入数据库
- 默认粗筛倍率为 `8`
- 这一版的目标是减少空扫数量，并让数据库更早看到写入
- `py_compile` 已通过
- 说明文档暂仍沿用原入口，后续如需要再补一段“新扫描策略”说明

### 2026-05-03 渔港 20m 语义修正为海岸线格子

- `coastline/build_japan_coast_grid_mysql.py` 已改为可配置海岸线格子大小：
  - 新增 `--cell-size-m`
  - 新增 `--layer-name`
  - 默认仍是 `200m -> coast_200m`
  - `--cell-size-m 50` 默认自动写入 `coast_50m`
  - 脚本不再 `DROP TABLE navsea_grid_cell/navsea_grid_layer_meta/navsea_grid_package_stat`
  - 重跑时只删除当前目标 `layer_name` 的旧记录，避免 `coast_50m`、`coast_200m`、`fish_port_20m`、`hazard_50m` 相互覆盖
  - 单层 coast 写入统一使用固定 `source_name`，避免同一层内相邻海岸线包的重叠格重复落库
  - `navsea_grid_package_stat` 已补 `layer_name` 维度，便于不同尺寸的海岸线统计并存
  - 已用临时库验证：`--db-name navsea_coast_grid_param_smoke --input coastline/C23-06_40_GML.zip --cell-size-m 1000`
- 新增 z12 阻断墙二进制生成器：
  - `coastline/build_coast_wall_z12_bin.py`
- 新增独立中文说明：
  - `NavSea_coast_wall_z12_bin_生成说明.md`
- 生成逻辑已经按当前 MySQL 三层格子实现，不再从原始矢量重新栅格化：
  - 读取 `fish_port_20m`
  - 读取 `hazard_50m`
  - 读取 `coast_200m`
  - 按 `density_overview_grid` 同一套密度优先级融合
- 当前融合规则：
  - `20x20` 永远保留
  - `50x50` 与已保留 `20x20` 重叠时跳过
  - `200x200` 与已保留 `20x20` 或已保留 `50x50` 重叠时跳过
- 输出格式：
  - `coast_wall_z12.bin`
  - `coast_wall_z12.bin.meta.json`
  - 可选 debug GeoJSON
- bin 编码：
  - z12 tile 内部切成 `40x40`
  - 每 tile blocked cell 数量 `<=96` 用 sparse `uint16[]`
  - `>96` 用 `uint32[50]` bitset
  - Header / BlockDirectory / TileDirectory / DataBlob 按任务文档写入
- 已做两次验证：
  - `./.venv/bin/python -m py_compile coastline/build_coast_wall_z12_bin.py`
  - `./.venv/bin/python coastline/build_coast_wall_z12_bin.py --self-test --bbox 130,33,131,34.5 --out out/navmask/coast_wall_z12_fukuoka_smoke.bin --query 130.4,33.6 --progress-every 0`
- 九州样例已生成：
  - `out/navmask/coast_wall_z12_kyushu.bin`
  - `out/navmask/coast_wall_z12_kyushu.bin.meta.json`
  - `out/navmask/coast_wall_z12_kyushu.debug.geojson`
  - 样例统计：`tiles=813`，`cells=148453`，`sparse=351`，`bitset=462`，`blocks=7`，`size=122625`
- 复查 `coastline/build_fish_port_20m_full_mysql_resume.py --fpc 4320065` 与 `--prc 40` 结果不一致的问题：
  - 原始 `C09-06.zip` 中 `FPC=4320065` 确实属于 `PRC=40`
  - 该 FPC 有 2 条线要素，按当前逻辑命中 54 个 `coast_200m` 粗格
  - 单港纯计算可得到 582 个去重后的 20m `COASTLINE` 格
  - 当前旧静态资产 `src/pbf/coastline-mysql/fukuoka_saga/fish_port_20m_grid.geojson` 仍是旧口径，含 `SEA_SURFACE/LAND_BASE` 且 source 仍为 `C09-06+coastline PRC=40`，不能再作为当前单港/FPC 口径的对比基准
  - `PRC=40` 全批处理里有若干 FPC 的 part 没有命中 `coast_200m` 底盘；默认严格模式会中止，若没有显式跳过，会导致后续 `4320065` 没有进入批处理结果
  - 又修正了一个批处理阻断点：`FPC=4310320` 这类无海岸线命中的港口会在加载海岸线阶段先报 `no coastline curves parsed`，导致 `--skip-missing-coarse` 来不及生效
  - 现在 `load_coastlines_for_prc` 会抛可捕获异常；在 `--skip-missing-coarse` 下会记录 `FPC_SKIPPED_NO_COASTLINE` 并继续后续 FPC
  - 已验证 `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --fpc 4310320 --skip-missing-coarse --max-scan-cells 200000` 可跳过而不退出
- 已重新明确 `fish_port_20m` 的入库语义：
  - 不是保留纯海面格子
  - 不是保留纯陆地格子
  - 只保留与海岸线缓冲带相交的 `COASTLINE` 格子
- `coastline/build_fish_port_20m_full_mysql_resume.py` 已改为：
  - `coast_buffer` 命中的 20m cell 才写入 `navsea_grid_cell`
  - 写入时 `state_name/class_name` 均为 `COASTLINE`
  - 未命中的 cell 只作为 `off_coast` 统计，不入库
  - 指定 `--prc` 重算时按 `source_name LIKE 'C09-06+coastline PRC=xx%'` 清理旧格子，避免混入旧 FPC 或旧缓冲结果
  - 指定 `--fpc` 重算时先清理该 FPC 的旧格子
  - 20m 写库从 `INSERT IGNORE` 改为 duplicate key upsert，避免相同 `cell_id` 被旧 PRC/source 占住后导致当前 PRC 看起来写入成功但导出为空
  - 修正 tiled 分支中 `y += cell_size_m` 的缩进风险
- `coastline/export_prc20_test_assets.py` 已改为只导出 `state_name='COASTLINE'`
- `src/pbf/navsea-fish-port-prc50-test.html` 已改为只显示 `COASTLINE` 海岸线格子
- 已复查无垢岛测试页空白原因：
  - 页面加载的 `fish_port_20m_prc50_grid.geojson` 一度只有 45 字节，为空 FeatureCollection
  - 数据库里无垢岛附近的旧 20m 格子被 `PRC=44` source 占用，`PRC=50` 重算时旧版 `INSERT IGNORE` 没有覆盖
  - 改为 upsert 后重跑 `--prc 50`，当前 `PRC=50 / COASTLINE` 为 `331` 格
  - 已重新导出并同步 `src/pbf/coastline-mysql/prc50_test/` 到 `/mnt/sda1/www/newpec/coastline-mysql/prc50_test/`
- 后续又收紧了 20m 扫描母集：
  - 不再复用整 PRC 的 coast_200m 窗口
  - 现在按每个 `fish_part` 自己的 bbox 找 `coast_200m`
  - `fish_part` 只负责筛选应命中的粗格，真正切 20m 时不再做 `fish_part ∩ coarse_window` 二次裁剪
  - 这样可以避免把粗格里本来应该保留的海岸线细格提前裁掉
- 这条口径已经同步回正式全国版 `coastline/build_fish_port_20m_full_mysql_resume.py`
- `--fpc` 入口也补齐了和 `--prc` 一致的进度清理动作，避免单港重算时残留旧的 PRC 进度记录
- `--prc` 入口已改成先按 `FPC` 分组，再逐港走同一套 20m 切格逻辑；不再把整个 PRC 的所有港混在同一个聚类里
- 相关使用说明已同步到：
  - `NavSea_全国三层数据生成与查看说明.md`

### 2026-05-02 全国 50x50 重算脚本

- 新增全国 50x50 海上障碍重算脚本：
  - `coastline/build_japan_hazard_50m_mysql.py`
- 默认行为：
  - 从全国 PBF 根目录 `'/home/wwwroot/pbf-delivery-full-20260418-rebuild'` 扫描 `z12` 瓦片
  - 识别 `navigation_hazard_area`、`fixed_fishing_gear_area`、`anchor_caution_hazard_area`、`navigation_hazard_point`、`anchor_caution_hazard_point`、`navigation_marks`
  - 追加把 `baseline_area` 里的 `canonical_object_type=breakwater` 视作 50m 障碍底盘
  - 过滤 `fish_reef` 类对象后，重算 `hazard_50m`
  - 写回统一库 `navsea_japan_coast_grid`
  - 导出全国静态资产到 `src/pbf/coastline-mysql/japan_national/`
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/build_japan_hazard_50m_mysql.py`
  - `./.venv/bin/python coastline/build_japan_hazard_50m_mysql.py --help`
  - 抽样全国瓦片可以解析到 hazard layer

### 2026-05-02 全国三层生成与查看说明

- 新增中文说明文档：
  - `NavSea_全国四脚本一页面数据生成与查看说明.md`
- 说明内容包括：
  - 全国 `200x200`、`20x20`、`50x50` 的重算脚本
  - 整体密度图 `density_overview` 的导出与查看
  - 各脚本的完整执行命令
  - 全国静态 JSON 导出命令
  - 全国预览 HTML 的完整 URL
  - 线下同步到网页目录的命令
- 已同步最新全国预览页与整体密度资产到：
  - `/mnt/sda1/www/newpec/navsea-coastline-fukuoka-saga-200m.html`
  - `/mnt/sda1/www/newpec/coastline-mysql/japan_national/density_overview_grid.geojson`
- 已修正全国预览页对 bbox 的容错：
  - 现在遇到旧版 mercator bbox 时会自动回退到预设中心点，不再抛 `Invalid LngLat latitude value`
- 同步修正了导出脚本与 200m 构建脚本的 bbox 口径：
  - `coastline/export_navgrid_mysql_assets.py`
  - `coastline/build_japan_coast_grid_mysql.py`
- 已把 20m 重算流程收紧为：
  - 先按渔港 bbox 找同区域 `coast_200m` 粗格
  - 再把命中的 `coast_200m` 粗格直接作为 20m 直切底盘
  - 不再额外用 `fish_part ∩ coarse_window` 裁窗
  - 20m 判定继续使用同一套海岸线重叠判断
  - 默认粗筛边距收紧为 0m，避免再做不必要的大范围外扩

### 2026-05-02 全国海岸/渔港/障碍三按钮预览页

- 已将 `src/pbf/navsea-coastline-fukuoka-saga-200m.html` 改造成全国入口页：
  - 页面标题改为全国
  - 默认加载全国 `200x200`
  - 增加四个切换按钮：
    - `200x200`
    - `20x20`
    - `50x50`
    - `整体密度`
- 已重新导出全国静态资产到：
  - `src/pbf/coastline-mysql/japan_national/`
- 三个按钮对应的数据源现在是：
  - `coast_200m`：全国海岸 200x200
  - `fish_port_20m`：全国渔港 20x20
  - `hazard_50m`：全国海上障碍 50x50
  - `density_overview`：三档密度整体格子图
- 已同步到线上页面：
  - `http://192.168.200.184/newpec/navsea-coastline-fukuoka-saga-200m.html`
- 已纳入固定基线的一部分，后续全国相关视觉确认优先看这页

### 2026-05-02 PRC 编号补零修正

- 已修正 `coastline/build_fish_port_20m_full_mysql_resume.py` 的 `PRC` 选择逻辑：
  - 现在会把 `2` 自动归一成 `02`
  - `PRC` 读取、选择、断点恢复和源名删除都统一按两位字符串处理
- 这次修正的直接原因：
  - `C09-06.zip` 里的原始 `PRC` 是两位编码
  - 传 `--prc 2` 时之前会匹配不到任何渔港线要素
- 已验证：
  - `normalize_prc_token('2') -> '02'`
  - `discover_prcs(..., {'2'})` 不再漏掉 `02`
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`

### 2026-05-02 全国 200m / 20m / 障碍层统一汇聚脚本

- 新增可直接运行的汇聚脚本：
  - `navsea_national_navigation_fusion.py`
- 当前默认汇聚的三层是：
  - `navsea_japan_coast_grid.navsea_grid_cell` 里的 `coast_200m`
  - `navsea_fukuoka_saga_grid.navsea_grid_cell` 里的 `fish_port_20m`
  - `navsea_fukuoka_saga_grid.navsea_grid_cell` 里的 `hazard_50m`
- 输出格式：
  - 单个 SQLite：`out/navsea_national_navigation_fusion.sqlite`
  - 清单：`out/navsea_national_navigation_fusion.manifest.json`
- 脚本特性：
  - 记录来源注册、图层注册、每层汇总与合并后的统一格网表
  - 支持 `--recreate`
  - 支持 `--batch-size`
  - 支持 `--emit-template`
- 已验证：
  - `./.venv/bin/python -m py_compile navsea_national_navigation_fusion.py`
  - `./.venv/bin/python navsea_national_navigation_fusion.py --help`
- 说明：
  - 这只是 SQLite 版的全国融合骨架
  - 当前 MySQL 侧已经合并为单库 `navsea_japan_coast_grid`

### 2026-05-03 全国静态导出支持分层开关

- 已为 `coastline/export_navgrid_mysql_assets.py` 增加独立导出开关：
  - `--coast-200m / --no-coast-200m`
  - `--fish-port-20m / --no-fish-port-20m`
  - `--hazard-50m / --no-hazard-50m`
  - `--density-overview / --no-density-overview`
- 默认仍是四项全导出
- 现在可以只导某一层，不必每次都重出全国全量资产
- `density_overview` 仍默认开启，因为全国预览页会用到它
- 全国预览页实际会同时读取 `japan_coast_200m` 和 `japan_national`
- 线下同步时要把 `src/pbf/coastline-mysql/japan_coast_200m/` 和 `src/pbf/coastline-mysql/japan_national/` 都复制到 `/mnt/sda1/www/newpec/coastline-mysql/`

### 2026-05-03 单港 20m 调试页

- 新增单港调试导出脚本：
  - `coastline/export_fish_port_debug_assets.py`
- 新增单港调试页面：
  - `src/pbf/navsea-fish-port-debug.html`
- 调试包按 `FPC + buffer` 分目录输出：
  - `src/pbf/coastline-mysql/fish_port_debug/fpc_<FPC>/buffer_<BUFFER>/`
- 调试页会同时画出：
  - 渔港 bbox
  - 海岸线
  - 海岸 buffer
  - 200m 粗窗
  - 实际扫描窗
  - 20m 海岸格
  - 20m 海面格
- 这条链路是为了定位“明明有 200m 底盘和海岸线，但 20m 为什么没长出来”的问题

### 2026-05-02 渔港 20m 支持按单港 FPC 重算

- 已为 `coastline/build_fish_port_20m_full_mysql_resume.py` 增加单港口入口：
  - 新增 `--fpc`
  - 脚本会先按 `FPC` 反查所属 `PRC`
  - 只处理该港口对应的线要素
- 单港口模式会在日志里同时给出：
  - 命中的 `200x200` 粗格数量
  - 最终写入的 `20x20` 格子数量
- 单港口模式下，每个批次会先按当前 cell_id 清掉旧记录，再写回，便于重算同一港口
- 当前 `20x20` 的粗格母集已经收回到 **PRC 级 coast_200m**：
  - 先按当前渔港 / PRC 的 bbox 去 MySQL 找 `coast_200m`
  - 取回的粗格直接作为 20m 细扫底盘
  - 不再按 `fish_part` 的局部外框裁掉这些粗格
- `20m` 海岸缓冲默认已收紧为 `5m`，仍可用 `--coast-buffer-m` 调整
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `discover_target_prcs(..., '1112040')` 可以反查到对应 `PRC`
  - `collect_fish_lines_for_prc(..., '01', '1112040')` 可以只筛出这个港口的线要素

### 2026-05-02 按港名查 FPC 小工具

- 新增脚本：
  - `find_fpc_by_port_name.py`
- 用途：
  - 输入港名，扫描 `coastline/C09-06.zip` 里的渔港要素
  - 通过 `NA2`、`NA4`、`FCF` 等字段找候选 `FPC`
  - 如果原始包里没有港名字段，也可以改用外部港名对照表 `--catalog`
  - 支持精确匹配、包含匹配和 `--fuzzy` 后缀归一模糊匹配
- 文档已补到：
  - `NavSea_全国三层数据生成与查看说明.md`
- 已验证：
  - `./.venv/bin/python -m py_compile find_fpc_by_port_name.py`

### 2026-05-02 PRC=50 单港 20x20 测试页

- 新增单港测试页：
  - `src/pbf/navsea-fish-port-prc50-test.html`
- 页面用途：
  - 直接读取专用 PRC=50 导出 `fish_port_20m_prc50_grid.geojson`
  - 只显示 `COASTLINE` 海岸线格子
  - 单独显示无垢岛这一港，便于确认当前 20x20 海岸线判断结果
- 已同步到线上：
  - `http://192.168.200.184/newpec/navsea-fish-port-prc50-test.html`

### 2026-05-02 PRC=50 专用 20x20 导出

- 新增专用导出脚本：
  - `coastline/export_prc20_test_assets.py`
- 用途：
  - 只导出 `fish_port_20m` 里 `source_name` 匹配 `PRC=50` 且 `state_name='COASTLINE'` 的记录
  - 输出到独立目录 `src/pbf/coastline-mysql/prc50_test/`
  - 便于测试页只加载单港数据，不再依赖全国全量资产
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/export_prc20_test_assets.py`
- 已实际导出并同步到线上：
  - `fish_port_20m: 2800`
  - `http://192.168.200.184/newpec/coastline-mysql/prc50_test/fish_port_20m_prc50_grid.geojson`

### 2026-05-02 全国预览页 20x20 旧资产同步修正

- 已复核 `src/pbf/navsea-coastline-fukuoka-saga-200m.html` 的加载逻辑：
  - HTML 本身使用的是 `./coastline-mysql/japan_national/manifest.json`
  - `20x20` 图层是从 `./coastline-mysql/japan_national/fish_port_20m_grid.geojson` 读取
- 问题根因：
  - 线上 `/mnt/sda1/www/newpec/coastline-mysql/japan_national/manifest.json` 仍停留在旧版
  - 旧版 `fish_port_20m` 只有 `34270` 个格子，所以页面看起来只在两块区域出现红格
- 已同步最新全国资产到线上目录：
  - `/mnt/sda1/www/newpec/coastline-mysql/japan_national/`
  - `/mnt/sda1/www/newpec/navsea-coastline-fukuoka-saga-200m.html`
- 同步后线上 `fish_port_20m` 计数已更新为：
  - `246653`
- 结论：
  - 这次不是 HTML 逻辑 bug，而是线上静态资产没跟上最新导出

### 2026-05-02 无垢岛 PRC=50 改为单库运行

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 从双库连接收回到单库模式：
  - 现在只打开一个 MySQL 连接
  - 同一个库里既读 `coast_200m`，也写 `fish_port_20m`
  - 当前默认库改为 `navsea_japan_coast_grid`
- 这次收口的原因：
  - 用户明确要求 `PRC=50` 的 20m 生成不要再同时开两个数据库
  - 以单库方式更容易保持 `coast_200m` / `fish_port_20m` 的同库可追溯性
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-05-02 两个 MySQL 库合并为一个

- 已执行合并脚本：
  - `navsea_merge_navgrid_mysql.py`
- 合并方向：
  - 保留 `navsea_japan_coast_grid`
  - 把 `navsea_fukuoka_saga_grid` 里的 `fish_port_20m`、`hazard_50m`、`navsea_grid_import_state`、`navsea_grid_import_progress` 搬入全国库
  - 合并完成后删除 `navsea_fukuoka_saga_grid`
- 合并后目标库现状：
  - `coast_200m`: `336215`
  - `fish_port_20m`: `16300`
  - `hazard_50m`: `176454`
  - `navsea_grid_import_state`: `1`
  - `navsea_grid_import_progress`: `39`
- 结果：
  - 当前只保留一个 MySQL 库：`navsea_japan_coast_grid`
  - 后续 `PRC=50` 的 20m 以及相关导出都以这个库为准
- 已验证：
  - `./.venv/bin/python navsea_merge_navgrid_mysql.py --dry-run`
  - `./.venv/bin/python navsea_merge_navgrid_mysql.py --drop-source-db`

### 2026-05-02 无垢岛漁港海岸线回退接入修正

- 已修正 `coastline/build_fish_port_20m_full_mysql_resume.py` 的海岸线加载逻辑：
  - 先尝试 `C23-06_{PRC}_GML.zip`
  - 如果同号包不存在，则按当前港区 bbox 退回扫描 `coastline/C23-06_*_GML.zip`
  - 这样 `PRC=50` 不会再卡死在缺失的同号文件上
- 追加修正：
  - 回退扫描时使用的是海岸线函数内部的墨卡托米制筛选
  - 调用点必须先把港区 bbox 从经纬度转成墨卡托，否则会出现 `(-68, -166, ...)` 这种错误 bbox
- 进一步修正：
  - 粗筛底盘现在改成从全国库 `navsea_japan_coast_grid` 读取
  - `navsea_japan_coast_grid.navsea_grid_cell` 实际存的是墨卡托米制坐标，查询时必须按米制直查，不能再转回经纬度
- 已实测 `PRC=50`：
  - 退回后从 `C23-06_44_GML.zip` 命中无垢岛附近海岸线
  - 命中线数 `6`
  - 这说明无垢岛漁港可以借助现有海岸线底盘继续做 20m
- 最新复核：
  - 无垢岛 bbox 在全国粗格库里可命中 `13` 个 `coast_200m` 窗口
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`

### 2026-05-02 全国 200x200 底盘已存在

- 仓库里已经有全国海岸 200x200 相关资产与预览页：
  - `src/pbf/coastline-mysql/japan_coast_200m/`
  - `src/pbf/navsea-coastline-fukuoka-saga-200m.html`
- 数据库里也确实存在全国级 `coast_200m`：
  - `navsea_japan_coast_grid`
  - 当前 `coast_200m` 记录数约 `336215`
- 说明：
  - 全国 200x200 地图是有的，不只是九州样区
  - 但它仍取决于当前已加载的海岸线来源包集合，缺包的区域不会凭空补出来

### 2026-05-02 无垢岛漁港 200m 覆盖复核

- 已复核 `PRC=50` 对应的无垢岛漁港坐标范围：
  - 原始边界线 bbox 约为 `131.975066922648..131.977924005868, 33.1589557725031..33.160819912381`
- 已在两个当前库里逐一查询该点是否落入 `coast_200m`：
  - `navsea_fukuoka_saga_grid` 命中数 `0`
  - `navsea_japan_coast_grid` 命中数 `0`
- 结论：
  - 当前仓库里能直接查到的两套 `coast_200m` 都没有覆盖无垢岛漁港
  - `navsea_japan_coast_grid` 的 `coast_200m` 来源分布里也没有 `C23-06_50`
  - 所以无垢岛漁港并不在当前已加载的 200x200 底盘里

### 2026-05-01 渔港 20m 超大范围扫描僵死止损

- 用户现场日志显示任务卡在：
  - `build_cells_for_geometry mask_hit row_idx=13315868 candidate_mask=3`
  - `build_cells_for_geometry tile_hit idx=162390 bbox=(16232000.000, 5368000.000, 16232360.000, 5370000.000)`
- 判断：
  - 这不是普通慢查询，而是 `build_cells_for_geometry` 已进入超大范围网格扫描
  - 直接原因是某些 `part` 没有有效 `coast_200m` 小窗时，旧逻辑会回退扫描完整 `fish_part`
  - 该回退路径会产生十万级 tile / 千万级 row 检查，足以把 Linux 拖到近似僵死
- 已修正 `coastline/build_fish_port_20m_full_mysql_resume.py`：
  - 默认关闭无边界回退：没有有效 `coast_200m` 交集的 `part` 作为异常中止，不再静默跳过
  - 如确需旧行为，必须显式加 `--allow-unbounded-fallback`
  - 如人工确认允许漏算某个无底盘 `part`，必须显式加 `--skip-missing-coarse`
  - `coast_200m` 命中后不再扫描整个粗窗 box，而是扫描 `fish_part ∩ coast_200m窗口`
  - 新增 `--max-scan-cells`，默认单次 `build_cells_for_geometry` 估算扫描格数超过 `200000` 直接中止
  - 日志新增 `grid=列x行` 和 `estimated_cells`，方便在真正扫描前判断风险
- 已验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`
- 当前注意：
  - `coastline/` 目录在当前工作树里仍是未跟踪目录，这次脚本修改不会出现在普通 `git diff` 中
  - 后续如果要正式提交渔港 20m 代码，需要单独决定是否把 `coastline/` 相关源码纳入版本控制，避免把导出大文件一起扫入提交

### 2026-05-01 渔港 20m 当前完成度复核

- 复核结果：
  - `coastline/C09-06.zip` 里一共能识别出 `40` 个有效 PRC
  - 当前数据库 `navsea_fukuoka_saga_grid` 里只有 `coast_200m` 和 `hazard_50m` 两层
  - 当前库里**没有** `fish_port_20m` 层数据
  - 当前磁盘上的 `out/fish_port_20m_full_resume.current_prc.json` 仍停在 `current_prc=01`
- 结论：
  - 你贴出来的 `C23-06_01 ... C23-06_47` 统计是 **coast_200m** 的数据，不是渔港 20m
  - 这份 `fish_port_20m` 任务在当前库里**还没有完成落库**
  - 如果要判断 20x20 是否完成，应该查 `layer_name='fish_port_20m'`，当前结果为空
- 额外更正：
  - 用户截图里当前选中的库是 `navsea_japan_coast_grid`
  - 这份库里只有 `coast_200m`，总数 `336215`，按 `source_name` 分布在 39 个县包
  - 这不是渔港 20m 任务库，不能拿来判断 `fish_port_20m` 是否完成

### 2026-05-01 渔港 20m 改为 part 内流式写库

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的写库方式再收紧一层：
  - 不再把一个 `part` 的所有 `rows` 整块攒起来
  - 改为在每个 `window` 生成后就直接进入批量写库
  - `commit_every` 仍然保留，负责控制每批提交多少条
- 这样可以明显降低大 `part` 的峰值内存占用
- 当前仍保留：
  - `window_rows` 这一小段局部结果
  - `build_cells_for_geometry` 的返回值
  - 但已经不再把整个 `part` 的结果常驻在一个大列表里

### 2026-05-01 全国 full-audit 页 z12 右侧空白回归定位与临时修复

- 用户在 `http://192.168.200.184/newpec/navsea-compare-full-audit.html` 发现：
  - 切到语义版 sprite / style 后，右侧 delivery 在 `zoom=12` 出现大块空白，表面像 PBF 损坏
- 已按 2026-04-18 历史记录复核，确认这是同一类旧问题：
  - 不是 sprite atlas 本身导致
  - 当前默认页仍指向旧的 `/home/wwwroot/pbf-delivery-full-semantic-20260416`
  - 该目录部分 z12 高 extent tile 存在几何错移
- 代表 tile 复核：
  - `12/3527/1641.pbf`
  - 原始 newpec / 20260418 rebuild：`y` 范围约 `-20480..1069056`
  - 旧 semantic 20260416：`y` 范围约 `1024000..2113536`
  - 这正是 2026-04-18 记录里的高 extent 重编码错移签名
- 已把全国 full-audit 页默认 PBF 切到 2026-04-18 修复版：
  - `/home/wwwroot/pbf-delivery-full-20260418-rebuild`
  - URL：`http://192.168.200.184/pbf-delivery-full-20260418-rebuild/{z}/{x}/{y}.pbf`
- 已补充可供客户端直接远程加载的 extentfix style：
  - 语义版：`http://192.168.200.184/newpec/domain/style.navsea-delivery-full-semantic-extentfix.json`
  - 普通版：`http://192.168.200.184/newpec/domain/style.navsea-delivery-full-extentfix.json`
  - 两者的 `sources.navsea_delivery.tiles` 都已指向 `/pbf-delivery-full-20260418-rebuild`
- 已按客户端一致性要求再次调整 full-audit 审计页：
  - 默认右侧不再由 HTML 覆盖 PBF URL
  - 默认右侧直接加载 `style.navsea-delivery-full-semantic-extentfix.json` 或 `style.navsea-delivery-full-extentfix.json`
  - 也就是说：审计页看到的 style，就是客户端应加载的同一份远程 style
  - 只有显式传入 `deliveryTileUrl=` 时，才作为临时实验入口覆盖 tile URL
- 后续全国 full/semantic 审计页固定按这个口径：
  - 先改远程 style
  - 审计页加载同一份远程 style
  - 不用 HTML 默认覆盖 PBF URL 来伪造审计结果
- 已继续压缩 full-audit 页面 UI：
  - 顶部工具栏桌面端压到单行，长版本 chip 省略显示，减少地图空间占用
  - `点击对比` 面板支持展开 / 收起
  - `点击对比` 面板可拖拽到屏幕任意位置，并用 `localStorage` 保留位置与折叠状态
  - 默认落位从右下改为底部居中，避免一开页就压住右侧地图视野
  - 进一步修正了页面横向撑宽问题，保证左右 pane 真正等宽
- 已更新并部署：
  - 源文件：`src/pbf/navsea-compare-full-audit.html`
  - 线上文件：`/mnt/sda1/www/newpec/navsea-compare-full-audit.html`
  - 线上 style：`/mnt/sda1/www/newpec/domain/style.navsea-delivery-full-semantic-extentfix.json`
  - 线上 style：`/mnt/sda1/www/newpec/domain/style.navsea-delivery-full-extentfix.json`
  - 页面版本：`full-audit-r6-20260501-1745`
- 当前页面语义版口径：
  - 使用 `style.navsea-delivery-full-semantic-extentfix.json`
  - sprite / PBF 都以该 style 内部声明为准
  - 当前 style 内部声明的 sprite 是 `/newpec/sprite-semantic/sprite`
  - 当前 style 内部声明的 PBF 是 `/pbf-delivery-full-20260418-rebuild`
- 已用 headless Chrome 自检：
  - `variant=semantic&center=130.070228,33.634637&zoom=12`
  - 右侧大块空白已消失
  - 1536px 宽桌面下工具栏高度约 `57px`
  - `点击对比` 面板展开 / 收起 / 拖拽均可用
  - 默认面板落位已切到底部居中，左右地图 pane 仍保持等宽
  - chip 显示 `HTML: full-audit-r7-20260501-1800`
  - chip 显示 `PBF: full-rebuild-pbf-20260418-extentfix`
  - 网络请求确认加载的是 `style.navsea-delivery-full-semantic-extentfix.json`

### 2026-04-25 渔港 20m 续跑改为数据库优先，并新增当前 PRC 状态文件

- 已调整 `coastline/build_fish_port_20m_full_mysql_resume.py` 的续跑规则：
  - `resume` 现在优先读取 MySQL 里的 `navsea_grid_import_state` 和 `navsea_grid_import_progress`
  - 不再把本地 checkpoint 文件当成续跑主来源
  - 已完成的 `PRC_DONE` 会在 resume 时直接跳过
  - 如果用 `--prc` 指定了 PRC，则仍然允许重新跑指定 PRC
- 已新增当前 PRC 状态文件：
  - `out/fish_port_20m_full_resume.current_prc.json`
  - 每次开始一个 PRC 时都会写入当前 PRC、开始时间、已完成 PRC 列表等信息
  - 每个 PRC 完成时也会更新一次，方便人工查看当前跑到哪一段
- 本地 checkpoint 文件仍保留作辅助记录：
  - `out/fish_port_20m_full_resume.checkpoint.json`
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`

### 2026-04-24 渔港 20m 海岸线改为 PRC 级缓存

- 已修正 `coastline/build_fish_port_20m_full_mysql_resume.py` 的主要慢点：
  - 现在海岸线只在每个 `PRC` 开始时读取一次
  - 只在每个 `PRC` 开始时做一次 `unary_union`
  - 只在每个 `PRC` 开始时做一次缓冲 `buffer`
  - 每个 `part` 不再重复打开海岸线包、重复解析 GML、重复合并整包海岸线
- 这次修正的目标是：
  - 把“一个渔港要跑 30 分钟”的最主要重复成本先砍掉
  - 保留现有的 part 级扫描和 checkpoint 逻辑
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`
- 现场诊断补充：
  - 当前这次运行没有写入 `out/fish_port_20m_full_resume.log`
  - `navsea_grid_import_progress` 里也还没有新进度行
  - 说明它现在仍停留在单个 `part` 的几何扫描阶段，还没跑到 PRC 收口写库

### 2026-04-24 渔港 20m 再接 coast_200m 作为粗筛底座

- 已进一步把 `coastline/build_fish_port_20m_full_mysql_resume.py` 接到数据库里的 `coast_200m` 底库：
  - 启动时先从 MySQL 读取 `coast_200m`
  - 先把 `coast_200m` 做一次粗筛缓冲
  - 每个渔港 `part` 先用这层粗筛底座裁切一次
  - 再进入原有的 20m 细扫与海岸线判定
- 这一步的目的：
  - 让 20m 扫描只看“港区 + 海岸 200m 底座”覆盖到的范围
  - 先砍掉明显不相关的空白区域，再做精判
- 已补充参数：
  - `--coast-coarse-margin-m`
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-04-24 渔港 20m 内部 TRACE 加密

- 已把 `build_cells_for_geometry` 里的内部执行步骤打印出来：
  - 准备阶段会打印 `fish_bounds`、扫描范围和 tile 范围
  - tile 命中时会打印 tile bbox
  - row 命中时会打印 row y 坐标和横向范围
  - 候选格命中时会打印候选数量
  - 函数结束时会打印累计统计
- 这样可以直接看出时间花在：
  - tile 粗筛
  - row 细筛
  - 候选格精判
  - 还是最后写库
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-04-24 渔港 20m 改为按 coast_200m 小格逐窗扫

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 再收紧一层：
  - 不再只用整片 `coast_200m` union 去裁 `part`
  - 改为直接按命中的 `coast_200m` 小格逐窗处理
  - 每个 200m 窗口内再跑原有 20m 细扫
- 这一步的目标：
  - 让 `candidate_cells` 真正随着海岸 200m 的局部区域缩小
  - 避免一个大 `part` 把几十万甚至上百万个 20m 候选格都扫进去
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-04-24 渔港 20m 打印 coast_200m 命中格数

- 已继续给 `coastline/build_fish_port_20m_full_mysql_resume.py` 加日志：
  - 每次按当前渔港 bbox 去数据库取 `coast_200m` 时，会打印取回的粗格窗口数
  - 这样可以直接看出这个 `part` 最终拿到了多少个 200m 粗筛格
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-04-24 渔港 20m 对 200m 小窗启用直算模式

- 已给 `build_cells_for_geometry` 增加小窗直算快路径：
  - 当输入几何本身已经缩到单个 `200m` 粗窗级别时
  - 不再再走 `2000m tile` 外循环
  - 直接按 `20m` 格线性扫描
- 目的：
  - 让 `candidate_cells` 与窗口尺寸严格对齐
  - 避免小窗还反复进入大范围 tile 扫描逻辑
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`

### 2026-04-24 渔港 20m 结果页改为海面 / 陆基双层显示

- 已把 `src/pbf/navsea-fukuoka-saga-coast200-fish20-full.html` 改成双层渲染：
  - `LAND_BASE` 用红色显示
  - `SEA_SURFACE` 用蓝色半透明显示
- 已重新导出 MySQL 静态资产：
  - `coastline/export_navgrid_mysql_assets.py --db-name navsea_fukuoka_saga_grid --fish-prc 40 41 --include-fish-sea`
- 这样页面不再只显示少量红色陆基块，而是能直接看到完整的渔港 20m 结果分布

### 2026-04-24 渔港 20m 红层提到海面层之上

- 已继续修正渲染顺序：
  - 海面蓝层先画
  - 陆基红层后画并置顶
  - 红层透明度和描边略微加重
- 这次修正是为了解决蓝色海面层把红色陆基层盖住的问题
- 页面版本已升到 `v2.4`

### 2026-04-24 全国 200x200 改成样区默认加载，红格已可见

- 已把全国海岸 200m 底库再导出一次，修正为经纬度 GeoJSON 输出：
  - `src/pbf/coastline-mysql/japan_coast_200m/`
  - `count = 336215`
- 已从全国底库额外导出九州样区：
  - `src/pbf/coastline-mysql/japan_coast_200m_hakata/`
  - `count = 3088`
- 现在预览页默认加载样区版，而不是全国全量版：
  - 源文件：`src/pbf/navsea-coastline-fukuoka-saga-200m.html`
  - 当前版本：`v1.5`
- 页面已经确认可以直接看到红色 200x200 格子
- 全国全量仍保留在“全国概览”按钮里，方便后续切换回去看整体分布

### 2026-04-24 全国海岸 200x200 已从数据库导出并接入页面

- 已新增全国海岸 200x200 静态导出脚本：
  - `coastline/export_japan_coast_grid_mysql_assets.py`
- 已从 MySQL `navsea_japan_coast_grid` 导出全国 200x200 数据：
  - 输出目录：`src/pbf/coastline-mysql/japan_coast_200m/`
  - 主要文件：
    - `coast_200m_grid.geojson`
    - `manifest.json`
- 全国导出数量：
  - `336215` 个 200x200 硬阻塞格
- 已把原来的红格预览页切换为全国视图：
  - 源文件：`src/pbf/navsea-coastline-fukuoka-saga-200m.html`
  - 线上页：`http://192.168.200.184/newpec/navsea-coastline-fukuoka-saga-200m.html`
- 当前页面版本：
  - `v1.2`
- 已做一次本地 headless 视觉自检：
  - 页面能正常加载全国红格
  - 视觉上可见全国海岸线周边的 200x200 红色覆盖
  - 页面初始视图已自动定位到全国范围

### 2026-04-24 全国 200x200 预览改成默认细节视图

- 由于全国总览缩放下 200m 格子太小，不容易直接看见，已把预览页改成默认显示九州海岸细节
- 现在页面保留两个视图按钮：
  - `九州细节`
  - `全国概览`
- 当前页面版本已升到：
  - `v1.3`
- 这样可以先确认红色格网确实存在，再切回全国概览看整体分布

### 2026-04-24 全国 200x200 红格再次加强可见性

- 已把同一份全国 200x200 数据的显示样式继续加重：
  - 红色填充更实
  - 外轮廓更粗
  - 增加白色 halo 辅助识别
- 当前页面版本已升到：
  - `v1.4`
- 这次不改数据，只改视觉权重，目标是让红格在底图上更容易一眼看出来

### 2026-04-24 fish port 20m resume 脚本启动修复

- 已修复以下启动错误：
  - `coastline/build_fish_port_20m_full_mysql_resume.py`
  - 问题原因：`@trace_fn("load_xml")` 在 `trace_fn` 定义之前执行，导致模块加载时直接 `NameError`
- 已调整为先定义通用 tracing 装饰器，再装饰 `load_xml`
- 已做最小验证：
  - `./.venv/bin/python -m py_compile coastline/build_fish_port_20m_full_mysql_resume.py`
  - `./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --help`
- 当前状态：
  - 脚本可以正常完成参数解析
  - 后续可以继续按原命令跑断点恢复任务

### 2026-04-24 渔港 20m 全国模式与指定 PRC 模式分离

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的运行语义拆成两种：
  - 默认模式：全国全量重建，不再把 `PRC` 当作必选条件
  - `--prc` 模式：只重建指定 PRC，并且忽略 `resume` 断点
- 指定 `--prc` 时会先删除对应 PRC 已写入的旧格网，再按该 PRC 从头完整重建
- 这样可以避免全国断点续跑和指定片区重建混在一起，导致日志看起来像“总是从 45 开始”

### 2026-04-24 渔港 20m 格网扫描做了轻量提速

- 已优化 `coastline/build_fish_port_20m_full_mysql_resume.py` 的 `build_cells_for_geometry`
- 这次改动重点：
  - 把每行新建的 `y_center/y_bottom/y_top_arr` 临时数组去掉了
  - 把 `x_values + half`、`x_values + cell_size_m` 这类重复数组改成按 tile 预先计算
  - 保留原有的 `intersects_xy` 过滤语义，不改判定结果
- 这属于低风险提速，主要目标是减少大 PRC / 大 cluster 下的临时数组分配和内存抖动

### 2026-04-24 渔港 20m 扫描增加 profiling 汇总

- 已给 `coastline/build_fish_port_20m_full_mysql_resume.py` 的 `build_cells_for_geometry` 增加汇总 profiling
- 当前会记录并在每个 PRC 完成后输出：
  - `tile_checked`
  - `tile_hit`
  - `row_checked`
  - `row_hit`
  - `mask_row_hit`
  - `candidate_cells`
  - `precise_cell_checks`
  - `precise_hits`
- 这样可以直接看出一个 PRC 的时间到底花在：
  - 粗 tile 过滤
  - 行级过滤
  - 候选格精判
  - 还是最终落库
- 同时修正了 `profile` 的 PRC 级默认值，避免某些全跳过分支在收口日志处触发 `UnboundLocalError`

### 2026-04-24 渔港 20m 进一步拆成单港部件处理

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的处理粒度从“cluster 整体”再下沉一层
- 当前流程变成：
  - 先按 `PRC` 收集候选渔港线
  - 再按空间连通性聚成 cluster
  - 然后把每个 cluster 的 `fish_geom` 拆成独立几何部件逐个处理
- 这样单次扫格的 `bounds` 会更接近单个渔港，而不是整个 `PRC` 的大外框
- 断点也同步细化到 `part` 级，避免中途停掉后还要重算整个 cluster

### 2026-04-24 海岸线按单港 bbox 裁切

- 已将 `coastline/build_fish_port_20m_full_mysql_resume.py` 的海岸线读取进一步改为按当前渔港部件 `bbox` 裁切
- 当前逻辑：
  - 先拿单个渔港部件的 `bbox`
  - 再去 `C23-06_{PRC}_GML.zip` 里只保留与该 `bbox` 相交的海岸线
  - 最终缓冲区也会再裁回这个 `bbox`
- 这样海岸线判定和 20m 格网扫描都不会再越过当前渔港的局部范围
- 这符合“一个渔港算完进数据，然后下一个渔港”的执行口径
- 另外给海岸线检索窗口加了很小的边界扩展，避免贴边海岸线因为刚好不穿过 `bbox` 而被误判为空；但最终格网仍只在原始 `bbox` 内计算

### 2026-04-24 全国海岸 200m 底库现状核对

- 已确认仓库里存在全国海岸 200m 的融合层定义：
  - `out/navsea_national_navigation_fusion.sqlite`
  - `layer_registry` 里已注册 `coastline_200m`
- 但当前这份库里的 `fusion_cell` 仍然是空的，说明全国海岸 200m 真值格还没有实际落库
- 这意味着：
  - 现阶段不能直接拿这份 national fusion 库来替代 `C23-06_*_GML.zip`
  - 但后续一旦把全国海岸 200m 真值格填进去，这条 `PRC -> bbox -> 海岸格` 的路径就可以直接复用

### 2026-04-24 全国版海岸 200m 生成脚本已补齐

- 已新增全国版海岸 200m 生成脚本：
  - `coastline/build_japan_coast_grid.py`
- 该脚本默认扫描：
  - `coastline/C23-06_*_GML.zip`
- 当前处理方式是按单个 `C23-06` 包逐包生成 200m 底库，避免把全国海岸一次性合成一个巨大的几何对象
- 默认输出：
  - `out/coastline/japan_coast_grid/japan_coast_grid.sqlite`
  - `out/coastline/japan_coast_grid/japan_coast_grid.meta.json`
- 可选输出：
  - `japan_coastline.geojson`
  - `japan_grid.geojson`
- 已做语法验证：
  - `./.venv/bin/python -m py_compile coastline/build_japan_coast_grid.py`
- 说明：
  - 当前仓库里的 MySQL 样例导入链路仍然是福冈/佐贺配置
  - 全国海岸 200m 底库已经可以先单独生成，后续再把 MySQL / 前端导入入口切到这份全国底库

### 2026-04-24 全国海岸 200m 直写 MySQL 脚本已新增

- 已新增全国海岸 200m 直接写 MySQL 的脚本：
  - `coastline/build_japan_coast_grid_mysql.py`
- 该脚本会：
  - 自动扫描 `coastline/C23-06_*_GML.zip`
  - 逐包解析海岸线 GML
  - 投影到米制坐标
  - 生成 200m 海岸硬阻塞格
  - 直接写入 MySQL
- 默认 MySQL 数据库名：
  - `navsea_japan_coast_grid`
- 当前输出的主体表：
  - `navsea_grid_layer_meta`
  - `navsea_grid_package_stat`
  - `navsea_grid_cell`
- 已支持可选的 manifest 输出，便于后续再接前端或导出脚本

### 2026-04-24 全国海岸 200m MySQL 口径收紧为只存阻塞格

- 已把 `coastline/build_japan_coast_grid_mysql.py` 的写库口径收紧为：
  - 只写 `HARD_BLOCKED`
  - 不再把 `NAVIGABLE_CANDIDATE` 之类的安全可航格写入 MySQL
- 这样全国海岸底库和之前福冈/佐贺测试版的口径一致：
  - 底库只保留阻塞格
  - 候选安全格仅作为统计信息，不落库
- 这次修正是按用户明确要求对齐，不再混入可航行候选格，避免污染后续全国融合层口径

### 2026-04-23 日本海岸线底库确认

- 已确认本地 `coastline/` 目录下存在日本海岸线原始数据包：
  - `C23-06_*_GML.zip`
- 这些数据包为国土数值信息海岸线数据，包内包含：
  - `*_g.xml` 主几何文件
  - `*_Coastline.shp/.dbf/.shx` 辅助矢量文件
  - `KS-META-*.xml` 元数据
- 抽查结果显示：
  - 几何是 `gml:Curve`
  - 坐标是经纬度形式的 `lat lon`
  - `gml:boundedBy` 覆盖日本海域范围
- 这说明海岸线任务可以直接进入独立的路由底库预处理线：
  - 先做海岸线导入与清洗
  - 再做米制投影
  - 再做 200m fishnet / `hardBlocked` 标记
- 当前判断：
  - 这条线与现有九州可航栅格工程是兼容的
  - 但它更适合独立成“全国海岸线硬阻塞底库”模块，而不是直接塞进现有 MVT / 显示流水线

### 2026-04-23 福冈 / 佐贺海岸样例栅格

- 已新增样例生成脚本：
  - `coastline/build_fukuoka_saga_coast_grid.py`
- 已新增浏览器资产导出脚本：
  - `coastline/export_fukuoka_saga_map_assets.py`
- 已新增可视化预览页：
  - `src/pbf/navsea-coastline-fukuoka-saga.html`
- 已实际跑通输入包：
  - `coastline/C23-06_40_GML.zip`
  - `coastline/C23-06_41_GML.zip`
- 这两个包分别对应：
  - 福冈县
  - 佐贺县
- 输出样例库：
  - `out/coastline/fukuoka_saga_test/fukuoka_saga_coast_grid.sqlite`
- 当前样例规模：
  - 海岸线曲线数：`1067`
  - 200m 格子数：`710562`
  - `HARD_BLOCKED`：`9743`
  - `NAVIGABLE_CANDIDATE`：`700819`
- 当前输出体积：
  - 约 `118MB`
- 浏览器 GeoJSON 资产：
  - `src/pbf/coastline/fukuoka_saga_blocked_cells.geojson`
  - `src/pbf/coastline/fukuoka_saga_coastline_lines.geojson`
  - `src/pbf/coastline/fukuoka_saga_manifest.json`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/navsea-coastline-fukuoka-saga/`
  - 目录入口：`index.html`
- 当前结论：
  - 福冈 / 佐贺这条切片已经能作为 coastline 全国底库的第一版样例基线
- 下一步可以直接沿着同一脚本扩到其他県包
  - 最近一次重跑已按低资源方式执行：`nice -n 10`，并将外部线程压到 1
  - 新输出目录：
    - `out/coastline/fukuoka_saga_test_slow/`
  - 结果与原样例一致：
    - 海岸线曲线数：`1067`
    - 200m 格子数：`710562`
    - `HARD_BLOCKED`：`9743`
    - `NAVIGABLE_CANDIDATE`：`700819`

### 2026-04-23 九州港湾 / 渔港叠加预览

- 已新增港湾叠加导出脚本：
  - `coastline/export_port_overlay_kyushu_assets.py`
- 已新增港湾叠加预览页：
  - `src/pbf/navsea-port-overlay-kyushu.html`
- 数据源：
  - `out/navsea_kyushu_navigability_full_run.export_snapshot.sqlite`
- 已导出资产：
  - `src/pbf/port-overlay/kyushu/port_overlay_kyushu_areas.geojson`
  - `src/pbf/port-overlay/kyushu/port_overlay_kyushu_centers.geojson`
  - `src/pbf/port-overlay/kyushu/port_overlay_kyushu_manifest.json`
- 当前规模：
  - AOI 总数：`5907`
  - 漁港：`3169`
  - 一般港湾：`1830`
  - 小港湾：`908`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-port-overlay-kyushu/`
- 当前判断：
  - 这版先把港湾 / 渔港 AOI 叠加视图做出来了
  - 后续若要做 200m / 50m 分类格网，可以直接在这层基础上继续切分
  - 但这版目前仍是基于九州工程库里的 `port_aoi` 近似预览，不是正式的 `C02-08.zip / C09-06.zip` 原始港湾/渔港底图

### 2026-04-23 港湾数据源纠正

- 已确认港湾/渔港正式原始数据应来自：
  - `coastline/C02-08.zip`：国土数值信息（港湾）数据
  - `coastline/C09-06.zip`：国土数值信息（漁港）数据
- 当前九州预览中的圆形 AOI 仅是工程库近似叠加，不应作为正式港湾区域边界
- 下一步需要把港湾/渔港层从这两个原始包重新生成，再替换现有预览

### 2026-04-23 港湾正式源预览已接入

- 已新增正式源导出脚本：
  - `coastline/export_official_port_overlay_kyushu_assets.py`
- 已将预览页切换为正式源：
  - `src/pbf/navsea-port-overlay-kyushu.html`
- 已导出并部署正式资产：
  - `src/pbf/port-overlay-official/kyushu/official_port_overlay_kyushu_lines.geojson`
  - `src/pbf/port-overlay-official/kyushu/official_port_overlay_kyushu_points.geojson`
  - `src/pbf/port-overlay-official/kyushu/official_port_overlay_kyushu_manifest.json`
- 当前规模：
  - 线要素：`1965`
  - 点要素：`1366`
  - C02-08 港湾线：`721`
  - C09-06 漁港线：`1244`
- 预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-port-overlay-kyushu/`
- 说明：
  - 这版已经不再使用 `port_aoi` 近似圆圈
  - 现在读取的是 `C02-08.zip / C09-06.zip` 正式源

### 2026-04-23 coastline-only 港湾预览已切换

- 已新增仅依赖 `coastline/` 原始包的干净脚本：
  - `coastline/export_coastline_only_port_overlay_kyushu_assets.py`
- 已新增仅依赖 coastline 原始包的新页面：
  - `src/pbf/navsea-port-overlay-coastline-only-kyushu.html`
- 已导出正式资产：
  - `src/pbf/coastline-only/kyushu/coastline_only_port_overlay_kyushu_lines.geojson`
  - `src/pbf/coastline-only/kyushu/coastline_only_port_overlay_kyushu_points.geojson`
  - `src/pbf/coastline-only/kyushu/coastline_only_port_overlay_kyushu_manifest.json`
- 当前规模：
  - 线要素：`1965`
  - 点要素：`1366`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-port-overlay-coastline-only-kyushu/`
- 说明：
  - 这版不碰数据库
  - 只用 `coastline/C02-08.zip` 和 `coastline/C09-06.zip`
  - 作为后续正式港湾 / 渔港分类栅格的干净基线

### 2026-04-23 福冈 / 佐贺渔港 50m 栅格预览

- 已新增仅使用渔港数据的 50m 栅格导出脚本：
  - `coastline/export_fish_port_grid_fukuoka_saga_assets.py`
- 已新增对应浏览器预览页：
  - `src/pbf/navsea-fish-port-grid-fukuoka-saga.html`
- 数据源：
  - 仅使用 `coastline/C09-06.zip`
  - 仅保留 `PRC=40/41`
- 当前导出结果：
  - 渔港边界线：`128`
  - 50m 栅格：`5772`
  - `polygonize` 成功，未走线缓冲回退
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-fish-port-grid-fukuoka-saga/`
- 当前判断：
  - 这版已经去掉港湾层和中心点，只保留福冈 / 佐贺渔港
  - 适合作为后续渔港 50m 分类栅格的人工核查样例

### 2026-04-23 福冈 / 佐贺渔港 海面 / 陆基分层预览

- 已新增港内导航分层脚本：
  - `coastline/export_fish_port_navsplit_fukuoka_saga_assets.py`
- 已新增对应浏览器预览页：
  - `src/pbf/navsea-fish-port-navsplit-fukuoka-saga.html`
- 数据源：
  - `coastline/C09-06.zip` 渔港边界
  - `coastline/C23-06_40_GML.zip`
  - `coastline/C23-06_41_GML.zip`
- 分类目标：
  - `LAND_BASE`
  - `SEA_SURFACE`
- 当前导出结果：
  - 渔港边界线：`128`
  - 海岸线参考：`1067`
  - 50m 格网：`5772`
  - 其中陆基：`737`
  - 海面：`5035`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-fish-port-navsplit-fukuoka-saga/`
- 当前判断：
  - 这版已经不是单纯边界线，而是能在渔港范围内直接看出海面和陆基的分层
  - 适合作为后续导航路径规划的港内判定样例

### 2026-04-23 渔港层口径修正为 20m 不可航行格

- 已确认用户最新要求：
  - 海岸线继续使用 `C23-06_40/41` 做 `200m` 级别底座
  - 渔港层必须独立于海岸线，只使用 `C09-06.zip`
  - 渔港层改为 `20m` 小格，不再用海岸线去推导港内可达性
  - 渔港格子的语义改成“不可航行格”，用于导航底图的高密度港区阻断层
- 已据此重做渔港三层预览脚本：
  - `coastline/render_fukuoka_saga_three_layer_png.py`
- 已导出新版三层 PNG：
  - `src/pbf/coastline-only/fukuoka_saga_three_layer/fukuoka_saga_three_layer_v7.png`
- 当前三层口径：
  - 海岸线：`200m` 红色
  - 渔港：`20m` 不可航行格
- PBF 海上障碍：`50m` 黄色

### 2026-04-23 渔港 20m 重建脚本改为按 PRC 流式入库

- 已调整全国渔港重建脚本：
  - `coastline/build_fish_port_20m_full_mysql_resume.py`
- 这次改动的目标：
  - 不再一次性保留全部渔港线到内存
  - 改为先发现 PRC 列表，再按 PRC 一段一段收线、计算、入库
  - 每完成一个 PRC / cluster 就立即写 MySQL 并保存 checkpoint
- 当前运行方式：
  - 继续使用 `--resume`
  - 通过 checkpoint 接着上次 40 / 41 的验证断点往后跑
- 当前处理策略：
  - 渔港线只保留当前 PRC 的数据
  - 海岸线按 PRC 现算现用
  - 目标是把 swap 压低，避免全国版把内存顶满

### 2026-04-24 MySQL 栅格导出到 HTML 静态资产

- 已新增 MySQL 栅格静态资产导出脚本：
  - `coastline/export_navgrid_mysql_assets.py`
- 用途：
  - 从 `navsea_fukuoka_saga_grid.navsea_grid_cell` 导出页面使用的 GeoJSON
  - 输出到 `src/pbf/coastline-mysql/fukuoka_saga/`
  - 再同步到 `newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前福冈 / 佐贺测试页导出口径：
  - 海岸 `coast_200m`：全量，`9743`
  - 渔港 `fish_port_20m`：只导出 `PRC=40/41` 且 `LAND_BASE`，`2904`
  - 海上障碍 `hazard_50m`：全量，`176454`
- 当前测试页：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`

### 2026-04-24 渔港重建脚本增加心跳输出

- 已给 `coastline/build_fish_port_20m_full_mysql_resume.py` 加入运行心跳：
  - 每累计固定数量的 cell 就写一次库
  - 每次写库都会打印 `HEARTBEAT`
  - 输出包含：
    - `PRC`
    - `cluster`
    - 当前累计写入格数
    - 已用时间
- 目的：
  - 避免长跑任务在中间阶段看起来像“死掉”
  - 让你能从日志直接确认它还在持续推进

### 2026-04-24 渔港重建状态改为按 PRC 完成输出

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的日志粒度改小：
  - 取消批次级心跳输出
  - 每个 PRC 完成后只输出一条状态
  - 这条状态同时写入数据库进度表
- 新增进度表：
  - `navsea_grid_import_progress`
- 写入内容：
  - `job_name`
  - `layer_name`
  - `prc`
  - `status_name`
  - `cluster_count`
  - `inserted_cells`
  - `land_cells`
  - `sea_cells`
  - `elapsed_sec`
- 这样你手工看日志时不会被一堆中间行干扰，也能在数据库里查到每个渔港段的完成状态

### 2026-04-24 渔港重建日志改为更密集的屏幕输出

- 已再次加密 `coastline/build_fish_port_20m_full_mysql_resume.py` 的屏幕打印：
  - `PRC` 开始时打印一次
  - `cluster` 开始时打印一次
  - 每次批量提交时打印一次
  - `PRC` 完成时仍打印一次总结
- 这样长跑时你能从终端里更容易判断它不是卡住，而是在持续推进
- 业务写库节奏不变，还是按固定批量提交，并在数据库里保留进度记录

### 2026-04-24 渔港重建日志再细分到处理步骤

- 已继续把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的屏幕打印拆细：
  - `PRC` 开始
  - 读取海岸线
  - 海岸缓冲完成
  - cluster 数量
  - 每个 cluster 开始
  - cluster 合并渔港线
  - 生成格网
  - 写库完成
- 这样你在终端里可以直接看出卡在哪一步，不会只看到一个“开始”和一个“结束”

### 2026-04-24 渔港重建日志统一带时间戳

- 已给 `coastline/build_fish_port_20m_full_mysql_resume.py` 的状态输出统一加时间戳
- 当前日志格式：
  - `[YYYY-MM-DDTHH:MM:SS] [fish_port_20m] ...`
- checkpoint 语义不变：
  - 当前断点仍是 `last_prc = 45`
  - 所以下一次 `--resume` 会从 `46` 继续

### 2026-04-24 渔港 20m 格网生成提速

- 已优化 `coastline/build_fish_port_20m_full_mysql_resume.py` 的格网扫描逻辑：
  - 不再纯粹逐格创建 `box()` 后再判断
  - 先按整行做裁剪
  - 再用 `intersects_xy` 批量筛候选格子
  - 最后只对候选格子做精确几何判断
- 目标：
  - 降低 20m 扫格阶段的几何对象创建数量
  - 缩短每个 cluster 的格网生成时间

### 2026-04-24 渔港 20m 格网继续按扫描块分段

- 已把 `coastline/build_fish_port_20m_full_mysql_resume.py` 的格网扫描再切成更小的块：
  - 新增 `--scan-tile-m`
  - 默认按 `2000m` 级别分块扫描
  - 每个扫描块内再做 20m 网格判断
- 这样大 cluster 不会一次把整个外接框都压在同一个扫描循环里
- 目标是让单次停顿更短，也让日志更容易看出它正在持续推进

### 2026-04-24 渔港重建增加函数级耗时日志

- 已给 `coastline/build_fish_port_20m_full_mysql_resume.py` 的几个大函数加上统一 trace 日志：
  - `load_xml`
  - `discover_prcs`
  - `collect_fish_lines_for_prc`
  - `cluster_line_indices`
  - `load_coastlines_for_prc`
  - `build_cells_for_geometry`
  - `main`
- 日志会记录：
  - 函数名
  - 入参摘要
  - 开始时间
  - 完成耗时
  - 异常信息
- 目的：
  - 后面可以直接定位最耗时的步骤
  - 方便分析是解析、聚类、格网扫描还是写库最慢

### 2026-04-23 福冈 / 佐贺三层格网改为 MySQL 主存储

- 用户明确要求：三层网格不要再用 SQLite，改为 MySQL 主库保存，GeoJSON 仅作为导出和预览产物
- 已创建 MySQL 数据库：`navsea_fukuoka_saga_grid`
- 已建立两张表：
  - `navsea_grid_layer_meta`
  - `navsea_grid_cell`
- 已导入三层网格数据：
  - 海岸线 `200m`：`9743`
  - 渔港 `20m`：`2196`
  - 海上危险 `50m`：`183339`
- 海上危险层只取 PBF 中的航行危险语义，不包含鱼礁
- 已生成并写出 MySQL 导出资产：
  - `src/pbf/coastline-mysql/fukuoka_saga/coast_200m_grid.geojson`
  - `src/pbf/coastline-mysql/fukuoka_saga/fish_port_20m_grid.geojson`
  - `src/pbf/coastline-mysql/fukuoka_saga/hazard_50m_grid.geojson`
  - `src/pbf/coastline-mysql/fukuoka_saga/manifest.json`
- 已将预览页切到 MySQL 导出资产：
  - `src/pbf/navsea-fukuoka-saga-coast200-fish20-full.html`
  - 版本：`v2.0`
- 已部署到预览目录：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前判断：
  - MySQL 已经成为这组福冈 / 佐贺三层格网的主存储
  - 后续需要导出或审核时，再从 MySQL 导出 GeoJSON 即可，不再依赖 SQLite 主库

### 2026-04-23 修正渔港 20m 未显示的问题

- 用户反馈页面上 20m 渔港格没有出来
- 复查发现页面代码错误地按不存在的 `classification` 字段过滤渔港格
- 实际导出字段为：
  - `state_name`
  - `class_name`
- 已修正页面逻辑：
  - 只保留 `state_name === "LAND_BASE"` 或 `class_name === "LAND_BASE"` 的 20m 格
- 已重新部署到：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前判断：
  - 20m 渔港格本身是存在的
  - 之前没有显示纯粹是前端筛选字段写错，不是 MySQL 数据缺失

### 2026-04-23 神集岛危险物位置复核

- 用户指出神集岛附近一处渔网在 PBF 预览中明显偏北，和官方海图不一致
- 已复核神集岛附近的同一 z12 tile（`12/3526/1642`）在多个交付根中一致：
  - `pbf-delivery-kyushu-reencoded`
  - `pbf-delivery-full-20260418-rebuild`
  - `pbf-delivery-full-semantic-20260416`
  - `pbf-delivery-full-20260415`
- 复核到的 `fixed_fishing_gear_area` 位置大致落在：
  - 经度 `129.965 ~ 129.985`
  - 纬度 `33.543 ~ 33.553`
- 对比神集岛附近参考点（神集岛ヘリポート）约为：
  - 经度 `129.96885`
  - 纬度 `33.54101`
- 这说明当前 PBF 源里的危险物位置确实位于岛北侧，而不是用户给出的海图中红框的东南侧
- 当前判断：
  - 这不是 MySQL 导入或 HTML 渲染造成的偏移
  - 也不是单个交付根的偶发问题
  - 更像是 PBF 危险物源数据本身与目标海图存在位置偏差
- 后续如果要继续把危险物层用于导航规划，需要额外做源数据校正或改用更可信的危险物来源
- 已把新版预览页部署到：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前结论：
  - 渔港层已经从“海岸辅助红绿判定”切换为“港区自身 20m 阻断栅格”
  - 后续如果要再细分港内通道，需要在这个 20m 纯港区底图之上再叠加更细规则，而不是回头用海岸线推导港内状态

### 2026-04-23 福冈 / 佐贺渔港 25m 海面 / 陆基分层预览

- 已新增 25m 版本脚本：
  - `coastline/export_fish_port_navsplit_fukuoka_saga_assets.py`
- 已新增对应浏览器预览页：
  - `src/pbf/navsea-fish-port-navsplit-fukuoka-saga-25m.html`
- 参数：
  - `cell_size_m = 25`
  - `coast_buffer_m = 15`
- 当前导出结果：
  - 渔港边界线：`128`
  - 海岸线参考：`1067`
  - 50m 预览时的 5772 格，扩细后为 `22535` 格
  - 其中陆基：`1742`
  - 海面：`20793`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-fish-port-navsplit-fukuoka-saga-25m/`
- 当前判断：
  - 25m 明显更适合看窄水道、泊位前缘和贴岸转折
  - 这版比 50m 更重，但对导航底库更有价值

### 2026-04-23 福冈 / 佐贺渔港 20m 海面 / 陆基分层预览

- 已新增 20m 版本脚本复用：
  - `coastline/export_fish_port_navsplit_fukuoka_saga_assets.py`
- 已新增对应浏览器预览页：
  - `src/pbf/navsea-fish-port-navsplit-fukuoka-saga-20m.html`
- 参数：
  - `cell_size_m = 20`
  - `coast_buffer_m = 12`
- 当前导出结果：
  - 渔港边界线：`128`
  - 海岸线参考：`1067`
  - 20m 格网：`35026`
  - 其中陆基：`2196`
  - 海面：`32830`
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-fish-port-navsplit-fukuoka-saga-20m/`
- 当前判断：
  - 20m 已经足够细，港内边角和窄通道会更清楚
  - 数据量继续上升，但仍然适合样区核查

### 2026-04-23 福冈 / 佐贺渔港 港内可通行 / 不可通行预览

- 已新增导航语义视图页面：
  - `src/pbf/navsea-fish-port-navpass-fukuoka-saga-20m.html`
- 语义映射：
  - `SEA_SURFACE -> PORT_PASSABLE`
  - `LAND_BASE -> PORT_BLOCKED`
- 仍沿用 20m 分类格网数据，不重新算几何
- 已部署到可直接打开的预览地址：
  - `http://192.168.200.184/newpec/coastline/navsea-fish-port-navpass-fukuoka-saga-20m/`
- 当前判断：
  - 这版更贴近导航场景，直接表达“能不能走”
  - 后续如果认可这个口径，可以把该语义正式写入导出数据

### 2026-04-23 全国导航融合骨架

- 已新增全国融合计划文档：
  - `tasks/route/NavSea_National_Navigation_Fusion_Plan_v1.md`
- 已新增全国融合骨架脚本：
  - `navsea_national_navigation_fusion.py`
- 已写出模板配置：
  - `tasks/route/NavSea_National_Navigation_Fusion_Plan_v1.template.json`
- 已初始化融合骨架 SQLite：
  - `out/navsea_national_navigation_fusion.sqlite`
- 已写出骨架 manifest：
  - `out/navsea_national_navigation_fusion.manifest.json`
- 当前判断：
  - 这不是旧样区延伸，而是从零开始的全国融合容器
  - 后续可以按统一 schema 接入海岸线 200m、渔港 20m 和 PBF 障碍层
  - 海岸线输入已明确只使用 `coastline/` 原始包，不再混入 PBF 来源

### 2026-04-22 语义小库设计

- 明确了海上路径检索和危险物碰撞检测可以抽成一个派生语义小数据库
- 新增文档：
  - `tasks/pbf/NavSea_semantic_query_index_design.md`
- 当前推荐定位：
  - PBF 负责完整载体和渲染
  - 小数据库负责语义索引、碰撞检测、路径检索
  - 两者通过 `fid` 和 `render_layer / source_layer_std` 互相回查
- 进一步补充了移动设备落地口径：
  - 推荐单文件 SQLite
  - 用 `semantic_object + semantic_geometry + grid_cell` 三层结构
  - 格网层负责快速判定，几何层负责精确验证

### 2026-04-22 九州 SQLite 落库

- 已生成九州轻量语义 SQLite：
  - `out/navsea_kyushu_semantic.sqlite`
- 对应生成脚本：
  - `navsea_build_kyushu_sqlite.py`
- 当前内容规模：
  - `semantic_object`：`1786316`
  - `grid_cell`：`65147`
- 这版 SQLite 重点保留：
  - `P陸域` / `P穴`
  - `collision`
  - `grounding`
  - `navigation_mark`
  - `boundary_reference`
  - `route_reference`
- 这版不再追求完整渲染几何，目标是让移动端可以直接做航线规划和危险检测查询

### 2026-04-22 九州核心 SQLite 压缩版

- 进一步压缩生成了核心版：
  - `out/navsea_kyushu_core.sqlite`
- 当前体积：
  - `178MB`
- 当前内容规模：
  - `semantic_object`：`1058445`
  - `grid_cell`：`26231`
- 核心版只保留：
  - `P陸域`
  - `P穴`
  - `collision`
  - 浅水搁浅层
- 核心版去掉了：
  - `navigation_mark`
  - `boundary_reference`
  - `route_reference`
  - 其他非必要辅助对象
- 适合更紧的移动端包体和更快的本地查询

### 2026-04-22 最终发布字段清单

- 整理了接近发布版的字段边界说明：
  - `tasks/pbf/NavSea_Final_Release_Field_List.md`
- 这份文档把字段分成了四类：
  - 必留字段
  - 推荐保留字段
  - 工程版专属字段
  - 旧字段兼容集
- 当前特别要盯住的点：
  - `fid` 和 `render_layer` 不能在最终发布版里被误裁掉
  - `fid_legacy_raw`、`trace_status`、`source_layer_jp` 等应留在工程版或 trace 口径
  - 最终发布版应以 `fid + render_layer + canonical_* + chart_*` 为核心

### 2026-04-22 九州可航行性测试版试跑

- 新增测试脚本：
  - `navsea_build_kyushu_navigability_test.py`
- 这条线当前目标不是“九州全海域一次性全精度栅格化”，而是先验证：
  - `z12` 几何恢复到 Web Mercator 的流程可跑
  - `200m` 主层和港口 `50m` 细化层的 SQLite 结构可落
  - `tile default + sparse/refined grid` 的双层查询口径可用
- 本轮试跑确认了两个关键现实：
  - 按 feature 逐个落 `200m` 格子，写放大和内存放大会非常重，不适合九州全量直接跑
  - 更合理的测试口径应先收敛到：
    - 九州全域保留 `z12 tile default=open_water`
    - 只对港口触发 tile 做 `200m/50m` 细化
- 这条线后续若要继续推进，优先方向应是：
  - tile 级批处理
  - 港口/近岸 AOI 优先
  - 不再对纯开放水域做全量细格预烘焙
  - 现已把脚本收成可切换：
    - `full-domain`
    - `port-tiles`

### 2026-04-22 路径规划快照回查核对

- 额外核对了 `P陸域` / `P穴` 的回查链路
- 当前 `pbf_analysis` 中，通过 `feature_geojson_lookup` 关联后：
  - `P陸域` 的 `fid` 不是空
  - `P穴` 的 `fid` 也不是空
- 这说明：
  - `landIdentifiers` 里出现大量 `fid=null`，更像是消费端快照组装时没有正确 join 回查表
  - 不是当前 `pbf` 源数据天然缺 `fid`
- 另一个容易混淆的点：
  - `land_area` 不是 `feature_geojson_lookup` 里的原始 `vt_layer` 名
  - 它是语义/样式层名，真正应回查的是 `P陸域` / `P穴` 这类对象层

### 2026-04-23 移动端发布包口径

- 已明确当前 `12G` 级别九州全域库只能作为工程库，不适合直接下发移动端
- 新增方案文档：
  - `tasks/pbf/NavSea_移动端可航栅格压缩方案_2026-04-23.md`
- 已新增移动核心包导出脚本：
  - `navsea_export_mobile_core_sqlite.py`
- 当前导出方式：
  - 先从工程库做 SQLite 一致性快照
  - 再从快照里导出非 `open_water` 的稀疏核心格
- 当前推荐发布口径：
  - 工程全域库继续保留在服务端
  - 移动端核心包只保留稀疏 `200m`
  - `50m` 只作为港口增量包

### 2026-04-21 航线规划 Q1 对接答复

- 基于当前仓库里的 builder、Domain、样式和对象保全审计，整理了：
  - `tasks/route/Q1_answer.md`
- 这份答复明确区分了三类结论：
  - 当前仓库已证实
  - 当前只能谨慎判断
  - 仍需上游 PBF 生产侧确认
- 当前给航线规划的保守口径先定为：
  - `z10-z12` 是建议工作区间
  - `z12` 是最保守可靠级别
  - `outline/boundary` 不作为 polygon 重建来源
  - `land_area` 是唯一陆海主判定层
  - 关键规划对象不能只看 style `minzoom`，要区分数据保留与显示起点

### 2026-04-16 图标改进与语义迁移

- 完成了新旧 sprite / 图标键的梳理与迁移准备
- 形成了语义版图标映射和审计材料：
  - `src/pbf/semantic_sprite_key_map_2026-04-16.json`
  - `src/pbf/style.navsea-delivery-full-semantic.json`
  - `tasks/pbf/NavSea_Sprite_Audit_2026-04-16.*`
  - `tasks/pbf/NavSea_Sprite_Audit_newpec_style_with_pbf_2026-04-16.*`
- 相关目标：
  - 让 full / semantic 的图标来源、命名和可审计性对齐
  - 方便后续对比新旧 style 时追查具体 icon 差异

### 2026-04-17 pickup 相关

- 补了 pickup 解释链与点击定位链路：
  - `src/pbf/navsea-pickup-interpreter.ts`
  - `src/pbf/navsea-pickup-interpreter.js`
  - `src/pbf/navsea-pickup-rules.v1.json`
  - `src/pbf/navsea-click-target-karatsu-20nm.html`
  - `src/pbf/navsea-pickup-test-karatsu-20nm.html`
- 目标：
  - 让当前点选对象的解释、迁移、回放更稳定
  - 方便把 pickup 规则直接纳入人工审计页

### 2026-04-18 全国审计与重建

- 建了全国 full / semantic 的几何、extent、native 风险审计
- 建了全国固定 AOI 的截图对比审计
- 把全国人工审计页改成可切换 `variant=full / semantic`
- 支持右侧 `deliveryTileUrl` 覆盖，便于直接拿 rebuild 产物做对比
- 已确认并修掉两类问题：
  - `extent=4096` 的错退片
  - 旧坏 tile 的几何坐标漂移
- 已做 AOI 固定点：
  - 博多港中心 `10nm`
  - 东京湾 `10nm`
  - 大阪 `10nm`
  - 冲绳 `10nm`
  - 唐津 `5nm`

## 审计方法

### 1. 物体保全审计

- 脚本：
  - `navsea_object_preservation_audit.py`
- 用法要点：
  - 优先看对象是否被保留、合并、丢失
  - delivery 侧尽量用可追溯字段做比对
- 经验基线：
  - `Karatsu 10nm`
  - `--fid-key 'thisMyWorld@2026'`
  - `--match-on-fid-only`

### 2. render 审计

- 脚本：
  - `navsea_render_audit.py`
- 作用：
  - 看 delivery 与 source 的渲染结果是否一致
  - 先排除对象被错误合并/丢失，再看视觉

### 3. AOI 截图对比审计

- 脚本：
  - `navsea_full_aoi_visual_audit.py`
- 页面：
  - `src/pbf/navsea-compare-full-audit.html`
- 方法：
  - 左右截图
  - 取固定 AOI
  - 计算图像 diff
  - 重点看 `zoom 10 / 12`

### 4. extent / native 风险审计

- 脚本：
  - `navsea_geometry_native_audit.py`
  - `navsea_extent_shift_audit.py`
  - `navsea_tile_reencode_guard.py`
- 目的：
  - 先抓 `extent=1048576` 相关回退、错重编码、几何越界
  - 再把视觉差异与真正的几何风险分开

### 5. 热点重建审计

- 脚本：
  - `navsea_rebuild_hotspot_tiles.py`
- 目的：
  - 对固定 AOI 热点先重建 full，再刷新 semantic
  - 用来确认坏 tile 是历史产物还是当前 builder 问题

## 当前结论

- `full / semantic` 的 `z12 extent` 错退问题已修正
- 旧坏 tile 的几何漂移已定位并重建
- 当前 AOI 高 diff 主要是 full / semantic 与原始 `newpec` 的整体表达差异
- 视觉审计继续优先看：
  - 图标是否对
  - pickup 是否对
  - AOI 截图是否仍有几何级异常

## 继续工作的保留点

- pickup 相关文件优先看：
  - `src/pbf/navsea-pickup-interpreter.ts`
  - `src/pbf/navsea-pickup-rules.v1.json`
  - `src/pbf/navsea-click-target-karatsu-20nm.html`
- 图标相关文件优先看：
  - `src/pbf/style.navsea-delivery-full-semantic.json`
  - `src/pbf/semantic_sprite_key_map_2026-04-16.json`
  - `tasks/pbf/NavSea_Sprite_Audit_2026-04-16.*`
- 审计相关文件优先看：
  - `navsea_object_preservation_audit.py`
  - `navsea_render_audit.py`
  - `navsea_geometry_native_audit.py`
  - `navsea_extent_shift_audit.py`
  - `navsea_full_aoi_visual_audit.py`
  - `navsea_rebuild_hotspot_tiles.py`

## 2026-04-18 full 全国版状态

- 已合并完成：
  - `/home/wwwroot/pbf-delivery-full-20260418-rebuild`
- 合并后总瓦片数：
  - `65148`
- zoom 分布：
  - `z0=1`
  - `z5=10`
  - `z6=27`
  - `z7=76`
  - `z8=230`
  - `z9=813`
  - `z10=3156`
  - `z11=12279`
  - `z12=48556`
- 当前可继续做的事：
  - 全量 extent / native 审计
  - 全量 AOI 截图对比审计
  - 需要时再把该目录切换给 compare page 做最终人工审查

## 2026-04-18 full 最终审计状态

- 已完成：
  - 全国分片重建
  - 全国根目录合并
  - 几何 / extent / native 审计
  - 全国固定 AOI 截图对比审计
- 当前结论：
  - `full` 根目录已可用于继续做人工视觉审查
  - `extent=1048576` 的高精度 tile 仍然是统一口径
  - AOI 高 diff 主要仍是和原始 `newpec` 的整体视觉差异，不是旧坏片那种几何炸裂
- 备注：
  - 全量 `extent shift` 长扫耗时过大，已暂停，后续如需可改成更小范围抽样或直接复用几何审计结论

## 2026-04-23 福冈/佐贺海岸线预览已部署

- 已把福冈/佐贺海岸线 200m 栅格预览页部署到：
  - `/mnt/sda1/www/newpec/coastline/navsea-coastline-fukuoka-saga/`
- 页面入口：
  - `http://192.168.200.184/newpec/coastline/navsea-coastline-fukuoka-saga/`
- 页面资源：
  - `index.html`
  - `coastline/fukuoka_saga_manifest.json`
  - `coastline/fukuoka_saga_blocked_cells.geojson`
  - `coastline/fukuoka_saga_coastline_lines.geojson`
- 数据来源：
  - `coastline/C23-06_40_GML.zip`
  - `coastline/C23-06_41_GML.zip`
- 说明：
  - 这版是只用 `coastline/` 原始包做的福冈/佐贺海岸线预览，不使用 PBF 海岸线数据

## 2026-04-23 福冈/佐贺海岸 200m + 渔港 20m 合并预览

- 新增合并预览页：
  - `/mnt/sda1/www/newpec/coastline/navsea-fukuoka-saga-coast200-fish20/`
- 页面入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20/`
- 页面内容：
  - 海岸线 `200m` 硬阻塞格网
  - 渔港 `20m` 海面/陆基格网
  - 海岸线轮廓与渔港边界同时显示
- 数据来源：
  - 海岸线：`coastline/C23-06_40_GML.zip`、`coastline/C23-06_41_GML.zip`
  - 渔港：`coastline/C09-06.zip`

## 2026-04-23 渔港范围内 20m 覆盖 200m

- 已将合并预览页调整为：
  - 渔港 `20m` 范围内不再显示海岸 `200m` 格子
  - 海岸 `200m` 只保留在渔港范围外作为骨架层
- 这样更符合后续导航分层：
  - 海岸层负责全国骨架
  - 渔港层负责港内细分

## 2026-04-23 渔港 20m 改为绿色显示

- 已将福冈/佐贺合并预览中的渔港 `20m` 图层改为绿色系
- 海岸 `200m` 仍保持淡红色
- 这样更容易在同一张图上区分：
  - 红色：海岸骨架
  - 绿色：渔港港内格网

## 2026-04-23 福冈 / 佐贺渔港全量 raster 预览

- 已把福冈 / 佐贺全量渔港 AOI 渲染成 20m 分辨率的 raster 叠加图
- 输出文件：
  - `src/pbf/coastline-only/fukuoka_saga_fish_port_navsplit_full_20m_aoi/fish_port_navsplit_fukuoka_saga_full_20m_aoi.png`
  - `src/pbf/coastline-only/fukuoka_saga_fish_port_navsplit_full_20m_aoi/fish_port_navsplit_fukuoka_saga_full_20m_aoi_raster_manifest.json`
- 预览页：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 说明：
  - 这版是全量 AOI raster，不再把渔港 20m 数据铺成超大的 GeoJSON
  - 更适合浏览器直接查看全范围覆盖情况

## 2026-04-23 福冈 / 佐贺三层预览口径

- 已把全量预览页调整为三层语义：
  - 红色：海岸线 `200m` 硬阻塞
  - 绿色：渔港内 `20m` 不可航行区域
  - 黄色：海上的渔网 / 标识 / 障碍
- 黄色层来源：
  - `navsea_delivery` 向量瓦片中的海上障碍语义层
- 当前预览页版本：
  - `v1.1`

## 2026-04-23 渔港重叠区改为红色 20m 小框

- 已根据最新确认把渔港层进一步收紧：
  - 海岸线仍按 `200m` 红色骨架保留
  - 渔港层只显示与海岸重叠的 `20m` 红色小框
  - 不再使用绿色渔港块表达港内范围
- 渔港层最新导出结果：
  - `src/pbf/coastline-only/fukuoka_saga_three_layer/fukuoka_saga_three_layer_v8.png`
  - `src/pbf/coastline-only/fukuoka_saga_three_layer/fukuoka_saga_three_layer_manifest.json`
- 页面已更新为：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前页面版本：
  - `v1.5`
- 当前判断：
  - 渔港层现在已经和海岸层解耦
  - 重叠区按渔港 `20m` 红色小框表达，更符合导航底图的视觉语义

## 2026-04-23 渔港层切回 20m GeoJSON 小格

- 已根据最新对照图重新修正渔港层表达：
  - 不再使用 `v8.png` 那张 raster 贴图
  - 改为直接读取 `fish_port_navsplit_fukuoka_saga_20m_grid.geojson`
  - 渔港层按 `20m` 小格绘制
  - 视觉上只保留红色小框，不再画绿色大块
- 新页面版本：
  - `v1.6`
- 新页面入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前判断：
  - 这才是用户要的港内细格表达
  - 渔港层应由真正的 20m 格网构成，而不是整块 raster 贴图

## 2026-04-23 渔港 20m 范围内裁掉海岸 200m

- 已继续修正合并预览的显示规则：
  - 渔港 `20m` 小格出现的位置，海岸 `200m` 大格不再显示
  - 海岸格网只保留在渔港范围外
- 页面版本更新为：
  - `v1.7`
- 当前入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前判断：
  - 这条规则更符合用户的直觉要求
  - 渔港层和海岸层在视觉上不再重叠抢位

## 2026-04-23 渔港层只保留不可航行红格

- 已继续收紧渔港层显示：
  - 只保留 `LAND_BASE` 对应的红色 20m 小格
  - `SEA_SURFACE` 不再显示
  - 渔港范围内只看不可航行格
- 页面版本更新为：
  - `v1.8`
- 当前入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前判断：
  - 这才符合“有小格子的地方只保留红格”的最终口径
  - 渔港层现在只表达阻断，不再表达可通行海面

## 2026-04-23 神集岛原始几何复核

- 已回到最原始的 `newpec` MVT 瓦片核对神集岛附近的渔具定置区：
  - 瓦片路径：`/home/wwwroot/newpec/exported_auto/tile.mapple-on.jp__newpec-mvt-20260106__z___x___y_.pbf/tiles/12/3526/1642.pbf`
  - 对应原始层：`P漁具定置箇所`
- 该瓦片里与神集岛相关的两个对象是：
  - `fid=18003411`
    - 顶点范围约 `lon 129.965292 ~ 129.966978`
    - 顶点范围约 `lat 33.543513 ~ 33.545354`
    - 落在岛西北侧/北侧近岸
  - `fid=18003509`
    - 顶点范围约 `lon 129.976376 ~ 129.985278`
    - 顶点范围约 `lat 33.547511 ~ 33.553343`
    - 落在岛东北侧外海
- 结论：
  - 这两条原始几何都不在用户手绘红框的东南侧位置
  - 说明我们当前抓到的 `newpec` 原始瓦片，和用户手头“右图”所指的位置并不一致
  - 后续如果要把黄格落到红框处，不能只改栅格逻辑，必须换源、换对象，或者先确认红框对应的具体图层 / fid

## 2026-04-23 福冈 / 佐贺预览切换为 semantic style 底图

- 已把当前三层栅格预览页的底图切换为：
  - `http://192.168.200.184/newpec/domain/style.navsea-delivery-full-semantic.json`
- 更新后的页面仍保留三层格网叠加：
  - 海岸 `200m`
  - 渔港 `20m`
  - 海上障碍 `50m`
- 页面版本已更新到：
  - `v2.1`
- 当前页面文件：
  - `src/pbf/navsea-fukuoka-saga-coast200-fish20-full.html`
- 当前部署入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`

## 2026-04-23 神集岛渔具定置区偏移再次确认

- 在切换为 `style.navsea-delivery-full-semantic.json` 底图后，神集岛附近的黄色渔具定置网格仍然明显落在岛北侧/东北侧，而不是用户标出的东南红框位置。
- 这进一步说明：
  - 不是当前底图样式导致偏移
  - 不是栅格绘制逻辑导致偏移
  - 而是原始 `newpec` 瓦片里的渔具定置几何与用户参考图存在位置不一致

## 2026-04-23 神集岛坐标原点修正

- 重新核对 `newpec` 原始瓦片后发现，之前的判断漏掉了一个关键点：
  - 这批瓦片的 tile 内几何 y 轴应按“底部原点”理解
  - 之前在若干转换脚本里误用了“顶部原点”的反向换算
- 复核示例：
  - `fid=18003509`
  - 使用底部原点换算后，中心点约为 `129.980826, 33.532361`
  - 这已经明显比之前的错误换算更接近用户图上的南侧位置
- 已修正脚本：
  - `coastline/build_fukuoka_saga_navgrid_mysql.py`
  - `coastline/render_fukuoka_saga_three_layer_png.py`
  - `navsea_mvt_to_geojson.py`
- 已重新导入福冈 / 佐贺 MySQL 三层格网：
  - 海岸 `200m`：`9743`
  - 渔港 `20m`：`2196`
  - 海上障碍 `50m`：`176454`
- 当前页面版本：
  - `v2.2`
- 结论：
  - 之前把 tile y 轴方向看反了，这是这次渔网位置异常的主要根因
  - 现在应以新导入的三层格网为准，再继续核对神集岛附近的黄格位置

## 2026-04-23 全国渔港 20m 全量重建脚本已启动

- 新增脚本：
  - `coastline/build_fish_port_20m_full_mysql_resume.py`
- 脚本职责：
  - 直接读取 `coastline/C09-06.zip`
  - 按 `PRC` 分组处理全国渔港
  - 使用对应的 `coastline/C23-06_{PRC}_GML.zip` 做海岸线叠加分类
  - 将 `fish_port_20m` 重新写入 MySQL
  - 支持 `--reset-layer` 清空旧数据
  - 支持 `--resume` 断点续跑
- 已验证样例：
  - `PRC=40/41` 试跑成功
  - 福冈 / 佐贺先导结果：`35026` 个 20m 格子
- 当前全国续跑状态：
  - 已从断点 `last_prc=40` 继续执行
  - 运行命令：`env PYTHONUNBUFFERED=1 nice -n 10 ./.venv/bin/python coastline/build_fish_port_20m_full_mysql_resume.py --resume`
  - 该任务会从 `PRC=41` 往后继续扫全国渔港

## 2026-04-23 内存与交换空间诊断

- 当前机器 swap 使用约 `1.4GiB`，但不是单一 Python 进程独占导致。
- 现阶段主要常驻进程占用包括：
  - VSCode / Pylance 相关 Node 进程，RSS 较高
  - MySQL 守护进程
  - 当前全国渔港重建 Python 进程
- 当前全国渔港脚本自身 RSS 约几百 MB 级，属于可控范围，但如果后续把更多 PRC 的几何一次性装入内存，仍有继续上涨风险。
- 后续若要进一步压内存，优先优化方向是：
  - 按 PRC 分段加载，不要长期保留所有渔港线
  - 海岸线几何按 PRC 现算现丢
  - 更细粒度地分批提交 MySQL

## 2026-04-24 福冈 / 佐贺三层预览 UI 可视性修正

- 已把 `navsea-fukuoka-saga-coast200-fish20-full.html` 的海岸 `200m` 颜色改为绿色，避免和渔港红格混淆。
- 已给左侧预览面板增加收起 / 展开按钮，折叠后只保留标题和切换按钮，尽量把地图画面让出来。
- 当前页面版本更新到：
  - `v2.5`
- 当前部署入口：
  - `http://192.168.200.184/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`

## 2026-04-24 海岸 200m 遮罩逻辑回退

- 复核发现：页面之前把海岸 `200m` 图层按 `fish_port_20m` 的 bbox 做了遮罩，导致用户在当前港区附近看不到该层的大量格子。
- 这不是坐标系错误，`coast_200m` 和 `fish_port_20m` 的 GeoJSON 坐标都还是经纬度。
- 已回退前端遮罩逻辑，改成直接显示完整的 `coast_200m`。
- 页面版本已继续更新到：
  - `v2.6`

## 2026-04-24 渔港 20m 外扩增强

- 当前测试里，`fish_port_20m` 还偏“贴线”，港区外围包络不够完整。
- 已给 `coastline/build_fish_port_20m_full_mysql_resume.py` 增加渔港几何外扩参数：
  - `--fish-buffer-m`
- 默认值已提升到 `120m`，用于把 20m 栅格更完整地围住港区，避免只剩边缘带状格子。

## 2026-04-24 渔港 20m 改为直接跟随 200m 粗格扫描

- 结合呼子港的实际结果，确认之前“先渔港线、再外扩、再切 20m”的办法会把湾内区域漏掉。
- 现在改成：
  - 先抓出当前渔港范围命中的 `coast_200m` 粗格
  - 直接把这些 `200m` 粗格作为 `20m` 细扫底盘
  - 再用同一套海岸线缓冲碰撞逻辑筛出 `COASTLINE`
- 这样 20m 的范围会更接近用户手工圈出的那几块红框，而不是只沿着港岸线出一圈带状格。

## 2026-04-24 呼子港重跑结果已更新

- 这次重跑后，`fish_port_20m` 总数已经从旧版的 `28726` 提升到 `126888`。
- 当前按 PRC 统计：
  - `PRC=40`：`12798`
  - `PRC=41`：`114090`
- 呼子港附近局部 bbox 内也能看到明显的陆 / 海混合格，不再是只剩外围带状格。
- 已重新导出并同步到 Web 目录：
  - `/mnt/sda1/www/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`

## 2026-04-24 福冈 / 佐贺结果导出与 Web 同步

- 已从 MySQL 重新导出三层静态数据：
  - `coast_200m: 9743`
  - `fish_port_20m: 28726`
  - `hazard_50m: 176454`
- 导出时 `fish_port_20m` 只保留 `LAND_BASE`。
- 已同步到 Web 目录：
  - `/mnt/sda1/www/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前页面版本：
  - `v2.6`

## 2026-05-03 PRC 与 FPC 对照确认

- 已确认 `FPC=4320065` 在原始 `C09-06.zip` 里对应的 `PRC` 是 `40`，不是 `50`。
- 这意味着它应当和 `--prc 40` 的结果对比，而不是和 `--prc 50` 对比。
- 已将 `fish_port_20m` 的唯一键改为 `UNIQUE KEY (layer_name, source_name, cell_id)`，让不同港口的同名格子不再互相覆盖。
- 全国导出层也补了按 `cell_id` 去重，避免同一格在全国 GeoJSON 里重复输出。
- 结论：`--prc` 与 `--fpc` 现在在落库层面已经按港独立了，后续如果再出现差异，就只需要查几何或海岸线输入，不用再怀疑存储覆盖。

## 2026-05-04 v2 导入脚本参数整理

- 已更新 `coastline/navgrid_v2/NavSea_v2_使用说明.md`，把三个 v2 导入脚本的参数开关单独列清楚。
- 重点补了鱼港 20m 的跳过与回退逻辑说明：
  - `--resume`
  - `--no-resume`
  - `--prc`
  - `--fpc`
  - `--skip-missing-coarse`
  - `--allow-unbounded-fallback`
- 沿岸与海上障碍两个导入脚本也补了参数用途说明，避免后续维护时再回到代码里找开关含义。

## 2026-05-04 coastline 最终目标确认

- 已在 `coastline/navgrid_v2/NavSea_v2_使用说明.md` 中明确：
  - `coastline` 这条链路的最终目标是导出阻断墙 `bin`
- 同时把生成顺序调整为：
  - 三类数据重建
  - 静态资产导出
  - 阻断墙二进制输出
- 后续如果再改表结构或导出逻辑，都以最终 `bin` 可用为收口标准。

## 2026-05-04 阻断墙 bin 支持切换海岸线层

- 已更新 `coastline/navgrid_v2/build_coast_wall_z12_bin.py`
  - 新增 `--coast-cell-size-m`
  - 新增 `--coast-layer-name`
- 默认仍按 `coast_200m` 生成 bin。
- 现在可以直接切到 `coast_100m` 或 `coast_50m`，前提是对应的 v2 海岸线表已重新生成。
- 使用说明也已同步到 `coastline/navgrid_v2/NavSea_v2_使用说明.md`。

## 2026-05-04 导入脚本的批量 resume 边界说明

- 已在 `coastline/navgrid_v2/NavSea_v2_使用说明.md` 里补充：
  - 沿岸数据支持 `--resume + --start-code` 的批量续跑
  - 渔港 20m 支持全国批量 `--resume`
  - 一旦显式指定 `--prc` 或 `--fpc`，渔港脚本会进入指定区域完整重算模式，并忽略原来的 resume 断点
- 这样后续维护时可以直接按两种模式理解：
  - 全国续跑
  - 指定区域重算

## 2026-05-04 海上障碍导入日志统一为时间戳

- 已更新 `coastline/navgrid_v2/build_hazard_50m_mysql.py`
  - 统一改用带时间戳的 `log()` 输出
  - 现在和沿岸、渔港两支一样，导入时更容易看出当前跑到哪一步
- 这样三支 v2 导入脚本的主流程日志格式已经统一。

## 2026-05-04 海上障碍 50m 轻量记录 fid

- 已更新 `coastline/navgrid_v2/build_hazard_50m_mysql.py`
  - 海上障碍 50m 不再追完整来源链
  - `navsea_hazard_grid_cell.source_name` 直接记录代表性的 `fid`
- `NavSea_v2_使用说明.md` 也同步说明了这条约定
- 这样海障这组的记录更轻，符合当前“只记 fid”的维护策略。

## 2026-05-04 来源字段的运维用途确认

- 已在 `NavSea_v2_使用说明.md` 中明确：
  - 来源字段除了追溯，还用于检查、删除某个指定来源的数据，以及按来源做 resume / 复跑
- 这也是 v2 表分离和 cell 来源显式化的主要原因之一。

## 2026-05-04 海障来源索引补齐

- 已更新 `coastline/navgrid_v2/build_hazard_50m_mysql.py`
  - 给 `navsea_hazard_grid_cell` 增加 `(layer_name, source_name)` 索引
  - 现在海障这组按 `fid` 查删和复跑会更顺手
- `NavSea_v2_使用说明.md` 也同步说明了这一点。

## 2026-05-04 v2 脚本根路径修正

- 已修正 v2 目录下几个脚本的 `project_root` 计算，统一指向仓库根目录 `/root/sourceserver/pbf`
- 这次影响到：
  - `build_coast_grid_mysql.py`
  - `build_fish_port_20m_mysql_resume.py`
  - `build_hazard_50m_mysql.py`
  - `export_coast_grid_mysql_assets.py`
  - `export_fish_port_debug_assets.py`
  - `export_prc20_test_assets.py`
- 原因是之前少退了一层，默认输入 glob 会去找一个不存在的 `coastline/coastline/...` 路径。

## 2026-05-04 阻断墙 bin 文件名带三层单位

- 已更新 `coastline/navgrid_v2/build_coast_wall_z12_bin.py`
  - 输出 `bin` 文件名会自动带上当前三层单位
  - 例如 `coast_wall_z12_100_50_20.bin`
  - `meta.json` 也会跟着同一文件名后缀走
- `NavSea_v2_使用说明.md` 已同步补充默认命名示例。

## 2026-05-04 阻断墙 bin 三层来源表修正

- 已修正 `coastline/navgrid_v2/build_coast_wall_z12_bin.py`
  - 之前三层数据都被错误地从 `navsea_fish_port_grid_cell` 读取
  - 现在 `fish_port_20m`、`hazard_50m`、`coast_100m / coast_200m` 分别读取各自表
  - `coast_*` 新层名也统一映射到 `navsea_coast_grid_cell`
- 修正后 `coast_wall_z12_100_50_20.bin` 的输出体量恢复正常，`hazard_50m` 与 `coast_100m` 不再是 0。

## 2026-05-04 渔港 20m 粗筛改查 coast 表

- 已修正 `coastline/navgrid_v2/build_fish_port_20m_mysql_resume.py`
  - `load_coarse_mask()` 由错误的 `navsea_fish_port_grid_cell` 改为 `navsea_coast_grid_cell`
  - `load_coarse_windows_for_bbox()` 也同步改为读取 `navsea_coast_grid_cell`
- 这解释了之前日志里 `coast_200m 粗筛底座为空` 的异常现象。
- 当前库里已经能查到 `navsea_coast_grid_cell / coast_200m`，所以后续鱼港脚本会真正拿海岸底盘去粗筛。

## 2026-05-04 渔港海岸几何合并日志细化

- 已在 `coastline/navgrid_v2/build_fish_port_20m_mysql_resume.py` 给 PRC 级海岸线处理补了更细日志：
  - `unary_union` 前后
  - `buffer` 前后
- 对比 v1 / v2，这一段逻辑本身是一致的；这次只是把真正耗时的位置显式打印出来，避免“海岸线缓存完成”这句把卡点遮住。

## 2026-05-04 阻断墙 bin 预览页

- 已新增 `src/pbf/navsea-coast-wall-z12-viewer.html`
  - 可直接用文件选择器加载 `coast_wall_z12_*.bin`
  - 支持可选加载同名 `.meta.json`
  - 直接在地图上查看最终阻断墙的铺面效果
- `NavSea_v2_使用说明.md` 已补上这个预览页入口。
- 页面已部署到 `/mnt/sda1/www/newpec/navsea-coast-wall-z12-viewer.html`，可直接用 `http://192.168.200.184/newpec/navsea-coast-wall-z12-viewer.html` 打开。
- 已把预览页调成高对比显示，底图透明度降低，阻断墙填充和描边加重，方便肉眼快速看清。
- 已进一步调整为自然底图 + 红色阻断墙高对比显示，避免整张图发黑。
- 预览页版本已抬到 `v1.1`，避免浏览器继续命中旧缓存。
- 阻断墙预览页再升级到 `v1.2`，新增鼠标经纬度读数和 tile 轮廓开关，便于核对是否存在坐标偏移。
- 阻断墙预览页升级到 `v1.3`，新增 Y 原点切换，默认底部原点，专门用于排查 tile XYZ / y 轴方向是否看反。
- 已按要求回退阻断墙预览页到 `v1.0` 风格，并把面板改成可拖动，避免遮挡主视图。
- 进一步把阻断墙重绘从 `move/zoom/rotate/pitch` 切到 MapLibre `render` / `moveend` 驱动，减少拖拽过程中 canvas 与地图不同步导致的“红墙看起来在变”。
- 又把阻断墙重绘改为同步执行，去掉 `requestAnimationFrame` 这层额外延迟，避免拖动地图时红墙比底图慢一拍、看起来向右偏。
- 当前阻断墙预览页已抬到 `v1.1`，用于继续排查红墙与底图轻微偏右的问题。
- 进一步把阻断墙 canvas 挂到 MapLibre 的 `canvasContainer` 里，并把页面版本抬到 `v1.2`，继续排查“只在局部窗口出现且略偏右”的问题。
- 发现把阻断墙 canvas 挂到 `canvasContainer` 反而会让红墙只在局部窗口出现；已撤回该绑定，并把页面版本抬到 `v1.3`，让 overlay 回到页面级覆盖层。
- 继续把阻断墙预览页抬到 `v1.4`，增加一个可切换的 tile 轮廓开关，便于确认红墙是否只是局部窗口显示偏移，还是 tile 本身就只落在那一块。
- 阻断墙预览页继续升级到 `v1.5`，增加“点位”模式，点击地图后会显示该点对应的 tile / cell 边界，方便把红墙偏移问题从感觉变成可验证坐标。
- 阻断墙预览页继续升级到 `v1.6`，补上 `z12_cell_for_lonlat()` 和 `idle` 补绘，避免点位模式报错，并减少“只有切换开发者模式后红墙才出现”的渲染时序问题。
- 阻断墙预览页继续升级到 `v1.7`，把 `map.resize()`、overlay 尺寸同步和 `ResizeObserver` 串起来，专门处理“切换开发者模式才整图出现红墙”和点位标记偏移的问题。

## 2026-08-06 九州语义图标替换测试版 v1

- 以当前可靠 Full 基线 `/home/wwwroot/pbf-delivery-full-20260418-rebuild` 为来源，生成九州范围测试 PBF：
  - `/home/wwwroot/pbf-delivery-kyushu-semantic-icon-v1-20260806`
  - 范围 `128.0,30.0,132.5,34.9`，zoom 5–12，共 4707 张瓦片
  - 实际重写 1340 张瓦片，40131 个 feature 发生图标语义字段替换
- 部署了语义 sprite：
  - `http://192.168.200.184/newpec/sprite-kyushu-semantic-icon-v1-20260806/sprite`
  - 补齐 `arc_open_YW / arc_G / arc_R / arc_YW` 四个弧灯键，并清除未使用的旧 `symbol-daytime-* / arc-daytime-*` 键；最终 55 个实际使用图标键全部闭合。
- 生成并部署了两套样式：
  - `style.navsea-newpec-kyushu-icon-test-v1.json`
  - `style.navsea-delivery-kyushu-semantic-icon-v1.json`
- 生成并部署左右对比页：
  - `http://192.168.200.184/newpec/navsea-compare-kyushu-semantic-icon-v1.html`
  - 页面版本 `kyushu-semantic-icon-v1-20260806`，支持同步平移/缩放和左右点击检查。
- 审计结果：
  - 对象/几何/非图标属性：4707/4707 瓦片比较，错误瓦片 0，结论 PASS。
  - 旧 `symbol-daytime-* / arc-daytime-*` 前缀残留：0。
  - Sprite 图标键闭合：55/55，结论 PASS。
  - native geometry audit：extent 与当前 raw source 不一致 0，未修复 0；报告中的 outside-extent 是当前既有坐标溢出表现，且对象审计确认本次没有新增几何变化。
  - 博多/唐津 z10、z12 浏览器视觉截图已完成；左右差异较大主要来自原始 newpec 底图与 delivery 海图样式本身不同，不能单独作为图标替换失败依据。
- 机器可复现入口：`navsea_build_kyushu_semantic_icon_test.py`；对象审计入口：`navsea_audit_kyushu_semantic_icon_test.py`。