0

我已经意识到这个“愚蠢的”空间查询可以找到距离中心 5 公里远的所有点。源表包含 +150K 行。

这里是查询：

DECLARE @position geography = geography::Parse('POINT(9.123 45.123)')
DECLARE @circle geography = @position.STBuffer(5000) -- A circle of 5Km of radius

SELECT 
    g.Coordinate.STDistance(@position), g.Coordinate.Filter(@circle)
FROM 
    [DB_NAME].[SCHEMA].[TABLE] AS g WITH (nolock)
WHERE 
    g.Coordinate.Filter(@circle) = 1

我奇怪地观察到该WHERE条件不起作用：实际上我检索到条件返回 0 的偶数 +600 个点。

有什么建议么？

为了清楚起见，表模式是

[DB_NAME].[SCHEMA].[TABLE](Coordinate geography NOT NULL)
4

1 回答 1

0

官方文档指出：«如果地理实例可能与另一个地理实例相交，则返回 1。这种方法可能会产生误报，确切的结果可能取决于计划。如果没有找到地理实例的交集，则返回准确的 0 值（真正的负返回） 。»

所以我的意思是 0 总是可以的，而 1 可以近似（恕我直言，这种行为是绝对合理的）

顺便说一句，@Damien 观察让我简单地解决了问题：

DECLARE @position geography = geography::Parse('POINT(9.123 45.123)')
DECLARE @circle geography = @position.STBuffer(5000) -- A circle of 5Km of radius

SELECT * FROM
    (SELECT 
       g.Coordinate.Filter(@circle) filter, g.Coordinate Coord
        FROM [DB_NAME].[SCHEMA].[TABLE] AS g WITH (nolock)
    WHERE 
        g.Coordinate.Filter(@circle) = 1
    ) t
    WHERE t.filter = 1

这让我想起了“双重检查模式”深奥……但在那种情况下，动机很明确。

可以进一步研究的一点是关于返回值的转换......很多年前，我偶然发现了一个类似的问题，在服务器场中，将布尔值树隐式转换为 int 导致 -1 (0xFFFFFFFF) 而不是 1 (0x00000001 )…COM 年龄…</p>

于 2013-03-14T16:08:44.413 回答