做能源选址、电网规划或者环境评估这行的朋友，应该都遇到过这种场景：手头有一份某个区域的发电站列表，领导或者同事突然问你——"离某某位置最近的电站是哪座？装机容量多大？烧的是什么燃料？"以前我的常规操作是打开本地GIS软件，导CSV、建图层、跑空间连接、再手动算距离，一套流程下来怎么也得十几二十分钟；如果数据在别人手里，还得先要文件、对字段，烦得很。

后来我搭了一个Google Earth Engine（GEE）的小应用：打开页面就是一张交互地图，点地图上任意一个位置，左侧面板自动显示离这个点最近的一座发电站，名称、装机容量、燃料类型、距离这些信息直接列出来，地图上还把最近电站和连线高亮画出来。整个过程从"点一下"到"看到结果"大概两秒钟。这个应用本质上就是一个"点选位置 → 最近点距离计算 → 信息回显"的模板，换成学校、医院、基站、充电桩任何点状数据都能复用。

这篇文章就是把这个小APP从需求拆解、数据准备、距离计算到面板搭建的全过程记录下来，包含完整可抄的代码框架和各种我踩过的坑。适合用GEE做地理分析、想快速搭建内部可视化工具，或者对WebGIS开发感兴趣的开发者参考。

1. 这个APP到底解决什么问题：从需求倒推设计

1.1 一句话需求背后的三个关键词

标题里的"最近点距离点"是理解整个项目的钥匙。拆开来看就是三个要素：一个候选点集合（发电站）、一个目标点（你点击的位置）、一套距离计算规则（最近邻）。整个APP要干的活就是：目标点确定后，在候选点集合中找出距离最小的那个，并展示它身上的属性信息。

这个需求看起来简单，但在传统GIS工具里做一次并不轻松。首先是数据获取，发电站数据集往往是几十MB的CSV或者Shapefile，得下载、导入、检查投影；然后是距离计算，要新建字段、写表达式、跑一次空间连接，整个过程还必须守着桌面软件操作；最后是展示，做完的分析结果想给别人看，要么截图，要么打包工程文件，没法形成一个"打开就能用"的共享工具。

GEE天然解决了这几个痛点。数据在云端，不用下载；空间算子直接在服务器上批量跑，几万个点的距离矩阵就是一条语句的事；UI组件和地图组件可以直接组装成网页应用，发布之后给个链接别人就能用，不需要对方装任何GIS软件。这也是我在这类"小工具"场景里首选GEE而不是本地方案的原因。

1.2 为什么是GEE而不是传统GIS或者纯前端

可能有人会问：用Leaflet或者OpenLayers调一个后端接口，前端画个Marker，不是也能实现吗？能实现，但工程量大得多。你要准备后端服务、地理数据库、距离计算接口、前端部署，还要考虑并发和数据更新。而GEE把这几层全部打包了：数据存储在你自己的asset里或者公开数据集中，空间计算引擎在云端，前端UI有现成的组件，最后还能一键发布成App。对于内部工具或者原型验证，这几乎是成本最低的路径。

当然GEE也有它的短板：不适合做高并发的大众产品，UI的灵活度不如纯前端框架高。但"最近点距离点"这种低频交互、数据量中等、结果要清晰展示的场景，恰好是它的舒适区。

1.3 整体架构：视图、逻辑、数据三层分离

我习惯把这类小应用分成三层来设计，后面写代码时思路会特别清爽：

• 视图层：地图组件、左侧面板、按钮、下拉框，负责用户交互和结果展示。
• 逻辑层：点击事件触发后的距离计算、最近点筛选、结果格式化，全部跑在GEE的Server端。
• 数据层：发电站矢量数据集，可以来自GEE公开数据集，也可以上传自己的CSV/Shapefile。

这样的分层还有一个好处：换数据源时，只需要改数据层和字段映射，视图和逻辑基本不动。后面我在第4章给的代码骨架也是按这个顺序组织的。

2. 数据准备与"最近点距离"核心算法

2.1 发电站数据从哪来：选数据集先说需求

GEE里能直接用的全球发电站数据，最典型的是全球发电厂数据库（GPPD）的社区公开版本。这份数据覆盖全球几十个国家的发电设施，每条记录带经纬度、装机容量、主要燃料类型、所属国家等字段。字段关键但不多，做信息回显刚好够用。

如果你要分析的区域没有现成公开数据，完全可以把自己的CSV传上去——GEE资产面板里直接上传，列名自己能控制。我个人建议CSV里至少要有x、y（或者lng、lat）、name、value这几个字段，再有一两个分类字段，比如燃料类型或者状态。字段越干净，后面代码越好写，别贪多。

加载公开数据集的代码很简单：

var powerPlants = ee.FeatureCollection('projects/sat-io/open-datasets/power_plant_database');

注意：这个asset id是社区维护版本，如果你加载失败，去GEE数据目录里搜"power plant"选一个能用的就行，但字段名要自己确认一遍。数据加载后先print(powerPlants.first())看一下字段，确认名称、容量、燃料类型对应的属性名，后面所有代码都依赖这一步。

2.2 最近点距离计算的两种方案及其原理

我要重点讲这个部分，因为"最近点距离点"是整个APP的灵魂。GEE里实现点对点最近邻有两种思路，我都实际用过。

方案一：遍历候选点逐个算距离，排序取最小

思路是把发电站集合里的每个点，都用distance()方法算到目标点的距离，然后作为新属性存起来，最后按距离排序取第一个。代码长这样：

var targetPoint = ee.Geometry.Point([lng, lat]); var withDist = powerPlants.map(function(f) { var d = f.geometry().distance(targetPoint, 10); // 第二个参数是最大误差容限 return f.set('distance', d); }); var nearest = withDist.sort('distance').first();

这段代码的逻辑非常直白：map遍历所有电站，每个电站都算一次到目标点的距离，距离字段写进Feature，然后排序取第一条。适合候选点数量在几千到几万这个量级，计算时间可以接受，而且结果可控、方便排查。

方案二：全量最近邻算子 reduceNearest

如果候选点量很大，比如几十万甚至上百万个点，逐个map遍历的耗时会直线上升。这时候可以用reduceNearest—— 它是GEE里专门做"集合到集合最近邻归约"的算子。语法上可以这么理解：目标点集合调用该算子，传入候选点集合，它会自动为每个目标点找到距离最近的候选点，并且把距离写入结果：

var nearestFC = powerPlants.reduceNearest({ collection: ee.FeatureCollection([targetPoint]), key: 'distance', maxDistance: 500000 }); var nearest = nearestFC.first();

maxDistance是搜索的半径上限，单位是米。这个参数要设好：太小找不到点，太大计算量上升。我一般给50公里，如果目标区域偏才调大。reduceNearest的底层是空间索引的最近邻搜索，不会真的把所有候选点都遍历一遍，所以性能远优于方案一。

两种方案怎么选？我的经验是：数据量小于5万、只是想快速验证逻辑，用方案一，代码可读性强；数据量上来、或者以后打算频繁换目标点计算，用方案二。本文后面示例代码用方案一为主，更容易看懂和调试，如果数据量大再换二。

2.3 坐标系、单位与距离精度：三个坑必须提前说

距离计算看着简单，但GEE里这三个细节不注意，结果会天差地别。

坑一：经纬度坐标系下算的是"大圆距离概念上的近似"。GEE的distance()方法返回的是以米为单位的测地线距离，内部会自动处理地球曲率，所以你不需要手动做投影转换。但要注意它输出的精度受第二个参数maxError影响。这个参数表示允许的最大计算误差，你给的越严格，内部计算越精细，耗时越高。默认值有时候会比较粗，我建议显式给个10（米），性能影响不大，精度够用。

坑二：point不要真当"点"用。如果你直接拿CSV上传的经纬度构造ee.FeatureCollection再取.geometry()，有时候会发现.distance()的结果不是期望的数值。这通常是因为数据里有些记录的坐标格式不对，或者字段名没对上，geometry实际是空的。我在第5章会专门说怎么排查。

坑三：筛选要先做。如果数据库覆盖全球，而你实际关心的是目标点周边几百公里，先用filterBounds把集合切到目标点附近，再跑距离计算，速度会快一个数量级。这个优化放在任何算法前面：

var nearby = powerPlants.filterBounds(targetPoint.buffer(200000));

先buffer一个半径圈出候选区，再对这一个小集合算距离，逻辑和性能都会好很多。这个方法强烈推荐。

3. 面板搭建与交互逻辑：从地图点击到信息回显

3.1 界面布局：左侧控制面板 + 右侧地图

GEE的UI组件用起来很像搭积木。我用的布局很简单：根容器是ui.Splitter，左边放一个竖着的ui.Panel做控制面板，右边是一个ui.Map。控制面板从上到下依次是：一段介绍文字、一个下拉框选择燃料类型、一个显示结果的面板（初始是隐藏的）、一个清空按钮。

面板的样式直接用style参数控制，宽度、边距、字体大小都写在对象里：

var panel = ui.Panel({ layout: ui.Panel.Layout.flow('vertical'), style: { width: '320px', padding: '8px' } });

这里有个容易忽略的细节：ui.Panel.Layout.flow('vertical')指定了子组件垂直排列，如果不写，默认的布局方式可能会让组件横向挤在同一个面板里。我第一次做的时候就因为漏了这句，下拉框和按钮全并排了，调试了半天才发现是布局没设置。

地图实例直接用ui.Map创建，设置中心点和缩放级别：

var map = ui.Map(); map.setCenter(116.0, 35.0, 6); // 先定位到大致区域，用户自己拖动

3.2 点击地图、计算距离、提取最近电站的完整链路

核心交互是用户点击地图任意位置，我在地图上加一个图层标记点击点，同时触发一次服务端计算。

GEE绑定点击事件用的是onClick回调：

map.onClick(function(coords) { // coords.lon / coords.lat 就是点击的经纬度，单位是十进制度 var pt = ee.Geometry.Point([coords.lon, coords.lat]); runNearest(pt); });

这里有一个新手常见误区：coords虽然是个对象，但它是客户端对象，不是ee.*类型。如果你想把它传给服务端函数用，需要先手动包成ee.Geometry.Point，我上面的代码就是这么做的。如果不加这一步，后面所有计算都会报"cannot use a computed geometry in this context"之类的错。

runNearest是真正干活的函数。它的职责是：接收点、计算最近电站、把结果写到面板里的Label上，同时更新地图图层。核心逻辑我直接给出：

function runNearest(targetPoint) { var searchRadius = 200000; // 200km var candidates = powerPlants .filterBounds(targetPoint.buffer(searchRadius)); var withDist = candidates.map(function(f) { var d = f.geometry().distance(targetPoint, 10); return f.set('distance', d); }); // 按距离排序取最小 var nearest = withDist.sort('distance').first(); nearest.evaluate(function(val) { if (!val) { showResult(null); return; } var props = val.properties; showResult({ name: props.name || '未知电站', fuel: props.primary_fuel || '未知燃料', capacity: props.capacity_mw || '未知装机', distanceKm: (props.distance / 1000).toFixed(1) }); }); }

这里用到了evaluate—— GEE的客户端回调机制。服务端算出来的结果不能直接当普通JavaScript对象用，必须通过evaluate把值取回浏览器端。这是搭建UI面板时绕不过去的一个环节。实际项目里我会把这段封装得再粗糙一点也没关系，关键是理解这个异步回调模型。

3.3 信息展示与图层可视化

结果面板是几个ui.Label，我预先在页面上占好位，计算完成后更新其value：

var nameLabel = ui.Label('', { fontWeight: 'bold' }); var fuelLabel = ui.Label('', {}); var capacityLabel = ui.Label('', {}); var distanceLabel = ui.Label('', { color: '#666666' }); function showResult(info) { if (!info) { nameLabel.setValue('未找到电站'); fuelLabel.setValue('试试扩大搜索范围'); capacityLabel.setValue(''); distanceLabel.setValue(''); return; } nameLabel.setValue(info.name); fuelLabel.setValue('燃料类型：' + info.fuel); capacityLabel.setValue('装机容量：' + info.capacity + ' MW'); distanceLabel.setValue('距离：' + info.distanceKm + ' km'); }

地图图层这块，我会维护几个图层变量：一个是全部电站灰点图层，一个是点击位置标记图层，一个是最近电站高亮图层，再加一条从点击点到最近电站的连线。图层的添加方式是用map.addLayer(eeObject, visParams, name)，图层之后可以靠map.layers()拿到再设置透明度。

连线的实现是构造一条线串几何：

var line = ee.Geometry.LineString([ [clickLon, clickLat], [nearestLon, nearestLat] ]);

线宽调成3像素、黄色，视觉上非常直观。用户一眼就能看出"我点的在这，最近电站在那，距离多远"。这个细节虽然小，但是整个工具给外行演示时效果会好非常多。

4. 完整代码骨架与关键细节：可以直接抄的版本

4.1 代码结构总览

整个APP我习惯拆成五个部分：引入数据、初始化地图面板、定义计算函数、定义展示函数、绑定交互事件。下面这个骨架是去掉异常处理的最小可用版本，你可以直接跑通再往里面加功能：

// 1. 数据层 var powerPlants = ee.FeatureCollection('projects/sat-io/open-datasets/power_plant_database'); // 2. 视图层 var map = ui.Map(); map.setCenter(116.0, 35.0, 6); var panel = ui.Panel({ layout: ui.Panel.Layout.flow('vertical'), style: { width: '360px', padding: '10px' } }); var titleLabel = ui.Label('发电站最近点查询工具', { fontSize: '16px', fontWeight: 'bold' }); var fuelSelect = ui.Select({ items: ['全部', 'Coal', 'Gas', 'Hydro', 'Wind', 'Solar'], value: '全部' }); var resultWrap = ui.Panel({ layout: ui.Panel.Layout.flow('vertical'), style: { marginTop: '8px' } }); var nameLabel = ui.Label('', { fontWeight: 'bold', fontSize: '14px' }); var fuelLabel = ui.Label('', {}); var capacityLabel = ui.Label('', {}); var distanceLabel = ui.Label('', { color: '#666666' }); var clearBtn = ui.Button('清空结果'); resultWrap.add(nameLabel); resultWrap.add(fuelLabel); resultWrap.add(capacityLabel); resultWrap.add(distanceLabel); panel.add(titleLabel); panel.add(fuelSelect); panel.add(resultWrap); panel.add(clearBtn); var splitter = ui.Splitter(panel, map); ui.root.add(splitter); // 3. 逻辑层 function runNearest(targetPoint) { var radius = 200000; var filtered = powerPlants.filterBounds(targetPoint.buffer(radius)); // 如果下拉框指定了燃料类型，再加一层过滤 var selected = fuelSelect.getValue(); if (selected !== '全部') { filtered = filtered.filter(ee.Filter.eq('primary_fuel', selected)); } var withDist = filtered.map(function(f) { var d = f.geometry().distance(targetPoint, 10); return f.set('distance', d); }); var nearest = withDist.sort('distance').first(); nearest.evaluate(function(val) { if (!val) { nameLabel.setValue('该范围内未找到电站'); fuelLabel.setValue(''); capacityLabel.setValue(''); distanceLabel.setValue(''); return; } var p = val.properties; nameLabel.setValue(p.name || '未知电站'); fuelLabel.setValue('燃料类型：' + (p.primary_fuel || '未知')); capacityLabel.setValue('装机容量：' + (p.capacity_mw || '未知') + ' MW'); distanceLabel.setValue('距离：' + (p.distance / 1000).toFixed(1) + ' km'); // 高亮最近电站 var nearestPt = ee.Geometry.Point([p.longitude, p.latitude]); map.layers().set(1, ui.Map.Layer(nearestPt, { color: 'red', pointRadius: 6 }, '最近电站')); // 画连线 var clickPt = val.geometry ? ee.Geometry(val.geometry) : targetPoint; var line = ee.Geometry.LineString([[targetPoint.coordinates().get(0), targetPoint.coordinates().get(1)], [p.longitude, p.latitude]]); map.layers().set(2, ui.Map.Layer(line, { color: 'yellow' }, '距离线')); }); } // 4. 交互层 map.onClick(function(coords) { var pt = ee.Geometry.Point([coords.lon, coords.lat]); map.layers().set(0, ui.Map.Layer(pt, { color: 'cyan', pointRadius: 5 }, '点击位置')); runNearest(pt); }); clearBtn.onClick(function() { nameLabel.setValue(''); fuelLabel.setValue(''); capacityLabel.setValue(''); distanceLabel.setValue(''); });

这段代码直接粘贴到GEE代码编辑器的"Apps"模式里是可以跑的。跑通之后你会发现一个最关键的经验：先用最简单的数据把链路打通，再加UI细节。我一开始就是把精力花在界面上，结果点击事件和数据计算各种报错，界面的问题跟计算的问题混在一起，排查了很久。后来先去掉所有UI，用print()验证runNearest输出正确，再一步步加回面板和图层，整个开发过程顺畅多了。

4.2 图层管理的两个实用技巧

图层管理是这个APP里最容易被忽略的部分。很多人一开始直接map.addLayer(...)成功一次就不管了，第二次点击地图时，上一个点击位置和上一个最近电站还留在图上，新结果和旧结果叠在一起，界面非常乱。

解决思路是：不要无限增加图层，而是固定图层槽位。用map.layers().set(index, layer)的方式覆盖指定位置的图层。上面代码里的0号槽位放点击位置、1号槽位放最近电站、2号槽位放距离线，每次点击事件都覆盖对应槽位。这样地图始终只有三四个图层，不会越积越多。

另一个小技巧是给每个图层设置合理的名称和透明度。特别是全量电站点如果一次全画出来，在区域数据密集的时候会盖住其他重要元素。我用灰色小点、transparency 0.6 显示全量电站，用高亮的红点显示最近电站，层次感一下就出来了。

4.3 数据量过大时的两个优化：先过滤再计算、必要时换reduceNearest

如果全量发电站数据有几十万点，直接在代码里powerPlants.map(...)跑一遍距离计算，哪怕GEE的服务器性能很强，一次响应也可能要好几秒。这个延迟在交互式工具里是难以接受的。我自己实测的经验是两条：

第一，先过滤再计算永远是第一优先级。filterBounds能把候选点集缩小到目标点周边Buffer区域内，这直接把参与计算的点数减少几个数量级。我在上面的实现里就是先targetPoint.buffer(radius)再做filterBounds，效果明显。

第二，如果区域内的候选点还是有几十万个，果断换reduceNearest。它走空间索引搜索，不用对每个点都算距离。使用方式和方案一几乎同样简单：

var nearestFC = tinyTargetFC.reduceNearest({ collection: powerPlants, key: 'distance', maxDistance: 200000 });

两者唯一的差异是reduceNearest返回的是一个FeatureCollection，你取.first()后属性的名称是distance，语义一致。如果你的参考点不止一个，比如想同时看三个选址点的最近电站，reduceNearest的优势会体现得更明显——直接传一个多点集合进去，批量返回结果，不用写循环。这是方案一做不到的，也是我后来更推荐它的原因。

5. 常见问题与排查实录

5.1 距离算出来全是0或者Null

这个现象十有八九是几何类型或者坐标字段的问题。我先讲一个具体案例：有人把CSV传上去，字段名是"lon""lat"，但在构造FeatureCollection时忘记指定x和y参数，GEE默认找"longitude""latitude"，结果每个点的几何都是无效的。距离计算遇到无效几何自然返回Null或者0。

排查方法很简单，在代码里加一行print(powerPlants.first().geometry())，看返回的是不是带坐标的Point。如果确认坐标没问题，再看distance(targetPoint, 10)的第二个参数——maxError如果给成0，在部分几何类型组合下会触发"Too many dimensions"这类奇怪的报错。我给10不会带来肉眼可见的误差。

5.2 点击地图没有反应或者coords是undefined

map.onClick回调一定是带一个坐标参数的，但是如果你绑定的函数里先用了某些UI组件的值（比如下拉框），而这个值还没初始化，就有可能在回调内部抛异常，样子就像"点击没反应"。这时候按F12打开浏览器控制台，看console有没有红色报错，基本都能定位到。

另一个更隐蔽的问题：onClick的回调是在客户端执行的，如果你在里面直接用了ee.FeatureCollection(...).sort(...)但没有.evaluate()或.getInfo()，结果永远不会真正取回浏览器端，UI也永远不会更新。我见过不少人卡在这一步——服务端计算逻辑完全正确，但UI不刷新，最后发现是缺少evaluate回调把值传回客户端。记住这条铁律：凡是Server端的结果要更新UI，都必须走evaluate。上面代码里的nearest.evaluate(function(val){...})就是这个作用。

5.3 面板样式错乱或者组件挤在一起

GEE的UI组件大部分问题都出在layout和style上。如果组件没有按预期方向排列，检查两件事：ui.Panel.Layout.flow('vertical')有没有写、父容器的style.width有没有足够宽。还有一个坑：ui.Label里的内容太长了不会自动换行，会撑破面板宽度。所以我习惯把长的字段值用substring包裹一下，或者直接用ui.Label的多行样式whiteSpace: 'pre-wrap'。

5.4 发布成APP后别人无法访问数据

GEE的APP默认情况下，数据集必须对运行该APP的用户可见。如果你用的是公开数据集，一般没有问题；如果用了自己上传的私有资产，需要去Asset页面把共享权限改成"Anyone can view"或者给特定的群组授权。这个授权是在资产盾牌图标里设置的，不是在APP页面里。另外发布APP时选择"Public"链接，别人才能用浏览器打开。很多人卡在这里——自己打开是好的，别人打开全是空白或者报错，一查几乎都是资产共享没开。

5.5 常见问题速查表

6. 发布成APP和后续扩展方向

6.1 把代码编辑器里的脚本变成真App

GEE的App发布入口在代码编辑器右上角的"Apps"按钮。选好名称后会生成一个链接，打开就是纯地图模式，不显示代码编辑器。发布之前建议做三件小事：把地图初始中心点调整到你的业务区域、把面板里的测试字段清干净、确认所有用到的图层在加载时都有一个合理的名称。App发布后，还可以嵌入到自己的网页里做内嵌分析工具，GEE提供了对应的JavaScript库，不过那是另一个话题了。

这里分享一个体验细节：发布后的App加载是全量加载页面，如果你的代码在初始化阶段做了大数据量计算（比如一开始就把全量电站全部画上地图），首屏会明显卡顿几秒。解决方法是把全量图层的shown参数设成false或者干脆等用户第一次点击后再加载。首屏快，用户第一印象就好。

6.2 几个很自然的扩展方向

这个模板改一改就能干很多事。比如：

• 新能源选址辅助：加一层风速、光照或者土地利用图层，用户点一个位置，不仅显示最近发电站，还同时显示周边适宜建新场站的比例信息。
• 设施覆盖评估：把发电站换成消防站、医院或者充电桩，一样的代码逻辑，输出最近站点名称和距离，覆盖了"一键查最近设施"的场景。
• 批量选址对比：用reduceNearest批量传入多个目标点，一次性输出每个点对应的最近电站清单，可以直接拿去生成报告。
• 时间维度扩展：如果数据集带建设日期字段，可以按年份过滤，观察不同时期最近电站的变化，这在追溯历史场景里非常有用。

6.3 最后的两个小提醒

回头整理这个项目的代码时，我最想分享的两个小提醒：第一，写GEE的UI应用，一定要分阶段开发，先打通数据链路再搞界面，否则调试成本成倍增长；第二，凡是涉及距离的展示，一定要在代码里标注单位，面板上显示"22.3 km"而不是"22.3"，看的人不会误解，你隔两个星期回来看代码也不会懵。

这个工具本身不大，骨架上也没多少行代码，但它的使用场景比想象中广。说实话，我在实际项目里用得最多的反而是那个清空按钮和下拉框的燃料筛选，领导到现场要看哪个片区的情况，点几下就出结果，比打开ArcGIS再拖图层解释半天要高效太多。技术难吗？不难。但它确实把一个平时要十分钟才能完成的活缩短到了十秒，这就是地理工具面向业务落地时真正的价值。