|
|
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 |
|
