高程+着色+矢量设计方案 1.1

我更推荐你采用第二种：

以当前 GPS 为中心，读取固定半径范围内的高程，生成一整块地形 mesh

并且配一个简单的：

displayBounds + loadedBounds 缓存

也就是：

显示范围：当前真正要看的范围
加载范围：比显示范围大一圈，用来减少频繁重读

1. 结论先说

对于你现在的条件：

只有一整块 elevation.tif
不使用影像瓦片
只做高程 + 着色 + 矢量
以 GPS 为中心显示

推荐优先级是：

GPS 中心固定范围方案  >  5x5 / 7x7 虚拟瓦片方案

原因是：你的数据天然不是瓦片化的，业务目标也不是瓦片地图，而是当前位置附近的三维地形显示。

2. 两种方案适用场景对比

对比项	5x5 / 7x7 虚拟瓦片	GPS 中心固定范围
数据要求	适合瓦片化数据或未来要瓦片化	适合单块 DEM
架构复杂度	较高	较低
是否需要 TileKey	需要	可不需要
是否需要 TileSchema	需要	可不需要
是否适合一整块 tif	可以，但有点绕	非常适合
是否适合 GPS 周边显示	可以	很适合
mesh 数量	多个 tile mesh	一个或少数几个 mesh
缓存策略	tile 复用	范围缓存
LOD 扩展	更标准	也能做，但要另行设计
大范围漫游	更好	中等
实现难度	中高	低到中
推荐程度	后续扩展型	当前最推荐

3. 为什么不优先推荐 5x5 / 7x7？

因为你的项目条件已经变了。

旧项目里的 5x5 / 7x7 主要是为了解决：

影像瓦片 + 高程裁剪 + 局部 mesh 复用 + 跨 tile 切换

它的核心前提是：

地图数据本身就是瓦片化组织的

但现在你说：

高程只有一整块 tif
不使用影像
只做高程着色

那继续设计 TileKey、TileSchema、displayTileKeys、preloadTileKeys，会带来额外复杂度。

你会多出很多概念：

虚拟瓦片
瓦片行列号
中心 tile
瓦片边界
瓦片过滤
瓦片 mesh 复用
瓦片间拼接

这些不是不能做，而是现在没有必要先做。

4. 为什么推荐 GPS 中心固定范围？

因为它和你的目标最匹配。

你的目标可以理解成：

围绕当前 GPS 显示附近地形

那最自然的数据结构就是：

当前位置
    ↓
显示半径
    ↓
高程裁剪范围
    ↓
地形 mesh

而不是：

当前位置
    ↓
虚拟 tile
    ↓
5x5 tile
    ↓
7x7 tile
    ↓
tile mesh 列表

第二条链路更长。

5. 推荐的最终方案

我建议采用：

GPS 中心范围 + 扩大加载范围缓存 + 单块/分块 mesh

具体设计：

displayBounds：真正显示的范围
loadedBounds：实际从 DEM 读取的范围，比 displayBounds 大
safeBounds：判断是否需要重读的安全范围

示意：

+----------------------------------+
|          loadedBounds            |
|                                  |
|      +--------------------+      |
|      |     safeBounds     |      |
|      |                    |      |
|      |    +----------+    |      |
|      |    | display  |    |      |
|      |    |  GPS *   |    |      |
|      |    +----------+    |      |
|      |                    |      |
|      +--------------------+      |
|                                  |
+----------------------------------+

只要 GPS 还在 safeBounds 内：

不重新读取 elevation.tif
不重新生成大 mesh

GPS 离开 safeBounds 后：

重新以 GPS 为中心读取一块新的高程区域
重新生成 mesh

6. 推荐参数

如果你是低空飞行或导航场景，建议先用：

显示范围 displayBounds：
前方 10km
后方 3km
左侧 5km
右侧 5km

加载范围 loadedBounds：
前方 14km
后方 5km
左侧 7km
右侧 7km

mesh 网格：
交互 129 x 129
最终 257 x 257

如果先做最简单版本：

displayBounds：10km x 10km
loadedBounds：14km x 14km
mesh：257 x 257

这样实现最稳。

7. 数据流建议

GPS lon/lat
    ↓
转换为 DEM 坐标 mapX/mapY
    ↓
计算 displayBounds
    ↓
判断 GPS 是否仍在 safeBounds
    ↓
如果在：复用当前 ElevationBlock 和 TerrainMesh
    ↓
如果不在：计算 loadedBounds
    ↓
从 elevation.tif 读取 loadedBounds
    ↓
生成 TerrainMesh
    ↓
读取/筛选矢量
    ↓
矢量贴地
    ↓
渲染

8. 一个关键建议：mesh 不一定只做一个

虽然我推荐“GPS 中心固定范围”，但 mesh 可以有两种实现。

方案 A：一个大 mesh

loadedBounds -> 一个 TerrainMesh

优点：

最简单。
管理方便。
第一版推荐。

缺点：

每次重建时整个 mesh 都要重建。
后续 LOD 不够灵活。

适合第一版。

方案 B：范围方案 + 内部分块 mesh

loadedBounds -> 内部分成 4x4 或 8x8 小 mesh

注意，这不是 5x5 / 7x7 瓦片缓存，而只是渲染内部切块。

优点：

可做视锥裁剪。
可做不同区域 LOD。
可减少单个 mesh 太大问题。

缺点：

实现稍复杂。

可以第二阶段再做。

9. 什么时候应该选 5x5 / 7x7？

如果以后你要做这些，再考虑 5x5 / 7x7：

高程数据未来会切成瓦片。
影像瓦片未来可能加回来。
地图范围非常大，需要长距离连续漫游。
要做标准地图瓦片体系，比如 L/Z/X/Y。
要做多级 LOD tile。
要做磁盘级 tile cache。
多个视口/多用户共享瓦片缓存。

这些情况下，瓦片体系更合适。

10. 什么时候应该选 GPS 中心固定范围？

你的情况基本都符合：

只有一个大 DEM。
不用影像。
主要围绕当前 GPS 看地形。
只需要高程着色。
只需要叠加矢量。
希望项目简化。
不想处理瓦片边界和索引。

所以更应该选它。

11. 我的最终推荐

建议分阶段：

第一阶段：GPS 中心固定范围

做：

一个 elevation.tif
一个 displayBounds
一个 loadedBounds
一个 TerrainMesh
高程着色
矢量贴地

不要做：

TileKey
TileSchema
5x5
7x7
ImageTile
纹理

目标是先把核心三维地形链路跑通。

第二阶段：范围缓存优化

加入：

safeBounds
GPS 移出 safeBounds 后才重读
交互 129x129
最终 257x257

第三阶段：内部 mesh 分块

如果性能不够，再把 loadedBounds 内部拆成：

4x4 mesh
或 8x8 mesh

用于：

视锥裁剪
局部更新
LOD

但这不是必须一开始就做。

12. 一句话结论

推荐“以当前 GPS 为中心读取固定半径范围”的方案。

对你当前项目最合适的设计是：

单块 DEM + GPS 中心范围 + 扩大加载范围缓存 + 高程色带渲染 + 矢量贴地