ArcGIS Pro中Oracle转SQL Server的空间查询过滤改写需求

一、核心需求对应SQL写法 #

1. 精准实现"要素位于多边形内"（推荐） #

原Oracle语句的SDO_RELATE(mask=anyinteract)是判断空间要素存在任意交互，但你的实际需求是筛选table.a中完全位于table.b多边形边界内的要素，SQL Server中用ST_Within或ST_Contains即可实现，语义清晰且性能更优：

-- 写法1：使用ST_Within，判断a的几何完全包含于b的几何
SELECT a.*
FROM table.a a
INNER JOIN table.b b 
    ON a.shape.STWithin(b.shape) = 1
-- 筛选table.b的特定边界子集，根据实际字段调整条件
WHERE b.boundary_code IN ('AREA_001', 'AREA_003')

-- 写法2：使用ST_Contains，逻辑与ST_Within互逆，效果一致
SELECT a.*
FROM table.a a
INNER JOIN table.b b 
    ON b.shape.STContains(a.shape) = 1
WHERE b.boundary_code IN ('AREA_001', 'AREA_003')

2. 严格匹配Oracle ANYINTERACT逻辑 #

如果需要完全对齐原Oraclemask=anyinteract的所有交互场景（包含相交、接触、包含等所有非空间分离的情况），使用ST_Relate配合OGC标准模式串'T********'（表示两个几何至少有一个公共点）：

SELECT a.*
FROM table.a a
INNER JOIN table.b b 
    ON a.shape.STRelate(b.shape, 'T********') = 1
WHERE b.boundary_code IN ('AREA_001', 'AREA_003')

二、构建逻辑说明 #

• 关联优化：用INNER JOIN替代原Oracle的笛卡尔积写法，避免无意义的全量笛卡尔积计算，提升查询效率
• 空间函数选择：
  • 若需求明确为"要素在多边形内部"，优先选ST_Within/ST_Contains，这两个函数专门针对包含关系优化，比通用的ST_Relate性能更好
  • 若必须兼容原Oracle的所有交互场景，ST_Relate的'T********'模式串完全对应anyinteract的逻辑——只要两个几何不是完全分离，就会返回匹配
• 多边界筛选：通过WHERE子句对table.b添加业务过滤条件，比如按边界ID、区域编码等字段筛选出目标子集，替换示例中的boundary_code为实际业务字段即可

内容的提问来源于stack exchange，提问作者spatialNB