企业官网建设流程全解析

我第一次认真去研究OSGEarth，是因为项目里要在三维地球上做态势显示、地形量算和路径推演。当时团队里有人提议直接用游戏引擎，有人倾向WebGIS方案，我翻了一周资料后还是决定回到OSGEarth这条路上。理由很简单：我们要做的是桌面级、可离线、需要精细控制渲染逻辑的C++三维GIS应用，而OSGEarth这个基于OpenSceneGraph（OSG）的开源三维地球渲染引擎，恰恰就是为这种场景准备的。

这篇文章不是官方文档的复述，是我在实际项目中从编译、部署、加载数据到做动态效果、排查性能问题这一路走下来的经验总结。如果你正准备把OSGEarth用进自己的项目，尤其是刚开始接触，被一堆依赖库和earth文件搞得头晕，那这篇内容应该能帮你少走很多弯路。我会尽量把每个环节背后的原理讲清楚，而不是只丢给你一堆能跑的命令。

1. 为什么折腾OSGEarth：它能解决哪些三维场景问题

1.1 用一段话讲清楚OSGEarth到底是什么

OSGEarth不是一个完整的GIS应用软件，它是一套基于OSG的三维地球渲染开发库。你可以把它理解成一块“能造地球场景的乐高底板”：底板本身提供了椭球体建模、影像高程叠加、瓦片调度、视点操控这些基础设施，你要做的就是在上面搭自己的业务模块。

它有四个核心能力：第一，加载全球或局部的高程数据（DEM），生成带起伏的真实地形；第二，把影像数据（卫星图、矢量切片渲染出的图等）贴合在高程上；第三，支持在线瓦片服务和本地栅格/矢量数据混用；第四，提供一套动态页面（地形分页调度）机制，让引擎根据需要加载和卸载数据，避免一次把全量数据塞进内存。

项目中用到最多的是它处理多源异构数据的能力。一个earth文件里可以同时配置本地高程、本地影像、在线影像、矢量边界等图层，引擎自动处理坐标转换、切片层级和绘制顺序。

1.2 它比裸写OSG、直接用商业GIS强在哪

最简单直接的做法是你用OSG自己建一个球体，贴上纹理，再自己写瓦片调度、坐标变换和LOD。如果你是做研究，那没问题；但如果是做实际产品，你会发现地形调度涉及的细节多到你怀疑人生：瓦片大小、像素误差、视锥裁剪、接缝处理、高程烘焙、纹理缓存，每一样都够写几个月。OSGEarth把这些都封装好了。

和商业GIS（比如ArcGIS Earth、SuperMap）相比，OSGEarth最大的优势是开放和可嵌入。你可以通过代码控制每一个图层、每一个节点的生命周期，可以自定义操纵器、自定义渲染回调，可以把整个地球视图嵌进你自己的Qt/MFC界面里，这些在商业软件里往往很难做到这么底层。

我梳理过一个简单的对比，方便你按场景选型：

所以说到底，如果你的产品是桌面软件，需要深度定制渲染、又要求能离线运行，OSGEarth基本是绕不开的最优解之一。

1.3 什么场景不建议用OSGEarth

有些情况下我建议你趁早换方案，别在OSGEarth上耗时间。

第一种是纯Web项目。如果你只需要在网页里展示三维地球、叠加一些点线面，CesiumJS或者MapBox GL更适合，部署方便，生态也成熟。虽然OSGEarth有Emscripten移植的Web版本，但成熟度和易用性都不如原生Web方案。

第二种是极其看重美术效果的场景，比如数字孪生中的高精度建筑渲染、光影反射。OSGEarth强在“真实地理数据”，不强在“好看”。游戏引擎能做出让领导眼前一亮的效果，OSGEarth做出来更多是“还挺专业但不够炫”。如果你要做对外展示的华丽场景，建议引擎做表现层、OSGEarth做GIS数据层，两者通过数据接口联动。

第三种是纯空间分析项目。如果你需求集中在缓冲区分析、叠加分析、网络分析，那这些是商业GIS的地盘，不必用OSGEarth硬造轮子。

2. 编译与部署：最容易被劝退的环节

2.1 依赖库清单与版本搭配

OSGEarth的编译是整个项目里最劝退新手的一步，因为依赖库比较多，版本搭配不对就是无休止的编译错误。我的建议是：如果你不做特别底层的定制，优先用vcpkg或者系统包管理器；如果你需要修改OSGEarth源码、断点调试到引擎内部，那就源码编译。

依赖库主要有这些：

我项目里最常用的一组版本组合是：OSG 3.6.5 + OSGEarth 2.10.2 + GDAL 3.4.x + libcurl 7.7x，这个组合在Windows和Linux上我都验证过，稳定性和性能都不错。

如果你的编译器是VS2019或VS2022，直接用vcpkg会省很多事：

vcpkg install osg osgearth gdal

但要注意，vcpkg默认编译的可能不是Release带符号版本，调试时不太方便。所以我的习惯是：先用vcpkg把依赖库装全，然后把OSGEarth自己拉源码编译，这样改动引擎源码也方便。

2.2 CMake配置里必须手动改的几个开关

打开OSGEarth源码目录，用CMake配置时，有几个选项建议你认真检查。

第一个是OSGEARTH_BUILD_SAMPLES，默认可能是OFF，我建议开成ON。OSGEarth自带的examples是学习引擎API的最佳参考资料，尤其是osgearth_viewer、osgearth_manipulator、osgearth_featurequery这几个例子，几乎覆盖了你想实现的所有功能的雏形。

第二个是OSGEARTH_USE_GDAL，一定要开。没有GDAL，很多本地高程和影像格式你都读不了，等于废了一半武功。

第三个是OSGEARTH_USE_OSGDEM，这个建议打开，它提供了osgdem命令行工具，可以预先把大地形数据烘焙成OSGEarth用的金字塔瓦片，对性能优化非常关键。

第四个是OSGEARTH_USE_CURL，如果项目需要加载在线瓦片服务，务必打开。不开的话，你的earth文件里所有URL形式的图层都会失效。

CMake命令行配置大致长这样：

cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_PREFIX_PATH=/path/to/deps \ -DOSGEARTH_BUILD_SAMPLES=ON \ -DOSGEARTH_USE_GDAL=ON \ -DOSGEARTH_USE_OSGDEM=ON \ -DOSGEARTH_USE_CURL=ON \ ..

在Windows上，CMake最常出问题的就是找不到OSG。你在CMakeGUI里配置时，把OSG_DIR手动指到你OSG的构建或安装目录，基本能解决80%的查找失败问题。Linux下如果OSG是源码装的，确认pkg-config路径或者OSG_DIR环境变量设置正确。

2.3 运行第一个earth文件：从earthig到earth_list

编译完成后，强烈建议先跑一下自带的示例验证环境是否正常。命令行里执行：

osgearth_viewer your.earth

如果你手头还没有earth文件，可以直接用examples里自带的readymap.earth，它会加载几个内置示例数据源，能看到一个完整的地球就说明环境没问题。

如果这个能跑起来，再试：

osgearth_earth_list your.earth

这个命令会打印earth文件里所有图层的解析结果，包括每个图层的类型、驱动、状态，是排查earth文件配置错误最顺手的工具。我经常这么干：先osgearth_earth_list确认图层都被正确解析，再开osgearth_viewer看渲染效果，避免两个问题混在一起分不清。

3. 数据组织：搞清楚earth文件的加载逻辑

3.1 earth文件结构逐行拆解

OSGEarth用XML格式的earth文件描述场景的所有图层配置。你完全可以不用它，直接用C++代码添加图层，但实际项目里我建议用earth文件做配置管理，好处是数据源调整时不用重新编译代码。

一个最简的earth文件长这样：

<map name="starter" version="2"> <elevation driver="gdal"> <url>data/dem.tif</url> </elevation> <image driver="gdal"> <url>data/satellite.tif</url> </image> </map>

结构上分三层：最外层是<map>，定义这张地图的名字和版本；中间是图层节点，类型包括elevation（高程）、image（影像）、model（模型/矢量）、mask（掩膜）；每个图层节点里有driver属性和若干子节点，driver指定用什么数据驱动去读取数据，url指定数据路径。

这里的driver="gdal"表示用GDAL驱动读取本地文件。你换数据源类型时只需要换driver，比如在线TMS服务用driver="tms"，ArcGIS切片用driver="arcgis"，GeoJSON矢量用driver="feature_query_geoJSON"。

3.2 高程、影像、矢量图层的加载顺序与映射

很多初学者搞不清楚高程和影像的关系。我打个比方：高程数据决定地形的“骨架”，它告诉引擎哪个点海拔是多少；影像数据是“皮肤”，贴在骨架上。没有高程，你就只有一张平的贴图；没有影像，你只有起伏的灰色网格。OSGEarth内部要做的是把影像瓦片和高程瓦片按经纬度逐一对齐，然后通过地形节点合成为最终的地球表面。

图层顺序也影响最终效果。一个earth里可以有多个影像图层，它们在绘制时按声明顺序从下往上叠加，支持透明度和混合模式。比如我做过一个项目，卫星图中的建筑已经过时，我就在顶层叠加了一个半透明的矢量图层，把新建建筑的轮廓和编号标出来，看起来就像“会更新的地图”。

矢量数据有两种用法。一种是通过<model>节点直接加载并渲染成几何体，比如把国界、省界渲染成线；另一种是通过feature_source和feature_style组合，用样式表控制符号化效果。矢量图层如果不设置高度，会贴在地表上；如果要浮空，就要配合altitude属性或代码设置垂直偏移。

3.3 本地数据与网络瓦片源的选型与配合

实际项目中很少只用单一数据源，通常是本地高程、本地高分影像、在线底图一起上。我写过这样一个earth配置：

<map name="hybrid" version="2"> <options> <cache type="filesystem"> <path>./cache</path> </cache> </options> <elevation driver="gdal"> <url>data/srtm.tif</url> </elevation> <image driver="tms"> <url>http://your-tile-server/{z}/{x}/{y}.png</url> </image> </map>

这里我加了<cache>配置，把在线瓦片缓存到本地磁盘，这样第二次浏览时速度明显提升，尤其是切到离线环境时，缓存能兜底。

关于在线源，有一点要特别注意：不同厂商的瓦片服务对请求数量、使用场景有各自的规定，公网底图在商用项目里务必确认授权边界。国内项目我一般优先考虑天地图这类有明确服务协议的来源，或者自建瓦片服务器，避免因为数据来源问题被卡脖子。自己用工具对高分影像切片后存成TMS瓦片，放到内网服务器上，是最稳妥的做法。

数据格式的选择也有讲究。高程数据建议用GeoTIFF，最稳定，GDAL读取效率高；影像数据如果是大范围，建议预先切片存成TMS目录或者MBTiles单文件库；矢量数据建议转成GeoJSON或Shapefile，结合feature_query驱动做动态过滤。

4. 视点与交互：让三维场景动起来

4.1 相机操控的底层逻辑

OSGEarth默认的地球操作器是EarthManipulator，它管理了相机围绕地球运动的所有规则：经纬度、高度、姿态、旋转中心。它不是简单的“相机绕物体旋转”，而是把相机位置换算成经纬高、把方向换算成方位角和俯仰角，从而保证视角在地球表面移动时符合地理直觉。

它的核心方法是setViewpoint，参数包括视点经纬度、高度、朝向、俯仰角，以及可选的视场角。代码简单如下：

osg::ref_ptr<osgEarth::Viewpoint> vp = new osgEarth::Viewpoint("home", 116.39, 39.90, 20000, 0, -45); manipulator->setViewpoint(vp);

这里116.39, 39.90是经纬度，20000是相机高度（米），0是方位角（正北为0），-45是俯仰角（负值表示向下看）。这段代码学会后，你就能实现“点击列表，视角飞到某个位置”这种非常常见的交互。

4.2 漫游、定位、书签的实现思路

漫游在OSGEarth里分两种：交互漫游和自动路径漫游。交互漫游不用你写代码，默认鼠标左键旋转、中键平移、右键缩放。但项目里经常需要对操纵器行为做定制，比如禁用缩放对高程的贴地限制、限制最小高度、关闭惯性。这些都是通过EarthManipulator::getSettings()来实现的：

osgEarth::Util::EarthManipulator* manipulator = new osgEarth::Util::EarthManipulator(); manipulator->getSettings()->setMinMaxPitch(-89.0, -10.0); manipulator->getSettings()->setAutoScrollEnabled(false); view->setCameraManipulator(manipulator);

自动路径漫游是用AnimationPath和AnimationPathManipulator实现的。项目里我做过一个“沿预定航线飞行”的演示：把航点数组转成osg::AnimationPath，每个控制点包含经纬高和姿态，然后让相机跟这条路径走。注意控制点的时间间隔要均匀，否则飞行速度忽快忽慢。

书签功能本质上就是保存Viewpoint。你可以把用户当前视角存进一个数组或JSON文件里，下次启动时恢复。OSGEarth自带的例子中就有Bookmark管理的示例，直接抄就好。

4.3 屏幕坐标与地理坐标互转的坑

交互类功能几乎逃不开坐标互转。比如鼠标点击地图，获取点击处的经纬度；或者在已知经纬度的地方，求它出现在屏幕的哪个位置。

获取鼠标对应地理坐标的写法：

osg::Vec3d world; if (mapNode->getTerrain()->getWorldCoordsUnderMouse(view, e.getX(), e.getY(), world)) { osgEarth::GeoPoint geo; geo.fromWorld(mapNode->getMapSRS(), world); double lon = geo.x(); double lat = geo.y(); }

反过来，把地理坐标投影到屏幕：

osg::Vec3d world; geo.toWorld(world); double x, y; view->getCamera()->project(world.x(), world.y(), world.z(), x, y);

这里最容易踩的坑是坐标系SRS不匹配。GeoPoint默认要用地图的SRS，如果你直接用WGS84经纬度但是地图SRS是Web Mercator，坐标就对不上。我的经验是：所有交互层统一用mapNode->getMapSRS()做转换，不要自己假设坐标系。

另外一个隐蔽的坑是“点选”和“地形高程”的配合。鼠标点击得到的是屏幕射线与地形的交点，但如果你在地形上方有一个半透明的模型层，射线可能会先撞到模型而不是地形。这种情况需要把模型节点排除在拾取范围之外，或者用getWorldCoordsUnderMouse并手动指定掩膜。

5. 动态内容与特效：往地球上挂东西

5.1 加载模型、贴图标、标注文本

三维地球上不能只显示地形和影像，业务系统里更多的是要“往地球上放东西”——雷达站、车辆、人员、建筑。最基本的做法是用GeoTransform节点，把模型实例放到指定的经纬高上：

osg::ref_ptr<osg::Node> model = osgDB::readNodeFile("tank.ive"); osg::ref_ptr<osgEarth::GeoTransform> xform = new osgEarth::GeoTransform(); xform->setPosition(osgEarth::GeoPoint(mapNode->getMapSRS(), 116.39, 39.90, 100)); xform->addChild(model); mapNode->addChild(xform);

GeoTransform的作用是把局部坐标系的模型转换到地理坐标系。如果你直接把模型加进场景而不包GeoTransform，OSGEarth会认为你就想放在世界坐标原点，后果就是模型跑到地心或者某个莫名其妙的方位。

图标和文字标注是另一大类高频需求。OSGEarth里有几种方案：osgText::Text结合Billboard做屏幕标签，简单但样式粗糙；osgEarth::Annotation::LabelNode是专门的地理标注节点，能自动处理遮挡和缩放；IconNode和PlaceNode则是为“业务点标记”设计的，支持图标加文字。我在项目里基本统一用PlaceNode，它的表现力够强，接口也简洁：

osg::ref_ptr<osgEarth::Annotation::PlaceNode> place = new osgEarth::Annotation::PlaceNode( mapNode.get(), "site", osgEarth::GeoPoint(mapNode->getMapSRS(), 116.39, 39.90), osgEarth::Style("text{content:'观测站'};icon{url:'icons/radar.png'}")); mapNode->addChild(place);

这行代码的核心意思是通过样式字符串同时定义了文字内容和图标地址，OSGEarth内部会把这些转发给对应的渲染器。

5.2 轨迹线、粒子、动态辉光

轨迹线的需求在态势系统中很常见，比如显示飞机航迹、导弹弹道。最稳妥的方案是把轨迹点转成osg::Geometry，然后用osgEarth::Annotation::FeatureNode或者LineNode来渲染。这里我建议直接用FeatureNode，它接收一个Feature对象（由一系列经纬度坐标点构成），自动处理坐标转换和线样式：

osg::ref_ptr<osgEarth::Feature> feature = new osgEarth::Feature( new osgEarth::LineString(), mapNode->getMapSRS()); // 添加航迹点 feature->getGeometry()->push_back(osg::Vec3d(116.0, 39.0, 1000)); feature->getGeometry()->push_back(osg::Vec3d(116.5, 39.5, 2000)); osgEarth::Style lineStyle; lineStyle.getOrCreate<osgEarth::LineSymbol>()->stroke()->color() = osg::Vec4f(1, 0, 0, 1); lineStyle.getOrCreate<osgEarth::LineSymbol>()->stroke()->width() = 2.0f; osg::ref_ptr<osgEarth::Annotation::FeatureNode> line = new osgEarth::Annotation::FeatureNode(feature, lineStyle); mapNode->addChild(line);

如果轨迹点很多、上万级别，直接把所有点做成一条Geometry性能更好；如果点不多，用FeatureNode省事。

粒子特效在OSGEarth里用得相对少，但一旦用上会很出彩。比如目标被击中后的爆炸火焰、飞机尾焰、喷泉效果。OSGEarth的粒子体系底层还是OSG的osgParticle，你需要先创建粒子系统，然后挂到场景节点上。实际经验是粒子别铺太大面积，粒子的更新计算在CPU侧，大量粒子会拖垮帧率。我有一个原则：粒子只做“点缀”，绝对不做“主体”。

动态辉光、闪烁效果通常用osgEarth::Util::PolygonDrawable配合透明度动画实现。由于辉光本质上是一个半透明面片，要保证它排序正确。OSGEarth默认的深度测试有时会让半透明面片被地形遮挡，这时候你需要把节点的RenderBin设置成透明排序，或者给节点关掉深度写入。

5.3 动画路径与业务数据绑定的经验

动态效果不只是“好看的动画”，它要跟业务数据联动才有价值。我的做法通常是这样的：后台数据线程拿到目标的最新位置、姿态后，通过队列把更新事件发给渲染线程；渲染线程根据事件修改对应节点的矩阵或位置。

实现时最关键的是线程模型。OSGEarth的viewer默认是多线程的，渲染线程和你的业务线程不是同一个。你不能在业务线程里直接改场景节点，否则很可能崩溃。我有专门的事件队列：

std::mutex mutex; std::queue<std::function<void()>> commandQueue; void updateTargetPosition(const std::string& id, const osgEarth::GeoPoint& pos) { std::lock_guard<std::mutex> lock(mutex); commandQueue.push([id, pos]() { // 找到对应节点并设置新位置 }); } void viewerLoop() { while (!done) { std::lock_guard<std::mutex> lock(mutex); while (!commandQueue.empty()) { auto cmd = commandQueue.front(); cmd(); commandQueue.pop(); } viewer->frame(); } }

这种“命令队列”模式我用了很久，简单、安全、可扩展。注意viewer->frame()里回调里执行场景修改才是安全的，别在任意线程碰节点。

6. 性能优化与常见问题排查

6.1 大规模地形卡顿的根源与对策

很多人在网上问“OSGEarth加载全球地形后转视角好卡”，但没人给完整答案。根据我的观察，卡顿一般来自四个方面。

第一是数据源读取太慢。如果你直接用GDAL读一个几GB的GeoTIFF，每次绘制都要随机读取文件中很小的瓦片区域，IO开销非常恐怖。解决办法是用osgdem或者其他切片工具，把数据烘焙成金字塔结构的瓦片目录。烘焙之后，每个层级只读取对应分辨率的小文件，IO效率成倍提升。

第二是显存带宽爆满。大量高分辨率影像同时加载到显存，最终会导致纹理调度成为瓶颈。解决办法是控制纹理缓存上限，在earth文件的<options>里设置：

<options> <cache type="filesystem" path="./cache"/> <scene> <tile_size>17</tile_size> <max_tiles>1024</max_tiles> </scene> </options>

tile_size是瓦片栅格大小，常用16或17（即256x256或512x512纹理）；max_tiles决定最多同时保持多少张瓦片，值过大会导致显存爆满，过小会导致频繁调度卡顿。这个参数没有一个通用最优值，要配合你机器的显存和业务场景去压测。

第三是LOD切换太频繁。当地形起伏剧烈、视点贴着地表飞行时，LOD会在高低层级之间来回切换，造成明显的卡顿和闪动。这时可以适当调高LOD计算时的像素误差阈值，让引擎不要那么“敏感”地升级细节层级。路径漫游中如果发现画面频繁跳变，通常就是这个问题。

第四是每帧业务逻辑太重。我曾经踩过一个坑，就是把大量UI更新和逻辑计算都放在渲染回调里，导致每帧耗时被拉长到100ms以上。后面把和场景无关的运算都挪出帧循环，卡顿立刻缓解。记住：渲染回调只做渲染更新，别在里头算业务。

6.2 影像黑块、高程断层、纹理闪烁

我把实际项目中遇到过的渲染类问题列个表，方便你按症状对号入座：

高程断层是最常见也是最难排查的。我遇到过一种情况：两块DEM数据来自不同渠道，一个高程基准是WGS84椭球高，一个是EGM96大地水准面高，两者相差几十米，拼在一起就是一道“悬崖”。这种问题在渲染层无解，只能是数据预处理阶段统一高程基准。所以我做数据接入规范时，第一页就写明“所有DEM统一为WGS84椭球高，不做水准面改正的就别入库”。

纹理闪烁很多情况下不是OSGEarth的问题，而是你的显卡驱动或者垂直同步设置。先排除驱动问题，再查代码。关闭垂直同步后帧率会大幅提升，但也可能出现画面撕裂，取舍看具体场景。窗口方式运行时我一般开垂直同步，全屏态势演示时反而关闭，确保帧率优先。

6.3 内存泄漏与多线程渲染的排查经验

长时间运行的态势系统最怕内存一点点涨上去。OSGEarth本身设计得比较干净，但使用不当照样泄漏。我排查下来，最常见的三个泄漏点。

第一是事件回调未解绑。你在某个节点上加了addEventCallback，节点释放时回调却还被某个事件源持有，导致节点永远无法释放。解决方法是节点移除前先removeEventCallback，或者在业务代码里用osg::ref_ptr管理回调生命周期，别裸指针满天飞。

第二是数据缓存无限增长。在线瓦片缓存如果配置成无上限的文件系统缓存，运行几个月后磁盘和内存都会慢慢爆掉。建议对缓存目录做定期清理，或者用DBOptions控制缓存上限。

第三是动画循环忘记停止。AnimationPath如果循环引用节点，停止动画时必须显式调stop()，否则那个路径对象会一直持有节点引用。这类问题用OSG自带的osg::NodeVisitor统计引用计数也能发现，但写代码时养成好习惯更省事。

多线程渲染的崩溃跟内存泄漏一样常见。OSGEarth的默认线程模式是DrawThreadPerContext，渲染线程、更新线程和主线程并发。如果你在交互回调里直接改了节点数据，很可能在渲染线程读取时造成崩溃。我的建议是：场景只读的节点别设法改，必须动态更新的数据用DynamicObject包装，或者像我前面提到的，用命令队列把所有场景修改切到帧更新阶段执行。

7. 从2D到3D：用OSGEarth做数字孪生与态势系统的扩展思路

OSGEarth项目做到后面，通常不只是个“三维地球浏览器”，而是要跟业务系统深度集成。我做过的一个数字孪生项目，就是在OSGEarth上叠加了楼宇白模、管网线和实时传感器数据的标签。这里有个关键认知：OSGEarth应该当数据可视化引擎用，而不是当业务系统本身用。

两者之间怎么协作？我是这样分层的：业务系统负责数据采集、存储、分析，通过内部消息总线推送状态变更；OSGEarth负责把变更翻译成可见的实体动作，比如改变颜色、移动位置、弹出提示。渲染端和业务端解耦之后，如果哪天要替换渲染引擎，业务层几乎不用动。

在功能扩展上，我最常用的几个能力组合是：GeoTransform加载精细建筑模型，FeatureNode画地下管网，Annotation::LabelNode标注传感器读数，再配合SceneGraphCallbacks监听场景事件。这套组合能覆盖大部分数字孪生项目的展示需求。

项目落地时还要考虑发布环境。OSGEarth运行依赖一堆动态库，打包时要一并带上。Linux下用ldd查依赖，Windows下用Dependencies工具查。另外，不同机器的显卡驱动差异会导致渲染效果不一致，正式发布前一定要在目标环境的机器上做一遍渲染回归，尤其是低端显卡机上，要确认LOD策略不会卡成PPT。

关于数据资产，我吃过亏，多说一句：三维项目里，程序代码只是小头，大头是数据。DEM、影像、模型、标注的原始数据一定要建好资产库，版本管理、坐标统一、格式规范都得上流程。代码可以重构，数据一旦混乱，项目基本就死了。

最后再分享一个小技巧：调试earth文件时，建议在启动程序里加一个--dump-viewpoint之类的调试参数，把当前相机视角打印出来。你看演示时发现某个角度好看，直接复制输出到代码里当初始视角，省得肉眼对齐。这种小工具不用做得多复杂，几十行代码就能让日常调试舒服很多，也算是我折腾OSGEarth大半年后最想推荐给刚上手的人的一件事。