宣告：本文是乙個系列原創（作者在gis+bim行業已有從業15年有餘，還是個行業的小學生，文章內容不免有錯誤或者不當之處，敬請理解），旨在通過這個系列打造乙個高效能，高可擴充套件的gis+bim框架，拋磚引玉，為國內gis+bim行業貢獻綿薄之力。
對於行業內的人說到gis、bim最先想到是：引擎，是的，沒有錯，應該說乙個好的引擎是核心了，放眼國內，做gis的公司很多，做bim的也很多，但原創卻很少，做到行業知名的卻是沒有，說到gis，不得不提我們的祖師（google earth）簡稱ge，隨著ge的推出，引起了行業的大變革，大家都開始做三維地球，最具名氣的應該是open scene graphic,簡稱 osg，確切的說，它是一款面向地理資訊行業的三維引擎，還談不到gis引擎，在osg的基礎上，osgearth算是乙個不錯的開源三維數字地球，也正因為osgearth開源數字地球的出現，為國內gis產業帶來了一次洪流，也可以這麼說，國內大部分三維地球都是基於osgearth發展而來。
然後隨著行業應用的不斷發展，也正式因為數位化地球的成功，很多以前想都不敢想的事情（數位化三維城市），數位化工程管理，數碼化工廠，數位化發電等相繼提出概念模型，而這些數位化資訊處理，對三維數位化地球提出了更好的要求，需要海量的顯示資料，osgearth有些力不從心，我們必須開發新一代三維數位化引擎來適用行業的發展，這也意味著新三維數位化時代到來:gis +bim/pim。
在這股洪流中國內也出現了很多不錯自研bim引擎的公司（筆者接觸過很多款，國外的不提了，別人起步早，沒有可比性，國內能讓我有印象的就兩個，乙個是深圳鵬銳的bim（速度真快，在一般的顯示卡下可以載入300萬個引數化模型，說行業頂尖不為過），另乙個北京達美勝（功能全））。然而都只是bim，或者pim，都缺少地理資訊部分，其他的都是基於osg或者unity3d引擎研發的，unity3d面向遊戲的，用來做bim/pim確實很不適宜，osg本身對顯示卡的新特性支援不好，設計上採用了過多的設計模式，對開發不是很友好，或者說一般的開發者是駕馭不了osg的，面對這種囧境：要想重構osg代價太大，so大牛們更願意自己重寫乙個全新的引擎，無拘無束，說到這裡，會有一部分人說重複造輪子，然後筆者認為任何事物都要經歷認知->熟悉->熟練->重複->改進->創新，沒有重複的過程，就沒有改進和創新（筆者本人就是乙個技術宅男）。
到這裡說到重點了，筆者本人也沒有擺脫這股洪流的衝擊洗禮，依然決定不惜粉身碎骨迎難而上，依然想當那只迎風起飛的豬（雖然當風停下來的時候，摔死的一定是豬），言歸正傳，先上圖，然後在慢慢介紹。
圖1
圖2看到這樣一幅圖形很多人覺得，這個才是gis + bim ，是的，國內已經有部分公司都實現了圖1所架構的部分，圖2部分目前還沒有看到(也許是因為筆者眼界狹窄，亦或者已經有了，但是還沒有公開發布)。圖1 到到圖2這條道路有幾個大坑。
解決大資料精度問題，gis本身是支援大資料的，但是實時性與精度是存在問題，地理資料採用金字塔模型形式進行儲存，大家都知道這樣資料結構儲存形式解決了海量資料的問題，即按需，按級別載入，根據攝像機的位置動態的載入所需的資料，如下圖所示。
圖3（gis）金字塔瓦片
圖4（gis）金字塔瓦片
然後bim資料一般都是比較集中的，對資料要求特別的高,做bim的都知道，一棟樓房每乙個細節表達務必要求精準，方便管理，造價，維護，能夠做到全生命週期管控。
圖５（bim）
圖６（pim）
這不是現有gis系統能完成的工作，如果按照gis的管理方法將模型按照gis的方式進行儲存，會發現bim／pim資料是不能這麼做的。一般乙個bim模型或者pim模型由很多個最小單元（模型）組成，我們稱為基本體，比如一閥門可以由幾十個或者更多基本體組成（多個圓柱，多個圓環，多個長方體，或者多面體），資料量非常的龐大，筆者接觸過最大的模型乙個pim模型（共計９００萬＋個基本體組成），絕大部分是引數化的。
筆者也嘗試過用lod的方式儲存這些資料，用gis的思維方式按需載入，結果是很多業務應用是無解的，下面我們分析下用gis思維方式載入資料我們遇到的問題：
１. 無法做到輕量化
為了降低網路延遲，或者儲存空間，資料一般採用引數化的形式儲存，比如我們要繪製乙個箱子，我們用箱子的引數來描述：類似：ｂｏｘ（長，寬，高，材質，位置），如果做ｌｏｄ，那麼該如何描述呢，我們唯一能做的，是將引數化資料三角化，即生成用模型（點線面來描述），這樣資料量會增加。
２. 資料量巨大
a) 引數化部分，目前大部分gis是不支援，需要在後台增加服務，用來把引數化模型資料三角化，然後在不同的級別做簡化模型）。
b) 計算下來，以２５６萬個基本體為例，正常儲存需要１００m空間，如果做ｌｏｄ，空間至少要４g
３. 更新／發布困難
模型資料不是一成不變的，都是在根據工程的進度或者維護進行實時更新的，那麼這就意味著每當資料更新，lod必須重新做一次，而往往我們希望可以瀏覽不同版本的模型，即要保留歷史資料，這樣一來，就災難了，資料會膨脹。
４. 無法完成精確的測量
因為bim業務的特殊性，對模型的測量上由精確的要求，如果我們做了lod，在計算上就會出現誤差，這是個硬傷，lod的是無法解決這個問題的。
５. 實時性差
每次時間變更都會從伺服器請求大量的模型資料，造成實時性比較差。
６. 編輯要求
一般的業務應用都會存在對模型進行修改的要求（輕量化的）比如對乙個閥門的位置進行修改，或者對乙個桌子的顏色修改，異或更換一把的門鎖。
目前大部分bim不具備這個功能，gis更不用說了，及時具備，gis的離散化資料儲存也做不到實時修改儲存。
圖７（修改前）
圖８（修改後）
７. 操作的便利性
從事設計工作的朋友，習慣了二維的座標下，對模型的編輯，或者三維空間上的操作，但是對於球體上的操作卻不適應，首先這裡要說明下，設計工作不應該在gis上完成，但是還是由少許的輕量化的編輯要求，設計工作者更加希望在非球體下進行（球體是投影，乙個直線也是由曲率的），很不方便，如下圖這樣檢視（也被稱作上帝視角）
圖9（上帝視角）
圖10（上帝視角下編輯）
８. 精度問題
在gis開發，或者bim開發過程中，很多同學都遇到用單精度無法滿足計算的要求，基本上在bim中計算都採用雙精度方式，然後把乙個bim模型放到三維球體上，需要解決到大地座標問題，為了效能方面的考慮，不得不採用單精度繪製(目前不是所有的顯示卡支援雙精度，同時即便支援雙精度)效能由極大的降低。
1 nvidia，雙精度計算花費的時間單精度的32倍
2 ati，雙精度計算花費的時間單精度的8倍
3 intel，雙精度計算花費的時間單精度的4倍
綜上，以上種種（只列舉了部分），總結：新一代gis+ bim引擎需要具備如下功能特點。
１. 支援引數化模型（海量，入門級別，至少支援100萬個引數化模型。
２. 解決資料載入與儲存問題
３. 支援輕量化編輯
４. 支援2d/2.5d /3d 地理資訊形態切換。
今天就到這裡，初次編寫，有沒有說清除的地方，希望大家指出，共同進步。
從無到有，構建GIS BIM大廈
宣告 本文是乙個系列原創 作者在gis bim行業已有從業15年有餘，還是個行業的小學生，文章內容不免有錯誤或者不當之處，敬請理解 旨在通過這個系列打造乙個高效能，高可擴充套件的gis bim框架，拋磚引玉，為國內gis bim行業貢獻綿薄之力。對於行業內的人說到gis bim最先想到是 引擎，是的...
Makefile 從無到有
makefile這玩意在上學時就應該學，可是一直沉浸於ide的 所謂 死於安樂 直到現在一把年紀才開始接觸這種基礎東西。建立c程式 先寫個c程式，儲存在main.c裡 view plain file main.c include int main 看看我這時的目錄結構 view plain code...
Redis從無到有
redis最佳執行環境是linux作業系統，所以要在虛擬機器裡的linux系統裡安裝redis 安裝教程 安裝過程中遇到的問題 1 windosws系統預設是沒開啟虛擬機器功能的，進入bios設定，將相應的disable改為enable 2 license not accept 依次輸入 1,2，c...