Mapbox矢量切片本地化(离线)生成与发布方案

        博主由于在项目中有建立矢量瓦片地图服务的需求,对矢量瓦片进行了相关研究,在此和大家分享我的解决方案。由于项目中矢量数据是需要保密的,因此需要研究出一套开源的本地化(离线)生成与发布的方案。所以利用Mapbox studio进行上传矢量数据并发布这一方案并不适合本项目,另一方面Geoserver2.11版本开始提供矢量瓦片插件,这使Geoserver能够支持矢量瓦片的生成与发布。

       Geoserver生成与发布矢量瓦片的方案操作简单,用户界面友好,本项目初期就利用了这一方案。关于Geoserver矢量瓦片的方案可以直接搜索相关技术博客,已经提供了详细的描述,这里我不再赘述。

       在实际项目当中,博主发现了Geoserver矢量切片方案存在一些较为致命的缺陷。首先,其矢量切片需要在发送地图请求后实时生成矢量瓦片(.pbf),虽然geoserver利用geowebcache进行矢量瓦片的缓存,但其效率依很长时间,然相对较低;若想直接完成各缩放级别的全部矢量瓦片的预生成,需要耗费很长时间,而且由于新版本中geowebcache都内嵌在geoserver当中,博主的项目出现过在矢量瓦片预生成过程中geoserver服务器down掉的情况(geowebcache与geoserver分布式部署的解决方案见博主的另一篇文章https://blog.csdn.net/luochanxiong6435/article/details/79731974)。另外, geoserver对矢量瓦片的管理依然采取类似WMTS栅格瓦片类似的文件系统管理方式,这种方案由于瓦片文件的碎片化而导致管理不够集约,效率较低。最后,由于博主的项目仅仅需要一个矢量瓦片的生成与发布方案,Geoserver相对量级较大,很多功能闲置,也造成服务器端的压力变大。

       考虑到上述问题,博主需要挖掘出另一套轻量的矢量瓦片本地化(离线)生成与发布方案。在经过反复测试与实验,博主选择了一条Tippecanoe + Nodejs的self-hosting矢量瓦片生成与发布方案。其中Tippecanoe是矢量瓦片生成工具,而Nodejs则是将矢量瓦片文件发布为Web服务的后台程序。下面对本方案进行一较为详细的介绍。

 

1.矢量切片综述

       矢量瓦片类似于栅格瓦片，以多层次模型将矢量数据分割成为矢量要素描述性文件存储于服务器端， 在客户端根据指定的样式进行渲染绘图。矢量瓦片与栅格瓦片的不同之处是单个矢量瓦片存储投影在一个四方形区域的几何信息和属性信息，而不是预先渲染的栅格图片。矢量瓦片地图的实现首先需要将矢量数据的几何信息和属性信息分割为一组矢量瓦片存储在服务器端，客户端根据地图显示范围和样式文件定义的数据源通过分布式网络获取矢量瓦片、地图标注字体、图标等数据源， 然后根据样式文件定义的地图表达规则在客户端即时渲染输出地图。

       目前矢量瓦片尚无统一数据标准，Mapbox基于Google protocol buffers制定的开源矢量瓦片数据标准 MAPBOX VECTOR TILE SPECIFICATION，是目前较为通用的矢量瓦片数据标准，已被多个公司和组织采用。早期Mapnik也制定了矢量瓦片数据标准（mapnik-vector-tile）。目前矢量瓦片的格式主要有三种:mvt(pbf)、geojson、topojson,其中压缩率和传输速度最好的是mvt格式,这里也着重介绍这一矢量瓦片格式。

       矢量瓦片技术主要包括三个研究方面:矢量瓦片数据组织、矢量瓦片存储管理和矢量瓦片渲染引擎。其具体细节如下图1所示。

图1.矢量瓦片技术研究综述

1.1   矢量瓦片数据组织

 

1.1.1 瓦片数据集组织模型

        矢量瓦片数据组织可分为两个层次:①瓦片数据集组织模型；②单个瓦片内要素的组织模型。

        矢量瓦片数据集的组织模型类似栅格瓦片金字塔模型,可通过自定义矢量瓦片的大地坐标系、投影方式和瓦片编号方案实现任意精度、任意空间位置与矢量瓦片的对应关系。为了与目前的栅格瓦片相关服务规范（如OGC WMTS等）相兼容以及便于将矢量瓦片转换为栅格瓦片，矢量瓦片一般采用与栅格瓦片相同的投影方式和瓦片编号方式。Mapbox矢量瓦片默认的大地坐标系为 WGS-84(EPSG:4326)，投影方式为球面墨卡托（Web Mercator(EPSG:3857)），瓦片编号采用Google瓦片方案。因此，Mapbox矢量瓦片的大地坐标系、投影坐标系、像素坐标系和瓦片坐标系与栅格瓦片一致。

        为了便于矢量瓦片数据集的网络传输和数据库存储，推荐将矢量瓦片数据集打包生成矢量瓦片包,常用的有ArcGIS矢量瓦片包(VTPK格式)和可存储到 SQLite数据库的MBTiles格式等。其中MBTiles是Mapbox推荐的矢量瓦片数据集格式,其本质上是以数据库的形式对矢量瓦片进行集中式管理,包含有metadata、sqlite_stat1、tiles三个表，name、tile_index两个索引。使用sqlite3可以打开mbtiles数据库直接进行查看,如下图2所示。

 

图2.mbtiles数据库内容组织

1.1.2 单瓦片组织模型

       单个矢量瓦片在逻辑上可以通过图层组织要素信息。每个图层所包含要素的几何信息和属性信息在逻辑上分开存储。以 Mapbox矢量瓦片为例，其逻辑存储 结构是Tile->Layer->geometry& metadata。其中几何要素分为点、线、面和未知要素类。未知要素类是 Mapbox 特意设置的一种要素类型，解码器可以尝试解码未知的要素类型，也可以选择忽略这种要素类型的要素。元数据信息又分为图层属性和要素属性。每块矢量瓦片至少包含一个图层，每个图层至少包含一个要素。

       矢量瓦片的物理模型是瓦片属性信息和位置信息在存储过程中的具体表现形式。描述矢量瓦片属性信息和几何位置信息的文件常有 GeoJson（.json）； TopoJSON（.topojson）和 Google Protocol Buffers (PBF)。 其中GeoJSON是一种基于Javascript对象表示法的地理空间信息数据交换格式,易于阅读，通用性强，大多数软件可以直接打开，但存储地理数据较多时易产生冗余信息。TopoJSON是在GeoJSON基础上对共享边界几何要素拓扑编码,减少冗余信息的一种优化数据格式，被 Mapzen推荐作为矢量瓦片的存储格式。Google Protocol Buffers（PBF）是一种轻便高效的结构化数据存储格式，Mapbox矢量瓦片采用 PBF格式组织单个瓦片内要素的信息,相比GeoJSON格式的矢量瓦片文件体积更小，解析速度更快。

       单个mvt矢量瓦片的组织编码分为几何编码和属性编码两部分,对应矢量数据的空间信息和属性信息。PBF格式的矢量瓦片存储几何信息所用坐标系定义为以瓦片左上角为原点，X 方向向右为正， Y方向向下为正，坐标值以格网数为单位。单个矢量瓦片默认的格网数为4096×4096，即使4K（屏幕分辩率为4096 px×4096px）的高清屏上只显示一张矢量瓦片也不会出现类似于栅格瓦片的锯齿效果。屏幕分辨率越高，可以提供相应的提高瓦片格网数量，以精确记录瓦片内要素的几何位置信息。具体的编码方式如下图3所示。

 

图3.Mapbox矢量瓦片编码方式

1.1   矢量瓦片渲染引擎

        OpenGL、WebGL等客户端图形渲染技术的发展，推动了地图渲染引擎的快速发展。WebGL是一项可以在浏览器中流畅展示