我们平时在讨论地图瓦片的时候,一般默认指的是栅格瓦片(参考https://blog.csdn.net/tzy233/article/details/159862368)。
而矢量瓦片技术(Vector Tiles)由传统栅格瓦片发展而来,核心是解决传统栅格瓦片数据量大、交互性差的痛点。它将地图数据按金字塔层级(多基于Web Mercator投影,参考https://blog.csdn.net/tzy233/article/details/156996224)进行切割,切割逻辑与栅格瓦片保持一致。每个切割片内包含点、线、面等地理要素,以及对应的属性信息,本质上是通过属性描述了当前瓦片范围内的所有地图元素的位置和形状。客户端获取到这些描述信息后,进行实时渲染,从而具备动态样式调整、缩放无损、要素交互查询等核心能力。
至于金字塔层级和切割的内容编号逻辑,则和栅格瓦片保持一致。
若类比Web端显示技术,栅格瓦片对应的是Canvas,矢量瓦片对应的则是SVG。但矢量瓦片的体积仅为同等场景下SVG的10%左右,核心原因是其采用了相对位置编码和二进制序列化方式。
一、栅格瓦片:互联网地图的基础范式
2005年,Google Maps推出瓦片地图技术,确立了Web Mercator投影与金字塔分级切割方案,该方案此后成为互联网地图的事实标准。栅格瓦片的核心逻辑是将大幅地图切割为256×256像素的静态图片,客户端通过拼接这些静态图片,呈现完整的地图画面。
优势
服务端实现简单,仅需完成地图切割、图片存储与分发,开发门槛低、部署成本可控。
局限
-
文件体积大,导致带宽消耗高、存储成本高;
-
仅包含像素数据,无法实现要素级交互(如点击道路查看详情);
-
缩放时易出现模糊、锯齿,影响视觉体验。
应用场景
适用于卫星影像、兼容性要求高的地图,比如现在天地图仅支持栅格瓦片,Mapbox虽然是矢量瓦片的开创者,但所有图层都支持矢量瓦片。
二、矢量瓦片的兴起与发展
移动互联网时代,栅格瓦片在文件体积上的短板愈发凸显,矢量瓦片凭借"存储矢量数据而非像素"的特点快速兴起,其体积可压缩至同等场景下栅格瓦片的千分之一,大幅降低了带宽和存储压力,同时提升了地图交互体验。
发展里程
-
2010年:Google在Android Maps中率先应用矢量地图技术。
-
2013年:Mapbox发布基于Protocol Buffers(PBF)的实验性矢量瓦片格式,并推出Mapbox GL JS(基于WebGL渲染)。
-
2015年前后:Mapbox Vector Tile(MVT)格式正式商用,OpenStreetMap、ESRI、GeoServer等主流地理信息工具广泛跟进,MVT成为行业事实标准(文件后缀为.mvt/.pbf)。
-
2016年:MVT Spec v2.0/v2.1版本发布,进一步规范了矢量瓦片的数据结构和编码标准。
-
后续发展:Cesium(3D地图引擎)、QGIS、ArcGIS等工具全面支持MVT格式;国内SuperMap、腾讯WeMap等地理信息平台也逐步集成MVT规范。
-
行业认可:OGC(开放地理空间信息联盟)将MVT接纳为社区标准;同时MVT融入OGC API体系,支持/tiles/{tileMatrix}/{tileRow}/{tileCol}标准化接口访问,提升了跨平台兼容性。
MVT核心特点
-
编码高效:采用Google Protobuf二进制编码,将地理坐标转为整数偏移量,大幅减少数据存储体积。
-
结构清晰:数据结构分为三层------图层(Layers)→要素(Features)→几何+标签(Tags),层次分明,便于解析。
-
样式灵活:数据与样式分离,客户端(如Mapbox GL)可通过Style JSON文件实现不同样式,无需修改原始矢量数据。
三、矢量瓦片的数据结构
矢量瓦片的核心是结构化的地理数据,其顶层数据结构定义如下:
Tile (顶层)
└── Layer (图层,如 "water", "roads")
├── keys: ["name", "class", "type"] // 属性键字典(存储所有属性名称)
├── values: ["Lake", "river", "main"] // 属性值字典(存储所有属性对应的值)
└── Feature (要素,单个地理对象)
├── type: 1/2/3 (分别对应Point/Line/Polygon,即点/线/面)
├── tags: [0, 0, 1, 2] // 索引对应关系,解读为name="Lake", class="river"
└── geometry: [9, 1136, 6400, ...] // 编码后的坐标命令,描述要素的空间位置
四、二进制序列化原理
MVT矢量瓦片的核心优势之一的是体积小,其关键在于采用Protobuf二进制序列化方式。相比XML、JSON等文本格式,Protobuf的体积更小、解析效率更高。
Protobuf采用变长编码方案,核心思想是:仅编码有值的字段,省略默认值和字段名;对小整数使用少数字节编码,对大整数使用多字节编码,最大限度减少冗余数据。(具体编码细节较为复杂,我也没搞明白)
五、矢量瓦片的局限
相比栅格瓦片,矢量瓦片的技术实现难度显著提升:
-
服务端:切割逻辑更复杂,需先分析当前瓦片范围内包含的各类地理元素(如道路、山丘、建筑等),再按照瓦片边界对这些元素的数据进行剪裁。
-
客户端:需先识别要素类型,完成数据的拼接、解析后再进行实时渲染,对客户端的性能和开发技术要求更高。比如国内外大受欢迎的Leaflet库就不支持MVT,虽然可以通过插件集成,但性能和显示效果都不好。
-
牺牲了可读性:既然是二级制文件,只能借助机器来识别,人类是不可读的。
最后,地图相关文章