CN110287508A - 一种多源三维城市模型的可视化融合系统 - Google Patents

Abstract

本发明公开了城市数字化系统技术领域的一种一种多源三维城市模型的可视化融合系统，包括HBase分布式数据库，处理单元，融合单元，检索/索引单元，Web浏览器和用户端，将标准化的CityGML三维城市模型，OSM数据以及Collada三维建筑模型整合起来，用HBase分布式数据库对其进行存储和管理，并为其设计了全新的row key便于快速地检索和索引，同时利用MapReduce并行计算框架和Hadoop平台实现了针对城市模型中建筑物的综合简化算法，最终将多源数据集成融合在浏览器中可视化，实验结果显示为HBase设计的row key在检索时较大的提升了检索效率，提出的综合简化算法也能有效降低三维城市模型的复杂度，同时不会过多的削弱其视觉效果，生成的简化模型可以用于用户端的可视化应用。

Description

一种多源三维城市模型的可视化融合系统

技术领域

本发明涉及城市数字化系统技术领域，具体为一种多源三维城市模型的可视化融合系统。

背景技术

在人类社会中，城市占据着重要的地位。2015年底中央城市工作会议指出:“要加强城市管理数字化平台建设和功能整合，建设综合性城市管理数据库，发展民生服务智慧应用。”为此，需要建立并完善城市数字化基础设施，其中城市三维模型作为城市数字化基础设施中重要的组成部分有着广泛的应用，比如城市规划，环境监控，空间信息分析等。在这些不同的应用需求中，城市三维模型可以作为底图，承载上层应用，展示领域数据，比如地理信息，道路交通，人口分布，空气环境质量等都可以整合到三维城市模型中。目前，许多城市创建了官方的三维模型。比如德国柏林在2009年3月发布出了它们的三维城市模型，它包含474000个带有纹理的建筑模型，分布在857平方公里地域范围中。然而，随着三维城市模型数量和种类爆炸式的增长，如何有效地存储和管理好海量、多源、结构复杂的三维模型并对其高效地分析处理以便为上层不同领域应用提供数据支撑，是目前亟待解决的问题。

大数据作为近年来高速发展的新技术，已经在互联网，人工智能等领域取得了令人瞩目的成果，并逐步渗透到了各个行业。在当前的三维城市模型研究工作中，各种复杂类型数据的采集、挖掘、处理、分析与应用都与信息社会的“大数据”不谋而合。传统上，三维模型数据往往是存储于文件(CityGML或Collada)或者对象关系型数据库 (Oraclespatial，PostGIS或3DCityDB)中，但关系型数据库在海量数据的管理中面临许多问题，包括高并发读写、难扩展等。要想解决上述难题与挑战，离不开现代“大数据”处理的新技术和新理念。

索引和检索技术是实现有效的数据存储与管理的关键技术。2002 年，之前有提出一种管理三维模型数据的方法，使用文字语义来影射三维模型数据。用户可以通过输入一个词或者一句话来搜索三维模型数据或三维模型场景，也因此实现了Wordseye软件。在根据形状检索三维模型的研究中，具有较大影响力的有美国普林斯顿大学提供的三维形状搜索引擎(3DModelSearchEngine)和台湾大学提供的三维形状检索系统(3DModelRetrievalSystem)等。针对CityGML开源三维城市模型数据，Felix在对象关系型数据库3DCityDB中实现了CityGML 三维模型的数据管理。然而，以CityGML为存储格式的三维模型是十分复杂的，它能在数据库中产生上百张表，随之带来的缺点是通用性很差，数据库中大部分的表不能被其他应用所使用。但是，上述当前的三维城市模型管理框架不易被实现，在面对海量数据时无法保证检索的时效性，也难以用云计算与NoSQL数据库技术扩展实现并行化。

为了减少模型的存储空间，进而提升网络传输速度与模型渲染效率，已经有不少研究提出了针对三维模型的综合简化算法。Kada基于半空间(half-space)将建筑模型表示为另一种新的形式，以消除“小”建筑部件。基于最小二乘法，Thiemann和Sester提出了适合于特定基于footprint或简单外壳建筑的适应性3D模板。Kada也提出了一种类似的方法来将建筑模型划分为多个单元格，然后使用单元格分解技术来综合模型。然而，这些方法没有考虑与建筑物的几何对象相关联的语义信息，这很可能会削弱最终的可视化效果。此外，很多研究着眼于通过挤压三维建筑的地面覆盖物(footprint)来构造三维形状，或者着眼于简化二维方法，比如删除或者修改边。但是，这些方法对于那些具有单个垂直面(墙)的三维建筑的应用没有太大帮助，并且也不适用于许多真实的建筑形状。Mao等提出了一种基于块分割和三维建筑聚合的三维模型多重表示结构，称之为CityTree，此方法满足了高密度建筑的可视化要求。然而，该方法改变了三维坐标的边界和位置导致其不能满足保持三维空间精确体积的要求。

基于此，本发明设计了一种多源三维城市模型的可视化融合系统，将数据存入HBase中以方便管理，并为其设计了全新的row key便于快速地检索和索引；然后分析模型数据的语义和几何特点，提出了一种模型综合简化算法，实现了Hadoop环境下对三维城市模型快速并发简化处理，从而在保留视觉效果的情况下减少了模型的复杂度，进而增加了网络传输速度和模型渲染效率；最后借助Cesium平台，实现了多源三维城市模型的融合可视化以解决上述问题。

发明内容

本发明的目的在于提供一种多源三维城市模型的可视化融合系统，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：一种多源三维城市模型的可视化融合系统，包括

HBase分布式数据库，用于存入准化的CityGML三维城市模型， OSM数据以及Collada三维建筑模型，将其进行整合、存储和管理；

处理单元，用于简化、过滤和提取三维建筑对象；

融合单元，用于将处理后的简化模型进行集成融合；

检索/索引单元，用于对空间位置矢量数据的检索和索引，并迅速定位需要返回的结果；

Web浏览器，用于将融合后的三维模型进行可视化；

用户端，通过Web浏览器对可视化的三维模型进行浏览，并进行反馈。

优选的，所述存入方式采用base64转码的方式。

优选的，所述CityGML三维城市模型，基于XML格式的开源数据模型，包括用于描述单个城市种各种不同实体的cityObjectMember元素和包含各种不同实体外观信息的appearanceMember元素；

所述OSM数据，包括道路元素配合Bing地图服务形成的二维底图；

所述Collada三维建筑模型，用于模型交换，包括KML，用于可视化地理数据的文件格式。

优选的，所述HBase分布式数据库还包括ZooKeeper和YARN，用于管理、调度集群各项资源与进程的互相协同工作，MapReduce，并行计算框架用于保障大量数据的并发快速处理，Hadoop Streaming，指导顶层应用的运行。

优选的，所述处理单元包括

简化模块，采用LoD3细节层次的三维建筑作为输入数据来简化模型；

过滤模块，用于过滤建筑物墙上的门或者窗户信息；

提取模块，用于提取建筑物的墙面和屋顶表面信息。

优选的，所述处理单元还包括修补模块，用于修补门或者窗户产生的空洞。

优选的，所述检索/索引单元采用Geohash算法，Geohash算法将经纬度转化成一维的字符串，将这一维的字符串作为HBase分布式数据库的row key索引。

优选的，所述融合单元采用Cesium融合平台，包括3D Tiles，3D Tiles用于以数据流的形式展示三维内容，包括建筑物，树木，点云和矢量数据。

优选的，所述Cesium融合平台与CityGML三维城市模型和Collada 三维建筑模型数据只支持glTF格式，与OSM数据只支持Geojson格式。

与现有技术相比，本发明的有益效果是：本发明从数据存储与管理，数据分析处理与三维模型综合简化，到多源数据融合可视化的多源三维城市模型数据处理框架，将标准化的CityGML三维城市模型， OSM数据以及Collada三维建筑模型整合起来，用HBase分布式数据库对其进行存储和管理，并为其设计了全新的row key便于快速地检索和索引，同时利用MapReduce并行计算框架和Hadoop平台实现了针对城市模型中建筑物的综合简化算法，最终将多源数据集成融合在浏览器中可视化，实验结果显示为HBase设计的row key在检索时较大的提升了检索效率，提出的综合简化算法也能有效降低三维城市模型的复杂度，同时不会过多的削弱其视觉效果，生成的简化模型可以用于用户端的可视化应用。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明结构示意图；

图2为本发明多源三维城市数据设计的表图；

图3为本发明建筑物简化前后可视化效果对比图；

图4为本发明屋顶简化前后可视化效果对比图；

图5为本发明墙体简化前后可视化效果对比图；

图6为本发明不同数目节点上的检索时间性能比较表图；

图7为本发明传统数据库与HBase集群之间的检索时间性能比较表图；

图8为本发明测试模型简化前后可视化效果对比图；

图9为本发明测试模型的统计信息表图；

图10为本发明整体压缩前后可视化效果对比图；

图11为本发明多源三维城市数据融合后的三维可视化结果图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1，本发明提供一种技术方案：一种多源三维城市模型的可视化融合系统，包括

HBase分布式数据库，用于存入准化的CityGML三维城市模型，OSM 数据以及Collada三维建筑模型，将其进行整合、存储和管理，存入方式采用base64转码的方式，CityGML三维城市模型，基于XML格式的开源数据模型，包括用于描述单个城市种各种不同实体的 cityObjectMember元素，比如建筑、道路、植被和水体等，和包含各种不同实体外观信息的appearanceMember元素，如颜色和纹理，所述 OSM数据，包括道路元素配合Bing地图服务形成的二维底图，所述 Collada三维建筑模型，用于模型交换，包括KML，用于可视化地理数据的文件格式，功能性庞大，兼容性好；

HBase分布式数据库还包括ZooKeeper和YARN，用于管理、调度集群各项资源与进程的互相协同工作，MapReduce，并行计算框架用于保障大量数据的并发快速处理，HadoopStreaming，指导顶层应用的运行。

处理单元，用于简化、过滤和提取三维建筑对象，所述处理单元包括简化模块，采用LoD3细节层次的三维建筑作为输入数据来简化模型，能够删除一些对于视觉效果有重要影响的几何特征，将属于不同实体的几何面合并到一起，过滤模块，用于过滤建筑物墙上的门或者窗户信息，门和窗户在CityGML LoD3中有它们自己对应的属性和几何描述，诸如墙和屋顶之类的对象包含了关于它们厚度的几何信息。一般情况下，每一个建筑物包含屋顶、墙壁、镶嵌于墙上的门或者窗户，以及其他的一些细节。对于整个建筑物来说，不是特别关心它的细节对象，比如Opening(门或窗户)和BuildingInstallation，可以把这些细节对象过滤掉，由于提取模块，用于提取建筑物的墙面和屋顶表面信息，提取方法具体如下：

在CityGML中，墙与墙之间是单独分开存放的，每一个墙体对象 (WallSurface)通常是一个至少由6个面组成的立方体。所以，建筑物的每一面墙都能由一个空间点集P＝{p1,p2,…,pk}来表示，首先计算它的质心Wi＝[Wx,Wy,Wz]，其中Wt＝(∑p_j)/k,t＝x,y,z。然后该面墙所在的平面α_i能通过下面的公式(1)被计算出来。计算了墙上每一个面的面积，把面积最大的面作为α_i，因为一般来说面积更小的面是作为一面墙的侧面而存在。

α_i:A_ix+B_iy+C_iz+D_i＝0

(1)

其中ni＝[Ai,Bi,Ci]是平面α_i的法向量，Di＝-(AiXpk+BiYpk+ CiZpk)。

在此之后，通过取所有墙体质心点的平均值就能很容易的得到整个建筑物的中心点W＝[Xw,Yw,Zw]。

对于在同一墙上的每一个面，将属于这个面的所有顶点都输入到公式(1)中可以得到一个平面β_i，然后根据公式(2)可以计算出平面α_i与平面β_j之间的夹角θ_ij：

如果夹角θ_ij趋近于0°或180°，那么这两个平面要么共面要么平行。因此，平面β_j所对应于墙上的面应该要保留下来。但是如果夹角趋近于90°或其他角度，那么对应于墙上的面需要被删除。现在，所有属于同一面墙上剩余的面应该是要么共面要么平行。接下来，从建筑物的中心点W处向任一墙发射一条射线，距离W最长的面即为此面墙的外壳面。计算距离的公式如下所示：

剩余的墙体对象重复上述步骤以获得它们的外壳面。

此时，已经提取到了所有墙体的外壳面，但是在许多大型的建筑中由于墙体在垂直方向上的不均匀性，正如图3(a)所示的那样墙体拥有多个外表面。墙A和墙B因为公用面c而具有邻接关系。上述的获取外表面的过程只能得到面a和面b。换句话说，正如图3(b)显示的那样在面a和面b之间存在一个间隙，导致三维实体不闭合，这不是想要的效果。所以，在提取外表面时需要修补这一间隙。遍历所有的外部面，如果外部面fi的最低点仍然高于外部面fj的最高点，这就表明在建筑物中至少存在两个垂直墙，然后再判断他们(fi和fj)是否在同一侧。否则，在建筑物的一侧只有一个垂直墙。如果fi和fj在同一侧，将自动修补他们之间的间隙，如图3(c)所示。

在CityGML中建筑物的屋顶有两种情况：(1)整个屋顶由多个 RoofSurface对象表示；(2)整个屋顶只由一个RoofSurface对象表示。

在第一种情况中，提取屋顶外壳面的方法和提取墙体的差不多，但略微有些不同。为了确保建筑物的紧密性，避免在墙和屋顶之间产生间隙，选取建筑物的中心点W到屋顶面距离最小的面作为屋顶的外壳面。第二种情况则相对复杂一些，采用Fan的方法来解决这个问题。从图4(a)中可以看到一个简单的带有厚度的屋顶对象，图4(b)则展示了正确提取外壳面后的结果。

还包括修补模块，用于修补门或者窗户产生的空洞；

墙体会包含门或窗户，而在CityGML LoD3的数据组织结构中，门或窗户是存在于Opening对象中。由于过滤掉了他们，导致在墙体上会出现三维孔洞，为了能使建筑物成为一个完全封闭的整体，必须要处理这些孔洞。

以门产生的三维孔洞为例，具体描述修补门所带来的孔洞的方法。墙体对象的外壳面已经能被提取到，同时三维孔洞也变成了二维孔洞。为了修补它们，列出属于每一个外壳面的最高点的坐标，从中挑选出一个最小值作为上界。同理，以最低点作为下界。接下来，遍历每一个外壳面并删除在上界和下界当中的点，这样通过删除一些不必要的点就能填补墙体面上包含的孔洞，如图5所示。

检索/索引单元，用于对空间位置矢量数据的检索和索引，并迅速定位需要返回的结果，采用Geohash算法，Geohash算法将经纬度转化成一维的字符串，将这一维的字符串作为HBase分布式数据库的row key索引，大大提高了模型的检索效率，如图2；

融合单元，用于将处理后的简化模型进行集成融合，采用Cesium 融合平台，包括3D Tiles，3D Tiles用于以数据流的形式展示三维内容，包括建筑物，树木，点云和矢量数据；

3D Tiles具有如下特性：

(1)交互性：3D Tiles支持交互性的选择和样式改变。3D Tiles 允许单个模型交互，比如在鼠标悬停时高亮，或者删除一个3D建筑物。瓦片可以为每个模型包含元数据，这样就可以允许额外的交互，比如利用一个建筑物ID查询第三方服务。

(2)多样性：单个模型的元数据，如建筑物高度、建造时间，可以在运行时用来当做渲染参数而无需写代码。风格(如颜色)可以动态改变。

(3)自适应性：3D Tiles能够自适应于3D的空间分割，包括k-d 树，四叉树，八叉树，网格和其他空间数据结构。转换工具可以自适应的分割一个数据集，代替了死板的空间分割。

(4)灵活性：支持替代性细化和添加式细化两种LoD策略，主要以添加式细化为主。添加式细化是指，当视角拉近时，3D Tiles只是会添加进来新的三维建筑物，而不是将相同的建筑物下载多次。

所述Cesium融合平台与CityGML三维城市模型和Collada三维建筑模型数据只支持glTF格式，与OSM数据只支持Geojson格式。

Web浏览器，用于将融合后的三维模型进行可视化；

用户端，通过Web浏览器对可视化的三维模型进行浏览，并进行反馈。

本实施例的一个具体应用为：在一个安装有Linux Ubuntu 14.04的高性能服务器(Intel Xeon E7-4807 1.87GHz CPU)上用KVM虚拟化技术，虚拟出6个节点，并在其上实现了Hadoop完全分布式集群的搭建与测试。此外，利用依赖于HDFS的HBase分布式数据库存储多源三维城市数据；并用ZooKeeper和YARN管理、调度集群各项资源与进程的互相协同工作；用MapReduce并行计算框架保障大量数据的并发快速处理；用Hadoop Streaming指导顶层应用的运行。

索引和检索技术是实现有效的数据存储与管理的关键技术。为了测试上述中基于HBase的海量三维城市模型存储与管理系统的检索性能，分别在不同的搭载有HBase的Hadoop集群节点上，从50万，200 万，500万和800万规模的三维城市模型中进行性能检索测试。正如图 6所看到的那样，检索同一目标区域的时间随着节点数目的增加而下降了。当节点数增加到6个时，它所花费的检索时间几乎只是2个节点所花时间的一半。与此同时，上述也比较了传统的对象关系型数据库 (3DCityDB)和带有4个节点的HBase之间的检索时间，它们都是在50万个三维建筑模型中检索同一片目标区域，如图7展示了最终的结果。

用于三维模型综合简化的CityGML LoD3测试模型数据在实验中，门和窗户对象基于语义信息首先被过滤掉(如图8的第二列)；然后在不改变三维模型的位置或者替换其边界的条件下，提取墙体和屋顶的外壳面；最后，在墙体或屋顶之间/之上的孔洞和间隙会被修补，以生成一个紧密闭合的三维实体(如图8的第三列)。此外，考虑到数据存储容量的要求，对比了应用综合简化算法前后三维模型的数据量，图9分别列出了三个CityGML测试模型(即图8中的(a)，(b)， (c))的统计信息。

在数据压缩量方面，采用上述所提出的综合简化算法在小镇数据集上做了测试(总共185个LoD3模型)，图10为压缩前后的可视化效果，并以x3d数据格式保存压缩后的模型。实验结果显示，总量为 31.1MB的CityGML原模型数据，经简化算法压缩后数据总量仅为541.4KB，整体压缩率达到了98.3％，却并没有破坏整体的外观和精度。

上述所提出的综合简化算法适用于包含语义信息的LoD3或LoD2 三维建筑模型，能较好地降低三维模型的细节层次以及极大地减少模型的数据量。

整套系统具有较强的稳定性。图11展示了多源三维城市数据融合后的三维可视化结果，其中包含绿色的道路、黄色和橙色的电缆线，带有纹理的三维建筑等。

在本说明书的描述中，参考术语“一个实施例”、“示例”、“具体示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

以上公开的本发明优选实施例只是用于帮助阐述本发明。优选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。

Claims (9)

1.一种多源三维城市模型的可视化融合系统，其特征在于：包括

HBase分布式数据库，用于存入准化的CityGML三维城市模型，OSM数据以及Collada三维建筑模型，将其进行整合、存储和管理；

处理单元，用于简化、过滤和提取三维建筑对象；

融合单元，用于将处理后的简化模型进行集成融合；

检索/索引单元，用于对空间位置矢量数据的检索和索引，并迅速定位需要返回的结果；

Web浏览器，用于将融合后的三维模型进行可视化；

用户端，通过Web浏览器对可视化的三维模型进行浏览，并进行反馈。

2.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述存入方式采用base64转码的方式。

3.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述CityGML三维城市模型，基于XML格式的开源数据模型，包括用于描述单个城市种各种不同实体的cityObjectMember元素和包含各种不同实体外观信息的appearanceMember元素；

所述OSM数据，包括道路元素配合Bing地图服务形成的二维底图；

所述Collada三维建筑模型，用于模型交换，包括KML，用于可视化地理数据的文件格式。

4.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述HBase分布式数据库还包括ZooKeeper和YARN，用于管理、调度集群各项资源与进程的互相协同工作，MapReduce，并行计算框架用于保障大量数据的并发快速处理，HadoopStreaming，指导顶层应用的运行。

5.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述处理单元包括

简化模块，采用LoD3细节层次的三维建筑作为输入数据来简化模型；

过滤模块，用于过滤建筑物墙上的门或者窗户信息；

提取模块，用于提取建筑物的墙面和屋顶表面信息。

6.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述处理单元还包括修补模块，用于修补门或者窗户产生的空洞。

7.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述检索/索引单元采用Geohash算法，Geohash算法将经纬度转化成一维的字符串，将这一维的字符串作为HBase分布式数据库的row key索引。

8.根据权利要求1所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述融合单元采用Cesium融合平台，包括3D Tiles，3D Tiles用于以数据流的形式展示三维内容，包括建筑物，树木，点云和矢量数据。

9.根据权利要求8所述的一种多源三维城市模型的可视化融合系统，其特征在于：所述Cesium融合平台与CityGML三维城市模型和Collada三维建筑模型数据只支持glTF格式，与OSM数据只支持Geojson格式。