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

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

什麼是柵格數據?

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

什麼是矢量數據?

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

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

1. Web地圖

2. 移動設備地圖

3. 地圖API

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

關於底圖數據:

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

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

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

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

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

關於覆蓋物數據:

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

關於地圖API:

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

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

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

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

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

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

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

常見的點圖層包括關鍵的POI點和泛需求檢索產生的麻點圖，麻點圖是在伺服器端完成渲染，傳回到客戶端的是柵格數據+矢量數據，矢量數據不用於渲染，而是用於實現用戶點選麻點時的交互。

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

以上數據的特點是什麼？

1. 數據簡單

2. 需要快速更新

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

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

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

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

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

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

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

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

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

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