本文介绍如何基于 leaflet routing machine 生成的路线坐标，筛选并展示指定半径（如5km）内数据库中存储的兴趣点（poi），避免逐公里轮询，推荐采用空间查询与缓冲区预计算结合的优化方案。
本文介绍如何基于 leaflet routing machine 生成的路线坐标，筛选并展示指定半径（如5km）内数据库中存储的兴趣点（poi），避免逐公里轮询，推荐采用空间查询与缓冲区预计算结合的优化方案。
在使用 Leaflet Routing Machine 构建导航路线时，route.coordinates 属性确实返回了整条路径的高精度经纬度点数组（例如 [ [lat1, lng1], [lat2, lng2], ... ]）。但需明确：不应也不必“每公里调用一次数据库”——这种轮询方式效率极低、易超时，且违背地理空间查询最佳实践。
✅ 正确做法是：以整条路线为几何对象，构建地理围栏（buffer），再通过空间数据库一次性完成 POI 筛选。以下是关键步骤：
1. 获取完整路线坐标并构造 LineString
// 假设已获取路由实例
const route = routingControl.getPlan().getWaypoints(); // 或直接监听 'routefound' 事件
const coordinates = route.coordinates; // 注意：Leaflet Routing Machine v3+ 中为 route.coordinates
// 转换为 GeoJSON LineString（供后端或 Turf.js 使用）
const lineString = {
type: 'LineString',
coordinates: coordinates.map(([lat, lng]) => [lng, lat]) // GeoJSON 要求 [lon, lat]
};2. 后端：使用空间数据库执行缓冲区查询（推荐 PostGIS）
-- 查询距离路线5km内的所有POI（假设 poi_table 含 geom 列，SRID=4326）
SELECT id, name, ST_AsGeoJSON(geom) AS geometry
FROM poi_table
WHERE ST_DWithin(
geom,
ST_Transform(ST_Buffer(
ST_Transform(ST_GeomFromGeoJSON('{"type":"LineString","coordinates":[[...]]}'), 4326),
5000 -- 缓冲距离：5000 米
), 4326),
0
);⚠️ 注意：
ST_DWithin需确保geom和缓冲区使用相同投影（推荐先转为 Web Mercator (EPSG:3857) 计算米级缓冲，再转回 WGS84 比较）。
3. 前端轻量替代方案（小数据量适用）
若无法使用空间数据库，可用 Turf.js 在浏览器端近似处理：
npm install @turf/turf
import * as turf from '@turf/turf';
const line = turf.lineString(coordinates.map(([lat, lng]) => [lng, lat]));
const buffer = turf.buffer(line, 5, { units: 'kilometers' }); // 生成5km缓冲多边形
// 将所有POI转为Point Feature，用 turf.booleanPointInPolygon 批量判断
const pois = /* 从API获取的POI数组 */;
const nearbyPois = pois.filter(poi =>
turf.booleanPointInPolygon([poi.lng, poi.lat], buffer)
);关键注意事项
- ❌ 避免循环调用 API：逐公里请求不仅增加服务器压力，还因坐标非等距分布导致覆盖不均；
- ✅ 优先服务端空间查询：PostGIS / MySQL 8.0+ / Spatialite 均支持
ST_DWithin，性能远超前端计算； - ? 坐标系一致性：WGS84（EPSG:4326）下
ST_Buffer(5000)并非精确5km（因经纬度单位非米），务必用ST_Transform(..., 3857)进行投影转换； - ? 性能优化：为
geom字段建立 GiST 索引（PostGIS）或空间索引（MySQL），可使查询从秒级降至毫秒级。
综上，核心逻辑是 “以线构面，以面查点” —— 利用路线本身生成地理缓冲区，再通过空间关系一次性精准召回目标 POI，兼顾准确性、性能与可维护性。
