做遥感这行的人时间大多不是花在分析上而是花在等下载。我最早做县域尺度地表覆盖制图时一个中等县五年的 Landsat 影像从检索、排队、下载、解压到拼成一张能用的年度合成图前后折腾了将近两周硬盘塞满了 400 多个 G最后真正用于建模的像素可能不到总量的十分之一。更别提中间还夹着云掩膜没做干净、坐标系不统一、跨年份辐射定标不一致这些细碎问题。后来我开始把整条链路往云上搬AI Earth 地球科学云平台就是在这个背景下进入我工作流的——它属于达摩院发的那套地球科学云平台把 PB 级的遥感数据、在线 Notebook 算力和一批预训练的 AI 解译模型放在同一个浏览器窗口里。简单说它能让一个只有笔记本、没有服务器的人用几十行代码跑完过去要一周才能跑完的区域级分析。这篇文章我想聊的不是官方文档里那些功能介绍而是一个真正拿它干过活的人会关心的事数据怎么挑、算力怎么省、AI 模型到底能信几分、以及哪几个坑我替你踩过一遍。1. AI Earth 在地球科学工作流里的真实位置1.1 传统遥感处理的三个卡点先说说为什么上云这件事对地学分析不是锦上添花而是效率上的一次结构性改变。传统工作流里最要命的第一个卡点是数据搬运成本。一景 Landsat 8 的 Level 2 产品解压后接近 1 个 G一个省十年的量级轻松上到几十 TB。这些数据你得先下到本地再读进内存算完再写回磁盘整个过程中 CPU 大部分时间在等 IO而不是在算。第二個卡点是环境依赖GDAL 的版本、PROJ 的坐标系库、rasterio 编译时的底层依赖随便一个版本不匹配就能让人调半天换一台机器又要重来一遍。第三个卡点是算力天花板本地做全国尺度的时序合成内存一爆就是 MemoryError然后你只能退而求其次把研究区切小切小之后又面临边界拼接和统计口径不一致的新问题。这三个卡点叠加起来的结果是大量时间被消耗在让流程跑起来而不是让结论站得住。我见过不少做地表变化研究的同学论文里方法写得漂漂亮亮但数据预处理那一段永远是黑箱因为自己也没完全搞清楚当年是怎么把那些影像拼在一起的。1.2 数据不动代码动到底改变了什么云平台的核心逻辑其实一句话能说清把算力搬到数据旁边而不是把数据搬到算力旁边。你在 Notebook 里写的那几行代码会在平台侧的数据中心执行影像不需要落地到你的硬盘。这件事带来的直接好处有三个层面。第一层是时间。以前检索完要等下载现在检索完直接filterBoundsfilterDate就是在做虚拟筛选只有真正参与计算的像素才会被读取。我做长三角一个市的年度合成从写代码到出图大概二十分钟其中十九分钟在等合成和导出。第二层是一致性。平台上的公开数据集是统一做过预处理和元数据规整的投影、波段命名、缩放系数基本统一跨年份、跨传感器的对比不再是玄学。第三层是可复现。你的代码、参数、时间范围、研究区矢量全部记录在一份 Notebook 里别人打开就能重跑这比我本地有份处理好的 TIFF你要不要要靠谱得多。我现在的习惯是每个项目一个 Notebook从检索到出图全部串起来半年后回头改一个参数重新跑五分钟的事。1.3 它不适合谁这点也要说清楚不是所有场景都值得上云。如果你的研究区只有一个县数据量两三个 G本地笔记本跑得动或者你的核心工作是精细的辐射校正算法开发需要对原始 DN 值做大量实验又或者你的数据是涉密的、不能出内网的那云平台帮不上忙。另外如果你只是想看看某地现在什么样其实直接用地図服务的时序影像底图更快没必要动代码。云平台真正的甜点区是这三类区域尺度以上的时序分析省级、流域级、跨国区域、需要批量试参数的模型实验同一套流程跑十几种阈值组合、教学与协作场景一批人用同一套数据和环境。判断标准很简单如果你估计自己的任务在本地要跑超过两小时或者要处理超过 100 景影像那就值得搬到云上。2. 数据货架怎么挑常用数据集与组合策略2.1 光学影像三件套Landsat、Sentinel-2、MODIS 各自的位置平台上的光学数据看着多实际常用的就三类各自的分工非常明确。Landsat 系列Landsat 8/9 的 Collection 2 Level 2是长期时序分析的主力30 米空间分辨率单星重访 16 天Landsat 8 和 9 组网后能压到 8 天左右从 2013 年至今的连续记录基本够用。它的优势是时间跨度长、辐射一致性做得比较好缺点是回访周期长在多云地区一年能用的晴空影像可能只有个位数。Sentinel-2是 10 米分辨率、5 天重访在空间细节和时间密度上都压过 Landsat做城市内部结构、小水体、地块边界的活儿它是首选。但要注意它的波段分辨率不一致10 米的是 B2/B3/B4/B820 米的是红边和 SWIR 那一批B5-B7、B8A、B11、B12做指数计算时如果直接混用分辨率会被自动对齐到最粗的那一档细节收益就没了。我的做法是先用 10 米波段做主分析需要 SWIR 的指数比如 MNDWI时单独处理心里清楚这一步的代价。MODIS是 250 米到 1 公里级的日频数据它的定位不是看得清而是看得勤。做物候分析、大区域快速变化预警、给高分辨率结果提供时间维度的上下文MODIS 的价值无可替代。常见产品是 MOD09 系列地表反射率和 MOD13 系列的植被指数后者已经算好了 NDVI 和 EVI直接拿来用可以省掉一步。选择逻辑可以总结成一句话要看长期趋势选 Landsat要看空间细节选 Sentinel-2要看时间密度选 MODIS。三者不是替代关系很多时候是互补的比如用 MODIS 定位变化发生的月份再用 Sentinel-2 定位变化发生的具体地块。数据集空间分辨率重访周期常见用途主要短板Landsat 8/9 C02 L230 米全色 15 米8 天双星长时序趋势、省级制图单年晴空影像少Sentinel-2 MSI10/20/60 米5 天城市细节、小水体波段分辨率不一2015 年前无数据MODIS250/500/1000 米1-2 天物候、大区域预警混合像元严重2.2 立体与辅助数据DEM、夜光、降水光有光学影像做不了完整的分析。DEM 数据比如 SRTM 或 ASTER GDEM至少有三个用途一是做坡度、坡向参与地形校正和分类特征构建二是做高程分区统计比如把研究区按海拔分带后分别做分类能显著提升山地场景的精度三是做地形阴影掩膜把因为地形遮蔽导致的异常暗像元剔掉否则这些像元在分类器眼里会被误判成水体。夜光遥感比如 NPP-VIIRS 的月度合成是城市研究的利器建成区的提取用夜光比用光学影像有时更直接因为它对灯光强度的响应和人类活动强度高度相关。但要注意夜光数据的饱和问题特大城市核心区容易过饱和用它做城市面积统计会有系统性低估通常需要和光学影像做交叉验证。降水与温度栅格这类气象数据在植被分析里是必需的对照变量。做 NDVI 年际波动分析时如果不把降水年际变化这个变量控制住你很容易把今年雨水多所以植被长得好误读成生态恢复有效。这一步是很多论文里被忽略的但审稿人经常问。2.3 检索四件套时间、空间、云量、波段在平台上做数据检索永远是这四个条件在组合。时间范围决定了你拿到多少景空间范围决定了单景被裁掉多少云量阈值决定了有效影像的筛选强度波段选择决定了后面计算的数据量。这四个条件里最容易被滥用的是云量阈值。我见过不少人直接把云量过滤设成 10% 以下结果一年只剩两三景做中值合成的时候样本严重不足最后出来的图有明显的条带感。正确做法是先看研究区的气候背景如果是干旱区设 20% 都可能偏严如果是长江中下游全年能有 30% 以下云量的影像本来就不多设 40% 再配合逐像元云掩膜比设 10% 直接丢掉大半影像要好得多。空间范围也有讲究。很多人习惯先圈一个很大的矩形再在里面慢慢筛这样每次计算扫描的瓦片数会成倍增加。我的习惯是把研究区矢量简化simplify一下再上传去掉那些为了精度加进去的碎顶点一个县域的边界从三万多个点简化到两三千个点几何运算耗时能降一个量级而实际面积误差可以忽略。提示上传矢量时优先用 WGS84 经纬度EPSG:4326或平台明确支持的投影坐标系不对会导致 filterBounds 返回空集合这个错误不会报异常只会让你拿到零景影像非常容易误判为这个区域没有数据。3. 在线 Notebook 实战环境、内存与导出3.1 初始化与依赖管理平台的在线 Notebook 本质是一个托管环境你需要先做认证和初始化然后才能调用数据接口。接口风格和主流的地球科学云平台很像如果你有 GEE 的使用经验上手基本没有障碍。下面这段是我常用的起手式注意这是示意写法具体的类名和方法请以平台当前文档为准因为这套 SDK 更新比较频繁。import aie aie.Authenticate() # 绑定平台账号 aie.Initialize() # 初始化地图与计算上下文 roi aie.FeatureCollection(projects/xxx/assets/my_county) collection (aie.ImageCollection(LANDSAT/LC09/C02/T1_L2) .filterDate(2023-06-01, 2023-09-30) .filterBounds(roi) .filter(aie.Filter.lte(eo:cloud_cover, 40)))关于依赖平台预装了 numpy、pandas、rasterio、geopandas 这些常用库绝大多数分析不用自己装。真正需要自己装的情况通常是你要用某个特定的深度学习框架或某个冷门的投影库这时候要注意在线环境的持久化问题很多平台的 Notebook 一旦重启手动 pip 安装的包就没了。我的做法是把安装命令写在 Notebook 第一格重启后顺手跑一遍比去研究持久化配置要省心。还有一个细节认证凭证是有有效期的。跑长任务的时候如果中间凭证过期导出任务可能会失败。所以长时间运行的导出操作最好在任务启动后确认一下任务状态别设完就跑去做别的事。3.2 分块与降采样别让内存先崩云平台虽然算力比本地强但也不是无限的尤其是在线 Notebook 用的往往是共享资源。我踩过最惨的一次坑是直接对全省范围做年度中值合成代码没报错跑了四十多分钟之后任务被中断原因是内存超限。后来改成网格分块处理把研究区切成 20 公里见方的格子循环处理每一格再拼接统计结果同样的任务十几分钟就跑完了而且中途某一格失败可以单独重跑。分块的逻辑不复杂核心是在空间维度上切而不是在时间维度上切。时间维度切开会导致每年的合成图来自不同的影像集合跨年对比时引入额外噪声。空间维度切开的代价只有边界拼接处理起来简单得多。grid roi.geometry().coveringGrid(EPSG:4326, 20000) # 示意 results [] for i in range(grid.size().getInfo()): cell grid.get(i) comp (collection.filterBounds(cell) .map(mask_qa) .median() .clip(cell)) stat comp.reduceRegion( reduceraie.Reducer.mean(), geometrycell, scale30, maxPixels1e13, bestEffortTrue ) results.append(stat.getInfo())maxPixels和bestEffort这两个参数值得单独说。默认的maxPixels值很小做区域统计时经常被拒绝报一个too many pixels的错。把它调到 1e13 配合bestEffortTrue平台会自动调整采样步长来完成统计代价是精度会略降。用于趋势分析完全够用但如果是要做最终的面积统计我还是会老实用分块 精确尺度算不依赖重采样。降采样是另一个省资源的技巧。做参数试错阶段完全没必要用 30 米全分辨率跑把scale设成 300 米速度能快十倍以上等你确定阈值和流程了再用原分辨率跑最终结果。这个习惯让我在调试阶段节省了大量算力额度。3.3 导出格式与参数导出是整条链路里最容易被低估的一步。平台上的栅格导出一般可以选 GeoTIFF矢量导出可以选 Shapefile 或 GeoJSON统计结果直接导 CSV。几个参数必须显式指定别依赖默认值。scale决定输出分辨率写 30 就是 30 米crs决定输出投影如果你的研究区跨带或者要做面积统计这里必须换成等积投影比如 Albers 等积投影具体参数要根据研究区中心纬度定region决定导出范围写roi.geometry()就是按矢量边界裁写roi.geometry().bounds()就是按外接矩形裁后者速度更快但文件更大。task aie.Image.export( imageclassification, descriptionlandcover_2023, scale30, crsEPSG:xxxx, # 换成适合研究区的等积投影 regionroi.geometry(), maxPixels1e13, fileFormatGeoTIFF )description是任务名不能有中文和空格我一般用项目名_年份_版本的格式比如lc2023_v2方便后续在任务列表里检索。另外要注意同时运行的导出任务数通常有上限批量导出的时候用一个简单队列控制并发数别一次性提交三十个任务容易被限流。还有一个导出失败的高频原因是输出尺寸超限。单次导出的像素总量是有上限的如果研究区很大、分辨率又要求很细导出的 TIFF 会超出限制。解决办法有两个要么降低分辨率要么按分块分别导出再在本地拼接。我一般用第二个因为分块导出的结果可以直接用于后续的分块统计一举两得。4. 预训练 AI 解译模型能做什么、做不到什么4.1 几类任务的实际表现平台提供了一批预训练的 AI 解译能力常见的有地物分类、变化检测、目标检测比如提取光伏板、风机、大棚这类特定目标、语义分割等。这些模型是开箱可用的你不用自己训练就能跑出结果这一点对没有深度学习背景的地学研究者非常友好。但真实表现和宣传图之间是有落差的我按自己的使用经验给个大致判断。大尺度地物分类水体、植被、建设用地、裸地这类宏观类别表现通常不错因为它对纹理和光谱差异的依赖不强模型见过的样本也多。特定目标检测在目标形态规整、背景单一的场景下效果很好比如在平坦农田里提取光伏板阵列召回率能到很高但一旦目标被遮挡、或者背景本身很杂乱漏检就明显增加。变化检测是最需要小心的一类因为它对前后两期影像的配准精度、时相一致性、辐射一致性都极其敏感输入差一点输出可能就是一堆噪点。我的一般原则是把 AI 模型当成一个高质量的预标注工具而不是最终产品。用它跑出初稿再人工修正关键区域效率比纯人工高出一个量级精度又比纯模型靠谱。4.2 微调与样本量的关系如果你需要更高的精度就得自己标样本做微调。这里有个常见误解很多人以为样本越多越好于是花两周硬标了五千个点结果精度提升有限。实际上在小样本场景里样本的空间分布质量比数量重要得多。我的经验是标 200 到 400 个高质量样本点如果分布覆盖了研究区的所有地物类型和地形梯度效果往往好过 2000 个扎堆在平原区的样本点。原因很简单模型学到的是特征的边界如果你没给它看过山地阴影下的水体、城镇边缘的混合像元、休耕期的农田它就没有办法在这些区域做出正确判断。样本标注还有两个细节容易被忽略。一是纯像元原则标注点要落在类别内部的均质区域不要落在类别边界上。30 米分辨率下一个像素对应地表 900 平方米在城乡交错带几乎不存在纯像元这些地方标注本身就是错的标进去只会给模型添乱。二是类别平衡如果建设用地只占研究区的 5%而植被占 70%直接训练会导致模型倾向于把所有模棱两可的像元都判成植被。解决方法是欠采样大类或者给类别加权我通常用加权因为欠采样会丢掉大量信息。4.3 精度评价的正确姿势模型跑完出来一张花花绿绿的分类图这时候最容易犯的错误是直接看图觉得挺像的就交付了。分类精度必须量化而且要看的东西不止一个数字。最基础的是混淆矩阵从中能算出总体精度OA、Kappa 系数以及每一类的制图精度Producers Accuracy和用户精度Users Accuracy。这里有个概念必须分清制图精度说的是真实属于 A 类的像元里有多少被正确识别为 A用户精度说的是被识别为 A 的像元里有多少是真的 A。前者的误差是漏分后者的误差是错分。对做面积统计的人来说用户精度更关键因为你统计出来的 A 类面积里掺杂的错分部分会直接造成偏差。更进一步的一步是面积无偏估计。即使分类图精度是 90%直接数像素算出来的面积依然可能有系统性偏差尤其是小类别。做法是用分层随机抽样每一类按分类图中的比例分配样本量对样本做人工判读然后用矩阵反推真实面积比例。这套方法在小类别的面积估计上能把误差从百分之十几压到百分之五以内代价是要人工判读几百个点。如果你做的是要对外发布的变化数据这步不能省。验证样本的来源也有讲究。如果研究区有历史的高分辨率影像比如亚米级的商业影像存档用它做参考最理想没有的话用同期更高分辨率的免费影像辅助判读。要避免的是用同一套影像既训练又验证那样得到的精度是虚高的。5. 一条完整的实战链路城市扩张监测5.1 问题定义与指标光讲原理没意思我把一个完整的项目拆开走一遍。任务是这样某地级市 2013 到 2023 年的建成区扩张监测输出每年的建成区范围、面积统计、扩张方向以及新增建成区占用的原土地类型构成。指标要提前定死不然做到一半会不断改需求。我的指标体系是分类总体精度不低于 85%Kappa 不低于 0.8面积相对误差控制在 10% 以内逐年结果的空间配准误差不超过一个像元。这几个数字不是拍脑袋来的是参考同类研究的通行标准也是审稿人会盯的地方。还有一个容易被忽略的前置决策建成区的定义。是只算连续的人工不透水面还是包含城市内部的大片绿地和水体这个定义直接决定分类体系的类别划分也决定了后续的面积数字怎么解释。我采用的是连续不透水面为主、剔除面积大于一定阈值的水体、保留城市内部绿地的口径并在交付文档里写清楚避免用的人按自己的理解再解释一遍。5.2 云掩膜与年度合成数据源用 Landsat 8 和 9 的 Collection 2 Level 2时间窗口选每年 6 月到 9 月的生长季。为什么选生长季因为这时候植被茂盛植被和不透水面的光谱差异最大分类最容易分开如果混入冬季影像落叶林和建成区的光谱会接近误差上升。第一步是云掩膜用 QA_PIXEL 波段做位运算。CLOUD_BITS (1 1) | (1 2) | (1 3) | (1 4) | (1 5) def mask_qa(img): qa img.select(QA_PIXEL) mask qa.bitwiseAnd(CLOUD_BITS).eq(0) return img.updateMask(mask) def scale_sr(img): optical img.select(SR_B.*).multiply(0.0000275).add(-0.2) return img.addBands(optical, None, True)位运算这段值得解释。QA_PIXEL 是一个 16 位整数每一位代表一种状态位 1 是膨胀云位 2 是卷云位 3 是云位 4 是云阴影位 5 是雪。把这几位对应的数值按位或起来再检查结果是不是零是零就说明这些状态一个都没触发这个像素是干净的。用位运算而不是简单比较数值是因为一个像素可能同时是好几种状态的组合数值会变得很大直接比大小会漏掉情况。scale_sr里的两个系数是 Collection 2 Level 2 产品特有的。它的地表反射率存的是整数需要乘 0.0000275 再减 0.2 才能还原成真实反射率。这一步看着不起眼但不做的话所有指数的绝对值和阈值全部偏移我见过有人因为这个把 NDVI 的阈值定错了 0.15水体边界整整扩出去一圈。掩膜完成后做中值合成。这里有个顺序问题必须先掩膜再合成不能先合成再掩膜。原因很直观中值是对所有影像逐个像素取中位数如果云像素还在里面它就会参与中位数的计算在有多云影像的时候中值会被污染。先掩膜之后被遮掉的像素不参与合成中值才是干净的。5.3 分类后处理与面积统计合成的年度影像上算几个指数作为特征NDVI 区分植被NDBI归一化建筑指数用 SWIR1 和 NIR突出不透水面MNDWI改进的归一化水体指数用绿波段和 SWIR1提取水体。MNDWI 相比传统的 NDWI 的优势在于它用了 SWIR1 而不是 NIR在建成区背景下水体的对比度更强。传统 NDWI 在城市区域会因为建筑的高反射率出现大量误判MNDWI 把这个问题解决得比较彻底代价是它对 SWIR 波段的分辨率有依赖Sentinel-2 上 SWIR 是 20 米会拉低整体分辨率。分类可以用平台的监督分类能力也可以用随机森林。我这次用的是随机森林特征包括三个指数加上原始的多光谱波段样本 320 个训练集和验证集按 7:3 分。分类完之后做两步后处理一是众数滤波用一个 3×3 窗口把孤立的单像素噪声平滑掉二是最小图斑剔除把面积小于 3 个像素的图斑合并到周围面积最大的类别里。这两步能把视觉上的椒盐噪声清掉对面积统计的影响通常在 1% 以内但成图效果提升明显。面积统计是全流程里最容易出错的一步。必须先把分类结果重投影到等积投影再数像素。在经纬度坐标系下一个像素对应的实际面积随纬度变化同样是 30 米在赤道和高纬度的真实面积差很多。我的做法是用研究区中心纬线定制一个 Albers 等积投影在这个投影下每像素 900 平方米直接数像素乘以 900 就完事。5.4 出图与结果表达出图这一步看起来简单其实决定了成果能不能被看懂。我一般准备三张图一张是逐年建成区范围的制图用同一条色带从浅到深表示年份一张是新增建成区的空间分布用不同颜色标出各年份的新增部分第三张是扩张方向的雷达图或玫瑰图把新增面积按八个方位统计后画出来一眼就能看出城市往哪个方向长。配色上有个教训分类图不要用高饱和度的纯色。纯红纯绿纯蓝放在一起在不同显示器上观感差异很大打印出来更难看。用低饱和度的分类色板配合清晰的类别图例和比例尺专业感会好很多。另外栅格图导出的时候把dpi提到 300 以上做汇报和打印都够用。如果需要把结果做成在线可交互的形式可以在 Notebook 里直接叠加到地图控件上设置一个透明度滑杆让不同图层可以切换对比。这个功能在做汇报的时候特别好用比静态图有说服力得多。6. 六个真实踩坑现场与修复思路6.1 面积算出来差了 15%投影没换这个坑前面提过但它太常见了值得单独说一遍。我第一次做全市建成区面积统计用经纬度坐标直接数像素结果算出来的面积比统计年鉴的数字小了将近 15%。当时以为是分类精度问题回头查了半天才反应过来是投影的事。在纬度 30 度附近经纬度网格的面积变形大概是 10% 到 15% 的量级正好对上。修复很简单用reproject把结果转成等积投影再统计。但这里有个陷阱如果你导出的时候已经写死了 30 米的分辨率重投影之后分辨率会变成不均匀的统计就不准了。所以顺序应该是先重投影到等积投影再按等积投影下的固定分辨率导出和统计。6.2 云掩膜写在合成之后等于没做有一段时间我图省事把掩膜写在median()之后逻辑上好像也对——先把一年影像合成一张再对合成结果做云掩膜。结果在某些多云区域合成图上出现了大片异常亮的斑块分类的时候被误判成了裸地。原因就是前面说的中值合成之前云像素还参与计算。如果一年只有五景影像其中三景有云那么某一像素的中位数很可能就是一个云像素的值。修复的方法是把掩膜放在集合映射阶段让它在合成前就生效。这不是性能问题是正确性问题。6.3 跨传感器对比辐射定标与被遗忘的偏移量做 2013 到 2023 年的对比早年用的是 Landsat 8后来加了 Landsat 9。两者都是 Collection 2 Level 2理论上辐射是一致的但实际上如果对其中一个忘了做缩放系数转换NDVI 的整体偏移会很明显。我遇到过一年数据显示植被指数整体偏低 0.05 的情况排查很久才发现是那批影像在预处理的某个分支里跳过了缩放步骤。避免这类问题的办法是把预处理写成一个函数所有数据源都走同一个函数不要在流程里写分支。多花十分钟统一接口能省掉后面几天的排查时间。跨传感器对比时还可以用重叠期的影像做交叉标定比如 2021 年 Landsat 8 和 9 都有数据用同期的两套数据比较同一地物的反射率如果系统性偏差超过 2%就说明定标环节有问题。6.4 物候错配导致的假变化这是我见过的最隐蔽的一类错误。做变化检测时如果两期影像一个是 6 月一个是 10 月植被的物候差异会被模型识别成地物变化。一月份的农田是裸土反射率七月份是茂盛植被两者光谱差异极大变化检测会把它们判成从裸地变成植被。避免方法是尽量用相同时相窗口的影像比如都限定在 7 月到 8 月。如果实在做不到就在模型里加入物候校正或者改用基于时序曲线的方法而不是两期对比。我现在的习惯是在变化检测的结果图上叠加一个物候敏感性检查把研究区内的农田区域单独拿出来看如果农田区域变化特别剧烈八成是物候问题而不是真的变化。6.5 导出任务失败与分辨率陷阱导出失败的原因我遇到过三类。一是输出尺寸超限解决办法是分块导出二是任务名重复同一个description提交两次第二次会被拒解决办法是加版本号三是并发数超限一次提交太多任务被限流解决办法是写个简单的循环加延时。分辨率陷阱更隐蔽一些。有些平台在导出时会自动把分辨率对齐到数据源的网格如果你请求的是 25 米实际输出可能是 30 米统计的时候按 25 米算就会出现偏差。所以导出后一定要检查输出文件的元数据确认实际的分辨率、投影、范围都符合预期别假设它跟你请求的一致。6.6 样本画在混合像元上前面提过纯像元原则这里补充一个具体场景。在城乡交错带采样如果经验不足很容易把样本点落在看起来像建设用地其实一半是菜地的地方。这类样本进了训练集会显著拉低模型的边界判断能力表现是验证精度上不去但加样本也没用。我的做法是先在目标区域的 Google 级别高分底图上判断确认是均质区域再落点。另外采样之后做一次样本特征的可分性检查比如画各类样本在 NDVI-NDBI 平面上的散点如果某一类样本在特征空间里和其他类别严重重叠就说明采样有问题需要重新标。7. 免费额度与福利资源的正确用法7.1 新用户资源包里最值钱的是什么平台对新用户通常会提供一定的免费资源形式可能是算力时长、存储空间或者特定模型的调用额度。这些东西里最值钱的是算力时长因为存储和公开数据的访问基本不构成瓶颈。算力时长用完了要么等下一个周期要么就得走付费所以在试错阶段把算力省着用是很实际的考虑。我见过有人把免费额度拿去跑一个全国范围的初次实验一次跑掉大半后面调参的时候发现没额度了。这完全是策略问题跟技术无关。7.2 调试与生产的资源分配我的资源分配原则是粗调省、精跑贵具体来说就是把整个项目分成三个阶段。第一个是探索阶段用小范围、低分辨率比如 300 米、短时间窗口跑通整条链路确认代码逻辑没问题这个阶段消耗大概 5% 的额度。第二个是参数阶段在研究区内选两三个有代表性的小区域用中等分辨率跑十几种参数组合比较结果这个阶段消耗 20%。第三个是生产阶段全区域、原分辨率、分块跑最终结果这个阶段消耗剩下的 75%。按这个节奏即使免费额度不多也能完整跑完一个地级市级别的项目。反过来说如果一上来就在全区域跑全分辨率第一次跑错一个参数整批额度就没了。7.3 比赛、训练营与公开课程除了资源额度平台上经常会有一些公开的活动比如遥感相关的算法比赛、线上训练营、公开课程。这些东西的价值不止在于奖品更在于它们通常会提供额外的算力资源和高质量的标注样本。我参加过一次水体提取的比赛拿到的训练样本质量比我自己标的好很多而且赛题设定逼着你把流程做得规范赛后的代码可以直接复用。另外一个容易被忽略的资源是平台上其他用户公开的 Notebook。很多常见任务都能找到现成的实现你不需要从零开始写。我习惯的做法是找三四个类似的实现对比它们的处理顺序和参数设置看看差异在哪然后挑最合理的部分组合成自己的流程。这比闷头自己写快得多也能避免一些自己想不到的坑。一些实际操作后的体会用了几年下来我觉得这类地球科学云平台真正的价值不在AI这两个字上而在它把数据、算力和协作这三件事塞进了同一个环境里。AI 解译能力确实好用但它更像是一个能帮你省掉 70% 重复劳动的工具剩下的 30% 判断工作——定义分类体系、检查物候错配、验证精度、解释结果——依然得人来完成。如果让我给刚开始用的人一条建议那就是先别急着跑大区域。选一个你熟悉的地方比如你老家的一个县用一两个小时的影像跑一遍完整的流程从检索到出图到精度验证全部走通。你会在这条小链路上遇到几乎所有后面会遇到的坑但代价小得多。等这条链路跑顺了再放大到流域或者省域只是参数和分块策略的调整而已。还有一个私心建议把每次跑的 Notebook 都存一份带日期的备份。我吃过一次亏半年前的一个项目需要重新出一版图结果当时的代码在编辑过程中被改乱了花了两天才复原。现在我每个项目目录下都有v1、v2、v3这样的版本快照多占一点存储空间换来的是随时能回到任意一个历史状态。 AI Earth地球科学云平台遥感实战：城市扩张监测与避坑
做遥感这行的人时间大多不是花在分析上而是花在等下载。我最早做县域尺度地表覆盖制图时一个中等县五年的 Landsat 影像从检索、排队、下载、解压到拼成一张能用的年度合成图前后折腾了将近两周硬盘塞满了 400 多个 G最后真正用于建模的像素可能不到总量的十分之一。更别提中间还夹着云掩膜没做干净、坐标系不统一、跨年份辐射定标不一致这些细碎问题。后来我开始把整条链路往云上搬AI Earth 地球科学云平台就是在这个背景下进入我工作流的——它属于达摩院发的那套地球科学云平台把 PB 级的遥感数据、在线 Notebook 算力和一批预训练的 AI 解译模型放在同一个浏览器窗口里。简单说它能让一个只有笔记本、没有服务器的人用几十行代码跑完过去要一周才能跑完的区域级分析。这篇文章我想聊的不是官方文档里那些功能介绍而是一个真正拿它干过活的人会关心的事数据怎么挑、算力怎么省、AI 模型到底能信几分、以及哪几个坑我替你踩过一遍。1. AI Earth 在地球科学工作流里的真实位置1.1 传统遥感处理的三个卡点先说说为什么上云这件事对地学分析不是锦上添花而是效率上的一次结构性改变。传统工作流里最要命的第一个卡点是数据搬运成本。一景 Landsat 8 的 Level 2 产品解压后接近 1 个 G一个省十年的量级轻松上到几十 TB。这些数据你得先下到本地再读进内存算完再写回磁盘整个过程中 CPU 大部分时间在等 IO而不是在算。第二個卡点是环境依赖GDAL 的版本、PROJ 的坐标系库、rasterio 编译时的底层依赖随便一个版本不匹配就能让人调半天换一台机器又要重来一遍。第三个卡点是算力天花板本地做全国尺度的时序合成内存一爆就是 MemoryError然后你只能退而求其次把研究区切小切小之后又面临边界拼接和统计口径不一致的新问题。这三个卡点叠加起来的结果是大量时间被消耗在让流程跑起来而不是让结论站得住。我见过不少做地表变化研究的同学论文里方法写得漂漂亮亮但数据预处理那一段永远是黑箱因为自己也没完全搞清楚当年是怎么把那些影像拼在一起的。1.2 数据不动代码动到底改变了什么云平台的核心逻辑其实一句话能说清把算力搬到数据旁边而不是把数据搬到算力旁边。你在 Notebook 里写的那几行代码会在平台侧的数据中心执行影像不需要落地到你的硬盘。这件事带来的直接好处有三个层面。第一层是时间。以前检索完要等下载现在检索完直接filterBoundsfilterDate就是在做虚拟筛选只有真正参与计算的像素才会被读取。我做长三角一个市的年度合成从写代码到出图大概二十分钟其中十九分钟在等合成和导出。第二层是一致性。平台上的公开数据集是统一做过预处理和元数据规整的投影、波段命名、缩放系数基本统一跨年份、跨传感器的对比不再是玄学。第三层是可复现。你的代码、参数、时间范围、研究区矢量全部记录在一份 Notebook 里别人打开就能重跑这比我本地有份处理好的 TIFF你要不要要靠谱得多。我现在的习惯是每个项目一个 Notebook从检索到出图全部串起来半年后回头改一个参数重新跑五分钟的事。1.3 它不适合谁这点也要说清楚不是所有场景都值得上云。如果你的研究区只有一个县数据量两三个 G本地笔记本跑得动或者你的核心工作是精细的辐射校正算法开发需要对原始 DN 值做大量实验又或者你的数据是涉密的、不能出内网的那云平台帮不上忙。另外如果你只是想看看某地现在什么样其实直接用地図服务的时序影像底图更快没必要动代码。云平台真正的甜点区是这三类区域尺度以上的时序分析省级、流域级、跨国区域、需要批量试参数的模型实验同一套流程跑十几种阈值组合、教学与协作场景一批人用同一套数据和环境。判断标准很简单如果你估计自己的任务在本地要跑超过两小时或者要处理超过 100 景影像那就值得搬到云上。2. 数据货架怎么挑常用数据集与组合策略2.1 光学影像三件套Landsat、Sentinel-2、MODIS 各自的位置平台上的光学数据看着多实际常用的就三类各自的分工非常明确。Landsat 系列Landsat 8/9 的 Collection 2 Level 2是长期时序分析的主力30 米空间分辨率单星重访 16 天Landsat 8 和 9 组网后能压到 8 天左右从 2013 年至今的连续记录基本够用。它的优势是时间跨度长、辐射一致性做得比较好缺点是回访周期长在多云地区一年能用的晴空影像可能只有个位数。Sentinel-2是 10 米分辨率、5 天重访在空间细节和时间密度上都压过 Landsat做城市内部结构、小水体、地块边界的活儿它是首选。但要注意它的波段分辨率不一致10 米的是 B2/B3/B4/B820 米的是红边和 SWIR 那一批B5-B7、B8A、B11、B12做指数计算时如果直接混用分辨率会被自动对齐到最粗的那一档细节收益就没了。我的做法是先用 10 米波段做主分析需要 SWIR 的指数比如 MNDWI时单独处理心里清楚这一步的代价。MODIS是 250 米到 1 公里级的日频数据它的定位不是看得清而是看得勤。做物候分析、大区域快速变化预警、给高分辨率结果提供时间维度的上下文MODIS 的价值无可替代。常见产品是 MOD09 系列地表反射率和 MOD13 系列的植被指数后者已经算好了 NDVI 和 EVI直接拿来用可以省掉一步。选择逻辑可以总结成一句话要看长期趋势选 Landsat要看空间细节选 Sentinel-2要看时间密度选 MODIS。三者不是替代关系很多时候是互补的比如用 MODIS 定位变化发生的月份再用 Sentinel-2 定位变化发生的具体地块。数据集空间分辨率重访周期常见用途主要短板Landsat 8/9 C02 L230 米全色 15 米8 天双星长时序趋势、省级制图单年晴空影像少Sentinel-2 MSI10/20/60 米5 天城市细节、小水体波段分辨率不一2015 年前无数据MODIS250/500/1000 米1-2 天物候、大区域预警混合像元严重2.2 立体与辅助数据DEM、夜光、降水光有光学影像做不了完整的分析。DEM 数据比如 SRTM 或 ASTER GDEM至少有三个用途一是做坡度、坡向参与地形校正和分类特征构建二是做高程分区统计比如把研究区按海拔分带后分别做分类能显著提升山地场景的精度三是做地形阴影掩膜把因为地形遮蔽导致的异常暗像元剔掉否则这些像元在分类器眼里会被误判成水体。夜光遥感比如 NPP-VIIRS 的月度合成是城市研究的利器建成区的提取用夜光比用光学影像有时更直接因为它对灯光强度的响应和人类活动强度高度相关。但要注意夜光数据的饱和问题特大城市核心区容易过饱和用它做城市面积统计会有系统性低估通常需要和光学影像做交叉验证。降水与温度栅格这类气象数据在植被分析里是必需的对照变量。做 NDVI 年际波动分析时如果不把降水年际变化这个变量控制住你很容易把今年雨水多所以植被长得好误读成生态恢复有效。这一步是很多论文里被忽略的但审稿人经常问。2.3 检索四件套时间、空间、云量、波段在平台上做数据检索永远是这四个条件在组合。时间范围决定了你拿到多少景空间范围决定了单景被裁掉多少云量阈值决定了有效影像的筛选强度波段选择决定了后面计算的数据量。这四个条件里最容易被滥用的是云量阈值。我见过不少人直接把云量过滤设成 10% 以下结果一年只剩两三景做中值合成的时候样本严重不足最后出来的图有明显的条带感。正确做法是先看研究区的气候背景如果是干旱区设 20% 都可能偏严如果是长江中下游全年能有 30% 以下云量的影像本来就不多设 40% 再配合逐像元云掩膜比设 10% 直接丢掉大半影像要好得多。空间范围也有讲究。很多人习惯先圈一个很大的矩形再在里面慢慢筛这样每次计算扫描的瓦片数会成倍增加。我的习惯是把研究区矢量简化simplify一下再上传去掉那些为了精度加进去的碎顶点一个县域的边界从三万多个点简化到两三千个点几何运算耗时能降一个量级而实际面积误差可以忽略。提示上传矢量时优先用 WGS84 经纬度EPSG:4326或平台明确支持的投影坐标系不对会导致 filterBounds 返回空集合这个错误不会报异常只会让你拿到零景影像非常容易误判为这个区域没有数据。3. 在线 Notebook 实战环境、内存与导出3.1 初始化与依赖管理平台的在线 Notebook 本质是一个托管环境你需要先做认证和初始化然后才能调用数据接口。接口风格和主流的地球科学云平台很像如果你有 GEE 的使用经验上手基本没有障碍。下面这段是我常用的起手式注意这是示意写法具体的类名和方法请以平台当前文档为准因为这套 SDK 更新比较频繁。import aie aie.Authenticate() # 绑定平台账号 aie.Initialize() # 初始化地图与计算上下文 roi aie.FeatureCollection(projects/xxx/assets/my_county) collection (aie.ImageCollection(LANDSAT/LC09/C02/T1_L2) .filterDate(2023-06-01, 2023-09-30) .filterBounds(roi) .filter(aie.Filter.lte(eo:cloud_cover, 40)))关于依赖平台预装了 numpy、pandas、rasterio、geopandas 这些常用库绝大多数分析不用自己装。真正需要自己装的情况通常是你要用某个特定的深度学习框架或某个冷门的投影库这时候要注意在线环境的持久化问题很多平台的 Notebook 一旦重启手动 pip 安装的包就没了。我的做法是把安装命令写在 Notebook 第一格重启后顺手跑一遍比去研究持久化配置要省心。还有一个细节认证凭证是有有效期的。跑长任务的时候如果中间凭证过期导出任务可能会失败。所以长时间运行的导出操作最好在任务启动后确认一下任务状态别设完就跑去做别的事。3.2 分块与降采样别让内存先崩云平台虽然算力比本地强但也不是无限的尤其是在线 Notebook 用的往往是共享资源。我踩过最惨的一次坑是直接对全省范围做年度中值合成代码没报错跑了四十多分钟之后任务被中断原因是内存超限。后来改成网格分块处理把研究区切成 20 公里见方的格子循环处理每一格再拼接统计结果同样的任务十几分钟就跑完了而且中途某一格失败可以单独重跑。分块的逻辑不复杂核心是在空间维度上切而不是在时间维度上切。时间维度切开会导致每年的合成图来自不同的影像集合跨年对比时引入额外噪声。空间维度切开的代价只有边界拼接处理起来简单得多。grid roi.geometry().coveringGrid(EPSG:4326, 20000) # 示意 results [] for i in range(grid.size().getInfo()): cell grid.get(i) comp (collection.filterBounds(cell) .map(mask_qa) .median() .clip(cell)) stat comp.reduceRegion( reduceraie.Reducer.mean(), geometrycell, scale30, maxPixels1e13, bestEffortTrue ) results.append(stat.getInfo())maxPixels和bestEffort这两个参数值得单独说。默认的maxPixels值很小做区域统计时经常被拒绝报一个too many pixels的错。把它调到 1e13 配合bestEffortTrue平台会自动调整采样步长来完成统计代价是精度会略降。用于趋势分析完全够用但如果是要做最终的面积统计我还是会老实用分块 精确尺度算不依赖重采样。降采样是另一个省资源的技巧。做参数试错阶段完全没必要用 30 米全分辨率跑把scale设成 300 米速度能快十倍以上等你确定阈值和流程了再用原分辨率跑最终结果。这个习惯让我在调试阶段节省了大量算力额度。3.3 导出格式与参数导出是整条链路里最容易被低估的一步。平台上的栅格导出一般可以选 GeoTIFF矢量导出可以选 Shapefile 或 GeoJSON统计结果直接导 CSV。几个参数必须显式指定别依赖默认值。scale决定输出分辨率写 30 就是 30 米crs决定输出投影如果你的研究区跨带或者要做面积统计这里必须换成等积投影比如 Albers 等积投影具体参数要根据研究区中心纬度定region决定导出范围写roi.geometry()就是按矢量边界裁写roi.geometry().bounds()就是按外接矩形裁后者速度更快但文件更大。task aie.Image.export( imageclassification, descriptionlandcover_2023, scale30, crsEPSG:xxxx, # 换成适合研究区的等积投影 regionroi.geometry(), maxPixels1e13, fileFormatGeoTIFF )description是任务名不能有中文和空格我一般用项目名_年份_版本的格式比如lc2023_v2方便后续在任务列表里检索。另外要注意同时运行的导出任务数通常有上限批量导出的时候用一个简单队列控制并发数别一次性提交三十个任务容易被限流。还有一个导出失败的高频原因是输出尺寸超限。单次导出的像素总量是有上限的如果研究区很大、分辨率又要求很细导出的 TIFF 会超出限制。解决办法有两个要么降低分辨率要么按分块分别导出再在本地拼接。我一般用第二个因为分块导出的结果可以直接用于后续的分块统计一举两得。4. 预训练 AI 解译模型能做什么、做不到什么4.1 几类任务的实际表现平台提供了一批预训练的 AI 解译能力常见的有地物分类、变化检测、目标检测比如提取光伏板、风机、大棚这类特定目标、语义分割等。这些模型是开箱可用的你不用自己训练就能跑出结果这一点对没有深度学习背景的地学研究者非常友好。但真实表现和宣传图之间是有落差的我按自己的使用经验给个大致判断。大尺度地物分类水体、植被、建设用地、裸地这类宏观类别表现通常不错因为它对纹理和光谱差异的依赖不强模型见过的样本也多。特定目标检测在目标形态规整、背景单一的场景下效果很好比如在平坦农田里提取光伏板阵列召回率能到很高但一旦目标被遮挡、或者背景本身很杂乱漏检就明显增加。变化检测是最需要小心的一类因为它对前后两期影像的配准精度、时相一致性、辐射一致性都极其敏感输入差一点输出可能就是一堆噪点。我的一般原则是把 AI 模型当成一个高质量的预标注工具而不是最终产品。用它跑出初稿再人工修正关键区域效率比纯人工高出一个量级精度又比纯模型靠谱。4.2 微调与样本量的关系如果你需要更高的精度就得自己标样本做微调。这里有个常见误解很多人以为样本越多越好于是花两周硬标了五千个点结果精度提升有限。实际上在小样本场景里样本的空间分布质量比数量重要得多。我的经验是标 200 到 400 个高质量样本点如果分布覆盖了研究区的所有地物类型和地形梯度效果往往好过 2000 个扎堆在平原区的样本点。原因很简单模型学到的是特征的边界如果你没给它看过山地阴影下的水体、城镇边缘的混合像元、休耕期的农田它就没有办法在这些区域做出正确判断。样本标注还有两个细节容易被忽略。一是纯像元原则标注点要落在类别内部的均质区域不要落在类别边界上。30 米分辨率下一个像素对应地表 900 平方米在城乡交错带几乎不存在纯像元这些地方标注本身就是错的标进去只会给模型添乱。二是类别平衡如果建设用地只占研究区的 5%而植被占 70%直接训练会导致模型倾向于把所有模棱两可的像元都判成植被。解决方法是欠采样大类或者给类别加权我通常用加权因为欠采样会丢掉大量信息。4.3 精度评价的正确姿势模型跑完出来一张花花绿绿的分类图这时候最容易犯的错误是直接看图觉得挺像的就交付了。分类精度必须量化而且要看的东西不止一个数字。最基础的是混淆矩阵从中能算出总体精度OA、Kappa 系数以及每一类的制图精度Producers Accuracy和用户精度Users Accuracy。这里有个概念必须分清制图精度说的是真实属于 A 类的像元里有多少被正确识别为 A用户精度说的是被识别为 A 的像元里有多少是真的 A。前者的误差是漏分后者的误差是错分。对做面积统计的人来说用户精度更关键因为你统计出来的 A 类面积里掺杂的错分部分会直接造成偏差。更进一步的一步是面积无偏估计。即使分类图精度是 90%直接数像素算出来的面积依然可能有系统性偏差尤其是小类别。做法是用分层随机抽样每一类按分类图中的比例分配样本量对样本做人工判读然后用矩阵反推真实面积比例。这套方法在小类别的面积估计上能把误差从百分之十几压到百分之五以内代价是要人工判读几百个点。如果你做的是要对外发布的变化数据这步不能省。验证样本的来源也有讲究。如果研究区有历史的高分辨率影像比如亚米级的商业影像存档用它做参考最理想没有的话用同期更高分辨率的免费影像辅助判读。要避免的是用同一套影像既训练又验证那样得到的精度是虚高的。5. 一条完整的实战链路城市扩张监测5.1 问题定义与指标光讲原理没意思我把一个完整的项目拆开走一遍。任务是这样某地级市 2013 到 2023 年的建成区扩张监测输出每年的建成区范围、面积统计、扩张方向以及新增建成区占用的原土地类型构成。指标要提前定死不然做到一半会不断改需求。我的指标体系是分类总体精度不低于 85%Kappa 不低于 0.8面积相对误差控制在 10% 以内逐年结果的空间配准误差不超过一个像元。这几个数字不是拍脑袋来的是参考同类研究的通行标准也是审稿人会盯的地方。还有一个容易被忽略的前置决策建成区的定义。是只算连续的人工不透水面还是包含城市内部的大片绿地和水体这个定义直接决定分类体系的类别划分也决定了后续的面积数字怎么解释。我采用的是连续不透水面为主、剔除面积大于一定阈值的水体、保留城市内部绿地的口径并在交付文档里写清楚避免用的人按自己的理解再解释一遍。5.2 云掩膜与年度合成数据源用 Landsat 8 和 9 的 Collection 2 Level 2时间窗口选每年 6 月到 9 月的生长季。为什么选生长季因为这时候植被茂盛植被和不透水面的光谱差异最大分类最容易分开如果混入冬季影像落叶林和建成区的光谱会接近误差上升。第一步是云掩膜用 QA_PIXEL 波段做位运算。CLOUD_BITS (1 1) | (1 2) | (1 3) | (1 4) | (1 5) def mask_qa(img): qa img.select(QA_PIXEL) mask qa.bitwiseAnd(CLOUD_BITS).eq(0) return img.updateMask(mask) def scale_sr(img): optical img.select(SR_B.*).multiply(0.0000275).add(-0.2) return img.addBands(optical, None, True)位运算这段值得解释。QA_PIXEL 是一个 16 位整数每一位代表一种状态位 1 是膨胀云位 2 是卷云位 3 是云位 4 是云阴影位 5 是雪。把这几位对应的数值按位或起来再检查结果是不是零是零就说明这些状态一个都没触发这个像素是干净的。用位运算而不是简单比较数值是因为一个像素可能同时是好几种状态的组合数值会变得很大直接比大小会漏掉情况。scale_sr里的两个系数是 Collection 2 Level 2 产品特有的。它的地表反射率存的是整数需要乘 0.0000275 再减 0.2 才能还原成真实反射率。这一步看着不起眼但不做的话所有指数的绝对值和阈值全部偏移我见过有人因为这个把 NDVI 的阈值定错了 0.15水体边界整整扩出去一圈。掩膜完成后做中值合成。这里有个顺序问题必须先掩膜再合成不能先合成再掩膜。原因很直观中值是对所有影像逐个像素取中位数如果云像素还在里面它就会参与中位数的计算在有多云影像的时候中值会被污染。先掩膜之后被遮掉的像素不参与合成中值才是干净的。5.3 分类后处理与面积统计合成的年度影像上算几个指数作为特征NDVI 区分植被NDBI归一化建筑指数用 SWIR1 和 NIR突出不透水面MNDWI改进的归一化水体指数用绿波段和 SWIR1提取水体。MNDWI 相比传统的 NDWI 的优势在于它用了 SWIR1 而不是 NIR在建成区背景下水体的对比度更强。传统 NDWI 在城市区域会因为建筑的高反射率出现大量误判MNDWI 把这个问题解决得比较彻底代价是它对 SWIR 波段的分辨率有依赖Sentinel-2 上 SWIR 是 20 米会拉低整体分辨率。分类可以用平台的监督分类能力也可以用随机森林。我这次用的是随机森林特征包括三个指数加上原始的多光谱波段样本 320 个训练集和验证集按 7:3 分。分类完之后做两步后处理一是众数滤波用一个 3×3 窗口把孤立的单像素噪声平滑掉二是最小图斑剔除把面积小于 3 个像素的图斑合并到周围面积最大的类别里。这两步能把视觉上的椒盐噪声清掉对面积统计的影响通常在 1% 以内但成图效果提升明显。面积统计是全流程里最容易出错的一步。必须先把分类结果重投影到等积投影再数像素。在经纬度坐标系下一个像素对应的实际面积随纬度变化同样是 30 米在赤道和高纬度的真实面积差很多。我的做法是用研究区中心纬线定制一个 Albers 等积投影在这个投影下每像素 900 平方米直接数像素乘以 900 就完事。5.4 出图与结果表达出图这一步看起来简单其实决定了成果能不能被看懂。我一般准备三张图一张是逐年建成区范围的制图用同一条色带从浅到深表示年份一张是新增建成区的空间分布用不同颜色标出各年份的新增部分第三张是扩张方向的雷达图或玫瑰图把新增面积按八个方位统计后画出来一眼就能看出城市往哪个方向长。配色上有个教训分类图不要用高饱和度的纯色。纯红纯绿纯蓝放在一起在不同显示器上观感差异很大打印出来更难看。用低饱和度的分类色板配合清晰的类别图例和比例尺专业感会好很多。另外栅格图导出的时候把dpi提到 300 以上做汇报和打印都够用。如果需要把结果做成在线可交互的形式可以在 Notebook 里直接叠加到地图控件上设置一个透明度滑杆让不同图层可以切换对比。这个功能在做汇报的时候特别好用比静态图有说服力得多。6. 六个真实踩坑现场与修复思路6.1 面积算出来差了 15%投影没换这个坑前面提过但它太常见了值得单独说一遍。我第一次做全市建成区面积统计用经纬度坐标直接数像素结果算出来的面积比统计年鉴的数字小了将近 15%。当时以为是分类精度问题回头查了半天才反应过来是投影的事。在纬度 30 度附近经纬度网格的面积变形大概是 10% 到 15% 的量级正好对上。修复很简单用reproject把结果转成等积投影再统计。但这里有个陷阱如果你导出的时候已经写死了 30 米的分辨率重投影之后分辨率会变成不均匀的统计就不准了。所以顺序应该是先重投影到等积投影再按等积投影下的固定分辨率导出和统计。6.2 云掩膜写在合成之后等于没做有一段时间我图省事把掩膜写在median()之后逻辑上好像也对——先把一年影像合成一张再对合成结果做云掩膜。结果在某些多云区域合成图上出现了大片异常亮的斑块分类的时候被误判成了裸地。原因就是前面说的中值合成之前云像素还参与计算。如果一年只有五景影像其中三景有云那么某一像素的中位数很可能就是一个云像素的值。修复的方法是把掩膜放在集合映射阶段让它在合成前就生效。这不是性能问题是正确性问题。6.3 跨传感器对比辐射定标与被遗忘的偏移量做 2013 到 2023 年的对比早年用的是 Landsat 8后来加了 Landsat 9。两者都是 Collection 2 Level 2理论上辐射是一致的但实际上如果对其中一个忘了做缩放系数转换NDVI 的整体偏移会很明显。我遇到过一年数据显示植被指数整体偏低 0.05 的情况排查很久才发现是那批影像在预处理的某个分支里跳过了缩放步骤。避免这类问题的办法是把预处理写成一个函数所有数据源都走同一个函数不要在流程里写分支。多花十分钟统一接口能省掉后面几天的排查时间。跨传感器对比时还可以用重叠期的影像做交叉标定比如 2021 年 Landsat 8 和 9 都有数据用同期的两套数据比较同一地物的反射率如果系统性偏差超过 2%就说明定标环节有问题。6.4 物候错配导致的假变化这是我见过的最隐蔽的一类错误。做变化检测时如果两期影像一个是 6 月一个是 10 月植被的物候差异会被模型识别成地物变化。一月份的农田是裸土反射率七月份是茂盛植被两者光谱差异极大变化检测会把它们判成从裸地变成植被。避免方法是尽量用相同时相窗口的影像比如都限定在 7 月到 8 月。如果实在做不到就在模型里加入物候校正或者改用基于时序曲线的方法而不是两期对比。我现在的习惯是在变化检测的结果图上叠加一个物候敏感性检查把研究区内的农田区域单独拿出来看如果农田区域变化特别剧烈八成是物候问题而不是真的变化。6.5 导出任务失败与分辨率陷阱导出失败的原因我遇到过三类。一是输出尺寸超限解决办法是分块导出二是任务名重复同一个description提交两次第二次会被拒解决办法是加版本号三是并发数超限一次提交太多任务被限流解决办法是写个简单的循环加延时。分辨率陷阱更隐蔽一些。有些平台在导出时会自动把分辨率对齐到数据源的网格如果你请求的是 25 米实际输出可能是 30 米统计的时候按 25 米算就会出现偏差。所以导出后一定要检查输出文件的元数据确认实际的分辨率、投影、范围都符合预期别假设它跟你请求的一致。6.6 样本画在混合像元上前面提过纯像元原则这里补充一个具体场景。在城乡交错带采样如果经验不足很容易把样本点落在看起来像建设用地其实一半是菜地的地方。这类样本进了训练集会显著拉低模型的边界判断能力表现是验证精度上不去但加样本也没用。我的做法是先在目标区域的 Google 级别高分底图上判断确认是均质区域再落点。另外采样之后做一次样本特征的可分性检查比如画各类样本在 NDVI-NDBI 平面上的散点如果某一类样本在特征空间里和其他类别严重重叠就说明采样有问题需要重新标。7. 免费额度与福利资源的正确用法7.1 新用户资源包里最值钱的是什么平台对新用户通常会提供一定的免费资源形式可能是算力时长、存储空间或者特定模型的调用额度。这些东西里最值钱的是算力时长因为存储和公开数据的访问基本不构成瓶颈。算力时长用完了要么等下一个周期要么就得走付费所以在试错阶段把算力省着用是很实际的考虑。我见过有人把免费额度拿去跑一个全国范围的初次实验一次跑掉大半后面调参的时候发现没额度了。这完全是策略问题跟技术无关。7.2 调试与生产的资源分配我的资源分配原则是粗调省、精跑贵具体来说就是把整个项目分成三个阶段。第一个是探索阶段用小范围、低分辨率比如 300 米、短时间窗口跑通整条链路确认代码逻辑没问题这个阶段消耗大概 5% 的额度。第二个是参数阶段在研究区内选两三个有代表性的小区域用中等分辨率跑十几种参数组合比较结果这个阶段消耗 20%。第三个是生产阶段全区域、原分辨率、分块跑最终结果这个阶段消耗剩下的 75%。按这个节奏即使免费额度不多也能完整跑完一个地级市级别的项目。反过来说如果一上来就在全区域跑全分辨率第一次跑错一个参数整批额度就没了。7.3 比赛、训练营与公开课程除了资源额度平台上经常会有一些公开的活动比如遥感相关的算法比赛、线上训练营、公开课程。这些东西的价值不止在于奖品更在于它们通常会提供额外的算力资源和高质量的标注样本。我参加过一次水体提取的比赛拿到的训练样本质量比我自己标的好很多而且赛题设定逼着你把流程做得规范赛后的代码可以直接复用。另外一个容易被忽略的资源是平台上其他用户公开的 Notebook。很多常见任务都能找到现成的实现你不需要从零开始写。我习惯的做法是找三四个类似的实现对比它们的处理顺序和参数设置看看差异在哪然后挑最合理的部分组合成自己的流程。这比闷头自己写快得多也能避免一些自己想不到的坑。一些实际操作后的体会用了几年下来我觉得这类地球科学云平台真正的价值不在AI这两个字上而在它把数据、算力和协作这三件事塞进了同一个环境里。AI 解译能力确实好用但它更像是一个能帮你省掉 70% 重复劳动的工具剩下的 30% 判断工作——定义分类体系、检查物候错配、验证精度、解释结果——依然得人来完成。如果让我给刚开始用的人一条建议那就是先别急着跑大区域。选一个你熟悉的地方比如你老家的一个县用一两个小时的影像跑一遍完整的流程从检索到出图到精度验证全部走通。你会在这条小链路上遇到几乎所有后面会遇到的坑但代价小得多。等这条链路跑顺了再放大到流域或者省域只是参数和分块策略的调整而已。还有一个私心建议把每次跑的 Notebook 都存一份带日期的备份。我吃过一次亏半年前的一个项目需要重新出一版图结果当时的代码在编辑过程中被改乱了花了两天才复原。现在我每个项目目录下都有v1、v2、v3这样的版本快照多占一点存储空间换来的是随时能回到任意一个历史状态。