一 引言

作為十年GIS老兵，常常遇到同行或領導的靈魂拷問，“為什么我們不用google地圖啊，我看它的3D很好啊”，“OpenLayers 6支持3D嗎？”，“MapboxGL 2.5D與Cesium的3D優缺點是啥”，“地圖不是球，這不是3D的啊？”，“51 World基于游戲引擎與云渲染技術在可視化領域已經對WebGL形成降維打擊，WebGIS是不是沒前途了？”等等等等。從業人員從技術角度對未來變革的擔憂，領導雖然不懂技術也會從非專業角度表達一些關心，諸如此類問題層出不窮卻又不是三言兩語能講清楚的，所以本文想稍微系統點介紹WebGIS發展歷程、各自特點、未來方向，一家之言僅供讀者參考。

二 地圖API分類

WebGIS系統通常都圍繞地圖進行內容表達，但并不是有地圖就一定是WebGIS，所以有必要討論下基于Web的地圖API分類及應用場景。Web上的Map API主要分類如下5大類：

• Charts：以D3.js，Echarts等為代表。

• LBS：以高德/谷歌/百度地圖等為代表。

• WebGIS商業API：ESRI的ArcGIS API For JS，超圖的IClient。

• WebGIS開源API: Leaflet，OpenLayers，Cesium，MapboxGL等。

Charts類型在各種業務頁面或后臺管理頁面很常見，適用業務場景是地圖非頁面表達的主體，且幾乎沒有交互，頁面中同時還有其他各類主題，示例如下：

charts地圖業務場景

LBS（基于位置的服務）廣泛應用于互聯網類ToC應用，在這個時代人們的衣食住行與這些地圖網站、地圖APP及其背后的地理信息服務日益緊密。LBS必須要在連接互聯網場景中使用，只能使用地圖服務商提供的數據和服務，最多支持自定義用戶標記若干興趣點的簡單操作，2G、2B場景如內網離線，復雜企業級地理數據展示分析等幾乎無能為力。

LBS地圖應用場景

WebGIS通常面向復雜業務場景，通常是內網離線的2G，2B定制化應用。與Charts不同，此類應用以地圖為表達中心，所有的UI都是與地圖交互和聯動為目的；與LBS 2C的單一需求不同，此類應用需要自建空間數據庫與空間數據服務以支撐前端空間數據的維護，復雜的業務交互，個性化的主題可視化等目的。現代WebGIS引擎種類也非常多，都是Html5時代發展的階段性成果，各自也有側重點和合適的業務場景，具體下文闡述。

三 WebGIS發展歷程

WebGIS發展以Html5標準確立為分水嶺分為前H5時代與H5時代，如果以發展的眼光看，當然也有后H5時代。之所以要本節要介紹發展歷程，是因為現代的WebGIS引擎的出身和適用場景與其息息相關。

前H5時代是Flex，JS，Silverlight“三駕馬車”時代，這個時代JS還沒有取得優勢，產品都以Flex為首推，以ArcGIS的Flex API（也有JS版）和開源的OpenScale（openlayer2 是其JS版）為代表，具體不細闡述，主要產品如下圖：

圖片

隨著時代發展，移動互聯網的崛起，H5標準的發布，新的技術變革勢不可擋。在2010年喬布斯宣布iphone不支持Flex后，這項技術就開始了落幕演出，H5技術及其主力語言JS獲得一統前端的地位，很多基于H5標準的WebGIS引擎紛紛入場，WebGIS H5時代開啟，引擎發布大事記如下：

• 2011年3月，WebGL1.0標準發布。

• 2011年5月，Leaflet發布v0.1版本，基于H5草案，只來得及支持Canvas，與WebGL擦肩而過，以后也再沒實現WebGL。

• 2012年底，H5標準發布。

• 2013年中，OpenLayer3測試版發布，與OpenLayer2不同，3是基于H5標準完全重寫的，并不是迭代升級，而是一個全新的產品，只是繼承了Openlayer這個已獲得認可的名稱與產品定位，應該說產品定位繼承的相當徹底且發揚光大，只是過于保守，從而沒能設想進入三維，滿足于自己的二維領域。

• 2013年制定WebGL2.0標準。

• 2014年秋，Cesium發布1.0版本，開源WebGIS引擎進入三維時代。

• 2016年春，ArcGIS API for JS 4.0發布，商業WebGIS引擎進入三維時代。

• 2017年2月，WebGL2.0標準發布。

• 2019年中，MapboxGL發布1.0版本，地圖可視化從功能邁向了性能，顏值等方向，更多人發現原來地圖還可以這樣展示，更多的客戶需要更加個性化的地圖更加舒服的用戶體驗。

• 2020年12月，MapboxGL發布2.0版本，支持三維相機參數，地形，地圖最大傾角從60°到85°等，終于擺脫2.5D的產品印象。

從發展歷程看，總結了如下幾個特點：

• WebGIS引擎與對應的Web技術與標準有較大的時間差。一項Web技術被淘汰，對應基于該技術的引擎就會走向終結，如Flex與Flex GIS引擎的落幕。那么可以設想，是不是WebGL被淘汰，目前所有的引擎都會被淘汰？發展角度看是必然的，并且替代WebGL的WebGPU已經在路上了。

• WebGIS產品設計上的“原罪”，這種引擎層面設計的缺陷和應對場景不足幾乎是難以改變的。如LeafLet發布還沒WebGL標準因此它只實現了Canvas，所以直到今天它也不支持WebGL；Ol發布完全想的是繼承OpenScale（flex)并現代化升級，但是眼光還是不長遠，技術實現上性能優化不足，也沒有引擎層面支持符合三維的MVP矩陣，相機參數等概念，雖然其支持WebGL，但卻沒法把三維和地圖結合起來，只能用于優化二維圖形渲染性能。

四 WebGIS引擎各自特點與適用業務場景

僅作簡要闡述，不再展開細談了。

• LeafLet，Canvas渲染機制，僅支持二維表達，地圖坐標系墨卡托投影，不支持球，特點是入手簡單，缺陷是不支持webgl渲染性能有瓶頸，適用于輕量級簡單地理信息主題可視化。

• OL6，WebGL渲染機制，僅支持二維表達，不限制坐標系，不支持球，特點是二維GIS功能最豐富全面，缺陷地圖樣式簡單，難以定制高顏值的可視化效果，不支持三維，適用于傳統地理信息強GIS的二維數據Web維護和展示，面向公網地圖顏值上有些上不了臺面。

• Cesium，WebGL渲染機制，二三維一體化，經緯度坐標系，支持球，明星數據格式是3DTiles，特點是唯一開源的WebGIS三維引擎，缺陷是卡，體驗差，地圖丑，原因應該是為了支持球，所有的平面瓦片都要進行紋理轉換貼球，計算量偏大，最新的矢量切片也是變成圖片再紋理轉換到球上，柵格化嚴重一點都不精美，可以說為了球，犧牲了太多性能和地圖美觀度，適用于Web強三維應用場景。

• ArcGIS API JS 4，對標Cesium，明星數據格式是I3S，也有類似Cesium的問題，但由于有ArcGIS平臺的體系支持，應該功能最強大，但是如果不采購這個平臺體系，純API很雞肋，適合采購了商業平臺的用戶，如政府采購再定制應用方式。

• MapboxGL，WebGL渲染機制，二三維一體化，墨卡托坐標系，不支持球，明星數據格式是矢量切片，特點是最具美感的專題地圖，缺點是沒有球，最新2.0必須聯網驗證token，適用于互聯網場景復雜地理信息表達，內網追求地圖可視化效果的也適用，Mapbox很多優化都是基于互聯網場景的。

在WebGIS 3D領域，比較有爭議性的是cesium與mapboxgl，簡單來說，兩者都是二三維一體化的GIS引擎，但產品側重點不同 ，Cesium追求的三維功能全面，Mapbox追求用戶體驗：

圖片

對于Cesium的API用戶來說，加載傾斜攝影，點云數據，地形數據都是直接調用引擎API就可以了，即使不懂WebGL也很快能做個三維的地圖樣子，當然高級開發者還會基于WebGL開發自定義高級顯示效果。

對于Mapbox的API用戶來說，2.0版本之前三維不足，主打的二維的矢量切片技術，并且切片加載機制導致傾角太大性能很差，因此引擎限制了最大傾角為60°，看起來就很像2.5D的東西。類似Cesium的三維功能只能依靠Deck.gl等庫去集成，萬幸的是引擎開放了自定義WebGL圖層功能，高級開發者可以定制自己的三維圖層，但坑爹的是沒有三維相機參數需要自己源碼擴展。2.0版本之后新增的地形3D展示，三維開發需要的相機參數，地圖傾角限制從60°改成85°，比較有三維感覺了，效果輔助和性能優化方向考慮的Sky API等，顯示了MapboxGL開始在三維方向發力，但仍然沒有在官方API層面支持傾斜攝影的3Dtiles，點云等，不熟悉WebGL的開發者使用仍然很困難。除此以外，值得警惕的地方是2.0的開源協議從商業友好的BSD-3改成了Mapbox自己的使用協議，無論是否使用Mapbox資源強制進行在線token計數，等于完全放棄了內網用戶（不聯網沒法計數等于沒法用），因此從安全和商業應用開發角度，請不要升級到2.0，保持在1.13版本進行企業定制化開發。

雖然兩者都是二三維引擎，但是如果認真看他們的三維功能都是很少的幾個常用場景，絕大部分業務場景和特效都需要高級開發者定制，也就是說，如果不熟悉WebGL，實際上是很難滿足地理信息可視化的要求的。

總的來說，雖然mapbox更改了使用協議，但不否認它仍是家偉大的公司，在現有的技術體系下，開創性的提出數據用矢量切片技術，圖標用sprite（互聯網應用場景的同學很熟悉，減少網絡請求的優化，合并的圖標紋理減少webgl渲染的調用命令次數），字體用字體pbf切片，就是怎么極致優化怎么做，強大的技術流風格。在此分享下個人用mapbox定制的一些二維，三維應用效果：

矢量切片的時序播放

三維等值面

三維體渲染

五 后H5時代的技術變革

H5時代涌現了很多令人贊嘆的GIS引擎，但是也有很多問題，三維效果差強人意，三維模型又受制于網速，只能說有功能，但難以說有好的功能。隨著用戶對可視化要求越來越高，人們開始思考別的技術方向，例如最近51World搞出了利用C端游戲引擎做GIS，可視化效果通過流媒體傳到前臺顯示的“云渲染”技術，不得不說這是個很投巧的做法，所謂游戲引擎對GIS可視化引擎的降維打擊。

有不少GIS軟文認為云渲染是次時代的GIS可視化技術，我個人認為并不是，51World的做法是業務創新而不是實質技術上的創新，并不會形成技術護城河，隨著專業GIS公司超圖和ESRI的介入很快會失去它目前形成的開創性優勢，也就是“投巧”的技術門檻實在太低。另外一方面，云渲染應用面過于狹窄適合無并發無交互的大屏可視化，不具備應用普適性。

除“云渲染”外，近期WebAssemble和WebGPU是另外兩個值得關注的發展方向，如果我們把時間線后移4，5年，在后H5時代的WebGIS會形成新的三足鼎立：

圖片

以下對三個方向做個技術說明：

• 云渲染

  原理：C端使用游戲引擎做數據可視化，可視化的結果通過視頻流傳到客戶端顯示。

  優點：游戲引擎比較成熟，效果好，三維大量數據，美術資源等不用傳到客戶端。

  缺點：完全放棄日益先進強大的客戶端計算資源（摩爾定律），完全依靠服務器資源，導致服務器資源投入很大，如果有高并發，起碼得有分布式GPU計算引擎吧？所以不可能廣泛應用，業務場景很小，只適合大屏可視化目前。

• WebAssemble

  原理：能讓c++,rust等高性能語言寫的功能以wasm形式在Web端應用，彌補JS性能的缺陷，（經過谷歌V8引擎優化，JS的性能也是直逼后臺，缺陷有點牽強，而且前端計算可以使用GPGPU，WebWork等技術在gpu，在多線程非阻塞計算）當然更主要的用處是有利于原先C端圖形軟件如CAD，GoogleEarth搬到BS上，例如GoogleEarth的BS版已經實現了。

  優點：可以用高性能語言寫的算法應用到前端改進JS的算法（牽強，實際投入產出比不大對絕大部分公司），大量的后端程序員開始進入前端搞事情，前端不再是JS程序員的前端（從性能方向考慮甚至產生是否WebAssemble會取代JS的疑問）。

  缺點：WebAssemble不能操作dom，因此它只是一個補充，給前端留個“后路”而已，并沒有取代JS的能力也沒有這樣的定位。另外業務應用場景非常狹窄，只適合有成熟C端圖形產品搬到BS，對一般業務產品沖擊不大。從公司角度如果沒有C端成熟圖形產品就不值得投入，從程序員個人角度，如果是JS程序員可以直接無視，這種技術不會對你產生任何影響，如果是后端程序員，可以興奮起來，你可以去前端玩玩了。。。

• WebGPU

  原理：下一代Web圖形引擎，WebGL的替代者，業務場景就是現在用WebGL的地方，將來也都是WebGPU應用的場景。

  優點：BS端的圖形引擎與C端幾乎一致（差半代），可以設想很多原先只有C端能做的酷炫效果B端也能做。（WebGL與C端差了好多代了，所以沒法做出能追上C端效果的東西）

  缺點：目前正式標準還沒發布，那么基于WebGPU的圖形，GIS引擎當然也沒有了，就算有了，酷炫效果也不是GIS API這種，更多是圖形學領域，大部分目前的業務API開發者會失去競爭力。

六 思考與建議

從H5時代個人的職業經歷來看，如果不懂圖形學原理，就算使用了WebGL的GIS引擎是做不出符合業務發展的東西來的，頂多加加地形加個建筑做做項目而已，稍微個性化的展示都做不了。從后H5時代來看，一方面可能C++,Rust等技術會更加如魚得水，那么依靠JS的程序員和依靠JS實現可視化的公司只能抱緊WebGPU的大腿，要在圖形學領域持續進行技術投入，純調用API實現效果的時代一去不復返了，更加先進的圖形引擎與更加靈活的渲染管線，再與更加個性化的業務展示要求結合與促進，會產生新的思想膨脹和化學反應，如果個人和公司跟不上，那么在下個時代，才真的是遇到”降維打擊”了。

地理可視化（尤其3D）的未來并不屬于GIS，而是屬于圖形學，所謂萬變不離其宗。。。（首發于微信公眾號：Spatial Data）