在无线规划、户外导航与地理可视化领域，实时计算特定观测点的可见范围（视域分析）至关重要。HeyWhatsThat 作为一项经典的在线天际线可视化服务，以其基于 SRTM 高程数据、融合地球曲率与大气折射的精确计算而闻名。然而，其在线依赖性与有限的坐标系支持，促使我们思考：能否构建一个可完全离线运行、并原生支持 WGS84、UTM 及 Web Mercator 等多种地理坐标系转换的 3D 地形渲染与遮挡计算引擎？本文将拆解 HeyWhatsThat 的核心逻辑，并详细阐述这样一套引擎从数据准备到实时渲染的完整技术实现路径。
一、数据基石：离线高程数据处理与金字塔构建
一切始于数据。HeyWhatsThat 使用美国地质调查局（USGS）的航天飞机雷达地形测绘任务（SRTM）数据，其技术文档证实了这一点。为了离线化，我们首先需要建立本地的 DEM（数字高程模型）处理流水线。核心步骤包括：
- 数据获取与标准化：收集 SRTM GeoTIFF 或其他格式的 DEM 数据。使用 GDAL 等工具，将所有数据统一转换至 WGS84 地理坐标系（EPSG:4326），这是后续所有坐标转换的基准。
- 构建多级金字塔：为了支持大规模地形的实时浏览与细节层次（LOD）渲染，必须对原始 DEM 进行重采样，构建金字塔。例如，Level 0 为原始分辨率（如 30 米），Level 1 降采样至 60 米，依此类推。每一级都覆盖相同的地理范围，但分辨率逐级降低。
- 瓦片化切割：对金字塔的每一层，按照固定尺寸（如 256x256 像素或高程点）进行规则网格切割，生成地形瓦片。每个瓦片文件应包含其地理范围（经纬度边界）和对应的高程值矩阵。为了极致优化，可将高程值量化为 16 位整数存储，并记录最小高程值和缩放系数以还原真实高度。
经过此流程，我们得到了一套组织有序的 (z, x, y) 瓦片数据集，其中 z 代表层级，(x, y) 代表瓦片索引。这套离线数据仓库是引擎运行的基石。
二、引擎核心：多坐标系转换与统一空间参考
HeyWhatsThat 主要服务于 Web 端，其投影处理兼顾了 Google Earth 的 Plate Carrée 和 Google Maps 的 Web Mercator。对于一个通用的离线引擎，我们需要更强大的坐标系转换能力，特别是在工程测绘中广泛使用的 UTM 坐标系。
引擎内部应设计一个统一的空间参考层，通常以 WGS84 经纬度（弧度制）作为中间表示。转换算法需完全离线实现，核心包括两套：
- WGS84 ↔ Web Mercator (EPSG:3857)：这是大多数 Web 地图的投影标准。其转换公式相对简单，基于球体模型。正算公式为：
x = R * lon，y = R * ln(tan(π/4 + lat/2))，其中R为地球半径（6378137 米）。反算则为上述的逆过程。此公式计算高效，足以满足可视化精度需求。 - WGS84 ↔ UTM：UTM 采用横轴墨卡托投影，基于 WGS84 椭球体参数，精度更高。转换涉及复杂的椭球体计算，包括子午线弧长公式、偏心率等参数。正算过程需要根据经度计算 UTM 带号，确定中央经线，然后通过一系列展开式计算东偏移和北偏移。反算则需要迭代求解。尽管复杂，但已有成熟的算法库（如 PROJ）或可嵌入的轻量级实现可供参考或移植。
通过将经纬度作为枢纽，引擎可以轻松实现 UTM 坐标与 Web Mercator 坐标之间的间接转换，满足不同应用场景的数据输入与输出需求。
三、渲染管线：WebGL 地形渲染与实时视域分析
有了数据和坐标转换能力，下一步是实现地形的 3D 可视化与实时分析。这依赖于基于 WebGL 的渲染管线。
1. 地形网格生成与 LOD 管理 前端（或离线桌面应用中的渲染线程）根据当前视点位置和视角，动态决定需要加载和渲染哪些地形瓦片。这里采用四叉树结构管理瓦片：
- 视锥体裁剪：只加载与相机视锥体相交的瓦片，忽略视野外的数据。
- LOD 选择：根据瓦片中心与视点的距离（或屏幕空间误差）决定使用金字塔中的哪一级细节。距离越近，使用越高分辨率（更低层级）的瓦片。
- 裂缝消除：不同 LOD 级别的瓦片边界可能产生裂缝。通用解决方案是在瓦片网格边缘添加 “裙边”（skirt），或强制相邻瓦片在边界处使用相同的顶点高度。
每个瓦片的高程数据在 GPU 端通过顶点着色器转换为三维顶点。一种高效做法是向着色器传递一个规则平面网格和对应瓦片的高程纹理，在着色器中采样纹理并置换顶点位置。
2. 视域分析（遮挡计算）集成 HeyWhatsThat 的核心功能 —— 计算可见范围（visibility cloak）—— 可以在我们的离线引擎中以更高性能实现。一种方法是在 GPU 上进行并行计算：
- 将观测点位置和高度传入计算着色器。
- 对目标区域（或当前加载的地形瓦片）的高程数据进行遍历，对于每个潜在目标点，在着色器中执行视线（Line-of-Sight）分析，考虑地球曲率（使用 WGS84 椭球模型）和固定的标准大气折射系数（如 HeyWhatsThat 采用的约 14% 曲率抵消量）。
- 输出一个布尔纹理或缓冲区，标记每个点是否可见。此结果可以实时叠加渲染到 3D 地形上，形成动态的 “可见性披风”。
对于需要更高精度或复杂折射模型的场景，也可在 CPU 端使用优化后的算法进行预计算，并将结果作为纹理提供给 GPU 渲染。
四、实现参数与监控要点
构建此类引擎时，以下参数需要根据实际场景仔细调优：
- 瓦片尺寸：256x256 是平衡内存、网络（或磁盘 I/O）与绘制调用（Draw Call）的常见选择。可考虑提升至 512x512 以减少瓦片数量，但会增加单次加载数据量。
- 金字塔层级与最大分辨率：取决于原始数据精度和最小可视化尺度。例如，SRTM-1arcsec（约 30 米）数据，可构建从 Level 0（30 米）到 Level 5（约 960 米）共 6 层金字塔。
- LOD 切换阈值：建议基于屏幕像素误差。例如，当瓦片在屏幕上的投影误差超过 2 个像素时，切换到更精细的层级。
- 视域分析采样间隔：平衡精度与性能。HeyWhatsThat 使用 3 角秒（约 90 米）的栅格，在中等尺度上已足够。引擎可根据分析范围动态调整采样率。
监控与调试至关重要：
- 性能面板：实时显示帧率、加载中的瓦片数、GPU 内存使用量、Draw Call 数量。
- 坐标校验工具：在界面中标注光标所在点的 WGS84、UTM、Web Mercator 坐标，并与专业工具（如 QGIS）比对，确保转换准确性。
- 视域分析验证：在已知观测点，将引擎计算结果与 HeyWhatsThat 在线服务或实地勘测数据进行对比，校准折射模型等参数。
结语
从 HeyWhatsThat 这一优秀的在线服务中获得灵感，我们系统地勾勒出了一个功能更强大、更独立的离线 3D 地形渲染与遮挡计算引擎的蓝图。它剥离了网络依赖，内嵌了多坐标系无缝转换能力，并提供了从海量 DEM 数据处理到 GPU 加速实时分析与可视化的完整解决方案。虽然实现这样的引擎需要跨越地理信息、图形学与高性能计算的领域知识，但其带来的自主性、定制化潜力与性能提升，对于专业的地理空间分析应用而言，无疑是值得投入的方向。未来，随着 WebGPU 等更底层图形 API 的普及，此类引擎的性能边界还将被进一步拓展。
参考资料
- HeyWhatsThat Technical FAQ. http://www.heywhatsthat.com/techfaq.html (揭示了高程数据源、投影处理及折射计算模型)。
- 关于 WGS84、UTM 与 Web Mercator 坐标系转换的算法总结。