Google 地图为什么不采用矢量地图渲染的方式，而是下载栅格化图像然后渲染的方式？
按票数排序
13 个回答
//呵呵，这个问题真好，激起了我写长文的欲望呀，哈哈~~
首先，先定义一些概念和描述一些事实：
什么是栅格数据?
栅格数据是指以将二维平面以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
首先，先定义一些概念和描述一些事实：
什么是栅格数据?
栅格数据是指以将二维平面以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地图出来以前，很少有利用AJAX从后台直接取图片的，专业GIS人士都是通过客户端对地理数据进行渲染，这就要强大的客户端程序的支撑。而地理空间数据的渲染是很耗CPU和内存的，所以如果单纯的靠浏览器对矢量地图进行渲染是不现实的。google Map是AJAX的一个经典应用，直接从服务器端搞到切片，传输到客户端，客户端仅仅排序展示就行了。总之一句话，浏览器实时绘制能力不够。
上面的情况是Web端的情况，目前移动端在大众化领域越来越重要，如果手机终端直接下载栅格数据经过app进行展示，那么毫无疑问要占用很大SD空间，因为一个北京市的栅格数据大约为100多m，全国的就可想而知了。另外app作为客户端完全可以实时渲染，所以目前很多图商都把地理数据搞成json串的形式供app实时渲染。
以上两位是专业人士，我提供一下我的观察作为佐证。
- 手机客户端，Android上的Google Maps从5.1（应该是这个版本号）开始，就改为矢量化了，配合3D效果，体验非常好；
- 浏览器端，Google Maps采用了更直接的方式：WebGL。你可以认为是一种矢量化的方法。
渲染效率不是主要的问题，地图客户端的矢量化是完全可以实现的。即使在2008年，山寨机MT6225平台上（104的主频，600K内存），矢量地图都能平滑的浏览。
Google难以采用的主要原因应该在于他们期望跨平台的体验在手机端和浏览器端一致。这样，浏览器上的渲染效率将成为瓶颈。
在我国当前的移动网络情况下，确实客户端矢量地图在几年内有它的优势。以北京的地图数据为例，矢量数据大约在3.2M左右，但是栅格的大约在130M左右。但是Google的人力成本和国内的类似老虎，高德的人力成本比起来，投入人去做一件这样的事情，与前面说的一起权衡，可能确实不够划算。
Google难以采用的主要原因应该在于他们期望跨平台的体验在手机端和浏览器端一致。这样，浏览器上的渲染效率将成为瓶颈。
在我国当前的移动网络情况下，确实客户端矢量地图在几年内有它的优势。以北京的地图数据为例，矢量数据大约在3.2M左右，但是栅格的大约在130M左右。但是Google的人力成本和国内的类似老虎，高德的人力成本比起来，投入人去做一件这样的事情，与前面说的一起权衡，可能确实不够划算。
Google Map 采用瓦片金字塔之前大家都用矢量的，但是要装 Java 虚拟机，性能和效果都不好，当时的终端能力有限，安装虚拟机的体验也很不好。后来 Android 平台，特别是这一年来大家都用矢量，首要原因是 Android 本身是 Java 的，不需要装插件，而且终端软硬件能力都能达到当年服务器渲染的视觉效果。
其它答案基本上都是对的，我只是用自己的话再说下。
其它答案基本上都是对的，我只是用自己的话再说下。
Google是注重用户体验的公司，我想应该从这个角度说明：
1、Google Maps推出之前，互联网上已有如Mapquest、Map24、Mappy等地图应用，但由于这些都是矢量地图，用户都需要安装浏览器插件来使用；
2、栅格图可以做的很漂亮，Google Maps出来后，GIS专业人士都赞叹这种“非传统方式”带来的显示效果，无疑Google做过栅格图和矢量图的效果对比；
3、细心的人都发现去年Google Maps手机版已经转为矢量图了，矢量图的微数据量是关键，更何况Google的矢量图效果已经可以和栅格图媲美了。
1、Google Maps推出之前，互联网上已有如Mapquest、Map24、Mappy等地图应用，但由于这些都是矢量地图，用户都需要安装浏览器插件来使用；
2、栅格图可以做的很漂亮，Google Maps出来后，GIS专业人士都赞叹这种“非传统方式”带来的显示效果，无疑Google做过栅格图和矢量图的效果对比；
3、细心的人都发现去年Google Maps手机版已经转为矢量图了，矢量图的微数据量是关键，更何况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技术的发展，相信客户端会有更多的矢量数据处理的能力。
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技术的发展，相信客户端会有更多的矢量数据处理的能力。
dulvyizhihua，Web与GIS迭代体
不止问题好，回答也TM好啊。
关于栅格渲染的优势，大家都列出来了，对于不广泛选择矢量渲染的原因大体有这些：
1、客户端（包括Web浏览器和移动APP）能获得矢量数据，即便数据是做过投影、坐标转换以及加密，也一样存在泄密的可能，于是会造成商业资源竞争，以及造成国家安全问题；
2、客户端做矢量渲染的能力各不相同，依赖于浏览器的实现以及软硬件环境，为了保证统一的用户交互体验，就要投入很大的人力，尤其是IE6、7这种用户基础广泛的浏览器，兼容不那么容易；
客户端矢量渲染能带来个性化的交互体验，所以在移动端APP以及WebGL中应该有广泛的前景。
关于栅格渲染的优势，大家都列出来了，对于不广泛选择矢量渲染的原因大体有这些：
1、客户端（包括Web浏览器和移动APP）能获得矢量数据，即便数据是做过投影、坐标转换以及加密，也一样存在泄密的可能，于是会造成商业资源竞争，以及造成国家安全问题；
2、客户端做矢量渲染的能力各不相同，依赖于浏览器的实现以及软硬件环境，为了保证统一的用户交互体验，就要投入很大的人力，尤其是IE6、7这种用户基础广泛的浏览器，兼容不那么容易；
客户端矢量渲染能带来个性化的交互体验，所以在移动端APP以及WebGL中应该有广泛的前景。
晃晃悠悠，LBS
google maps新版本已经改为矢量图了，所以栅格方式只是google从web服务模式延续到客户端方式的过渡技术。
google采用栅格金字塔瓦片技术最主要解决了互联网环境中海量并发服务以及浏览器兼容性（如采用胖应用applet、flash依赖各自的运行环境）的问题。但这两点问题对于客户端来说都不存在，而采用矢量地图可以获得的好处有：
1.客户端离线下载数据总量小，支持离线使用成为现实可能
2.地图渲染更灵活，地图平移时本地直接更新标注，用户体验好；不需要通过后台就可以支持地图旋转（导航图随路转会用到此功能）、伪3D（罗盘）等操作
3.支持本地用户标注、简单空间运算
google采用栅格金字塔瓦片技术最主要解决了互联网环境中海量并发服务以及浏览器兼容性（如采用胖应用applet、flash依赖各自的运行环境）的问题。但这两点问题对于客户端来说都不存在，而采用矢量地图可以获得的好处有：
1.客户端离线下载数据总量小，支持离线使用成为现实可能
2.地图渲染更灵活，地图平移时本地直接更新标注，用户体验好；不需要通过后台就可以支持地图旋转（导航图随路转会用到此功能）、伪3D（罗盘）等操作
3.支持本地用户标注、简单空间运算
861
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
