Planet Labs 的开放卫星影像源
文章摘要
Mark Litwintschik 是一位 Big Data、AI、GIS 和网络方向的顾问，他的博客以”每一步都能照着复现”著称。这篇文章带读者用命令行工具走一遍 Planet Labs 的开放灾害影像数据源（Disaster Data feed）。
背景。Planet Labs 是一家成立 15 年、总部在旧金山的卫星制造商兼星座运营商，历史上运营过四个不同的星座，每天拍摄地球全部陆地。作者顺手做了一个很有 Planet 风格的事：用 wget 拉下 Planet 的星历服务发布的 TLE 文件，从中提取 NORAD ID，再用 DuckDB 去 GCAT 的 satcat.parquet 里把这些卫星的详细信息查出来。结果是 97 颗仍在轨的卫星，从 2013 年发射的 SkySat A 到 2026 年 7 月 7 日由 SpaceX Transporter 17 任务部署、进入希腊上空低低地球轨道的 Pelican-11。表格清楚地显示出几代硬件的差别：SkySat 系列质量 90–110 公斤，占绝大多数的 Flock（Dove/SuperDove 立方星）只有 5.7 公斤、0.3 米长，而 Pelican、Tanager、Edda 这一代是 150–160 公斤、2.3 米长、翼展 3 米，轨道高度普遍在 500 公里出头、倾角约 97.4 度（太阳同步轨道）。高光谱的 Pelican 星座与其他星座不同，能捕捉 426 个光谱波段。
这次的主角是灾害数据源。Planet 去年宣布了这个 feed：由 Cloudflare 托管、对 DuckDB 和 QGIS 友好，包含他们在各类自然与人为灾害发生后不久拍摄的部分影像，描述影像的元数据以 Parquet 和 JSON 形式发布。作者用 wget 拉下 catalog.json，再用 jq 提取链接、过滤出灾害事件的 URL slug，得到今年的完整清单：哥伦比亚地震（2026-08-10）、吉伦特野火（2026）、飓风 Melissa（2025）、尼泊尔山洪（2026-08-26）、菲律宾地震（2026-06-08）、委内瑞拉地震（2026-06-24）。
事前底图（pre-event basemaps）。每个事件文件夹里的资产类型不尽相同。哥伦比亚和委内瑞拉两个事件带有底图——这是把一段时间内拍摄的多张卫星影像拼接成的镶嵌图，目标是尽可能少的云遮挡。委内瑞拉的底图覆盖 280 公里海岸线、向内陆延伸最多 52 公里；哥伦比亚的底图以瓦片形式发布，共 93 个 GeoTIFF 加对应的 JSON 元数据。作者展示的单条记录是一份标准的 STAC Feature：包含 thumbnail 和 visual 两种资产（后者是真彩色 RGB 的 Cloud-Optimized GeoTIFF）、bbox、几何、采集时间区间、星座名（planetscope）、地面采样距离（约 4.78 米）、投影 EPSG:3857、4096 × 4096 的形状，以及 pl: 前缀的 Planet 专有字段（镶嵌图名、quad id、覆盖百分比）。
处理流水线。作者的做法很能代表现代地理空间工作流：用 DuckDB 从 items.parquet 里 UNNEST 出所有 visual 资产的 URL，管道给 xargs 用 8 线程并行 wget，得到 1.7 GB 的 GeoTIFF；再用 gdalbuildvrt 拼成一个 VRT，用 gdal_translate 输出为采用 WEBP 压缩的 COG——他指出这能把文件体积减少 80% 以上而外观变化极小，最终单文件 327 MB。元数据侧同理：把所有 JSON 下载下来、用 jq 压成一行行的 JSONL，再用 DuckDB 把 GeoJSON 几何转成空间类型、以 ZSTD 级别 22 写成 Parquet，然后用 SUMMARIZE 统计每个字段的唯一值数量和极值。他还给了一条容易被忽略的元数据解读：datetime 字段看起来是镶嵌图中最旧影像的时间戳，而 end_datetime 看起来是镶嵌图发布时间或其中最新影像的拍摄时间。
事前/事后影像与可用数据掩膜。任何事件的资产分成事前和事后两大类，作者用尼泊尔山洪的事后影像做演示：一个 83 KB 的 Parquet 元数据文件里有 24 条记录，资产包括 pansharpened（全色锐化）的 GeoTIFF。这些影像拍摄于不同时间，有些彼此重叠。下载后总计 1.9 GB。他很坦率地指出这批影像的局限：拍摄时云量很大，但受山洪影响的一些聚落仍然可见。
这就引出了文章最实用的一节——可用数据掩膜（UDM）。上述每张影像都有对应的 UDM，用来指出影像中被云覆盖的区域（这批 UDM 共 49 MB）。读法是：黑色区域能清晰看到地表，白色被云遮挡，灰色则根本没有影像数据。来自 PlanetScope 和 Tanager 星座的影像配的是 UDM2，除了云之外还能识别阴影、雾霾和积雪。
文章还老老实实交代了工作环境（AMD Ryzen 9 9950X、96 GB DDR5、Crucial T700 NVMe，在 Windows 11 的 WSL Ubuntu 24 LTS 上跑）、软件版本（GDAL 3.9.3、DuckDB 1.5.4 加 h3/lindel/json/parquet/spatial 扩展、QGIS 4.2.1），以及数据来源（边界与地名用 Natural Earth，地震数据来自 USGS，海洋边界来自 Marine Regions）。他特别提醒：GDAL 3.12 对 CLI 做了大改，文中的命令在新版本上可能需要调整。
HN 评论精华
这条帖子拿到 187 分，但只有 34 条评论，且讨论重心明显不在文章的技术步骤上——而是转向了”普通人和小机构到底能不能买得起卫星影像“。
对博客本身的评价。jjwiseman 说”Mark Litwintschik 的博客是互联网上最好的工程博客之一，永远实用，写得足够详细以至于工作流很容易复现”。Avicebron 的评价更有时代特征：”读起来清爽地不像 AI 写的。如果有人问我’软件工程长什么样’，我会指向这篇。”moffkalast 用一句玩笑佐证了这一点：”这不是 AI，这哥们在他写的每一篇文章里都要炫耀一遍他的工作站，从我记事起就这样。”ge96 说自己学到了两个新的文件扩展名：.tle 和 .parquet；coinfused 顺势分享了一个组合技——DuckDB + Parquet + HTTP range 请求，他正在用它做浏览器里跑的数据探索工具，”是个很棒的组合”。
最有价值的一整条线：非营利组织买不起影像。smallerfish 说他与人共同运营一家关注拉丁美洲毁林问题的保护类非营利组织，他们负担得起的选项只有三个：两年前的 Google Earth 影像、10 米分辨率的 Nimbo 影像（还行，但细节不足以作为证据）、以及 Sentinel-1 的 SAR 数据（有用但噪声很大）。而 Planet 给他们的报价大约是每年 3 万美元，还只覆盖他们监测范围里约 5% 的一段海岸线，在现行定价模式下完全不可行。
这条评论引来了整个帖子里最实在的一组回复。文章作者 marklit 本人回复问他们的预算量级，并透露自己去年为加拿大的电信项目调研过大约 19 家影像公司——”有私人飞机能拍 10 厘米影像，还能挑最理想的天气窗口起飞；也有公司在离地 20 到 80 公里放气球，能拍 4 厘米影像。这个领域相当热闹。”smallerfish 回答说他们靠志愿者和个人捐赠运作，比较拮据，大概能撑到每年 1 万美元左右，并说飞机/气球这个角度他没想到、会去查查。
sveme 补充了这个市场的全貌和残酷现实：从卫星星座定向拍摄，到 Planet 等公司的底图，到 Sentinel 家族，到航空影像、直升机、无人机甚至飞艇，”它们各自有独特的成本、分辨率、覆盖面积、重访率和光谱模式组合，有时候很难为手头的问题找到合适的那个。明确的是分辨率和重访率都与成本正相关。这玩意儿很贵。”
notahacker 给出了这条线里最专业的建议（他自称曾在这个领域做非技术岗）。第一，先和 Planet 的客户经理谈需求——当他们意识到你没有理想数据的预算但可能是一个持续的收入来源时，会比标价灵活；而且对地观测市场的竞争正在加剧。第二，如果目的是取证，可以考虑用 Sentinel-1 加 Nimbo 的数据把全森林范围过滤缩小到具体的兴趣区，再对那些小区域争取更高的空间/时间分辨率——他引用一位老同事的说法：”要在草堆里找针，先把草堆移走。”而且缩小到具体区域本身，可能成为你把问题上报给另一个有预算、有动机的机构的路径。第三，可以通过与有公共资助研发项目的对地观测咨询公司合作来获取理想的商业数据——他举例说 ESA 投入了大量资金让私营联合体去证明 Copernicus 数据（必要时结合其他数据）能产出有用的结果（对欧洲机构更容易，但不是硬性前提）。
其他人也给出了具体线索：noodlesUK 说他们作为普通客户从 SkyWatch 拿到过便宜的高分辨率存档影像（但面积很大时价格会涨得厉害）；guhidalg 直接推荐了微软的 Planetary Computer 并披露那是他的团队在运营；lmc 提到 ICEYE 这家高分辨率商业 SAR 星座，他们有毁林监测服务，还与珍·古道尔研究会有合作，或许可以从这个方向接触。Melatonic 提了个更”当代”的思路：用 Sentinel 的低分辨率数据配合 AI 超分辨率算法，再喂进高分辨率但年代较老的影像作为参照，甚至用多个年份的高低分辨率数据对来训练，可能可以近似推断出当前的高分辨率画面；他还补了一句”假彩色红外数据在这里可能特别有用”。
Flock 的命名误会。ricardobeat 问 Planet 目前在轨的卫星是不是大多在为 Flock（那家美国监控公司）服务，还是只是名字撞车。回答很一致且很有说服力：mandevil 解释 Flock 是 Planet 给那批由 3U 立方星组成的巨型成像星座起的名字，这些星星叫 Dove（鸽子），所以整个星座叫 Flock（鸟群），与那家车牌自动识别公司毫无关系。marklit 也确认与那家街道监控摄像头公司无关。fnands 给出了最完整的答案：Planet 用鸟类给所有星座命名（Dove、Pelican、Tanager、Owl——SkySat 是收购来的，所以不遵循他们的命名惯例），因此他们把星座描述为 Flock。hangonhn 从商业逻辑上佐证：”你不会用一个客户的名字给卫星命名，尤其当你的生意是卖影像和数据而不是卖卫星的时候。而且一群卫星叫 flock 很合理。”
一条直指数据本身陷阱的技术评论。aysanz 提出了文章里没有展开、但对实际使用至关重要的两点。第一，这些记录里的 geometry 和 bbox 不是同一个形状，如果你要建索引就会出问题。他对文中那条尼泊尔的 Pelican 影像轮廓跑了一遍鞋带公式，发现外接矩形的面积比实际轮廓大约大 40%，也就是说那个框里超过四分之一的地面背后根本没有像素。而那一景还只是偏离天底 3.8 度；文中后面的 summarize 表里有些高达 28.9 度，那些会偏得更厉害。他指出索引 bbox 是显而易见的做法——它只有四个数字，任何数据库都能给它建 R 树——但覆盖查询于是会把某些景返回给你的兴趣区，而文件在那一部分其实是空的。”我花了比应该花的更长的时间才搞明白为什么我的镶嵌图上有个洞。”第二，eo:cloud_cover 是整景一个数，靠它排序来找小范围内最清晰的选项是靠不住的——85% 的云量在你想看的那一小块上仍然可能是晴的。UDM2 给的是逐像素的信息，但那意味着在排序之前，每个候选景都得额外打开第二个栅格文件。
此外 maelito 提到了另一个相关项目（Mapterhorn 的高清晰卫星 PMTiles，尚未发布），som 指出它目前似乎只聚合欧洲数据、且叠在一个低分辨率的 Planet 底图上，并问 PMTiles 对卫星影像是否合适；wkrp 回答说他发现 PMTiles 对栅格瓦片很有用，易于托管，配上好的 CDN 性能极佳。neets 留下了一条冷冷的观察：”人们想看地球上的哪里，本身对情报界就是相当有价值的信息“——就像那些能跨社交网络查用户名的 OSINT 数据库一样。