第06章 服务、互操作、工程化与选型矩阵
本章导读
技术选型只是起点。本章对应原报告 3.7—3.9 节，是技术层的收口：先把服务与互操作收敛到 OGC API 与 STAC 的分工上，再讲分析能力变成生产能力所需的五个工程属性，最后给出一张按场景排列的选型矩阵；第07章再补上质量这一环。要带走的判断是，接口拆 Part 的价值在于可增量实现，先上 Core 就能跑；而决定项目成败的往往不是引擎性能，而是可复现、可观测、可审计这几件看起来不产生业务价值的事。读完你应当能给自己的场景选一套组合，并说清每条关键提醒防的是哪类失败。
学习目标
读完本章，你应当能够：
- 用 OGC API 的分 Part 设计解释“先实现 Core 就能上线”是怎么成立的，并说明 Part 2 处理什么；
- 为接口、元数据与发现、三维、点云四类需求各选一种规范，说明为什么不必强求统一格式；
- 用 3.8 节的五个属性（可复现、可调度、可观测、可审计、可治理）给一条现有分析管线逐项打分；
- 从 3.9 节矩阵为单项目探索、部门级系统、城市级平台、实时监控四类场景各选一套分层组合；
- 解释增量计算为什么是成本控制的关键，说明它在影像与轨迹类数据上的具体做法；
- 写出一条可审计要求，能落到“谁、什么时候、用什么数据、跑了什么模型”四个要素上。
3.7 服务与互操作：OGC API 的收敛
OGC API 系列已取代 WMS/WFS 成为新系统的默认接口风格。其设计是“按资源类型分家、每个标准分 Part”：例如 OGC API - Features 的 Part 1 是 Core（限定 WGS 84、经纬度轴序），Part 2 处理其他坐标参考系〔来源：OGC 标准页〕。这种拆分的实际好处是可增量实现——先实现 Core 就能上线，复杂能力按需追加。
对工程团队的含义：
- 新系统优先按 OGC API 设计，老系统通过网关适配，避免“一次性重构”。
- 元数据用 STAC 组织（影像、栅格尤为合适），检索与发现走 STAC API。
- 三维走 3D Tiles，点云走 COPC/3D Tiles，矢量瓦片走 MVT——格式各司其职，不要强求统一。
3.8 工程化：分析能力如何变成生产能力
技术选型只是起点，真正决定成败的是工程化程度。五个必备能力：
可复现。同一份输入、同一份代码、同一个环境，必须得到同一个结果。要点：容器化环境、锁定依赖版本、数据快照（湖仓时间旅行）、随机种子固定。没有可复现，就没有可信度。
可调度。分析任务要能被编排（DAG 调度）、能重跑、能断点续算。增量计算（只算变化部分）是成本控制的关键，尤其在影像与轨迹类数据上。
可观测。记录每次运行的输入版本、耗时、输出行数、异常率。空间分析的性能退化往往悄无声息（索引失效、数据倾斜），没有监控就发现不了。
可审计。谁、什么时候、用什么数据、跑了什么模型、得出什么结论——完整链路留痕。这既是合规要求，也是模型回溯的前提。
可治理。数据分级、权限最小化、脱敏规则、生命周期管理。GIS 数据的敏感度差异极大（公开底图 vs 精确位置轨迹），必须分级对待。
3.9 选型矩阵：按场景而非按偏好
| 场景 | 数据层 | 计算层 | 服务层 | 关键提醒 |
|---|---|---|---|---|
| 单项目探索分析 | GeoParquet + DuckDB | 单机 | 静态报告 | 优先速度，别上集群 |
| 部门级业务系统 | PostGIS + GeoPackage 交付 | 数据库内计算 | OGC API | 事务与权限优先 |
| 城市级时空平台 | 湖仓 + GeoParquet + COG | Spark/Sedona + 调度 | 瓦片 + API + 仪表盘 | 治理与元数据是难点 |
| 实时监控 | 时序库 + H3/S2 网格 | Flink | WebSocket + 地图 | 网格分辨率决定精度成本 |
| 三维审查/孪生 | 3D Tiles + 点云 COPC | GPU 渲染 + 模型服务 | 三维引擎 + API | 坐标与语义对齐是坑 |
| AI 辅助分析 | 嵌入 + 矢量库 | 推理服务 + 几何库 | 对话式界面 | 必须保留工具调用轨迹 |
本章小结
- OGC API 系列已取代 WMS/WFS 成为新系统的默认接口风格；按资源类型分家、每个标准分 Part 的设计，实际价值是可增量实现——先实现 Core 上线，复杂能力按需追加。
- 互操作的分工已经清楚：接口走 OGC API，影像等元数据用 STAC 组织、检索走 STAC API，三维走 3D Tiles，点云走 COPC/3D Tiles，矢量瓦片走 MVT。
- 工程化有五个必备属性：可复现（容器、锁版本、数据快照、固定随机种子）、可调度（DAG、重跑、断点续算）、可观测（输入版本、耗时、输出行数、异常率）、可审计（完整链路留痕）、可治理（分级、权限最小化、脱敏、生命周期）。
- 空间分析的性能退化往往悄无声息（索引失效、数据倾斜），没有监控就发现不了；可观测不是可选项，而是发现问题的入口。
- 选型矩阵按场景而非按偏好：单项目探索用 GeoParquet + DuckDB，部门级用 PostGIS + GeoPackage 交付，城市级用湖仓 + Spark/Sedona，实时用网格编码 + Flink。
- 三维审查与 AI 辅助两行的关键提醒都落在同一件事上：坐标与语义对齐、工具调用轨迹留痕，这些都不是引擎性能问题。
思考与练习
- 列一份你单位的接口清单，标出哪些还是 WMS/WFS、哪些已按 OGC API 设计，给出迁移优先级与理由。
- 给一条现成的分析脚本补三项可观测指标（耗时、输出行数、异常率），说明缺了它会漏掉哪类故障。
- 辨析：“都改上 OGC API 就能互操作”。用 3.7 节的分工说明这句话漏掉了哪些数据类别。
- 应用：为一个区县级业务系统从 3.9 节矩阵选一套方案，说明为什么不该上分布式、该怎么留升级位。
- 你的分析任务单次跑 6 小时、数据每天更新。用增量计算的思路说明怎么改造，并估算能省下多少时间。
- 写一份可复现清单，列出你会锁定的四样东西，并说明抽查时如何验证它真的被锁住了。