扩展BIM至空间数据库的做法与应用

有利资料存取 扩展BIM必走之路

今日随着建筑信息塑模（Building Information Modeling，BIM）技术日益成熟，以及在营建业应用的蓬勃发展，可预期BIM将成为建筑物生命周期各阶段之信息储存与管理中心。在建筑物规划、设计与施工阶段，国内外文献均呈现许多BIM应用成功的实例，如BIM在协同设计、4D碰撞检查，与可施工性分析（Constructability Analysis）等。究其原因，乃BIM商用软件能提供完善的建筑元件编修能力，如参数化设计、建筑元件库等，使得资料可改一次、用很多次，达到资料一 致性的理想境界，进而显示信息整合后的优势。

然而，从资料存取的角度来看，BIM终将累积出完整的建筑物设计施工阶段各式资料，但现今BIM商用软件是否足以担任建筑物整合式资料来源的重责大任，使得后续越来越多的软件应用程序皆可顺利存取BIM资料呢？

例如，目前数据库技术可轻易达到大量资料的快速查询功能（透过索引机制）、资料栏位的动态增减与资料字典管理（透过SQL DDL机制），与巨量等级以上资料管理（透过BLOB机制）等，均少见于目前商用BIM软件中。但此需求随着营建、物业管理，甚至防救灾管理领域更多软件应用程序的出现，扩展BIM是一条必走之路。

本文提出一套结合空间数据库的BIM扩展做法与应用案例，着眼于利用原本数据库技术擅长的栏位扩充、档案处理、简单空间关系之大量资料快速查询能力，使得更多软件应用程序可重用BIM资料与功能。在此除了说明扩展与转换BIM资料的做法，也探讨应用案例，并展望未来。

资料存取至数据库 转换做法

BIM技术与数据库技术具有不同的设计理念：BIM强调视觉化建筑物3D几何，同时提供丰富的属性信息；数据库则多半无视觉化能力，但均可处理2D或3D几何资料，可多人同时存取大量资料且良好地维持资料一致性。从文献[1]可知，若要让更多软件应用程序可顺利存取BIM资料，有两种做法：

（1）将BIM资料汇出至开放的档案格式，如IFC或COBie；

（2）透过BIM软件应用程序提供的API（Application Programming Interface）存取BIM模型内各式属性信息。一般而言，第一种作法虽然开放，但模型转换技术无法避免语意上（semantic）的信息遗失。例如，在同水平位置但不同楼层的房间具有垂直空间关系，还有房间、走廊与楼梯的联通性等。第二种作法虽然看似封闭，但透过API存取软件内部资料原本就是目前软件的技术主流，如微软Office亦开放NET或VBA界面让外部应用程序可操控Office内部行为与资料，做进阶应用。然而，此作法也伴随着两类问题，其一为BIM软件厂商对于开放API的态度，有时因保护BIM运作顺畅故不开放某类型API以求稳定，因此使用前必须评估与审查这些API的适用性。

使用API存取BIM资料的第二问题在于执行效能。例如，图一左侧为一个简单的范例建筑物，乃以Revit 2014制作，内含50个建筑元件。若以Revit API写Plugin软件应用程序，计算任意2至50个建筑元件的体积，其执行所需时间如图二蓝线所示。同时，若将上述50个元件建立在空间数据库领域着名的开放软件PostgreSQL 9.3与PostGIS 2.0内，其储存后结果如图一右侧，并撰写空间资料查询SQL程序计算体积，其执行所需时间如图二的橘线所示。本文虽以Revit作为测试对象，但使用其他BIM软件如Tekla、ArchiCAD等均可得类似的结果。简言之，从图二可看出随着建筑元件数量的增加，BIM软件执行空间查询时间将快速成长，与空间数据库执行时间的差异亦渐增。

　　图一 左侧：范例用简单Revit模型；右侧：模型转换至空间数据库后的表格

进一步分析其原因可知，BIM提供非常完善的建筑元件资料编辑能力，且建筑元件时常具有复杂的资料结构，但若只以基本资料存取动作之查询指令来看，当然无法与专为多人快速存取设计的数据库技术相比。此外，在建筑物生命周期的后期应用阶段，BIM模型特别是几何类资料之异动频率就不高，但资料之查询与加值运算的需求却频繁很多，若能将常用的BIM资料转换至空间数据库，并建立连结与索引的机制，相信整体BIM信息应用系统的执行速度可大幅提升。

除执行效能层面的考量，转型BIM至空间数据库亦具有「管理」上的优势。如同数据库技术的发展历史，一般企业运作的基底资料可依资料本体的特性分类至各「关联表格」（或称之为Conceptual Model），但也因企业具有各式各样的服务或流程，常将资料动态分类组成特定领域的特定应用方式（称之为View Model），此种既集中又分散的弹性做法，背后依靠的数学为集合理论，造就数据库技术为当今主流派。回到BIM的领域，BIM内各式建筑元件只依设计或施工阶段的分类方式，原本便较难弹性运用在后期各领域，但若能扩展到数据库，且维持空间运算特性，便可动态组合出使用者欲处理的建筑元件群组，应是较适当的做法。

　　图二 查询任意2-50个建筑元件之体积指令在Revit与PostgreSQL所需执行时间（秒）

此外，从软件应用程序的需求面考量，BIM转换至空间数据库的建筑元件几何形状应可再行简化，例如某走廊上的灭火器，在BIM内的3D呈现可以相当逼真， 但在防救灾应用上，也许使用者只想知道「方圆三公尺内的灭火器」，或「离某物件五公尺内的其他建筑元件」等查询结果。是故，笔者乃发展最小方盒（Bounding Box）包装技术，使得符合指定条件的所有建筑元件，均可自动产生其最小方盒并储存在空间数据库中。简言之，最小方盒即是某建筑元件之x/y/z轴的最大与最小值组成，空间数据库内则储存：元件编号（Element ID）、元件类型（Element Type）、最小方盒几何（Bounding Box Geometry）、元件阶层（Element Level），更多的属性也可视需要而自由地新增。图三显示一群范例建筑元件（左图）之最小方盒包装化的结果（右图）。因建筑元件几何形状可能非与x/y/z坐标轴平行（如屋顶斜窗），最小方盒化时须使方盒体积最小，故可能不一定在xy平面上。

转换BIM建筑元件重要属性至空间数据库后，接下来便可依循OGC（Open Geospatial Consortium）组织替空间数据库定义的SpatialSQL功能，执行空间联集、差集，与交集运算[2]。例如，假设某消防设备服务有效范围为三十公尺，利用空间数据库可非常容易找出建筑物内此消防设备无法有效服务的区域。部份商用资料库甚至提供更进阶的空间推理功能，远超过现今BIM软件能提供的空间运算能力。

　　图三 任意建筑元件之最小方盒包装化后结果

扩增BIM应用 建立多对多关系

在执行一些BIM应用计划的过程当中，笔者发现BIM模型常扮演资料中控端的角色，亦即许多软件程序的输入资料，必须由BIM模型中的某群建筑元件属性转出；许多软件程序的输出资料，事实上是针对某群建筑元件有意义，同时部份输出资料可能为另一软件程序的输入资料，信息流相当复杂但却很有条理。既然各式软体程序的输入或输出资料均与BIM建筑元件群组有关系，如何透过Revit API寻找这些群组便成为首要工作。接下来则建立「建筑元件」与「外加档案」的多对多关系，让各式软件程序的输入或输出以档案形式呈现：

·建筑元件群组A内含元件A1、元件A2等，这些元件的属性可汇出成档案给软件程序a使用，也可汇出成另一格式给软件程序b使用。

·软件程序C的输出档案，会影响建筑元件C群组与D群组的属性值。

此种元件与档案的多对多关系，可透过一关系表格清楚记录在空间数据库中。如图四所示，符合特定条件的群组，内含数个建筑元件（上图）。每个建筑元件可能关联到数个档案（下图（1）），同时，某个档案也可能关联到数个建筑元件（下图（2））。

　　图四 上图：查询符合特定条件之元件；下图：元件与外加档案为多对多关系

上述软件运作环境，皆假设BIM建筑元件几何属性资料的部份已无异动，方能在初次使用时转换至空间数据库内，使得BIM模型内实际几何资料与空间数据库最 小方盒资料一致。透过对最小方盒的条件查询，多样化的动态分类以至于关连到外加档案机制，便可使BIM扮演资料中控端的角色，与其他软件应用程序进行良好互动。

两者互相支援　加乘效应

BIM软件具有优异的视觉化能力，也具有完善的3D空间资料处理能力，确实已能协助建筑物之规划、设计与施工阶段众多信息应用服务。然而，如同现今云端数据库与传统数据库各有所长的现象，BIM信息模型与空间数据库的设计理念不同，若能截长补短，使得BIM专注在视觉化与3D资料编辑（新增/修改/删除）工作上，而空间数据库则聚焦在资料查询上，相信此混合式作法，尤其对生命周期后期阶段的软件应用程式将有很大助益。

现今部份空间数据库产品仍未完全实作OGC SQL的全部定义，因此BIM软件处理空间运算中，部份函数的执行效能有时甚至比空间数据库还快，这其中的分水岭需学术界或实务界来找到适当的平衡点，以设计信息分流机制，使得较复杂的空间运算由BIM软件完成，较简单但大量的服务则由空间数据库完成。此外，建筑物在营运维护阶段仍有可能进行BIM资料的修改，如何适当地反馈至空间数据库也是另一个值得深入研究的议题。

参考文献

[1] MP Gallaher, AC O’Connor, JL Dettbarn, Jr., and LT Gilday （August 2004）。 Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. National Institute of Standards and Technology, USA.

[2] ISO 19125-2:2004, Geographic information — Simple feature access — Part 2: SQL option, International Organization for Standardization.

微信公众号：xuebim

关注建筑行业BIM发展、研究建筑新技术，汇集建筑前沿信息！

← 微信扫一扫，关注我们+