前不久，终于对osgb以及3dtiles的数据结构有了足够的了解，成功地利用FME将osgb数据转换成了3dtiles数据。于是，我开心地决定先来写一下如何将osgb转换成3dtiles数据。

为了让大家能够比较详细的了解这两个数据格式，该系列文章一共分为上下两篇，我将会从osgb与3dtiles的数据结构以及层级构建两个方面对其进行介绍。下篇仍在酝酿中，所以我们可以先将此篇作为单篇来看。

本篇文章，仅讲解osgb与3dtiles的数据结构，不会涉及到层级等等的介绍，但为了能够成功的看到我们最终转换出来的数据效果，因此我们仅挑选osgb中的一个层级进行转换，这样能有效地排除层级渲染的时候对数据最终效果的影响。

要想正确的对这两个数据进行转换，我们需要对这两个数据进行一些初步的了解。

首先什么是osgb数据？什么是3dtiles数据？他们两个数据之间有什么差异？

不知道大家有没有想过，为什么市面上能够找到osgb数据向3dtiles数据格式转换，却鲜有能够将3dtiles转换成osgb数据的？是否是这两个数据格式之间存在着很大的差异？

我也一头雾水，后来请教了一个3dtiles数据的大佬。

他跟我说：“理论上，3dtiles是可以转换成osgb数据的，不过成本很大。因为诸如osgb数据转3dtiles本质上是将对人类友好的对象型数据，裂解为对GPU友好的图形编程型数据；以3dtiles、gltf等格式的数据，是为了怎么渲染快怎么来，从来没有考虑过往回倒的余地。”

嗯，了然，就是说这类型数据就不是创建出来给人看的而是给计算机看的，可二次利用率很低。

好了，明白了这个道理，我就不再纠结回转了。

现在我们看一下，这两个数据的区别。

osgb数据，通常渲染在平面坐标场景上，其数据使用的是ENU坐标系。我更习惯叫它相对坐标，在其数据本身的坐标数值上，再加入坐标原点的值，即是正常的载体坐标（通常为2000平面坐标）。其坐标原点及坐标系定义存储在名为“metadata.xml”的xml文件内，长宽高单位为米。

而3dtiles数据格式，则是渲染在球面场景上，坐标常为wgs84经纬度坐标，（也可能为2000经纬