附录B 工具选型决策树

本篇导读

这份决策树把正文第 5 章的工具链横评压成一串二分判断：数据以什么形态交付、是否需要跨图层拓扑、是否已深度使用 Esri 生态、是否面向数据湖按需增量质检、是否有三维或点云交付，五问之后落到具体方案。它不追求覆盖所有产品，只给一条先排除再选型的路径。前提是接受表下三条不可绕过的约束：规则与标准条款有映射、结果可回放、阻断级规则与流水线阶段绑定。

开始
 ├─ 数据是否以文件交付、单批次？
 │    ├─ 是 → GDAL + 脚本 + 报告模板（成本最低）
 │    └─ 否 ↓
 ├─ 是否需要跨图层拓扑与邻域检查？
 │    ├─ 是 → PostGIS（库内）或 1Integrate（需审计留痕时）
 │    └─ 否 ↓
 ├─ 是否已深度使用 Esri 生态？
 │    ├─ 是 → 迁移到 attribute rules（不要新建 Reviewer Batch Job）
 │    └─ 否 ↓
 ├─ 是否需要面向数据湖、按需增量质检？
 │    ├─ 是 → GeoParquet + Iceberg + DuckDB/Trino，规则用 SQL
 │    └─ 否 ↓
 ├─ 是否有三维/点云交付？
 │    ├─ 是 → 3d-tiles-validator + PDAL + 自研表面缺陷算子
 │    └─ 否 → 通用规则引擎（自研 YAML 规则 + DAG 调度）

三条不可绕过的约束：

规则必须与标准条款建立映射，否则无法举证；
质检结果必须可回放（规则版本 + 数据指纹 + 引擎版本）；
阻断级规则必须与流水线阶段绑定，避免“全阻断导致交付停滞”。

使用提醒

决策树给的是起点不是结论：落到某一支后仍需按第 5 章的能力边界核对许可、并发、审计与迁移成本。
三条不可绕过的约束优先于工具选型；若团队暂时做不到“结果可回放”，应先补这一条，再谈自动化率。
“不要新建 Reviewer Batch Job”是针对新建项目的建议，不等于存量方案立即停用；既有系统迁移前先确认版本、许可与支持周期。
分支按交付形态划分，多形态混合交付时按最复杂的一支选型，再对简单形态做裁剪，不要反向拼装。
选型结论应随标准换版与数据格式演进复核，建议至少每年重走一次判断。