|
【 第一幕墙网 】
在开发BIM解决方案的过程中，经常会遇到数据交换的问题。什么是数据交换？简单来说，就是把A软件中产生的数据导入到B软件中去。看似很简单的一个问题，却是一直困扰BIM软件开发者和使用者的大麻烦。 大家都知道，建筑项目的参与方通常包括建筑、结构、水、暖、电以及概预算等多个专业，各个专业所使用的软件和工具也是五花八门，不一而足。如何使得信息能够在不同的系统间平滑地流动，是创建和使用建筑信息模型的一个重要课题。在和学术界及业界的同仁们交流的过程中，经常会遇到这样的讨论： （1）能不能开发一个接口来将A程序的数据导入到B程序？ （2）能不能通过一个通用的数据格式来交换数据？ 先来看看点对点的接口。虽然几乎所有CAD和BIM软件都会或多或少提供一些接口工具来进行数据交换，但大家都有一个共识：这种点对点的接口会形成一个网状结构，当软件数量较多时，需要的接口数量会呈指数增长，从而带来开发和维护的问题。如果问题仅限于此的话，也许数据交换的问题就不会是一个大问题了。那么，数据交换到底难在哪儿？来看看下面几种情况： （1）“语言不通” 不同软件使用的数据模型千差万别，就像一个说中文，一个讲英语，在单词和语法上都有很大的差别。很多人都用过自动翻译工具，这里给一个例子：“好好学习，天天向上”-->“Good Good Study, Day Day Up”，相信只有中国人才能看懂这样翻译过来的英文。这还算是好的，更多情况下，自动译文估计只有翻译工具自己才能理解。做接口就像是做翻译工具，很难做到数据模型的精确转换。带来的问题就是：假沟通。让我想起一个例子：某软件号称能够输出DWG文件，但输出的DWG文件只能被它自己认识。 （2）“你要的东西我没有” 我遇到过一些项目使用3D Max进行复杂建筑造型设计。如果要使用Green Building Studio来进行建筑性能分析，能不能做一个接口来把Max模型转换成gbXML（GBS的输入文件格式）呢？来看看能不能做到。要生成gbXML文件，首先需要知道墙、楼板、门、窗等信息，而Max模型中只包含了几何信息。显然，直接转换不可行。另外一个方案，如果让用户给Max几何实体附加一些额外的信息（例如，设定好哪里是墙，哪里是门等)，是不是就可以了？还是有问题。gbXML还需要知道建筑构件间（墙与墙、墙与楼板等）的拓扑关系，而这些关系很难通过几何数据推导出来。是不是也要用户去手工设定这些拓扑关系？ （3）“我给你的不是你想要的” 在上面Max-->gbXML的例子中，假如有一道复杂曲面造型的墙体跨越了多个楼层，在生成gbXML的时候，则需要根据楼层将其切割成多个部分。在开发接口时，需要针对类似的情况进行复杂的几何计算。熟悉计算几何的人都知道，这不是一个简单的问题。 （4）“我给你的你消化不了” 我曾经在一个项目中试图把Inventor中的几何模型导入到Revit中去，可调研后发现，Inventor所支持的几何造型远远比Revit所能支持的几何造型复杂。除非对Inventor中的复杂模型进行简化和分解，否则这种转换是不可行的。 这些问题仅仅依靠接口程序本身是很难完整解决的。软件自身还需要不断地修炼内功。 第二个问题：能不能通过一个中性的数据格式来交换数据？ 通用数据格式是一个看上去很美的东西。就好像让地球人都说同一种语言，就不会存在沟通的问题了。情况果真如此吗？ 我在北京读大学的时候，才知道北方人管南方人说的“大白菜”叫“白菜”，管南方人说的“白菜”叫“青菜”。北方人和南方人说的都是普通话，但依然会出现沟通不畅的情况。类似的问题在使用中性数据格式交换数据的时候也会发生。 还有一种情况，就是信息的表现形式。以表示一个球为例，可以有参数形式（球心坐标、半径）、三角形网格形式（点、线、三角形）等。如果以参数方式来表示，则数据的消费者可以有最大的自由度，即其可以通过改变球心和半径来操作这个球。但是，这里有各前提，数据的消费者需要能够理解这些参数，即知道如何根据参数来生成这个球的几何造型。另一方面，如果以三角形网格的形式来表达，数据的消费者可以很方便地显示这个球，而无需具备解析参数的能力，但其操作自由度也小了很多。在实际应用中，信息的复杂度远远大于一个简单的球，其表现形式也存在多种。那么，在输出中性文件时，该使用哪种表现形式呢？你也许已经有了答案：根据数据消费者的需要选择合适的表现形式。你说的没错！可问题是，很多人希望这种中性的数据格式能够被不同的数据消费者所使用。这个要求是不是有点太高了？！也许，针对不同的数据交换需求建立相应的标准才是王道。 |
