图数对不上时，怎么把问题说清楚：土地供应双源质检实践
只发现问题、不改源库；主键、粒度、容差与图数联动
做土地供应数据治理时，最常见的投诉不是「程序跑不通」，而是：图上有、表上无；表上有、图上无；两边都有，字段却写得不一样。 甲方手里通常有一份 FileGDB（空间）和若干份 Excel 台账（业务），质检若只输出「不一致」三个字，复核人员仍然要在 GIS 和表格之间来回翻，效率极低。
我在一套土地供应双源质检工具里，把问题收成一句话：程序只负责发现与定位，不修改源 GDB、不修改源 Excel；把「谁和谁、哪一字段、差在哪里」写到能复核的粒度。 下文按业务人员也能读懂的顺序，讲清主键、问题粒度、规则分层、容差和图数联动——这些比「用了什么库」更值得留下来。
说明：文中不出现客户名、内部路径与不可访问的仓库链接；样例口径来自真实项目中的通用做法，数值阈值以当时甲方确认为准，换项目时必须可配置。
问题一览
| 痛点 | 错误做法 | 更稳的做法 |
|---|---|---|
| 图斑数多于台账行 | 按行号硬对齐 | 可配置主键关联，允许一对多 |
| 「不一致」刷屏 | 同一主键每个图斑各报一条 | 区分图斑级 / 主键级，组内冲突合并说明 |
| 全图一片红 | 固定阈值着色 | 按本次错误数分布分档（四分位） |
| 宽度、面积正常误差 | 一律当错误 | 相对容差（如 1‰）+ 人工审核出口 |
| 质检改坏源库 | 程序直接写回 | 只读；整改另走流程 |
一、先关联，再比对：主键必须可配置
双源一致性检查的前提是记录关联。关联不能依赖行号或当前排序——台账一排序、图斑一筛选，行号就失效了。
实践中更稳妥的是主键优先级列表，由业务人员在界面确认，而不是写死某一个字段。土地供应场景里，常见候选大致是：
- 电子监管号
- 供地标识
- 宗地编号
- 合同 / 划拨编号
顺序只是默认推荐。真正关键的是关联前做唯一性诊断，并写进日志：两侧总记录数、空主键、重复主键、一对一 / 一对多 / 多对一 / 多对多、仅单源存在、无法关联数量。没有这张「体检表」，后面所有「不一致」都会被质疑「是不是根本没对上」。
一对多不要直接判错。 一个供地项目对应多个图斑很常见。正确顺序是：
- 看同一主键下，GDB 多条记录在待核字段上是否彼此一致；
- 组内一致，再与 Excel 比；
- 组内已经多个非空值互相冲突，先报主键级冲突，写明各图斑取值，再继续与台账比对（标明谁与台账一致、谁不一致）。
程序不裁决哪一侧正确。整改口径可以业务约定「以台账为准」，但质检工具的职责是把冲突写明白，而不是替人改数。
二、四级问题粒度：别让复核猜「这条问题挂在谁身上」
若问题列表只有「有没有 OBJECTID」两种状态，界面就会开始猜。更干净的做法是显式四级粒度：
| 粒度 | 含义 | 典型例子 |
|---|---|---|
| 图斑级 | 只属于某一个 GDB 图斑 | 某图斑必填属性为空 |
| Excel 行级 | 只属于某一份表的某一行 | 某行批准日期晚于供地日期 |
| 主键级 | 属于同一主键整组 | 同主键属性冲突、图数不一致、仅单源存在 |
| 数据集级 | 属于字段结构或配置 | 缺标准字段、字段名不规范 |
粒度一旦进台账，地图、表格、问题列表才能各管一段：
- 点图斑：看本图斑问题 + 主键级问题，同主键其它图斑作参照；
- 点 Excel 行：看本行问题 + 主键级问题；
- 点主键级问题：高亮整组，不虚构「代表图斑」当背锅侠；
- 数据集级问题：不定位地图，单独筛选查看。
一个值得单独记住的合并规则
同一主键下三个图斑，只有中间一个行政区为空、其余与台账一致时：应输出 1 条图斑级「必填为空」，不要再派生一条「组内空/非空冲突」。否则台账会充斥重复噪音。
反过来：组内两个非空权利人互相冲突时，应输出 1 条主键级冲突，列出各图斑取值，而不是按图斑数翻倍。
一侧有值、另一侧全空，仍应报双源问题，并写明「台账侧空」或「GDB 侧空」——笼统写「不一致」会逼复核人员自己再查一遍。
三、规则要分层：缺数、逻辑、图形不是一类事
把所有问题塞进同一个「错误」桶，台账无法分工。较清楚的分层是：
| 类型 | 管什么 | 例子 |
|---|---|---|
| 必填 / 条件必填 | 字段有没有、该不该空 | 非划拨未填出让年限 |
| 属性逻辑 | 业务先后与上限 | 批准→供地→开工→竣工时间顺序；出让年限超法定上限 |
| 双源取值 | 两边可比字段是否等价 | 代码与中文经映射表归一后再比 |
| 图形类 | 压盖、面积关系 | 图层内压盖；同主键几何面积之和与供应面积相对差 |
图形类尤其容易和「点选命中」混淆：地图上连续点击叠置图斑做轮选，只是解决「点到了谁」；是否非法压盖应由独立空间规则输出问题，而不是靠点击手感。
面积与压盖在工程上几乎总要引入相对容差。常见做法是相对差不超过 1‰ 不报——具体数字以甲方确认为准，但原则应固定：容差写进配置，写进台账说明，写进审核口径，避免「这次严、下次松」说不清。
另一类边界也要提前说死：例如「图形是否超出行政区」若约定由人工核对，程序就明确不做，而不是半做半不做留下灰色地带。
四、图数联动：地图优先，明细按需
质检结果若同时摊开地图、整表 Excel、问题列表，屏幕会被四块面板挤死。更适合复核的布局是：
- 默认只有地图，用问题密度着色看热点；
- 点图斑后右侧滑出明细：台账 / 双源对照 / 问题，一次只看一页；
- 需要「从表找图」时，用搜索（项目名、坐落、主键片段），而不是常驻大表。
问题密度着色有一个容易踩的坑：若用固定阈值（例如「≥3 条错误就最深红」），样例数据里大多数主键组都会落进同一档，整张图全红，等于没有着色。更稳的是按本次运行的错误数分布（如四分位）自适应分档，图例标出具体区间——业务人员看到的是「相对热点」，而不是被绝对值带偏。
双源对照面板建议只列有问题的交集字段：没问题的字段不占行。程序只标不一致或组内冲突，不宣布「以谁为准」。
五、审核出口：误报、例外、待定必须分开
质检默认结论交给人表态时，至少要分清：
| 结论 | 含义 |
|---|---|
| 问题成立 | 数据要改 |
| 程序误报 | 规则或实现有缺陷，应反馈修程序 |
| 合理例外 | 数据可接受，业务允许 |
| 待定 | 需上级确认 |
「误报」和「例外」混用，后面就分不清该改程序还是改管理口径。审核结论写在独立状态文件里、不回写源数据；导出「已审核台账」时另存副本，不覆盖原始问题台账。多人审核可以各写各的状态文件再汇总，程序不替人裁决分歧。
一句话：审核 ≠ 整改。 整改责任人、整改期限留给下游流程；质检工具把发现与复核做干净即可。
六、交付形态：对方电脑上要能跑
行业现场常见约束是：甲方机器没有 Python、没有 .NET SDK、不能联网装库。对应策略是：
- 引擎与桌面端打成自包含目录；
- 配置（字段映射、主键优先级、容差、规则开关）全部外置；
- 日志与台账 UTF-8，避免编号被 Excel 吃成科学计数法。
单次运行只检一个 GDB 图层，可关联多份 Excel。多图层请换图层多次跑——各图层主键与字段口径往往不同，硬做「一次勾选多层」性价比很低，联动复杂度却陡增。
可带走的原则
- 先诊断关联，再谈一致。 没有主键体检表，双源结论不可信。
- 问题要有粒度。 图斑、行、主键、数据集分清，复核才不靠猜。
- 一对多先看组内，再看跨源。 不要按图斑数把同一冲突复制 N 遍。
- 容差与「不做」的边界写进配置。 1‰、越界是否检，都是合同口径，不是代码灵感。
- 只发现，不改库。 审核与整改分流，误报与例外分流。
- 地图服务定位，不服务虚荣。 密度着色看热点，明细抽屉看证据。
土地供应只是双源质检的一个具体行业壳。换到监测上图、不动产台账、设施普查，骨架往往仍是同一套：可配置主键、分级问题、只读输出、让人能定位。 把这四件事做稳，比堆更多规则名更有用。