BIM模型數(shù)據(jù)主要有哪些交換方式與方法?事實上，信息回饋至BIM模型之前往往先有信息擷取的過程，因為信息回饋端至少必須知道BIM模型的項目信息、對象標識符、參數(shù)化屬性標識符、參數(shù)數(shù)據(jù)格式等基本信息，因此信息擷取的方法將會影響信息回饋的途徑(approach)，以下就目前市面上三大建模工具(AutodeskRevit,GraphisoftArchiCAD,BentleyAECOsim)共同有的功能來分析各種BIM模型信息交換(即包含擷取和回饋)之方法或途徑，并以入門或操作門坎的高低順序來闡述。

一、電子數(shù)據(jù)表(spreadsheet)

大部分的BIM設計工具皆有輸出明細報表(schedule)之功能，并可以在輸出后其他電子表格軟件(如：MicrosoftExcel)來編輯，但若要修改表格中的屬性值或?qū)崟r反映(即動態(tài)交互參照)修改模型后的屬性值，則必須回到原本采用的BIM設計工具來操作?；旧?，電子數(shù)據(jù)表位于BIM設計工具的內(nèi)部環(huán)境，難以與外界溝通，也就是連基本的相互操作性都有蠻大的問題，因此較適合用于信息擷取和輸出，信息回饋則較不適用。

二、公開標準格式(openstandard)

與BIM相關的公開標準格式很多，可以達到一定程度相互操作性的卻很少，這些公開標準較知名的有：IFC、COBie、gbXML等等。目前大部分的BIM設計工具皆支持IFC格式的檔案輸出，而COBie、gbXML等其他公開標準格式也或多或少有支持，即便沒有支持亦可透過非官方之插件(plug-in)來輸出該格式之檔案。公開標準是一種追求完美的理想，IFC的相互操作性在近年來的確有所提升，而COBie和gbXML等格式則較不具通用性，因COBie和gbXML分別較適用在設備管理和能源分析。但整體而言，無論何種公開標準，在信息回饋方面的相互操作性仍有待改善，可以想象的是：以公開標準格式將所需信息從BIM設計工具中擷取出來，相較于用同樣格式回饋至相同(甚至不同)的BIM設計工具容易太多了。

三、開放數(shù)據(jù)庫互連(ODBC)

用外部數(shù)據(jù)庫來管理BIM模型中的信息不失為一個解決相互操作性的好方法，而ODBC是個發(fā)展已久的標準數(shù)據(jù)庫接口，但由于數(shù)據(jù)庫的操作門坎和維護成本皆不低，若模型管理者和利害關系人欲使用數(shù)據(jù)庫來進行信息交換，額外開發(fā)數(shù)據(jù)庫應用程序和依實際需求來客制化使用界面或許是必要的。另一方面，ODBC的應用實例大多搭配傳統(tǒng)常用的關系型(relational)數(shù)據(jù)庫，而關系數(shù)據(jù)庫的數(shù)據(jù)綱要(schema)對于BIM模型多變且復雜的面向?qū)ο?object-oriented)結(jié)構(gòu)在進行對象關聯(lián)對應(ORM,ObjectRelationalMapping)時很難概括承受。

四、應用程序編程接口(API)

大部分的BIM設計工具皆提供API讓具程序開發(fā)能力之用戶延伸其核心功能，信息擷取和回饋當然是非常普遍的應用，但API的使用門坎又比用數(shù)據(jù)庫來管理高出許多，因使用API來進行數(shù)據(jù)交換除了必須具備面向?qū)ο蟮某绦蜷_發(fā)能力，還需對BIM設計工具的對象核心架構(gòu)相當了解，且不同的BIM設計工具有不同的API，更添難度，因此模型管理者和利害關系人欲直接透過API來進行數(shù)據(jù)交換可謂強人所難。此外，API的應用范圍和彈性雖高，但若只「單純」采用API來開發(fā)BIM設計工具的插件，則又回到以檔案為基礎(file-based)之數(shù)據(jù)交換模式，對于協(xié)同作業(yè)、版本管控和相互操作性而言不見得較有效率。

BIM模型主要由BIM建模軟件工具來建立，故建模工具是最基礎的BIM設計工具，若將建模工具視為一個獨立的計算機系統(tǒng)，則將信息從此系統(tǒng)提取出來或存放進去的動作，即是一種信息擷取或信息回饋的操作，而在目前市場占有率較高的幾個建模工具中，具備信息擷取的功能和方法較多，信息回饋的功能和方法則較少，且普遍存在技術門坎較高、相互操作性較差和效率不彰等問題。