我有一些空间数据，其所有坐标都为 lat/lon 对（大约 10 位小数精度），它作为 WGS84 数据存储在数据库中。一些数据表示为多边形，这些多边形是一些较小的多边形，其边界被存储。然后我有一些点，我从中构建了一个线段（每个段中只有 2 个点），稍后我将其用于与多边形的相交测试。
我正在使用 SpatialIndex 来改进我的查询，因此我将所有多边形的包络插入树中（使用 QuadTree 和 STRtree 进行测试）。然后，我将两个点连接到一个线段中，并使用它的包络来查询树对于可能的交叉点。问题是我得到了几乎所有的多边形，这显然是错误的。为了让您了解我的数据的真实规模，我有大约 100 个多边形覆盖整个北美，每个线覆盖了单个多边形的很小一部分。理想情况下，我希望结果不超过 2 个多边形。
我正在使用 JTS 进行此计算，并且我知道它并不真正适合球形数据，因此您能否建议我使用另一个库/工具来实现所需的行为或可能的解决方法（例如，在使用 JTS 之前进行投影）？
如果你只有北美，只需将地球旋转 90 度，这样阿拉斯加就不再在远东了。（有趣的事实：阿拉斯加是美国最北部、西部和东部的州）那么你的矩形应该没问题。
但是，在处理球形数据时，有许多不平凡的情况。根据数据的定义方式，多边形边界实际上可能是弯曲线，而不是直线。考虑一下 Google Ingress 的截图：https ://lh4.ggpht.com/S_9jrMqf08JfIbr7DgUDH96rvXMK4wOGtaSKYPGCruXv2HE4oeRuEaQIDIywMgH4198=h900
我在某处读到“雾”纹理与左侧字段中可见的绿线不匹配是由于两个绘图函数使用不同的近似值。一个始终是一条直线，而另一个则遵循地球的曲率。如果你有一个大的领域（多边形！），错误会变得更糟。
不幸的是，当您的数据由球体表面上的非直线组成时，“交点”成为一个棘手的术语；并且地球表面上的“直线”通常会在纬度坐标中产生arctan型曲线。
预测：这些可以提供帮助，但主要是当您的数据是本地数据时。UTM 预测非常好，但您至少需要 9 个 UTM 区域才能覆盖没有阿拉斯加的北美。只要您的数据在一个UTM 区域内，将数据投影到该区域，然后使用 2D 欧几里德空间就可以了。但如果它比这更大，你可能需要缝合不同的投影，这也很混乱。