BIM中的數(shù)據(jù)交換問題

在開發(fā)BIM解決方案的過程中，經(jīng)常會遇到數(shù)據(jù)交換的問題。什么是數(shù)據(jù)交換？簡單來說，就是把A軟件中產(chǎn)生的數(shù)據(jù)導入到B軟件中去�？此坪芎唵蔚囊粋�問題，卻是一直困擾BIM軟件開發(fā)者和使用者的大麻煩。

 大家都知道，建筑項目的參與方通常包括建筑、結(jié)構(gòu)、水、暖、電以及概預算等多個專業(yè)，各個專業(yè)所使用的軟件和工具也是五花八門，不一而足。如何使得信息能夠在不同的系統(tǒng)間平滑地流動，是創(chuàng)建和使用建筑信息模型的一個重要課題。在和學術界及業(yè)界的同仁們交流的過程中，經(jīng)常會遇到這樣的討論：

 （1）能不能開發(fā)一個接口來將A程序的數(shù)據(jù)導入到B程序？

（2）能不能通過一個通用的數(shù)據(jù)格式來交換數(shù)據(jù)？

 先來看看點對點的接口。雖然幾乎所有CAD和BIM軟件都會或多或少提供一些接口工具來進行數(shù)據(jù)交換，但大家都有一個共識：這種點對點的接口會形成一個網(wǎng)狀結(jié)構(gòu)，當軟件數(shù)量較多時，需要的接口數(shù)量會呈指數(shù)增長，從而帶來開發(fā)和維護的問題。如果問題僅限于此的話，也許數(shù)據(jù)交換的問題就不會是一個大問題了。那么，數(shù)據(jù)交換到底難在哪兒？來看看下面幾種情況：

 （1）“語言不通”

不同軟件使用的數(shù)據(jù)模型千差萬別，就像一個說中文，一個講英語，在單詞和語法上都有很大的差別。很多人都用過自動翻譯工具，這里給一個例子：“好好學習，天天向上”-->“Good Good Study, Day Day Up”，相信只有中國人才能看懂這樣翻譯過來的英文。這還算是好的，更多情況下，自動譯文估計只有翻譯工具自己才能理解。做接口就像是做翻譯工具，很難做到數(shù)據(jù)模型的精確轉(zhuǎn)換。帶來的問題就是：假溝通。讓我想起一個例子：某軟件號稱能夠輸出DWG文件，但輸出的DWG文件只能被它自己認識。

 （2）“你要的東西我沒有” 

我遇到過一些項目使用3D Max進行復雜建筑造型設計。如果要使用Green Building Studio來進行建筑性能分析，能不能做一個接口來把Max模型轉(zhuǎn)換成gbXML（GBS的輸入文件格式）呢？來看看能不能做到。要生成gbXML文件，首先需要知道墻、樓板、門、窗等信息，而Max模型中只包含了幾何信息。顯然，直接轉(zhuǎn)換不可行。另外一個方案，如果讓用戶給Max幾何實體附加一些額外的信息（例如，設定好哪里是墻，哪里是門等)，是不是就可以了？還是有問題。gbXML還需要知道建筑構(gòu)件間（墻與墻、墻與樓板等）的拓撲關系，而這些關系很難通過幾何數(shù)據(jù)推導出來。是不是也要用戶去手工設定這些拓撲關系？

 （3）“我給你的不是你想要的”

 在上面Max-->gbXML的例子中，假如有一道復雜曲面造型的墻體跨越了多個樓層，在生成gbXML的時候，則需要根據(jù)樓層將其切割成多個部分。在開發(fā)接口時，需要針對類似的情況進行復雜的幾何計算。熟悉計算幾何的人都知道，這不是一個簡單的問題。

 （4）“我給你的你消化不了”

 我曾經(jīng)在一個項目中試圖把Inventor中的幾何模型導入到Revit中去，可調(diào)研后發(fā)現(xiàn)，Inventor所支持的幾何造型遠遠比Revit所能支持的幾何造型復雜。除非對Inventor中的復雜模型進行簡化和分解，否則這種轉(zhuǎn)換是不可行的。

 這些問題僅僅依靠接口程序本身是很難完整解決的。軟件自身還需要不斷地修煉內(nèi)功。

 第二個問題：能不能通過一個中性的數(shù)據(jù)格式來交換數(shù)據(jù)？

 通用數(shù)據(jù)格式是一個看上去很美的東西。就好像讓地球人都說同一種語言，就不會存在溝通的問題了。情況果真如此嗎？

 我在北京讀大學的時候，才知道北方人管南方人說的“大白菜”叫“白菜”，管南方人說的“白菜”叫“青菜”。北方人和南方人說的都是普通話，但依然會出現(xiàn)溝通不暢的情況。類似的問題在使用中性數(shù)據(jù)格式交換數(shù)據(jù)的時候也會發(fā)生。

 還有一種情況，就是信息的表現(xiàn)形式。以表示一個球為例，可以有參數(shù)形式（球心坐標、半徑）、三角形網(wǎng)格形式（點、線、三角形）等。如果以參數(shù)方式來表示，則數(shù)據(jù)的消費者可以有最大的自由度，即其可以通過改變球心和半徑來操作這個球。但是，這里有各前提，數(shù)據(jù)的消費者需要能夠理解這些參數(shù)，即知道如何根據(jù)參數(shù)來生成這個球的幾何造型。另一方面，如果以三角形網(wǎng)格的形式來表達，數(shù)據(jù)的消費者可以很方便地顯示這個球，而無需具備解析參數(shù)的能力，但其操作自由度也小了很多。在實際應用中，信息的復雜度遠遠大于一個簡單的球，其表現(xiàn)形式也存在多種。那么，在輸出中性文件時，該使用哪種表現(xiàn)形式呢？你也許已經(jīng)有了答案：根據(jù)數(shù)據(jù)消費者的需要選擇合適的表現(xiàn)形式。你說的沒錯！可問題是，很多人希望這種中性的數(shù)據(jù)格式能夠被不同的數(shù)據(jù)消費者所使用。這個要求是不是有點太高了？！也許，針對不同的數(shù)據(jù)交換需求建立相應的標準才是王道。