尧图网页设计 
简介面向Cesium地形开发者的瓦片生成工具重点解决TIFF高程数据到Cesium可加载Terrain格式的转换问题。工具附带CTB运行库及完整依赖能将激光雷达或卫星遥感获取的数字高程模型按层级切分为瓦片便于Web端按需加载。压缩包共108个文件大小16.17MB其中包含40个dll运行库、4个exe可执行程序、29个csv坐标与投影参数文件以及gfs、wkt等地理数据描述配置从数据解析、坐标系定义到地形服务发布均有覆盖。已有2368人浏览学习适合GIS开发者、三维可视化工程师以及需要自定义地形的Cesium前端用户。借助该工具可生成JSON或Binary格式的地形瓦片在Cesium中配置Terrain服务URL即可加载渲染显著降低高程数据接入门槛同时可用于测绘、城市规划、环境监测、灾害模拟等场景支持将自有高程数据快速集成进三维地球应用实现流畅的LOD地形过渡与批量瓦片发布。1. Cesium 地形加载的卡点为什么 tif 高程数据不能直接丢给 Cesium拿到一块本地 tif 高程数据想在 Cesium 里看到起伏的真实地形第一反应往往是直接把 tif 丢给CesiumTerrainProvider。结果就是一片黑屏或者直接报错原因很简单Cesium 原生不认栅格 DEM它只认切片好的地形瓦片服务而这个切片过程基本绕不开cesium terrain builder以下简称 CTB这类瓦片地形生成器。CTB 的价值在于把 GeoTIFF 格式的高程数据转换成 Cesium 能直接加载的 quantized-mesh 瓦片附带 tileset.json 索引文件最终扔到任意静态服务器上就能用。这篇文章适合手里有 tif terrain 高程数据、想在自己的 Cesium 项目里加载离线地形的开发者也适合想搞清楚 CTB 参数边界、避免反复翻车的从业者。下面从数据预处理、CTB 实操、Cesium 接入到避坑逐层拆一遍。2. 高程数据预处理把杂乱的 tif 变成 CTB 吃得动的 DEM2.1 先从坐标系说起CTB 默认只认 WGS84CTB 的输入数据默认要求是 WGS84 经纬度坐标系也就是 EPSG:4326。很多人从国家地理信息公共服务平台或者 NASA 下载的 DEM 数据投影五花八门常见的有 UTM、Web MercatorEPSG:3857、Albers 等。如果直接丢给 CTB生成出来的瓦片位置会出现几十到几百公里的偏移而且完全看不出来是坐标系问题——因为 CTB 不会报错它只是按经纬度把数据硬切片。用 GDAL 工具先查看数据的坐标系这是我每次处理地形数据的第一步gdalinfo input.tif | grep -E EPSG|Origin|Pixel Size|Size is我需要重点看三行Coordinate System是否带EPSG:4326、Origin的纬度是否在 -90 到 90 之间、像素分辨率大约是多少。如果坐标系不是 WGS84就需要重投影用gdalwarp处理gdalwarp -t_srs EPSG:4326 -r bilinear input.tif output_wgs84.tif这里-r bilinear指定重采样算法为双线性对地貌起伏的平滑性保持比较好。如果原始数据是山地区域用-r cubic效果更圆润但处理时间会明显增加。对地形这种连续表面来说不建议用 nearest否则生成的瓦片边缘会呈现明显的台阶状瑕疵。2.2 裁剪与合并控制生成的瓦片数量和边界CTB 的-c参数需要指定切片的经纬度边界如果不指定它会按输入数据的全部范围来切。问题在于很多 DEM 数据是整块大范围数据比如整个省的 30 米分辨率 DEM直接切片会让瓦片数量爆炸生成时间从几分钟变成好几个小时。所以我在预处理阶段必做两件事裁剪到项目实际需要的范围、合并多块覆盖同一区域的 tif。裁剪用gdalwarp就够gdalwarp -t_srs EPSG:4326 -te 116.2 39.4 116.6 39.9 -tr 0.0003 0.0003 \ -r bilinear origin_dem.tif beijing_area.tif-te后面跟的是最小经度、最小纬度、最大经度、最大纬度单位是度。-tr是输出像素分辨率0.0003 度大约相当于 30 米这个值要和你原始数据的分辨率匹配否则可能会让 gdalwarp 做无谓的重采样损失精度。多块 tif 覆盖同一区域的情况更常见比如分幅下载的 DEM 数据用gdal_merge.py先拼成一块整的gdal_merge.py -o merged.tif -create -ot Float32 tile_1.tif tile_2.tif tile_3.tif合并后的数据再统一裁剪、重投影。这里有个小地方要注意-ot Float32强制输出为 32 位浮点高程精度能保持到小数点后好几位而默认的 Int16 整数型在某些低海拔平缓区域会丢掉关键的地形起伏细节生成的地形看起来像「磨平」了一样。提示CTB 支持多个输入文件直接切片不必每次手动合并。但如果文件数量多或坐标系不一致合并后再切片能减少很多隐性错误。3. CTB 实操与参数详解一条命令从 tif 到地形瓦片3.1 安装 CTB源码编译最稳CTB 的官方仓库提供源码没有直接给二进制安装包。常见的安装方式是源码编译。我一般按以下步骤来git clone https://github.com/geo-data/cesium-terrain-builder.git cd cesium-terrain-builder mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DUSE_GDALON -DUSE_CURLON .. make -j4 sudo make install编译完成后会得到两个可执行文件ctb-tile用于生成地形瓦片ctb-info用于查询瓦片信息。-DUSE_GDALON必须开启否则 CTB 无法读取 tif 格式-DUSE_CURLON主要在从网络获取数据时才需要本地切片可以不开。如果你的开发机是 Windows用 vcpkg 或者 MSYS2 环境也能编译但我遇到的环境问题比较多最后都是在 Linux 容器里跑。3.2 核心命令ctb-tile 参数逐个拆解CTB 切片的核心命令是ctb-tile一个典型命令长这样ctb-tile -f quantized-mesh -o ./terrain_tiles \ -c 116.2 39.4 116.6 39.9 \ -l 15 \ -e 0.05 \ ./tif/beijing_area.tif参数含义从上到下依次是参数说明建议值-f quantized-mesh输出瓦片格式Cesium 专用必须且有且仅有一个-o ./terrain_tiles输出瓦片目录建议路径不要带空格-c lon_min lat_min lon_max lat_max切片经纬度范围必须与预处理后 tif 的范围一致或包含在内稍大于数据范围即可-l 15最大瓦片级别城市级项目 13~15全国级 10~12-e 0.05地形误差阈值单位米默认 1.0 会丢太多细节0.05 较精细./tif/beijing_area.tif输入 DEM 文件支持多个 tif 用空格分隔-l参数决定瓦片级别上限。每加一级瓦片数量变成原来的 4 倍。以覆盖 40km×40km 的范围为例15 级大约会产生数万个瓦片文件生成时间在几分钟到几十分钟之间。如果范围更大且对精度要求不高用 12 级就能明显减少生成压力Cesium 加载时靠地形误差来做细节替代。-e参数是很多人忽略的一个关键点。它控制点与点之间的最大高度误差误差越小地形细节保留越多瓦片体积也越大。默认 1.0 在平原地区看不出区别但在山地场景中山顶和山谷会被明显磨平。我会在 0.1 到 0.5 之间反复试具体看项目需要的视觉效果。3.3 生成后的文件结构理解瓦片目录才能正确部署切片完成后输出目录结构是固定的terrain_tiles/ └── 0/ ├── 0/ │ └── 0.terrain ├── 1/ │ ├── 1.terrain │ └── 2.terrain └── ... └── tileset.json0/0/0.terrain是根瓦片路径上第一层是 z 级别第二层是 x文件名是 y。Cesium 请求瓦片的 URL 规则是/{z}/{x}/{y}.terrain这个结构在部署时不要改动。tileset.json 是瓦片集合描述文件Cesium 加载时先请求它再按内容去请求具体瓦片。我把地形瓦片部署到静态服务器后用 Nginx 托管是最简单的方案注意 Nginx 配置里要加对.terrain扩展名的 MIME 类型声明location /terrain { alias /data/terrain_tiles; default_type application/octet-stream; add_header Access-Control-Allow-Origin *; expires -1; }没有正确的 MIME 类型和 CORS 头Cesium 在 HTTPS 域名下就会报跨域错误或者解析失败。expires -1是让瓦片不缓存的选项开发阶段修改瓦片后能立刻生效上线后可以改成按天缓存。提示CTB 生成的瓦片文件是 quantized-mesh 格式的二进制数据不是普通图片。在浏览器调试里看到.terrain文件正常返回 200 和二进制内容就说明切片和部署没问题。4. Cesium 端接入与验证加载瓦片、调帧率、看渲染效果4.1 用 CesiumTerrainProvider 替换默认地形Cesium 默认使用的是在线地形服务要换成 CTB 生成的本地瓦片核心代码就是替换terrainProviderconst viewer new Cesium.Viewer(cesiumContainer, { terrainProvider: new Cesium.CesiumTerrainProvider({ url: https://your-server.com/terrain, requestVertexNormals: true, requestWaterMask: false, }), });参数url指向的是 tileset.json 所在的目录注意不是文件本身。requestVertexNormals: true会请求每个瓦片的法线数据让地形在光照下呈现凹凸感这个效果在 CTB 生成瓦片时已经包含在文件里不需要额外处理。requestWaterMask对 CTB 生成的瓦片没用除非你在切片时使用过水体掩膜数据。如果地形已经加载但你看不到起伏检查是否在Viewer构造后设置了地形。另一种写法是在已有 viewer 上动态替换const terrainProvider await Cesium.CesiumTerrainProvider.fromUrl( https://your-server.com/terrain, { requestVertexNormals: true } ); viewer.scene.terrainProvider terrainProvider; viewer.camera.setView({ destination: Cesium.Cartesian3.fromDegrees(116.4, 39.7, 12000), });setView是为了把相机移到底图上方否则加载地形后看到的还是默认视角。如果你用了自定义底图图层底图与地形之间存在坐标系不一致的问题最常见的就是偏移和旋转后者大概率是底图不是 WGS84 导致的。4.2 验证加载是否正常三层检查法我每次接入完成后都会按顺序做三个验证任何一个不通过都说明上游链路有问题。第一层看网络请求打开 DevTools 的 Network 面板筛选.terrain能看到瓦片请求持续发出。正常加载时每一个可见瓦片都会产生一次 200 请求数量通常在十几个到几十个。第二层看渲染效果把相机抬高到 45 度视角让地形处于太阳光照角度下如果山体有明暗差异且边缘有锯齿过渡说明顶点法线生效。如果地形是纯色的平面但有轮廓起伏原因是requestVertexNormals没有生效或者瓦片里没有法线数据。第三层验证高程精度这是最容易忽略的一步。在地形上放置一个实体标记设置经纬度和高度然后切换到地形表面视角从侧面观察标记点是否贴合地表const entity viewer.entities.add({ position: Cesium.Cartesian3.fromDegrees(116.4, 39.7, 200), point: { pixelSize: 10, color: Cesium.Color.RED }, heightReference: Cesium.HeightReference.CLAMP_TO_GROUND, });如果标记点悬浮在半空或陷入地下说明瓦片的高程数据和原始 tif 之间存在系统偏差通常和预处理时的重投影或重采样有关。CLAMP_TO_GROUND 模式下标记会贴近地形表面此时对比放置位置和实际地理坐标偏差超过几米就在可接受范围内。5. 避坑排查地形偏位、黑底、进程被杀怎么定位5.1 地形整体偏移几十公里坐标系问题不是 bug现象生成的地形瓦片在 Cesium 中加载正常但位置明显偏移底图上的建筑和地形高低起伏完全错开几十公里。原因输入 tif 不是 WGS84 经纬度坐标系CTB 默认按 EPSG:4326 处理数据原始数据的坐标值被当作经纬度解释导致位置整体平移。解决预处理阶段用gdalinfo确认坐标系如果是 UTM 或 Web Mercator用gdalwarp -t_srs EPSG:4326重投影。处理完后再用gdalinfo检查输出数据的地理范围确保经纬度范围符合实际项目位置而不是原坐标系下的公里网数值。5.2 黑底瓦片或加载后地形区域为空洞现象Cesium 加载地形后部分区域显示为黑色或者完全透明能透过看到底图但底图上对应区域没有地形起伏。原因这类问题 90% 是输入 tif 在该区域存在 NoData 空洞例如原始 DEM 中海洋或云遮挡区域为 0 值或无效值。CTB 不会做插值直接把无效值切进瓦片最终渲染时 NaN 或 0 值被当成无效处理。解决用 GDAL 把无效值清洗掉再做切片。以 NoData 值为 -9999 的 tif 为例gdal_translate -a_nodata -9999 input.tif output_clean.tif gdal_fillnodata -md 50 output_clean.tif output_filled.tifgdal_fillnodata是 GDAL 自带的内插工具默认用周围有效像素加权插值填充空洞-md 50限制最大插值距离为 50 像素避免远处的数据污染本地地形。如果空洞区域过大比如整片海洋要么把-md调小要么用掩膜把水体区域直接裁掉。5.3 ctb-tile 进程内存暴涨被系统杀掉现象执行ctb-tile时内存占用持续攀升到 90% 以上运行一段时间后终端直接报Killed或者Segmentation fault。原因CTB 在切片时会把整个输入 tif 读入内存构建网格输入范围过大或分辨率过高的文件比如数十 GB 的全国范围内 DEM会直接吃满内存。这不是代码问题是数据规模超过了物理内存上限。解决先按实际项目范围裁剪数据缩小到合理范围再切片。如果必须处理大范围数据用gdal_retile把 tif 切块分成多个 tile 范围分别调用ctb-tile最后合并瓦片目录即可。注意合并时保持同一级别的瓦片不跨目录覆盖。mkdir split_tiles gdal_retile -ps 5000 5000 -targetDir split_tiles merged.tif for tif in split_tiles/*.tif; do ctb-tile -f quantized-mesh -o ./terrain_tiles -l 12 -e 0.05 $tif done每块 tif 的 5000×5000 像素设定是为了让单次切片的内存占用控制在 2GB 左右。实践中这个数值可以根据机器内存适当调整原则是单块数据在 500MB 以下最安全。5.4 请求量巨大导致加载缓慢现象地形加载时要发送大量.terrain请求浏览器同时加载几十上百个瓦片页面卡顿甚至白屏。原因-l级别设得太高或-e误差阈值太小瓦片数量和单个瓦片体积双高网络带宽和渲染线程被占满。解决在 Cesium 端用maximumLevel限制请求上限同时降低 CTB 的误差阈值权重const terrainProvider await Cesium.CesiumTerrainProvider.fromUrl( https://your-server.com/terrain, { requestVertexNormals: true, maximumLevel: 15, } );maximumLevel告诉 Cesium 即使瓦片服务有更高层级的数据也不要请求超过这个级别。这样视觉效果上虽然远处地形精度略降但加载曲线会平滑很多。根本解法还是回到 CTB 的-l参数把生成上限设到你实际需要的级别即可。6. 进阶技巧误差阈值、层级上限与静态部署的性能平衡CTB 的几个参数不是独立变量它们的组合决定了地形瓦片的「精细度-体积-加载速度」三角平衡。我最后给出一组经过实际项目验证的参数组合和验证手段。对城市级场景推荐这套值-l 15 -e 0.1。15 级在大约 40km×40km 的范围内能覆盖到建筑物级别的起伏细节0.1 米误差在平原和丘陵地区几乎看不出磨平痕迹。如果数据源是 30 米分辨率的 DEM-e 0.1已经低于数据本身精度再小没有收益只会把瓦片体积从几百 KB 抬到几 MB。对全国级场景-l 10 -e 0.5更合适。10 级瓦片在远景下足够流畅0.5 米的误差在切换到局部视角时才会暴露细节缺失但大多数场景根本不会放大到那种程度。注意-l不需要改到 20 级Cesium 在某一级别的瓦片缺失时会自动请求更细的级别而不是一直用最高级别。部署时还有一个提高加载速度的技巧把 terrain 目录挂到 CDN 或者 Nginx 的静态缓存上并对.terrain响应头加上Content-Encoding: gzip。quantized-mesh 瓦片内部本身已经做了顶点整数化压缩但 gzip 后仍能减少约 30% 体积。如果瓦片文件数超过十万强烈建议用tileset.json之外再加一层数据索引服务而不是依赖静态文件系统的目录列出——不过大多数项目不会走到这一步。验证参数的黄金标准我一般是这么做的生成瓦片后用ctb-info抽检单块瓦片ctb-info ./terrain_tiles/13/5120/7156.terrain它会输出该瓦片的层级、包围盒、顶点数量、三角形数量。顶点数在 5000 到 20000 之间属于健康范围低于 1000 说明误差阈值太大细节丢失严重高于 50000 则单瓦片体积过大加载会吃力。然后关闭 Cesium 的默认底图只加载地形跟踪相机实测瓦片请求延迟和帧率。帧率低于 30 就降低maximumLevel或调大-e。从那以后我每次处理地形数据都强制走一遍「gdalinfo 查坐标系 → gdalwarp 裁剪重投影 → ctb-tile 生成 → 部署后三层验证」的完整流程不再跳过任何一步。这套流程配合上面的参数列表基本能解决 90% 的本地地形加载问题希望帮到你。本文还有配套的精品资源点击获取 tif高程数据转Cesium地形瓦片：CTB切片参数与避坑指南
简介面向Cesium地形开发者的瓦片生成工具重点解决TIFF高程数据到Cesium可加载Terrain格式的转换问题。工具附带CTB运行库及完整依赖能将激光雷达或卫星遥感获取的数字高程模型按层级切分为瓦片便于Web端按需加载。压缩包共108个文件大小16.17MB其中包含40个dll运行库、4个exe可执行程序、29个csv坐标与投影参数文件以及gfs、wkt等地理数据描述配置从数据解析、坐标系定义到地形服务发布均有覆盖。已有2368人浏览学习适合GIS开发者、三维可视化工程师以及需要自定义地形的Cesium前端用户。借助该工具可生成JSON或Binary格式的地形瓦片在Cesium中配置Terrain服务URL即可加载渲染显著降低高程数据接入门槛同时可用于测绘、城市规划、环境监测、灾害模拟等场景支持将自有高程数据快速集成进三维地球应用实现流畅的LOD地形过渡与批量瓦片发布。1. Cesium 地形加载的卡点为什么 tif 高程数据不能直接丢给 Cesium拿到一块本地 tif 高程数据想在 Cesium 里看到起伏的真实地形第一反应往往是直接把 tif 丢给CesiumTerrainProvider。结果就是一片黑屏或者直接报错原因很简单Cesium 原生不认栅格 DEM它只认切片好的地形瓦片服务而这个切片过程基本绕不开cesium terrain builder以下简称 CTB这类瓦片地形生成器。CTB 的价值在于把 GeoTIFF 格式的高程数据转换成 Cesium 能直接加载的 quantized-mesh 瓦片附带 tileset.json 索引文件最终扔到任意静态服务器上就能用。这篇文章适合手里有 tif terrain 高程数据、想在自己的 Cesium 项目里加载离线地形的开发者也适合想搞清楚 CTB 参数边界、避免反复翻车的从业者。下面从数据预处理、CTB 实操、Cesium 接入到避坑逐层拆一遍。2. 高程数据预处理把杂乱的 tif 变成 CTB 吃得动的 DEM2.1 先从坐标系说起CTB 默认只认 WGS84CTB 的输入数据默认要求是 WGS84 经纬度坐标系也就是 EPSG:4326。很多人从国家地理信息公共服务平台或者 NASA 下载的 DEM 数据投影五花八门常见的有 UTM、Web MercatorEPSG:3857、Albers 等。如果直接丢给 CTB生成出来的瓦片位置会出现几十到几百公里的偏移而且完全看不出来是坐标系问题——因为 CTB 不会报错它只是按经纬度把数据硬切片。用 GDAL 工具先查看数据的坐标系这是我每次处理地形数据的第一步gdalinfo input.tif | grep -E EPSG|Origin|Pixel Size|Size is我需要重点看三行Coordinate System是否带EPSG:4326、Origin的纬度是否在 -90 到 90 之间、像素分辨率大约是多少。如果坐标系不是 WGS84就需要重投影用gdalwarp处理gdalwarp -t_srs EPSG:4326 -r bilinear input.tif output_wgs84.tif这里-r bilinear指定重采样算法为双线性对地貌起伏的平滑性保持比较好。如果原始数据是山地区域用-r cubic效果更圆润但处理时间会明显增加。对地形这种连续表面来说不建议用 nearest否则生成的瓦片边缘会呈现明显的台阶状瑕疵。2.2 裁剪与合并控制生成的瓦片数量和边界CTB 的-c参数需要指定切片的经纬度边界如果不指定它会按输入数据的全部范围来切。问题在于很多 DEM 数据是整块大范围数据比如整个省的 30 米分辨率 DEM直接切片会让瓦片数量爆炸生成时间从几分钟变成好几个小时。所以我在预处理阶段必做两件事裁剪到项目实际需要的范围、合并多块覆盖同一区域的 tif。裁剪用gdalwarp就够gdalwarp -t_srs EPSG:4326 -te 116.2 39.4 116.6 39.9 -tr 0.0003 0.0003 \ -r bilinear origin_dem.tif beijing_area.tif-te后面跟的是最小经度、最小纬度、最大经度、最大纬度单位是度。-tr是输出像素分辨率0.0003 度大约相当于 30 米这个值要和你原始数据的分辨率匹配否则可能会让 gdalwarp 做无谓的重采样损失精度。多块 tif 覆盖同一区域的情况更常见比如分幅下载的 DEM 数据用gdal_merge.py先拼成一块整的gdal_merge.py -o merged.tif -create -ot Float32 tile_1.tif tile_2.tif tile_3.tif合并后的数据再统一裁剪、重投影。这里有个小地方要注意-ot Float32强制输出为 32 位浮点高程精度能保持到小数点后好几位而默认的 Int16 整数型在某些低海拔平缓区域会丢掉关键的地形起伏细节生成的地形看起来像「磨平」了一样。提示CTB 支持多个输入文件直接切片不必每次手动合并。但如果文件数量多或坐标系不一致合并后再切片能减少很多隐性错误。3. CTB 实操与参数详解一条命令从 tif 到地形瓦片3.1 安装 CTB源码编译最稳CTB 的官方仓库提供源码没有直接给二进制安装包。常见的安装方式是源码编译。我一般按以下步骤来git clone https://github.com/geo-data/cesium-terrain-builder.git cd cesium-terrain-builder mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DUSE_GDALON -DUSE_CURLON .. make -j4 sudo make install编译完成后会得到两个可执行文件ctb-tile用于生成地形瓦片ctb-info用于查询瓦片信息。-DUSE_GDALON必须开启否则 CTB 无法读取 tif 格式-DUSE_CURLON主要在从网络获取数据时才需要本地切片可以不开。如果你的开发机是 Windows用 vcpkg 或者 MSYS2 环境也能编译但我遇到的环境问题比较多最后都是在 Linux 容器里跑。3.2 核心命令ctb-tile 参数逐个拆解CTB 切片的核心命令是ctb-tile一个典型命令长这样ctb-tile -f quantized-mesh -o ./terrain_tiles \ -c 116.2 39.4 116.6 39.9 \ -l 15 \ -e 0.05 \ ./tif/beijing_area.tif参数含义从上到下依次是参数说明建议值-f quantized-mesh输出瓦片格式Cesium 专用必须且有且仅有一个-o ./terrain_tiles输出瓦片目录建议路径不要带空格-c lon_min lat_min lon_max lat_max切片经纬度范围必须与预处理后 tif 的范围一致或包含在内稍大于数据范围即可-l 15最大瓦片级别城市级项目 13~15全国级 10~12-e 0.05地形误差阈值单位米默认 1.0 会丢太多细节0.05 较精细./tif/beijing_area.tif输入 DEM 文件支持多个 tif 用空格分隔-l参数决定瓦片级别上限。每加一级瓦片数量变成原来的 4 倍。以覆盖 40km×40km 的范围为例15 级大约会产生数万个瓦片文件生成时间在几分钟到几十分钟之间。如果范围更大且对精度要求不高用 12 级就能明显减少生成压力Cesium 加载时靠地形误差来做细节替代。-e参数是很多人忽略的一个关键点。它控制点与点之间的最大高度误差误差越小地形细节保留越多瓦片体积也越大。默认 1.0 在平原地区看不出区别但在山地场景中山顶和山谷会被明显磨平。我会在 0.1 到 0.5 之间反复试具体看项目需要的视觉效果。3.3 生成后的文件结构理解瓦片目录才能正确部署切片完成后输出目录结构是固定的terrain_tiles/ └── 0/ ├── 0/ │ └── 0.terrain ├── 1/ │ ├── 1.terrain │ └── 2.terrain └── ... └── tileset.json0/0/0.terrain是根瓦片路径上第一层是 z 级别第二层是 x文件名是 y。Cesium 请求瓦片的 URL 规则是/{z}/{x}/{y}.terrain这个结构在部署时不要改动。tileset.json 是瓦片集合描述文件Cesium 加载时先请求它再按内容去请求具体瓦片。我把地形瓦片部署到静态服务器后用 Nginx 托管是最简单的方案注意 Nginx 配置里要加对.terrain扩展名的 MIME 类型声明location /terrain { alias /data/terrain_tiles; default_type application/octet-stream; add_header Access-Control-Allow-Origin *; expires -1; }没有正确的 MIME 类型和 CORS 头Cesium 在 HTTPS 域名下就会报跨域错误或者解析失败。expires -1是让瓦片不缓存的选项开发阶段修改瓦片后能立刻生效上线后可以改成按天缓存。提示CTB 生成的瓦片文件是 quantized-mesh 格式的二进制数据不是普通图片。在浏览器调试里看到.terrain文件正常返回 200 和二进制内容就说明切片和部署没问题。4. Cesium 端接入与验证加载瓦片、调帧率、看渲染效果4.1 用 CesiumTerrainProvider 替换默认地形Cesium 默认使用的是在线地形服务要换成 CTB 生成的本地瓦片核心代码就是替换terrainProviderconst viewer new Cesium.Viewer(cesiumContainer, { terrainProvider: new Cesium.CesiumTerrainProvider({ url: https://your-server.com/terrain, requestVertexNormals: true, requestWaterMask: false, }), });参数url指向的是 tileset.json 所在的目录注意不是文件本身。requestVertexNormals: true会请求每个瓦片的法线数据让地形在光照下呈现凹凸感这个效果在 CTB 生成瓦片时已经包含在文件里不需要额外处理。requestWaterMask对 CTB 生成的瓦片没用除非你在切片时使用过水体掩膜数据。如果地形已经加载但你看不到起伏检查是否在Viewer构造后设置了地形。另一种写法是在已有 viewer 上动态替换const terrainProvider await Cesium.CesiumTerrainProvider.fromUrl( https://your-server.com/terrain, { requestVertexNormals: true } ); viewer.scene.terrainProvider terrainProvider; viewer.camera.setView({ destination: Cesium.Cartesian3.fromDegrees(116.4, 39.7, 12000), });setView是为了把相机移到底图上方否则加载地形后看到的还是默认视角。如果你用了自定义底图图层底图与地形之间存在坐标系不一致的问题最常见的就是偏移和旋转后者大概率是底图不是 WGS84 导致的。4.2 验证加载是否正常三层检查法我每次接入完成后都会按顺序做三个验证任何一个不通过都说明上游链路有问题。第一层看网络请求打开 DevTools 的 Network 面板筛选.terrain能看到瓦片请求持续发出。正常加载时每一个可见瓦片都会产生一次 200 请求数量通常在十几个到几十个。第二层看渲染效果把相机抬高到 45 度视角让地形处于太阳光照角度下如果山体有明暗差异且边缘有锯齿过渡说明顶点法线生效。如果地形是纯色的平面但有轮廓起伏原因是requestVertexNormals没有生效或者瓦片里没有法线数据。第三层验证高程精度这是最容易忽略的一步。在地形上放置一个实体标记设置经纬度和高度然后切换到地形表面视角从侧面观察标记点是否贴合地表const entity viewer.entities.add({ position: Cesium.Cartesian3.fromDegrees(116.4, 39.7, 200), point: { pixelSize: 10, color: Cesium.Color.RED }, heightReference: Cesium.HeightReference.CLAMP_TO_GROUND, });如果标记点悬浮在半空或陷入地下说明瓦片的高程数据和原始 tif 之间存在系统偏差通常和预处理时的重投影或重采样有关。CLAMP_TO_GROUND 模式下标记会贴近地形表面此时对比放置位置和实际地理坐标偏差超过几米就在可接受范围内。5. 避坑排查地形偏位、黑底、进程被杀怎么定位5.1 地形整体偏移几十公里坐标系问题不是 bug现象生成的地形瓦片在 Cesium 中加载正常但位置明显偏移底图上的建筑和地形高低起伏完全错开几十公里。原因输入 tif 不是 WGS84 经纬度坐标系CTB 默认按 EPSG:4326 处理数据原始数据的坐标值被当作经纬度解释导致位置整体平移。解决预处理阶段用gdalinfo确认坐标系如果是 UTM 或 Web Mercator用gdalwarp -t_srs EPSG:4326重投影。处理完后再用gdalinfo检查输出数据的地理范围确保经纬度范围符合实际项目位置而不是原坐标系下的公里网数值。5.2 黑底瓦片或加载后地形区域为空洞现象Cesium 加载地形后部分区域显示为黑色或者完全透明能透过看到底图但底图上对应区域没有地形起伏。原因这类问题 90% 是输入 tif 在该区域存在 NoData 空洞例如原始 DEM 中海洋或云遮挡区域为 0 值或无效值。CTB 不会做插值直接把无效值切进瓦片最终渲染时 NaN 或 0 值被当成无效处理。解决用 GDAL 把无效值清洗掉再做切片。以 NoData 值为 -9999 的 tif 为例gdal_translate -a_nodata -9999 input.tif output_clean.tif gdal_fillnodata -md 50 output_clean.tif output_filled.tifgdal_fillnodata是 GDAL 自带的内插工具默认用周围有效像素加权插值填充空洞-md 50限制最大插值距离为 50 像素避免远处的数据污染本地地形。如果空洞区域过大比如整片海洋要么把-md调小要么用掩膜把水体区域直接裁掉。5.3 ctb-tile 进程内存暴涨被系统杀掉现象执行ctb-tile时内存占用持续攀升到 90% 以上运行一段时间后终端直接报Killed或者Segmentation fault。原因CTB 在切片时会把整个输入 tif 读入内存构建网格输入范围过大或分辨率过高的文件比如数十 GB 的全国范围内 DEM会直接吃满内存。这不是代码问题是数据规模超过了物理内存上限。解决先按实际项目范围裁剪数据缩小到合理范围再切片。如果必须处理大范围数据用gdal_retile把 tif 切块分成多个 tile 范围分别调用ctb-tile最后合并瓦片目录即可。注意合并时保持同一级别的瓦片不跨目录覆盖。mkdir split_tiles gdal_retile -ps 5000 5000 -targetDir split_tiles merged.tif for tif in split_tiles/*.tif; do ctb-tile -f quantized-mesh -o ./terrain_tiles -l 12 -e 0.05 $tif done每块 tif 的 5000×5000 像素设定是为了让单次切片的内存占用控制在 2GB 左右。实践中这个数值可以根据机器内存适当调整原则是单块数据在 500MB 以下最安全。5.4 请求量巨大导致加载缓慢现象地形加载时要发送大量.terrain请求浏览器同时加载几十上百个瓦片页面卡顿甚至白屏。原因-l级别设得太高或-e误差阈值太小瓦片数量和单个瓦片体积双高网络带宽和渲染线程被占满。解决在 Cesium 端用maximumLevel限制请求上限同时降低 CTB 的误差阈值权重const terrainProvider await Cesium.CesiumTerrainProvider.fromUrl( https://your-server.com/terrain, { requestVertexNormals: true, maximumLevel: 15, } );maximumLevel告诉 Cesium 即使瓦片服务有更高层级的数据也不要请求超过这个级别。这样视觉效果上虽然远处地形精度略降但加载曲线会平滑很多。根本解法还是回到 CTB 的-l参数把生成上限设到你实际需要的级别即可。6. 进阶技巧误差阈值、层级上限与静态部署的性能平衡CTB 的几个参数不是独立变量它们的组合决定了地形瓦片的「精细度-体积-加载速度」三角平衡。我最后给出一组经过实际项目验证的参数组合和验证手段。对城市级场景推荐这套值-l 15 -e 0.1。15 级在大约 40km×40km 的范围内能覆盖到建筑物级别的起伏细节0.1 米误差在平原和丘陵地区几乎看不出磨平痕迹。如果数据源是 30 米分辨率的 DEM-e 0.1已经低于数据本身精度再小没有收益只会把瓦片体积从几百 KB 抬到几 MB。对全国级场景-l 10 -e 0.5更合适。10 级瓦片在远景下足够流畅0.5 米的误差在切换到局部视角时才会暴露细节缺失但大多数场景根本不会放大到那种程度。注意-l不需要改到 20 级Cesium 在某一级别的瓦片缺失时会自动请求更细的级别而不是一直用最高级别。部署时还有一个提高加载速度的技巧把 terrain 目录挂到 CDN 或者 Nginx 的静态缓存上并对.terrain响应头加上Content-Encoding: gzip。quantized-mesh 瓦片内部本身已经做了顶点整数化压缩但 gzip 后仍能减少约 30% 体积。如果瓦片文件数超过十万强烈建议用tileset.json之外再加一层数据索引服务而不是依赖静态文件系统的目录列出——不过大多数项目不会走到这一步。验证参数的黄金标准我一般是这么做的生成瓦片后用ctb-info抽检单块瓦片ctb-info ./terrain_tiles/13/5120/7156.terrain它会输出该瓦片的层级、包围盒、顶点数量、三角形数量。顶点数在 5000 到 20000 之间属于健康范围低于 1000 说明误差阈值太大细节丢失严重高于 50000 则单瓦片体积过大加载会吃力。然后关闭 Cesium 的默认底图只加载地形跟踪相机实测瓦片请求延迟和帧率。帧率低于 30 就降低maximumLevel或调大-e。从那以后我每次处理地形数据都强制走一遍「gdalinfo 查坐标系 → gdalwarp 裁剪重投影 → ctb-tile 生成 → 部署后三层验证」的完整流程不再跳过任何一步。这套流程配合上面的参数列表基本能解决 90% 的本地地形加载问题希望帮到你。本文还有配套的精品资源点击获取