pbf/STEP_RECORD.md

项目步骤记录

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

保留原则

• 只保留最近 3 天里真正会反复回看的内容
• 重点保留三类信息：
  • pickup 相关
  • 图标改进相关
  • 所有审计的方法
• 详细过程、反复试跑、临时中间值尽量不写，统一指向报告或脚本
• 详细审计结论索引：
  • 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-03 渔港 20m 语义修正为海岸线格子

• 复查 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 现在在落库层面已经按港独立了，后续如果再出现差异，就只需要查几何或海岸线输入，不用再怀疑存储覆盖。