用途
本技能面向大规模地理空间数据的处理、优化与可视化，定位为地理空间数据管道方面的专家能力。适用于需要处理空间数据、进行空间查询或生成地图瓦片的工程场景。
主要能力
技能覆盖以下方向：
- 无人机影像处理与标注
- GPS 轨迹分析与可视化
- 基于位置的搜索（查找附近的 X）
- 面向 Web/移动端的地图瓦片生成
- 坐标系转换
- 地理围栏与空间查询
- 面向 Web 的 GeoJSON 优化
技能同时明确列出不适用场景：简单地址校验（应使用地址 API）、基础距离计算（应使用 Haversine 公式）、静态地图嵌入（应使用 Mapbox Static API）、地理编码（应使用 Nominatim 或 Google Geocoding API）。
技术选型
技能给出 PostGIS 与 MongoDB Geospatial 的对比：
- 空间索引：PostGIS 使用 GiST、SP-GiST；MongoDB 使用 2dsphere
- 查询语言：PostGIS 为 SQL + 空间函数；MongoDB 为聚合管道
- 几何类型：PostGIS 支持 20+（完整 OGC 支持）；MongoDB 为基础类型（Point、Line、Polygon）
- 坐标系：PostGIS 通过 EPSG 支持 6000+；MongoDB 仅 WGS84
- 性能（1000 万点）：PostGIS <100ms；MongoDB <200ms
- 最佳适用：PostGIS 适合复杂空间分析；MongoDB 适合以文档为中心的应用
时间线：2005 年 PostGIS 1.0 发布；2012 年 MongoDB 加入地理空间索引；2020 年 PostGIS 3.0 提升性能；2024 年 PostGIS 仍是 GIS 工作负载的黄金标准。
常见反模式
技能以反模式形式讲解关键实践：
- 将坐标存为字符串：无法使用空间索引、查询慢、无校验。正确做法是使用 PostGIS GEOGRAPHY 类型并建立 GiST 空间索引，配合 ST_DWithin 与距离排序。
- 不使用空间索引：邻近查询会全表扫描。建立 GiST 索引后，1000 万点、5km 半径查询从 3.2 秒降至 12ms。
- 混用坐标系：混用 EPSG:4326（WGS84）与 EPSG:3857（Web Mercator）会导致距离错误、地图要素错位。应统一存储、仅在显示时转换。
- 加载超大 GeoJSON 文件：50MB 文件会导致浏览器卡死。可选方案包括矢量瓦片（MBTiles 或 PMTiles）、GeoJSON 简化与分块、服务端按可见范围过滤。
- 在球面上使用欧氏距离：平地距离计算在尺度较大时错误，靠近两极更严重。应使用 Haversine 公式或 PostGIS 的 GEOGRAPHY 类型。技能给出旧金山到纽约的对比：欧氏（平地）约 55km（错误 98.7%）、Haversine（球面）约 4130km、PostGIS（椭球）约 4135km（最准确）。
使用方式
技能提供生产环境检查清单，包括：安装 PostGIS 扩展并创建空间索引；所有坐标使用一致的 SRID（推荐 4326）；GeoJSON 文件优化至小于 1MB 或改用矢量瓦片；坐标转换使用 ST_Transform 而非手工计算；距离计算使用 ST_Distance 配合 GEOGRAPHY 类型；边界框查询使用 ST_MakeEnvelope + ST_Intersects；大几何体分块（单要素不超过 100KB）；为常用缩放级别预生成地图瓦片；为瓦片服务器配置 CORS；对地理编码/反向地理编码端点做限流。
技能还包含参考文档与脚本：
- /references/coordinate-systems.md：EPSG 代码、坐标转换、Web Mercator 与 WGS84 对比
- /references/postgis-guide.md：PostGIS 安装、空间索引、常用查询
- /references/geojson-optimization.md：简化、分块、矢量瓦片
- scripts/geospatial_processor.ts：处理无人机影像、GPS 轨迹、GeoJSON 校验
- scripts/tile_generator.ts：从 GeoJSON 生成矢量瓦片（MBTiles/PMTiles）
适用场景
适合：无人机影像标注与搜索、GPS 轨迹可视化、查找最近的咖啡店、管辖边界查询（点在多边形内判断）。
不适合：简单地址自动补全（使用 Mapbox/Google）、页面嵌入静态地图（使用 Static API）、单个地址地理编码（使用地理编码 API）。
限制
技能未提供具体的收费、价格、平台支持范围或效果承诺等信息，这些内容暂未提供。