图斑核查为什么要分清业务流、影像流和证据流

这个问题从哪里来

图斑核查项目做到一半，发现成果和原始台账总是对不齐：同一块地，业务侧说“已核查”，影像侧却没有对应记录。排查到最后，问题出在当初把三条数据流当成了一条。

三条流不要混在一起

• 业务流：哪些图斑需要核查、由谁核查、状态怎么流转。
• 影像流：用什么影像、什么时候拍的、空间对不对得上图斑。
• 证据流：每次判断依据的截图、航片、位置信息是否可回查。

难就难在它们各自有生命周期和状态机，又要在核查完成那一刻交汇。只要有一个流上的状态没跟上，总账就对不上。

一条数据流里的状态，不能靠另一条流的推断来补齐。核查结果必须有一个唯一的、可回查的证据源。

图斑红线实时计算里，那个怎么都不触发的超限

用无人机 MQTT 姿态实时把图斑几何投影到画面里时，遇到过一个很隐蔽的错：超限判断从来没触发过。

• 根因：图斑 geometry 没带 Z 值，coord.getZ() 返回 NaN；旧逻辑又用“三维距离”去比，于是 NaN > maxDistance 永远为 false，该跳过的一直不跳过。
• 修正：超限判断改用水平距离（calculateHorizontalDistance），缺失 Z 不影响判断；离地高度优先用 elevation。
• 工程习惯：pitch-threshold、max-distance 这类要落成 application.yml 里的配置项，不要写死；超限时清掉对应的 Redis，跳过本轮计算。

数值比较里最防不胜防的就是 NaN：它和任何数比都返回 false，让“大于阈值”永远不生效。遇到“条件从没触发”的 bug，先查是不是比值比出了 NaN，而不是急着改阈值。

可复用经验

1. 项目立项就把业务流、影像流、证据流各建一张表，明确主键和关联键。
2. 每条核查记录必须落一条证据引用，缺证据即视为未完成。
3. 状态流转用显式状态机，禁止在业务表里推断影像或证据字段。
4. 冲突检测单独标记，不要静默吞掉。

留给下次

这套三流模型想抽成一份通用的核查项目检查清单，作为以后投标和评审的附件。