Show HN爆火：查任意地点上空卫星及实拍影像

一个周末的「摸鱼」项目，在 Hacker News 上拿到了 300 点。作者自称是「卫星极客」，因为周末无聊，就动手写了个东西：输入地球上任意地点，系统会找出过去 7 天内所有飞越该地上空的卫星，并把那些卫星在那次过境时拍下的真实照片一并调出来。

这条发布帖下方聚集了 50 条评论，讨论热度集中在两个方向——工程实现有多硬核，以及这类「地理信息可视化」工具还能玩出什么花样。

这个工具到底能做什么

输入地点，倒查 7 天卫星过境

交互极其简单：在页面上输入任意一个地点，工具会回溯过去 7 天，列出所有从该地点上空经过的卫星。底层用的是 CelesTrak 目录上的 SGP4 轨道传播算法，跟踪的卫星目标超过 1.7 万个，而且全部在浏览器里跑完，耗时大约半秒。

这个响应速度值得多看一眼。1.7 万个运动目标的轨道计算，传统做法要么放到后端排队，要么靠预计算缓存。作者把它塞进了浏览器，意味着按下回车到结果出现之间，几乎感觉不到等待。

SGP4 与 TLE：SGP4（Simplified General Perturbations model 4）是北美防空司令部（NORAD）为近地轨道目标开发的经典轨道传播模型，也是 CelesTrak 提供的标准轨道数据格式 TLE（两行轨道根数）的配套算法。TLE 用平均轨道根数描述卫星在某一历元时刻的状态，SGP4 则把这些根数连同地球非球形引力、大气阻力等摄动项一起外推，算出任意时刻卫星的位置和速度。它的计算量很小、精度对可视化场景足够，因此在卫星追踪工具里被广泛采用。需要说明的是，TLE 本身属于公开数据，精度有限（近地轨道误差可能达公里级），所以这类工具适合做「看过境」而非精密定轨。

照片来自真实过境时刻

工具展示的图片不是示意图，也不是渲染图。它拉取的是 Sentinel-2、Landsat 以及 NASA 的真实影像，对应的是这些卫星在飞越时刻实际拍下的画面。作者在帖子里特意强调，只展示来自「那些具体卫星」的真实照片，不做任何替代或拼接。

这一点决定了工具的可用性边界。它不是一个「给你看个大概」的玩具，而是把卫星轨道数据和公开遥感档案对上了账。

两个硬核的技术细节

GPU 逐帧解 Kepler 方程

作者提到的第一个实现细节是：在轨的全部约 1.7 万个目标，都由 GPU 绘制，并且每一帧都在解 Kepler 方程。

这句话的分量在于「每一帧」。卫星轨道可视化如果只是把星历表插值成动画，计算量大不了多少；但对每个目标每帧求解 Kepler 方程，是实打实的物理计算负载。放到 GPU 上并行，才让这个量级撑得住实时渲染。对做 WebGL 或图形开发的读者来说，这是这条帖子里最值得抄作业的部分。

Kepler 方程：在二体问题中，卫星沿椭圆轨道运动，偏近点角 E 与平近点角 M 之间满足 M = E − e·sin E（e 为偏心率），这就是 Kepler 方程。给定时间对应的 M，需要反解出 E，再换算成真近点角求出卫星在轨道上的位置。这个方程没有解析解，只能迭代求解（如 Newton 法）。对 1.7 万个目标每帧都做迭代，计算量相当可观，而 GPU 的并行架构恰好适合这种「同一套迭代逻辑、作用在大量独立目标上」的负载，用着色器或 WebGPU 通用计算即可批量完成。

修正 5–10 分钟的时间偏差

第二个细节更隐蔽，也更影响结果正确性。Sentinel-2 的影像时间戳，常常和卫星实际穿过你所在位置的那一刻相差 5 到 10 分钟。如果不处理这个偏差，用户看到的「过境影像」在空间位置上就是错位的。

作者说为此做了一些「很酷的数学」来保证站点上的结果准确。帖子里没展开具体方法，但从问题性质推断，这涉及时间戳对齐与地面轨迹匹配——属于那种外行看不出问题、内行一眼就知道糊弄不过去的环节。

Sentinel-2 的时间戳与观测模式：Sentinel-2 是欧空局哥白尼计划下的多光谱成像卫星，双星组网，单星重访周期约 10 天，双星联合约 5 天。它的影像元数据时间通常标记为成像时刻，但整景影像的获取是推扫式的，加上产品生成与元数据记录方式，使得「产品时间戳」与卫星恰好位于地面某点正上方的时刻并不重合。要做「你家上空拍的哪张图」这种点级匹配，必须把影像的成像几何（景中心、成像时间）与轨道星下点轨迹做对齐，这是该修正的核心难点。

隐私与开源

工具不会存储用户的位置信息，这是作者明确给出的承诺。对一个需要输入地理位置的应用来说，这条承诺是必要的，尤其是在浏览器端已经承担了大量计算的背景下。

代码已经公开在 GitHub 上（仓库名 satellites），作者在帖子里直接邀请反馈和贡献。300 点和 50 条评论的组合，对一个周末项目而言已经是相当正面的信号——HN 社区对「自己动手把公开数据用出花」的项目一向不吝点赞。

这类工具的价值在哪

从产品形态看，它踩中了一个被长期忽视的空隙：卫星轨道数据（CelesTrak）和遥感影像档案（Sentinel、Landsat、NASA）都是公开的，但两者之间缺一座桥。普通用户想知道「上周三下午我家上空飞过什么、拍了什么」，过去需要同时懂轨道力学和遥感数据检索，现在只需要一个输入框。

对开发者而言，这个项目的参考意义在于技术选型的胆量。把轨道计算压进浏览器不是必需品——可以偷懒放到服务端——但作者选了更难的路径，换来了半秒级的交互体验。这种「把计算推到离用户最近的地方」的思路，在数据可视化类工具里往往能带来质变。

至于还能往哪走：历史影像的时间轴回溯、特定卫星的订阅提醒、多地点批量查询，都是评论区里可以自然延伸的方向。作者本人在帖尾的态度也很开放——「欢迎反馈、贡献，或者任何你们能给的东西」。