探寻电子地图背后的秘密：瓦片技术的原理与实现

不知道大家是否还有电子地图出现以前出行场景的记忆？彼时的出行，对于陌生的路线，我们只能通过问人或者查看纸质地图的人肉方式推进，因此出行之前要搜集信息、查看路线做很多出行前的准备，一些报刊亭甚至还提供收费问路服务。而电子地图应用的出现，极大地方便了我们在出行导航、地址查找等方面的需求，而瓦片技术则是实现电子地图服务的重要技术之一。接下来我们将逐步探寻电子地图背后的秘密，了解地图瓦片技术的原理与实现。

首先让我们先来看看人类发展的过程中，地图是如何一步步从过去的纸质地图模式演进到如今的电子地图模式的。地图的历史可以大致划分为四个阶段：手工制图阶段、数字地图阶段、电子地图阶段和智能地图阶段。从1960年代开始，每个阶段都出现了一些阶段性的标志事件推动了电子地图技术不断发展。

简单了解完地图的主要发展阶段后，让我们把视线集中在从电子地图阶段到智能地图阶段的跃进的千禧年的时代，来看看电子地图应用发展经历了哪些难题，又是怎么逐一解决的。

大概在2000年左右，互联网地图多采用CS架构（客户端/服务器架构） ，客户端安装客户端软件，服务器运行服务端程序。地图使用者需要预先在本地安装客户端软件，再下载保存矢量地图数据（点、线、面数据）的文件才能浏览使用地图，但一张包含世界地物信息的地图数据文件往往很大，想象一下千禧年代的网络环境和基建，可想而知下载文件耗时会很久，而且相关软件的操作也通常需要专业知识才可操作，在设备平台浏览地图不是一件易事。

随着互联网的发展，ajax技术逐渐兴起，也催生了通过浏览器使用地图的需求，BS架构（浏览器/服务器架构） 网页版地图服务随之流行起来。这种方式下用户可以直接通过浏览器查看地图，省去了用户安装客户端软件和下载地图数据的操作，极大地降低了使用电子地图的门槛。

在网页上浏览地图的方式已经很接近当下我们使用电子地图的形态了，那地图应用就此得到大范围的推广了吗？答案是并没有，此时的地图服务商们不得不面临两大难题：

面对这些问题，让我们来看看地图开发商们都提出过哪些主意？1999年，出现了WMS（Web Map Service）这样的解决方案：

虽然WMS大大推进了电子地图的发展进程， 但问题还是存在，WMS根据浏览器视窗大小每次生成一大张图片，对于后端数据渲染能力和网络传输带宽都是挑战，效率仍旧低下。紧接着就有了WMS-C（Cached） 的方案，通过缓存地图瓦片提高效率，但仍没有从根本上解决问题。

较大的地图数据给浏览器、服务器、网络带宽都带来了压力，早期的解决方案大多对硬件设备和网络环境提出了较高的要求。如果没有更好的硬件和网络环境可供选择，那是否可以从数据本身出发，尝试减小地图数据的数据量呢？比如：每次请求的地图数据量小一些，渲染速度和网络传输不就可以应付自如了吗？

最终，在工程实践方面更胜一筹的Google成为这一思想的最佳实践者，2005年Google地图发布，提出并实现了瓦片地图技术，让全球用户轻而易举的享受到了地图应用的福利。Google瓦片地图技术中采用的 墨卡托投影（Web Mecator投影）和 瓦片分级切割方案，也成为目前互联网地图事实上的标准。接下来就让我们逐步了解墨卡托投影和瓦片分级切割方案是如何让地图应用蓬勃发展起来的。

说到墨卡托投影，非地图学专业的读者可能很陌生，但是要说到地图投影，大家就能稍微get到一些方向了。在地图学中，地图投影是一种将地球表面展平的方法，以便制作地图，这就需要一种方法将球面上的点转换为平面上的点。

但是将球体投影到平面上，球面必然会有一定程度的变形，打个比方：吃完橘子🍊后把橘子皮压平，肯定会产生撕裂和变形。根据地图的目的，有些变形是可以接受的，有些则是不可以接受的，因此，为了保留球面的某些性质而牺牲其他性质，就存在不同的地图投影。

五花八门的地图投影方式

一般情况下，由以下三个维度的因素影响投影坐标：

墨卡托投影就是使用一个外切地球赤道的圆柱做正轴投影方向后得到的投影。

墨卡托投影，又称正轴等角圆柱投影，是一种等角的圆柱形地图投影。由荷兰地图学家墨卡托(G.Mercator)于1569年创立，他于这一年发表长202公分、宽124公分以此方式绘制的世界地图。

细心的同学可能会注意到一个问题，墨卡托投影会使面积产生变形，赤道地区变化最小，南北两极的变形最大，但因为在南北回归线之间影响很少，而这是多数航线所在区域，所以被广泛用来编制地图。目前百度地图、高德地图、腾讯地图和Google Maps使用的投影方法都是墨卡托投影。

由于墨卡托投影在高纬度过分放大，低纬度又过分缩小，因此会产生有趣的投影偏差。比如：世界第一大岛高纬度的格陵兰比澳洲看起来还大好几倍，然而实际上格陵兰岛面积(216万平方公里)不足澳洲面积(769万平方公里)的三分之一。

如果使用人脸的来模拟墨卡托投影形变的程度，投影后的脸大概长这个样子😅：

好了，现在我们已经对墨卡托投影有了简单地了解了，接下来我们进一步了解谷歌地图瓦片技术的另一大绝妙方案——瓦片切割方案。

在日常使用电子地图时，我们看到的是一张铺满整个屏幕的大的地图图片。还记得文章开头提到的2000年左右的互联网环境吗？当时的硬件条件和网络传输都无法满足大数据量的地图应用，如果能把这张大的地图图片裁切成多个小的地图图片，那数据的处理量就自然变小了。然后再像拼图🧩一样将小图片拼起来，就能完美地解决地图应用面临的问题了。

实际上，这就是谷歌地图瓦片切割技术方案的具体做法：将大的地图图片切割成多个尺寸相同（通常是256*256像素）的小地图图片，再按照既定规则无缝拼接成大的地图图片，这些小图片就是瓦片。

瓦片：将一定范围内的地图图片按照一定的尺寸和格式裁切成若干行和列的正方形图片，对切片后的正方形图片因为跟屋顶上按序排列的瓦片非常相似，因此它们也被形象的称为瓦片（Tile） 。

上面提到地图中的瓦片需要按瓦片按照如下图所示的金字塔结构组织，每张瓦片都可通过级别、行列号唯一标记。在平移地图、缩放地图时，浏览器根据金字塔规则，计算出所需的瓦片，从瓦片服务器获取并拼接。

由于瓦片是静态的图片，可预先生成，通过缓存和CDN技术，瓦片服务器可提供高效的瓦片读取服务。此外，浏览器并行获取和显示多张小图片，比获取和显示一张大图片要高效的多。显示地图变成和显示图片一样简单，这也是互联网地图能够承载亿级规模用户的原因。

瓦片分层加载体验地址👉 Tiles à la Google Maps: Coordinates, Tile Bounds and Projection | MapTiler

瓦片技术又分为栅格瓦片和矢量瓦片。栅格瓦片就是图片切片，以图片为介质的瓦片打开了互联网地图的大门，互联网地图得以迅速普及。但是，随着地图的移动化和应用的逐渐深入，栅格瓦片至少遇到了两个问题：

受网络带宽开销和存储空间的限制，栅格瓦片地图在移动端一开始就显现出先天不足。这促使在移动端，使用矢量瓦片替代栅格瓦片。矢量瓦片采用和栅格瓦片相同的分级切割方案，所不同的是，瓦片数据以矢量形式存在（为了减少客户端计算量，存储的不是坐标位置而是相对位置）。矢量瓦片体积小，可高度压缩，占用的存储空间比栅格瓦片要小上千倍。一方面减小网络带宽消耗，另一方面使地图离线成为可能。

目前在浏览器端，矢量瓦片也在逐渐成为互联网地图的主流技术。但这并不是说栅格瓦片将退出历史舞台。 互联网地图数据更新不频繁，单个瓦片内需要显示的地物数量和种类有限，矢量瓦片可预先生成，进行局部更新的代价也很小。矢量瓦片并不适合数据更新频繁，数据量大，渲染方式复杂多样的场景。

地理可视化引擎：AntV L7 地理空间数据可视化引擎

瓦片服务资源：国家地理信息公共服务平台_天地图_在线地图

瓦片图层操作：图层的添加与移除-覆盖物与图层管理-示例中心-JS API 2.0 示例 | 高德地图API

贴两张截图给大家增加一些对栅格数据和矢量数据的体感。

下图中黄色区域的边界很不规整，有些像马赛克的形状，那是因为栅格瓦片图层中的数据是arrayBuffer二进制数据，在可视化出来后全部转化成像素点了，你看到的黄色像素点数据是算法同学通过模型识别出来的玉米作物🌽，聚少成多，形成了一个个黄色片区。

下图中红色边界是规整的线条，因为矢量数据的就是由点、线、面构成，无论地图如何缩放，用户看到的都是规整的地理图像元素。

要裁剪地图瓦片，首先需要确定要裁剪的瓦片的范围。假设我们已经确定了裁剪范围的左上角坐标为 (x1, y1)，右下角坐标为 (x2, y2)，则可以按如下方式裁剪：

其中，tileImage 是原始瓦片的 Image 对象。

完整的代码实现如下：

其中，tiles 是原始的瓦片数组，每个元素包含 x、y 和 image 三个属性，分别表示瓦片在地图上的横向和纵向索引以及瓦片的 Image 对象。函数返回裁剪后的瓦片数组，格式与原始瓦片数组相同。