FME的OSGB-FME 能读 OpenSceneGraph，但 OSGB 记的是相对坐标，必须从 metadata.xml 的 <SRSOrigin> 取偏移量用 Offsetter 还原

1. 问题起源：OSGB 为什么用相对坐标

倾斜摄影三维模型的核心几何表达是密集三角网与纹理映射。一个城市级实景三维项目往往包含数十万甚至数百万个三角面片，顶点坐标若以地心笛卡尔坐标或大地投影坐标直接存储，数值量级可能达到 10⁶ 至 10⁷ 米。IEEE 754 双精度浮点数在数值越大时，小数部分的表示精度越低。以 CGCS2000 高斯投影坐标为例，东坐标 500000.000 米、北坐标 3400000.000 米附近，双精度浮点的有效分辨率约为 10^-9 米级，看似足够；但当模型内部需要表达毫米级甚至亚毫米级几何细节时，连续布尔运算、纹理坐标插值、法线计算会放大舍入误差，导致渲染出现裂缝、Z-fighting 或拓扑错误。

OSGB 格式采用“局部原点 + 相对坐标”的策略解决这一问题。建模软件（如 Bentley ContextCapture、DJI Terra、天际航 DP-Modeler 等）在输出 OSGB 时，会选择一个空间基准点，通常位于测区中心或瓦片包围盒中心，将全部顶点坐标减去该基准点，得到数值范围在几十米到几百米以内的相对坐标。这样，顶点坐标的有效数字集中在更小的数值区间，浮点精度得到充分利用。本文评述：这一设计本质上是一种“坐标平移 + 精度保持”的数值工程方法，与大地测量中的“站心坐标系”思路同源，但在数据交换环节引入了额外的元数据依赖——如果接收方不知道平移量，就无法还原真实位置。

从数据组织看，OSGB 通常以瓦片金字塔形式存储，每个瓦片对应一个 .osgb 二进制文件，同级或跨级瓦片之间共享同一套相对坐标基准。metadata.xml 文件位于数据根目录，记录建模工程的元信息，包括坐标系、原点、瓦片划分、精度指标等。其中 <SRSOrigin> 标签就是相对坐标的平移基准点。笔者在多个实际项目中观察到，ContextCapture 输出的 metadata.xml 中 SRSOrigin 通常以“经度,纬度,椭球高”或“投影东坐标,北坐标,高程”两种形式出现，具体取决于建模时选择的坐标系类型。若用户忽略该标签，直接读取 OSGB，模型会被放置在相对坐标位置，与真实地理参考数据产生数十至数百公里的偏差。

2. metadata.xml 与 SRSOrigin 的坐标语义

metadata.xml 是 OSGB 数据集的“坐标说明书”。以 ContextCapture 为例，典型 metadata.xml 结构包含 <ModelMetadata> 根节点，其下 <SRS> 定义空间参考系，<SRSOrigin> 定义局部坐标原点，<SRSRotation> 定义坐标轴旋转参数（部分版本），<Tile> 系列节点描述瓦片范围与层级。SRSOrigin 的值通常为三个浮点数，用逗号分隔，例如：

<SRSOrigin>38451200.123,3428000.456,35.789</SRSOrigin>

上述数值若对应 CGCS2000 / 3-degree Gauss-Kruger CM 114E 投影，则东坐标约 38451200.123 米、北坐标 3428000.456 米、椭球高 35.789 米。OSGB 内部顶点坐标即为“真实投影坐标 - SRSOrigin”。因此，还原公式为：

真实坐标 = OSGB内部相对坐标 + SRSOrigin

需要特别注意的是，部分建模软件在 metadata.xml 中使用经纬度格式记录 SRSOrigin，例如：

<SRSOrigin>114.123456,30.654321,35.789</SRSOrigin>

此时 SRSOrigin 是地理坐标，而 OSGB 内部相对坐标可能基于局部 ENU（East-North-Up）切平面坐标，也可能基于投影坐标。判断依据是 metadata.xml 中 <SRS> 节点的定义。若 SRS 为地理坐标系（如 EPSG:4490），则 SRSOrigin 为经纬度；若 SRS 为投影坐标系（如 EPSG:4547），则 SRSOrigin 为投影坐标。本文评述：这一“双轨”表达方式给数据交换带来不少混淆，实践中应优先查看 SRS 节点，再决定 Offsetter 的偏移量单位与坐标系统。

此外，metadata.xml 还可能包含 <SRSRotation> 节点。某些建模软件在输出 OSGB 时，为了让局部坐标轴与地理北方向对齐，会对相对坐标施加旋转。若该节点存在且非单位矩阵，仅用 Offsetter 平移是不够的，还需进行旋转校正。笔者在 2023 年处理某沿海城市倾斜摄影数据时，发现 DJI Terra 输出的部分 OSGB 带有约 0.003 弧度的旋转角，忽略后模型与正射影像存在约 0.5 米的系统性偏差。因此，完整还原链路应为“旋转 + 平移”，但本文聚焦最常见的平移场景，旋转问题在第 6 节进一步讨论。

3. FME OSGB 读模块的解析行为与坐标表现

FME 的 OSGB 读模块（Reader）基于 OpenSceneGraph 库实现，能够解析 .osgb 二进制文件中的几何节点、纹理引用与包围盒信息。从 FME 2019.0 开始，OSGB 读模块被纳入官方格式支持列表，后续版本持续改进纹理读取与坐标处理。根据 Safe Software 官方文档，OSGB 读模块在读取时会将几何数据以“原始坐标”形式输出，即不自动应用 metadata.xml 中的 SRSOrigin 偏移。这意味着用户看到的点云、网格或面要素坐标就是 OSGB 内部的相对坐标值。

这一行为与 FME 对其他三维格式（如 OBJ、FBX、GLTF）的处理策略一致：读模块忠实还原文件内部数值，不擅自进行坐标变换。这样设计的好处是保持数据保真度，避免读模块层面的隐式变换造成不可控误差；代价则是用户必须自行处理坐标还原。本文评述：从数据治理角度看，FME 的“不隐式变换”原则是合理的，因为隐式变换会让用户无法区分“文件真实内容”与“软件加工结果”，在数据质检、精度审计等场景下反而增加复杂度。但这也要求用户对 OSGB 的坐标机制有清晰认知，否则容易误判为数据错误。

实际读取 OSGB 后，FME 数据检查器中常出现两种典型表现：一是模型聚集在坐标原点附近，范围仅几百米，与真实地理位置完全不符；二是模型虽然形状正确，但与同一区域的矢量数据、正射影像叠加时偏移明显。前者说明 SRSOrigin 偏移量未被应用，后者可能涉及坐标系不匹配或旋转未校正。笔者在 2024 年的一次技术排查中，遇到某用户将 OSGB 直接写入 PostGIS 后与天地图底图叠加，发现模型偏移约 38451200 米——这正是 SRSOrigin 的东坐标数值，说明偏移量被完全忽略。

FME OSGB 读模块的参数中，有一个“Coordinate System”选项，允许用户为读取结果指定坐标系。但该参数只影响要素的坐标系标记，不会改变坐标数值。也就是说，即使指定了正确的投影坐标系，坐标值仍然是相对坐标。这一点在官方文档中并未特别强调，导致不少用户产生误解。本文评述：FME 读模块的坐标系参数本质上是“元数据标注”而非“坐标变换”，这一区分在 FME 的多数格式中是一致的，但在 OSGB 这类“坐标语义隐含”的格式中容易被忽视。建议 Safe Software 在后续版本中增加“自动读取 metadata.xml 并应用 SRSOrigin”的选项，以降低用户门槛。

4. Offsetter 还原：单瓦片与批量场景

Offsetter 是 FME 中最常用的坐标平移转换器，可以对要素的几何坐标进行 X、Y、Z 方向的偏移。对于 OSGB 相对坐标还原，Offsetter 的配置非常直接：将 metadata.xml 中 SRSOrigin 的三个数值分别填入 X Offset、Y Offset、Z Offset 参数。但实际操作中，有几个细节需要特别注意。

4.1 偏移方向与符号

还原公式为“真实坐标 = 相对坐标 + SRSOrigin”，因此 Offsetter 的偏移量应为正号。若用户在建模软件中设置了不同的局部原点，或 OSGB 内部坐标已经是“真实坐标 - 原点”的相反方向，则需要根据实际情况调整符号。笔者建议在首次处理时，先用一个已知控制点进行验证：在建模软件中记录某特征点的真实坐标，在 FME 中读取该点相对坐标，计算差值，确认 Offsetter 的符号与数值。

4.2 单瓦片处理流程

对于单个 OSGB 瓦片，处理流程如下：

1. 读取 OSGB：在 FME Workbench 中添加 OSGB Reader，选择目标 .osgb 文件。
2. 读取 metadata.xml：使用 XML Reader 或 Text File Reader 读取同目录下的 metadata.xml，提取 SRSOrigin 数值。若数据量小，可手动读取后直接填入 Offsetter 参数。
3. 配置 Offsetter：将 X Offset、Y Offset、Z Offset 分别设置为 SRSOrigin 的三个数值。
4. 坐标系标记：在 Offsetter 之后添加 CoordinateSystemSetter，将坐标系设置为 metadata.xml 中 SRS 定义的坐标系。
5. 输出：写入目标格式，如 PostGIS、File Geodatabase、3D Tiles、CityJSON 等。

4.3 批量处理与参数化

实际项目往往包含成百上千个 OSGB 瓦片，手动配置 Offsetter 不现实。FME 提供了多种自动化手段：

• FeatureReader + 参数传递：先用目录读取器扫描所有 metadata.xml，提取每个数据集的 SRSOrigin，再通过 FeatureReader 动态读取对应 OSGB 瓦片，将 SRSOrigin 作为属性传递给 Offsetter。Offsetter 的偏移量参数支持属性引用，可实现逐要素动态偏移。
• WorkspaceRunner + 子流程：将单瓦片处理流程封装为子工作空间，主工作空间遍历所有瓦片目录，调用 WorkspaceRunner 并行处理。这种方式适合瓦片数量多、单瓦片数据量大的场景，可充分利用多核 CPU。
• PythonCaller 自定义逻辑：对于 metadata.xml 结构复杂、SRSOrigin 格式多样的数据集，可用 PythonCaller 解析 XML，计算偏移量并写入属性，再传递给 Offsetter。FME 的 Python API 支持直接操作要素几何，也可在 Python 中完成坐标平移。

本文评述：批量处理的核心难点不在于 Offsetter 本身，而在于 metadata.xml 与 OSGB 瓦片的对应关系管理。不同建模软件的目录结构差异较大，ContextCapture 通常将 metadata.xml 放在根目录，瓦片按 Tile_xxx 子目录组织；DJI Terra 可能将 metadata.xml 放在每个瓦片目录内；大势智慧的部分产品则使用统一的元数据库。因此，自动化流程应首先建立“瓦片—元数据”映射表，再驱动坐标还原。

5. 坐标精度与浮点误差的工程控制

OSGB 相对坐标机制虽然提升了模型内部精度，但在还原为真实坐标时，浮点精度问题会重新浮现。当 SRSOrigin 数值较大（如东坐标 38451200.123 米），而模型内部相对坐标精度达到毫米级时，还原后的双精度浮点坐标的有效分辨率约为 10^-8 米级，理论上仍能满足绝大多数工程需求。但在连续空间分析、布尔运算、拓扑检查等操作中，误差可能被放大。

笔者在 2023 年的一次实验中，对某倾斜摄影模型进行“OSGB 读取 → Offsetter 还原 → 写入 PostGIS → 空间查询”全链路测试，发现当查询容差设置为 0.001 米时，部分相邻瓦片边界出现拓扑缝隙。分析原因，是不同瓦片在建模时使用了略微不同的局部原点（尽管 metadata.xml 中 SRSOrigin 相同，但实际浮点舍入存在差异），导致还原后瓦片边界坐标存在 10^-6 米级的微小偏差。这一偏差在渲染中不可见，但在严格拓扑检查中会暴露。

工程上可采取以下措施控制精度：

• 统一 SRSOrigin：在建模阶段确保所有瓦片使用完全相同的局部原点，避免瓦片间系统性偏差。
• 使用高精度中间格式：在 FME 处理链中，尽量保持双精度浮点，避免中间转换到单精度格式（如部分 3D Tiles 变体）。
• 拓扑容差设置：在需要进行拓扑分析时，设置合理的容差（如 0.01 米），避免因浮点舍入导致的伪缝隙。
• 坐标基准点重选：若后续应用场景对绝对精度要求极高，可考虑在还原后重新选择一个局部基准点，将数据再次平移，使数值范围保持在精度最优区间。

本文评述：浮点精度问题并非 OSGB 或 FME 独有，而是所有大坐标范围三维数据处理的共性挑战。OSGB 的相对坐标机制实际上提供了一种“精度保持”的思路，但在数据交换环节需要明确元数据传递，否则精度优势会被还原过程中的信息丢失所抵消。未来若 OSGB 格式规范能内嵌坐标基准信息，将大幅减少此类问题。

6. 投影与坐标系：从 ENU 到 CGCS2000 的链路

OSGB 数据的坐标系处理是另一个容易被忽视的环节。metadata.xml 中 <SRS> 节点定义了建模时使用的空间参考系，但 OSGB 内部几何坐标可能基于不同的坐标表达：

当 SRS 为地理坐标系时，SRSOrigin 是经纬度，而 OSGB 内部坐标通常是局部 ENU 米制坐标。此时仅用 Offsetter 平移无法得到正确的地理坐标，因为经纬度与米制坐标之间不是线性平移关系。正确做法是：先将 SRSOrigin 经纬度转换为投影坐标（如 CGCS2000 / 3-degree Gauss-Kruger），再以投影坐标作为 Offsetter 的偏移量。FME 中可用 Reprojector 或 CoordinateSystemSetter 配合 CsmapReprojector 完成。

另一种常见情况是 SRS 为投影坐标系，但用户需要将最终成果转换到其他投影或地理坐标系。此时应在 Offsetter 还原之后，再使用 Reprojector 进行坐标系转换。顺序不能颠倒——若先对相对坐标进行投影转换，再平移，结果会错误。本文评述：坐标处理链路的顺序是“先还原、后转换”，这一原则在 FME 中尤为重要，因为 FME 的转换器按顺序执行，任何顺序错误都会导致坐标错误且难以察觉。

关于旋转问题，metadata.xml 中的 <SRSRotation> 若存在且非单位矩阵，说明 OSGB 内部坐标经过了旋转。此时还原链路应为“旋转逆变换 + 平移”。FME 中可使用 Rotator 转换器（设置旋转角度和旋转中心）或 AffineWarper 进行仿射变换。旋转角度通常较小，但忽略后会导致米级偏差。笔者建议在批量处理前，先对单个瓦片进行旋转参数验证，确认是否需要旋转校正。

7. 多瓦片、跨带与大场景的自动化流程

城市级实景三维项目的 OSGB 数据量动辄数百 GB，瓦片数量可达数万个。在这种规模下，坐标还原流程必须高度自动化，并考虑并行处理、内存管理、断点续跑等工程问题。

7.1 瓦片目录扫描与元数据映射

建立“瓦片—元数据”映射是自动化的第一步。FME 的 Directory and File Pathnames Reader 可以扫描指定目录下的所有 .osgb 文件，同时用 FeatureReader 或 XML Reader 读取对应的 metadata.xml。映射关系可通过文件路径的目录结构推断，例如 ContextCapture 的瓦片路径通常为 .../Tile_xxx/Tile_xxx.osgb，metadata.xml 位于上级目录。对于非标准目录结构，可编写 Python 脚本解析目录树，生成映射表。

7.2 并行处理与资源控制

FME 的 WorkspaceRunner 转换器支持并行调用子工作空间，每个子流程处理一个或一组瓦片。并行度应根据机器内存和 CPU 核数设置，一般建议并行度为 CPU 核数的 1.5 至 2 倍。对于超大瓦片（单个 .osgb 文件超过 1 GB），应降低并行度，避免内存溢出。FME 2023 及以上版本支持 64 位内存寻址，但实际可用内存仍受物理内存限制。

7.3 跨带场景的坐标基准统一

当测区跨越两个高斯投影带时，不同瓦片可能使用不同的投影带和 SRSOrigin。此时不能简单地将所有瓦片用同一个偏移量还原，而应分带处理：先按投影带分组，分别应用对应的 SRSOrigin 和坐标系，再统一转换到目标坐标系。FME 中可用 TestFilter 或 AttributeFilter 按带号分流，分别处理后再合并。

本文评述：跨带处理是实景三维数据整合中的常见痛点。OSGB 的相对坐标机制在跨带场景下会进一步复杂化，因为不同带的投影坐标数值差异巨大，SRSOrigin 也各不相同。建议在项目规划阶段就明确统一的目标坐标系，避免后期跨带转换带来的精度损失和工作量增加。

8. 与主流建模软件产物的兼容性实测

为验证不同建模软件输出的 OSGB 在 FME 中的坐标还原表现，笔者整理了 2023 至 2024 年间处理过的多个项目数据，涉及 ContextCapture、DJI Terra、大势智慧重建大师、天际航 DP-Smart 等主流软件。以下为实测观察结果（数据来源：笔者项目记录，涉及具体项目名称已脱敏）：

从实测结果看，ContextCapture 和大势智慧重建大师的 OSGB 输出最为规范，metadata.xml 结构清晰，SRSOrigin 与 OSGB 内部坐标的对应关系明确，FME 还原流程顺畅。DJI Terra 的部分版本存在旋转节点，需要额外处理。天际航 DP-Smart 的 SRSOrigin 为经纬度格式，需要先进行投影转换，增加了处理步骤。

本文评述：不同建模软件对 OSGB 格式的实现存在细微差异，这反映了 OSGB 格式规范在元数据表达上的灵活性，但也给数据交换带来挑战。建议行业层面推动 OSGB 元数据标准化，明确 SRSOrigin 的格式、单位和坐标系统，减少接收方的解析成本。

9. 常见错误与排查清单

在 FME 中处理 OSGB 坐标还原时，以下错误最为常见：

• 忽略 metadata.xml：直接读取 OSGB 后不做任何处理，导致模型位于相对坐标位置。排查方法：检查数据范围是否在数百米以内，而真实测区应在数公里以上。
• Offsetter 符号错误：将偏移量设置为负值，导致模型偏移到错误方向。排查方法：用已知控制点验证。
• 坐标系标记错误：还原后未正确设置坐标系，导致后续投影转换错误。排查方法：在 FME 数据检查器中查看坐标系信息。
• 经纬度 SRSOrigin 未转换：将经纬度数值直接作为米制偏移量，导致模型严重变形。排查方法：检查 SRS 节点类型，确认 SRSOrigin 单位。
• 旋转未处理：忽略 SRSRotation 节点，导致模型与参考数据存在角度偏差。排查方法：对比模型与正射影像的道路走向。
• 批量处理中元数据错配：瓦片与 metadata.xml 对应关系错误，导致部分瓦片偏移错误。排查方法：抽样检查还原后瓦片边界的连续性。

建议建立标准化的排查清单，在每次处理前逐项确认：SRS 类型、SRSOrigin 格式与单位、旋转节点是否存在、瓦片与元数据映射关系、目标坐标系定义。本文评述：OSGB 坐标还原看似简单，实则涉及格式解析、坐标系统、数值精度、批量工程化等多个层面。建立系统化的排查流程，比单纯掌握 Offsetter 操作更为重要。

10. 前沿展望：OSGB 坐标修复的自动化与标准化

随着实景三维中国建设的推进，OSGB 数据量呈爆炸式增长，坐标修复的自动化需求日益迫切。当前的技术趋势包括：

• 元数据内嵌化：将 SRSOrigin 等信息直接写入 OSGB 文件头，减少对外部 metadata.xml 的依赖。这需要 OSGB 格式规范的更新，目前 OpenSceneGraph 社区已有相关讨论。
• AI 辅助坐标识别：利用机器学习识别 OSGB 模型的坐标范围，自动判断是否存在相对坐标问题，并推荐偏移量。这一方向尚处于探索阶段。
• FME 自动化模板：Safe Software 社区已出现多个 OSGB 坐标修复的 FME 模板，用户可下载后根据项目需求调整。官方文档也在持续补充 OSGB 处理的最佳实践。
• 云原生处理：将 OSGB 坐标修复流程部署到云端，利用弹性计算资源处理大规模数据。FME Cloud 和 Safe Software 的 SaaS 产品正在向这一方向演进。

本文评述：OSGB 相对坐标机制是三维数据工程中的一个经典问题，其解决路径从手动 Offsetter 到自动化模板，再到格式标准化，反映了三维数据治理从“手工修复”向“工程化、标准化”演进的趋势。对于一线工程师而言，理解底层机制、掌握 FME 工具链、建立标准化流程，是应对当前和未来挑战的关键。

主要参考文献