R-tree包更靠谱，因其基于磁盘友好的R*-tree实现，内置批量插入、重叠查询、边界更新等能力，底层调用libspatialindex（非纯Python），性能远超手写四叉树，尤其在10k+多边形场景下避免性能断崖下跌。
为什么直接用 r-tree 包比手写四叉树更靠谱
因为 r-tree 是基于磁盘友好的 R*-tree 实现，自带批量插入、重叠查询、边界更新等能力，而自己实现容易在数据量稍大（比如 10k+ 多边形）时性能断崖式下跌。它底层调用的是 libspatialindex，不是纯 Python 实现，所以构建和查询都快得多。
注意：PyPI 上的 r-tree 包只是 C 库的 Python 绑定，安装失败大概率是缺系统依赖——Linux 要先装 libspatialindex-dev（Debian/Ubuntu）或 spatialindex-devel（CentOS/RHEL），macOS 用 brew install spatialindex。
如何用 Rtree 构建带地理坐标的围栏索引
关键点：R-Tree 本身不理解经纬度，它只认平面笛卡尔坐标。如果你直接把 (lon, lat) 当作 (x, y) 插入，跨本初子午线或极地时会出错（比如北京和西雅图的 bbox 可能被算作“相交”）。必须先投影。
- 小范围围栏（城市级）：用
pyproj转成 UTM（如 EPSG:32650），再塞进Rtree - 全球围栏（国家/洲级）：改用球面几何库（如
shapely.ops.transform+pyproj.Transformer）预处理 bbox，或换用支持地理坐标的引擎（如 PostGIS） - 最简方案（开发验证用）：确保所有围栏都在同一半球内，且不跨日期变更线，可临时用
(min_lon, min_lat, max_lon, max_lat)直接插入——但上线前必须改掉
示例（UTM 投影后插入）：
立即学习“Python免费学习笔记（深入）”；
from pyproj import Transformer
from rtree import index
<h1>WGS84 → UTM zone 50N</h1><p>transformer = Transformer.from_crs("EPSG:4326", "EPSG:32650", always_xy=True)
idx = index.Index()</p><h1>假设 fence_geo 是 [(min_lon, min_lat, max_lon, max_lat), ...]</h1><p>for i, (l, b, r, t) in enumerate(fence_geo):
xl, yb = transformer.transform(l, b)
xr, yt = transformer.transform(r, t)
idx.insert(i, (min(xl, xr), min(yb, yt), max(xl, xr), max(yb, yt)))
Rtree 查询时为什么总漏掉边缘围栏
常见原因是传入查询 bbox 的坐标系和索引中存储的不一致。比如索引里存的是 UTM 米单位，但查询时还传 (lon, lat)，导致数值范围差 3 个数量级，自然查不到。
另一个坑是 Rtree 的 intersection() 返回的是索引 ID，不是原始几何；如果原始围栏列表顺序变了（比如 reload 数据），ID 就对不上。
- 务必对查询 bbox 做和插入时**完全相同的投影变换**
- 避免用 list 索引匹配结果，改用字典映射：
fences_dict = {i: geom for i, geom in enumerate(fence_list)} - 如果要精确判断点是否在多边形内（而不仅是 bbox 相交），得用
shapely.geometry.shape().contains()二次过滤
内存 vs 磁盘索引：该选 Index() 还是 Index("my_index")
前者是纯内存索引，进程退出就丢；后者会持久化到文件（生成 my_index.dat 和 my_index.idx）。但注意：Rtree 的磁盘索引不是 ACID 的，多个进程同时写会损坏文件。
- 单进程高频读写（如实时围栏服务）：用内存索引，启动时从 DB 或文件批量 load
- 静态围栏（每天更新一次）：用磁盘索引，避免每次重启重建
- 别在 NFS 或网络文件系统上存磁盘索引——
libspatialindex依赖 mmap，远程文件系统不保证一致性
真正麻烦的从来不是建索引这一步，而是坐标系对齐和查询上下文的一致性。哪怕只差一次 transform，结果就不可信。
