地理围栏功能怎么做?ES查询语句咋写?

你写的地理围栏总漏人？可能是坐标系和ES语法在“背刺”你

上周一位做共享单车调度的朋友找我救火：“Dr. Gis，我们用ES做电子围栏，明明用户在禁停区里，系统却说他在外面！”——这几乎是所有初学者踩的第一个坑。别慌，今天我就带你从原理到实战，手把手拆解地理围栏的底层逻辑和ES查询语句的正确写法。

地理围栏不是画个圈那么简单：坐标系才是真正的“隐形裁判”

很多人以为地理围栏就是“在地图上画个多边形，然后判断点是否在内部”。听起来像切西瓜一样简单？错！现实是，你画的“圈”和用户的“点”，很可能根本不在同一个“宇宙”里——因为坐标系不同。

我在参与某一线城市共享单车监管平台项目时，就吃过这个亏。前端用百度地图画围栏（BD-09），后端直接拿GPS坐标（WGS-84）去匹配，结果系统天天误报“用户违规停车”，差点被甲方骂到自闭。后来统一转成GCJ-02才解决。

类比一下：想象你要把一张A4纸（WGS-84坐标）上的图案，精确剪下来贴到一张微微拉伸过的B5纸上（GCJ-02坐标）。哪怕图案轮廓一模一样，位置也会错位。地理围栏同理——必须确保围栏边界和用户坐标使用同一套坐标系，否则再精准的算法都是空中楼阁。

实战第一步：在Elasticsearch中定义你的“电子围栏”

假设我们要在ES里创建一个“校园禁飞区”的围栏。首先得建索引，并指定字段为geo_shape类型：

PUT /campus_no_fly_zone
{
  "mappings": {
    "properties": {
      "name": { "type": "keyword" },
      "boundary": { "type": "geo_shape" }
    }
  }
}

接着，插入一个多边形围栏数据（注意坐标顺序是[经度, 纬度]）：

POST /campus_no_fly_zone/_doc/1
{
  "name": "教学楼核心区",
  "boundary": {
    "type": "polygon",
    "coordinates": [
      [
        [116.330, 39.990],
        [116.330, 39.995],
        [116.335, 39.995],
        [116.335, 39.990],
        [116.330, 39.990]
      ]
    ]
  }
}

核心操作：用ES查询语句判断“点是否在围栏内”

现在用户无人机上报了一个坐标[116.332, 39.992]，如何判断它是否闯入禁飞区？关键在于geo_shape查询的relation参数：

GET /campus_no_fly_zone/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "geo_shape": {
            "boundary": {
              "shape": {
                "type": "point",
                "coordinates": [116.332, 39.992]
              },
              "relation": "within"
            }
          }
        }
      ]
    }
  }
}

这里relation: "within"表示“点完全包含在多边形内”。其他常用选项：

• intersects：点与多边形有交集（哪怕擦边也算）
• disjoint：点在多边形外

⚠️ 注意：ES默认使用WGS-84坐标系（EPSG:4326）。如果你的数据是其他坐标系（如Web墨卡托），必须先转换！

避坑指南：三个高频报错和我的解决方案

进阶技巧：用GeoJSON批量导入复杂围栏

实际项目中围栏往往很复杂（比如整个行政区划）。手动写coordinates太痛苦？用GeoJSON！先准备好标准GeoJSON文件（可用QGIS导出），再用_bulk API批量插入：

POST /district_boundaries/_bulk
{ "index": { "_id": "1" } }
{ "name": "朝阳区", "boundary": { "type": "Polygon", "coordinates": [...] } }
{ "index": { "_id": "2" } }
{ "name": "海淀区", "boundary": { "type": "Polygon", "coordinates": [...] } }

这样效率提升10倍不止，亲测在百万级围栏数据下依然流畅。

总结：地理围栏=坐标系+空间查询+工程化思维

今天我们拆解了地理围栏的核心三步：① 统一坐标系避免“关公战秦琼”；② 用ES的geo_shape类型存储围栏；③ 通过within/intersects等关系精准查询。记住：90%的问题都出在坐标系和数据格式上，而不是算法本身。

你在实现地理围栏时踩过什么坑？或者对ES的空间查询还有哪些疑问？欢迎在评论区留下你的“血泪史”，我会一一回复——说不定下次教程就专为你定制！