简介ArcGIS DataReviewer 10.2 是 Esri 面向 GIS 数据质检环节推出的专业工具适用于测绘、国土、城市规划等领域中需要把控成果质量的从业者与中高级 GIS 学习者。它覆盖三类检查在空间位置上检测坐标精度、要素重叠或缺失、边界匹配在属性层面校验格式规范、空值与重复值、字段间逻辑关系在拓扑层面识别未闭合线段、越界穿越、孤立点等问题。工具支持自定义规则、批量任务并提供脚本与 API 接口可与既有工作流衔接实现自动化质检团队协作与质检报告输出也一并提供。 压缩包共 157 个文件、约 76.22MB以 png、gif、jpg 等界面截图与图标素材为主并配有由 js、css、htm 搭建的帮助文档与交互页面另有 xml 配置、exe、msi、cab 安装组件及 db、ini 支撑文件。借助这套材料读者可对照了解质检规则的组织方式、批处理任务的配置思路与报告字段构成为项目中的数据质量管控提供参照。目前已有 1231 人学习下载。1. 一个 zip 能顶半个质检岗dataReviewer 在 ArcGIS 里补的是哪块短板交付数据前最难受的一步不是图画不出来而是明知道图层里藏着悬挂点、重叠面、重复要素和空属性却只能靠人眼一屏一屏翻。dataReviewer 这套 arcgis 质检扩展的价值在于把发现问题变成留下可回查的记录校验跑完不是出一张截图而是往一个独立的结果库里写记录每条问题带位置、带严重性、带复核状态谁改的、改没改掉都追得回来。这个 zip 是 10.2 版本的扩展安装包适合还在 ArcMap 体系里做数据生产、需要把质检从人工翻图改成流程化复核的人。只偶尔查几个重复要素拓扑规则就够了一旦交付要留痕、返工要统计、多人要分工复核这套东西才开始回本。2. 装得上、跑得动10.2 环境下的安装与许可落地拿到压缩包先别急着双击。这类扩展包能不能用八成取决于安装前那十分钟的环境清点而不是安装过程本身。下面按版本对齐 → 许可启用 → 建结果库三步走每一步都给可验证的动作装完能立刻判断是成功还是埋了雷。2.1 安装前的版本清点三个必须对齐的号Data Reviewer 是挂在 ArcGIS Desktop 上的扩展它跟主程序的版本咬得很死。10.2 的扩展装在 10.2.1 上一般没事装在 10.2.2 上就可能出现工具条能显示、按钮点下去报错的情况反过来把高版本扩展往低版本主程序上装安装程序往往会直接拦下来。清点时盯住三个号桌面端主版本号、补丁号Service Pack、以及 Python 版本10.2 自带的是 Python 2.7.x写脚本时别拿 Python 3 的语法去试。最省事的确认方式不是翻安装包而是直接问已经装好的机器# -*- coding: utf-8 -*- import arcpy # 打印桌面端版本、补丁号与许可级别先确认主环境 info arcpy.GetInstallInfo() print(产品: {0}.format(info[ProductName])) print(版本: {0}.format(info[Version])) print(补丁: {0}.format(info.get(SPNumber, 未打补丁))) print(安装路径: {0}.format(info[InstallDir])) print(许可级别: {0}.format(arcpy.ProductInfo())) # ArcInfo / ArcEditor / ArcView这段代码的作用是把我以为的版本变成实际的版本。ProductName会告诉你装的是 Desktop 还是 EngineVersion精确到小数点后一位SPNumber缺省时说明补丁没打全。许可级别那一行很关键——Data Reviewer 的部分校验能力对许可级别有要求ArcView 级别下能跑的规则集比 ArcInfo 少提前知道能省掉后面为什么这个检查项是灰的的排查。提示如果机器上同时装过多个版本的 DesktopGetInstallInfo返回的是当前 Python 绑定的那一套不一定是你 ArcMap 正在跑的那一套。稳妥做法是在 ArcMap 的关于里再核一次版本号两边对上了再动手安装。2.2 许可与扩展启用勾选框背后的两套授权安装程序跑完很多人第一反应是打开 ArcMap 找工具条找不到就以为装失败了。实际上这里有两道门第一道是扩展许可有没有授权第二道是扩展有没有在应用里被勾选。两道门任意一道没开工具条都不会正常出来。第一道门在许可管理端。Data Reviewer 属于单独计费的扩展单机版需要在授权管理工具里导入对应的扩展授权文件浮动版则要确认服务端确实分配了该扩展的许可。这一步失败的表现很统一扩展能勾上但一执行校验就提示许可不可用或者干脆勾选框是灰的。第二道门在应用内。打开 ArcMap走自定义 → 扩展在列表里找到 Data Reviewer 并勾选工具条才会加载。这里有个血泪经验勾选后一定要把 ArcMap 完全退掉再重开光关文档不关程序工具条有时候只加载一半按钮图标是空的。命令行侧可以用一段脚本快速验证扩展许可是否可用# -*- coding: utf-8 -*- import arcpy # 检查扩展许可扩展名字符串在不同版本里可能略有差异 # 若返回 Unavailable先在 ArcMap 的扩展列表里核对准确名称 for ext in [DataReviewer, Data Reviewer]: status arcpy.CheckExtension(ext) print({0} - {1}.format(ext, status)) if status Available: breakCheckExtension返回三种值Available表示可以检出Unavailable表示没授权或名称不对NotLicensed表示这台机器压根没这个扩展的授权。三种值对应三种处理路径不要一看到失败就去重装先分清是哪一种。检出成功之后记得配对使用CheckInExtension虽然脚本结束会自动释放但在循环里批量跑的时候不归还跑到第十几次就会卡住。2.3 建 Reviewer 工作空间gdb、mdb 还是 SDE结果库不是随便一个文件夹它是 Data Reviewer 自己建的一套表结构用来存校验结果、要素类索引和状态域。建库入口在 ArcCatalog 的 Data Reviewer 节点下也可以在 ArcMap 的工具条里直接建。选存储类型时别拍脑袋三种选择对应三种完全不同的使用场景。存储类型适用场景主要限制个人地理数据库.mdb单机、历史项目、要和旧数据放一起单库 2GB 上限依赖本机 Access 驱动位数路径含中文容易出问题文件地理数据库.gdb单人或两人小团队、日常质检不支持多人并发写两人同时提交结果容易锁表企业级数据库SDE多人分工复核、结果要长期沉淀需要数据库侧配合建库前要确认权限和版本绝大多数单机场景我建议直接用 .gdb别贪 .mdb 的兼容老环境。.mdb 的坑集中在驱动上机器上装了 64 位 Office 之后32 位 Access 驱动被顶掉建库那一步会报一个跟数据库毫无关系的驱动错误第一次遇到能查半天。.gdb 没有这个问题代价只是不能并发。建库时有个细节值得注意结果库和业务数据要分开放。见过不少项目把结果库和被检要素类塞进同一个 .gdb结果校验跑崩一次整个库一起进修复流程。分开之后最坏情况也只是丢质检记录业务数据不受牵连。建完库先别急着配规则用一条最简单的检查项跑通闭环确认能写进结果表这件事成立。这一步通了后面所有复杂配置才有意义这一步不通配一百条规则都是白费。3. 规则怎么定把看着不对翻译成可执行的校验项质检最容易犯的错是把业务语言直接当成规则。这个图层的数据质量不行不是规则面要素之间存在小于 0.5 米的缝隙才是。这一章解决的就是翻译问题先认清华检项的类别地图再抠单条规则的参数最后把散装规则固化成能重复执行的批次作业。3.1 校验项分类地图先选类别再选具体规则内置校验项按检查对象分了几大类选规则的正确顺序是先定位问题属于哪一类再在类里挑具体项而不是在长长的列表里从头翻到尾。下面这张表是我常用的归类方式按你要抓什么倒推该用哪类。想抓的问题对应类别典型校验项重复录入、同一位置两条记录要素间检查重复要素检查、要素重叠检查悬挂、断头、该接没接上线要素检查悬挂点检查、自相交检查、线段过短检查面之间有缝、有压盖面要素检查缝隙检查、重叠检查、面闭合检查属性空值、超范围、不符合域属性检查空值检查、属性域检查、属性范围检查几何本身就不合法几何检查无效几何检查、空几何检查、几何类型检查要素落在不该落的地方空间关系检查要素在要素内检查、要素不相交检查选类别的判断标准很简单问题能不能只看单个要素就发现能走属性或几何类不能必须两个以上要素比对才能发现走要素间或空间关系类。这个判断决定了后面参数怎么填——单要素检查基本不需要容差要素间检查几乎一定要容差。再补一个容易被忽略的类别元数据检查。很多交付要求图层必须带坐标系、必须填责任人、必须有更新时间这些都能用元数据类校验项自动卡住。它的价值不在于技术难度而在于把交付规范从文档里搬进了执行流程人不填就跑不过去。3.2 参数怎么填容差、过滤器与严重性分级单条规则配不配得准八成看三个参数容差、查询过滤器、严重性。前两个决定抓多少第三个决定抓出来怎么排序处理。容差是最容易翻车的地方。它用的是被检要素类的坐标系单位不是米。数据是地理坐标系单位是度时容差填 0.001 代表大约一百米填 0.00001 才接近一米数据是投影坐标系单位是米时0.001 就是 1 毫米。见过有人拿投影数据的经验值往经纬度数据上套结果缝隙检查跑出几十万条结果一条条看过去全是同一条边界被反复报。填容差前先确认坐标系这一步没有捷径。查询过滤器决定参与检查的要素范围。全表跑一次检查在大图层上可能几十分钟起步而实际需要质检的往往只是本次新增或修改的部分。常见的做法是加一个基于时间或批次号的条件只让增量数据进入检查。过滤条件写错的表现很隐蔽检查跑得飞快结果是零看着像数据很干净其实是压根没选中要素。严重性分级1 到 5是用来排优先级的不是用来决定报不报。我的习惯是几何不合法、坐标系错误这类会直接导致下游系统崩掉的问题给 1重复要素、属性空值这类影响业务但不致命给 2 到 3命名不规范、元数据缺失给 4 到 5。分级的真正用途在于结果导出之后业务方能按级别分批处理而不是一次性看到几千条记录直接放弃。注意严重性只在结果记录上打标记不会自动改变复核状态。别指望设成 1 就自动拦截入库拦截逻辑得自己在入库流程里按严重性写判断。3.3 批次作业把散装校验固化成可重复任务规则配好之后如果每次都手动一条条点执行这套东西基本用不过三次。批次作业Batch Job就是来解决重复劳动的把若干条校验项按顺序打包成一个任务命名、保存下次一键跑完。组织批次作业有两个原则。一是按检查目的分组不要按规则类别分组。比如入库前几何体检一个作业里面放无效几何、空几何、自相交、面闭合交付前属性体检另一个作业里面放空值、属性域、元数据。这样出问题时能快速定位是哪一关没过。二是控制单个作业的规则数量十几条以内比较合适太多的话中途某条报错前面跑完的结果要不要留、怎么续跑都很别扭。批次作业里规则的执行顺序也有讲究。几何类的检查放前面因为几何不合法会让后面的空间关系检查结果失真——一个自相交的面去参与重叠检查报出来的重叠可能完全是几何错误引起的假阳性。属性类检查放最后它最便宜也最不容易受前序影响。保存批次作业时一部分版本会把定义存进 Reviewer 工作空间一部分支持导出成独立的作业文件。后者更适合纳入版本管理改了什么、谁改的跟着代码库一起留痕。这一步看着琐碎但等你要复盘上个月质检为什么漏了一批数据有没有这份历史定义就是能不能查清的分水岭。4. 结果怎么管结果表结构、状态流转与导出交付校验跑完只是开始。结果库里的记录如果没人处理它跟一张截图没区别。这一章讲三件事结果表到底长什么样、状态怎么流转、以及怎么把这些记录变成业务方能看的东西。4.1 结果表长什么样三张几何表加一张索引表结果库不是一张大表而是按几何类型分开存点问题进REVTABLEPOINT线问题进REVTABLELINE面问题进REVTABLEPOLYGON。这个设计的好处是每条记录都能直接带几何打开就能定位坏处是统计总量时必须三张表一起查只查一张会漏。关键字段不多但每一个都得认识字段含义使用要点CHECKTITLE校验项名称统计时按它分组能看出哪类问题最集中ORIGINCHECKTITLE原始校验项规则被改名后靠它追溯历史SEVERITY严重性 1 到 5排序和分批处理的依据REVIEWSTATUS复核状态编码整数编码具体取值以库里的状态域为准NOTES备注复核人写处理说明的地方别浪费要素类关联字段指向要素类索引表不要硬编码通过索引表翻译成要素类名状态字段是这套东西的核心。它是一个整数编码取值含义由工作空间里的状态域定义不同版本、不同建库方式可能有细微差别。上手第一件事是把域打开看一眼确认哪个值代表未复核、哪个代表已复核、哪个代表例外。查询统计用 SQL 最快不用打开桌面端-- 按校验项和严重性统计未复核问题快速看出问题集中在哪 -- REVIEWSTATUS 的取值以库内状态域为准此处 2 代表尚未复核完成 SELECT CHECKTITLE, SEVERITY, COUNT(*) AS CNT FROM REVTABLEPOINT WHERE REVIEWSTATUS 2 GROUP BY CHECKTITLE, SEVERITY ORDER BY CNT DESC;这段 SQL 的价值在于把感觉问题很多量化成重复要素 1832 条、空属性 240 条。GROUP BY两个字段而不是一个是因为同一个校验项在不同严重性下的处理优先级完全不同混在一起统计等于没统计。如果结果库是文件地理数据库用支持 SQL 的客户端连上去要装驱动嫌麻烦可以直接在 ArcMap 的表属性里做汇总或者用下面的 Python 版本。# -*- coding: utf-8 -*- import os import arcpy from collections import Counter ws rD:\qa\city_qa.gdb # Reviewer 工作空间 tables [REVTABLEPOINT, REVTABLELINE, REVTABLEPOLYGON] stat Counter() for name in tables: path os.path.join(ws, name) if not arcpy.Exists(path): continue # 该几何类型没有结果就跳过 with arcpy.da.SearchCursor(path, [CHECKTITLE, SEVERITY, REVIEWSTATUS]) as cur: for title, sev, status in cur: stat[(title, sev, status)] 1 # 按数量倒序打印前十条基本就是本次质检的主要矛盾 for (title, sev, status), cnt in stat.most_common(10): print({0:28} 严重性{1} 状态{2} 数量{3}.format(title, sev, status, cnt))arcpy.da.SearchCursor比老版SearchCursor快一个量级字段名写成列表、取值用元组解包这种写法在大表上差别很明显。arcpy.Exists那层判断不能省几何类型没结果时表可能压根不存在直接开游标会抛异常脚本跑到一半断掉。most_common(10)只是取前十实际排查时我一般会全量导出成 CSV 再排序控制在终端里刷屏没有意义。4.2 状态流转与分工谁复核、谁修正、谁验证多人协作时最容易乱的不是技术是职责。结果库里每条记录其实要经过三段复核确认这条到底是不是问题、修正处理改数据或标记例外、验证关闭改完之后问题确实没了。三段由不同人做状态才会干净。我的分工习惯是质检执行者只负责跑规则和初判把明显是假阳性的标成例外并写原因数据生产方负责修正改完不自己关状态只更新备注质量负责人做最后验证重新跑一遍校验确认记录不再出现才把状态推到已完成。这里有个反复踩的坑修正完直接在结果表里把状态改掉但没有重新执行校验。结果是记录显示已处理可实际数据里问题还在或者修 A 处引出 B 处新问题。正确做法是修正后重跑对应的批次作业让系统自己判断这条记录还存不存在。真正修干净的问题重跑之后不会再有新记录没修干净的会重新冒出来这才是可信的闭环。删除要素这条操作要特别小心。结果记录里存的是要素的对象 ID要素一旦被删除再重新导入ID 会重新分配旧记录就变成指向空气的孤儿。表现是点开记录定位不到要素或者定位到了完全不相干的另一个要素。处理方式有两种要么在修正阶段用属性更新代替删除重建要么在重建之后把上一轮的结果库整体归档不混用。4.3 导出与交付从结果库到 Excel 和 Shapefile结果最终要给人看而看的人未必有桌面端。导出分两条线走给管理方看统计给作业方看位置。统计线用表格。把三张结果表按校验项、严重性、状态汇总输出成 CSV 或 Excel附一列占比。别小看占比这一列它能直接回答这次质检的主要问题是什么——如果重复要素占了七成那说明问题出在数据采集环节而不是绘图精度。位置线用空间数据。把结果表导出成 Shapefile 或要素类按严重性做符号化1 到 2 级红色、3 级橙色、4 到 5 级灰色作业方打开就能按颜色优先级处理。导出时注意坐标系结果表可能用的是被检数据的坐标系如果交付要求统一到某个投影导出这一步就要做转换而不是等对方打开发现坐标对不上再返工。# -*- coding: utf-8 -*- import os import arcpy ws rD:\qa\city_qa.gdb out_dir rD:\qa\export if not os.path.isdir(out_dir): os.makedirs(out_dir) # 只导出未复核完成且严重性较高的记录避免交付一堆低优先级噪声 for name in [REVTABLEPOINT, REVTABLELINE, REVTABLEPOLYGON]: src os.path.join(ws, name) if not arcpy.Exists(src): continue out_fc os.path.join(out_dir, name _high.shp) where SEVERITY 3 AND REVIEWSTATUS 2 # 条件按项目实际状态编码调整 arcpy.FeatureClassToFeatureClass_conversion(src, out_dir, name _high.shp, where) print(已导出: {0}.format(out_fc))这段脚本的关键在where那一行。导出全部记录看着完整实际是把筛选工作推给了对方几千条记录里真正要处理的可能只有几十条。按严重性和状态做一次过滤交付物的可用性立刻不一样。Shapefile 单文件有 2GB 上限、字段名会被截断到 10 个字符如果结果表字段较多导出后要核对一遍字段有没有丢或者直接导成文件地理数据库里的要素类再打包。5. 避坑与排查五个真实翻车现场这套东西的坑集中在环境和数据两头中间配置环节反而相对稳定。下面五条按现象、原因、解决写都是能在半小时内定位的问题怕的是不知道往哪看。5.1 环境与许可类的三个坑坑一扩展勾上了工具条按钮全是灰的。现象是扩展列表里 Data Reviewer 打了勾重启之后工具条也出来了但新建工作空间、执行校验这些按钮点不动。原因基本是扩展许可没真正授权勾选只是加载了界面权限校验在点击时才触发。解决路径是先看许可管理端有没有这个扩展的授权记录浮动版还要确认服务端许可池没被占满确认授权没问题再检查主程序补丁号扩展和主程序补丁不匹配时也会出现界面正常、功能失效的组合。坑二建工作空间时报数据库驱动错误。现象是选了个人地理数据库点创建直接弹一个跟 Access 驱动相关的错误路径、权限看着都没问题。原因是机器上装过 64 位 Office把 32 位 Access 驱动顶掉了而桌面端是 32 位进程找不到匹配的驱动。解决方式要么修驱动要么直接换文件地理数据库——后者更省事也避开了 2GB 上限。这类错误的迷惑性在于报错文本完全没提 Data Reviewer第一次遇到容易往安装包坏的方向查。坑三两个人同时跑质检结果库报锁。现象是第一个人跑得好好的第二个人一提交就提示锁定或写入失败。原因是文件地理数据库不支持多人并发写两个人往同一个结果库里写记录必然冲突。解决方式是按人分库、事后合并或者直接上企业级数据库。分库合并时要注意状态编码必须一致否则合并出来的记录状态会错乱。5.2 规则与结果类的两个坑坑四缝隙检查跑出几十万条结果全是假阳性。现象是面要素的缝隙检查执行完结果表直接爆量点开一看全是同一条边界被反复报。原因几乎都是容差单位搞错了——数据是地理坐标系容差按米填了 0.5换算过去是半个地球。解决方式是先确认被检要素类的坐标系单位把容差换算成度再填宁可先填大一点跑一遍看量级再逐步收紧。收紧的过程要配合抽样检查每次调小一档就随机抽十条人工核对确认报出来的确实是问题而不是噪声。坑五修完数据结果记录还在状态却是已完成。现象是作业方反馈问题都改了打开结果库发现记录状态已经是完成但把对应位置放大看问题原样还在。原因是修正的人直接手工改了状态字段没有重新执行校验。解决方式是立规矩状态只能由重新校验的结果来推动人工只填备注。已经出现这种污染时处理办法是把这批记录的状态重置为未复核整批重跑一遍校验让系统重新判定。这件事的血泪教训是——结果库的状态字段一旦允许手工改整套质检的可信度就归零了。6. 从手动到流水线批次作业自动化与质检回归验证规则配顺、结果能看之后剩下的事就是让它自己跑。手动点鼠标的质检有个天花板只要执行成本高人就会找理由跳过跳过一次就有第二次。把批次作业接进流水线本质是把要不要质检这个决策从人手里拿走。第一条路是用地理处理工具串流程。批次作业定义好之后可以在模型构建器里把它和前置的数据转换、后置的结果导出串成一条链保存成工具箱里的一个工具。这条链的输入端是被检要素类输出端是结果库和导出的报表。串好之后用 Windows 任务计划在夜间触发第二天上班先看报表而不是先点按钮。这里要注意模型的中间数据落地位置全放内存里在数据量大时会直接崩中间结果落到临时地理数据库更稳。第二条路是用脚本做回归验证这一步很多人省掉但它是质检能不能长期可信的关键。做法很简单每次修正之后重跑同一批次作业把新一轮结果和上一轮做差集比对。理论上问题数应该单调下降如果出现修了 A 又冒出 B说明修正动作本身引入了新问题得回头查修正脚本或者编辑流程。# -*- coding: utf-8 -*- import os import arcpy ws rD:\qa\city_qa.gdb def load_keys(table): 读取结果表的定位键校验项 要素对象ID用于跨轮次比对 keys set() path os.path.join(ws, table) if not arcpy.Exists(path): return keys with arcpy.da.SearchCursor(path, [CHECKTITLE, FEATUREOBJECTID]) as cur: for title, fid in cur: keys.add((title, fid)) return keys before load_keys(REVTABLEPOINT) after load_keys(REVTABLEPOINT) new_issues after - before # 本轮新增说明修正引入了新问题 fixed before - after # 本轮消失说明确实修掉了 print(已消除 {0} 条新增 {1} 条.format(len(fixed), len(new_issues))) # 新增数量超过阈值就报警阻止继续入库 if len(new_issues) 20: raise SystemExit(新增问题过多疑似修正动作引入新错误已阻断)这段脚本的核心是两个集合的差。before - after是修掉的after - before是新冒出来的两个数字放一起看比单看剩余问题数有信息量得多。阈值那一行是最后的保险新增超过 20 条就中断流程宁可卡住也不要让一批带病数据流下去。字段名FEATUREOBJECTID在不同版本的结果表里可能略有差异跑之前先用字段列表核一遍别照抄。再补一个实用技巧把结果库按批次归档每轮质检新建一个工作空间命名带上日期和批次号。这样历史结果全部留着任何时候都能回答这批数据在某个时间点是什么状态。归档库不参与日常查询只在复盘和审计时打开既不影响性能又保住了追溯链。这套流程我踩过最贵的一次坑是在一个跨部门交付的项目里图省事让作业方自己改结果状态。三个月后对方质疑质检结论我打开结果库发现状态全是已完成但抽样一查问题还在——那一刻没有任何证据能证明质检真的执行过。从那以后我每次建完工作空间第一件事就是把状态字段的编辑权限收掉谁都不许手工改只能靠重跑校验来推动状态。这个习惯看着不近人情但它保住了整套流程的可信度也保住了我在评审会上说话的分量。希望帮到你。本文还有配套的精品资源点击获取
 并测得实打实的加速)
