第 一 節 BIM-IFC 與 各 種 3D-GIS 格 式 特 性 與 比 較
本研究進行 IFC 與 3D-GIS 轉換之研究，目的即在於嘗試將建築物與地理 資訊系統進行結合，進行大範圍的空間分析與模擬。並將建築元件之維護管 理資訊一併帶入，在地理資訊系統中進行應用。關於 BIM 之 IFC 及 3D-GIS 的 各種格式之特性與比較如下所述：
（一） IFC
IFC 格式在 BIM 領域中已經是一個交換資料的標準格式，無論使用哪一 種 BIM 軟體，最後都能輸出 IFC 格式與其他的軟體進行資料交流。
IFC 格式是採用 ISO 10303-11 所定義之描述語言，即 Express 語言進行編 寫，此種資料結構的特色在於十分的簡潔，重複的資訊以引數(index)的方式 進行引用，以避免重複的資訊太多佔去太多位元使得檔案大小增加。但此種 儲存方式也使得資料的易讀性下降，沒有經過編譯的編碼是難以直接閱讀 的。
因為 IFC 已經成為 BIM 領域中的交換標準，於是 BIM 領域與其他領域的 串接，使用 IFC 格式來進行翻譯、轉換是比較適當且通用的。
（二） CityGML
CityGML 是 一 種 OGC 已 認 定 的 開 放 格 式 ， 以 可 擴 展 性 標 記 語 言 (Extensional Markup Language, XML)的語法寫成，經過空間資料上的定義，依 照地理圖徵之描述需求而建立的綱要(Schema)，成為地理標記語言(Geography Markup Language, GML)。
由於 XML 的語言特性，具有起始標籤<.>及結束標籤</.>，相同的文字會 重複出現，導致所佔的字元數增加，使得檔案變大。雖然具有 Schema 定義標 籤內的資料類型，方便資料的接收及二次處理，但卻有檔案過大，電腦效能 要求較高的問題。CityGML 語言範例如下圖 5- 1 所示。
70
（三） CityJSON
CityJSON 是一種以 CityGML 為基礎，改寫為 JSON 的一種檔案格式，但尚 未被 OGC 認定為開放格式，目前由台夫特理工大學(Technische Universität Delft, TU Delft)進行開發與維護。由於 JSON 是一種以括號與逗號分隔成不同語意的 語言，並不需要標籤重複出現，相較於 CityGML 而言是相當輕量的格式，其 檔案大小可能相差 3~10 倍。但相較於 GML 或 XML，JSON 的格式並無強制定 義每個欄位的屬性與意義，並無法透過綱要(Schema)進行資料格式的檢核與驗 證正確性，也因此較不適合作為交換標準使用。其語言範例如下圖 5- 2 所示。
（四） i3s
i3s 格式是由 esri 公司研發，為 ArcGIS 3D 而設計的檔案格式，為了未來 與行動裝置的串連，其基底是以 JSON 語法進行撰寫，以方便提供 WebGL 使 用。i3s 格式除包含點、線、面等幾何資訊，還可以建立塊體、點雲，亦可以 將多個物件包裹成一個檔案(*.slpk)與其他的單機進行檔案的交換。其呈現的 樣貌於下圖 5- 3 所示。
圖 5- 1 CityGML 格式語法節錄
資料來源：本研究整理
圖 5- 2 CityJSON 格式語法節錄
資料來源：本研究整理
圖 5- 3 esri ArcGIS 之 i3s 展現的樣貌
資料來源：esri 網站
71
（五） glTF
glTF 是一種以 JSON 語法為基底寫成的 3D 模型檔案格式，目前已廣泛應 用於 3D 模型、遊戲製作等領域。CesiumJS 團隊將 glTF 借用來做為 3D 建築物 模型，並加入 GIS 概念，將 glTF 包裝成為 3D Tiles 做為 3D-GIS 系統。glTF 做 為 3D 模型，其樣貌如下圖 5- 4 所示：
（六）
綜合比較由以上 3D-GIS 使用的格式中可以發現，除了 CityGML 以外，幾乎都是利 用 JSON 的語法來編寫資料語意。除了 JSON 格式有輕量化的特點外，其自由 度也很高，並具有圖磚特性，可以提供系統及瀏覽器 WebGL 進行快速局部展 示使用。不像 CityGML 檔案必須一次讀取整個檔案，十分耗費時間與資源。
其中 i3s 有 ArcGIS 的技術支援，有比較友善的操作環境，透過圖形化介面即 可操作，glTF 方面則須自行編輯程式碼來執行，須要比較深厚的程式設計基 礎。其各種格式的比較總覽如表 5- 1 所示。
由於 JSON 語言在資訊領域的應用已十分廣泛，如應用程式編寫、網際網 路溝通資料傳送等。目前各網頁瀏覽器都可以支援 JSON 的格式，也有專為
圖 5- 4 glTF 格式做為 3D 模型的樣貌
資料來源：three.js 網站 (https://threejs.org/examples/webgl_loader_gltf.html)
72
近年新型的網頁瀏覽器已有廣泛支援 WebGL，這一種 JavaScript API 可以 不透過外掛程式，利用 JavaScript 語法直接互動呈現 2D 與 3D 圖形。如上的數 款 3D-GIS 軟體所使用的格式，均是以 JSON(JavaScript Object Notation)語法寫 成，即是為了直接與瀏覽器銜接而進行的手法，讓使用者端可以更方便的使 用。而 WebGL 作為一種 JavaScript 的 API，在設計行動裝置的應用程式時，也
73
可以較容易地讀取以 JSON 格式產製的 2D 及 3D 圖資，在行動裝置上顯示與 操作。
而 GML 語法，則是為了進行資料交換的完整性與嚴謹性定義而成的，在 現今的 GIS 使用趨勢並不相同。GML 語法並無法直接和瀏覽器產生互動而呈 現圖形，需要透過特定的 GIS 軟體才能讀取資料。於是在使用者端的親和性、
易操作性方面比較不友善。但由於嚴謹的特性，從不同系統中收取資料進行 統整時，可以利用 Schema 檢核資料的正確性，是否具有正確的資料類型，於 是在資料整合作為資料庫方面較為合適。
未來在 3D-GIS 的發展上，需要能快速的從資料庫中索取資料進行檢視。
因此，資訊面的格式上會逐漸往 JSON 方向發展。而較早期的對於 3D-GIS 模 型的 CityGML 格式語法，為了快速檢視上的需要也開始進入 JSON 的語法。由 台夫特理工大學(TU Delft)研究，將 CityGML 轉寫為 CityJSON 的轉換方法，可 以將 GML 資料加以簡化，使檔案大小更輕量，且可以更方便的提供網頁瀏覽 器使用。
74
第 二 節 CityGML 與 JSON 格 式 比 較 與 應 用
經由前節之綜合比較，可以了解到 CityGML 格式與 JSON 格式都有其優缺 點。CityGML 格式由於屬於 XML 語言，除了有許多起始標記與結束標記外，
各物件的欄位資訊都會重複儲存，但具有嚴謹的 schema 可以驗證欄位資料類 型的正確性。而 JSON 則是較輕便易攜的格式，且可支援 WebGL 直接在瀏覽 器上進行檢視，但卻缺少資料驗證的機制。
依內政部營建署於 2010 年 10 月頒訂之《公共設施管線資料庫系統建置 案共通規格》，利用 GML 格式並訂定應留存資料的項目與資料類型，便是善 用了 XML 系列格式的特性。利用嚴謹的 schema 進行資料的驗證，使不同單 位提交的資料仍保有共同性，以方便後續的資料統整與整合。
而目前營建署對於 3D-GIS 的執行方針，是由各地方政府依各自的需求規 定所需的欄位，再由營建署依據各地方政府訂定的欄位進行整合，訂出一個 能夠適用於各地方政府需求的共通規格規定，進行全國性資料的整合。在這 個執行方針之下，為避免資料整合時發生資料不相容而導致困難，且後續營 建署提供資料予其他單位使用時亦應負責資料正確性的問題，故應善加利用 XML 格式的 schema 進行資料類型的檢核。
營建署收集全國的 3D-GIS 管線資料後，成為一個可以供全國使用的資料 庫。而後其他單位索取資料庫內容作後續展示與分析使用時，則不再需要確 認資料的正確性，而是由提供的單位，也就是營建署負責維護資料品質。此 時為求快速的使用與展示，則需要使用輕量化的 JSON 格式進行 API 資料拋轉，
以增加使用的效率。而資料庫本身則可以內建由 CityGML 轉檔至 JSON 格式的 功能，以快速提供資料的拋轉。例如在液化潛勢區的範圍內，是否有管線的 影響；或是在 SafeTaiwan 安全臺灣的平台上，展示管線資訊，協助判斷道路 養護、災害防治等議題；又或是在跨縣市的地區，需要共通的管線資料，以 降低銜接介面與責任切分的衝突。
CityGML 與 JSON 在資料庫應用的概念圖如圖 5- 5 所示。
75
依概念圖所示，在未來全國 3D-GIS 管線資料的應用，分為資料收取端及 資料使用端。由於在收取端需要整合各來自各地方政府的管線資料，建議可 以使用資料結構較嚴謹的 CityGML 進行傳遞。若依照 CityGML 之 schema 輸入 資料的類型、提升資料的嚴謹性，在進行資料整合的同時，可以避免資料發 生錯誤。在資料收存與整合上可以減少錯誤發生的機會，減少再次確認資料 正確性或排除錯誤之人力物力成本。
而在使用端方面，則建議使用 JSON 格式進行資訊傳遞。由於接收資料之 後不必進行資料的二次處理，只要能讀取檔案即可。目前技術上利用瀏覽器 之 WebGL 可以直接支援 JSON 格式進行圖形及資料的展示，不必再透過安裝 軟體的方式即可直接在電腦及行動裝置上進行展示。
圖 5- 5 全國管線資料庫資料收存端與應用端概念圖
76
類別碼 CharacterString ISO 19103 識別碼 CharacterString ISO 19103 起點編號 CharacterString ISO 19103 終點編號 CharacterString ISO 19103 管道編號 CharacterString ISO 19103 管徑寬度 Decimal ISO 19103 管徑高度 Decimal ISO 19103 涵管條數 Integer ISO 19103 管線材料 CharacterString ISO 19103 起點埋設深度 Decimal ISO 19103 終點埋設深度 Decimal ISO 19103 管線長度 Decimal ISO 19103 備註 CharacterString ISO 19103
3D-GIS 與 2D-GIS 的主要差別，在於在幾何方面增加了一個高程的維度，
77
是透過屬性欄位的方式進行儲存。如同在 2D-GIS 中，管線之平面空間的位置 是以卡氏座標的方式進行儲存。
‧ 2D-GIS 幾何資料儲存方式範例：
<gml:LineString>
<gml:posList>178591.914 2503500 178591.811 2503500.289 178617.395 2503509.378 178626.211 2503503.638</gml:posList>
</gml:LineString>
‧ 3D-GIS 幾何資料儲存方式範例(其中一面)：
<gml:surfaceMember>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>324979.35154554225 2771114.7916486156 1.02 324979.0284409111 2771110.0890711015 1.02 324986.2633165384 2771109.615653229 1.02 324986.5864211696 2771114.318230743 1.02 324979.35154554225 2771114.7916486156 1.02</gml:posList>
</gml:LinearRing>
</gml:exterior>
<gml:interior>
<gml:LinearRing>
<gml:posList>324980.3603443318 2771113.599332306 1.02 324980.14799262735 2771110.5086915214 1.02 324979.0707697747 2771110.5791801624 1.02 324979.2831214792 2771113.669820947 1.02 324980.3603443318 2771113.599332306 1.02</gml:posList>
</gml:LinearRing>
</gml:interior>
<gml:interior>
<gml:LinearRing>
<gml:posList>324985.1885801002 2771112.573594863 1.02 324985.23643459566 2771113.270085884 1.02 324986.30016849574 2771113.2004798995 1.02 324986.2523140003 2771112.503988879 1.02 324985.1885801002 2771112.573594863 1.02</gml:posList>
</gml:LinearRing>
</gml:interior>
<gml:interior>
<gml:LinearRing>
<gml:posList>324981.34982410714 2771110.4261291386 1.02 324981.4799282905 2771112.3197108083 1.02 324982.54557665106 2771112.2499795505 1.02 324982.4154724677 2771110.3563978802 1.02 324981.34982410714 2771110.4261291386 1.02</gml:posList>
</gml:LinearRing>
</gml:interior>
</gml:Polygon>
</gml:surfaceMember>
因此，在 3D-GIS 領域，深度、管徑、寬度、高度等資料都可以以幾何的 方式儲存，不必須再記入屬性資料內就可以進行空間碰撞的演算。當然若需 提供檢閱者方便，仍可以將深度、管徑、寬度、高度等資訊保留在屬性資料 中。
78
準即可進行銜接。COBie 為國際上現有之通用資訊交換標準格式，COBie (Construction Operation Building Information Exchange)，是由美國陸軍工兵單 位於 2007 年公佈的資訊交換標準格式，由 Bill East 博士主銜，其被視為工程 竣工交付到設施營運管理資料交換格式的重要標準，並且同年也納入美國國 家建築資訊標準(US-NBIMS)，而英國基於 COBie 的重要性，也於 2012 年發布「COBie-UK-2012」指引手冊，並於 2014 年頒布「BS 1192-4:2014」規範配套 指引手冊，提供業主於專案導入與實施 COBie 的指引