距离谷歌倾斜摄影OSGB数据V1.2版发布已三月有余，这三个月除了忙于对转换软件进行Bug修复和数据效果提升外，最重要的是解决一个比较严重的问题，即倾斜摄影数据中除了倾斜摄影外，还包含没有倾斜摄影的影像数据。从软件V0.1版免费向大家发布成果数据后，用户就针对这个问题提了意见与建议，虽然比较迫切，但是这个软件有更重要的问题，包括瓦片缺失、数据偏移等显示重要问题没有解决，这个问题的优先级排到了后面，一直待V1.2版本发布后，才排上解决日程，经过两个月艰苦预研、开发、测试和验证，问题终于得以解决，因此将转换软件升级到2.0版。在介绍V2.0版软件之前，我们先回顾一下这款数据转换软件的研发背景与更新历史。

一、研发初衷

开发这款软件的初衷，是解决OsgEarth开发过程中OSGB数据匮乏的窘境。在WebGIS还没有兴起之前，国内GIS一直以OsgEarth为GIS渲染引擎，其地位堪比现在Web端的Cesium。主要是因为OsgEarth开源，版本更新迭代也比较及时，开发用户多，公司招人也比较容易，没有后顾之忧；正是因为如此，OsgEarth在国内GIS行业应用越来越广泛，OsgEarth+Qt成为当时GIS开发人员标配，很多GIS公司以OsgEarth为平台，研发了公司的GIS平台，包括GIS桌面、GIS二次开发组件等，其中GIS桌面基本上以OsgEarth+Qt为技术路线，最直接的原因是用户的运行环境基本上就是Linux环境，使用Qt能够解决跨平台的难题，相当方便。随着WebGIS的兴起，GIS系统也纷纷转型拥抱B/S模式，即便如此，OsgEarth仍然在C端GIS开发组件上占据主流地位，虽然OsgEarth历经逾20年的更新迭代，其底层组件已经相当成熟稳定，但是国内开发者和用户一直面临着OSGB数据匮乏的问题，主要是OSGB倾斜摄影数据生产成本太高，一平方公里航拍数据报价高达数千元，寻找大量廉价甚至免费OSGB数据，是解决无米下锅难题的直接解决方案。

二、V0.1版

在V0.1版，主要解决0到1的过程，从0开始的确很难，因为目前市面上没有相关成熟产品，技术路线完全从0开始，从产品立项、需求梳理到功能研发，进行了大量预研，通过分析，主要有以下几条路线：

1.转成OBJ/FBX等中间格式再将数据切割成OSGB

将谷歌倾斜摄影数据转换为obj、fbx等通用三维模型格式，然后使用商业软件(如OSGBLab或大势智慧等软件)或一些开源的工具或代码(osgb2fbx、Cesium3DTilesConverter)，将obj、fbx等三维模型文件转换生成OSGB格式，这条路线对于小范围数据生产没有问题，但是对于大场景数据，就无能为力了。以台北市为例，倾斜摄影数据共计320GB，受限于硬件性能，不可能一次性全下载下来，然后再切割生成OSGB，只能按块进行生成后，再进行拼接，这个过程全程需要人工参与，生产效率低，而且还存在分块数据拼接导致的裂缝等问题，显示效果比较差。

2.使用转换工具，将3DTiles格式数据转换成OSGB

这条路线我刚开始觉得可行，也花了大量时间预研，因为那时候我已经将谷歌倾斜摄影转换生成了3DTiles，如果能将3DTiles转换生成OSGB，那就能一劳永逸，完成谷歌倾斜摄影转换生成OSGB的产品使命。很可惜，目前市面上没有一款工具，能够将3DTiles格式转换成OSGB格式，虽然当前有很多工具和软件能够将OSGB、obj、fbx等各种各样的格式转换成3dtiles格式瓦片，但是反过来转换，没有任何工具和开源算法，也查了很多资料，发现这个无法解决，最后不得不放弃这条路线。

3.将谷歌地球数据直接转成OSGB

那直接将谷歌数据转换成OSGB格式是否可能呢，我在分析了前面三种路线走不通后，经过两个月的艰苦探索与研发，从0到1的问题得以解决。

从上图可以看到，红色箭头线是第1条技术路线，绿色箭头线是第3条技术路线。第三条技术路线不需要通过转成OBJ中间格式，直接生成OSGB，后来也证明了，这条技术路线有很多优势。使用转换工具V0.1版，生成了澳门地区倾斜摄影OSGB数据。

三、V0.2版

V0.1版本解决了0到1的过程，可谓开天辟地，但是这个V0.1版存在很多问题，包括生成效率、生成数据等两个方面，因此V0.2版本进行了针对这些问题进行了优化与修复，主要如下：

1.生产速度大幅提升

V0.1以解决流程问题为主，未考虑生成效率，在V0.2版本中，改成了多线程，生产效率大幅提高，以生产澳门数据为例，V0.1版本需要3个多小时，而使用V0.2版本，仅仅只需30分钟，提升了7倍之多。

2.显示效率大大提升

V0.1版本在构建LOD上，使用了比较基础的LOD构建，在显示效率上并未做优化。V0.2版本大幅优化了LOD构建机制，极大减少当前视景范围内OSGB瓦片调度数量，进而大幅提高数据加载速度和显示效率。

3.数据量压缩20%

V0.1版中并未对OSGB瓦片进行简化，图片是原始Jpg数据，而在V0.2版本中，图片压缩设置为70，数据量减少了20%，但是可视化效果并未有肉眼可见下降。

使用V0.2版工具也是使用澳门地区数据进行测试与验证。

四、V0.3版

这是一个小版本，使用台北地区原始数据进行生产，主要解决三个问题；

1.生成程序崩溃，这是由于多线程引起。

2.OSGB孩子节点为空的问题，虽然不影响显示效果，但是会影响显示效率，因为空节点本来不需要显示，加载空节点反而对显示帧率有较大影响。

3.虽然去掉了空节点，但是又引发了新的问题，瓦片节点缺失，这个问题也得到了解决。通过下面两张图进行对比就可以看出。

五、V1.0版

这是一个大版本，对数据生成，结构组织等进行了重大更新，使用V1.0版本生产了台北、台中、桃园、香港等地区成果数据。版本更新主要有以下几个方面：

1.支持ContextCapture目录结构格式生成

之前生成的格式与3dtiles瓦片格式保存一致，能够基于osgViewer进行正常加载和显示，在目前ContextCapture是当前倾斜摄影生产标杆的情况下，其生成的目录组织结构成为了用户使用的默认方式，很多osgb转obj/fbx/3dtiles等格式的开源工具或商业软件，都是参考ContextCapture生产的osgb成果数据目录格式进行处理，很多读者都有共同的使用转换需求；戏剧性的是，就在2024年9月6日，ContextCapture的研发公司Bentley Systems收购了Cesium，如果说Bentley提供了数字孪生的数据生产处理解决方案，那收购Cesium，则整合了数字孪生的数据发布与可视化解决方案，解决方案链条进一步加强。

2.显示效率优化提升

谷歌倾斜摄影OSGB转换工具中针对RangeMode率先采用DISTANCE_FROM_EYE_POINT模式，并非大家常用的PIXEL_SIZE_ON_SCREEN模式。采用此模式，判断相机到瓦片中心点的距离进行瓦片切换，而不是按照瓦片所占的屏幕像素大小切换，这样更合理，同时和3dtiles保持一致，也和谷歌官方倾斜摄影保持一致，在效果和性能上保持三者一致性。另外在这次更新中，去除了纹理摩尔纹效果，在效果表达上更加清晰，纹理摩尔纹是由纹理贴图过采样形成的摩尔纹闪烁，对三维实景影响比较大，使用多重纹理，根据相机距离加载不同层级的纹理图片，解决纹理过采样的问题。

3.生产效率再提升

针对数据生产效率进行了优化，提升20%左右。

4.增加成果数据质检流程

之前版本中，数据是没有进行质检的，受限于按范围采集规则，会导致存在部分节点子节点丢失的情况，但是当前节点又记录了子节点PagedLOD信息，虽然在浏览上没有太大影响，但是使用osgViewer会频繁有警告信息，更重要的是使用这份osgb数据转成obj/fbx/3dtiles会导致失败，因此增加质检校验环节，保证数据更加符合标准，增强数据结构健壮性，兼容市场主流OSGB转换处理工具。

六、V1.1版

V1.1版本主要解决了使用OSGB软件生成3DTiles、DOM和DSM数据的问题。并使用此版本生成了桃园、台中等地区数据。支持Cesiumlab等软件将OSGB数据转成3DTiles格式数据，并且能够输出DOM和DSM数据。很多读者使用OSGB数据，并非是直接加载到OsgEarth上做可视化用，而是将OSGB转成3dtiles格式，这样数据就能够在Cesium上使用。大家使用Cesiumlab或其他OSGB处理软件，基本上都是参考Cesium3DTilesConverter或3DTiles这两款开源的转换工具，我在研发时参考了这两款开源工具代码，针对转换工具进行测试与验证，解决了OSGB数据转换生产3DTils异常的问题。

七、V1.2版

V1.2版本解决了数据加载到OsgEarth上与影像存在的偏移问题，也就是影像与数据匹配不上。OSGB数据以米为单位，而且精度很高，谷歌倾斜摄影数据分辨率能达到5cm，相比目前卫星影像0.3米高分辨率还要高6倍。如何将高分辨率OSGB数据完美、精准匹配叠加在OSGEarth上，使用WGS84或者3857等常用投影或地理坐标系，误差较大，具体表现是OSGB数据与卫星影像数据不匹配。

上图OSGB数据是采用Web Mercator(EPGS:3857)进行生产的，导出DOM数据叠加卫星影像底图进行对比可以看出:OSGB数据中道路和房屋等和卫星影像底图数据没有匹配上，偏差在20米左右，无法满足实际使用要求。在V1.2版本中，通过几十次不断测试与验证，彻底解决了数据偏移问题，针对这个问题，并非偏移原点坐标就能解决，而是在数据生产时，对数据进行逐顶点处理转换，再进行优化合并。经过正确处理后的效果如下图所示：

以上是这款软件的更新迭代总结，可以看出，从V0.1-V1.2,解决了OSGB数据生成，兼容ContextCapture、大势智慧等软件加载，生成OSGB数据转换生成3DTiles、DOM/DSM数据，并且解决加载到地图上存在偏移等重大问题。

下面我们重点说明此次更新的V2.0版本：

一、更新背景：

在目前向大家免费分享的数据中，不知道大家有没有发现，分享的数据中都存在着一个很大的问题，分享的数据中既有倾斜摄影数据，又有影像数据，这个问题很多用户向我提出过，但是由于还有其他更急迫的问题未解决，加上我初步分析了这个问题，难度太大，所以这个问题的的解决日期一直在往后延，在数据生产3DTiles、数据偏移等重大问题解决后，才开始下定决心来解决这个问题，最开始我考虑的是使用四至范围，也就是矩形范围进行裁剪，主要有以下几个问题：

1.影响数据浏览体验，因为数据浏览逐级放大时，影像部分逐渐减小，越放大非倾斜摄影部分就消失了，与倾斜摄影和普通卫星影像的浏览体验大不一样。

2.用户在加载倾斜摄影数据前一般提前先加载好底图，有些底图是矢量瓦片或者栅格矢量瓦片，如果非倾斜摄影区域，也就是卫星影像覆盖太大，这样会遮盖底图，导致矢量瓦片上的信息就无法展示出来，影响了用户对底图信息的获取。

3.最重要的一点，数据中倾斜摄影没有水印，而影像部分有google的水印，部分用户在意这点。

解决这几个问题，中间还走过一段弯路，因为用户说保证每层级面积一样就行，于是在V1.2版本中，我的确保证了每一层级面积一样大，逐级放大时没有数据消失的现象，但是引来了更大的问题，因为影像数据覆盖部分面积更大了；因此最根本的解决方案是完全裁剪掉数据中影像数据部分，这样不管如何浏览，都只有倾斜摄影数据。解决方案有了，但是技术方案不好抉择。

二、技术路线

针对这个问题，我做了相关预研，主要如下：

1.目前大大小小的关于OSGB处理的软件，比如大势智慧、ContextCapture、OSGBLab等，都有模型裁剪的功能，模型裁剪功能一般使用开源工具CGAL(Computational Geometry Algorithms Library，计算几何算法库)来进行裁剪，CGAL是一个开源的计算几何库，提供了一系列高效、可靠的几何算法和数据结构。它由瑞士的计算几何学研究人员开发，旨在支持计算几何相关的应用程序，如图形学、计算机辅助设计（CAD）、机器人学等。CGAL具有几何数据结构、几何算法、三角网格处理、计算几何基础、3D几何处理等主要功能，提供Kernel、Convex Hull、Voronoi Diagram、Triangulation、Polygon、Surface Mesh、Nef等核心模块。其算法经过优化和广泛测试与验证，支持大规模数据集的处理，保证了各种应用场景中的可靠性。刚开始我也打算用CGAL库对模型进行裁剪，但是预研后发现，CGAL进行裁剪比较复杂，不一定能满足数据转换要求，使用风险较大，因此这条技术路线预研后被搁置。

2.自研算法裁剪。经过大量分析，发现模型Mesh裁剪，其实只要解决瓦片内Mesh按范围裁剪，难题就会迎刃而解，因此，我研究Mesh内裁剪的技术路线，最终分解到三角面片裁剪，将问题大事化小，而三角面片按Polygon裁剪复杂度大大降低，因此，我自研算法，总共调试了不下20个版本，终于生成了一个快速、稳定且数据效果优秀的版本。
我使用了台湾省桃园市某一块区域进行的测试，当数据逐级放大时，其数据面一直未变，而且几乎所有区域都是倾斜摄影数据，这就是用户想要的那种效果。V2.0版发布后，这个软件已经比较完善，下一步将会针对生产速度以及数据性能进行调优，为将来生产谷歌地球倾斜摄影全球数据做准备。

三、样例数据领取

目前使用V2.0版生产了台湾地区台北、台中以及桃园这三个地区的成果数据，后期会将免费数据都会更新到V2.0版，让大家及时享用软件更新带来的数据新体验与新效果。本次将上面录屏使用的桃园样例数据免费分享给大家，领取方式还是老方法，大家在评论区留言或者私信，我会将领取方式发送给大家。在这里首先感谢私信我向我反馈数据使用问题以及给我提供使用需求和建议的读者，正是因为你们，才有了这款软件工具的不断更新迭代。同时也欢迎大家积极领取样例数据，针对数据中存在的问题可以私信我，我会及时回复大家的消息，并针对数据中存在的问题及时修复，对软件版本进行及时更新迭代；最后如果读者有谷歌地球倾斜摄影OSGB数据的使用需求，欢迎随时私信沟通。