做这行十一年，见过太多人栽在Geo数据上。特别是最近有个兄弟找我，说搞es geo直线相交怎么都查不出结果，急得半夜打电话。我打开他的代码一看，好家伙，坐标系乱套，查询语法还写错，典型的“想当然”式开发。今天不整那些虚头巴脑的理论，咱们直接说人话，怎么把这个硬骨头啃下来。

首先，你得明白，GeoLineString在ES里不是简单的画条线，它是经纬度的有序集合。很多新手第一步就错了，直接往里塞坐标，却不注意顺序。比如你要查两条路是不是交叉，你得先确定这两条线在地理意义上真的可能相交。如果一条在北京，一条在纽约，那肯定不相交，别浪费算力。

第一步，建索引。mapping里geometry字段类型必须是geo_shape。这里有个坑，很多文档没细说，默认的策略是indexed。如果你数据量大，建议用recursive策略，虽然查询稍微慢点，但精度和灵活性更好。别为了追求极致速度牺牲准确性，除非你明确知道自己在干嘛。

第二步，构造查询。这是重灾区。es geo直线相交的核心在于shape query里的relation参数。你要查相交，必须用intersects。很多人习惯用within或者contains，结果查出来的数据要么为空，要么全是错的。记住，intersects才是真相交，哪怕只是端点碰到，也算。

举个真实案例。我之前帮一个物流客户做路径重叠分析。他们有两万条线路，要找出所有有重叠部分的路段。刚开始用within查，结果发现很多只是共用起终点的线路也被算进去了，数据量爆炸，服务器直接崩了。后来改成intersects，并配合bbox过滤，先把距离远的排除掉，查询速度提升了十倍不止。

第三步，性能优化。Geo查询是CPU密集型操作。如果你的线特别长，节点特别多，查询会非常慢。这时候，你得考虑简化几何图形。在存入ES之前，用Java的JTS库或者Python的Shapely库，把那些不必要的拐点去掉。别追求像素级的还原，业务上差几米根本看不出来，但查询性能能提升好几个档次。

还有，别忽略坐标系。WGS84是默认的，但如果你用的是投影坐标系，比如UTM，那得在mapping里指定。不然ES会把你的经纬度当成平面坐标处理，结果完全不对。这点经常被忽视，导致查出来的结果南辕北辙。

最后，调试技巧。别光看结果，要看explain。看看ES是怎么执行查询的，是用点查还是面查。有时候你会发现，明明数据存在，却查不到，可能是因为精度问题。GeoHash的精度不够，导致两条很近的线被哈希到了不同的桶里。这时候，得调整geohash_precision参数，或者干脆不用geohash，用point策略，虽然存储大点，但查得准。

说了这么多，其实核心就两点：数据要干净，查询要精准。es geo直线相交这事儿，看着简单，水很深。你以为是简单的SQL查询，其实是复杂的几何计算。

如果你还在为Geo查询头疼，或者数据量大得跑不动，别硬扛。找个懂行的帮你看一眼mapping和查询语句，往往能省你半个月的时间。毕竟，经验这东西，不是看文档能学会的，是踩坑踩出来的。

本文关键词：es geo直线相交