把 STAC item 放进 GeoParquet 并以 API 提供查询，可以减少目录服务依赖，但不等于文件本身已经成为可靠的数据目录。stac-fastapi-geoparquet 的官方 README 给出了单文件、collection 清单与当前限制；GIS 团队应把存储、集合语义和查询服务拆开验收。
可核查事实
- stac-fastapi-geoparquet 是使用 stac-geoparquet 后端的 stac-fastapi 实现。
- 项目称可从位于对象存储等位置的一个或多个 stac-geoparquet 文件提供完整 STAC API，无需数据库。
- 项目明确标注为 active development，可能随时发生破坏性变化。
- 单文件启动示例使用 STAC_FASTAPI_GEOPARQUET_HREF 和 uvicorn。
- 单文件模式会根据 stac-geoparquet 文件中的 items 自动生成 collection。
- 多 collection 模式使用 STAC_FASTAPI_COLLECTIONS_HREF 指向 JSON collection 列表。
- type 为 application/vnd.apache.parquet 的 collection assets 会被作为 item 来源加入服务。
- 项目提供 generate-collections 脚本生成 collections.json。
- 当前限制是每个文件只支持一个 collection。
关键词：STAC、GeoParquet、stac-fastapi、对象存储、collection、遥感目录、API。
核心机制：一个文件、一个集合和一个 API 是三层对象
GeoParquet 文件保存 item 元数据，collection 描述数据集语义，API 暴露检索接口。单文件模式自动生成 collection 很适合验证，但自动生成的名称、范围、时间覆盖和资产字段仍要检查。多 collection 模式通过 JSON 清单把多个 parquet 资产加入服务，清单本身便成为需要版本化的目录入口。
“无需数据库”意味着部署面更小，不意味着没有运行边界。对象存储 URL 可访问、Parquet schema 完整、collection 与 item 一致、API 过滤正确，缺一项都会让目录查询产生错误的可用性印象。
GIS 场景：先用样本目录验收查询，而不是直接替换生产检索
建立一个小型样本：一份单 collection GeoParquet、一个包含两个 collection 的 JSON 清单，以及若干已知的空间和时间查询。分别记录 API 返回的 collection、item、bbox、datetime 和 asset href。若一个文件只能承载一个 collection，就不要把多来源 items 为了部署方便硬合并进同一文件。
技术路径
- 固定 GeoParquet schema、文件校验和与对象存储位置。
- 单文件模式下核对自动生成的 collection 元数据。
- 多集合模式下将 collections.json 纳入版本控制与发布流程。
- 用已知 bbox、datetime 与 collection 参数回归 API 响应。
- 对每个 parquet 文件保持单一 collection，直到项目限制改变并完成升级验证。
检查清单
- GeoParquet 文件与其 collection 是否有可回读版本和校验和？
- 自动生成 collection 的空间、时间与资产字段是否正确？
- collections.json 是否只引用预期的 Parquet assets？
- API 对 bbox、时间和 collection 的过滤是否符合样本结果？
- 是否避免在一个文件中混装多个 collection？
- 是否将 active-development 的破坏性升级风险写入发布计划？
风险边界
项目明确处于 active development，接口和限制可能变化。无数据库部署不等于免维护：对象存储权限、Parquet schema、清单更新和 API 兼容仍需要监控。本文不把 README 示例视为生产吞吐、可用性或访问控制承诺。
结语
轻量 STAC 服务的关键不是少一套数据库，而是让文件、collection 清单和查询结果保持同一份可验证的目录合同。