ZenithTrack 固定视口天穹本地优先渲染管线解析

ZenithTrack 是一个独特的天文观测项目，其核心工程挑战在于用极窄视口（固定指向天顶）实时呈现地球自转带来的恒星视运动。与传统天文软件强调交互式浏览不同，ZenithTrack 刻意移除平移和缩放控制，让运动完全来自天体自身的周日视运动。本文聚焦其固定视口渲染管线的工程实现、客户端元数据缓存策略以及本地优先的数据流设计，为构建类似天文可视化应用提供可落地的参数参考。

固定视口的设计逻辑：角速度放大器

ZenithTrack 的核心创意并非全新的渲染引擎，而是一个视角约束的设计决策。传统天文软件允许用户自由控制朝向和缩放级别，ZenithTrack 反其道而行 —— 视口固定于天顶方向（zenith），并采用极窄视场（field of view）。项目作者将这个设计命名为 "角速度放大器"（Angular Velocity Amplifier）：当视场缩窄到只有约 4.33 角分时，地球自转导致的恒星位移在浏览器屏幕上将被放大到肉眼可见的程度。换算关系为：视场宽度 = 屏幕像素 × 单像素角分辨率，在 1000 像素宽的窗口下配合 Pan-STARRS 的 0.26 角秒 / 像素分辨率，刚好得到 260 角秒即 4.33 角分的视场。

这个视场大小的物理含义是：恒星在屏幕上完成一次全屏横移所需时间恰好等于地球旋转相同角度耗费的时间。对于普通天文爱好者，这意味着无需延时摄影或快进播放，只需将页面保持打开，即可直观感受到 "我们没动，是地球在转" 这一基本天文事实。工程上，该设计将视口约束简化为单一参数 —— 当前天顶点的赤经（Right Ascension），所有后续渲染动作都围绕这个单一变量计算。

实际实现中，赤经值由用户地理位置（纬度和经度）结合当前 UTC 时间计算得出。纬度和经度通过浏览器 Geolocation API 获取，经由 sidereal time 算法转换为恒星时，进而求出天顶点的当前赤经坐标。这个坐标以一定间隔（如 100 毫秒或 1 秒）更新，驱动 Leaflet.js 的瓦片加载逻辑重新请求当前天区图像。由于视口极窄，每次需要加载的瓦片数量有限，系统资源占用保持在较低水平。

Leaflet.js 在天球渲染中的适配

选择 Leaflet.js 作为渲染框架是 ZenithTrack 的一个非典型决策。Leaflet 专为地球地图设计，其核心假设是地面为平面且投影局部近似矩形。然而 ZenithTrack 的极窄视场使得这种近似变得可接受 —— 当视场仅覆盖约 4 角分天区时，曲率误差可以忽略不计。项目在技术文档中明确承认这一点：Treat each tile as a rectangle, and the motion as simply linear, which is the same approximation Leaflet uses for navigating on earth。

在实际使用中，Leaflet 的 CRS.Simple 坐标系被设置为无投影模式，瓦片坐标直接映射为天球坐标（赤经 / 赤纬）。底图瓦片来源为 Pan-STARRS 巡天数据的彩色合成图，通过 STScI MAST 档案的 fitscut.cgi 接口实时裁剪获取。每个瓦片请求携带目标天区的赤经、赤纬以及所需的像素尺寸，服务器返回 JPEG 彩色图像后由客户端直接渲染。

关键实现参数如下：Pan-STARRS 原始图像来自夏威夷望远镜 2010-2014 年的巡天观测，单像素分辨率 0.26 角秒，覆盖全天了可观测天区。STScI 提供 g、r、i 三个滤光波段的原始数据，ZenithTrack 组合为真彩色输出。这种数据源的局限性在于 Pan-STARRS 的核心任务是移动天体检测（小行星、近地天体等），而非天文摄影，因此中等亮度以上的恒星普遍存在传感器过饱和问题 —— 这直接导致明亮恒星在图像中呈现为偏绿的过曝像素团。

针对瓦片边缘不完整的问题（某些瓦片存在白色边缘残留），ZenithTrack 在客户端执行两步预处理：白色边缘裁剪和噪声滤波。白色边缘裁剪采用保守策略以避免误切有效像素，噪声滤波则使用激进阈值函数压制暗部噪声。然而过曝像素的拓扑特征（绿色团块被白色区域包围）与真实红矮星的颜色分布存在重叠，简单的颜色阈值无法区分二者，这是项目文档中标注为 "未解决问题" 的已知缺陷。

客户端元数据缓存：50% API 调用削减

一个常被忽视但至关重要的优化是元数据缓存机制。获取 Pan-STARRS 彩色图像需要两步 API 调用：首先通过 ps1filenames.py 接口查询指定天区的 g、r、i 波段原始文件路径（返回 FITS 文件名），随后将文件名传递给 fitscut.cgi 接口请求彩色 JPEG 裁剪图。

这两步调用中，第一步返回的数据是完全确定性的 —— 相同天区坐标始终映射到相同的 FITS 文件集，不随时间变化。ZenithTrack 利用这一特性，将第一步的查询结果预先生成并存储为静态 JSON 文件，按赤纬带（每 10 角分一个文件，覆盖 -30° 到 +90° 全区）组织在 app/metadata/ 目录下。客户端启动时根据用户纬度加载对应赤纬带的 JSON 文件，此后所有图像请求直接跳转到 fitscut.cgi，不再产生元数据查询。

这个设计的工程效果显著：每个用户会话的服务器 API 调用量从每帧两次减少到每帧一次，总调用量削减 50%。考虑到 STScI 作为学术机构服务器需承载来自全球研究者的请求压力，这一缓存策略既保护了公共服务资源，也降低了用户端的网络延迟和失败率。实现上只需在初始化阶段做一次 HTTP HEAD 或预加载验证缓存文件的新鲜度，之后即可安全复用。

需要注意的是，这种缓存策略的前提是数据源本身不变。对于天文图像数据，由于恒星位置在人类时间尺度上相对固定，该前提基本成立。但如果未来项目切换到其他巡天数据源或使用实时更新的星表，则需要重新评估缓存失效策略。

本地优先架构与隐私设计

ZenithTrack 的另一个设计亮点是彻底的本地优先（local-first）架构。项目的技术文档明确声明：用户地理位置信息永远不会离开用户设备，项目服务器（smorgasb.org）不接收、不存储、不处理任何个人位置数据。这是一个通过架构约束而非隐私政策承诺实现的隐私保护 —— 即使服务器被攻陷，攻击者也无法获取用户位置，因为数据根本不经过服务器。

实现层面，浏览器 Geolocation API 获取的纬度和经度仅用于在客户端内存中计算当前天顶点的赤经坐标。这个坐标值仅用于构造 STScI API 请求和 Leaflet 渲染参数，不包含任何用户标识符或持久化存储。当用户关闭页面或切换标签页后，该信息即随浏览器进程一同销毁。

如果浏览器禁止或限制了 Geolocation API 的位置共享，ZenithTrack 会优雅降级为预设的默认地点 —— 英国巨石阵（Stonehenge，坐标 51.18°N, 1.83°W）。选择巨石阵的理由可能与其在天文观测历史上的象征意义有关，而非技术必要性。任何地点都可以作为有效的备用值，用户只需接受一个虚构的 "天顶位置" 即可继续使用应用。

这套本地优先架构的工程启示在于：当数据的隐私敏感性集中在客户端处理阶段时，将计算资源推向边缘是最直接的隐私保护手段。服务端只需提供静态资源和第三方图像 API 的间接调用，完全避免成为用户数据的处理节点或存储节点。

键盘交互与显示模式

ZenithTrack 提供两个键盘快捷键用于控制显示模式：F 键切换全屏模式，C 键切换清屏模式（clear mode）。清屏模式隐藏所有 HUD 元素和信息面板，仅保留天空图像，提供沉浸式观测体验。这两个快捷键通过监听键盘事件在全局范围内响应，适合将页面投影到天花板进行实际天文教学演示的场景。

全屏模式下，浏览器通常会隐藏地址栏和其他系统 UI，最大化画布可用空间。对于天文演示应用，这种全屏独占模式能有效减少视觉干扰，让观众专注于恒星视运动本身。实现上需要注意全屏 API 的浏览器兼容性差异，现代浏览器中通常通过 Element.requestFullscreen() 方法触发，但旧版 Safari 等浏览器需要前缀变体。

工程权衡与可改进方向

ZenithTrack 在设计上做出了若干有意识的取舍。最显著的取舍是放弃对过曝恒星的修复尝试。项目文档记录了多种颜色阈值去噪的失败经验，最终承认当前算法无法完美区分过曝绿色团块与真实红矮星。潜在的改进方向包括基于拓扑特征的更精细图像分析 —— 利用 "绿色像素团块周围必为白色" 这一先验知识构建连通区域检测，或者引入机器学习模型识别真实的恒星信号而非传感器伪影。

另一个可改进方向是离线数据包支持。当前架构依赖实时从 STScI 获取图像瓦片，在网络不佳或离线环境下无法工作。技术上可以预先生成特定纬度范围内的完整天区图像集（按 sidereal day 周期组织），供用户下载后离线使用。这种离线包设计需要权衡存储体积与覆盖率 —— 以 4.33 角分视场为例，覆盖 -30° 到 +90° 赤纬需要约 7200 个独立图像（每个 sidereal day 一帧），总数据量可达数 GB 量级。

最后是定位服务的隐私增强。当前实现依赖浏览器 Geolocation API，该 API 在不同设备和浏览器上的行为差异较大，部分移动设备会直接拒绝所有位置请求。考虑增加手动输入坐标的功能作为补充，同时提供 "拒绝定位后随机分配一个假位置" 的行为选项，可以让用户在不清楚内部逻辑的情况下仍能体验应用（尽管看到的天空可能与实际不符）。

关键参数速查

• 视场宽度：4.33 角分（屏幕像素 × 0.26 角秒 / 像素，约 180 倍放大倍率）
• 恒星全屏横移周期：约 30 秒（地球每小时旋转 15° 的比例计算）
• 元数据缓存覆盖率：-30° 到 +90° 赤纬，每 10 角分一个 JSON 文件
• API 调用优化：每帧从 2 次减少到 1 次，削减 50% 服务器负载
• 快捷键：F（全屏）、C（清屏）
• 默认备用位置：51.18°N, 1.83°W（巨石阵）
• 瓦片来源：Pan-STARRS 巡天数据（STScI MAST 档案）
• 恒星数据库：SIMBAD TAP/ADQL 查询

ZenithTrack 用一个看似简单的约束（固定视口）揭示了天文可视化中一个常被忽视的问题：交互的自由度有时反而阻碍了天体运动本身的感知。通过将控制权交还给自然现象本身而非用户操作，它提供了一种独特的、以体验驱动的天文教育工具。其客户端架构和元数据缓存策略对其他依赖外部图像 API 的可视化项目同样具有借鉴意义。

资料来源

• ZenithTrack 技术文档：https://smorgasb.org/zenith-tech
• ZenithTrack 项目仓库：https://github.com/S1D1T1/ZenithTrack

systems