首先，先定義一些概念和描述一些事實：
什麼是柵格資料?
柵格資料是指以將二維平面以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的工程師，只是天才地把這些模型恰到好處地融合到了一起，使人們驚訝，原來地理資訊竟然可以如此優雅簡潔地形式展現給世人，並深刻地影響著我們的生活。向偉大的工程師們致敬！
1向量資料渲染很慢2資料量大，載入慢。其實把地圖經過簡化之後，如線面抽稀，點抽稀之後，手機螢幕通常也較小，手機端已經開始用矢量了，如百度地圖。
首先，先定義一些概念和描述一些事實：
什麼是柵格資料?
柵格資料是指以將二維平面以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的工程師，只是天才地把這些模型恰到好處地融合到了一起，使人們驚訝，原來地理資訊竟然可以如此優雅簡潔地形式展現給世人，並深刻地影響著我們的生活。向偉大的工程師們致敬！