㈠ 蜂鳥視圖的三維地圖引擎與現有的三維地圖引擎相比有何區別
【蜂鳥視圖】室內三維地圖引擎（ FengMap SDK）是蜂鳥視圖基於OpenGL三維技術自主開發的一款功能全面的室內地圖引擎 ， 支持iOS、 Android 、 HTML5和PC多種桌面及移動平台， 具有靈活方便的二次開發介面 ，基於組件的可定製服務， 確保系統的可擴展性。通過調用FengMap SDK介面， 開發者可以快速將功能豐富、 交互性強的室內地圖模塊集成到應用程序中 ， 減少開發成本和開發時間。
功能簡介：
我們所建立的三維地圖引擎是將傳統GIS地圖引擎與三維游戲引擎技術相結合，在滿足日常三維空間分析的功能上，支持單機應用及多用戶大場景下的協同操作展現。簡單實用的物理引擎、高質量的粒子系統、動畫系統、柔和陰影及光照系統。
㈡ cesium 和 Three.js有什麼區別，以及二者與WebGL 的關系
我也想做3D。暫時還在門外，以下僅供參考。
Cesium是國外一個基於JavaScript編寫的使用WebGL的地圖引擎。看到這個問題，第一次知道它。專做地圖的看樣子，類似於jquery之類的，jquery方便快速出網站，cesium方便快速出地圖網站。
Three.js知道一點，是做3D的基礎庫啊，可以做任意的3D的東西。做動畫，做游戲的吧。
WebGL 是一個底層標准吧，它不是一個具體的工程應用。它本身不是javascript的東西，印象中他是專門做圖像圖像的，更關注底層硬體的渲染和性能之類。
我覺得是javascript 在這個WebGL 的繪圖標准上，定義了canvas， 熟悉不，canvas的各種繪圖標准應該是參考的這個標准。Canvas 提供了最基本的點線面的繪制，是基本api。然後Three是對canvas的一層封裝，方便更加快速地繪制一個球，一個立方體，然後動起來。
㈢ 蜂鳥視圖所提的三維地圖引擎用的什麼底層技術是如何實現跨平台的展現的
蜂鳥視圖所建立的三維地圖引擎是將傳統GIS地圖引擎與三維游戲引擎技術相結合，在滿足日常三維空間分析的功能上，支持單機應用及多用戶大場景下的協同操作展現。簡單實用的物理引擎、高質量的粒子系統、動畫系統、柔和陰影及光照系統。
引擎底層使用C++技術基於OpenGL及相應的WebGL、OpenGL ES 技術進行定製裁剪。應用層使用C#、Java、JavaScript語言對於不同系統平台進行封裝，確保保證外部介面的統一性，並使其可運行在電腦端、網頁端、手機端、以及HTML5的公眾號內。所採用的GLTF三維數據格式是國際標准格式，滿足VR及室內定位技術的對接展現。
㈣ 蜂鳥視圖的室內三維地圖引擎是如何實現跨平台的展現的
【蜂鳥視圖】FENGMAP室內三維地圖引擎底層使用C++技術，保證引擎的高效、穩定性。基於OpenGL及相應的WebGL、OpenGL ES 技術進行定製裁剪。應用層使用C#、Java、JavaScript語言對於不同系統平台進行封裝，最大程度上保證外部介面的統一性，並使其可運行在電腦端、網頁端、手機端、以及HTML5的公眾號內。所採用的GLTF三維數據格式是國際最新標准格式。已滿足VR及室內定位技術的對接展現。
㈤ 從零打造一個Web地圖引擎
說到地圖，大家一定很熟悉，平時應該都使用過網路地圖、高德地圖、騰訊地圖等，如果涉及到地圖相關的開發需求，也有很多選擇，比如前面的幾個地圖都會提供一套 js API ，此外也有一些開源地圖框架可以使用，比如 OpenLayers 、 Leaflet 等。
那麼大家有沒有想過這些地圖是怎麼渲染出來的呢，為什麼根據一個經緯度就能顯示對應的地圖呢，不知道沒關系，本文會帶各位從零實現一個簡單的地圖引擎，來幫助大家了解 GIS 基礎知識及 Web 地圖的實現原理。
首先我們去高德地圖上選個經緯度，作為我們後期的地圖中心點，打開 高德坐標拾取 工具，隨便選擇一個點：
筆者選擇了杭州的雷峰塔，經緯度為： [120.148732,30.231006] 。
地圖瓦片我們使用高德的在線瓦片，地址如下：
目前各大地圖廠商的瓦片服務遵循的規則是有不同的：
谷歌和 TMS 的瓦片區別可以通過該地址可視化的查看： 地圖瓦片 。
雖然規范不同，但原理基本是一致的，都是把地球投影成一個巨大的正方形世界平面圖，然後按照四叉樹進行分層切割，比如第一層，只有一張瓦片，顯示整個世界的信息，所以基本只能看到洲和海的名稱和邊界線，第二層，切割成四張瓦片，顯示信息稍微多了一點，以此類推，就像一個金字塔一樣，底層解析度最高，顯示的細節最多，瓦片數也最多，頂層解析度最低，顯示的信息很少，瓦片數量相對也最少：
每一層的瓦片數量計算公式：
十八層就需要 68719476736 張瓦片，所以一套地圖瓦片整體數量是非常龐大的。
瓦片切好以後，通過行列號和縮放層級來保存，所以可以看到瓦片地址中有三個變數： x 、 y 、 z
通過這三個變數就可以定位到一張瓦片，比如下面這個地址，行號為 109280 ，列號為 53979 ，縮放層級為 17 ：
對應的瓦片為：
關於瓦片的更多信息可以閱讀 瓦片地圖原理 。
高德地圖使用的是 GCJ-02坐標系 ，也稱火星坐標系，由中國國家測繪局在02年發布，是在GPS坐標（ WGS-84 坐標系）基礎上經加密後而來，也就是增加了非線性的偏移，讓你摸不準真實位置，為了國家安全，國內地圖服務商都需要使用 GCJ-02坐標系 。
WGS-84 坐標系是國際通用的標准， EPSG 編號為 EPSG:4326 ，通常GPS設備獲取到的原始經緯度和國外的地圖廠商使用的都是 WGS-84 坐標系。
這兩種坐標系都是地理坐標系，球面坐標，單位為 度 ，這種坐標方便在地球上定位，但是不方便展示和進行面積距離計算，我們印象中的地圖都是平面的，所以就有了另外一種平面坐標系，平面坐標系是通過投影的方式從地理坐標系中轉換過來，所以也稱為投影坐標系，通常單位為 米 ，投影坐標系根據投影方式的不同存在多種，在 Web 開發的場景里通常使用的是 Web墨卡托投影 ，編號為 EPSG:3857 ，它基於 墨卡托投影 ，把 WGS-84 坐標系投影成正方形：
這是通過舍棄了南北 85.051129緯度 以上的地區實現的，因為它是正方形，所以一個大的正方形可以很方便的被分割為更小的正方形。
坐標系更詳細的信息可參考 GIS之坐標系統 ， EPSG:3857 的詳細信息可參考 EPSG:3857 。
上一節里我們簡單介紹了一下坐標系，按照 Web 地圖的標准，我們的地圖引擎也選擇支持 EPSG:3857 投影，但是我們通過高德工具獲取到的是火星坐標系的經緯度坐標，所以第一步要把經緯度坐標轉換為 Web墨卡托 投影坐標，這里為了簡單，先直接把火星坐標當做 WGS-84 坐標，後面再來看這個問題。
轉換方法網上一搜就有：
3857 坐標有了，它的單位是 米 ，那麼怎麼轉換成瓦片的行列號呢，這就涉及到 解析度 的概念了，即地圖上一像素代表實際多少米，解析度如果能從地圖廠商的文檔里獲取是最好的，如果找不到，也可以簡單計算一下（如果使用計算出來的也不行，那就只能求助搜索引擎了），我們知道地球半徑是 6378137 米， 3857 坐標系把地球當做正圓球體來處理，所以可以算出地球周長，投影是貼著地球赤道的：
所以投影成正方形的世界平面圖後的邊長代表的就是地球的周長，前面我們也知道了每一層級的瓦片數量的計算方式，而一張瓦片的大小一般是 256*256 像素，所以用地球周長除以展開後的世界平面圖的邊長就知道了地圖上每像素代表實際多少米：
地球周長算出來是 40075016.68557849 ，可以看到 OpenLayers 就是這么計算的：
3857 坐標的單位是 米 ，那麼把坐標除以解析度就可以得到對應的像素坐標，再除以 256 ，就可以得到瓦片的行列號：
函數如下：
接下來我們把層級固定為 17 ，那麼解析度 resolution 就是 1.194328566955879 ，雷峰塔的經緯度轉成 3857 的坐標為： [13374895.665697495, 3533278.205310311] ，使用上面的函數計算出來行列號為： [43744, 11556] ，我們把這幾個數據代入瓦片的地址里進行訪問：
一片空白，這是為啥呢，其實是因為原點不一樣， 4326 和 3857 坐標系的原點在赤道和本初子午線相交點，非洲邊上的海里，而瓦片的原點在左上角：
再來看下圖會更容易理解：
3857 坐標系的原點相當於在世界平面圖的中間，向右為 x 軸正方向，向上為 y 軸正方向，而瓦片地圖的原點在左上角，所以我們需要根據圖上【綠色虛線】的距離計算出【橙色實線】的距離，這也很簡單，水平坐標就是水平綠色虛線的長度加上世界平面圖的一半，垂直坐標就是世界平面圖的一半減去垂直綠色虛線的長度，世界平面圖的一半也就是地球周長的一半，修改 getTileRowAndCol 函數：
這次計算出來的瓦片行列號為 [109280, 53979] ，代入瓦片地址：
結果如下：
可以看到雷峰塔出來了。
我們現在能根據一個經緯度找到對應的瓦片，但是這還不夠，我們的目標是要能在瀏覽器上顯示出來，這就需要解決兩個問題，一個是載入多少塊瓦片，二是計算每一塊瓦片的顯示位置。
渲染瓦片我們使用 canvas 畫布，模板如下：
地圖畫布容器 map 的大小我們很容易獲取：
地圖中心點我們設在畫布中間，另外中心點的經緯度 center 和縮放層級 zoom 因為都是我們自己設定的，所以也是已知的，那麼我們可以計算出中心坐標對應的瓦片：
縮放層級還是設為 17 ，中心點還是使用雷峰塔的經緯度，那麼對應的瓦片行列號前面我們已經計算過了，為 [109280, 53979] 。
中心坐標對應的瓦片行列號知道了，那麼該瓦片左上角在世界平面圖中的像素位置我們也就知道了：
計算出來為 [27975680, 13818624] 。這個坐標怎麼轉換到屏幕上呢，請看下圖：
中心經緯度的瓦片我們計算出來了，瓦片左上角的像素坐標也知道了，然後我們再計算出中心經緯度本身對應的像素坐標，那麼和瓦片左上角的差值就可以計算出來，最後我們把畫布的原點移動到畫布中間（畫布默認原點為左上角，x軸正方向向右，y軸正方向向下），也就是把中心經緯度作為坐標原點，那麼中心瓦片的顯示位置就是這個差值。
補充一下將經緯度轉換成像素的方法：
計算中心經緯度對應的像素坐標：
計算差值：
最後通過 canvas 來把中心瓦片渲染出來：
這里先來看看 getTileUrl 方法的實現：
這里隨機了四個子域： webrd01 、 webrd02 、 webrd03 、 webrd04 ，這是因為瀏覽器對於同一域名同時請求的資源是有數量限制的，而當地圖層級變大後需要載入的瓦片數量會比較多，那麼均勻分散到各個子域下去請求可以更快的渲染出所有瓦片，減少排隊等待時間，基本所有地圖廠商的瓦片服務地址都支持多個子域。
為了方便看到中心點的位置，我們再額外渲染兩條中心輔助線，效果如下：
可以看到中心點確實是雷峰塔，當然這只是渲染了中心瓦片，我們要的是瓦片鋪滿整個畫布，對於其他瓦片我們都可以根據中心瓦片計算出來，比如中心瓦片左邊的一塊，它的計算如下：
所以我們只要計算出中心瓦片四個方向各需要幾塊瓦片，然後用一個雙重循環即可計算出畫布需要的所有瓦片，計算需要的瓦片數量很簡單，請看下圖：
畫布寬高的一半減去中心瓦片占據的空間即可得到該方向剩餘的空間，然後除以瓦片的尺寸就知道需要幾塊瓦片了：
我們把中心瓦片作為原點，坐標為 [0, 0] ，來個雙重循環掃描一遍即可渲染出所有瓦片：
效果如下：
很完美。
拖動可以這么考慮，前面已經實現了渲染指定經緯度的瓦片，當我們按住進行拖動時，可以知道滑鼠滑動的距離，然後把該距離，也就是像素轉換成經緯度的數值，最後我們再更新當前中心點的經緯度，並清空畫布，調用之前的方法重新渲染，不停重繪造成是在移動的視覺假象。
監聽滑鼠相關事件：
在 onMousemove 方法里計算拖動後的中心經緯度及重新渲染畫布：
movementX 和 movementY 屬性能獲取本次和上一次滑鼠事件中的移動值，兼容性不是很好，不過自己計算該值也很簡單，詳細請移步 MDN 。乘以當前解析度把 像素 換算成 米 ，然後把當前中心點經緯度也轉成 3857 的 米 坐標，偏移本次移動的距離，最後再轉回 4326 的經緯度坐標作為更新後的中心點即可。
為什麼 x 是減， y 是加呢，很簡單，我們滑鼠向右和向下移動時距離是正的，相應的地圖會向右或向下移動， 4326 坐標系向右和向上為正方向，那麼地圖向右移動時，中心點顯然是相對來說是向左移了，因為向右為正方向，所以中心點經度方向就是減少了，所以是減去移動的距離，而地圖向下移動，中心點相對來說是向上移了，因為向上為正方向，所以中心點緯度方向就是增加了，所以加上移動的距離。
更新完中心經緯度，然後清空畫布重新繪制：
效果如下：
可以看到已經凌亂了，這是為啥呢，其實是因為圖片載入是一個非同步的過程，我們滑鼠移動過程中，會不斷的計算出要載入的瓦片進行載入，但是可能上一批瓦片還沒載入完成，滑鼠已經移動到新的位置了，又計算出一批新的瓦片進行載入，此時上一批瓦片可能載入完成並渲染出來了，但是這些瓦片有些可能已經被移除畫布，不需要顯示，有些可能還在畫布內，但是使用的還是之前的位置，渲染出來也是不對的，同時新的一批瓦片可能也載入完成並渲染出來，自然導致了最終顯示的錯亂。
知道原因就簡單了，首先我們加個緩存對象，因為在拖動過程中，很多瓦片只是位置變了，不需要重新載入，同一個瓦片載入一次，後續只更新它的位置即可；另外再設置一個對象來記錄當前畫布上應該顯示的瓦片，防止不應該出現的瓦片渲染出來：
因為需要記錄瓦片的位置、載入狀態等信息，我們創建一個瓦片類：
然後修改之前的雙重循環渲染瓦片的邏輯：
效果如下：
可以看到，拖動已經正常了，當然，上述實現還是很粗糙的，需要優化的地方很多，比如：
1.一般會先排個序，優先載入中心瓦片
2.緩存的瓦片越來越多肯定也會影響性能，所以還需要一些清除策略
這些問題有興趣的可以自行思考。
拖動是實時更新中心點經緯度，那麼縮放自然更新縮放層級就行了：
效果如下：
功能是有了，不過效果很一般，因為我們平常使用的地圖縮放都是有一個放大或縮小的過渡動畫，而這個是直接空白然後重新渲染，不仔細看都不知道是放大還是縮小。
所以我們不妨加個過渡效果，當我們滑鼠滾動後，先將畫布放大或縮小，動畫結束後再根據最終的縮放值來渲染需要的瓦片。
畫布默認縮放值為 1 ，放大則在此基礎上乘以 2 倍，縮小則除以 2 ，然後動畫到目標值，動畫期間設置畫布的縮放值及清空畫布，重新繪制畫布上的已有瓦片，達到放大或縮小的視覺效果，動畫結束後再調用 renderTiles 重新渲染最終縮放值需要的瓦片。
效果如下：
雖然效果還是一般，不過至少能看出來是在放大還是縮小。
前面還遺留了一個小問題，即我們把高德工具上選出的經緯度直接當做 4326 經緯度，前面也講過，它們之間是存在偏移的，比如手機 GPS 獲取到的經緯度一般都是 84 坐標，直接在高德地圖顯示，會發現和你實際位置不一樣，所以就需要進行一個轉換，有一些工具可以幫你做些事情，比如 Gcoord 、 coordtransform 等。
上述效果看著比較一般，其實只要在上面的基礎上稍微加一點瓦片的淡出動畫，效果就會好很多，目前一般都是使用 canvas 來渲染 2D 地圖，如果自己實現動畫不太方便，也有一些強大的 canvas 庫可以選擇，筆者最後使用 Konva.js 庫重做了一版，加入了瓦片淡出動畫，最終效果如下：
另外只要搞清楚各個地圖的瓦片規則，就能稍加修改支持更多的地圖瓦片：
具體實現限於篇幅不再展開，有興趣的可以閱讀本文源碼。
本文詳細的介紹了一個簡單的 web 地圖開發過程，上述實現原理僅是筆者的個人思路，不代表 openlayers 等框架的原理，因為筆者也是 GIS 的初學者，所以難免會有問題，或更好的實現，歡迎指出。
在線 demo ： https://wanglin2.github.io/web_map_demo/
完整源碼： https://github.com/wanglin2/web_map_demo
㈥ 3D Web地圖渲染引擎
是一個 實驗性和正在進行 的開源3D地圖渲染引擎。
您可以使用此引擎：
考慮到這一點，我們已經包含了一些模塊，讓您開始使用一些簡單的Web應用程序，這些應用程序可以使用我們的默認樣式顯示地圖
添加three.js和harp.gl你的HTML，並創建一個id畫布map：
初始化地圖：
節點模塊
使用包生成器生成一個簡單的應用程序：
這個存儲庫是一個包含核心組件的monorepo harp.gl，組織在一個yarn workspace。
所有組件都可以獨立使用，並且位於@here子目錄中。
在Node.js中
所有harp.gl模塊均可通過紗線（或npm）安裝：
在瀏覽器中
由於harp.gl包含一組模塊，因此沒有現成的捆綁包。查看有關如何使用工具的信息的示例，例如webpack為瀏覽器創建一個包。
跑：
下載並安裝所有必 需的包並設置工作區。
跑：
發射webpack-dev-server。localhost:8080/在您喜歡的瀏覽器中打開。
跑：
localhost:8080/在您喜歡的瀏覽器中打開以運行測試。
跑：
跑：
記下URL並使用調用測試mocha-webdriver-runner。例：
跑：
它將輸出所有文檔/dist/doc。
更多用法 需要查看官方文檔
您知道哪些好用的網路地圖渲染引擎，歡迎評論分享，共同探討學習