随着计算机技术和网络技术的发展，建筑信息模型（building information modeling，BIM）与地理信息系统（geographical information system，GIS）在Web端的集成已成为各界关注的技术重点^[1]. 从两者所含信息来看，GIS侧重大尺度宏观环境，BIM侧重建筑内部微观信息，两者存在互补关系^[2]；将GIS和BIM结合，是推进学科交叉，实现智慧城市建设的理想思路^[3-4]. 李德超等^[5]从数据组织、应用模型等方面探讨了BIM技术在数字城市三维建模中的应用. 汤圣君等^[6]提出了工业基础类（industrial foundation classes，IFC）几何要素过滤方法以及从IFC到CityGML的语义映射规则. 以上研究实现了初步集成，但停留在软件互操作层面. WebGL可视化等技术的应用，为两者在Web端集成奠定了基础^[7]. 集成的根本是数据信息的共享. 王珩玮等^[8]研究了基于WebGL框架Three.js的BIM模型显示技术. 乐世华等^[9]采用Java Script和WebGL，运用缓存加载、切片技术实现地形与影像的Web端集成加载. 这些研究实现了Web端BIM模型的展示，但受限于网络带宽和服务器性能，计算机处理海量三维数据时会出现加载时间过长、系统崩溃等问题. 众多学者就此问题从模型轻量化的角度进行了研究. 高喆等^[10]通过基于构件的几何复用算法对BIM模型进行轻量化处理，大幅减小了三维模型的大小. 但模型的轻量化程度有限，无法从根本上解决海量三维数据在Web端的加载问题.

在三维WebGIS的发展过程中，以WebGL为绘制三维模型标准的三维瓦片数据格式在近几年得到广泛应用，如Cesium所使用的3D Tiles^[11]. 该数据由瓦片集数据（Tileset.json）和瓦片数据（tile）组成^[12]. 其中包含多种瓦片数据格式，针对三维模型的数据格式为批量3D模型（batched 3D model，b3dm）. b3dm瓦片主要应用于包含信息的三维建筑模型、带有纹理材质的地形表面及大批量模型，适合作为BIM数据转换的目标格式. 该格式在设计初便以WebGL渲染机制为基础，面向海量三维数据的快速加载，因此其内部结构更加符合基于WebGL的模型快速加载. 但在数据格式方面，3D Tiles与IFC在模型几何表达、语义信息、展示范围、LOD层级和坐标系统方面均存在明显差异，增加了数据交互的难度^[13]. 本文针对目前BIM与GIS集成方案网络传输与浏览器渲染能力的不足，转变传统模型轻量化的处理思路，对BIM模型从IFC通用标准向3D Tiles数据格式进行转化，提出一种在Web端快速加载BIM模型的思路，并为GIS和BIM在Web端的大体量数据集成提供可行方案.

以某高层居民楼BIM模型为例进行研究，从Revit中导出IFC标准文件，分析BIM文件与3D Tiles文件的映射关系，把IFC整体模型分解为包含语义属性的JSON文件和多个包含几何信息的模型构件并与3D Tiles建立数据映射，再将IFC模型所包含的属性信息传递到3D Tiles. IFC文件需转化为OBJ格式，再转化为glTF（GL transmission format），在此过程中完成坐标转换、空间索引和LOD层级划分，最终将glTF文件和包含属性信息的JSON（JavaScript object notation）文件封装之后得到瓦片数据b3dm文件. 将所得文件添加瓦片集文件得到3D Tiles文件，借助Cesium框架和Node.js实现WebGL平台的数据展示，研究方法如图1所示.

由于无法直接从IFC格式转化得到3D Tiles数据，需要先将IFC格式文件转化为OBJ文件，再转化为glTF文件. 为保证格式转化后的模型属性完整且符合实际建筑中构件的构成情况，需在设定模型拆分规则的基础上对模型进行拆分. 模型拆分规则参考实际建筑构件的构成，结构专业部分拆分为结构柱、类型梁（如过梁、连梁、圈梁等）、结构楼板、剪力墙、集水坑、桩、承台、地梁、条形基础、挑檐、台阶、饰条（如踢脚、墙裙等装饰性构件）；建筑专业部分拆分为建筑柱、构造柱、墙（如建筑内隔墙、幕墙）、楼梯栏杆、坡道、门、窗、楼板建筑面层、吊顶、装饰性构件. 在具体转化过程中，对IFC文件内所有对象进行遍历，将包含几何信息的对象按照以上模型拆分原则拆分成单个较小的IFC文件导出，同时以JSON文件保留对象的语义属性信息. b3dm数据中内嵌了二进制的glTF（glb），最终由b3dm数据和Tileset.json文件共同组成3D Tiles数据，转化过程如图2所示.

1）从IFC到OBJ.

IFC和OBJ作为2种常见的数据格式，已经有开源的格式转换工具供使用. 如前所述，IFC包含三维模型和大量建筑领域的语义信息；而OBJ文件只包含三维模型的几何信息和材质，是三维建筑模型良好的转换媒介. 如果直接将IFC文件按照已有方法转化为OBJ文件，会导致与建筑相关的属性无法保留. 因此转化之前，需要将IFC文件按拆分规则进行拆分，得到多个IFC文件和对应的属性信息.

在IFC文件中，空间结构通过IfcRelAggregates进行定义. 模型构件通过局部定位的方式进行位置定义. 每个建筑构件都有基于本身的独立坐标体系（IfcLocalPlacement），属性PlacementRelto对应上一级坐标系，属性RelativePlacement对应相对位置信息，再通过坐标体系的多重引用，将建筑构件的坐标系嵌套在多个IfcLocalPlacement下，最终确定其在整个项目的全局坐标系中的位置. 通过多个IfcLocalPlacement对象的嵌套引用，获得构件所在的局部坐标系在全局坐标系中的相对位置（局部坐标系原点、坐标轴在全局坐标中的定位）.

BIMserver是基于BIM的服务器管理平台. 将IFC文件上传到BIMserver服务器，通过IFCEngine对模型进行拆分，获得构件模型（IFC文件）和构件相关属性（JSON文件）. 至此，原始IFC文件转化为按构件划分的IFC文件和包含构件属性的JSON文件. 在提取构件的过程中，需遍历IFC文件，获取构件所在的局部坐标系在整个模型坐标系中的几何定位、形状表达和相关的材料属性，以JSON文件进行存储.

IfcOpenShell是针对IFC文件提供的开源（LGPL）软件库，提供了IFC文件解析的预定义函数库和IFC数据到OBJ数据的转换框架. 针对以上获得的IFC文件，应用IFCOpenShell库中提供的IfcConvert将其转化为OBJ文件.

2）从OBJ到glTF.

glTF是为了方便三维模型的网络传输而设计的三维模型文件格式^[12]，其数据结构如图3所示. JSON文件是对整个文件结构的记录，包含节点层级、材质、相机等逻辑结构，bin文件记录具体数据信息，包含顶点、外法向量、纹理坐标；GLSL文件包含模型渲染过程中的着色器信息.

前述步骤得到的文件即模型切片后的子瓦片，将对应的网格和材质数据写入glTF文件. 在格式转换过程中，需要确定纹理坐标和顶点坐标的对应关系，通过对纹理设置坐标来将纹理映射到三维多边形表面. 由于子瓦片之间相互不连续，对文件添加顶点属性（attribute）batchid，以彼此区分. 最终得到的文件中，各个建筑物由网格组成，相同建筑构件具有相同的标识符，网格存储在网格数组（meshes）中，网格中包含图元（primitives）数组，图元中包含变量属性（attribute），该属性中又包含定点位置POSITION、顶点法向量NORMAL、顶点纹理坐标TEXCOORD_0、网格标识符_BATCHID.

3）从glTF到b3dm.

glTF文件转换成二进制glTF（glb），作为文件体的一部分，与文件头、特征表（Feature Table）和批次表（Batch Table）共同组成瓦片数据b3dm文件. 批次表中存储与模型相关的用户自定义数据，这些数据用于和用户进行交互，例如填充UI或发出REST API请求，不影响模型的渲染展示.

考虑到实际建筑物中虽然构件数量庞大，但建筑物中每一楼层相同位置的墙、门、窗都是相同的建筑构件，很大一部分属于相同构件的不断重复. 在文件头（header）中，每个构件都被分配一个batchid，所有ID组成一个区间. ID相同的顶点属于同一个构件，存储在文件体（body）的批次表（batch Table）中的属性信息也通过batchid进行调用^[12]，其数据结构如图4所示.

b3dm与瓦片集数据共同组成三维瓦片. 瓦片集文件中包含瓦片元数据，用来组织三维瓦片的空间结构^[12]，其数据结构如图5所示. 空间包围盒（bounding volume）是一个数组，表示当前瓦片数据的空间范围，所有子节点的瓦片数据包含在父节点瓦片数据的包围盒中，以体现瓦片数据结构的空间层次性. 包围盒可以是长方体（box）、球体（sphere）和经纬度与高度共同定义的区域（region），以适应不同数据的切片需求. 几何误差（geometric error）用来在LOD划分中决定当前视角下所应加载的层级. 精细化（refine）表示瓦片数据加载的精细化方式，支持ADD和REPLACE两种. 内容（content）通过链接（uniform resource identifier，uri）指定加载的瓦片数据.

4）坐标转换.

IFC模型中的构件模型的坐标系是局部坐标系，而3D Tiles展示数据的坐标系是世界坐标系，因此IFC到GIS的几何信息转换包括对坐标系的变换. Cesium框架所使用的三维数字地球对应的是全局笛卡尔坐标系统，地心位于坐标原点^[2]. 在具体展示模型的过程中，模型自身所在的坐标系是局部笛卡尔坐标系统. 一般坐标原点在椭球体表面，对应高程为0. 两坐标系之间的转换矩阵 ${{T}_{\rm{t}}}$ 的计算方法如下：

(1) ${{T}_{\rm{t}}} = {{R}_{{x}}}{{R}_{{y}}}{{R}_{{z}}}{{T}}.$

式中：

(2) $ {{{R}}_{{x}}} = \left[ {\begin{array}{*{20}{c}} 1&0&0&0 \\ 0&{\cos {\theta _x}}&{\sin {\theta _x}}&0 \\ 0&{ - \sin {\theta _x}}&{\cos {\theta _x}}&0 \\ 0&0&0&1 \end{array}} \right], $

(3) $ {{{R}}_{{y}}} = \left[ {\begin{array}{*{20}{c}} {\cos {\theta _y}}&0&{ - \sin {\theta _y}}&0 \\ 0&1&0&0 \\ {\sin {\theta _y}}&0&{\cos {\theta _y}}&0 \\ 0&0&0&1 \end{array}} \right], $

(4) $ {{{R}}_{{z}}} = \left[ {\begin{array}{*{20}{c}} 1&0&0&0 \\ 0&{\cos {\theta _z}}&{\sin {\theta _z}}&0 \\ 0&{ - \sin {\theta _z}}&{\cos {\theta _z}}&0 \\ 0&0&0&1 \end{array}} \right], $

(5) $ {{T}} = \left[ {\begin{array}{*{20}{c}} 1&0&0&0 \\ 0&1&0&0 \\ 0&0&1&0 \\ {{x_1}}&{{y_1}}&{{z_1}}&1 \end{array}} \right]. $

假设IFC模型中局部坐标坐标系原点在3D Tiles中世界坐标系的坐标为 $({x_1},{y_1},{z_1})$，该局部坐标系Z轴垂直地面向上，Y轴指向正北，各坐标轴对应的旋转矩阵是 ${{{R}}_{{x}}}$、 ${{{R}}_{{y}}}$、 ${{{R}}_{{z}}}$； ${\theta _x}$、 ${\theta _y}$、 ${\theta _z}$ 是旋转矢量与X轴、Y轴、Z轴的夹角.

IFC信息获取是整个工作的基础. 利用Revit软件将建筑模型导出，得到整个建筑的IFC文件（IFC2×3）. 调用BIMServer API中的检索包对整个建筑模型（IFC文件）进行检索，按照拆分规则，将模型拆分为IFC文件和JSON属性文件. 应用IfcOpenShell库中的IfcConvert工具将每个建筑构件对应的IFC文件转换为OBJ文件. 整个过程如图6所示.

使用obj2gltf工具，将OBJ文件转换为glTF文件，添加包含属性信息的JSON文件组成要素化的b3dm文件，再添加瓦片集文件，得到可在Cesium框架中展示的3D Tiles文件.

在转化过程中，需要根据拟定算法完成局部坐标系到世界坐标系的空间关系的映射、BIM模型到三维瓦片模型语义属性数据的映射以及属性数据到展示模型的映射. 将模型几何数据按照转换矩阵对坐标系进行转换，完成空间数据的映射，将相关属性信息录入对应要素的批次表层次结构（Batch Table Hierarchy）拓展要素属性，完成语义属性的映射. 瓦片数据在glTF数据属性中增加_BATCHID属性，该属性存储整数数组，与渲染图元中的顶点数组对应. 当Cesium框架运行，渲染某一图元时，该图元的顶点数组与batchid数组形成映射，即可在渲染该batchid所对应的所有图元时，找到对应索引位置的属性数据，完成批次表对应的要素属性数据到模型的映射，如图7所示.

瓦片集数据仅包含三维瓦片的基本信息，加载的模型以b3dm形式保存在瓦片数据中. 瓦片数据的组织，也就是空间索引和LOD划分，很大程度上决定了3D Tiles的实际加载速度和渲染效果. 合理的空间索引结构和LOD层级划分，能够在保证加载效率的同时，避免对整个数据集进行遍历，大幅提高渲染速度. 在3D Tiles中，瓦片空间索引结构很自由，可以使用k-d树、四叉树、八叉树、网格等常见树结构的任意一种，如图8所示. 相同层级之间的瓦片可以交叉，也允许不规则分布.

智慧城市是目前GIS和BIM集成的重点领域，但以城市为尺度进行场景渲染^[14]，一个场景可能包含数以千计甚至万计的建筑物三维模型. 三维数据所占存储空间大，以有限的网络带宽、内存容量、计算性能和渲染性能遍历所有节点加载数据势必影响数据渲染速度和帧率. 在浏览数据时，用户观察到的数据只是一部分，其余数据对最终显示不产生影响. 因此在LOD索引层级基础上，通过视域剔除减少渲染数据量可进一步提高数据调度效率.

1）屏幕空间误差.

视点的可视空间是一个锥体（视锥体），LOD层级为数据索引提供了结构，数据渲染过程中需要判断LOD层级进行加载. 根据视点位置和视锥体方向，靠近视点的瓦片数据需要更高分辨率，反之，则加载分辨率较低的瓦片. 屏幕空间误差（screen space error，SSE）^[15]是确定具体加载层级的指标.

在展示渲染模型的过程中，通过视点决定显示区域绘制的内容，如图9所示. SSE可由几何误差（geometric error）和视锥体情况确定，如图10所示， $r$ 为几何误差； $d$ 为视点到远截面的距离（线段AE）； $\alpha $ 为视锥体的角度； $h$ 为屏幕高度（线段BC）； $\delta $ 为屏幕空间误差.

根据透视投影几何关系，可得

(6) $ \frac{\delta }{r} = \frac{h}{{2d \times \tan \left( {{\alpha /{\rm{2}}}} \right)}}. $

从而得到屏幕空间误差的计算公式如下：

(7) $ \delta = \frac{{hr}}{{2d \times \tan \left( {{\alpha / {\rm{2}}}} \right)}}. $

将SSE与阈值 $\varepsilon $ 比较以确定是否加载下一级节点. 如果 $\delta < \varepsilon $，则不加载下一级节点，如果 $\delta > \varepsilon $，加载下一级节点.

2）视锥体剔除.

视锥体剔除是指剔除不在视锥体视域范围内的三维物体，具体实践中，即不加载包围盒与视锥体不存在交集的瓦片数据. 其实现原理如图11所示为球型（sphere）包围盒和视锥体. 点O为包围盒球心， $(x,y)$ 是该点坐标. 由几何关系可得

(8) $ h = \left( {y - x \times \tan \frac{\alpha }{2}} \right)\times \cot \frac{\alpha }{2}. $

将 $h$ 与包围盒半径比较以确定是否加载该节点；如果 $h < r$，则不加载该节点；如果 $h > r$，加载该节点.

3）背面剔除.

视点、视锥体和物体A位置关系如图12所示. 对于视点而言，物体A实线面可见，虚线面不可见. 数据渲染前可进行可见性判断，剔除不可见面片，只对可见的瓦片要素渲染显示，以提高渲染速率. WebGL本身提供了背面剔除的接口函数，直接调用gl.cullFace函数即可在光栅化阶段完成背面剔除^[16].

为保证当面对城市体量级的三维建筑模型时，常规计算机所提供的渲染力能满足场景的渲染加载要求，建立BIM数据在WebGIS框架下的LOD检索层级，辅以视域剔除，应用目标场景调度算法以实现快速检索和确定需要渲染绘制的场景区域和层级.

如图13所示，首先通过视锥体剔除，确定视锥体可视范围内瓦片数据的根节点；然后通过背面剔除，判断瓦片数据是否可见；最后根据SSE确定该节点是否满足阈值要求，若不满足则根据索引结构检索其子节点，直到检索出满足阈值误差要求的瓦片节点.

在进行三维场景可视化的首次渲染绘制指令时，系统根据视锥体参数和索引结构判断所要加载的瓦片数据和层级，向服务器请求相关数据，收到返回的数据后，依托WebGL可视化接口对数据进行绘制，在浏览器上显示结果. 用户进行操作时，视锥体参数发生变化，系统根据场景调度算法更新数据，同时判断缓冲内存中是否存在需要调用的数据，存在则直接从本地加载，不存在则向服务器请求新数据. 渲染帧率和加载速度直接反应系统流畅程度，帧率越高，加载速度越快，则用户体验越好. 选择2份内容相同的数据，第一份不进行处理，为对照组；第二份进行视域剔除算法处理，为实验组。在Cesium中加载2份数据，可获得渲染加载过程中对照组的帧率图（见图14）和实验组的帧率图（见图15）. 从图中可以看出，两次加载帧率均稳定在50 fps左右，经视域剔除后的帧率更加稳定；经视域剔除后加载时间更短. 如果不进行视域剔除算法处理，在数据量更大、实验平台性能不足的情况下，帧率不稳定和加载时间变长的现象会更加明显.

为验证以上提出的IFC到3D Tiles格式转换方法的可行性，本文选取某BIM模型进行测试. 模型信息：18层居民楼，大小为44.8 MB；硬件环境：Intel Core i7-4800 MQ 2.70 GHz CPU，内存为16 GB，NVIDIA Quadro K2100 M GPU；软件环境：Chrome浏览器，Node.js服务器.

1）运用Revit软件将居民楼模型以IFC格式导出，并将导出的文件上传到BIMServer服务器. 调用BIMServer API中的检索包对整个建筑模型进行检索，按照拟定的检索规则将整个模型拆分成建筑构件，分别保存每个构件对应的IFC文件和JSON属性文件. 以窗为例，对属性为窗的构件进行整理，可得表1. 窗构件数量多达518个，但类型仅有7种. 因此在瓦片数据的构成中，仅需保留7种窗构件各1个，渲染加载时根据batchid反复调用.

2）运用BIM_to_3Dtiles格式转换工具对IFC文件进行处理，在此过程中完成数据映射、数据组织和索引结构构建，得到glTF文件. 在此基础上添加包含属性信息的JSON文件组成b3dm文件. BIM_to_3Dtiles是基于以上分析流程，为减少转化时间而实现的格式转换工具. 该工具的实现以开源库IfcOpenShell、IfcPlusPlus、obj2gltf为基础. 经过数据组织和索引结构的构建，在视角与模型之间距离较近时，加载物体的高层级LOD4模型数据；当视角与模型之间距离拉开时，屋檐、窗户等相对较小的构件在较低的LOD2、LOD3层级设置为不加载，直接从高层级LOD中删除一部分构件数据，以保证加载速率和加载精度根据视角的远近达到一个均衡程度；当视角与模型距离较远时，只加载LOD1层级的场地轮廓，具体加载类型和渲染情况如表2所示.

3）为b3dm文件添加瓦片集文件（Tileset.json），组成能够在Cesium中加载的3D Tiles数据. 将得到的三维瓦片数据打包并通过Node.js服务器发布，即可在Chrome浏览器中实现该居民楼BIM模型的加载.

如图16~18所示为最终在Cesium框架中实现居民楼样板模型加载的效果。图16为Cesium框架初始加载页面，证明数据成功发布至网页端三维GIS框架中；图17为Cesium框架下居民楼样板模型的近景和远景，模型位置准确，墙、楼板、窗等建筑构件显示完整，证明坐标转换顺利，几何信息保留完整；图18为鼠标点击基本墙构件后弹出的墙构件属性框，证明几何构件之间相互独立，且构件的属性信息保留完整。综上所述，从居民楼样板模型渲染加载的结果来看，LOD层级划分明确，几何构件相互独立，属性信息保留完整，达到实验预期效果。

（1）本研究基于开源库IfcOpenShell、IfcPlusPlus、obj2gltf编制了格式转换工具，能够将IFC文件按照构件进行拆分，提取其几何信息和属性信息进行格式转化，得到对应3D Tiles文件.

（2）在文件格式转换的过程中，通过对模型数据的空间索引结构进行设计，对构件坐标系进行坐标转换，划分合理的LOD层级，保证了BIM数据以3D Tiles的文件格式在WebGL平台上实现快速渲染加载，但由于未提取不同精度的IFC模型文件，LOD层级在转换过程中只能采取ADD，不能采取REPLACE的转换方法.

（3）改变了模型轻量化的处理思路，以BIM文件格式转换为三维瓦片数据的方式完成了BIM数据在三维WebGIS框架下的渲染展示，为BIM和GIS的数据集成和信息交互提供了完整可行的实施方案.