bdac7873f4
fix: 修复 ContentMapper 类体被模块级函数截断的严重 bug
...
问题: 批量生成专题图时报 'ContentMapper' object has no attribute 'process_data'
根因: _local_krige_block_worker (0空格缩进,模块级) 被错误地插入在
ContentMapper 类体中间 (line 819), 导致类定义在此处终止。
之后 19 个方法 (_idw_interpolation, read_csv_data, create_content_map,
visualize_raster, prepare_shared_context, process_data, process_batch...)
全部脱离类变成模块级函数。
AST 验证: ContentMapper 仅剩 9 个方法。
修复: 将 _local_krige_block_worker 移至文件末尾 (模块级正确位置),
ContentMapper 恢复为 28 个方法的完整类。
2026-07-08 13:02:03 +08:00
8f03dcb10b
perf: Local Kriging 500m spatial window + multiprocessing
...
Local Kriging: grid split into 500m blocks, each block uses only
sample points within block+buffer zone. Covariance matrix shrinks
from 8242x8242 to local nxn. 10M+ grid cells now finish in minutes.
Complexity:
Global: O(G * P * logP * K^3) = hours for large grids
Local: O(sum(block*grid * block*points * 15^3)) = minutes
2026-07-08 12:03:46 +08:00
e0b9257b56
perf: Kriging 多进程分块 + C 后端自动检测 — 1m 分辨率千层级网格加速
...
问题: 用户需要 1m 分辨率 (2285×4600 = 1051万网格点)，
单进程 loop 后端需要数小时。
修复 (三层加速):
1. C 后端自动检测 (_detect_kriging_backend):
- 检测 pykrige 是否有编译的 C 扩展 (conda-forge 默认有)
- 可用时 C 后端比 loop 快 50-100×
- 不可用时回退 loop + 多进程补偿
2. 多进程分块 (_krige_chunked):
- 网格 >100 万点时自动启用
- 沿 Y 轴将网格拆分为 N 个 stripe (N=CPU核数,上限8)
- 每个 worker 独立运行 OrdinaryKriging.execute()
- 结果沿 Y 轴 vstack 拼接
3. 进度可见:
- 每个 worker 启动时打印 '[Krige Worker] 分块 X/N'
- 完成后立即打印完成消息
- 主进程打印拼接结果维度
预期性能 (8核, C后端, 1051万网格点):
单进程 loop: ~3-5 小时
8进程 + C: ~1-3 分钟 (loop后端 ~15-30 分钟)
2026-07-08 11:34:14 +08:00
212772caf4
fix: Kriging 大网格自动拦截 — 防止百万级网格点导致无限卡死
...
问题: 用户将 step11 分辨率设为 1m，生成 2285×4600 = 1051万
网格点。pykrige OrdinaryKriging.execute() 在此规模上需要数小时，
且期间无任何进度输出，看起来像程序卡死。
根因: 原代码对网格规模无上限约束。
修复 (create_interpolation_grid):
- 推荐上限: 500K 网格点 (~30-120s)
- 绝对上限: 2000K 网格点 (超出直接抛错，建议提升分辨率)
- 超推荐上限时自动按比例提升分辨率: 2285×4600 → ~505×1016
- 打印明确的网格点数统计和 ETA 提示
- 网格自动缩减后日志: '调整后网格: N×M = X 个网格点'
2026-07-08 11:28:25 +08:00
796d36c093
fix: 修复 TIF 缺失 CRS 时 fallback 到 WGS84 导致掩膜擦除全部像元的 bug
...
问题: step11 日志反复出现:
'栅格 TIF 缺失坐标系，默认按 WGS84 渲染'
'擦除后有效像元: 0/15300'
根因: step10 生成的 GeoTIFF 缺少 CRS (可能是 PROJ 异常时生成的)。
visualize_raster 中当 crs_obj 为 None 时无条件回退到 EPSG:4326 (WGS84),
但 transform 实际是 UTM 米坐标 (e.g. x≈470000, y≈2200000)。
UTM 度坐标的掩膜被 reproject 到 WGS84 后,
与仍在 UTM 米坐标的 transform 彻底错位 → geometry_mask 全部为 False
→ 0 个有效像元。
修复: 当 crs_obj 为 None 且 boundary 有投影 CRS 时,
检查 transform 的 X 坐标量级: 若 >180 则必定是投影坐标 (UTM 等),
直接使用 boundary 的 CRS 而非 WGS84 回退。
仅当坐标量级 <180 时才回退到 WGS84 (真经纬度)。
2026-07-07 16:51:33 +08:00
c46f78e69d
fix: 补齐缺失的 handler 文件 + IDW 插值退化检测 + V1 代码归档
2026-07-06 15:57:29 +08:00
385e5915af
格式统一
2026-07-01 17:33:52 +08:00
8de73db80e
格式统一
2026-07-01 11:32:32 +08:00
43f50ec07b
测试修改
2026-06-25 15:50:02 +08:00
027981e9a6
ContentMapper 边界读取支持栅格水掩膜（.dat/.bsq/.tif/.tiff/.img）
2026-06-16 15:15:10 +08:00
184f5fe9f4
fix(step14): 批量渲染文件名唯一性 + Colorbar 样式 + 2σ拉伸
2026-06-11 10:29:32 +08:00
0493ba7916
fix(map): GeoTIFF 可视化全链路修复
2026-06-10 17:13:51 +08:00
b0a94ba1e7
更新工作目录子文件夹的序号
2026-04-14 09:24:18 +08:00
91e36407ae
Initial commit of WQ_GUI
2026-04-08 15:25:08 +08:00
