遥感团队常把“找影像”当成分析前的杂务：先下载一批场景，再在本地筛云量、时间和覆盖范围。这会把目录检索、空间判断和像素处理拆成难以追溯的三段。Apache Sedona 在 2026 年 7 月给出的 STAC 工作流提供了更直接的路径：把场景目录读成带真实几何列的 DataFrame，在进入像素处理前就完成空间、时间与质量筛选。

可核查事实

  • Apache Sedona 于 2026 年 7 月 17 日发布“Join the Sky to the Ground: Spatial Joins over STAC Catalogs”一文，演示将 STAC 目录接入 SedonaSpark。

  • 文中说明 STAC 条目可描述单景影像的 footprint、时间戳、云量和指向实际像素的链接；Sentinel-2、Landsat、NAIP、Maxar 和 Microsoft Planetary Computer 都使用 STAC。

  • SedonaSpark 的 STAC reader 会把 geometry 读为原生 Sedona geometry，datetime 读为 timestamp，并将 EO 扩展的 eo:cloud_cover 提升为 double 类型列。

  • reader 可从公开 STAC API、s3a:// 对象或本地 collection.json 读取；官方示例以 Element 84 的 earth-search Sentinel-2 L2A collection 演示。

  • 对空间、时间和云量的过滤可以下推到 STAC /search API，避免把整个 Sentinel-2 目录传到计算端。

  • 官方示例用 ST_Intersects 把 AOI 与场景 footprint 做空间连接，并以 ST_Intersection 面积除以 AOI 面积计算覆盖比例。

  • LEFT ANTI JOIN 可返回没有任何影像覆盖的 AOI，用于识别缺口或安排新的采集。

  • 匹配项的 assets map 保留像素链接；过滤后的目录可用 save_to_geoparquet() 持久化，再按 eo:cloud_cover 与 datetime 用窗口函数为每个 AOI 选择场景。

核心机制：目录先成为空间数据

这套做法的关键不是“多一个下载器”，而是把影像目录转成可查询的空间表。场景 footprint 和业务 AOI 处在同一套空间谓词里，因此团队可以先问三个确定的问题：哪些场景相交、各自覆盖多少、哪些 AOI 根本没有可用覆盖。只有这些答案成立，才进入裁切、指数计算或模型推理。

把过滤留在读取阶段也改变了成本边界。若先拉取候选清单再筛选，网络和存储开销已经发生；若把 AOI、日期与云量条件下推到 STAC API，传输到 Spark 的只是命中条目。官方的 San Francisco 例子以 2026 年 5—6 月、云量低于 20% 为条件，返回的只有覆盖该区域的 10SEG tile，而不是完整目录。

GIS 场景：把“有影像”升级为可审计的覆盖决定

以农田巡查为例，地块边界是 AOI，目标时间窗和云量阈值是业务规则。空间连接后，输出不应只是一串 scene ID，还应包括场景时间、云量、覆盖比例和选择理由。覆盖 29.4% 的场景可以用于边缘观察，却不应与覆盖 80.2% 的场景混作同等级训练或统计输入；没有匹配的 AOI 则进入补采或时间窗调整队列。

这一模式同样适用于洪涝、林火、建设变化和资产巡检。对每个 AOI 保存一次“目录快照”，能让后续模型结果回答它使用了哪一景、当时目录筛了什么条件、为何没有采用另一景。GeoAI 推理从来不能弥补输入覆盖不足，因此覆盖审计应放在模型之前。

技术路径

  1. 将 AOI 维护为有唯一标识和坐标参考说明的向量表，并明确时间窗、最大云量和最低覆盖比例。

  2. 通过 format("stac") 读取目标 collection；先检查 geometry、datetime、eo:cloud_cover 与 assets 字段是否齐全，再接入业务查询。

  3. 在读取链上提交空间、时间和云量过滤，让可下推条件由 STAC /search 执行；记录 endpoint、collection 和查询条件。

  4. 用 ST_Intersects 连接 AOI 与 footprint，以交集面积比例形成覆盖报告；用 anti join 形成“无覆盖”清单。

  5. 按每个 AOI 的覆盖比例、时间和云量排序，选出候选场景；保存过滤后的目录到 GeoParquet，并把 assets 链接交给后续裁切或栅格计算。

  6. 在像素处理和模型推理之后，把所选 STAC item、查询快照、处理参数和输出版本一起登记，便于复跑与复核。

检查清单

  • STAC 条目的 geometry 是可计算的空间列，而非只保存 bbox 文本吗？

  • AOI、时间和云量条件是否在读取时下推，而不是先搬运整批目录？

  • 每个 AOI 是否记录覆盖比例与未命中原因？

  • 是否把“有交集”和“覆盖足以支撑业务判断”分成两个阈值？

  • 过滤结果、collection 版本、assets 链接和最终像素处理是否可追溯？

风险边界

STAC 目录中的 footprint、时间和云量是筛选证据，并不等于像素已经适合分析。云量字段可能不能代表阴影、烟雾、边缘缺失或具体地物的可见性；多景拼接还需处理传感器差异和时间一致性。空间连接也受 AOI 坐标、几何有效性与覆盖阈值影响。高影响决策应在目录筛选之后继续做影像质量检查和人工复核。

结论

把 STAC 当作空间表，能让遥感团队先用可审计的查询决定“哪些影像值得处理”。这比先下载再解释更节省资源，也让后续 GIS 分析和 GeoAI 模型有一条可复跑的证据链。

资料来源