让 GIS Agent 回答“某片区域有哪些设施”时，常见做法是先把 GeoParquet 导入数据库。geoparquet-mcp 的官方 README 提供了另一种实验性工程样本：DuckDB 通过 HTTP range request 读取对象存储中的 Parquet footer 与必要列块，再通过 MCP 提供空间操作。它的关键不只是免导入，而是把“允许读什么”和“第一次查询要付多少元数据成本”变成显式约束。

本文依据该项目官方 GitHub README 的演示与架构说明。文中的性能数字来自项目给定的 Overture 演示数据与网络环境，不能外推成其他数据、区域、对象存储或部署的通用承诺。

可核查事实

  • geoparquet-mcp 将自己定义为 MCP server，用于回答位于公共对象存储、数 GB 级 GeoParquet 文件的空间问题，目标是不先下载或导入整个文件。

  • README 说明 DuckDB 可通过 HTTP range requests 读取远程 Parquet，并把 filter 下推到文件读取过程。

  • 项目将可读取的范围在应用启动时解析，而不是让工具在每次调用时任意决定要访问的资源。

  • 官方 demo 使用 Overture Maps 2026-08-19.0 的 places 主题：73,631,092 行、16 个文件、10.48 GB、4,096 个 row group；读取 footer 以获取这些描述信息为 26.5 MB。

  • 该 demo 的巴黎查询返回 166,966 个要素与 1,022 个 categories.primary 值，报告读取 4.0 MB、耗时 6,674 ms。

  • pushdown benchmark 对同一远程 part 比较关闭与开启过滤下推：关闭时读取 128.8 MB、25,033 ms；开启时读取 6.9 MB、4,626 ms，README 报告约少传输 18.8 倍字节。

  • README 将首个进程读取约 26.5 MB 的成本归因于 16 个文件的 Parquet footer；其中包含 4,096 个 row group 的统计信息，正是裁剪 row group 的依据。

  • 项目说明以 bbox.xmin、bbox.xmax、bbox.ymin、bbox.ymax 的比较表达范围筛选，可让 Parquet 统计参与裁剪；单独把 ST_Intersects 施加在 geometry 列上虽可正确求交，却会失去该裁剪优势。

这些是项目演示的可复核事实。它们同时说明“少传输”并不等于“没有成本”：第一次读取 footer、远端往返、数据布局、缓存与精确几何过滤都必须进入服务设计。

核心机制

远程 GeoParquet 的成本结构分两段。第一段是元数据：客户端先读 footer 和 row group 统计，才知道哪些列块可能满足范围或属性条件。第二段才是候选数据页。若筛选条件写成可由列统计判断的 bbox 比较，reader 可以跳过不可能命中的 group；若所有判断都藏在空间函数中，通常需要先物化更多几何再计算。

这并不意味着 Agent 可以接受任意 URL、任意 SQL 或任意大范围请求。项目 README 强调访问范围由应用在启动时决定。它应被落实为允许的数据集清单、可用字段、AOI 上限、行数或字节预算、超时与审计记录。MCP 只是一种工具协议，不是对象存储访问控制的替代品。

GIS 场景

以城市应急值守为例，值班人员询问“医院 5 公里内有哪些补给点”。Agent 应先从注册的数据集清单选择可读的 places 数据版本，记录 AOI、分类、距离、精确几何条件和字节预算。系统先用 bbox 过滤削减远端读取，再用精确距离或相交判断处理候选记录。结果必须同时返回数据版本、查询时间、空间口径、命中数和截断状态，不能只给自然语言结论。

若用户把 AOI 扩展到全国或要求遍历所有属性，服务不应悄悄扩大扫描。它应估算 footer 与候选数据成本，超过配额就要求缩小范围、改用聚合或转为异步任务。这样既保护对象存储与运行成本，也防止 Agent 的模糊问题触发不可控的数据传输。

技术路径

先为每个公开 GeoParquet 建立 manifest：固定数据 URL、版本、许可、可用 geometry/bbox 列、允许字段、空间参考、文件大小、预计 footer 成本和刷新日期。启动时加载 manifest，并让 MCP 只显示其中获准的数据集。查询计划先检查 AOI、时间、字段和预计扫描量；需要精确几何时采用“bbox 预筛 + geometry 精查”的两阶段路径。

为每次执行保存请求、manifest 版本、SQL 或结构化计划、下推开关、命中数、读取字节、耗时和截断原因。冷启动与热缓存应分别测量，不能把一次热缓存结果当作首次用户体验。指标可以按数据集、operation 和预算结果聚合，但不把完整用户 AOI 或敏感实体写入公开标签。

风险边界

README 演示使用特定的 Overture release、文件布局和网络路径；数据更新、对象存储延迟、HTTP 服务限制、Parquet 编码、列统计质量和用户查询形状都会改变结果。bbox 预筛还能保留精确几何检查的必要性：边界框相交不代表真实多边形相交。公开对象存储也不保证所有数据许可、更新时效或业务可用性相同，服务仍须复核许可与版本。

检查清单

  1. 为每个可读 GeoParquet 固定 manifest、版本、许可、字段、CRS 与对象存储位置。

  2. 在启动时装载访问边界；工具调用不能新增任意远端 URL 或绕过字段限制。

  3. 分别记录冷启动 footer 成本与热缓存查询成本，设置字节、行数和时延预算。

  4. 将空间请求拆为 bbox 列裁剪与精确 geometry 判定，并验证两阶段结果一致。

  5. 对大 AOI、宽字段选择和无筛选查询演练拒绝、截断或异步路径。

  6. 保存请求参数、数据版本、读取量、命中数与运行时间，支持复现和成本核算。

  7. 把 MCP 进程权限、对象存储凭据和运行日志纳入最小权限与审计策略。

结论

GeoParquet 可以让 Agent 在不复制整份数据的前提下完成空间提问，但前提是数据范围、读取预算和筛选计划都由服务端明确控制。把 footer 成本、bbox 裁剪、精确几何和访问边界一起验收，才能把“远程直查”变成可控的数据能力。

参考来源

  1. geoparquet-mcp 官方 README：https://github.com/rteina/geoparquet-mcp