AI Agent 能很快回答空间问题、做出地图，但“看起来正确”的页面通常不够。数据版本、坐标系、处理参数、临时假设和图层派生过程若没有记录，下一次就无法复现，也无法判断结果是否因数据更新而变化。

openmapstack 将一次 GIS 分析组织成可检查项目：把来源、假设、CRS、处理管线、验证和展示写进同一份项目契约。这是一个工作流参考，不是对任何单个空间结论的担保。

可核查事实

  • openmapstack 面向 AI Agent 提供从权威数据发现到交互地图和 GIS 交付的工作流。
  • 项目使用 YAML 文件保存固定来源、明确假设和 CRS 选择。
  • 该工作流强调确定性处理、机器可读验证和公开的来源追溯。
  • 文档列出 STAC、GeoParquet、COG、PMTiles、DuckDB、PostGIS、QGIS 与 MapLibre 等开放 GIS 组件。
  • 项目契约名为 openmapstack-project/v1。
  • 项目提供 validate、verify、run 和 inspect 四类命令。
  • verify 可读取产物的几何与 CRS，并检查来源哈希、输出和运行记录。
  • 示例评测包含分析正确性、度量 CRS、来源不可变性、模式、覆盖项、验证完整性和可重跑性检查。

核心机制

核心机制是将自然语言需求编译成可审查的 GIS 项目，而不是只保留最终网页。项目清单固定数据来源和版本，处理管线确定步骤顺序，验证报告记录执行结果，展示层从受控输出派生。这样，地图上的每个统计或要素都可以回到来源、投影、处理和运行记录。

验证也分层：validate 检查项目结构、声明和记录；verify 面向实际产物重读几何、CRS 和元数据，必要时在隔离环境重跑并比较结果。它不声称自动证明所有业务结论，但能让缺少依赖或无法检查的环节明确显示为未验证。

GIS 场景与实施路径

适用于 Agent 生成的选址分析、土地利用统计、通达性计算、遥感指标汇总和交互地图交付。每个分析先登记 AOI、业务问题、权威来源、更新时间、许可、预期输出、目标 CRS 和空间精度；之后才让 Agent 调用 GDAL、DuckDB、PostGIS 或 QGIS。

处理完成后，应先在小范围样本运行同一管线，再进行完整运行。发布前保存输入哈希、执行时间、软件版本、验证报告和输出图层；如果来源、假设或投影变化，生成新的运行记录，而不是覆盖旧结果。

可执行建议

  1. 用项目清单固定每个数据源的版本、许可、范围、时间和访问方式。
  2. 明确分析 CRS 与度量单位，避免把 Web 墨卡托坐标直接用于面积和距离结论。
  3. 将数据获取、转换、空间分析、图层导出和网页展示写成一条可重跑管线。
  4. 先在样本 AOI 验证，再运行全域任务，并区分样本结果与正式结果。
  5. 发布地图时附带运行记录、来源追溯和机器可读验证报告。

风险边界

项目契约可以提高可追溯性，却不能自动证明来源数据正确、假设合理或空间模型适合业务。外部数据许可、实时性、敏感区域访问和本地权威数据仍需单独审查。开源工具的可复跑也依赖明确固定依赖版本和可长期访问的来源。

结论

GIS Agent 的交付应从“生成一张地图”升级为“生成可复跑的项目”。当来源、CRS、处理、验证和展示共同被记录时，团队才有条件复核结果、发现数据漂移并安全迭代。

资料来源与数据口径