简介：这份资源面向具备一定前端与三维 GIS 基础的开发者，聚焦在 Cesium 场景中实现克里金插值并完成温度数据的三维可视化渲染。它解决的是离散温度观测点难以直观呈现空间连续变化的问题，通过变异函数分析将不规则采样值估算为平滑温度场，适用于气象展示、环境监测与地理空间分析类 Web 应用。压缩包共 585 个文件，约 7.27MB，以 321 个 js 脚本承载插值与渲染逻辑，配合 141 个 png、53 个 jpg 图片资源及 29 个 json 配置、27 个 css 样式，另有 svg、wasm、html 等辅助文件，构成可直接运行的示例工程。已有 167 人学习下载。读者可从中获得克里金插值的工程化落地思路、Cesium 图层叠加与温度场平滑渲染的实现参考，以及按模块组织的目录结构，便于对照调试与二次开发。
1. 克里金插值：为什么几个气象站就能画出一整张温度图
你手上有十几个气象站的温度读数，散落在几百公里的范围内，却要在地图上渲染出一整片连续变化的温度色带。最直觉的做法是反距离加权——离得近的权重大，离得远的权重小，简单粗暴。但做过的人都知道，这套方案在山区和沿海经常翻车：明明两站之间隔着一道山脊，插值结果却平滑过渡，画出来的等温线和地形完全对不上。
克里金插值解决的正是这个问题。它不把「距离」当成唯一的权重依据，而是先估计数据的空间自相关性——也就是「相隔多远的两个点，其数值差异大概有多大」——再用这套相关性模型去分配权重。Cesium Kriging 要做的，是把这套在地统计学里成熟了几十年的算法，塞进三维地球的渲染管线里，让温度场能贴着地形起伏铺开。搞懂它，你就搞懂了「空间插值」和「实时渲染」这两件事是怎么被强行捏在一起的，以及为什么中间那些取舍会直接决定最终画面是可信还是玄学。
2. 半变异函数：克里金的权重到底从哪来
2.1 从「距离越近越像」到可量化的空间相关性
反距离加权的隐含假设是：相似性随距离单调衰减，且衰减速度固定。克里金不这么认为。它先做一件反距离加权完全没做的事——用已知采样点两两配对，统计「距离为 h 的点对，其数值差的平方的平均值的一半」是多少。这个量叫半方差，记作 γ(h)：
γ(h) = (1 / 2N(h)) * Σ [Z(xi) - Z(xi + h)]²其中 N(h) 是距离恰好为 h 的点对数量，Z 是采样值。把所有 h 对应的 γ(h) 算出来画成散点，再拟合一条曲线，就得到半变异函数模型。这条曲线告诉你三件事：块金值（ nugget，距离趋近 0 时仍存在的方差，代表测量误差或微观变异）、基台值（ sill，方差的上限，超过这个距离两点就完全不相关了）、变程（ range，相关性消失的距离阈值）。
常见的拟合模型有球状模型、指数模型、高斯模型。球状模型在变程处硬性截断，指数模型渐近逼近基台，高斯模型在原点附近极其平坦——选哪个模型，直接决定了插值结果在近距离是「平滑」还是「锐利」。这是克里金里第一个需要人工判断的地方，也是很多实现直接写死球状模型的原因：它数学形式简单，闭式解好求。
2.2 普通克里金的方程组：为什么必须解线性系统
有了半变异函数，克里金的核心就变成一个带约束的最优化问题：给待插值点 x0 分配权重 λi，使得估计方差最小，同时权重之和为 1（保证无偏）。用拉格朗日乘子法推导，得到普通克里金方程组：
[ γ(x1,x1) γ(x1,x2) ... γ(x1,xn) 1 ] [ λ1 ] [ γ(x1,x0) ] [ γ(x2,x1) γ(x2,x2) ... γ(x2,xn) 1 ] [ λ2 ] [ γ(x2,x0) ] [ ... ... ... ... . ] [ .. ] = [ .. ] [ γ(xn,x1) γ(xn,x2) ... γ(xn,xn) 1 ] [ λn ] [ γ(xn,x0) ] [ 1 1 ... 1 0 ] [ μ ] [ 1 ]左边是 n+1 阶的矩阵，前 n 行 n 列是采样点之间的半方差，最后一行一列是拉格朗日约束。右边前 n 项是待插值点与各采样点的半方差，最后一项是常数 1。解这个线性系统，就得到每个采样点的权重 λi 和拉格朗日乘子 μ。
这里有个关键点：矩阵只和采样点有关，和待插值点无关。也就是说，如果你要插值一万个网格点，矩阵只需要分解一次（比如做 LU 或 Cholesky 分解），之后每个待插值点只是换一个右端项做回代。这是克里金能在渲染场景里跑起来的前提——如果每个像素都重新解一遍 n 阶系统，性能会直接崩掉。常见的实现思路是：先对采样点矩阵做一次分解，缓存分解结果，然后对每个网格点做一次 O(n²) 的回代。n 通常只有几十到几百，这个量级在 JavaScript 里是可以接受的。
2.3 半变异函数拟合：最小二乘与模型选择的工程妥协
理论上的半变异函数拟合应该用加权最小二乘，权重取 N(h)/γ(h)²，让点对多的距离段获得更高置信度。但实际工程里，很多实现为了省事直接用普通最小二乘，甚至用肉眼调参。这不是偷懒，而是因为采样点往往只有十几个，经验半变异函数的散点本身就噪声很大，过度拟合反而会让插值结果出现不合理的振荡。
Cesium Kriging 这类实现通常把模型参数（块金、基台、变程）暴露成可配置项，让使用者根据数据特性手动指定。温度数据的空间相关性通常比较强，变程可以设得大一些；如果数据里混入了城市热岛这种局部异常，块金值就要调高，否则插值结果会被少数异常点带偏。我一般会建议先用全部数据画一遍经验半变异函数散点，看看拐点大概在什么距离，再反推参数，而不是一上来就调渲染参数——顺序反了，后面怎么调都是玄学。
3. 从网格到纹理：插值结果怎么变成 Cesium 能画的像素
3.1 规则网格采样：为什么不能逐像素插值
Cesium 的渲染管线吃的是纹理，不是散点。所以克里金插值不能对屏幕像素直接做，必须先在一个规则网格上算出温度值，再把网格数据打包成纹理，贴到地球表面。这个网格的划分方式直接决定了性能和画质的平衡。
常见的做法是在经纬度平面上按固定步长采样，比如经度方向每 0.01 度一个点，纬度方向同理。网格分辨率越高，色带越平滑，但计算量按面积平方增长。假设覆盖范围是 10 度乘 10 度，步长 0.01 度，那就是 1000×1000 共一百万个网格点。每个点做一次 n 阶回代，n=50 时大约是 2500 次乘加，总计 25 亿次运算——这在浏览器里显然跑不动。
所以实际实现会做两件事：一是降低网格分辨率，比如 256×256 或 512×512，靠纹理的双线性插值来弥补视觉平滑度；二是把插值计算放到 Web Worker 里，避免阻塞主线程。Cesium Kriging 的典型实现会把网格数据算完后转成 ImageData 或 Canvas，再作为纹理源交给 Cesium 的材质系统。这里有个容易忽略的细节：经纬度网格在墨卡托投影下不是均匀的，高纬度地区网格会被拉伸，如果直接按像素映射，温度场会在高纬出现形变。严谨的做法是在投影后的平面上做插值，或者对纬度做余弦修正。
3.2 纹理打包与色带映射：温度值怎么变成颜色
插值得到的是浮点温度值，纹理需要的是 RGBA 字节。中间这层映射就是色带。最简单的做法是线性映射：把温度范围归一化到 0 到 1，再查一张预定义的渐变色表。但温度数据的分布往往不是均匀的，直接线性映射会让大部分区域挤在色带的中间段，视觉上缺乏层次。
更合理的做法是先对插值结果做统计，取 2% 和 98% 分位数作为色带的端点，把极端值截断。这样色带的动态范围被充分利用，等温线的层次感会明显提升。色带本身可以用分段线性插值实现，也可以用现成的色表库。Cesium Kriging 的实现里通常会把色带做成可配置的数组，每个元素是「归一化位置 + RGB 值」，渲染时对每个网格值做一次查找和线性混合。
纹理的坐标系也需要对齐。Cesium 的 ImageryLayer 期望的纹理是自上而下的行序，而很多图像处理库默认是自下而上。如果搞反了，温度场会上下颠倒，而且因为温度分布通常有南北差异，这种错误在视觉上表现为「北方突然变热」，很容易被误判成插值算法出了问题。血泪经验是：先在网格数据里放一个已知的不对称图案（比如左上角设一个极值），渲染出来看一眼方向对不对，再往里灌真实数据。
3.3 与地形和相机的耦合：为什么温度场要贴地
温度场不是飘在空中的，它要贴着地表。Cesium 的地形是动态加载的，不同缩放级别下地形精度不同，如果温度纹理直接贴在地球椭球面上，在山区会出现「温度穿山」的穿模现象。解决办法有两种：一是用 Cesium 的 GroundPrimitive 或贴地材质，让纹理跟随地形起伏；二是把温度场做成带高度的几何体，但这样计算量会大幅上升。
常见的实现思路是用 Cesium 的 CustomShader 或 Material 机制，把温度纹理作为 uniform 传入，在片元着色器里根据当前片元的经纬度采样纹理，再和地形颜色做混合。这样温度场天然贴合地形，而且可以利用 GPU 的并行能力做逐像素的色带映射，比在 CPU 端生成最终图像更灵活。代价是着色器里不能做复杂的插值计算，所以克里金必须在 CPU 端或 Worker 里算完，GPU 只负责采样和上色。这个分工是性能与灵活性的折中，也是理解整个渲染链路的关键：克里金负责「算得对」，着色器负责「画得顺」。
4. 避坑与排查：克里金渲染最常见的五类翻车
4.1 插值结果出现大面积同色或条纹
现象：渲染出来的温度场大片区域颜色一致，或者出现规则的横向条纹。原因通常是网格分辨率太低，而纹理过滤方式设成了最近邻（NEAREST）而不是线性过滤，导致每个像素直接取最近的网格值，色带被量化成台阶。解决方法是把纹理的 minFilter 和 magFilter 都设为 LINEAR，同时适当提高网格分辨率。如果条纹是横向的，还要检查网格的行列顺序是否和纹理的宽高对应——行列搞反会让插值结果在错误的方向上被拉伸。
4.2 边缘区域温度值异常跳变
现象：地图边缘或数据覆盖范围的边界处，温度值突然跳到极值。原因是克里金在采样点稀疏的区域，权重分配会变得不稳定，尤其是当待插值点远离所有采样点时，半变异函数值趋近基台，方程组接近奇异，解出来的权重可能出现负值或超大值。解决办法是在插值前做一次范围裁剪，对超出采样点凸包一定距离的网格点直接标记为无效，渲染时用透明或背景色填充。另一个办法是增加一个「最大影响半径」参数，只让距离待插值点一定范围内的采样点参与计算，超出范围的点权重置零。
4.3 页面卡顿甚至崩溃
现象：数据量稍大，浏览器就卡死或标签页崩溃。原因几乎总是主线程被插值计算占满。一百万个网格点乘以几十个采样点的回代，在 JavaScript 里是秒级到十秒级的运算，期间 UI 完全无响应。解决办法是把整个插值过程放进 Web Worker，主线程只负责接收结果和更新纹理。注意 Worker 里不能直接操作 DOM 或 Cesium 对象，传回来的应该是 TypedArray 或 ImageBitmap，主线程再转成纹理。如果连 Worker 都扛不住，就要降网格分辨率或者减少采样点数量——克里金的计算复杂度对这两个参数都很敏感。
4.4 温度场和地形对不上，出现穿模
现象：在山区，温度色带明显穿入山体或者悬浮在山谷上方。原因是纹理贴在了椭球面而不是地形表面。解决方法是使用 Cesium 的贴地材质或 GroundPrimitive，确保纹理采样时使用地形高度。如果用的是自定义着色器，要在顶点着色器里把位置更新到地形高度，或者在片元着色器里根据深度做偏移。注意贴地渲染在低缩放级别下可能因为地形 LOD 切换而闪烁，需要配合 depthTest 和 polygonOffset 做微调。
4.5 色带映射后层次感差，等温线糊成一片
现象：温度场看起来像一团模糊的色块，看不出温度梯度。原因通常是色带映射用了线性归一化，而温度数据的实际分布集中在中间段。解决办法是先对插值结果做分位数统计，用 2% 和 98% 分位数做截断，再把色带做成非线性分段，在温度变化剧烈的区间分配更多颜色层次。另外，色带本身的选择也很重要，彩虹色带虽然视觉冲击强，但在表达数值大小上不如单色渐变准确，容易误导读者。如果目标是科学可视化，建议用感知均匀的色带，比如 viridis 或 cividis 的变体。
5. 设计取舍：为什么克里金在浏览器里总要妥协
把克里金搬进 Cesium，本质上是在三个约束之间找平衡：统计正确性、渲染实时性、实现复杂度。理论上，克里金应该对每个待插值点解完整的方程组，用加权最小二乘拟合半变异函数，用交叉验证选模型。但在浏览器里，这套流程的每一步都要打折扣。
第一个取舍是网格分辨率。逐像素插值在统计上最准确，但计算量不可接受。退到规则网格加纹理过滤，是用空间分辨率换时间。这个取舍的代价是高频细节丢失，温度场的锐利边界会被平滑掉。缓解办法是在数据变化剧烈的区域做自适应网格加密，但这会显著增加实现复杂度，大多数实现选择不做。
第二个取舍是半变异函数模型的固定化。让用户手动调块金、基台、变程，把统计建模的责任推给使用者，实现上最省事，但使用者如果不懂地统计，调出来的参数可能完全不合理。更友好的做法是提供自动拟合，用经验半变异函数的散点做最小二乘，但自动拟合在采样点少的时候极不稳定，容易过拟合。我一般会建议保留手动参数，同时在文档里给出典型数据的参考范围，让使用者至少有个起点。
第三个取舍是计算位置的分配。CPU 端算插值，GPU 端做采样和上色，这个分工是性能和灵活性的折中。如果把插值也搬到 GPU，用片元着色器直接算，理论上可以做到逐像素精度，但半变异函数的拟合和线性方程组的求解在 GPU 上很难高效实现，而且调试成本极高。反过来，如果全部在 CPU 端算完再生成最终图像，GPU 只负责贴图，灵活性又太差，无法做动态色带和交互式调整。
验证一套实现是否靠谱，我通常会用三个检查：一是用已知解析解的简单场（比如线性梯度场）做输入，看插值结果是否还原；二是留出部分采样点做交叉验证，看预测值和实测值的误差是否在合理范围；三是把渲染结果和独立工具（比如用 Python 的插值库）算出的网格做逐点对比，排除渲染链路引入的偏差。这三个检查做完，基本能区分「算法实现有问题」和「渲染参数没调好」。
从那以后我每次接空间插值的活，都强制先把半变异函数散点画出来看一眼，再动渲染参数。顺序反了，后面调什么都是碰运气。希望帮到你。
本文还有配套的精品资源，点击获取
