1. 属性查询这件事90%的人只用到了皮毛干这行十来年我发现一个挺有意思的现象身边不少同事能把空间分析、模型构建器、栅格计算器玩得很溜但一到按属性选择那个对话框敲出来的公式永远是字段 某值这一种。其实在 ArcGIS 里属性查询公式能干的活儿远比大多数人想象的多——地类核查、面积异常筛查、时间区间统计、导出前的数据过滤、裁剪前的范围锁定、批量改图例名称前的要素定位很多原本要写脚本或者手工翻属性表的活儿一条公式就能收工。这套写法的核心是SQL 表达式ArcGIS 把它嵌在按属性选择定义查询查询图层等多个入口里。但不同数据源、不同字段类型、不同版本的工具对同一句公式的容忍度完全不一样——同样一句DLMC 耕地在 shapefile 里能跑在 File Geodatabase 里能跑换到个人地理数据库就未必日期字段更是重灾区2024-01-01、date 2024-01-01、#2024-01-01#三种写法各对应一套环境。这份内容我按数值、文本、日期、空值、多条件组合、几何系统字段、业务组合七个方向整理了 100 条公式同时把背后的语法规则、报错原因、性能坑一并说清楚。刚入门的朋友可以照着抄做了几年的老手也能找到几条顺手存进自己模板里的。1.1 哪些活儿其实一条公式就能干完先说几个我自己最常用的场景。第一类是成果自检比如入库前要确认有没有面积为零的图斑、有没有地类名称为空的记录、有没有权属代码缺失的字段这三件事各一条公式就能筛出来比人工翻表快几十倍。第二类是批量导出前的圈选要按行政区、按年份、按地类把数据切成几份往外发用属性把要素选出来再导出比先裁剪再筛选省一步。第三类是地图显示控制整幅图几万个图斑全画出来又卡又密用定义查询只留重点图层页面秒开。第四类是制图出图时的要素定位改图例名称、改符号样式之前把符合某个特征的要素单独选出来出错的概率会低很多。这些场景有个共同点它们都只需要属性层面的判断不需要几何关系参与。很多人一遇到筛选就想用按位置选择那玩意儿慢而且要求图层之间必须有重叠关系属性查询只要字段写得对几秒钟就返回结果。所以判断标准很简单——如果筛选条件和坐标无关就别去碰空间选择。1.2 四个查询入口别再搞混ArcGIS 里跟查询沾边的入口有好几个用法差别不小混着用很容易出问题。按属性选择是最常用的它生成的是当前选择集结果不落盘换个操作就没了适合临时筛查。定义查询是给图层加一个永久性的显示过滤条件被过滤掉的要素在地图上根本不画出来也不参与后续的分析和统计适合做大范围屏蔽比如整幅底图我只想看某一年的数据。查询图层ArcGIS Pro 里的 Make Query Layer会生成一个新的只读图层数据源还是原来的库适合在企业级数据库上做轻量取数。至于字段计算器里的表达式那又是另一回事它用的是 Python 或 VBScript不是 SQL语法体系完全不同——这一点我见过太多人搞混在字段计算器里写LIKE %村%然后报错跑来问我为什么按属性选择能跑。记住一条SQL 表达式管选哪些字段计算器管改成什么两边不通用。2. 公式写不对八成是这几个语法细节没搞清先把底层规则讲透后面 100 条公式才不会照抄照错。属性查询的语法看起来简单实际是个方言混杂区——ArcGIS 本身不解析 SQL它把表达式转给底层的数据库去执行File Geodatabase 交给自己的引擎shapefile 走 dBase企业级数据走 SQL Server 或 PostgreSQL所以同一句话在不同地方表现不同。2.1 数据源不同字段界定符完全不同这个是最典型的翻车点。同一个字段DLMC不同数据源写法如下数据源类型字段界定符示例Shapefile双引号DLMC 耕地File Geodatabase不加任何符号加双引号也能跑DLMC 耕地Personal GeodatabaseAccess方括号[DLMC] 耕地SQL Server / PostgreSQL双引号或按库规范DLMC 耕地我在 ArcMap 里试过一个坑从网上抄来的公式带双引号粘到 File GDB 上照跑不误但粘到个人地理数据库上直接报表达式无效。反过来也一样。所以看到别人的公式先看对方用的是什么数据源再决定要不要改界定符。字段名里带空格、带中文、或者撞上数据库的保留字比如DATE、LENGTH、ORDER时界定符是必须加的这个没有偷懒的余地。中文别名尤其要注意有些版本的 ArcGIS 对全角括号、全角引号零容忍最好一开始就用拼音字段名。2.2 值的写法由字段类型决定判断标准只有一条看字段到底是数值型还是文本型还是日期型。数值型短整型、长整型、浮点、双精度值不加任何引号MJ 1000。加了引号MJ 1000有的数据源能自动转换有的直接报类型不匹配。文本型值必须用英文单引号包起来DLMC 耕地。注意是单引号不是双引号双引号是给字段名用的。日期型这块最麻烦后面 3.3 节单独讲File GDB 用date YYYY-MM-DDAccess 用#YYYY-MM-DD#企业库用YYYY-MM-DD。还有一个隐蔽的坑文本型字段里存数字。比如行政区代码存在文本型字段里你写XZQDM 330100就会出问题必须写成XZQDM 330100。反过来数值型字段想按前两位筛选得先用SUBSTRING转字符串——但注意很多 SQL 引擎不允许在WHERE里直接对数值做字符串函数这时候要么改成文本字段要么就别用 LIKE。2.3 通配符与操作符速查通配符这块File GDB 和 Personal GDB 是两套规则这是最容易被忽略的语义File GDB / 企业库Personal GDBAccess匹配任意多个字符%*匹配单个字符_?模糊包含LIKE %田%LIKE *田*匹配固定两位LIKE 3301__LIKE 3301??常用操作符列一下等于、不等于、比较、LIKE模糊、IN集合、BETWEEN ... AND ...区间包含两端这个务必记住、IS NULL/IS NOT NULL判空、ANDORNOT逻辑组合。提示BETWEEN 100 AND 200等价于 100 AND 200两端都是闭区间。我见过有人以为它是开区间结果边界值总漏掉。还有一点SQL 里的字符串比较大小写敏感与否取决于底层数据库。File GDB 默认区分大小写企业库通常也区分。如果你不确定目标数据源的行为最省事的做法是两边都套上UPPER()或LOWER()兜底比如UPPER(DLMC) GRASSLAND虽然会牺牲一点索引性能但结果稳定。3. 100个属性查询公式按场景分组整理下面这 100 条我按使用频率和场景分组。字段名用的是常见的国土/规划类命名习惯DLMC地类名称、DLBM地类编码、MJ面积、XZQDM行政区代码、QSDWMC权属单位名称、YXRQ影像日期、Shape_Area、Shape_Length这些你套到自己数据里改个名就行。所有示例默认针对 File Geodatabase其他数据源按第 2 章的规则调整界定符和通配符。3.1 数值型字段范围、精度与异常值筛查数值字段的查询看着最没技术含量实际最考验细心程度。因为数值字段往往承载着面积、长度、代码、年份这些关键信息一旦比较逻辑写错筛出来的结果就是错的而且错得很隐蔽——不会报错只会悄悄漏掉或者多出记录。比如BETWEEN的闭区间特性、浮点数的精度问题、负数遗漏问题都是常见的坑。-- 1. 大于指定值 MJ 10000 -- 2. 大于等于且小于等于等价于 BETWEEN MJ 500 AND MJ 2000 -- 3. 区间筛选含两端 MJ BETWEEN 500 AND 2000 -- 4. 排除某个值 DLBM 101 -- 5. 等于指定编号 OBJECTID 1024 -- 6. 多值集合 DLBM IN (101, 102, 103) -- 7. 排除多值集合 DLBM NOT IN (101, 102) -- 8. 筛选零值 MJ 0 -- 9. 筛选负值异常数据排查 MJ 0 -- 10. 空值风险下的安全比较先排除空值再比大小 MJ IS NOT NULL AND MJ 1000 -- 11. 浮点数按精度比较 ROUND(MJ, 2) 1234.56 -- 12. 绝对值筛选 ABS(MJ) 100 -- 13. 向下取整定位 FLOOR(MJ) 500 -- 14. 向上取整定位 CEILING(MJ) 501 -- 15. 平方关系如长度平方 POWER(LEN, 2) 1000000 -- 16. 开方筛选 SQRT(MJ) 10 -- 17. 比值筛选如建筑密度 MJ / Shape_Area 0.9 -- 18. 倍数关系不同单位换算后筛选 MJ * 15 10000第 11 条要特别注意浮点数在计算机里不是精确存储的1234.5599999和1234.56在肉眼看来一样直接比较可能匹配不上。用ROUND()把它固定到你要的小数位再比才稳。第 12 条用ABS()也是同理处理那些可能存成负值的面积数据。第 17 条这种字段间比值比较特别有用比如查建筑面积占图斑面积超过 90%的地块一条公式就出来了。但注意除法有除零风险如果Shape_Area可能存在 0最好补一句Shape_Area 0 AND。3.2 文本型字段模糊匹配、前后缀与编码筛查文本字段是属性查询的主战场。地类名称、单位名称、备注、证件编号全是文本。这里的核心是LIKE加通配符的组合以及SUBSTRING、CHAR_LENGTH这类函数。-- 19. 精确匹配 DLMC 耕地 -- 20. 排除精确值 DLMC 耕地 -- 21. 前缀匹配 DLMC LIKE 耕地% -- 22. 后缀匹配 DLMC LIKE %田 -- 23. 包含匹配 DLMC LIKE %耕% -- 24. 定长匹配两个字符且首字为耕 DLMC LIKE 耕_ -- 25. 大写归一后比较 UPPER(DLMC) GRASSLAND -- 26. 小写归一后包含匹配 LOWER(DLMC) LIKE %road% -- 27. 按字符长度筛选 CHAR_LENGTH(DLMC) 2 -- 28. 长度超限排查 CHAR_LENGTH(DLMC) 4 -- 29. 截取前两位比较 SUBSTRING(DLMC, 1, 2) 耕地 -- 30. 首尾带空格排查 TRIM(DLMC) DLMC -- 31. 尾部残留空格 DLMC LIKE % -- 32. 首部残留空格 DLMC LIKE % -- 33. 单位名称后缀匹配 QSDWMC LIKE %村委会 -- 34. 单位名称前缀匹配 QSDWMC LIKE 杭州市% -- 35. 多值集合匹配 DLMC IN (耕地, 园地, 林地) -- 36. 多值排除 DLMC NOT IN (耕地, 园地) -- 37. 等价多值的手写写法 DLMC 旱地 OR DLMC 水田 -- 38. 组合条件 DLMC LIKE %田 AND DLBM 101 -- 39. 排除包含特定词的记录 ZLMC NOT LIKE %临时% -- 40. 编码首字符筛选 SUBSTRING(DLBM, 1, 1) IN (1, 2)第 24 条那个_通配符实际用起来比想象中有用。比如查两个字且以水开头的地类LIKE 水_一下就出来比写一堆OR清爽。但如果你要匹配的字符本身就是%或_那就得转义而 ArcGIS 对转义的支持在各数据源之间不一致遇到这种需求我一般宁可在字段计算器里处理不在查询里死磕。第 30 条是我自己用得最多的一条脏数据检查公式。数据从 Excel 导入、从 CAD 转换、从其他系统对接过来尾巴上带空格的字段特别多肉眼看不出但一比较就匹配不上。TRIM(DLMC) DLMC一条下去所有带空格的记录全露馅。第 40 条针对的是地类编码第一位是 1 或 2这类需求前提是DLBM得是文本型字段。如果它是数值型就得换思路或者先建个计算字段把它转成文本。3.3 日期型字段按月、按季度、按时段筛选日期是属性查询里最容易翻车的类型没有之一。原因有两个一是各数据源对日期的字面量写法不统一二是日期字段可能带时间部分导致等于某一天这种看似简单的需求变得复杂。File Geodatabase 推荐写法是date YYYY-MM-DD也可以带时间date YYYY-MM-DD HH:MM:SS。个人地理数据库用#2024-01-01#。企业级数据库直接写2024-01-01。-- 41. 某天之后 YXRQ date 2024-01-01 -- 42. 与当前日期比较 YXRQ CURRENT_DATE -- 43. 年度区间筛选 YXRQ BETWEEN date 2024-01-01 AND date 2024-12-31 -- 44. 按年份提取 EXTRACT(YEAR FROM YXRQ) 2024 -- 45. 按月份提取 EXTRACT(MONTH FROM YXRQ) 6 -- 46. 按日提取 EXTRACT(DAY FROM YXRQ) 15 -- 47. 季度筛选3-5月 EXTRACT(MONTH FROM YXRQ) IN (3, 4, 5) -- 48. 时间下限排查清理历史数据 YXRQ date 2000-01-01 -- 49. 日期空值排查 YXRQ IS NULL -- 50. 精确到时刻的匹配 YXRQ date 2024-06-01 08:30:00 -- 51. 按小时筛选 EXTRACT(HOUR FROM YXRQ) 12 -- 52. 跨年跨月的组合筛选 EXTRACT(YEAR FROM YXRQ) 2020 AND EXTRACT(MONTH FROM YXRQ) 6 -- 53. 日期存成文本时的模糊匹配 SJ LIKE 2024-06% -- 54. 更新时间的合法区间 GXSJ date 2020-01-01 AND GXSJ CURRENT_DATE -- 55. 每月1号的记录 EXTRACT(DAY FROM JCRQ) 1 -- 56. 已填写且非默认值的日期 XZRQ IS NOT NULL AND XZRQ date 1900-01-01第 50 条我特意留在这里做个提醒很多日期字段实际存的是时间戳带时分秒。你写YXRQ date 2024-06-01如果底层存的是2024-06-01 08:30:00那这一条根本匹配不上。解决办法要么用区间 date 2024-06-01 AND date 2024-06-02要么用EXTRACT把年月日拆出来比。第一种写法更推荐因为它能走索引速度快。第 56 条那个date 1900-01-01是很典型的占位默认值。数据从老系统迁移过来日期没填的地方经常被塞成 1900 年或者 1970 年用一条公式把它们和真正的空值一起筛出来是个好习惯。3.4 空值与脏数据NULL、空串、零值不是一回事这一节单独拎出来是因为没有值在数据库里至少有四种表现形式NULL真·空、空字符串、纯空格 、以及业务意义上的零值或默认值。它们互相之间不相等IS NULL匹配不到空串 也匹配不到NULL这是 SQL 的三值逻辑决定的。-- 57. 真·空值 DLMC IS NULL -- 58. 非空 DLMC IS NOT NULL -- 59. 空字符串 DLMC -- 60. 纯空格或空串去空格后无内容 CHAR_LENGTH(TRIM(DLMC)) 0 -- 61. 面积缺失或非正 MJ IS NULL OR MJ 0 -- 62. 面积为零 MJ 0 -- 63. 行政区代码有但权属代码缺失 XZQDM IS NOT NULL AND QSDWDM IS NULL -- 64. 状态字段未填写 YXZT IS NULL -- 65. 日期未填写 YXRQ IS NULL -- 66. 几何面积未计算 Shape_Area IS NULL -- 67. 非空的另一种写法逻辑等价 NOT (DLMC IS NULL) -- 68. 几何面积无效排查 Shape_Area IS NULL OR Shape_Area 0第 60 条是我个人最推荐的空值检查写法。因为数据来源一多你根本不知道这列是被填成了NULL还是还是几个空格用CHAR_LENGTH(TRIM(字段)) 0一次性全覆盖比你写三个OR靠谱得多。第 68 条这种Shape_Area 0的检查在数据入库质检里属于必查项。几何面积为零通常意味着这个要素的几何有问题——可能是空几何、可能是自相交导致的退化、也可能是投影问题。查出来之后别急着删先看看几何本身长什么样。3.5 多条件组合与括号优先级条件一多括号就成了生死线。SQL 的运算优先级是NOTANDOR也就是说A OR B AND C会被解析成A OR (B AND C)而不是(A OR B) AND C。这两种结果差得很远。我的习惯是——只要出现OR就给所有条件加上括号宁可多敲几个字符也别让结果悄悄跑偏。-- 69. 两个条件同时满足 DLMC 耕地 AND MJ 1000 -- 70. 满足其一即可 DLMC 耕地 OR DLMC 园地 -- 71. 取反 NOT DLMC 耕地 -- 72. 先或后与务必加括号 (DLMC 耕地 OR DLMC 园地) AND MJ 1000 -- 73. 先与后或 DLMC 耕地 AND (MJ 1000 OR Shape_Area 5000) -- 74. 满足前者且不满足后者 DLMC 耕地 AND NOT DLBM 101 -- 75. 两组条件各自成组 (DLMC 耕地 OR DLMC 园地) AND (XZQDM LIKE 3301% OR XZQDM LIKE 3302%) -- 76. 三条件串联 DLMC 耕地 AND MJ 1000 AND XZQDM LIKE 33% -- 77. 三条件择一 DLMC 耕地 OR DLMC 园地 OR DLMC 林地 -- 78. 整体取反德摩根定律 NOT (DLMC 耕地 OR DLMC 园地) -- 79. 与非的等价写法 NOT (DLMC 耕地 AND MJ 1000) -- 80. 两两组合 (DLMC 耕地 AND MJ 1000) OR (DLMC 园地 AND MJ 500) -- 81. 主条件加细分 DLMC 耕地 AND (MJ 1000 OR Shape_Area 5000) AND XZQDM LIKE 33% -- 82. 排除法的多条件版本 NOT DLMC 耕地 OR NOT MJ 1000第 78 条和第 82 条都涉及德摩根定律NOT (A OR B)等价于NOT A AND NOT BNOT (A AND B)等价于NOT A OR NOT B。听起来绕但实际工作中很有用——有些数据源对整体取反的括号支持不好换成展开形式就能跑。第 82 条就是NOT (DLMC 耕地 AND MJ 1000)的展开版。3.6 几何与系统字段Shape_Area、Shape_Length、OBJECTID这类字段平时容易被忽略但它们在做数据质检的时候非常好用。Shape_Area和Shape_Length是系统自动维护的跟几何形状严格对应用它来筛碎图斑狭长图斑超大面积图斑都特别顺手。OBJECTID是要素的唯一标识用来定位具体某几条记录。-- 83. 大面积图斑 Shape_Area 10000 -- 84. 面积区间 Shape_Area BETWEEN 1000 AND 5000 -- 85. 短边线要素 Shape_Length 10 -- 86. 按对象标识定位 OBJECTID 1000 -- 87. 狭长形态初筛周长与面积之比 Shape_Length / Shape_Area 0.01 -- 88. 碎图斑筛查 Shape_Area 100 -- 89. 零面积几何 Shape_Area 0 -- 90. 指定若干对象标识 OBJECTID IN (1, 5, 9, 20) -- 91. 大面积且长周长 Shape_Length 1000 AND Shape_Area 100000 -- 92. shapefile 的 FID 范围 FID 0第 87 条这个周长除以面积的比值是我做狭长图斑初筛时常用的土办法。比值越大形状越细长。但它只是个粗筛真正的狭长判断还得结合尖锐角检查那类工具来做——属性查询负责缩小范围几何工具负责精确判定两步走的效率比一上来就全量跑几何算法高得多。第 88 条查碎图斑也是同理先圈出来再决定是合并还是删除。第 89 条查零面积几何这个在数据合并、坐标转换之后特别容易出现。有些要素在转换过程中几何退化了属性表里还留着记录但面积算出来是 0画在地图上也看不见。用这条筛出来要么修复几何要么删掉。3.7 面向业务的组合公式地类、图斑、权属最后一组是我在实际项目里攒下来的组合公式特点是条件多、跨字段、贴近真实业务规则。这类公式没法通用但思路可以复用——把你脑子里的业务规则翻译成字段之间的逻辑关系。-- 93. 一级地类为 01 且面积达标的图斑 DLBM LIKE 01% AND MJ 100 -- 94. 指定行政区内的耕地和园地 XZQDM LIKE 3301% AND DLMC IN (耕地, 园地) -- 95. 耕地园地中大面积的图斑 (DLMC 耕地 OR DLMC 园地) AND Shape_Area 5000 -- 96. 村级的、2015 年之前的影像 QSDWMC LIKE %村% AND YXRQ date 2015-01-01 -- 97. 地类和面积都完整填写的记录 DLMC IS NOT NULL AND MJ IS NOT NULL AND MJ 0 -- 98. 四位行政区代码内、中等面积图斑 XZQDM LIKE 3301__ AND MJ BETWEEN 100 AND 1000 -- 99. 编码集合 面积 行政区三重筛选 DLBM IN (101, 102, 103) AND Shape_Area 2000 AND XZQDM LIKE 33% -- 100. 田类地类、有面积、限定时间段的完整筛选 MJ 0 AND DLMC LIKE %田 AND YXRQ BETWEEN date 2010-01-01 AND date 2020-12-31第 93 条用的LIKE 01%是个很实用的技巧地类编码通常是分级编码前两位代表一级类、前四位代表二级类用前缀匹配能一次性圈出整个大类不用把子类一个个列出来。前提是编码字段得是文本型或者能被当作文本处理。第 98 条那个LIKE 3301__里的双下划线表示3301 后面还有恰好两位也就是五位行政区代码。如果你写成LIKE 3301%就会把六位、九位的代码也一起匹配进来结果完全不一样。第 100 条是典型的多重业务约束实际工作中这种公式往往是从一段需求文档翻译过来的面积大于零、地类名字里有田、影像日期在某个十年区间内。翻译的原则是一个约束对应一个条件条件之间用 AND 连接涉及或者关系的用小括号圈起来。4. 查到之后怎么用从选择到导出的完整衔接公式敲完、点确定、要素被选中这只是开始。真正产生价值的是选完之后的那几步操作。很多人卡在这一环选是选出来了但不知道下一步该干嘛或者用了错误的方式处理导致数据丢失、属性错乱。4.1 选出来的要素怎么变成新数据最直接的做法是导出数据。右键图层 → 数据 → 导出数据选导出所选要素得到一个只包含筛选结果的新要素类。注意导出时坐标系统有个选项默认是数据源的坐标系如果目标环境用别的坐标系在这里顺手改掉能省很多事。第二个做法是在选区基础上继续裁剪。比如你有一个全省的矢量图层和一个县界图层先用属性把县界选出来再用裁剪工具把全省数据切到该县范围内。这个流程比先按位置选再裁剪更可控因为按属性选的县界不会因为你地图比例尺变了而选错。第三个做法是批量编辑。选中之后打开属性表右键某个字段 → 字段计算器对整批记录统一赋值。比如把选出来的所有图斑的状态字段改成已核查一条计算就完成不用一条条改。这里要注意字段计算器操作的是当前选择集如果你忘了先做选择它会把整个图层的值全改了这个错误很难撤销。4.2 用表达式驱动显示和出图定义查询是出图场景里最好用的东西。一幅图几万个图斑全画出来不仅卡符号还会挤成一团——你可能遇到过地类符号太密的问题符号压符号什么都看不清。解决思路之一就是用定义查询把图层按类别拆开比如把耕地做成一个图层、园地做成一个图层每个图层单独调符号密度和显示比例尺范围。具体做法是给每个图层加定义查询公式就是前面那些条件比如耕地图层写DLMC 耕地园地图层写DLMC 园地。这样每个图层的符号系统可以独立设置符号大小、偏移、注记密度都能分开调出图效果干净很多。而且被过滤掉的要素不参与渲染滚动缩放的时候明显更流畅。需要提醒的是定义查询是永久生效的它会一直跟着图层走保存文档后重新打开也还在。如果你只是临时想看某一部分数据用按属性选择更合适别随便动定义查询。检查图层有没有被过滤看图层名后面有没有一个小漏斗图标就行了。4.3 把常用公式沉淀成自己的模板公式这东西敲一次就够了敲第一百次就是浪费生命。ArcMap 里按属性选择对话框下方有一排按钮可以把当前表达式保存成文件扩展名是.exp下次从同一位置加载回来就能用。ArcGIS Pro 里没有直接对应的保存按钮但可以建查询图层或者定义查询把它留在工程里。我自己的做法是维护一个纯文本的公式清单按项目分类每条前面写一行注释说明用途。比如筛碎图斑Shape_Area 100、筛空值CHAR_LENGTH(TRIM(DLMC)) 0用的时候搜关键词复制过来改字段名就行。这个习惯坚持了几年现在处理新项目的质检环节基本半小时能把全套检查跑完。如果你手上项目多还可以把公式按数据源分成几个文件——File GDB 一份、企业库一份避免界定符和通配符搞混。文件命名上用项目名_检查类型.txt这种格式找起来快。5. 报错与慢查询我踩过的坑最后这部分是纯经验。语法规则书上都有但这些报错和性能问题只有真正在项目里摔过跟头才知道。5.1 常见报错速查表报错提示大概率原因解决方向未找到列 / Invalid column name字段界定符用错或字段名拼写不符检查数据源类型shapefile 加双引号Access 加方括号SQL 表达式无效 / 语法错误引号用了中文全角或括号不配对关掉输入法重敲引号逐个核对括号参数类型不匹配数值字段的值加了引号或文本字段的值没加引号核对字段类型数值裸写、文本加单引号值太长 / String truncatedLIKE 模式里的引号不闭合导致整段文字被当成一个值检查LIKE %田这类语句是否缺了右边的引号日期格式无效日期写法跟数据源不匹配File GDB 用date ...Access 用#...#查询返回空结果但不报错大小写不一致或字段值带首尾空格用UPPER()归一或先跑一遍 TRIM 检查中文变乱码编码不匹配多见于 shapefile 的属性表检查 dbf 的编码设置或改用 File GDB 存储找不到字段但属性表里明明有字段名是数据库保留字或含空格加界定符或改用别名这里面最常见的是中文全角引号。从网页或者 Word 文档里复制公式引号经常变成和ArcGIS 完全认不出来。我踩过好几次盯着屏幕看半天觉得没毛病最后发现是引号的问题。所以我的习惯是粘过来的公式一律先用英文输入法把引号重新敲一遍。另一个高频坑是保留字。字段名叫DATE、NAME、ORDER、LENGTH、YEAR这些在某些数据库里不加界定符会解析失败。系统的报错一般会说未找到列让人一头雾水——明明字段就在那儿。解决办法就是给字段名加上界定符或者干脆在数据设计阶段就避开这些词。5.2 慢查询的几个优化方向属性查询在数据量小的时候感觉不出来一到十万级以上的要素慢的能让人怀疑人生。我自己总结下来慢的原因基本集中在这几个地方。第一LIKE 用了前置通配符。LIKE %村%这种写法数据库没办法用索引必须逐行扫描十万条数据扫下来就是几秒。如果业务上允许改成后缀匹配LIKE 杭州市%或者用IN列枚举值速度能差一个数量级。实在要用前置通配符就先把数据按其他条件缩到一个小范围再做模糊匹配。第二属性索引没建。File Geodatabase 和 shapefile 都可以给字段建属性索引在图层属性里能找到。经常用来做筛选的字段——比如地类编码、行政区代码、日期——建上索引查询速度提升很明显。代价是数据编辑会稍微慢一点索引需要维护但对以查询为主的数据来说完全值得。第三先空间后属性的顺序反了。如果你的筛选既要满足空间范围又要满足属性条件正确的顺序是先用空间范围把数据砍小再用属性条件精筛。因为空间筛选通常能砍掉 90% 以上的数据剩下的再做属性判断就快了。反过来先做属性、再叠空间等于对全量数据跑两遍。第四用错了入口。定义查询和按属性选择虽然公式一样但执行方式不同。定义查询是渲染层面的过滤每次重绘都会重新执行按属性选择是一次性的选完就固化了。数据量特别大的时候我更倾向于先用按属性选择把要素选出来导出成临时图层再对临时图层做后续操作。5.3 几个容易被忽略的实操细节关于选择集的传递性。按属性选择出来的结果会被后续的很多工具继承。比如你选了一批要素然后去跑裁剪工具如果没注意底下的输入要素是哪个图层工具可能只处理你选中的部分也可能处理全部取决于那个工具的默认行为。这个坑我踩过不止一次明明只想处理一个县结果整个市的数据都被重算了。养成习惯跑工具之前先看一眼有没有活动选择集。关于字段类型的隐性转换。有时候公式在 A 数据源上跑得通换到 B 就报类型错误原因往往是同一个字段在两边的类型不一样。比如从 CAD 转过来的数据面积字段可能是文本型你按数值比较就会失败。遇到这种情况别急着改公式先确认字段类型必要时用字段计算器新建一个数值字段。关于表达式里的空格。MJ1000和MJ 1000大多数情况都能跑但涉及字符串拼接或者函数嵌套时缺空格会引发解析错误。我的习惯是运算符两边一律加空格函数参数逗号后面也加空格写的时候多敲几下调试的时候能少花半小时。关于多用户环境。企业级数据库上的属性查询如果你的账号权限不够可能查不到某些记录但不会报权限错误——数据就是凭空少了一些。这个现象排查起来非常费劲因为公式本身没问题。如果发现查询结果跟预期对不上先确认一下自己账号的权限范围。关于查询结果的顺序。属性查询返回的记录顺序是不确定的除非你显式指定排序。所以不要假设第一条就是最新的涉及顺序的处理一定要另外加排序字段。我在实际项目里的体会是属性查询这套东西语法门槛其实很低真正的门槛在于对数据本身的理解——知不知道字段里存的是什么、有没有脏数据、边界值怎么处理。同样一条公式理解数据的人写出来能用三年不理解的人写完第二天就发现漏了一半记录。所以每次接手新数据我都会先花二十分钟看看字段类型、抽几条看看值的形态、跑一遍空值和异常值检查然后再动手写筛选逻辑。这个习惯帮我省下的返工时间远比那二十分钟多得多。
ArcGIS属性查询100条公式：SQL表达式、报错与优化
1. 属性查询这件事90%的人只用到了皮毛干这行十来年我发现一个挺有意思的现象身边不少同事能把空间分析、模型构建器、栅格计算器玩得很溜但一到按属性选择那个对话框敲出来的公式永远是字段 某值这一种。其实在 ArcGIS 里属性查询公式能干的活儿远比大多数人想象的多——地类核查、面积异常筛查、时间区间统计、导出前的数据过滤、裁剪前的范围锁定、批量改图例名称前的要素定位很多原本要写脚本或者手工翻属性表的活儿一条公式就能收工。这套写法的核心是SQL 表达式ArcGIS 把它嵌在按属性选择定义查询查询图层等多个入口里。但不同数据源、不同字段类型、不同版本的工具对同一句公式的容忍度完全不一样——同样一句DLMC 耕地在 shapefile 里能跑在 File Geodatabase 里能跑换到个人地理数据库就未必日期字段更是重灾区2024-01-01、date 2024-01-01、#2024-01-01#三种写法各对应一套环境。这份内容我按数值、文本、日期、空值、多条件组合、几何系统字段、业务组合七个方向整理了 100 条公式同时把背后的语法规则、报错原因、性能坑一并说清楚。刚入门的朋友可以照着抄做了几年的老手也能找到几条顺手存进自己模板里的。1.1 哪些活儿其实一条公式就能干完先说几个我自己最常用的场景。第一类是成果自检比如入库前要确认有没有面积为零的图斑、有没有地类名称为空的记录、有没有权属代码缺失的字段这三件事各一条公式就能筛出来比人工翻表快几十倍。第二类是批量导出前的圈选要按行政区、按年份、按地类把数据切成几份往外发用属性把要素选出来再导出比先裁剪再筛选省一步。第三类是地图显示控制整幅图几万个图斑全画出来又卡又密用定义查询只留重点图层页面秒开。第四类是制图出图时的要素定位改图例名称、改符号样式之前把符合某个特征的要素单独选出来出错的概率会低很多。这些场景有个共同点它们都只需要属性层面的判断不需要几何关系参与。很多人一遇到筛选就想用按位置选择那玩意儿慢而且要求图层之间必须有重叠关系属性查询只要字段写得对几秒钟就返回结果。所以判断标准很简单——如果筛选条件和坐标无关就别去碰空间选择。1.2 四个查询入口别再搞混ArcGIS 里跟查询沾边的入口有好几个用法差别不小混着用很容易出问题。按属性选择是最常用的它生成的是当前选择集结果不落盘换个操作就没了适合临时筛查。定义查询是给图层加一个永久性的显示过滤条件被过滤掉的要素在地图上根本不画出来也不参与后续的分析和统计适合做大范围屏蔽比如整幅底图我只想看某一年的数据。查询图层ArcGIS Pro 里的 Make Query Layer会生成一个新的只读图层数据源还是原来的库适合在企业级数据库上做轻量取数。至于字段计算器里的表达式那又是另一回事它用的是 Python 或 VBScript不是 SQL语法体系完全不同——这一点我见过太多人搞混在字段计算器里写LIKE %村%然后报错跑来问我为什么按属性选择能跑。记住一条SQL 表达式管选哪些字段计算器管改成什么两边不通用。2. 公式写不对八成是这几个语法细节没搞清先把底层规则讲透后面 100 条公式才不会照抄照错。属性查询的语法看起来简单实际是个方言混杂区——ArcGIS 本身不解析 SQL它把表达式转给底层的数据库去执行File Geodatabase 交给自己的引擎shapefile 走 dBase企业级数据走 SQL Server 或 PostgreSQL所以同一句话在不同地方表现不同。2.1 数据源不同字段界定符完全不同这个是最典型的翻车点。同一个字段DLMC不同数据源写法如下数据源类型字段界定符示例Shapefile双引号DLMC 耕地File Geodatabase不加任何符号加双引号也能跑DLMC 耕地Personal GeodatabaseAccess方括号[DLMC] 耕地SQL Server / PostgreSQL双引号或按库规范DLMC 耕地我在 ArcMap 里试过一个坑从网上抄来的公式带双引号粘到 File GDB 上照跑不误但粘到个人地理数据库上直接报表达式无效。反过来也一样。所以看到别人的公式先看对方用的是什么数据源再决定要不要改界定符。字段名里带空格、带中文、或者撞上数据库的保留字比如DATE、LENGTH、ORDER时界定符是必须加的这个没有偷懒的余地。中文别名尤其要注意有些版本的 ArcGIS 对全角括号、全角引号零容忍最好一开始就用拼音字段名。2.2 值的写法由字段类型决定判断标准只有一条看字段到底是数值型还是文本型还是日期型。数值型短整型、长整型、浮点、双精度值不加任何引号MJ 1000。加了引号MJ 1000有的数据源能自动转换有的直接报类型不匹配。文本型值必须用英文单引号包起来DLMC 耕地。注意是单引号不是双引号双引号是给字段名用的。日期型这块最麻烦后面 3.3 节单独讲File GDB 用date YYYY-MM-DDAccess 用#YYYY-MM-DD#企业库用YYYY-MM-DD。还有一个隐蔽的坑文本型字段里存数字。比如行政区代码存在文本型字段里你写XZQDM 330100就会出问题必须写成XZQDM 330100。反过来数值型字段想按前两位筛选得先用SUBSTRING转字符串——但注意很多 SQL 引擎不允许在WHERE里直接对数值做字符串函数这时候要么改成文本字段要么就别用 LIKE。2.3 通配符与操作符速查通配符这块File GDB 和 Personal GDB 是两套规则这是最容易被忽略的语义File GDB / 企业库Personal GDBAccess匹配任意多个字符%*匹配单个字符_?模糊包含LIKE %田%LIKE *田*匹配固定两位LIKE 3301__LIKE 3301??常用操作符列一下等于、不等于、比较、LIKE模糊、IN集合、BETWEEN ... AND ...区间包含两端这个务必记住、IS NULL/IS NOT NULL判空、ANDORNOT逻辑组合。提示BETWEEN 100 AND 200等价于 100 AND 200两端都是闭区间。我见过有人以为它是开区间结果边界值总漏掉。还有一点SQL 里的字符串比较大小写敏感与否取决于底层数据库。File GDB 默认区分大小写企业库通常也区分。如果你不确定目标数据源的行为最省事的做法是两边都套上UPPER()或LOWER()兜底比如UPPER(DLMC) GRASSLAND虽然会牺牲一点索引性能但结果稳定。3. 100个属性查询公式按场景分组整理下面这 100 条我按使用频率和场景分组。字段名用的是常见的国土/规划类命名习惯DLMC地类名称、DLBM地类编码、MJ面积、XZQDM行政区代码、QSDWMC权属单位名称、YXRQ影像日期、Shape_Area、Shape_Length这些你套到自己数据里改个名就行。所有示例默认针对 File Geodatabase其他数据源按第 2 章的规则调整界定符和通配符。3.1 数值型字段范围、精度与异常值筛查数值字段的查询看着最没技术含量实际最考验细心程度。因为数值字段往往承载着面积、长度、代码、年份这些关键信息一旦比较逻辑写错筛出来的结果就是错的而且错得很隐蔽——不会报错只会悄悄漏掉或者多出记录。比如BETWEEN的闭区间特性、浮点数的精度问题、负数遗漏问题都是常见的坑。-- 1. 大于指定值 MJ 10000 -- 2. 大于等于且小于等于等价于 BETWEEN MJ 500 AND MJ 2000 -- 3. 区间筛选含两端 MJ BETWEEN 500 AND 2000 -- 4. 排除某个值 DLBM 101 -- 5. 等于指定编号 OBJECTID 1024 -- 6. 多值集合 DLBM IN (101, 102, 103) -- 7. 排除多值集合 DLBM NOT IN (101, 102) -- 8. 筛选零值 MJ 0 -- 9. 筛选负值异常数据排查 MJ 0 -- 10. 空值风险下的安全比较先排除空值再比大小 MJ IS NOT NULL AND MJ 1000 -- 11. 浮点数按精度比较 ROUND(MJ, 2) 1234.56 -- 12. 绝对值筛选 ABS(MJ) 100 -- 13. 向下取整定位 FLOOR(MJ) 500 -- 14. 向上取整定位 CEILING(MJ) 501 -- 15. 平方关系如长度平方 POWER(LEN, 2) 1000000 -- 16. 开方筛选 SQRT(MJ) 10 -- 17. 比值筛选如建筑密度 MJ / Shape_Area 0.9 -- 18. 倍数关系不同单位换算后筛选 MJ * 15 10000第 11 条要特别注意浮点数在计算机里不是精确存储的1234.5599999和1234.56在肉眼看来一样直接比较可能匹配不上。用ROUND()把它固定到你要的小数位再比才稳。第 12 条用ABS()也是同理处理那些可能存成负值的面积数据。第 17 条这种字段间比值比较特别有用比如查建筑面积占图斑面积超过 90%的地块一条公式就出来了。但注意除法有除零风险如果Shape_Area可能存在 0最好补一句Shape_Area 0 AND。3.2 文本型字段模糊匹配、前后缀与编码筛查文本字段是属性查询的主战场。地类名称、单位名称、备注、证件编号全是文本。这里的核心是LIKE加通配符的组合以及SUBSTRING、CHAR_LENGTH这类函数。-- 19. 精确匹配 DLMC 耕地 -- 20. 排除精确值 DLMC 耕地 -- 21. 前缀匹配 DLMC LIKE 耕地% -- 22. 后缀匹配 DLMC LIKE %田 -- 23. 包含匹配 DLMC LIKE %耕% -- 24. 定长匹配两个字符且首字为耕 DLMC LIKE 耕_ -- 25. 大写归一后比较 UPPER(DLMC) GRASSLAND -- 26. 小写归一后包含匹配 LOWER(DLMC) LIKE %road% -- 27. 按字符长度筛选 CHAR_LENGTH(DLMC) 2 -- 28. 长度超限排查 CHAR_LENGTH(DLMC) 4 -- 29. 截取前两位比较 SUBSTRING(DLMC, 1, 2) 耕地 -- 30. 首尾带空格排查 TRIM(DLMC) DLMC -- 31. 尾部残留空格 DLMC LIKE % -- 32. 首部残留空格 DLMC LIKE % -- 33. 单位名称后缀匹配 QSDWMC LIKE %村委会 -- 34. 单位名称前缀匹配 QSDWMC LIKE 杭州市% -- 35. 多值集合匹配 DLMC IN (耕地, 园地, 林地) -- 36. 多值排除 DLMC NOT IN (耕地, 园地) -- 37. 等价多值的手写写法 DLMC 旱地 OR DLMC 水田 -- 38. 组合条件 DLMC LIKE %田 AND DLBM 101 -- 39. 排除包含特定词的记录 ZLMC NOT LIKE %临时% -- 40. 编码首字符筛选 SUBSTRING(DLBM, 1, 1) IN (1, 2)第 24 条那个_通配符实际用起来比想象中有用。比如查两个字且以水开头的地类LIKE 水_一下就出来比写一堆OR清爽。但如果你要匹配的字符本身就是%或_那就得转义而 ArcGIS 对转义的支持在各数据源之间不一致遇到这种需求我一般宁可在字段计算器里处理不在查询里死磕。第 30 条是我自己用得最多的一条脏数据检查公式。数据从 Excel 导入、从 CAD 转换、从其他系统对接过来尾巴上带空格的字段特别多肉眼看不出但一比较就匹配不上。TRIM(DLMC) DLMC一条下去所有带空格的记录全露馅。第 40 条针对的是地类编码第一位是 1 或 2这类需求前提是DLBM得是文本型字段。如果它是数值型就得换思路或者先建个计算字段把它转成文本。3.3 日期型字段按月、按季度、按时段筛选日期是属性查询里最容易翻车的类型没有之一。原因有两个一是各数据源对日期的字面量写法不统一二是日期字段可能带时间部分导致等于某一天这种看似简单的需求变得复杂。File Geodatabase 推荐写法是date YYYY-MM-DD也可以带时间date YYYY-MM-DD HH:MM:SS。个人地理数据库用#2024-01-01#。企业级数据库直接写2024-01-01。-- 41. 某天之后 YXRQ date 2024-01-01 -- 42. 与当前日期比较 YXRQ CURRENT_DATE -- 43. 年度区间筛选 YXRQ BETWEEN date 2024-01-01 AND date 2024-12-31 -- 44. 按年份提取 EXTRACT(YEAR FROM YXRQ) 2024 -- 45. 按月份提取 EXTRACT(MONTH FROM YXRQ) 6 -- 46. 按日提取 EXTRACT(DAY FROM YXRQ) 15 -- 47. 季度筛选3-5月 EXTRACT(MONTH FROM YXRQ) IN (3, 4, 5) -- 48. 时间下限排查清理历史数据 YXRQ date 2000-01-01 -- 49. 日期空值排查 YXRQ IS NULL -- 50. 精确到时刻的匹配 YXRQ date 2024-06-01 08:30:00 -- 51. 按小时筛选 EXTRACT(HOUR FROM YXRQ) 12 -- 52. 跨年跨月的组合筛选 EXTRACT(YEAR FROM YXRQ) 2020 AND EXTRACT(MONTH FROM YXRQ) 6 -- 53. 日期存成文本时的模糊匹配 SJ LIKE 2024-06% -- 54. 更新时间的合法区间 GXSJ date 2020-01-01 AND GXSJ CURRENT_DATE -- 55. 每月1号的记录 EXTRACT(DAY FROM JCRQ) 1 -- 56. 已填写且非默认值的日期 XZRQ IS NOT NULL AND XZRQ date 1900-01-01第 50 条我特意留在这里做个提醒很多日期字段实际存的是时间戳带时分秒。你写YXRQ date 2024-06-01如果底层存的是2024-06-01 08:30:00那这一条根本匹配不上。解决办法要么用区间 date 2024-06-01 AND date 2024-06-02要么用EXTRACT把年月日拆出来比。第一种写法更推荐因为它能走索引速度快。第 56 条那个date 1900-01-01是很典型的占位默认值。数据从老系统迁移过来日期没填的地方经常被塞成 1900 年或者 1970 年用一条公式把它们和真正的空值一起筛出来是个好习惯。3.4 空值与脏数据NULL、空串、零值不是一回事这一节单独拎出来是因为没有值在数据库里至少有四种表现形式NULL真·空、空字符串、纯空格 、以及业务意义上的零值或默认值。它们互相之间不相等IS NULL匹配不到空串 也匹配不到NULL这是 SQL 的三值逻辑决定的。-- 57. 真·空值 DLMC IS NULL -- 58. 非空 DLMC IS NOT NULL -- 59. 空字符串 DLMC -- 60. 纯空格或空串去空格后无内容 CHAR_LENGTH(TRIM(DLMC)) 0 -- 61. 面积缺失或非正 MJ IS NULL OR MJ 0 -- 62. 面积为零 MJ 0 -- 63. 行政区代码有但权属代码缺失 XZQDM IS NOT NULL AND QSDWDM IS NULL -- 64. 状态字段未填写 YXZT IS NULL -- 65. 日期未填写 YXRQ IS NULL -- 66. 几何面积未计算 Shape_Area IS NULL -- 67. 非空的另一种写法逻辑等价 NOT (DLMC IS NULL) -- 68. 几何面积无效排查 Shape_Area IS NULL OR Shape_Area 0第 60 条是我个人最推荐的空值检查写法。因为数据来源一多你根本不知道这列是被填成了NULL还是还是几个空格用CHAR_LENGTH(TRIM(字段)) 0一次性全覆盖比你写三个OR靠谱得多。第 68 条这种Shape_Area 0的检查在数据入库质检里属于必查项。几何面积为零通常意味着这个要素的几何有问题——可能是空几何、可能是自相交导致的退化、也可能是投影问题。查出来之后别急着删先看看几何本身长什么样。3.5 多条件组合与括号优先级条件一多括号就成了生死线。SQL 的运算优先级是NOTANDOR也就是说A OR B AND C会被解析成A OR (B AND C)而不是(A OR B) AND C。这两种结果差得很远。我的习惯是——只要出现OR就给所有条件加上括号宁可多敲几个字符也别让结果悄悄跑偏。-- 69. 两个条件同时满足 DLMC 耕地 AND MJ 1000 -- 70. 满足其一即可 DLMC 耕地 OR DLMC 园地 -- 71. 取反 NOT DLMC 耕地 -- 72. 先或后与务必加括号 (DLMC 耕地 OR DLMC 园地) AND MJ 1000 -- 73. 先与后或 DLMC 耕地 AND (MJ 1000 OR Shape_Area 5000) -- 74. 满足前者且不满足后者 DLMC 耕地 AND NOT DLBM 101 -- 75. 两组条件各自成组 (DLMC 耕地 OR DLMC 园地) AND (XZQDM LIKE 3301% OR XZQDM LIKE 3302%) -- 76. 三条件串联 DLMC 耕地 AND MJ 1000 AND XZQDM LIKE 33% -- 77. 三条件择一 DLMC 耕地 OR DLMC 园地 OR DLMC 林地 -- 78. 整体取反德摩根定律 NOT (DLMC 耕地 OR DLMC 园地) -- 79. 与非的等价写法 NOT (DLMC 耕地 AND MJ 1000) -- 80. 两两组合 (DLMC 耕地 AND MJ 1000) OR (DLMC 园地 AND MJ 500) -- 81. 主条件加细分 DLMC 耕地 AND (MJ 1000 OR Shape_Area 5000) AND XZQDM LIKE 33% -- 82. 排除法的多条件版本 NOT DLMC 耕地 OR NOT MJ 1000第 78 条和第 82 条都涉及德摩根定律NOT (A OR B)等价于NOT A AND NOT BNOT (A AND B)等价于NOT A OR NOT B。听起来绕但实际工作中很有用——有些数据源对整体取反的括号支持不好换成展开形式就能跑。第 82 条就是NOT (DLMC 耕地 AND MJ 1000)的展开版。3.6 几何与系统字段Shape_Area、Shape_Length、OBJECTID这类字段平时容易被忽略但它们在做数据质检的时候非常好用。Shape_Area和Shape_Length是系统自动维护的跟几何形状严格对应用它来筛碎图斑狭长图斑超大面积图斑都特别顺手。OBJECTID是要素的唯一标识用来定位具体某几条记录。-- 83. 大面积图斑 Shape_Area 10000 -- 84. 面积区间 Shape_Area BETWEEN 1000 AND 5000 -- 85. 短边线要素 Shape_Length 10 -- 86. 按对象标识定位 OBJECTID 1000 -- 87. 狭长形态初筛周长与面积之比 Shape_Length / Shape_Area 0.01 -- 88. 碎图斑筛查 Shape_Area 100 -- 89. 零面积几何 Shape_Area 0 -- 90. 指定若干对象标识 OBJECTID IN (1, 5, 9, 20) -- 91. 大面积且长周长 Shape_Length 1000 AND Shape_Area 100000 -- 92. shapefile 的 FID 范围 FID 0第 87 条这个周长除以面积的比值是我做狭长图斑初筛时常用的土办法。比值越大形状越细长。但它只是个粗筛真正的狭长判断还得结合尖锐角检查那类工具来做——属性查询负责缩小范围几何工具负责精确判定两步走的效率比一上来就全量跑几何算法高得多。第 88 条查碎图斑也是同理先圈出来再决定是合并还是删除。第 89 条查零面积几何这个在数据合并、坐标转换之后特别容易出现。有些要素在转换过程中几何退化了属性表里还留着记录但面积算出来是 0画在地图上也看不见。用这条筛出来要么修复几何要么删掉。3.7 面向业务的组合公式地类、图斑、权属最后一组是我在实际项目里攒下来的组合公式特点是条件多、跨字段、贴近真实业务规则。这类公式没法通用但思路可以复用——把你脑子里的业务规则翻译成字段之间的逻辑关系。-- 93. 一级地类为 01 且面积达标的图斑 DLBM LIKE 01% AND MJ 100 -- 94. 指定行政区内的耕地和园地 XZQDM LIKE 3301% AND DLMC IN (耕地, 园地) -- 95. 耕地园地中大面积的图斑 (DLMC 耕地 OR DLMC 园地) AND Shape_Area 5000 -- 96. 村级的、2015 年之前的影像 QSDWMC LIKE %村% AND YXRQ date 2015-01-01 -- 97. 地类和面积都完整填写的记录 DLMC IS NOT NULL AND MJ IS NOT NULL AND MJ 0 -- 98. 四位行政区代码内、中等面积图斑 XZQDM LIKE 3301__ AND MJ BETWEEN 100 AND 1000 -- 99. 编码集合 面积 行政区三重筛选 DLBM IN (101, 102, 103) AND Shape_Area 2000 AND XZQDM LIKE 33% -- 100. 田类地类、有面积、限定时间段的完整筛选 MJ 0 AND DLMC LIKE %田 AND YXRQ BETWEEN date 2010-01-01 AND date 2020-12-31第 93 条用的LIKE 01%是个很实用的技巧地类编码通常是分级编码前两位代表一级类、前四位代表二级类用前缀匹配能一次性圈出整个大类不用把子类一个个列出来。前提是编码字段得是文本型或者能被当作文本处理。第 98 条那个LIKE 3301__里的双下划线表示3301 后面还有恰好两位也就是五位行政区代码。如果你写成LIKE 3301%就会把六位、九位的代码也一起匹配进来结果完全不一样。第 100 条是典型的多重业务约束实际工作中这种公式往往是从一段需求文档翻译过来的面积大于零、地类名字里有田、影像日期在某个十年区间内。翻译的原则是一个约束对应一个条件条件之间用 AND 连接涉及或者关系的用小括号圈起来。4. 查到之后怎么用从选择到导出的完整衔接公式敲完、点确定、要素被选中这只是开始。真正产生价值的是选完之后的那几步操作。很多人卡在这一环选是选出来了但不知道下一步该干嘛或者用了错误的方式处理导致数据丢失、属性错乱。4.1 选出来的要素怎么变成新数据最直接的做法是导出数据。右键图层 → 数据 → 导出数据选导出所选要素得到一个只包含筛选结果的新要素类。注意导出时坐标系统有个选项默认是数据源的坐标系如果目标环境用别的坐标系在这里顺手改掉能省很多事。第二个做法是在选区基础上继续裁剪。比如你有一个全省的矢量图层和一个县界图层先用属性把县界选出来再用裁剪工具把全省数据切到该县范围内。这个流程比先按位置选再裁剪更可控因为按属性选的县界不会因为你地图比例尺变了而选错。第三个做法是批量编辑。选中之后打开属性表右键某个字段 → 字段计算器对整批记录统一赋值。比如把选出来的所有图斑的状态字段改成已核查一条计算就完成不用一条条改。这里要注意字段计算器操作的是当前选择集如果你忘了先做选择它会把整个图层的值全改了这个错误很难撤销。4.2 用表达式驱动显示和出图定义查询是出图场景里最好用的东西。一幅图几万个图斑全画出来不仅卡符号还会挤成一团——你可能遇到过地类符号太密的问题符号压符号什么都看不清。解决思路之一就是用定义查询把图层按类别拆开比如把耕地做成一个图层、园地做成一个图层每个图层单独调符号密度和显示比例尺范围。具体做法是给每个图层加定义查询公式就是前面那些条件比如耕地图层写DLMC 耕地园地图层写DLMC 园地。这样每个图层的符号系统可以独立设置符号大小、偏移、注记密度都能分开调出图效果干净很多。而且被过滤掉的要素不参与渲染滚动缩放的时候明显更流畅。需要提醒的是定义查询是永久生效的它会一直跟着图层走保存文档后重新打开也还在。如果你只是临时想看某一部分数据用按属性选择更合适别随便动定义查询。检查图层有没有被过滤看图层名后面有没有一个小漏斗图标就行了。4.3 把常用公式沉淀成自己的模板公式这东西敲一次就够了敲第一百次就是浪费生命。ArcMap 里按属性选择对话框下方有一排按钮可以把当前表达式保存成文件扩展名是.exp下次从同一位置加载回来就能用。ArcGIS Pro 里没有直接对应的保存按钮但可以建查询图层或者定义查询把它留在工程里。我自己的做法是维护一个纯文本的公式清单按项目分类每条前面写一行注释说明用途。比如筛碎图斑Shape_Area 100、筛空值CHAR_LENGTH(TRIM(DLMC)) 0用的时候搜关键词复制过来改字段名就行。这个习惯坚持了几年现在处理新项目的质检环节基本半小时能把全套检查跑完。如果你手上项目多还可以把公式按数据源分成几个文件——File GDB 一份、企业库一份避免界定符和通配符搞混。文件命名上用项目名_检查类型.txt这种格式找起来快。5. 报错与慢查询我踩过的坑最后这部分是纯经验。语法规则书上都有但这些报错和性能问题只有真正在项目里摔过跟头才知道。5.1 常见报错速查表报错提示大概率原因解决方向未找到列 / Invalid column name字段界定符用错或字段名拼写不符检查数据源类型shapefile 加双引号Access 加方括号SQL 表达式无效 / 语法错误引号用了中文全角或括号不配对关掉输入法重敲引号逐个核对括号参数类型不匹配数值字段的值加了引号或文本字段的值没加引号核对字段类型数值裸写、文本加单引号值太长 / String truncatedLIKE 模式里的引号不闭合导致整段文字被当成一个值检查LIKE %田这类语句是否缺了右边的引号日期格式无效日期写法跟数据源不匹配File GDB 用date ...Access 用#...#查询返回空结果但不报错大小写不一致或字段值带首尾空格用UPPER()归一或先跑一遍 TRIM 检查中文变乱码编码不匹配多见于 shapefile 的属性表检查 dbf 的编码设置或改用 File GDB 存储找不到字段但属性表里明明有字段名是数据库保留字或含空格加界定符或改用别名这里面最常见的是中文全角引号。从网页或者 Word 文档里复制公式引号经常变成和ArcGIS 完全认不出来。我踩过好几次盯着屏幕看半天觉得没毛病最后发现是引号的问题。所以我的习惯是粘过来的公式一律先用英文输入法把引号重新敲一遍。另一个高频坑是保留字。字段名叫DATE、NAME、ORDER、LENGTH、YEAR这些在某些数据库里不加界定符会解析失败。系统的报错一般会说未找到列让人一头雾水——明明字段就在那儿。解决办法就是给字段名加上界定符或者干脆在数据设计阶段就避开这些词。5.2 慢查询的几个优化方向属性查询在数据量小的时候感觉不出来一到十万级以上的要素慢的能让人怀疑人生。我自己总结下来慢的原因基本集中在这几个地方。第一LIKE 用了前置通配符。LIKE %村%这种写法数据库没办法用索引必须逐行扫描十万条数据扫下来就是几秒。如果业务上允许改成后缀匹配LIKE 杭州市%或者用IN列枚举值速度能差一个数量级。实在要用前置通配符就先把数据按其他条件缩到一个小范围再做模糊匹配。第二属性索引没建。File Geodatabase 和 shapefile 都可以给字段建属性索引在图层属性里能找到。经常用来做筛选的字段——比如地类编码、行政区代码、日期——建上索引查询速度提升很明显。代价是数据编辑会稍微慢一点索引需要维护但对以查询为主的数据来说完全值得。第三先空间后属性的顺序反了。如果你的筛选既要满足空间范围又要满足属性条件正确的顺序是先用空间范围把数据砍小再用属性条件精筛。因为空间筛选通常能砍掉 90% 以上的数据剩下的再做属性判断就快了。反过来先做属性、再叠空间等于对全量数据跑两遍。第四用错了入口。定义查询和按属性选择虽然公式一样但执行方式不同。定义查询是渲染层面的过滤每次重绘都会重新执行按属性选择是一次性的选完就固化了。数据量特别大的时候我更倾向于先用按属性选择把要素选出来导出成临时图层再对临时图层做后续操作。5.3 几个容易被忽略的实操细节关于选择集的传递性。按属性选择出来的结果会被后续的很多工具继承。比如你选了一批要素然后去跑裁剪工具如果没注意底下的输入要素是哪个图层工具可能只处理你选中的部分也可能处理全部取决于那个工具的默认行为。这个坑我踩过不止一次明明只想处理一个县结果整个市的数据都被重算了。养成习惯跑工具之前先看一眼有没有活动选择集。关于字段类型的隐性转换。有时候公式在 A 数据源上跑得通换到 B 就报类型错误原因往往是同一个字段在两边的类型不一样。比如从 CAD 转过来的数据面积字段可能是文本型你按数值比较就会失败。遇到这种情况别急着改公式先确认字段类型必要时用字段计算器新建一个数值字段。关于表达式里的空格。MJ1000和MJ 1000大多数情况都能跑但涉及字符串拼接或者函数嵌套时缺空格会引发解析错误。我的习惯是运算符两边一律加空格函数参数逗号后面也加空格写的时候多敲几下调试的时候能少花半小时。关于多用户环境。企业级数据库上的属性查询如果你的账号权限不够可能查不到某些记录但不会报权限错误——数据就是凭空少了一些。这个现象排查起来非常费劲因为公式本身没问题。如果发现查询结果跟预期对不上先确认一下自己账号的权限范围。关于查询结果的顺序。属性查询返回的记录顺序是不确定的除非你显式指定排序。所以不要假设第一条就是最新的涉及顺序的处理一定要另外加排序字段。我在实际项目里的体会是属性查询这套东西语法门槛其实很低真正的门槛在于对数据本身的理解——知不知道字段里存的是什么、有没有脏数据、边界值怎么处理。同样一条公式理解数据的人写出来能用三年不理解的人写完第二天就发现漏了一半记录。所以每次接手新数据我都会先花二十分钟看看字段类型、抽几条看看值的形态、跑一遍空值和异常值检查然后再动手写筛选逻辑。这个习惯帮我省下的返工时间远比那二十分钟多得多。
