Google 地圖原本為什麼不採用矢量地圖渲染，而是下載柵格化圖像然後渲染？

01-05

//呵呵，這個問題真好，激起了我寫長文的慾望呀，哈哈~~

首先，先定義一些概念和描述一些事實：

什麼是柵格數據?

柵格數據是指以將二維平面以cell鑲嵌形式進行分割的數據表達形式。

什麼是矢量數據?

矢量數據是指以基本的體元(primitive)來描述形狀、圖像的數據表達形式。

Google地圖產品線可以細分為以下三個方向：

1. Web地圖

2. 移動設備地圖

3. 地圖API

Google地圖展現的數據可以大致分為兩類：底圖數據(baselayer)和覆蓋物數據(overlay)

關於底圖數據:

1. Google地圖的Web的經典版本的底圖數據是純柵格的

2. Google地圖的Web的WebGL 版本的底圖數據是矢柵結合的

3. Google地圖的移動設備版本：

iOS 上的地圖目前的底圖數據仍然是基於柵格數據

Android 上的谷歌地圖從5.0 開始支持矢柵結合的底圖數據

關於覆蓋物數據:

1. 除了實時路況數據，google其他的覆蓋物數據一直都是以矢量數據形式表達的

關於地圖API:

1. 除了靜態地圖生成API，其他的地圖API服務中涉及到的空間數據幾乎都是以矢量數據形式表達的

------------------------------------------------------------------------------------

然後，我想說一下為什麼google在各類數據上分別選擇了不同的數據格式?

1. 為什麼最初的底圖使用的是柵格數據，更準確地說，基於金字塔結構的柵格數據？

說實話，tile真是一個偉大的東西，它直接秒殺了GIS界的那些學究們。當OGC委員會的大爺們還在為所謂的WMS服務如何才能夠支持更多的空間語義而在推出一版又一版更加複雜的標準時，Google Maps證明了tile是一個非常簡潔的方案來為公眾提供基礎地理信息服務。它的優點有：

1. 兼容性極強，對於瀏覽器而言，只需要能夠顯示圖片、支持css、非同步傳輸、DOM和javascript，它就能夠顯示Google Maps

2. 對於伺服器的負載同樣很低，由於地圖都是預先渲染好的，用戶的請求對伺服器來講只有IO代價，而幾乎沒有CPU代價，相比WMS那種需要實時切圖，實時渲染的機制來講，這種設計的負載真得低了太多了。記住：還有內存資料庫可以減少磁碟IO，還有瀏覽器緩存可以減少圖片的請求。

2. 為什麼覆蓋物圖層使用的是矢量數據？

google提供的覆蓋物圖層幾乎都是點圖層和線圖層，雖然理論上它支持多邊形矢量數據的展現，但是在很長的一段時間裡，其實多邊形矢量數據都很少被應用(底圖中的建築輪廓最初是底圖柵格數據的一部分).

常見的點圖層包括關鍵的POI點和泛需求檢索產生的麻點圖

//update:2012-06-19

感謝@Jack Jiang補充，修正一個錯誤，麻點圖是在伺服器端完成渲染，傳回到客戶端的是柵格數據+矢量數據，矢量數據不用於渲染，而是用於實現用戶點選麻點時的交互。

//end of update

常見的線圖層則是駕車路線和公交路線

以上數據的特點是什麼？

1. 數據簡單

2. 需要快速更新

做過地圖渲染引擎的同學應該都了解，底圖渲染是一個非常昂貴的操作，是需要計算很久滴。因此，一般底圖的數據的更新頻率不會特別高，幾個月一次是常態（不是說渲染一次需要幾個月)。而作為面向大眾的互聯網地圖產品，POI信息，路線信息每天都可能發生改變，如果把這些數據放到底圖裡幾個月不更新，恐怕用戶要用口水吐死你的產品嘍。加之POI數據和路線數據格式簡單，所以Google選擇了傳輸矢量數據，在客戶端對其進行渲染，使用VML或者SVG

3. 為什麼說移動設備上使用的是矢柵結合的地圖？

如果大家仔細分析過google地圖的離線地圖數據包的話，應該會發現，其實還是有一些小圖片存在的，這些小圖片幾乎是純色的，但是會包括一些主幹道和國界的數據。

為什麼不走得那麼徹底，直接將所有的數據都用矢量形式表達呢？我認為是工程上的折中，因為對於幾乎純色的圖片，使用柵格的形式並不比矢量表達耗費的存儲大，甚至更小（經過壓縮之後)。那麼，假如說你的手機不是那麼地強勁，以至於不能迅速地把所有矢量數據渲染好，至少你還能夠看到一個半成品的底圖。

那麼，為什麼還要把另外一些底圖數據矢量化呢？

這個其他幾位已經介紹地很多了，總結一下：

1. 減少數據流量，矢量表達在更多情況下更緊湊

2. 更加靈活，使用矢量數據客戶端渲染地方式，軟體可以有更靈活地策略控制圖上所要顯示的要素

3. 支持更快地數據更新，當數據以矢量形式表達後，數據的增刪改都和柵格底圖解耦了，於是，再也不用為修改一個重要地點信息而要重新渲染一大片的數據而憂愁了，數據運維就舒了長長的一口氣。

最後，總結一下，正如google當年發GFS,big table和map reduce那三篇驚世論文時所說的，這些文章中所介紹的，都沒有什麼理論上的創新，只是在工程上的實踐，無論是矢量的理論，還是柵格的理論，異或是矢柵一體化的理論，在學術界都已經孕育了很多年，Google的工程師，只是天才地把這些模型恰到好處地融合到了一起，使人們驚訝，原來地理信息竟然可以如此優雅簡潔地形式展現給世人，並深刻地影響著我們的生活。向偉大的工程師們致敬！

註：

個人看法，歡迎討論

參考資料：

1. http://googlesystem.blogspot.com/2010/12/vector-based-google-maps-for-android.html

這個說來已久。

首先在google地圖出來以前，很少有利用AJAX從後台直接取圖片的，專業GIS人士都是通過客戶端對地理數據進行渲染，這就要強大的客戶端程序的支撐。而地理空間數據的渲染是很耗CPU和內存的，所以如果單純的靠瀏覽器對矢量地圖進行渲染是不現實的。google Map是AJAX的一個經典應用，直接從伺服器端搞到切片，傳輸到客戶端，客戶端僅僅排序展示就行了。總之一句話，瀏覽器實時繪製能力不夠。

上面的情況是Web端的情況，目前移動端在大眾化領域越來越重要，如果手機終端直接下載柵格數據經過app進行展示，那麼毫無疑問要佔用很大SD空間，因為一個北京市的柵格數據大約為100多m，全國的就可想而知了。另外app作為客戶端完全可以實時渲染，所以目前很多圖商都把地理數據搞成json串的形式供app實時渲染。

Google Map 採用瓦片金字塔之前大家都用矢量的，但是要裝 Java 虛擬機，性能和效果都不好，當時的終端能力有限，安裝虛擬機的體驗也很不好。後來 Android 平台，特別是這一年來大家都用矢量，首要原因是 Android 本身是 Java 的，不需要裝插件，而且終端軟硬體能力都能達到當年伺服器渲染的視覺效果。

其它答案基本上都是對的，我只是用自己的話再說下。

我用chrome看了下新版的google maps，新版google maps的web版好像已經是矢量渲染了，求拿到邀請的知友測試、鑒定

不止問題好，回答也TM好啊。

關於柵格渲染的優勢，大家都列出來了，對於不廣泛選擇矢量渲染的原因大體有這些：

1、客戶端（包括Web瀏覽器和移動APP）能獲得矢量數據，即便數據是做過投影、坐標轉換以及加密，也一樣存在泄密的可能，於是會造成商業資源競爭，以及造成國家安全問題；

2、客戶端做矢量渲染的能力各不相同，依賴於瀏覽器的實現以及軟硬體環境，為了保證統一的用戶交互體驗，就要投入很大的人力，尤其是IE6、7這種用戶基礎廣泛的瀏覽器，兼容不那麼容易；

客戶端矢量渲染能帶來個性化的交互體驗，所以在移動端APP以及WebGL中應該有廣泛的前景。

網路帶寬，客戶端渲染需要大量計算。

渲染效率不是主要的問題，地圖客戶端的矢量化是完全可以實現的。即使在2008年，山寨機MT6225平台上（104的主頻，600K內存），矢量地圖都能平滑的瀏覽。

Google難以採用的主要原因應該在於他們期望跨平台的體驗在手機端和瀏覽器端一致。這樣，瀏覽器上的渲染效率將成為瓶頸。

在我國當前的移動網路情況下，確實客戶端矢量地圖在幾年內有它的優勢。以北京的地圖數據為例，矢量數據大約在3.2M左右，但是柵格的大約在130M左右。但是Google的人力成本和國內的類似老虎，高德的人力成本比起來，投入人去做一件這樣的事情，與前面說的一起權衡，可能確實不夠划算。

這個問題其實問的不夠準確，如果單純從問題本身看，答案很簡單：Google當時還沒有發明矢量切片技術（或者說，矢量切片技術不夠成熟），所以推出了矢量地圖柵格化解決方案，也就是近十年來，我們使用的在線電子地圖。

但是客觀的說，當時谷歌推出地圖柵格化技術時，衝擊並徹底改變了當時傳統的瀏覽器端地圖顯示技術。當時瀏覽器端地圖顯示技術的弊端，在這裡我就不再啰嗦了，上面的各位都多多少少已經提到了。在那以後很長一段時間裡，矢量地圖柵格化技術幾乎是在線地圖緩存唯一的技術方案。隨著LBS的發展和應用，在線地圖廠商發現，矢量地圖柵格化技術逐漸顯現出其不足的一面，比如：存儲的數據量太大（因為每一個比例尺級別都要生產瓦片，比例尺越大瓦片數量月大）、網路傳輸帶寬消耗太多、局部區域數據更新麻煩（需要重新生產瓦片並替換伺服器上的瓦片資源，但是客戶端緩存的瓦片怎麼辦呢？）、地圖配色方案單一（一套方案需要生成一套瓦片）等等。於是，又是google公司率先提出了矢量切片的技術，利用客戶端實時渲染解析矢量數據繪製地圖（但是，客觀的說，正式HTML5和Javascript的發展才給了矢量切片技術生存的土壤）。如果對矢量地圖柵格化和矢量地圖切片動態渲染技術感興趣，我們在微信上（微信號：15658809327）繼續聊。

我覺得矢量數據帶來最大的便利就是無級縮放，Google地圖真心用不到

從需求和產品定位，客戶端、移動端技術發展的角度回顧一下：

1. Google map 首先是一個典型的互聯網應用，面向普通客戶。最初的時候功能側重於，基礎地圖顯示，查詢POI，路徑規劃，公交換乘，性能特點是高並發。

傳統的 Web GIS 軟體所有數據都是動態渲染，客戶端瀏覽器發送請求，服務端渲染矢量數據為柵格，再將柵格回傳給客戶端。簡單說，每次放到，縮小，平移都需要服務端渲染矢量數據為柵格，渲染極其耗費服務端資源特別是CPU。所以2002年左右的web gis 應用，客戶接受客戶端響應時間是5秒左右。動態渲染的優勢是，實時渲染，只要數據有更新，可以及時發布，適用於數據量小，更新頻率高的應用。

分析下google map 的主要需求，基礎地圖數據量大，更新頻率低。查詢poi ，路徑規劃，公交換乘只需對查詢結果顯示，客戶端技術即可實現，無需服務端再進行動態渲染。所以對矢量地圖進行預渲染，對google map是一個最好的技術方案。這個技術方案地圖數據預渲染，只是側重快速顯示漂亮地圖。

預渲染的缺點顯而易見，不能獲取地圖對應的圖層以及圖層中的feature，無法實現傳統GIS 的基本空間查詢，比如地圖上點某個街道，獲取街道附近100米內的電線杆。google map 要求客戶，查詢周邊時必須先搜索，比如搜索poi 國貿大廈，或者光華路，而不能直接點街道進行周邊查詢；

2. 移動端googl map，同理，手機端運算很少，主要運算都放在服務端。所以一旦沒有網路信號，完全就不可用。比如去門頭溝玩，google map 完全不能用。

相對來說導航是移動端的特殊應用，必須實現離線地圖，而且必須是矢量數據，所以導航端應用直接是矢量數據。

3. 隨著技術的發展，越來越多的矢量數據可以在客戶端渲染。富客戶端技術，flex，silverlight 極大的豐富了客戶端展現的能力。隨著HTML 5技術的發展，相信客戶端會有更多的矢量數據處理的能力。

Google是注重用戶體驗的公司，我想應該從這個角度說明：

1、Google Maps推出之前，互聯網上已有如Mapquest、Map24、Mappy等地圖應用，但由於這些都是矢量地圖，用戶都需要安裝瀏覽器插件來使用；

2、柵格圖可以做的很漂亮，Google Maps出來後，GIS專業人士都讚歎這種「非傳統方式」帶來的顯示效果，無疑Google做過柵格圖和矢量圖的效果對比；

3、細心的人都發現去年Google Maps手機版已經轉為矢量圖了，矢量圖的微數據量是關鍵，更何況Google的矢量圖效果已經可以和柵格圖媲美了。

google maps新版本已經改為矢量圖了，所以柵格方式只是google從web服務模式延續到客戶端方式的過渡技術。

google採用柵格金字塔瓦片技術最主要解決了互聯網環境中海量並發服務以及瀏覽器兼容性（如採用胖應用applet、flash依賴各自的運行環境）的問題。但這兩點問題對於客戶端來說都不存在，而採用矢量地圖可以獲得的好處有：

1.客戶端離線下載數據總量小，支持離線使用成為現實可能

2.地圖渲染更靈活，地圖平移時本地直接更新標註，用戶體驗好；不需要通過後台就可以支持地圖旋轉（導航圖隨路轉會用到此功能）、偽3D（羅盤）等操作

3.支持本地用戶標註、簡單空間運算

google以非GIS的角度提供了一種可行的方案

最近也在關注這方面內容，上面很多都說web端的谷歌地圖矢量圖層是webgl渲染，但是我在chrome開發者模式下看谷歌中國地圖，矢量地圖還是瓦片方式渲染的啊，難道不同地區不一樣嗎？webgl發展這麼快了，切圖什麼的，也應該逐漸退出歷史舞台了吧@羅皓@鄭傑

就矢量地圖渲染來說，在移動端作矢量渲染開銷確實比較大，但如果優化得好，一樣可以作到效率很高，像UCMap這個GIS平台就作到了離線矢量地圖高效渲染，用戶體驗跟柵格瓦片地圖不相上下，而且矢量圖還能無級縮放、還能本地編輯分析地圖；其他平台都達不到這樣的效率，所以，很多平台就只能採用柵格瓦片圖，使用他們的矢量圖，用戶體驗都不好

PC這樣搞應該是為了兼容性和節省系統資源。手機上矢量是為省流量

我覺得最簡單的原因是，矢量圖是可以無限放大而不變形的。但是地圖的輸入設備即照相機是沒法完成這一要求的，而且也沒有必要。