Question

我意识到这个“愚蠢”的空间查询，找到距离中心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)

Answer 1

Official documentation州：«如果地理实例可能与另一个地理实例相交，则返回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

让我想起了«Double Check Pattern»深奥......但在这种情况下，这显然是动机。

可能需要更多调查的一点是关于返回值的转换......很多年前我偶然发现了一个类似的问题，在服务器场中，一个boolean tre的隐式转换为int导致-1（0xFFFFFFFF）而不是1（0x00000001）...... COM年龄......

SQL Server空间查询：条件行为«奇怪»

1 个答案: