Go rtreego 最近邻查询中的距离基于什么对象

Go rtreego 最近邻查询比较的是查询点到索引条目包围矩形的最短欧氏距离。对象以 Spatial 接口的 Bounds() 提供这个矩形；库不会自动读取对象里的中心点、多边形顶点或业务距离函数。

所以，“最近的对象”要结合索引表示理解：返回值是业务对象，参与距离计算的却是它在索引中的矩形。一个中心很远、边缘很近的大矩形，可能比中心较近的小矩形排得更靠前。

官方项目地址：https://github.com/dhconnelly/rtreego。接口说明：https://pkg.go.dev/github.com/dhconnelly/rtreego。下面依据项目接口及实现说明，不声称已在本机执行示例。

我会先问：你说的最近，是离什么最近

假设页面展示的是仓库中心，而索引保存的是仓库区域。我面对“最近结果看起来离定位点很远”的反馈时，会先把这个建模假设拆开：页面用中心距离形成直觉，索引是否用区域距离给出答案？这比直接怀疑树的分支参数更容易解释现象。

这里用原创二维示例代入排查，不是线上事故复盘。我的判断重点是先确定目标：想找最近区域、最近中心，还是最近道路入口？三个问题需要的空间表示并不相同。

沿着Spatial接口找到真正参与计算的矩形

Spatial 的核心契约是 Bounds() Rect。索引条目保存矩形并关联对象。最近邻实现到达叶子条目后，用查询点与该条目矩形的最小距离进行比较，选中后交还对应对象。

矩形各坐标轴提供一个区间：查询点在区间内，该轴的距离贡献为零；在区间外，取到最近端点的差。把各轴差的平方相加，再开平方就是最短欧氏距离。若点在矩形内部或边界上，距离为零。这里说的是到矩形这个集合的距离，不是无条件到矩形边界线的距离。

项目的 geom.go 中 minDist 保存平方距离；单最近邻比较时有开平方，多最近邻排序可以保留平方值，因为非负距离的排序关系不因此改变。不要把内部平方值当成接口直接返回的米数。

用两个矩形拆开边缘距离和中心距离

令查询点为 (0,0)。矩形 A 的两个轴范围都是 [1,101]；矩形 B 的两个轴范围都是 [3,4]。A 到查询点的最短距离是 √2，B 是 √18。可是中心分别为 (51,51) 和 (3.5,3.5)，按中心距离比较会得到另一种次序。

package main

import (
    "fmt"
    "log"

    "github.com/dhconnelly/rtreego"
)

type Area struct {
    Name string
    Box  rtreego.Rect
}

// 用矩形作为索引表示；名称不参与距离计算。
func (a *Area) Bounds() rtreego.Rect { return a.Box }

func main() {
    // A靠近原点的一角很近，但矩形中心很远。
    boxA, err := rtreego.NewRect(rtreego.Point{1, 1}, []float64{100, 100})
    if err != nil {
        log.Fatal(err)
    }
    boxB, err := rtreego.NewRect(rtreego.Point{3, 3}, []float64{1, 1})
    if err != nil {
        log.Fatal(err)
    }

    // 二维索引，两个对象的矩形与查询点使用同一坐标单位。
    tree := rtreego.NewTree(2, 2, 4)
    tree.Insert(&Area{Name: "A", Box: boxA})
    tree.Insert(&Area{Name: "B", Box: boxB})
    nearest := tree.NearestNeighbor(rtreego.Point{0, 0})
    if nearest == nil {
        // 空树等无结果情形不应直接做类型断言。
        return
    }
    fmt.Println(nearest.(*Area).Name)
}

按上述几何关系，这个示例应选 A。这个结论来自坐标计算，不是伪造的程序输出。若把 A 理解为一个真实矩形区域，这个结果合理；若只想找中心最近的区域，问题就出在索引表示与需求不一致。

实际排查时，我会把查询点、对象用于构建 Bounds 的坐标和页面显示坐标并排看。坐标维数、轴顺序、单位必须一致；不能一边用平面坐标，一边把结果解释成另一种单位的路程。

业务需要中心或真实几何时怎样调整

如果业务对象本来就是矩形区域，继续使用包围矩形距离通常符合这类需求。如果对象是复杂多边形，包围矩形可能覆盖并不属于真实几何的空白位置；点落在框里，不代表它落在多边形里。

如果我要的是中心距离，我会把中心作为独立的索引语义来设计，而不再声称区域 Bounds 最近等于中心最近。库提供的 Point.ToRect(tol) 可以把点包装成小矩形，但计算对象仍是这个小矩形；容差会影响很近对象的距离和并列关系，不能把这种包装说成完全相同的点距离。

如果我要的是真实几何距离，应用需要另行计算。先取有限数量的矩形近邻再按真实距离重排，是一种候选策略，但不能仅凭这一步宣称找到了全局真正最近对象：没进入候选集的对象仍可能更近。要求严格精确时，需要有可证明覆盖范围的候选搜索或针对该度量的完整方案。

这也是我的取舍：宽泛包围框易于接入，却会损失对象内部几何信息。不能把候选数从 10 改成 100 就当作正确性证明，也不应编造一个通用候选数。

返回对象、距离数值与常见误判

为什么改了对象中心字段，最近邻没有按预期改变？ 先看中心字段是否参与 Bounds 的构建，以及索引中是否仍保留旧空间表示。单改业务字段不能假设索引条目同步刷新；调整位置应遵守项目的删除、更新与重新插入约定。

经纬度放进 Point 就是球面距离吗？ 不能这样解释。这里使用的是坐标空间的欧氏度量，不能直接把经纬度差的计算当成球面距离或道路行程。地理业务需要自己定义坐标转换和距离语义。

为什么 API 没有距离数字？ 最近邻接口的返回类型就是对象或对象列表。需要展示数值时，要明确计算的是矩形、中心还是真实几何的距离，再由应用计算并标注单位，避免列表按一种度量排序、界面却显示另一种度量且不作说明。

参考：rtreego 接口文档；项目最近邻实现；项目几何距离实现。