简介：OSGBTool.rar是一份基于C++、无需额外环境配置的倾斜摄影测量模型查看器工程包，面向GIS三维开发者和倾斜摄影数据处理人员，解决OSGB格式三维模型的高效查看与解析学习需求。OSGB格式由英国国家测绘局推出，广泛用于存储倾斜摄影测量模型，包含位置、高度、纹理等属性，可用于城市规划、建筑可视化等领域。资源共2672个文件，压缩包约52.68MB，主要包含949个头文件、9个cpp源文件，以及dll、lib、obj、pdb等编译产物；头文件覆盖大量Qt界面组件与OSG三维场景节点（如geode、ref_ptr、terrainmanipulator），便于研究数据渲染、交互漫游与界面实现。当前已有641人学习浏览。压缩包内提供完整C++工程源码及构建中间文件，读者可以对照源码理解OSGB模型解析、三维渲染和交互操作的具体实现，也可参考Qt与OSG的结合方式完成二次开发，具有较高的工程参考价值。
1. 一个压缩包解决倾斜摄影模型三件大事：OSGBTool 到底是做什么的
做倾斜摄影数据处理的人，大概率都收到过这样的压缩包：同事丢过来一个 OSGBTool.rar，附带一句“这个能转 OSGB，你试试”。OSGB 不是单个模型文件，而是倾斜摄影建模软件导出的一整棵瓦片树，包含成百上千个分块文件和层级目录。平时用的三维查看器、GIS 平台、游戏引擎绝大多数不能直接读这种格式。你需要的工具至少要能干三件事：把 OSGB 转成通用格式、处理坐标原点和偏移、合并或轻量化瓦片。OSGBTool 这一类工具解决的就是这三件事。本文不依赖某个特定版本源码，所有命令和脚本按这类工具最常见的使用方式整理，新手可以直接抄，熟手可以对照参数边界做二次开发。
2. OSGB 格式为什么要专门做工具：先搞懂瓦片、LOD 与坐标原点
2.1 OSGB 不是单一模型文件：金字塔瓦片结构是理解一切的前提
很多人第一次打开 OSGB 数据时都懵了：解压后不是一个大模型文件，而是一个 Data 目录，里面全是 Tile_+000_+000 这种编号文件夹，每个文件夹下又有 L12、L13 这类子目录。这才是 OSGB 的真实形态——一个按空间网格切分的金字塔瓦片树。
典型的目录长这样：
Data/ ├── Tile_+000_+000/ │ ├── Tile_+000_+000.osgb │ └── L12/ │ ├── Tile_+000_+000_L12_0.osgb │ ├── Tile_+000_+000_L12_1.osgb │ └── ... ├── Tile_+000_+001/ │ ├── Tile_+000_+001.osgb │ └── L12/ │ └── ... └── metadata.xml瓦片文件本身是基于场景图序列化的二进制容器，里面记录了几何顶点、法线、三角面索引，以及纹理贴图的相对路径引用。把 OSGB 文件用文本编辑器打开看是乱码，这是正常的——它是二进制序列化格式，不是文本格式。
分块的意义在于渲染裁剪。一块 5 平方公里的城市实景模型，如果整个加载进内存，几十 GB 很正常。建模软件会按空间范围切成 Tile，每个 Tile 内部再按细节层次生成 LOD 层级。视锥裁剪只加载视口范围内的 Tile，LOD 机制按距离决定加载哪一层细节。理解这个结构，你就明白为什么工具必须一瓦片一瓦片地处理，而不是把整个 Data 目录当成一个整体文件。
以我处理某测区 1.2 平方公里单体建筑模型的经验：源数据共 3000 多个瓦片文件，纹理总数超过 1 万张。如果转换工具不支持批量与 LOD 控制，单靠人工挑选瓦片导出，一次作业就要耗掉整个下午。
2.2 局部坐标系与原点：为什么模型一到别的软件里就飞走
OSGB 最坑人的地方不在二进制格式，而在坐标系。倾斜摄影建模软件在空三计算时，通常使用测区附近的局部坐标系，输出瓦片时把全局坐标减去一个原点偏移，只存相对偏移量。这个原点可能记录在 metadata.xml 里，也可能被硬编码进建模工程的设置中。
当你在另一个软件里直接加载 OSGB 瓦片时，软件只看到局部坐标下的顶点。不知道原点偏移是多少，模型就会出现在世界坐标系原点附近，或者散落到几十公里外。很多新手把模型导进引擎后一脸茫然——模型不在预期位置，甚至飞到空中或钻入地下十几米。这不是数据坏了，是坐标偏移没处理。
metadata.xml 是排查坐标系问题的第一入口：
cat metadata.xml正常你会看到类似这样的内容：
<SRS>EPSG:4547</SRS> <Origin x="500000.000" y="3400000.000" z="50.000"/> <Envelope minx="500012.34" miny="3400012.34" maxx="510012.34" maxy="3410012.34"/>Origin 就是建模时设置的原点坐标，SRS 是坐标参考系代码。OSGB 瓦片顶点里保存的坐标，本质上是真实坐标减去这个 Origin 后的差值。加载时要么把顶点加上 Origin，要么把转换矩阵统一设置成这个偏移量。OSGBTool 这类工具的“坐标转换”功能，底层做的就是这件事。
2.3 OSGBTool 的三种处理主线：转换、合并、轻量化
把需求归纳起来，工具的能力模型就三条主线。
格式转换：OSGB 到 OBJ、OSGB 到 3D Tiles。OBJ 适合在传统三维软件里编辑，3D Tiles 适合在 Web 端渲染。还有 OSGB 到 IFC、OSGB 到 GLB 等少见需求，本质都是做二进制解析和重新序列化。
坐标处理：常见的是整体平移、三参数转换、七参数转换。平移最简单，即在所有顶点坐标上加上固定的 x/y/z 偏移，适合恢复原地坐标系。七参数转换还涉及旋转和尺度因子，适合把地方坐标系成果转到国家坐标系或 CGCS2000 下。这一步错了，模型方位会偏，甚至整个测区倒过来。
瓦片合并与轻量化：多区块建模成果合到一个工程时，需要合并瓦片树并重建索引；要做 Web 端展示时，把高层级 LOD 删掉或合并，可以显著降低三角面数和纹理大小。
这三个主线不是互相独立的。转换时经常要同时做坐标偏移；合并时也要保持新瓦片树的坐标原点与包围球正确。工具如果只提供单一功能，后面每一环节都要手动补脚本，非常容易出错。
3. 动手跑通 OSGBTool 第一组命令：格式转换与目录结构解析
3.1 解包与文件清单确认：先看 Data 目录和 metadata.xml
拿到 OSGBTool.rar 后，先别急着双击。第一步解压并确认目录结构，防止工具找不到工作路径。
# Linux 下解压 rar 包，Windows 上也可以用 7-Zip 解压 unrar x OSGBTool.rar # 进入工具目录，查看可执行程序和依赖库 cd OSGBTool ls -la解压后你会看到主程序、若干动态链接库和一个说明文档。这类工具大多不要求安装，直接运行目录下的可执行文件即可。如果运行时报缺少 DLL，通常是把工具放在带空格的路径里导致的，建议把整个工具目录挪到盘符根目录下，比如 D:\OSGBTool。
接下来确认数据目录结构：
# 统计瓦片数量和层级分布 find Data/ -name "*.osgb" | wc -l # 查看最高 LOD 层级 find Data/ -maxdepth 2 -type d | sort | tail -20统计瓦片数量很重要。如果总数在几千片以上，转换时间就不是分钟级而是小时级，你要规划好机器内存和磁盘空间。层级目录里常见的 L12、L13、L14 表示不同细节等级，L 后面的数字越大，模型细节越精细，同时文件数量也越多。转换时如果全层级处理，时间和磁盘需求都会倍增；只保留顶层 LOD 的话，模型会很粗糙，但速度快很多。
3.2 把 OSGB 瓦片批量转成 OBJ/3D Tiles：核心命令
这类工具的命令行模式大致可以概括为四个参数：输入路径、输出路径、输出格式、坐标系处理方式。
我是按这种习惯来组织转换命令的：
# 格式转换常用参数组合 ./osgb_tool convert \ --input ./Data \ --output ./Output \ --format obj \ --srs EPSG:4547 \ --origin 500000,3400000,50 \ --lod max \ --merge-single-mesh各参数含义：--input指向 Data 目录，工具会自动递归识别瓦片树；--output是输出目录，建议与输入目录放在不同磁盘分区，避免读写竞争；--format指定输出格式，obj 用于离线编辑、3dtiles 用于 Web 端发布；--srs与--origin决定顶点如何从局部坐标转换到真实坐标；--lod max表示输出包括所有层级的最高细节版本；--merge-single-mesh将同一 Tile 内的多个 LOD 合并成单个网格，减少 OBJ 文件数量。
这套命令对应的工作流程是：工具读取瓦片树的根节点，递归遍历全部子节点，把每个瓦片内的几何数据解析出来，然后按指定的坐标偏移量重算顶点坐标，最后把多个瓦片网格写入目标格式。如果输出为 3D Tiles，工具还会额外生成 tileset.json，描述瓦片的包围盒和层级关系。
3.3 转换参数说明：纹理采样、LOD 层控制与合并策略
新手最容易忽略的参数是纹理尺寸与采样方式。OSGB 的纹理通常是一张或多张 JPEG/PNG，存在瓦片目录的纹理子文件夹里。转换器读取纹理时，默认会保留原始分辨率。但如果原始纹理每张 2048x2048，输出 OBJ 后同目录会多出几千张图片，导入三维软件时加载极慢。
我一般会这样控制输出质量：
./osgb_tool convert \ --input ./Data \ --output ./Output \ --format obj \ --texture-size 1024 \ --texture-format jpg \ --keep-texture-name--texture-size 1024把超过 1024 像素的纹理等比缩小，--texture-format jpg统一转成 JPG 以减小体积，--keep-texture-name保留原始纹理文件名。如果你需要修改纹理路径，保留原始文件名能让你少改几百个材质引用。
LOD 控制方面，我的经验是：用于离线建模软件精修的，选全部层级输出；用于 BIM 集成或 Web 展示的，只输出L12到L14层级即可，更高级别的瓦片面数过多，只会白白拖慢加载速度。
# Web 展示场景，限制 LOD 级别，输出 3D Tiles ./osgb_tool convert \ --input ./Data \ --output ./OutputTiles \ --format 3dtiles \ --lod-min 12 \ --lod-max 14--lod-min和--lod-max组合使用可以跳过不需要的细节层级。比如测区是 5 平方公里的宏观场景，最高 LOD 是为地面近景拍照准备的，Web 端根本用不到，跳过它能让输出文件体积减少 60% 以上。注意：只输出部分 LOD 时，工具必须保留顶层根节点，否则 3D Tiles 的包围盒会丢失，加载场景时模型会被裁掉。
4. 坐标偏移与七参数：OSGBTool 里最容易被忽略的转换逻辑
4.1 偏移量到底加在哪：从建模软件的局部坐标到工程坐标
坐标偏移是 OSGB 转换里最容易翻车、也最不好排查的环节。前面说过，瓦片内保存的是相对原点坐标。工具在转换时会读取 metadata.xml 里的 Origin 字段，把偏移加回顶点。但问题在于：metadata.xml 的 Origin 未必是你想要的最终坐标系原点。
举一个我处理过的实例：某测区建模时原点设成了测区中心(500000, 3400000, 50)，但这套坐标系是测区的自定义地方坐标系。业主单位要求最终成果必须是 CGCS2000 坐标系下的数据。此时只加 Origin 是不够的，还要在加偏移之后再做一次七参数转换。
工具里对应的做法是在转换时给两个阶段的坐标系参数：
./osgb_tool convert \ --input ./Data \ --output ./Output2000 \ --format 3dtiles \ --origin-position 500000,3400000,50 \ --target-srs EPSG:4547 \ --output-srs EPSG:4499--origin-position是建模原点，--target-srs是建模时使用的坐标系，--output-srs是目标坐标系。工具内部的顺序是：先把局部坐标加回 Origin 得到建模坐标系坐标，再调用坐标转换库转到输出坐标系。如果你的 OSGB 数据在建模时选择的就是 CGCS2000 经纬度坐标系，那么 Origin 可能为零或空，此时只设置--output-srs就行，不要画蛇添足加偏移。
判断要不要加 Origin 的一个简单办法：打开 metadata.xml 确认Origin字段是否为空或全零。全零就说明瓦片顶点直接使用建模坐标系坐标，不需要偏移。任何情况下都不要猜测，直接看源文件记录。
4.2 七参数设置与点位验证：控制点检验法
做国家坐标系转换时，你需要七参数：三个平移参数（ΔX、ΔY、ΔZ）、三个旋转参数（α、β、γ）和一个尺度因子 k。这套参数通常由测绘单位根据测区内的已知控制点解算，不是工具自动生成的。
工具配置七参数的界面或命令行格式，本质上和下面代码表达的计算一致：
import math def seven_param_transform(x, y, z, params): # params: dx, dy, dz, rx, ry, rz, k dx, dy, dz = params[0], params[1], params[2] rx, ry, rz = [math.radians(v) for v in params[3:6]] k = params[6] # 旋转矩阵（小角度近似，实际工程建议用完整矩阵） x2 = dx + (1 + k) * (x + rz * y - ry * z) y2 = dy + (1 + k) * (-rz * x + y + rx * z) z2 = dz + (1 + k) * (ry * x - rx * y + z) return x2, y2, z2 # 用法示例：输入建模坐标点，输出目标坐标点 print(seven_param_transform( 500012.34, 3400012.34, 52.60, [12.5, -8.3, 0.2, 1.2, -0.8, 2.1, 0.0001] ))代码里的旋转矩阵是小角度近似模型。实际七参数解算时，旋转角通常很小（以角秒为单位），小角度近似在大多数工程场景足够。如果旋转角超过数十角秒，必须用完整罗德里格矩阵。
七参数转换后必须用控制点验证。我把验证步骤固定为三步：先取 3 个已知控制点坐标，让工具转换后输出对应成果，在 GIS 软件里叠加对比；再检查三个控制点的残差，平面残差大于 5 厘米时说明参数或坐标系区间不匹配；最后检查模型的边界包围盒是否落在测区范围内。
4.3 不同坐标系混合数据：先统一椭球再转
常见翻车操作是把不同坐标系下建模的多块 OSGB 直接合并。比如一块数据是 CGCS2000 高斯投影，另一块是 WGS84 经纬度，两者在原点附近可能只差几十米，但到测区边缘会偏出几米甚至几十米。直接用整体平移合并，接边处必然错位。
正确的处理顺序是：分别转换到同一个坐标系。我通常先把两块数据的瓦片树都转成 CGCS2000 投影坐标系的 3D Tiles，确认每块数据里的控制点坐标误差合格后，再合并瓦片树。合并前还要检查两个数据分块之间的重叠区域。重叠区存在 1 米以上的裂缝或重叠时，优先检查是不是高程基准不一致，而不是急着调整合并参数。
这里有一个万能的临时验证脚本思路：把两块数据各导出 5 到 10 个同名地面点坐标，写成文本文件，用下面脚本计算点位互差：
with open('points_a.txt') as f: pts_a = [tuple(map(float, line.split())) for line in f] with open('points_b.txt') as f: pts_b = [tuple(map(float, line.split())) for line in f] for pa, pb in zip(pts_a, pts_b): d = ((pa[0] - pb[0]) ** 2 + (pa[1] - pb[1]) ** 2) ** 0.5 print(f"平面偏差: {d:.3f} m")点位互差超过 0.1 米时，大概率是椭球基准或投影带参数设置不一致，先别动合并功能，回头检查坐标系参数。
5. OSGBTool 避坑实录：五条真实踩坑记录
5.1 转换完模型是黑块：纹理路径被重写
现象：OSGB 转换成功，OBJ 导入三维软件后模型表面全是黑色，几何结构正常但一张纹理都没有。
原因：转换工具把 OSGB 里的纹理文件复制到输出目录后重写了相对路径。OBJ 的 MTL 文件里记录的纹理名与实际文件名对不上，软件按路径找不到贴图时就渲染成黑色。我遇到的具体情况是：原始纹理文件名带中文，工具转码后变成拼音加数字索引。
解决：转换时使用--keep-texture-name保留原始文件名，同时确保输出目录不要包含中文路径。转换完成后打开 MTL 文件抽查，确认map_Kd后面的文件名与对应图片文件真实存在。
5.2 合并瓦片后模型重叠错位：原点与包围球参数不一致
现象：把两个区块的 OSGB 合并成一个工程后，加载场景时模型分成两半，中间错开十几米，有时还有重影。
原因：两区块建模时使用了不同的原点坐标，合并工具默认按第一个区块的原点重算所有瓦片，但第二个区块的 metadata.xml 中 Origin 没被正确读取，顶点被加上了错误的偏移。
解决：合并前分别打开两个区块的 metadata.xml，确认 Origin 完全一致。不一致时，先把第二个区块单独转换并指定--origin-position为它的实际建模原点，这样数据统一后再合并。合并完成后再叠加一次检查，确保两个区块的接边处没有缝和重影。
5.3 大场景转换时内存暴涨崩溃：LOD 分支被全部加载
现象：转换 10 平方公里测区时，工具运行到一半内存占用飙到 90% 以上，进程被系统杀掉或直接闪退。
原因：工具在递归遍历瓦片树时，默认把顶层根节点下的所有子节点都加载到内存做包围盒计算。当某个 Tile 包含几十个 L12 子节点，每个子节点又有几十个 L13 子节点时，内存叠加非常快。
解决：在命令中加入 LOD 范围限制。我处理大场景时固定使用--lod-min 12 --lod-max 14与--max-memory 8192这类参数，分区域转换比一次性全场景更稳定。如果工具没有内存限制参数，就手动把 Data 目录按 Tile 前缀拆成多个分目录，逐个转换后再合并。
5.4 坐标转换后模型悬空或下沉：高程基准不一致
现象：七参数转换后平面位置正确，但模型整体比原地形高 0.5 米，部分建筑悬空。
原因：高程基准不一致。建模软件可能使用椭球高，而目标坐标系使用正常高，两者之间隔着一个高程异常值。七参数只解决平面与椭球转换，不解决高程异常改正。
解决：确认测区的似大地水准面模型或高程异常值。比如某测区高程异常约 40.2 米，转换时把--z-offset -40.2加进参数中。不确定数值时找测绘单位要测区高程异常图，不要用公式硬算。模型整体出现均匀高度差，基本就是这个原因。
5.5 转出的 OBJ 文件碎成几百个小文件
现象：一个 Tile 转换后输出十几个 OBJ 文件，整个测区生成了几百个 OBJ，每个文件只有几十 KB，导入三维软件时操作卡顿。
原因：工具默认不合并同一 Tile 下的多个 LOD 节点，瓦片树里每个子节点单独输出成一个网格。
解决：转换命令加上--merge-single-mesh。控制台日志会输出每个 Tile 的节点数量，合并后一个 Tile 对应一个 OBJ 文件。要注意：合并参数对 OBJ 有效，对 3D Tiles 无效——3D Tiles 格式本来就需要多个节点维持 LOD 关系。
6. 验证与进阶：用控制点与批处理脚本把工具用到极致
6.1 输出质量的三重验证：坐标系、三角网、纹理
转换完别急着交付，花十分钟做三件事。第一验证坐标系：在 GIS 软件里加载输出文件，把范围线与测区边界叠加，确认平面位置偏差在厘米级；再检查模型与 DOM、DEM 的相对关系，看房顶、地面是否与影像贴合。第二验证三角网：用查看软件打开模型旋转视角，找几个边角区域观察有没有破面、三角面翻转和黑洞；出现破面时回到源数据检查是不是瓦片本身缺失，而不是转换器问题。第三验证纹理：随机抽查 10 个 Tile 的纹理，确认清晰度是否达到预期，黑块和模糊区域占比是否可接受。
6.2 批处理脚本：多区块一次转换
工具转换通常支持批处理模式，但我不建议直接对整个测区一次性跑完。更稳妥的做法是分区块、分批次执行，配合脚本自动生成命令。下面是一个最简单的批处理脚本骨架：
#!/bin/bash # 按区块批量转换，每个区块独立执行 for region in region_A region_B region_C; do ./osgb_tool convert \ --input ./$region/Data \ --output ./$region/Output \ --format 3dtiles \ --srs EPSG:4547 \ --origin-position 500000,3400000,50 \ --lod-min 12 \ --lod-max 14 echo "$region 转换完成" done脚本把每个区块的输出放到对应目录，方便后续检查和对照。如果某个区块失败，重新执行该区块即可，不会影响其他区块的结果。
6.3 进阶用法：只转顶层 LOD 够不够
有一个高频需求是“只转顶层 LOD 做预览”。做法是--lod-min 0 --lod-max 0，输出文件只有根节点瓦片，整体是一个粗糙的模型壳。这非常适合快速检查测区范围与模型完整性。注意事项是：预览模型无法用于测量，因为细节丢失严重。如果你需要预览的同时保留量测能力，最少保留到 L13 层级。
做了一阵子 OSGB 处理之后，我的习惯是每接一批新数据先跑通最小可用的转换链路，用一个小区块验证参数，再全量跑。直接全量处理而不做预验证，等到跑完才发现坐标偏了，重新转换的时间足够让人彻底怀疑人生。工具本身并不复杂，问题往往出在你对它“暗地里做了什么”的假设上。希望这篇笔记能帮你把 OSGB 转换这条路走顺，少走几次弯路。
本文还有配套的精品资源，点击获取
