基于PostGIS的矢量瓦片按需组装技术研究

2021-11-10方登茂张晓平刘梁

城市勘测 2021年5期

方登茂，张晓平，刘梁

(西安市勘察测绘院，陕西西安 710000)

1 引言

伴随互联网和地理信息技术的飞速发展，以制图表达为主的纸质地图已经全面被电子地图替代。早期的电子地图受数据量和计算机性能约束，无法满足电子地图实时在线访问的需求。栅格瓦片的出现，极大地改变了电子地图加载缓慢、效率低下等问题[1]。随着地理空间大数据时代的来临，不同精度、尺度、维度的地理空间数据呈爆炸式增长[2]，传统栅格瓦片作为缓存数据，灵活性不足、交互性差、处理周期长，在海量数据加载和大数据实时可视化方面已无优势可言[3]。Mapbox于2016年推出了全新的矢量瓦片标准，已经被国内外主流的商业软件和开源平台所采用[4]。目前国内学者在矢量瓦片的可视化渲染[5]、索引优化[6]、并行处理[7]、服务应用[8]等方面已经有了较多的研究，但在矢量瓦片数据组织与生产方面并没有太大突破。

《新型基础测绘体系数据库建设试点技术指南》中指出，“一库多能、按需组装”是未来我国地理实体基础时空数据库的建设目标。本研究在当前矢量瓦片相关应用研究的基础上，基于PostGIS空间数据库，提出了一种无须事先创建索引和生产瓦片，通过客户端请求和服务端按需响应的方式实时创建矢量瓦片，简化了矢量瓦片的应用流程，实现了矢量瓦片的实时创建和按需组装，扩展了矢量瓦片的应用方式，可为新型基础测绘数据库建设提供技术参考。

2 Mapbox矢量瓦片解析

2.1 瓦片数据组织

矢量瓦片是矢量数据多尺度表达的一种形式，按照特定的规则对原始矢量数据进行分割，采用分级金字塔的形式进行调用，矢量瓦片格式紧凑、生产效率高、样式可动态编辑，交互性强[9]。区别于栅格瓦片，矢量瓦片以二进制的方式直接存储矢量数据的描述性信息，包含了瓦片范围内矢量的几何编码和属性编码。Mapbox的矢量瓦片(mvt)文件采用Google Protocol Buffers(pbf)进行编码，该编码具有跨平台、易扩展、通用性强等优点，便于数据的高效渲染和快速查询[10]。

2.2 几何与属性编码

Mapbox矢量瓦片(mvt)不存储矢量数据的空间范围和投影等信息，单个mvt文件采用屏幕坐标存储矢量数据的几何信息。瓦片的左上角为坐标系的原点，X轴向右为正，Y轴向下为正。解码器可通过解析一系列指令，按照坐标序列生成几何图形编码。如图1所示为面状信息的图形编码存储，通过MoveTo指令确定屏幕点坐标，通过LineTo指令结合相对位移确定下一节点位置，ClosePath用于闭合图形。

Mapbox矢量瓦片(mvt)的属性数据被编码在矢量要素的一系列标签对象中，标签引用的key值与几何图形中指定的原始key值对应的值一致。对于复杂图形，这种方式可以消除具有相同键和相似值引起的属性冗余，具体原理如图2所示，左侧表示原始矢量数据的GeoJSON格式，右侧为矢量瓦片的属性编码。

图1 Mapbox矢量瓦片的几何编码方式

图2 Mapbox矢量瓦片的属性编码方式

3 矢量瓦片按需组装与渲染

3.1 PostGIS的矢量据存储方式

PostGIS以插件的形式扩展了PostgreSQL数据库对空间数据类型、空间索引和空间函数的支持，将PostgreSQL数据库升级为空间数据库，实现了空间数据的存储、管理和操作。PostGIS以WKB(well-known binary)方式存储和管理矢量数据，WKB格式是WKT(well-known text)格式的二进制表达，WKT(Well-known text)是开放地理空间联盟OGC制定的一种文本标记语言，用于表示矢量几何对象、空间参照系统及空间参照系统之间的转换。如表1表达了矢量数据的WKT和GeoJSON格式。

PostGIS将矢量数据的图形和属性分别以相应的字段存储于Postgresql的表结构中，使矢量数据的图形与属性均可作为数据库字段进行管理和操作。如图3所示为POI点的shapefile数据在数据库表结构中的存储，geom字段表达了矢量数据的图形，以WKB格式存储。

WKT格式和GeoJSON格式对照表1

图3 矢量数据在PostGIS中的存储

3.2 矢量瓦片按需组装流程

Mapbox矢量瓦片采用Web Mercator作为默认投影方式，使用了和Google地图相同的瓦片编号方式，实现了全球不同分辨率和任意范围坐标与实际空间位置的一一对应。以“https：//{address}/{version}/{name}/{z}/{x}/{y}.mvt”为例，该矢量瓦片的请求url主要包含了4个参数：name代表矢量瓦片服务的名称；z代表当前请求数据所在的层级；x代表该层级下瓦片所处的行号；y代表该层级下瓦片所处的列号。遵循以上4个参数，以PostGIS存储的矢量数据为数据源，构建服务端矢量瓦片API，按照客户端的请求按需生产和组装矢量瓦片，并将生成的mvt文件实时返回客户端，具体流程如图4所示：

图4 矢量瓦片按需组装技术流程

(1)矢量瓦片的客户端可支持Web端、桌面端、移动端，采用对应的地图引擎或SDK按照矢量瓦片的服务地址实时请求服务端的API，并接收服务端返回的矢量瓦片数据进行可视化渲染；

(2)服务端接收客户端的请求参数，获取矢量瓦片的服务名、层级、瓦片行号和瓦片列号，结合Google地图的瓦片编号方式和文献[11]，通过z，x和y计算对应瓦片的坐标范围；

(3)服务端按照请求的服务名和瓦片的坐标范围组装检索对应矢量数据的SQL语句。主要是通过瓦片的服务名确定对应的矢量数据表，以瓦片坐标范围作为空间约束，执行空间查询，获取对应瓦片的几何图形和属性信息，并采用PostGIS的ST_AsMvtGeom和ST_AsMVT函数将该瓦片对应的矢量数据转换为Mapbox的mvt格式；

(4)数据库执行SQL查询语句，返回对应的矢量瓦片数据，服务端设置响应标头和状态码，组装mvt格式的二进制流，并向客户端返回矢量瓦片数据。

3.3 矢量瓦片渲染机制

相对于栅格瓦片，矢量瓦片通常由地图引擎在前端进行直接渲染，由特定的渲染描述文件实现矢量数据的可视化。基于WebGL技术，前端地图引擎可以承载海量数据的实时渲染，如图5所示，客户端地图引擎接收服务端返回的二进制矢量瓦片、字体库和样式文件，按样式文件进行配置和读取，保证了各个图层的高效渲染和表达。

图5 矢量瓦片的前端渲染方式

4 实验与分析

本实验采用PostGIS空间数据库存储原始矢量数据，按照矢量瓦片按需组装与渲染的技术流程，基于Node.js开发了矢量瓦片的服务端应用，并通过前端的地图引擎进行调用和可视化渲染，对矢量瓦片按需组装的技术进行了实现和验证。

4.1 实验数据与软硬件环境

本实验以西安市约10 000 km2范围内的建筑物面、道路线和兴趣点作为实验数据，数据总大小为 3.32 GB，数据总记录为498.1万条。将所有矢量数据统一转换至Web Mercator投影坐标系下，建立了对应的数据库表结构，采用PostGIS的Shapefile Import工具将原始Shapefile数据导入PostGIS空间数据库，并配置了相关坐标基准参数，实现了空间数据与属性数据的结构化存储。具体数据信息如表2所示。

本次实验所采用的数据表2

本实验服务器端硬件处理器为Intel(R) Core(TM) i5-4430 CPU 3.00GHz，内存 32 GB，Postgresql数据库版本为v11.7，PostGIS版本为v3.1，Node.js版本为v14.2，前端地图引擎采用Mapbox GL JS v2.2。

4.2 客户端加载分析

为了测试和分析矢量瓦片按需组装的性能，服务端程序以单进程的方式部署，客户端基于Mapbox开发测试页面，实现了不同数据类型矢量瓦片的动态请求、按需组装和实时渲染。具体结果如图6所示：

由于本研究并没有考虑要素综合及数据压缩，原始矢量数据在所有层级下均完全可见，地图层级越小，单个瓦片的矢量要素数据量越大。本实验通过抓取同一地图视角内不同层级下矢量瓦片请求的响应时间，统计了15级～20级下不同图层的平均响应速度和矢量瓦片的平均大小，用于分析矢量瓦片的加载效率。

图6 矢量瓦片按需组装可视化渲染

矢量瓦片响应速度及数据量统计表3

如表3所示，从总体上来看，单进程下矢量瓦片数据响应性能优异，客户端渲染流畅，实时性好，按需组装效率高。在最大缩放级别下，平均响应时间能保证在 300 ms以内，L18级～L20级别下，服务端的响应性能相差不大。随着地图缩放级别的变小，所请求瓦片的数据量变大，矢量瓦片的实时组装性能略有衰减，服务端组装和响应消耗的时间变长，但总体响应速度均在 984 ms以内。实验证明，无论是单图层请求还是多图层的请求，在约500万规模的数据量下，该方法的按需组装效率完全能够满足日常应用和可视化的要求。