把 STAC Item 转成 GeoParquet，常被当成一次格式转换：下载 catalog、写一个 Parquet 文件、下游就能查询。但空间覆盖字段若没有按目标规范写入，读取端可能无法可靠判断每行或每个 row group 的空间范围，继而错失过滤、分区裁剪和质量检查机会。rustac 的 stac-v0.17.4 官方发布只修复了一项具体问题——GeoParquet 写入时补上 covering——却恰好说明空间数据管线里的“小元数据”也应被当作发布合同。

这不代表出现 covering 就能保证快速、正确或跨工具兼容。覆盖范围来自 STAC 的 bbox 时，团队仍须核对 STAC 与实际几何是否一致、分区粒度是否匹配查询模式、row group 是否可裁剪，以及不同读取端实际采用了哪些统计或索引。修复应成为一次回归验收的触发器，而不是升级后的默认通过。

可核查事实

  • rustac 的官方 GitHub 发布页显示 stac-v0.17.4 发布于 2026 年 8 月 6 日。

  • 该版本的唯一 release note 是“add covering to geoparquet writes”，即为 GeoParquet 写入加入 covering。

  • 对应的官方 pull request #1107 标题同为“fix: add covering to geoparquet writes”，并于 2026 年 8 月 6 日合并。

  • PR 说明没有调用 geoparquet 来生成 covering，因为那样会重新计算 bbox，而转换链已经从 STAC 获得 bbox。

  • PR 的命令行验证示例以 cargo run -- translate 读取 Earth Search 的 cop-dem-glo-30 collection Item，并写出 items.parquet。

  • 同一验证示例用 gpio check items.parquet 报告已找到名为 bbox 的列且具有 proper metadata covering。

  • 示例还报告 GeoParquet metadata version 为 1.1.0、geometry 列使用 ZSTD compression、文件看起来 spatially ordered，并显示 spec validation 为 25 项通过、1 项失败。

  • PR 的验证输出提示 GeoParquet 2.0 提供 native spatial stats 和 filter pushdown，并给出使用 gpio convert geoparquet 转换版本的命令。

这些是 rustac 发布和合并请求中记录的特定代码路径与样例结果，不是对任意 STAC catalog、任意文件大小或任意查询引擎的性能保证。

核心机制

STAC 的 bbox、GeoParquet 的列元数据与 Parquet 的 row group 共同构成空间裁剪线索。转换器若知道一个 Item 的空间范围，应明确说明该范围在输出文件中服务什么层级：是每个 feature 的属性、文件级 metadata，还是让读取端按 row group 跳过无关数据的 covering。不同层级不能互相替代。文件有总 bbox，不等于每个 row group 都有足以裁剪的统计；一个 metadata 字段存在，也不等于几何值没有越界。

#1107 选择复用 STAC 已有 bbox，而非在转换时再算一次，体现了一个可审计原则：派生字段要记录权威来源和生成规则。这样可以避免同一 Item 在不同库或浮点策略下得到不同范围，但也要求输入 STAC 的 bbox 已经受过质量检验。将来源、转换器版本、输入 Item 标识和输出校验一起写入 manifest，才能追查范围错误是上游描述错误还是写入错误。

GIS 场景

一个地形数据平台需要把多个公开 DEM collection 的 STAC Item 转成 GeoParquet，供灾害 AOI 检索和批量分析。发布作业为每个 Item 保存原始 STAC URL、collection、datetime、bbox、资产链接、转换命令、rustac 版本和输出文件摘要。然后用典型小 AOI、跨分区 AOI 和空结果 AOI 分别测试：返回 Item 数量是否正确、读取字节是否符合预期、bbox 与实际几何/栅格覆盖是否一致。

当 gpio check 指出 covering 存在时，质量门槛只通过了“覆盖元数据被写入”的一项。若 AOI 过滤仍读入全量 row group，团队应检查排序、分区、统计和具体引擎的执行计划；若 STAC bbox 与资产实际范围不一致，必须回溯源 catalog，而不是在转换阶段静默修正。对公共目录可优化读取，对私有目录还要把访问授权、签名链接与审计日志作为独立控制。

技术路径

先建立输入契约。对每个 STAC Item 校验 id、collection、datetime、bbox、geometry、assets 和链接可用性；检查 bbox 的维度、坐标顺序、跨反经线处理与 geometry 包络是否符合项目约定。记录那些缺失或不可信的范围，阻断它们进入“可空间裁剪”的发布目录。

再建立转换与文件契约。固定 rustac/转换器版本和命令；写入后用独立工具检查 GeoParquet 版本、geometry 列、bbox/covering metadata、row group 尺寸、压缩和空间排序。采样读取应覆盖单一 AOI、跨分区 AOI、边界相交 AOI和空 AOI；同时保存返回行数、读取字节、耗时和执行计划。若使用 GeoParquet 2.0，另行验证读写端对 native spatial stats 和 filter pushdown 的实际支持。

最后建立回归集。每次升级转换器、规范或数据源时，重跑固定的 STAC Item 和 AOI 集合，比较输出 schema、范围、行数、校验报告和查询成本。范围或结果集合变化必须与源数据版本或明确变更单关联，不能只凭“文件能打开”就发布。

风险边界

bbox 是近似筛选线索，不能代替精确空间谓词；范围相交不表示几何一定相交。基于 STAC bbox 复用 covering 的前提是上游 bbox 可信，错误的 catalog 描述会被稳定地传播到新文件。空间排序、压缩、row group 大小和查询引擎实现也会决定真实性能；样例中“小文件合适”的判断不能直接套用到大规模生产数据。

GeoParquet 版本和读写器能力必须显式管理。转换器提示 GeoParquet 2.0 的功能不等于所有下游已经支持它，升级前需做兼容测试与回退计划。

检查清单

  1. 保存每个 STAC Item 的 URL、ID、collection、时间、bbox、geometry 和 assets 摘要。

  2. 对 bbox 与 geometry 包络、坐标顺序、维度和反经线规则做输入校验。

  3. 固定转换器版本、命令和输出摘要，并记录 covering 的来源与写入层级。

  4. 用独立工具检查 GeoParquet version、geometry、bbox/covering metadata、row group、压缩和排序。

  5. 用单一、跨分区、边界和空 AOI 测试结果集合、读取字节和执行计划。

  6. 为 GeoParquet 2.0 的统计与 pushdown 建立读写端兼容矩阵，不能仅依据提示信息上线。

  7. 将升级纳入回归集，任何范围、行数或成本变化都绑定到数据或代码变更。

结论

GeoParquet covering 的修复是一项很小的代码变化，却提醒空间数据团队：范围字段、转换来源和读取证据同样是发布物。把 STAC 输入、覆盖写入、文件校验和 AOI 回归连成一条链，才能把“已写入 GeoParquet”变成可验证的空间数据服务能力。

参考来源

  1. rustac stac-v0.17.4 官方发布：https://github.com/stac-utils/rustac/releases/tag/stac-v0.17.4

  2. rustac pull request #1107：https://github.com/stac-utils/rustac/pull/1107