OlmoEarth：把地理空间推理扩展到行星尺度

预计阅读时间：9 分钟

OlmoEarth Platform 指向一个明确目标：让地理空间推理不再局限于单张影像或局部区域，而是能够覆盖行星尺度的数据。由于现有信息只给出了平台名称与主题，下面不会假定其具体 API、模型架构或部署方式，而是从工程角度分析这类平台必须解决的问题，并给出一套可改造的调用与批处理范式。

行星尺度改变的不只是数据量

传统遥感任务通常从一个边界框开始：下载若干影像，完成云层过滤、波段组合和模型推理，再把结果写成 GeoTIFF。这个流程在县、市或单个流域范围内可以运行，但扩展到全球后，系统约束会发生变化。

一是空间必须切片。全球影像无法作为一个张量直接送入模型，平台需要按瓦片组织输入，并记录每个瓦片的坐标参考系、分辨率、时间范围和数据来源。

二是时间成为关键维度。土地覆盖变化、火灾、洪水和作物生长都不是静态问题。同一地点可能存在数百次观测，推理任务需要明确使用哪一段时间的数据，以及如何处理云层、缺测和传感器差异。

三是结果必须能够重新拼接。瓦片边缘容易产生断裂，重叠区域可能得到相互冲突的预测。平台不仅要运行模型，还要处理边界缓冲、结果融合、坐标转换和质量标记。

因此，“行星尺度”更像一种完整的执行能力：把数据发现、预处理、推理、重试、拼接和发布组织成可重复的流水线。

地理空间推理需要一份严格的任务契约

普通图像 API 接收一张 JPEG 就可以工作，地理空间任务则需要更多上下文。一份可执行的任务至少应描述以下信息：

空间范围，例如 GeoJSON 多边形或经纬度边界框；
时间范围，以及选择最接近日期、时间合成或完整时间序列；
输入数据与波段，例如可见光、近红外或雷达数据；
输出任务，例如分类、分割、目标检测或连续值回归；
输出坐标系、像元大小、格式和置信度要求；
模型与数据版本，确保结果可以复现。

这种契约还有一个现实作用：控制成本。全球范围、10 米分辨率和多年时间序列的组合可能产生数量庞大的瓦片。服务端应在提交前估算覆盖面积、瓦片数量、读取字节数和计算预算，并允许调用方设置硬上限。

可以这样实践：提交一个异步推理任务

下面是一个假设性的 HTTP 接口，用于说明客户端应如何描述任务。它不是 OlmoEarth 已公开 API 的声明；接入真实平台时，需要替换地址、认证方式、模型标识和字段名称。

先设置服务地址和令牌：

export GEO_API_BASE="https://geo.example.com/v1"
export GEO_API_TOKEN="replace-with-your-token"

提交一个土地覆盖分割任务：

curl --fail-with-body \
  -X POST "$GEO_API_BASE/inference/jobs" \
  -H "Authorization: Bearer $GEO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "land-cover-segmentation-v1",
    "geometry": {
      "type": "Polygon",
      "coordinates": [[[116.20, 39.75], [116.65, 39.75], [116.65, 40.10], [116.20, 40.10], [116.20, 39.75]]]
    },
    "time_range": {
      "start": "2024-05-01",
      "end": "2024-06-30"
    },
    "input": {
      "bands": ["red", "green", "blue", "nir"],
      "cloud_cover_max": 20
    },
    "output": {
      "format": "cog",
      "crs": "EPSG:3857",
      "resolution_m": 10,
      "include_confidence": true
    },
    "limits": {
      "max_tiles": 5000
    }
  }'

行星尺度任务通常不能保持一个同步 HTTP 连接，因此客户端应轮询任务状态，或者注册 webhook。假设创建接口返回 job_id，可以这样检查：

JOB_ID="replace-with-job-id"

curl --fail-with-body \
  -H "Authorization: Bearer $GEO_API_TOKEN" \
  "$GEO_API_BASE/inference/jobs/$JOB_ID"

生产环境还应为提交请求附带幂等键，避免网络重试创建重复任务：

REQUEST_ID="land-cover-2024-beijing-001"

curl --fail-with-body \
  -X POST "$GEO_API_BASE/inference/jobs" \
  -H "Authorization: Bearer $GEO_API_TOKEN" \
  -H "Idempotency-Key: $REQUEST_ID" \
  -H "Content-Type: application/json" \
  --data @job.json

其中 job.json 可以直接使用前一个示例中的 JSON 请求体。对批量区域，不要在客户端无限并发；应设置并发上限，并针对 429、502 和 503 响应执行带抖动的指数退避。

结果可信度比吞吐量更难处理

地图上的每个像元看起来都很确定，但模型输出未必如此。云、阴影、积雪、季节差异和训练数据覆盖不足都可能造成错误。一个可用的平台应让调用者同时获得预测结果与质量信息，例如置信度栅格、缺测掩膜、输入影像时间、模型版本和处理日志。

评估也不能只随机抽取像元。相邻像元高度相关，随机拆分训练集和测试集容易造成空间泄漏，让指标虚高。更稳妥的方法是按地区、生态区或时间段隔离测试集，并单独检查模型未充分覆盖的地理区域。

全球推理还涉及治理边界。高分辨率结果可能暴露敏感设施、私人活动或脆弱生态区域；不同数据集也有各自的许可条件。上线前应确认数据授权、结果保留周期、访问控制和允许的下游用途。

接入时应先验证什么

采用这类平台时，可以按以下顺序降低风险：

用一个熟悉的小区域建立基准数据，检查坐标、时间和类别定义是否一致。
固定模型、输入数据和预处理版本，确保同一任务能够复现。
测试瓦片边缘、跨坐标系区域、日期变更线和高纬度区域。
设置面积、瓦片数、费用与运行时间上限，并验证取消任务是否真正停止计算。
同时保存预测、置信度和来源元数据，不要只下载最终渲染图。
经过跨区域和跨季节评估后，再逐步扩大覆盖范围。

OlmoEarth 所代表的方向，重点不只是让模型“看懂”遥感影像，而是把这种能力变成可以在巨大空间范围内稳定执行、审计和复现的工程系统。真正决定平台价值的，将是数据契约、异步调度、质量控制和成本边界能否一起工作。