On hinting spatial indexes

Recently, using SQL Server 2008 (not R2), I came across an issue with hinting a SELECT statement with a spatial index. This particular issue is different from the one Bob Beauchem wrote about in his article On hinting spatial indexes and query complexity (in turn he references Isaac Kunen’s Is my spatial index being used?).

The difference with the issue I found is to do with a very simple query that uses a constructed geometry. Here is the original coding of the query:

   FROM dbo.admin_sorted a
   WITH (INDEX (admin_sorted_geom))
  WHERE a.geom.STIntersects(geometry::STLineFromText('LINESTRING(320000,5340000,321000,5341000)',a.geom.STSrid)) = 1;
 -- Result
 Msg 8635, Level 16, State 8, Line 1
 The query processor could NOT produce a query plan FOR a query WITH a spatial INDEX hint.  Reason: The spatial parameter REFERENCES a COLUMN that IS defined below the predicate.  Try removing the INDEX hints OR removing SET FORCEPLAN.

Now, there could not be anything more simple that this query, so why is an error being thrown?

Following a hunch I discovered (I think) that the geometry::STLineFromText() constructor is the culprit. On this basis, I played around with the query and, using a CTE, came up with the following that correctly uses the spatial index.

Note: The reason for the “(SELECT TOP 1…. )” in the CTE is because I want the constructed linestring to have the same SRID as the host table.

 WITH sg AS (
   SELECT geometry::STLineFromText('LINESTRING(300000 5200000,500000 5400000)',a.Geom.STSrid) AS geom
     FROM (SELECT TOP 1 geom
             FROM  dbo.admin_sorted) a
 SELECT COUNT(*) AS AdminCount
   FROM sg a,
        dbo.admin_sorted b
   WITH (INDEX (admin_sorted_geom))
  WHERE b.geom.STIntersects(a.geom) = 1;
 -- Results

Here is that part of the actual explanation plan showing the use of the spatial index.

Perhaps this is no longer an issue in R2 or Denali.