# 项目步骤记录

最后更新：`2026-05-02`
仓库：`/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-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` 粗格
  - 再把粗格按 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-02 渔港 20m 支持按单港 FPC 重算

- 已为 `coastline/build_fish_port_20m_full_mysql_resume.py` 增加单港口入口：
  - 新增 `--fpc`
  - 脚本会先按 `FPC` 反查所属 `PRC`
  - 只处理该港口对应的线要素
- 单港口模式会在日志里同时给出：
  - 命中的 `200x200` 粗格数量
  - 最终写入的 `20x20` 格子数量
- 单港口模式下，每个批次会先按当前 cell_id 清掉旧记录，再写回，便于重算同一港口
- 已验证：
  - `./.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`
  - 支持精确匹配和模糊匹配
- 文档已补到：
  - `NavSea_全国三层数据生成与查看说明.md`
- 已验证：
  - `./.venv/bin/python -m py_compile find_fpc_by_port_name.py`

### 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` 细扫底盘
  - 再用同一套海岸线碰撞逻辑判定 `LAND_BASE / SEA_SURFACE`
- 这样 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 + SEA_SURFACE` 全量导出，便于一起看港区外围形状。
- 已同步到 Web 目录：
  - `/mnt/sda1/www/newpec/coastline/navsea-fukuoka-saga-coast200-fish20-full/`
- 当前页面版本：
  - `v2.6`