企业官网建设流程全解析

1. 从一堆OSGB文件说起：这套数据到底能拿来干什么

第一次拿到OSGB倾斜摄影数据的人，大概率会经历三个阶段：先是兴奋，觉得这玩意儿跟实景一模一样，比手工建模强太多；然后是懵圈，一个文件夹里躺着几百上千个.osgb文件，外加一个metadata.xml，完全不知道从哪下手；最后是抓狂，想把它塞进项目里，结果发现坐标系对不上、模型加载卡成幻灯片、贴图还发黑。

我这些年经手的倾斜摄影项目不算少，从早期的ContextCapture 4.x一路用到现在的版本，OSGB这套数据格式可以说是国内实景三维领域最“接地气”的存在。它不像3DTiles那样天生为Web端流式加载设计，也不像OBJ那样通用，但胜在结构简单、分块清晰、单机加载性能好，所以大量无人机航测项目交付时，默认给的就是OSGB。

这篇文章我想把OSGB倾斜摄影数据从“下载到用起来”这条链路彻底讲透。核心关键词OSGB、倾斜摄影、数据资源下载会贯穿全文，但我不打算只停留在“哪里能下”这个层面——那种内容网上已经够多了，而且很多链接早就失效。我更想聊的是：拿到数据之后，坐标系怎么选、OSGB和DOM到底什么关系、怎么转成3DTiles给前端用、大疆无人机拍的片子怎么走通建模流程。这些才是真正卡住人的地方。

适合谁看？如果你是测绘、GIS、三维可视化方向的学生或者刚入行的工程师，这篇能帮你少走至少半年的弯路。如果你已经有一定基础，但每次遇到坐标系和格式转换就头疼，那第3节和第4节应该能解决你的大部分问题。全文基于我自己的实操经验，涉及参数和步骤的地方我会把计算过程也写出来，方便你直接抄作业。

2. OSGB数据资源获取与前期准备

2.1 免费OSGB数据到底从哪里来

先说清楚一件事：真正高质量的OSGB倾斜摄影数据，几乎没有完全免费公开的。原因很简单，一套城市级实景三维模型的采集成本摆在那里——无人机飞行、像控点测量、空三解算、人工修模，每一步都是钱。所以网上流传的“免费下载”，基本是以下几类：

• 教学示例数据：一些软件厂商和高校会放出小范围样例，比如ContextCapture自带的示例工程，或者某些测绘单位公开的几百米街区数据。这类数据的特点是范围小、精度一般，但用来练手完全够用。
• 开放地理数据平台：部分城市有公开的实景三维成果，格式可能是OSGB或者3DTiles，需要注册申请，有的还限制用途。
• 个人项目分享：一些博主会把自己练手做的模型打包分享，这类数据质量参差不齐，坐标系信息经常缺失，下载后要自己核对。

我个人的建议是：别把精力花在到处找免费数据上，先用手头的样例把流程跑通。等你真正理解了OSGB的结构和处理方法，再去找项目数据或者自己飞一片区域建模，效率高得多。

提示：下载任何数据前，先确认它的坐标系和范围。我见过太多人下载完直接拖进软件，结果模型跑到几千公里外，就是因为没看metadata。

2.2 拿到数据后先做这三件事

很多人下载完OSGB就急着往软件里拖，这是大忌。我习惯先做三件事，五分钟就能避免后面几小时的返工。

第一，看目录结构。标准OSGB数据通常长这样：

Data/ ├── metadata.xml ├── Tile_+000_+000/ │ ├── Tile_+000_+000.osgb │ ├── Tile_+000_+000_L20_00.osgb │ └── ... ├── Tile_+001_+000/ └── ...

那个metadata.xml是命根子，里面记录了SRS（空间参考系统）、范围、层级信息。用文本编辑器打开看一眼，重点找<SRS>标签，它会告诉你这是EPSG多少。

第二，确认坐标系。国内常见的倾斜摄影成果坐标系有这么几种：

坐标系选错，模型位置就全错。这一步千万别偷懒。

第三，检查文件完整性。OSGB是分块的，如果下载过程中断了，某些tile可能损坏。我一般会看总文件数和总大小是否和说明一致，然后用一个简单的脚本遍历一遍，确认没有0字节文件。

2.3 硬件和软件环境的最低配置

倾斜摄影数据处理是吃硬件的大户，尤其是OSGB这种带大量贴图的数据。我踩过的坑是：用一台8G内存的笔记本打开一个城市级OSGB，直接卡死。

给你一个我实测下来比较稳的配置参考：

• 内存：16G起步，处理城市级数据建议32G以上。OSGB加载时会把节点和贴图读进内存，内存不够就频繁换页，卡到怀疑人生。
• 显卡：独立显卡，显存4G以上。集成显卡能打开但体验很差。
• 硬盘：SSD，至少留出数据体积3倍的剩余空间。转换和缓存过程会产生大量临时文件。
• 软件：ContextCapture（建模和查看）、OSGB转3DTiles工具（如CesiumLab、3DTiles转换器）、QGIS或ArcGIS（坐标系处理）、Blender或3ds Max（模型修整）。

软件这块我要多说一句：不要迷信某一个工具能包打天下。ContextCapture擅长建模和OSGB输出，但转3DTiles不是它的强项；CesiumLab转3DTiles很顺手，但处理坐标系不如专业GIS软件。组合使用才是常态。

3. 核心概念拆解：OSGB、DOM与3DTiles的关系

3.1 OSGB到底是什么，为什么倾斜摄影爱用它

OSGB全称OpenSceneGraph Binary，是OpenSceneGraph这个开源三维引擎的二进制格式。它本质上是一种场景图格式，把三维模型组织成树状结构，每个节点可以包含几何体、贴图、变换矩阵等信息。

倾斜摄影为什么偏爱OSGB？我总结下来有三个原因。

第一，分块机制天然适配倾斜摄影的数据组织方式。倾斜摄影模型是通过多视角影像密集匹配生成的，数据量巨大，必须分块。OSGB的LOD（细节层次）结构让不同距离显示不同精度的模型，近处清晰远处简化，这个机制和倾斜摄影的“金字塔”数据组织完美契合。

第二，二进制格式读取快。相比OBJ这种文本格式，OSGB是二进制的，解析速度快很多。一个几百MB的OSGB文件，加载起来比同样内容的OBJ快好几倍。

第三，贴图内嵌，管理方便。OSGB可以把贴图打包在文件内部，也可以外链。倾斜摄影的贴图是影像自动映射的，数量多且碎，内嵌方式省去了管理成千上万张贴图的麻烦。

但OSGB也有明显短板：它是桌面端格式，Web端不能直接加载，必须转成3DTiles；不同软件对OSGB的支持程度不一，跨平台性一般。

3.2 OSGB和DOM的关系，别再搞混了

这是被问得最多的问题之一：osgb和dom的关系到底是什么？

简单说，OSGB是三维模型，DOM是二维正射影像。两者是完全不同的数据产品，但经常一起出现，所以容易混淆。

DOM（Digital Orthophoto Map）是数字正射影像图，它是把航空影像经过几何校正后，消除地形和相机倾斜影响，生成的一张大图。你可以把它理解成“从正上方垂直往下拍、并且把地形起伏都压平了的照片”。DOM是二维的，每个像素对应地面一个位置，有坐标信息。

OSGB是三维的，它不仅有平面位置，还有高度信息，能看到建筑物的侧面、树木的轮廓。

它们的关系体现在这几个方面：

• 生产流程上：倾斜摄影一次飞行，可以同时产出OSGB三维模型和DOM正射影像。空三解算后，用同一套影像分别生成两种产品。
• 应用上互补：DOM适合做底图、量测平面距离和面积；OSGB适合看立体效果、量测高度和体积。很多项目会同时交付这两样。
• 数据关联：DOM的坐标系通常和OSGB一致，可以叠加使用。在三维场景里，DOM经常被当作地面底图贴在OSGB模型下方。

我见过有人把DOM当成OSGB的贴图，这是不对的。OSGB的贴图是模型自带的，来自倾斜影像的自动映射；DOM是独立的正射产品，两者来源相同但用途不同。

3.3 为什么最终都要转成3DTiles

如果你只做桌面端展示，OSGB够用了。但只要涉及Web端、涉及在浏览器里流畅加载大场景，3DTiles就是绕不过去的坎。

3DTiles是Cesium提出的三维瓦片规范，专门为流式加载设计。它的核心思想是：把三维场景切成一个个瓦片，每个瓦片有明确的包围盒和几何误差，浏览器根据视角动态请求需要的瓦片。这样即使数据总量几十上百G，用户也只需要加载当前视野内的部分。

OSGB转3DTiles，本质上是把OSGB的LOD树结构重新组织成3DTiles的tileset.json加b3dm（或glTF）瓦片。转换过程中要处理几个关键问题：

• 坐标系转换：OSGB的坐标系要转成3DTiles要求的EPSG:4978（地心直角坐标）或者带地理参考的局部坐标。
• 贴图格式：OSGB的贴图可能是DDS等格式，要转成Web友好的JPEG或PNG。
• 层级重构：OSGB的LOD层级和3DTiles的geometricError要对应好，否则会出现加载闪烁或者精度突变。

转换工具我用过不少，CesiumLab的转换质量比较稳定，对坐标系处理也比较友好。开源方案里，3d-tiles-tools可以做一些基础转换，但配置起来麻烦一些。

4. 实操全流程：从OSGB到可用三维场景

4.1 坐标系选择与转换的完整计算过程

坐标系这块我要展开讲，因为这是最容易出错、也最需要理解原理的地方。

假设你拿到的OSGB数据是CGCS2000高斯投影3度带，中央经线117度，带号39。metadata里写的EPSG是4547。现在你要把它转成3DTiles，用于Cesium展示。

第一步，确认源坐标系。EPSG:4547是CGCS2000 / 3-degree Gauss-Kruger CM 117E，也就是中央经线117度、3度带投影。它的坐标值是东坐标（带500km假东）和北坐标，单位米。

第二步，确定目标坐标系。Cesium的3DTiles通常用EPSG:4979（WGS84地理坐标）或者EPSG:4978（地心直角坐标）。转换时一般先转成4979，再由Cesium内部处理。

第三步，执行转换。这里有两种路径：

路径A：用GIS软件转换。在QGIS里加载OSGB的metadata，确认坐标系，然后用“重投影”功能转成EPSG:4979。但OSGB本身不是QGIS直接支持的格式，通常要先转成其他格式或者用专门工具。

路径B：在转换工具里指定坐标系。以CesiumLab为例，导入OSGB时它会让你指定源坐标系和目标坐标系。源坐标系选EPSG:4547，目标选EPSG:4979，工具会自动计算转换参数。

这里有个关键点：高斯投影转经纬度不是简单的线性变换，涉及椭球参数和投影反算。如果你手动算，公式是这样的：

对于高斯投影反算，已知x（北坐标）、y（东坐标），先去掉假东500000，然后计算底点纬度，再迭代求解经度。这个过程比较复杂，实际工作中没人手算，都是用工具。但你要理解：转换参数错了，模型就会偏移几百米甚至几公里。

我踩过的坑是：有一次数据是地方独立坐标系，metadata里没写清楚，我按CGCS2000转了，结果模型整体偏移了1.2公里。后来找项目方要了转换参数（四参数或七参数），才纠正过来。所以，如果数据来源不明，一定要先问清楚坐标系，或者找一个已知点验证。

4.2 OSGB转3DTiles的详细步骤

下面是我用CesiumLab转3DTiles的完整流程，其他工具逻辑类似。

第一步，准备数据。把OSGB文件夹整理好，确保metadata.xml在根目录。如果数据是分多个文件夹的，先合并到一个目录下。

第二步，打开转换工具，新建任务。选择“OSGB转3DTiles”功能。

第三步，指定输入输出。输入选OSGB根目录，输出选一个空文件夹。注意输出路径不要有中文和空格，这是很多工具的通病。

第四步，设置坐标系。源坐标系按metadata填写，目标坐标系选EPSG:4979。如果工具支持，勾选“自动计算中心点”，这样生成的tileset会以数据中心为原点，避免坐标值过大导致精度问题。

第五步，设置瓦片参数。这里有几个关键参数：

• 最大层级：根据数据精度定，一般倾斜摄影最大层级在20-22级。设太高会生成大量小文件，设太低会丢失细节。
• 几何误差：控制LOD切换的阈值。默认值通常可用，如果发现切换太突兀，可以调小。
• 贴图格式：选JPEG，质量75-85，平衡体积和清晰度。
• 线程数：按CPU核心数设置，一般设成核心数的80%。

第六步，开始转换。转换时间取决于数据量，一个1GB的OSGB大概需要10-30分钟。转换过程中可以看日志，如果有报错会提示。

第七步，验证结果。转换完成后，用Cesium加载tileset.json，检查模型位置、贴图、LOD切换是否正常。

注意：转换过程中如果中断，输出文件夹里会有残留文件，下次转换前一定要清空，否则可能出错。

4.3 大疆无人机倾斜摄影建模的坐标系选择

大疆无人机（如Mavic 3E、Phantom 4 RTK）做倾斜摄影，坐标系选择有几个关键决策点。

第一，飞行时用什么坐标系。大疆RTK机型默认输出WGS84经纬度和椭球高。如果你需要CGCS2000成果，可以在飞行设置里选择，或者后期转换。我的建议是：飞行时用WGS84，后期按项目要求转换。因为WGS84是GPS原生坐标系，转换到其他坐标系有成熟参数，反过来则可能引入误差。

第二，空三解算时用什么坐标系。在ContextCapture里新建工程时，会要求指定SRS。如果你有像控点，像控点的坐标系就是你的目标坐标系。如果没有像控点，用WGS84也能出成果，但绝对精度差一些。

第三，建模输出时用什么坐标系。ContextCapture输出OSGB时，可以选择输出坐标系。这里要和项目需求一致。如果是国内测绘项目，通常输出CGCS2000高斯投影；如果是Web展示，输出WGS84更方便。

我实测下来，大疆RTK机型在无像控点情况下，WGS84成果的平面精度可以做到5cm以内，高程精度10cm左右。加像控点后能到2-3cm。这个精度对于大部分实景三维应用足够了。

4.4 模型提取与轻量化处理

有时候你不需要整个场景，只想从OSGB里提取某栋建筑或者某个区域。这时候就需要模型提取。

提取的方法有几种：

• 按范围裁剪：在ContextCapture或者第三方工具里，画一个多边形范围，只输出范围内的模型。适合规则区域。
• 按层级提取：OSGB的LOD结构里，高层级是简化模型，低层级是精细模型。如果只需要粗略模型，可以只保留高层级。
• 手动修模：用Blender或3ds Max打开OSGB（需要插件），删除不需要的部分，重新导出。适合小范围精细处理。

轻量化是另一个重要话题。OSGB数据动辄几十G，直接用于Web不现实。轻量化的手段包括：

• 减面：用Decimation算法减少三角形数量，但会损失细节。
• 贴图压缩：把大贴图缩小，或者转成更高效的格式。
• LOD重构：重新生成更合理的LOD层级，减少总瓦片数。

我一般会先转3DTiles，然后在3DTiles基础上做轻量化，因为3DTiles的瓦片结构更适合做按需加载和简化。

5. 常见问题与排查技巧实录

5.1 模型加载后位置不对怎么办

这是最高频的问题。模型位置不对，99%是坐标系问题。排查思路如下：

第一步，确认源坐标系。打开metadata.xml，找SRS标签。如果没有，问数据提供方。如果提供方也不清楚，看坐标值范围：如果东坐标在6-7位数、北坐标在7-8位数，大概率是高斯投影；如果经纬度在几十到一百多，那是地理坐标。

第二步，确认转换参数。如果源坐标系和目标坐标系之间需要转换参数（比如地方坐标系转CGCS2000），确认参数是否正确。四参数用于平面，七参数用于三维。

第三步，验证。找一个已知点，比如某个明显地标的角点，在模型里量它的坐标，和实际坐标对比。如果偏差是固定值，说明是平移问题；如果偏差随位置变化，说明是旋转或尺度问题。

我整理了一个速查表：

5.2 贴图发黑或丢失的排查

贴图问题也很常见，表现是模型灰暗、发黑，或者某些面没有贴图。

原因通常有这几个：

• 贴图路径错误：OSGB如果外链贴图，路径变了就找不到。解决方法是把贴图内嵌，或者修复路径。
• 贴图格式不支持：某些工具不支持DDS格式，转成JPEG即可。
• 光照设置问题：有些查看器默认没有环境光，模型看起来就是黑的。加一个环境光或者调整材质。
• 贴图坐标丢失：转换过程中UV丢失，需要重新映射。

我的经验是：转3DTiles时，贴图格式统一转成JPEG，质量80，基本能解决大部分问题。

5.3 性能优化：让大场景流畅加载

OSGB转3DTiles后，如果加载还是卡，可以从这几个方面优化：

• 减少瓦片数量：合并小瓦片，或者提高几何误差阈值。
• 压缩贴图：用工具批量压缩，或者降低分辨率。
• 使用Draco压缩：3DTiles支持Draco几何压缩，能显著减小文件体积。
• 按需加载：确保tileset.json的LOD结构合理，不要一次性加载所有瓦片。
• 服务端优化：如果用Cesium ion或者自建服务，开启gzip压缩和缓存。

我实测过一个20GB的OSGB，经过轻量化和Draco压缩后，转成3DTiles只有3GB左右，Web端加载流畅很多。

5.4 数据下载与使用的合规提醒

最后说一个容易被忽视的点：数据合规。倾斜摄影数据可能涉及地理信息，使用和传播要遵守相关规定。下载免费数据时，注意看授权协议，不要用于商业用途或者公开传播。自己采集的数据，也要注意飞行区域的限制。

提示：涉及地理信息的数据，建议在合规框架内使用，避免不必要的麻烦。

6. 我个人的一些实操体会

做倾斜摄影这些年，最大的感受是：工具在变，但底层逻辑没变。坐标系、数据组织、LOD这些概念，从OSGB到3DTiles到未来的新格式，本质都是一样的。把原理搞懂了，换什么工具都能快速上手。

另一个体会是：别追求一步到位。很多人想一次就把整个城市的数据处理好，结果卡在某个环节就放弃了。我的做法是先拿一小块数据跑通全流程，从下载到转换到展示，走一遍。流程通了，再处理大数据只是时间问题。

还有，多动手验证。坐标系对不对，量一下就知道；贴图好不好，看一眼就知道。别光看文档，文档和实际总有差距。

最后分享一个小技巧：如果你经常处理OSGB，可以写一个脚本自动检查metadata、统计文件数、验证坐标系。我自己的脚本跑了三年，帮我省了无数时间。这个后续可以展开讲，先把基础流程走通最重要。