做区域碳汇潜力摸底的时候，我最头疼的往往不是报告怎么写，而是怎么让决策者一眼看懂“哪些地块值得优先补碳”。单看一张土壤有机碳含量图不够——含量低的地方可能受限于砂质、干旱，实际提升潜力很小；含量高的湿地和林地又可能已经接近饱和，再投入也收效甚微。后来我把评估逻辑搬到GEE（谷歌地球引擎）上，用公开土壤属性图层直接算出一张交互式的碳固存潜力地图，点击任意位置就能看到有机碳、黏粒、pH、容重这些关键指标，还能随手画个多边形统计区域平均值。这篇文章就把这套做法的完整路线讲清楚，从数据选型、评估规则、界面设计到代码实现和踩坑记录都会覆盖，适合正在做区域碳汇评估、农业生态规划、双碳相关分析的同学参考。
1. 这个App要回答的问题：优先补碳的地块在哪里
1.1 为什么不能只看“谁碳少，谁潜力大”
最早我接到一个县域尺度的固碳优先区摸底需求，项目方给的原始图就是土壤有机碳含量分布：颜色越红的地方有机碳越低。项目方第一反应是“红色区域潜力最大，应该重点投入”。但实际跑下来发现，这个直觉在很多地方是错的。
举个例子，同样是有机碳低于1%的两块地，一块是黏壤质、排水良好的农田，另一块是砂质、干旱的退化草地。前者通过秸秆还田、保护性耕作，有机碳很容易往上走；后者因为土壤缺乏黏粒对有机碳的物理保护，外加水分条件差，施再多有机物料，分解损失也快，几年后能留下多少很难说。所以固碳潜力本质上要看两件事：一是现状离“合理目标”还有多大差距，二是这块土壤有没有能力把碳“留住”。只看单一指标会得到误导性结论。
把这两件事落到地图上，就需要同时引入多个土壤属性，并且用一个相对透明的规则把它们组合起来。这正好是GEE适合干的事——所有图层都在云端，不需要本地装GIS、不需要下载几十个GeoTIFF，写一段脚本就能完成多波段叠加、重采样、区域统计。
1.2 传统流程和云端流程的差别在哪
传统做法大概是：野外布点采样，拿回实验室测有机碳、容重、质地，然后做地统计插值，最后再叠加上地利用、地形这些辅助数据判断潜力分区。这个流程精度高，但周期长、成本高，而且一旦边界改了或者想换一套评估规则，整套插值重跑一遍非常痛苦。
GEE的路线不太一样。公开土壤属性数据集已经把全球250米分辨率的主要属性图层做好了，我只需要在脚本里按行政区划边界裁剪，然后把评估公式写进去，一张“潜力指数图”几秒钟就能出来。想换权重？改一个数字重新跑一次就行。想换区域？换个边界要素就行。这种“把评估变成参数化脚本”的灵活性，是传统流程完全比不了的。
当然代价也有：公开图层是模型估算结果，不是实测值，代表的是区域尺度的趋势，而不是地块尺度的真值。所以这个工具的定位是快速筛查，用来回答“哪里应该优先做深入调研”，而不是替代实地采样出最终报告。
1.3 工具定位：筛查工具，不是定值报告
我在开发前就跟对接方明确了一个边界：这个App输出的潜力等级是“相对评估”，不是“测土配方”。比如某一块地潜力指数70分，只代表它在当前规则下比55分的地更有提升空间，不代表这块地一年能固多少吨碳。真要算固碳速率，得引入管理措施、气候情景、时间序列，那是另一个量级的模型。
把定位定清楚，后面很多决策就顺了：权重用经验值就行，不需要刻意贴近某个实验站点；图例分级也按相对区间做，不承诺绝对阈值；地图上同时展示底层属性，让用户自己核对数值来源。做这类分析工具，透明比精准更重要——精准是后面实地验证的事，透明决定了使用者信不信你的结果。
2. 底料怎么选：土壤属性与辅助数据的图层清单
2.1 核心土壤属性：有机碳、黏粒、pH、容重
潜力评估至少需要四个土壤属性图层，缺一个都会让评估逻辑站不住。
第一个是有机碳含量，这是基线。它决定“现状离目标还有多远”。第二个是黏粒含量，它代表土壤对有机碳的物理保护能力。黏粒多，比表面积大，有机质更容易吸附在矿物表面形成团聚体，分解速率会明显下降。第三个是pH，过酸过碱都会限制微生物活性和有机质积累，中性偏微碱的土壤通常更适合碳积累。第四个是容重，它用来把“每千克土里有多少碳”换算成“每公顷这块土里总共堆了多少碳”，没有容重就算不出碳储量。
这四个属性在公开土壤数据集中都有现成波段，深度选的0-30厘米层，正好对应农业土壤有机碳管理最常讨论的耕层范围。
| 属性 | 在评估中的作用 | 常见深度/单位 |
|---|---|---|
| 有机碳含量 | 判断现状与目标差距 | 0-30 cm，g/kg |
| 黏粒含量 | 表征物理保护能力 | 0-30 cm，% |
| 容量 | 将含量换算为储量 | 0-30 cm，g/cm³ |
| pH | 表征微生物活性环境 | 0-30 cm，无单位 |
2.2 辅助数据：地形、气候、土地利用
土壤属性图层解决“保不保得住”的问题，但还缺“让不让长”的环境条件。坡度太陡，无论属性多好，水土流失都会把积累的碳带走，所以坡度要作为一个减分项。降水过少会限制植被生产力，有机物输入量低，固碳潜力自然打折扣；当然降水太多、长期淹水的地块又容易形成甲烷等温室气体排放，那是另一个评估体系，所以我在基础版里只做温和修正，不做极端惩罚。
土地利用也不能忽略。同样是低有机碳土壤，在耕地上做秸秆还田前景可期，在林地和湿地上强行谈“固碳潜力”反而可能破坏既有生态功能。所以评估时会根据土地利用类型做分类调节：耕地、退化草地给正常权重，林地、湿地往下压，避免工具误导用户去不该动的地方搞干预。
这些辅助图层在GEE上都能直接调用或快速派生。坡度用公开地形数据算，气候用逐月累计降水归一到多年平均，土地利用用全球地表覆盖产品重分类。基础版不需要面面俱到，每个辅助因子给一个“软修正”就行，把复杂留给后续迭代。
2.3 数据版本与分辨率的选择原则
很多新手拿到图层后第一个问题是：250米够细吗？答案取决于你要做什么决策。如果是省级或县域尺度的优先区筛查，250米完全够用，它能告诉你哪个乡镇、哪个流域值得进一步看，但到了这一步之后，就要用更高分辨率影像做地块分割，或者干脆布点采样了。如果试图用250米数据去指导一户农家“你这块田怎么改”，那就是用错了尺子。
另一个容易忽略的点是数据版本。公开土壤属性数据会不定期更新，不同版本的估算方法差异会导致同一点位的数值变化。我的做法是把数据版本号和应用构建日期写进App的“关于”面板里。任何评估结果脱离版本和时间都是危险的，后续有人追问“你这个数字哪来的”，至少能交代清楚。
3. 把属性翻译成潜力：碳储量公式与潜力指数设计
3.1 先算碳储量，别直接用百分含量
很多人习惯直接拿“有机碳含量”画图，但含量描述的是浓度，不是总量。同样1%的有机碳，容重1.1的地和容重1.5的地，每公顷碳储量能差出三成以上。潜力评估一定要先算储量，再谈缺口。
0-30厘米土层的有机碳储量简化公式：
碳储量(t C/ha) = SOC(g/kg) × BD(g/cm³) × 30(cm) × (1 - 砾石%) × 0.1打比方说：有机碳10 g/kg，容重1.3 g/cm³，砾石5%，那么每公顷0-30厘米土层大约存了 10×1.3×30×0.95×0.1=37.05 吨碳。有了这个基数，才能往下讨论“提升30%意味着什么”。在GEE里，这步就是一个波段乘法的表达式，计算量不大，唯一要注意的是单位换算系数别写错。
3.2 潜力指数怎么打分：五因子加权
潜力指数不追求严格的机理模型，而是要像一张“体检综合报告”那样，把多个维度的信号汇总成一个0到100的分数。基础版采用线性分段打分加权重加权：
- 有机碳现状分（权重0.3）：碳越低给分越高，因为提升空间大。有机碳低于1.5%给90分，1.5%-2.5%给70分，2.5%-4%给40分，高于4%给20分。
- 黏粒保护分（权重0.2）：黏粒10%-40%区间内线性打分，越低分越低；低于10%说明砂性太重，给20分封顶。
- pH环境分（权重0.1）：pH在6-8之间给90-100分，偏离越多分越低，低于5或高于8.5给30分以下。
- 地形气候分（权重0.2）：坡度小于8度给满分，每增加5度扣15分；年降水量低于400毫米的地块额外扣10分。
- 土地利用修正（权重0.2）：耕地、退化草地给90分；林地、灌丛给50分；湿地、水体给10分。
最终合成就是五个分数分别乘权重再加总。权重不是神圣不可变，换区域时完全可以调，比如在一些石灰性土壤区域，pH的影响可能没那么敏感，可以把0.1的权重挪给黏粒。关键是把权重写在界面里，让使用者看得到，而不是藏在一个莫名其妙的总图里。
3.3 等级划分和可视化着色
算完指数还要分级。我用的是四档：0-30分为低潜力，30-50分为中潜力，50-70分为高潜力，70分以上为极高潜力。着色方案用黄-绿连续渐变，低潜力偏棕黄，高潜力偏深绿。这里有个细节：图例的色带边界要固定，不能随着当前视图动态拉伸。很多人做出来的地图有个毛病，这次打开看某区域是绿色的，缩小范围再看同样的区域变成了黄色，原因就是色带按当前显示范围拉伸了。对分析工具来说，必须保证同一套数据在任何缩放下颜色都一样，不然用户会直接对结果失去信任。
4. 交互分析地图的功能拆解
4.1 界面布局：地图为主，控制面板为辅
这个App的界面没有做得很复杂，整体就是一个地图占据屏幕主要区域，左上角放控制面板，底部放图例和状态栏。控制面板里放三样东西：图层切换下拉框、透明度滑块、潜力指数重算按钮。点击重算按钮后，系统会读取用户在面板里改的权重参数，重新执行指数合成并刷新地图图层。
为什么把“重算按钮”做得这么突出？因为很多评估需求不是一次性的，管理人员会反复问：“如果更看重土壤质地，高潜力区会不会移动？”有了交互重算，他们自己动手就能验证，而不是每次都要跑回来找开发者改参数。这个“让用户能碰参数”的功能，是交互地图和静态专题图最本质的区别。
4.2 图层的分组与透明度调节
我把图层分成三组。底图组：普通影像和道路底图，负责地理参考；属性图层组：有机碳含量、黏粒、pH、容重、碳储量，每个都是单波段灰度显示，方便叠加上潜力指数作对比；潜力成果组：潜力指数分级图和潜力等级分区边界。图层切换只作用在属性图层组和潜力成果组之间，底图始终保持可见，这样用户在切换属性时始终有地理上下文。
透明度滑块针对叠加层，方便把潜力指数和底下的真实影像对照。比如某个高潜力区域如果底图显示是城市建筑，那很明显土地利用数据出了问题，潜力分级需要重新检查。这种“数据交叉验证”的需求，靠静态图完全做不到。
4.3 点击查点与区域统计
点击地图弹出一个信息面板，列出该位置的有机碳、黏粒、pH、容重、碳储量、潜力指数、潜力等级。这个交互看起来简单，实际上是把“看图”变成“读数”，决策者可以用手指着地图跟别人说“这里潜力高是因为质地好”，比笼统看颜色有说服力得多。
区域统计功能则用绘制工具实现。用户在地图上画一个或多个多边形，系统对多边形覆盖的所有像元做区域平均，输出包括平均有机碳、平均潜力指数、高潜力面积占比。这个功能的作用是支撑“哪一片值得重点关注”的讨论——把散点状的判断聚合成面上结论。
5. 代码实现路线：从数据加载到交互反馈
5.1 项目骨架结构
GEE App的核心都用JavaScript脚本写在Code Editor里。整个项目的骨架分四段：加载数据、定义评估计算、搭建界面、绑定交互事件。下面我按这个顺序拆解，代码是简化可运行版本，实际资产ID、图层路径请替换成你自己导入的影像。
// 1. 数据加载（示意：用占位资产，替换为你的土壤属性图层） var soc = ee.Image('your-asset/soil_ocs_0_30cm').select(0).rename('SOC'); var clay = ee.Image('your-asset/soil_clay_0_30cm').select(0).rename('CLAY'); var bd = ee.Image('your-asset/soil_bd_0_30cm').select(0).rename('BD'); var ph = ee.Image('your-asset/soil_ph_0_30cm').select(0).rename('PH'); var slope = ee.Image('your-asset/dem_slope').select(0).rename('SLOPE'); var landuse = ee.Image('your-asset/landuse_reclass').select(0).rename('LU');5.2 数据加载和波段重命名
加载时最重要的一步是统一波段名和分辨率。不同来源的图层像元分辨率、投影可能不一致，直接计算会造成结果错位。我的做法是把所有图层重采样到统一投影（一般是EPSG:4326），统一分辨率（250米），并裁剪到目标行政区划。
var targetRegion = ee.FeatureCollection('your-asset/study_area'); var scale = 250; var commonProjection = soc.projection(); soc = soc.resample('bilinear').reproject({ crs: commonProjection, scale: scale }); clay = clay.resample('bilinear').reproject({ crs: commonProjection, scale: scale }); // 其他图层同样处理...这个小段代码看着不起眼，实际却是整个项目里最容易出问题的地方。如果某个图层跳过reproject，后续波段相乘时GEE会自动匹配，像素位置可能发生偏移，最终潜力指数图上会出现明显的条带或锯齿。踩过一次之后，我就把“所有图层统一分辨率/投影”作为不可跳过的固定步骤。
5.3 碳储量和潜力指数的计算
统一完数据之后，直接写计算表达式。先用有机碳、容重、砾石算碳储量，再用各因子分段函数算潜力指数。
var gravel = ee.Image(5); // 简化版砾石含量，实际用图层 var carbonStock = soc .multiply(bd) .multiply(30) .multiply(ee.Image(1).subtract(gravel.divide(100))) .multiply(0.1) .rename('SOC_STOCK'); // 分段打分函数 function scoreSOC(img) { return img .where(img.lt(15), 90) .where(img.gte(15).and(img.lt(25)), 70) .where(img.gte(25).and(img.lt(40)), 40) .where(img.gte(40), 20) .rename('SCORE_SOC'); }潜力指数合成：
var wSoc = 0.3, wClay = 0.2, wPh = 0.1, wTerrain = 0.2, wLu = 0.2; var potentialIndex = scoreSOC(soc).multiply(wSoc) .add(scoreClay(clay).multiply(wClay)) .add(scorePH(ph).multiply(wPh)) .add(scoreTerrain(slope, precipitation).multiply(wTerrain)) .add(scoreLanduse(landuse).multiply(wLu)) .rename('POTENTIAL_INDEX');权重我是做成面板可调参数的，计算函数写成接受权重参数的形式，这样用户在界面上拖动或输入新权重后再调用一次重算就行。这个设计的代码成本不高，但带来的交互价值很大。
5.4 点击交互与区域统计
点击交互的核心是Map.onClick事件。点击地图后取到经纬度，用sample方法提取该点在各图层上的值，然后把结果逐条填进信息面板。
Map.onClick(function(evt) { var lon = evt.lon, lat = evt.lat; var point = ee.Geometry.Point([lon, lat]); var values = potentialIndex.addBands(carbonStock) .addBands(soc).addBands(clay).addBands(ph).addBands(bd) .sample(point, scale).first().toDictionary(); values.evaluate(function(data) { infoPanel.setValue(JSON.stringify(data, null, 2)); }); });区域统计用的是“画多边形→reduceRegion”的组合。用户在Map上绘制一个多边形后捕获绘制完成事件，对该区域执行均值归约，最后把结果渲染到统计表格。
Map.drawingTools().onDraw(function(geometry) { var stats = potentialIndex.addBands(carbonStock).reduceRegion({ reducer: ee.Reducer.mean(), geometry: geometry, scale: scale, maxPixels: 1e13 }); stats.evaluate(function(data) { statPanel.setValue('区域平均潜力指数：' + data.POTENTIAL_INDEX.toFixed(1)); }); });这里建议给统计结果加一个“高潜力面积占比”字段，不同区域之间可以横向比较，否则单看平均值，可能两个区域平均分差不多，但一个内部很均匀，另一个是有几个极高点拉起来的，决策逻辑完全不同。
5.5 发布为App
GEE Code Editor里写好脚本后，通过“Apps”面板创建应用，会生成一个独立分享链接。界面构建用ui.root作为根容器，地图、控件都挂在这个根节点下，发布后用户打开链接看到的就是纯App界面，不需要看代码。
ui.root.clear(); ui.root.add(controlPanel); ui.root.add(apiMap);发布前记得做两件事：一是把评估公式和数据版本说明写进“关于”面板，二是测试一遍非技术用户的操作路径。我发现很多开发者把App发出去后，用户第一反应是反复缩放找“图例在哪”，而不是点图层。所以界面设计时图例不要藏在二级菜单里，固定显示在地图右下角最稳妥。
6. 实测中遇到的坑与调整
6.1 坐标与经纬度的顺序陷阱
点击交互一开始我遇到过值对不上的问题。点击A点，弹出的数据却是几十公里外的值。排查了一圈才发现是经纬度顺序写反了。GEE的Geometry构造是[经度, 纬度]，而事件返回对象里lon是经度、lat是纬度，看起来没问题，但我在某个回调里习惯性写成了[lat, lon]，结果点位直接跳到了另一片区域。这种问题在静态脚本里不容易暴露，因为整幅图计算不依赖点击坐标，只有交互功能一加上，坐标顺序错误就立刻暴露。后来所有涉及点位的代码都统一走一个函数，不再现场写坐标构造。
6.2 scale选错了，统计结果完全不同
区域统计结果对scale非常敏感。250米数据用500米的像元去统计，均值变化可能不太大，但高潜力面积占比会明显漂移；如果误用10米尺度，统计时会强制对250米数据进行插值细分，相当于编造了并不存在的细节，结果看起来“更精确”，实际是虚假精度。
正确做法是统计尺度跟数据原始分辨率保持一致，最多允许取整倍关系。我最后在统计控件旁边直接写上了“当前统计尺度：250米”，提醒用户这个数字不是任意精度。
6.3 全量计算太慢：预计算资产是关键
初版App启动时要现场算潜力指数，全屏评估范围有上百万像元，用户打开页面经常要先转圈十秒以上。这个体验很难接受。后来我把潜力指数、碳储量这类不变的基础产物先导出到资产（Asset）里，App启动直接addLayer加载，界面秒开；只有用户修改权重时才现场重算，而且重算会自动限制在当前视图范围，避免全图计算。
这个优化大幅缩短了首屏时间。评估工具的使用场景经常是开会演示时临时打开，等十秒和等一秒完全两个概念。预计算资产本质上是“把计算成本前移”，对固定区域、固定数据版本的场景性价比极高。
6.4 配色与图例的“误导性”
第一次配色我用了红绿渐变，红色低潜力、绿色高潜力。结果有次演示，一个色弱同事看后说“这块地红得很，潜力很高吧”。我当场愣住，检查才发现他把红绿亮度混在一起判断。后来换成黄-深绿渐变，并加上了数值标签和图例色块，不再依赖单一颜色传达信息。可视化有一个底线原则：任何信息都不能只靠颜色区别，必须有数字和文字跟着。
图例的另一个坑是色带边界。最初潜力指数图层用的是动态拉伸配色，导致同一区域在不同视图范围下颜色不一样。发现问题后我改成固定色带：0~100分四档，色标写死，任何缩放比例都不变。用户对照图例看色块，给出的结论才可复现。
6.5 区域统计分析大面积超时
画一个几百平方公里的多边形做统计，GEE有时会报超时或者“内存超限”。调大maxPixels能解决一部分，但碰到极端情况还是会挂。我的处理策略是三层：第一，把统计最大范围限制在5000平方公里左右，超过就提示用户缩小范围；第二，统计时先对潜力指数图层做轻量聚合（先reduceToVectors再统计均值），减少像元数量；第三，对单个多边形面积特别大的，按网格切块统计再汇总。这套组合下来，实操中没有再出现统计超时的问题。
7. 后续值得做深的方向
7.1 方法学透明比界面漂亮更重要
做交互式评估工具，我最想强调的一点是：方法学要写在工具里，而不是只写在论文或项目报告里。我的做法是在控制面板底部放一个“评估规则”按钮，点开就能看到完整的公式、分层打分规则、权重来源、数据版本和日期。如果不做这个，用户只是看到一个颜色斑斓的图，理解不了图背后的假设，结果就只能被当成“黑箱”。而黑箱的评估地图，使用频率会断崖式下降。
7.2 从静态潜力到情景对比
目前的版本只输出“当前状态下哪里潜力高”，但更实用的问题是“如果采取不同管理措施，哪里会优先响应”。扩展方向可以引入未来气候情景数据，调整降水/温度因子后再算潜力指数，观察高潜力空间是扩大还是缩小。另一种做法是接入土壤采样点实测数据，作为局部校正因子，让潜力指数在有点位的地区向实测偏移。这个能显著提升现有数据的可信度，也是从“区域筛查”向“地块建议”过渡的关键。
7.3 数据的保质期与更新机制
评估图的保质期通常比很多人想得短。土壤属性模型更新、土地利用图层换版，都会导致潜力分区结果变化。所以更新机制要提前设计好，而不是等别人发现问题后才补救。我现在每个季度重新导出一版预计算资产，同时把上一个版本归档，App内保留版本切换入口，用户可以对比新旧两版看看哪里变了。这样做了之后，每次数据更新反而成了对话机会——大家会主动来问“这次哪变了”，说明他们真的在用这个工具。
最后分享一个实际操作中的体会：做这种地图工具，别一上来就堆功能。先跑通“单点点击读数”，再叠加“区域统计”，最后才上“权重重算”，每一步都让使用者真正用过之后再决定要不要加下一个。我第一次做的时候贪多，同时做了十来个图层切换和下载按钮，结果美观是美观了，核心评估反而被淹没在功能里。工具的价值不在于界面多炫，而在于别人打开它之后，能不能用一句话说清楚“哪里值得补碳，为什么”。做到这一点，这个App就算立住了。
