Earths-v1.0 现实地球展示

Wed, 25 Feb 2026 00:00:00 +0000

Earths-v1.0 是一个 3D 可交互的地球可视化项目：把海洋、大气、生物地球化学、地质等公开数据源，投影到一颗可以旋转、缩放、点选的地球上。它首先是一个“展示界面”，不负责实时预测，也不承担具体行业应用；这一版的任务，是把从数据到画面的整条链路搭起来。

但我想在这篇复盘里先把话说透：它看起来是三维的，技术上却仍然停留在“一次展示一个水平高度或一个深度”的阶段。 选择 500 hPa，你看到的是 500 hPa 这一层；选择 1000 m 深度，你看到的是 1000 m 这一层。球体提供了空间参照，却没有提供真正的垂直结构。它是一张会转的图，还不是一个可以切、可以透视、可以做体积渲染的三维地球。

封面图上的“2D”并不是笔误：它恰好说明了这一版的本质——三维的外壳，二维的数据。

严格说，大气用等压面（hPa），海洋用深度（m），两者并不是同一种坐标；但在交互上它们共享同一个“层”的概念，也共享同一个限制：一次只能看一层。这正是 v1.0 与“数字孪生地球”之间最实质的差距。

v1.0 做到了什么，没做到什么

v1.0 的重心是“搭建”和“上手”，所以它先解决的是从 0 到 1 的问题：

用一个统一的地球底座承载不同圈层、不同来源的数据；
支持图层切换、时次切换、水平高度/深度切换；
统一色标、单位、图例和交互方式；
把公开数据源的二维场，稳定地贴到球面上。

它没有解决的是“第三个维度”：

能力	v1.0 的状态
球体旋转、缩放、点选	已具备
多源数据图层	已具备
时间与层级切换	已具备，但一次只显示一层
垂直剖面、帘幕、体渲染	未具备
多圈层耦合分析	未具备
实时预测、同化、集合预报	未具备，留给 v2.0

这不是自我否定，而是给 v1.0 划一条清楚的边界。只有承认它仍然是“球面化的平面展示”，后面才知道该往哪里走。

为什么先从复刻开始

项目初期，团队没有现成的数据管道、设计系统和渲染框架。与其闭门造车，不如把市面上最好的几个地球可视化作品逐个拆开、跑通、复刻。

复刻不是抄界面，而是把别人的工程约束完整走一遍：数据从哪里来、怎么切、怎么传、怎么画、怎么保证时间一致、怎么在浏览器里不卡。四个项目，正好对应四类问题。

1. earth.nullschool：把风画成流动的场

原项目：
我的复刻：
代码库：

这是我理解“风场应该怎么画”的起点。它用粒子平流把不可见的风变成可见的流线，再用多种地图投影把同一份数据放进不同的空间框架里。

图 1：earth-classic.that.earth，全球风场粒子动画与多投影切换。

技术栈。 前端是原生 ES Modules，没有重型框架；渲染以 WebGL / Canvas 2D 混合完成，瓦片和粒子计算放进 Web Worker，避免主线程被动画拖死。它支持从等经纬、正交、立体到 Waterman Butterfly 等 9 种投影，状态通过 URL hash 保存，方便深链和回退。数据侧把 GRIB2/NetCDF 网格切成按变量、时次、层级组织的压缩瓦片，浏览器按需取用。

数据变量。 它把地球数据分成几个模式，每个模式再叠加标量场或矢量场：

模式	主要变量
Air	风场/风速、温度、相对湿度、露点、湿球温度、3 小时降水、CAPE、总可降水量、总云水、海平面气压、体感温度、Misery Index、UV Index、风功率密度
Ocean	表层流、波周期、有效波高、海表温度、海表温度异常、珊瑚白化预警
Chem	一氧化碳、二氧化碳、二氧化硫、二氧化氮、沙尘气溶胶光学厚度、PM1/PM2.5/PM10、有机气溶胶、硫酸盐气溶胶
Space / Bio	极光可见概率、珊瑚白化预警
标注	活跃火点

数据源。 GFS/NCEP、GFS-Wave/WAVEWATCH III、OSCAR v2.0、GEOS-5/GMAO、CAMS/Copernicus/ECMWF、OISST/RTG-SST/OSTIA/CMEMS、NOAA Coral Reef Watch、SWPC OVATION、NASA FIRMS/VIIRS 等。不同变量来自不同机构、不同网格、不同时间分辨率，最后要在同一个球面上对齐——这件事比“画出来”难得多。

我学到的。 一是投影畸变下的粒子平流：同一个风矢量，在球心、球边缘和不同投影里要走不同的路径；二是瓦片与元数据组织：变量、时次、层级、单位、色标必须一起设计；三是“少即是多”的配色，风场本身已经足够复杂，界面要退到后面。

2. Fluid Earth：把大气、海洋、冰冻圈和大气化学放进同一个浏览器

原项目：
我的复刻：
代码库：

如果说 earth.nullschool 是把风画得漂亮，Fluid Earth 更像一个“地球数据浏览器”：它把再分析、预报、卫星海流、海表温度、海浪、永久冻土和大气成分放在同一套图层系统里。

图 2：fluid-earth.that.earth，全球温度场叠加风场粒子，并可切换多种地球科学变量。

技术栈。 前端是 Svelte 5 + Vite 6，WebGL 渲染基于 twgl.js，地理投影和拓扑用 D3；后端是一个独立的 Node 数据服务（tera），负责从 GRIB2、NetCDF 等原始格式解码、裁剪、重采样，再输出带元数据的压缩二进制瓦片。前端通过 inventory 和 topology 知道“有哪些变量、覆盖哪些时间、网格多大”，再按需请求。项目还提供了 Web Component，方便把地球嵌进别的页面。

数据变量。 它的覆盖面很广，而且把“层”组织得很清楚：

圈层	主要变量
大气	10 m 风、10/200/300/500/850 hPa 风与风速、温度、相对湿度、位势高度、海平面气压、CAPE、总可降水量、总云水、降水、日照、臭氧
海洋	有效波高、主浪周期、主浪方向、表层流、海表温度
再分析	ERA5 月平均 2 m 温度、降水及其距平（1959 年至今）
大气化学	地表一氧化碳、沙尘、二氧化硫
冰冻圈/陆地	永久冻土概率、永久冻土分区

数据源。 Copernicus CDS 的 ERA5、NASA GMAO 的 GEOS-FP、NOAA NCEP 的 GFS 与 GFS-Wave、NASA OSCAR 表层流、PANGAEA 永久冻土数据、NOAA RTG 海表温度，以及 Natural Earth 的底图。

我学到的。 地球可视化项目里，后端不是附属品，而是一半的产品。同一个变量可能有多个来源、多个单位、多个时间覆盖范围；如果元数据不统一，前端再漂亮也只是把错误画得更清楚。Fluid Earth 的 inventory 思路，后来直接影响了我对 Earths 数据层的设计。

3. earth-clock：把地球变成一个时钟

原项目：
我的复刻：
代码库：

earth-clock 是四个项目里最“感性”的一个。它不把地球当地图，而是当钟表：太阳和月亮按真实天体位置运动，晨昏线、日食、月食、时区、夜光都被放进同一个场景。你可以把时间加速到一分钟等于一周，也可以把某一次日食逐帧倒放。

图 3：earth-clock.that.earth，基于 Three.js 的 3D 地球、真实太阳光照与时钟界面。

技术栈。 前端是 TypeScript + Three.js + Vite，天气和天文数据由独立的 Node 服务提供；GFS 1° 风场每 6 小时刷新，云图来自 VIIRS 每日真彩拼图或 GFS 云量，极光、火点、气旋、闪电分别接不同的实时源。项目还保留了早期 D3 + Canvas 的 classic 版本，并派生出 Windows 屏保和 Wallpaper Engine 版本。

数据变量。 风场粒子、云量、极光概率、活跃火点、热带气旋及 5 天路径、实时闪电、气压、温度、湿度、可降水量、云水；以及太阳/月亮位置、日月食、晨昏线、时区、夜光等天文与时间图层。

数据源。 GFS、NASA GIBS 的 VIIRS 真彩云图、NOAA SWPC 的 OVATION 极光、NASA FIRMS 火点、NOAA NHC 气旋、Blitzortung 闪电、NASA Deep Star Maps 星空、Natural Earth 海岸线，以及 Meeus 的月球历表算法。

我学到的。 一是把时间当作一等公民：同一个场景里，地球自转、太阳位置、天气图层和日月食必须共享同一个 simulatedTime；二是“真实感”来自物理一致，而不是贴图精度；三是数据新鲜度要能被界面表达——当模拟时间偏离现在超过 24 小时，实时天气图层应该主动隐藏，而不是假装还在更新。

4. Ventusky：产品化的天气预报长什么样

原项目：
我的复刻：
代码库：

Ventusky 是四个项目里产品化程度最高的一个。它不只是“把数据画出来”，而是把多家数值模式的多个时次、雷达拼图、卫星云图、空气质量和海浪等图层，组织成一个普通用户也能用的天气预报产品。

图 4：ventusky.that.earth，多模式温度预报、风场动画与天气图层菜单。

技术栈。 前端以 PHP + JavaScript + Canvas 2D 为主，使用自研的瓦片式渲染和交互层，针对不同模式、不同区域、不同变量做分辨率和时次管理。数据通过 /proxy 反向代理到 static.ventusky.com、data.ventusky.com、api.ventusky.com 等服务，部署在 Netlify 边缘。我的复刻采用“反向代理镜像 + 本地部署”的方式，先把完整的数据与渲染链路跑通，而不是逐行重写。这个选择让我更快地看清它的产品结构，也让我意识到：真正难的不是前端，而是后面的数据服务、模式调度、雷达拼图和授权体系。

数据变量。 温度、体感温度、降水、雷达、卫星、风速、阵风、云量、气压、CAPE/CIN/切变/螺旋度、积雪、湿度、能见度、雷暴、空气质量、海浪/海流/海表温度、极光、太阳辐射等 50 多个图层，并支持地面到高空的多个层次。

数据源。 NOAA 的 GFS/HRRR/RTOFS/STOFS/NBM、DWD 的 ICON、CMC 的 GEM、ECMWF、UKMO、MeteoFrance 的 AROME/MFWAM、挪威气象局、芬兰气象局的 SILAM、Copernicus，以及 GOES/Himawari/Meteosat 卫星和各国雷达网；底图来自 OpenStreetMap。

为什么没有复刻 Windy。 Windy 是唯一一个我停下来的项目。不是前端画不出来，而是它背后的数据服务、瓦片体系、多模式/雷达/卫星/摄像头融合、移动端和商业授权，已经不是一个前端项目能覆盖的。强行做一个“看起来像”的空壳没有意义。这个“没做”的决定，反而让我更清楚地看到这类产品的护城河在哪里：数据管道的深度，决定了产品的上限。

四个项目放在一起看

earth.nullschool：原生 ES Modules + WebGL/Canvas，GRIB2/NetCDF 切成多投影压缩瓦片。学到的是投影畸变、粒子平流和瓦片元数据。
Fluid Earth：Svelte 5 + WebGL + Node 数据服务，原始场转二进制瓦片。学到的是“数据层是一半产品”，元数据必须统一。
earth-clock：TypeScript + Three.js，GFS/实时源 + 天文历表。学到的是把时间当作第一维度，物理一致比贴图精度重要。
Ventusky：PHP + Canvas 2D，多模式、多时次、雷达/卫星融合。学到的是数据服务与运维才是壁垒。
Windy：未复刻。学到的是知道什么时候该停。

这类网站的技术栈与数据管道，接下来会怎么走

把这四个项目放在 2026 年的时间点看，地球可视化正在从“画一张场”转向“管理一个可计算的地球”。变化主要发生在五层。

1. 渲染：从 Canvas 到 WebGPU

Canvas 2D 解决了“能画”，WebGL 解决了“画得快”，WebGPU 正在解决“画得复杂”。WebGPU 把 compute shader 带进浏览器，粒子平流、体积渲染、三维粒子追踪、实时等值面才有可能在消费级设备上跑起来。与此同时，WASM 把 GRIB、NetCDF、Zarr 的解码能力带到客户端，OffscreenCanvas + Worker 让渲染不阻塞交互。Three.js、Cesium、deck.gl 负责场景与图层，WebXR 则把同一个数据地球带进头显。

2. 数据：从文件到云原生 ARCO

过去的主流做法是“下载 GRIB2/NetCDF → 服务端转成私有瓦片 → 浏览器取瓦片”。下一步更可能是“对象存储 + 云原生分块格式”：Zarr/Icechunk/Kerchunk 负责多维数组，COG/COPC 负责影像与点云，STAC 负责目录与发现，浏览器按 chunk 做范围请求。数据不再被转换成某个项目私有的瓦片，而是以接近原始组织的方式被直接消费。元数据——CF 约定、单位、坐标、时间、缺失值——会比像素本身更重要。

3. 管道：从定时脚本到事件驱动

数据管道会从“cron 定时跑脚本”变成“模型跑完就触发”的事件驱动系统：增量更新、质量控制和血缘追踪成为标配，Airflow/Prefect/Dagster/Temporal 负责编排，多模式、多时次、集合预报、雷达/卫星/站点融合在同一个图里管理。边缘缓存和 CDN 负责把最近一次结果推到离用户最近的地方，成本可观测性则决定这套系统能不能长期跑下去。

4. 维度：从单层切片到 3D/4D

这是 Earths-v1.0 最需要补的一课。真正的三维地球需要：垂直坐标（等压面、高度、深度、地形追随坐标）、任意剖面、帘幕、等值面、体渲染、拉格朗日轨迹、时间插值、LOD 和渐进加载。数据量会涨一到两个数量级，必须靠分块、压缩和 GPU 一起解决。再往后是集合预报和不确定性可视化——不是画一条“最可能的路径”，而是画出一簇可能的世界。

5. AI：让数据更多，也让“画清楚”更难

GraphCast、Pangu-Weather、AIFS、FuXi 这类 AI 天气模型，让预报更快、更便宜，也让可视化面对更多成员、更高频次、更大不确定性的数据。AI 可以做降尺度、偏差校正、学习式压缩，但“把不确定性画清楚”仍然是难点。AI 不会自动让可视化更清楚，它只会把“数据太多、维度太多”的问题放大。

层次	现在 → 正在发生
渲染	Canvas/WebGL → WebGPU、compute shader、WebXR
数据格式	GRIB2/NetCDF → 私有瓦片，走向 Zarr/Icechunk、COG/COPC、STAC
传输	静态瓦片 + CDN → chunk 范围请求、边缘计算、流式
计算	服务端 ETL → WASM 客户端解码、serverless
编排	cron → 事件驱动、增量、血缘、质量控制
维度	2D 单层 → 3D/4D、体渲染、集合与不确定性

回到 Earths-v1.0：下一步不是把球做得更炫

v1.0 的价值，是把“多源公开数据 → 统一地球界面”这条路走通了。它证明了球体可以成为共同底座，但也暴露了真正的瓶颈：数据模型还是二维的。只要数据仍然是“一层一层”的，界面再三维，认知仍然是平面的。

下一步我会优先做四件事：

把“层”变成真正的维度。 以 CF/STAC 为骨架统一网格、单位、时间和垂直坐标，让 level/depth 成为数据模型的一等字段，而不是界面上的一个下拉框。
补上三维表达。 剖面、帘幕、等值面、体渲染、GPU 粒子；从“看一层”变成“切一个体”。
把管道云原生化。 原始 GRIB/NetCDF 不再落成一堆私有文件，而是按 chunk 组织、增量更新、事件驱动；前端按需取，不再全量预生成。
从“看”走向“算”。 接上 v2.0 的实时预测和 v3.0 的数字孪生，把预报、集合、不确定性和决策放进同一个界面。

v1.0 是地基，不是终点。它的意义不在于假装自己已经是数字孪生，而在于把通往数字孪生的第一段路走完，并且清楚地知道下一段路在哪里。

附：站点与代码

项目	站点与代码
Earths-v1.0
earth.nullschool 复刻	·
Fluid Earth 复刻	·
earth-clock 复刻	·
Ventusky 复刻	·

文中截图摄于 2026 年 10 月 22 日，实时数据以站点当前显示为准。

WebGL | YHK's life