11. 矢量瓦片和栅格瓦片的性能测试负载指标的比较研究

摘要

网络地图应用程序的最新发展对背景地图（background maps）的渲染（ rendered）方式产生了广泛影响。栅格瓦片（ Raster tiles）目前被认为是一种常规解决方案，而矢量瓦片（vector tiles）的使用正变得越来越普遍。本文描述了一个测试栅格和矢量瓦片方法的实验。栅格瓦片背后的概念基于预先生成的一个原始数据集，这个数据集包括自定义（customized）的符号系统（symbology）和样式。所有瓦片都是根据标准化方案生成的。这种方法有一些缺点：如果需要对数据集进行任何更改，则必须重做整个瓦片生成过程。矢量瓦片是对矢量对象进行操作。只有矢量几何图形（geometry）存储在服务器上，而符号系统、渲染和定义缩放级别（defining zoom levels run）在客户端运行。这种方法简化了符号系统或拓扑结构的更改。基于八项试验性的（pilot）研究，对加载时间、数据量（data size）和请求的数量进行了性能测试。观察到的结果根据具体的交互（ specific interactions）提供了全面的比较。在缩放和移动交互（ interactions）中，矢量瓦片下载了更多数据，但只多一两个瓦片，而对于相同的交互，光栅瓦片下载了40个瓦片。

关键词

瓦片；网络地图；栅格；矢量；性能测试

1. 简介

1993年，施乐公司（Xerox ）发布了第一张网络地图。这只是一张图像，要与地图交互就必须加载一张具有所需视区（viewport）范围的全新图像。这一原则一直被使用，直到2005年谷歌推出“滑动地图（slippy map）”，这是一种使地图更易于访问和加载更快的新技术。它的原理是将地图图像分割成单独的更小的部分。地图不再是一张图片，而是几张图片无缝（ seamlessly）拼接在一起。与地图的交互只需要加载和显示地图的必要部分，而不是整个图片。这些图片被称为栅格瓦片，所有主要的地图应用程序和软件库都采用了谷歌的方法。

自2005年以来，尽管瓦片Web地图技术仍以几乎相同的形式使用，但是Web应用程序发生了重大变化。瓦片格式已经进行了根据需求生成瓦片，并更改瓦片的大小和分辨率（ resolution）的实验，但是，此后这些方法没有发生任何重大变化。今天的用户需求与14年前的需求大不相同。今天，地图需要动态、流畅、快速和交互的属性。一个潜在的解决方案是矢量图块，它仍然采用将地图划分为正方形的原理，但加载的是矢量对象而不是图像。然后可以使用JavaScript操作地图上的所有对象，可以查询，可以更改其符号系统等等。虽然基于栅格的应用程序是当今事实上的标准，但矢量瓦片正成为一种更流行的解决方案。例如，谷歌

地图和Mapbox等主要网络地图服务已经开始从栅格瓦片迁移到矢量技术，尽管许多其他地图服务仍然依赖于栅格瓦片，通常在卫星或航空底图中（包括全球知名门户网站，如BingMaps、ArcGISOnline、mapy.cz等），其中许多源自OpenStreetMap（例如，Mapnik、Stamen、Positron、OpenTopoMap等）、Esri的底图图层（WorldStreetMap、DeLorme、WorldTopoMap等）、国家和区域地图服务（例如，捷克地籍办公室）或用于本地目的的自定义生成数据。 LeafletProviders概述了数十种栅格底图。

这项工作比较了栅格和矢量瓦片的性能。该实验的主要目的是比较侧重于服务器端和网络测试的不同负载指标。测试使用八项试验性的研究来衡量四个可衡量指标和一个不可衡量指标的应用程序性能。该研究旨在回答加载矢量瓦片是否比栅格瓦片更快，以及性能上的任何差异是否是所选方法导致的。性能测试和获得的结果使我们能够从理论和实践的角度对这些方法进行全面比较。结果可以帮助开发人员选择将栅格或矢量瓦片地图方法应用于应用程序。

2. 地图瓦片

Goodchild在网络地图（web maps）几乎不被应用的情况下提出了地图瓦片的概念。将瓦片与仅在大比例地图（a large-scale map sheet）上显示选定区域的旅游地图系统进行了比较。每个额外的区域都位于不同的地图（sheets）上，如果用户需要组合地图以创建具有更大区域的地图，他们必须并排放置地图。该系统与当今的地图瓦片技术非常相似。网络地图的开发始于1993年，将图像放到网络上变成了可能。最初的网络地图通常只是上传到服务器上的扫描图像。1993年，施乐帕洛阿尔托研究中心首次创建了用户生成的交互式地图，但每次查询服务器时都会重新生成地图。该技术也应用在MapQuest的网络地图中，它是1996年至2009年最流行的网络地图。2005年，谷歌推出了基于滑动地图技术的谷歌地图。这项技术包括提前生成地图瓦片，并且仅在用户请求时显示预先生成的瓦片，而不是整个地图。缩放地图时仅下载最初显示的瓦片以外的瓦片。此后，该技术已被大多数Web地图服务采用。 Sample et al, Jiang et al, and Veenendaal 等人 描述了地理门户（geoportals ）和底图的现状。 Zalipnys or Villar-Cano等人对栅格模块的实施进行了案例研究， 而Xiaochuang, Wan et al, Zouhar et al, or Li 等人结合大数据对矢量数据进行案例研究。

2.1 栅格瓦片

要创建栅格瓦片地图，必须将所需区域划分为多个部分。当加载地图瓦片图层以从不同的服务（services）中查看时，用户通常不会感知数据是如何存储的，因为这些差异发生在后台。每个瓦片集都有一个定义的数据存储方案。Yang 等人将方案描述为具有多个参数，例如像素大小、瓦片形状和大小、坐标（coordinate）系原点、瓦片矩阵大小和缩放(zoom)级别数。

Stefanakis 也提到了地图坐标系作为一个重要参数。今天几乎所有的web地图都使用韦伯墨卡托（WebMercator）坐标系(EPSG:3857)，它由Google创建并修改了原始的Mercator投影系统。在这个坐标系下，通过去除极地区域，世界地图可以显示为一个正方形。这个正方形是瓦片地图中的一个关键特征，用作零缩放级别的瓦片。每个额外的缩放级别都是通过将前一个瓦片分成四个瓦片来创建的。各个方案之间的主要区别在于它们的坐标系原点和瓦片编号。谷歌用一对X和Y坐标命名它的瓦片（图1a）。要获得选定的图块，还必须知道其坐标和缩放级别，因为每个额外的缩放级别都以坐标为0,0的图块开始。编号从左上角开始。第二个最常用的图块编号系统（例如，由BingMaps实现；图1b）也将原点放在这一点上，但使用四叉树算法（Quadtree algorithm）来命名每个图块。每个新的缩放级别都会保留瓦片编号，并在下一个位置添加0–3之间的数字。第一个缩放级别中的图块表示为0，下一个缩放级别中的四个图块表示为00、01、02和03。开放地理空间联盟(OGC)定义了栅格切片的Web地图切片服务(WMTS)标准。

Zavadil写道：Web服务最常使用256×256像素的瓦片大小。64×64和512×512像素的不太常见的瓦片尺寸也在使用。 Peterson估计存储一张256×256像素的单个瓦片地图的平均内存需求是15KB。使用20个缩放级别的瓦片总数约为1万亿，即大约20,480TB的数据。栅格瓦片必须为每个缩放分别生成，并且每个缩放级别的瓦片数量增加四倍。

允许服务器端地图生成保存结果以供将来使用（不是直接在接收到查询之后）的技术称为缓存。然后，Web服务器可以立即将结果传递给客户端，而无需服务器执行请求的操作。缓存可减少对地理信息系统(GIS)和数据库服务器的需求，并加快地图工作。通常为不经常更改的地图（街道网络、正射影像、测高图）创建缓存，而对于频繁更改的地图，缓存会定期更新。还可以为浏览器创建缓存，以允许重新使用已经从服务器下载的内容，而无需再次下载内容，从而减少服务器占用空间并提高网速。

栅格瓦片符号系统是在瓦片生成之前创建的。对符号的任何修改都需要重新生成整个瓦片集，这是栅格地图瓦片的主要缺点之一。如果提供Web地图瓦片服务，用户可以定义自定义符号系统以便使用GetMap进行渲染。这是使用标准化样式图层描述符(SLD)和符号系统编码(SE)服务来完成的，方法是创建XML格式的文档，通过该文档，显示的图层可以根据符号系统编码标准与文档中描述的符号系统配对。

2.2 矢量瓦片

尽管栅格瓦片地图在21世纪初是一个革命性的想法，但它现在有许多缺点，通常是由于每次数据、几何结构或符号系统发生变化时都需要生成一整套瓦片。栅格瓦片地图也不允许用户与网络地图进行交互。

矢量瓦片地图比光栅瓦片更新，由谷歌首创，于2010年在移动版谷歌地图中实施，然后在2013年再次在网络版中实施。通常，矢量瓦片不显示图像，而是显示存储在服务器端的矢量对象给用户。矢量数据只是由其vertex points表示的点、线和多边形，不包含任何用于渲染的信息。

矢量瓦片模式与栅格瓦片模式相同，将原始矢量数据集划分为瓦片网格（图2），每个网格对应于瓦片显示的数据。如果一个矢量对象属于多个瓦片，则该对象被分割，每个部分显示在不同的瓦片上。客户端仅显示其感兴趣区域中的数据。图2说明了根据Gaffuri的瓦片生成过程。

与栅格瓦片一样，将数据集拆分为瓦片后，仅传输客户端所需的数据。瓦片也必须根据特定的方案命名。大多数矢量瓦片应用程序使用GoogleXYZ方案。矢量瓦片的编号方式与栅格等效项完全相同。例如，在第8列和第4行的缩放级别为4时，切片的栅格编号为4/8/4.png，矢量的编号为4/8/4.geojson。虽然矢量切片允许缩放级别（例如缩放8.5）的渐进式（小数的）增加，但光栅切片仅针对每个增量缩放级别（例如缩放8或9等）生成。

根据Netek等人的说法，最常用的格式是GeoJSON、TopoJSON和MapboxVectorTile(mvt)。GeoJSON格式基于JSON（JavaScriptObjectNotation），它是一种通用数据格式，将数据存储为点、线、多边形、多点、多线、多多边形和几何集合。它结构简单，独立于使用的平台。TopoJSON是GeoJSON的拓扑扩展，将所有对象的几何图形存储在一起，而不是单独存储。

这减少了数据量，因为几何图形的每个部分只保存一次，并且每个对象都引用几何图形。以这种方式，数据量最多可以减少80%。

MapboxVectorTile是一种基于GoogleProto[colBuffers]的开放格式，它是一种独立于语言和平台的结构化数据序列化机制。使用WebMercator坐标系(EPSG:3857)根据Google方案排列瓦片。2015年，Esri还宣布支持MapboxVectorTile。每个对象的几何图形都相对于每个瓦片的原点进行存储。对象可以拥有以下几何图形：未知、点、多点、线串、多重线、多边形或多重多边形。

更改符号系统是矢量瓦片的主要优势。客户端可以请求更改地图上显示的矢量数据的样式。样式始终包含对要渲染的数据的引用和渲染规则。以下几个标准和规范定义了符号系统的创建方式和随后在地图数据中的应用方式：

• Mapbox GL样式——其他服务的开放标准。由Mapbox创建为mvt格式的符号系统。样式存储为一个JSON对象，具有特定的根元素和属性（properties）。符号系统使用可视化编辑器（MapboxStudio样式编辑器tnik）或通过JSON文件编辑。

• CartoCSS——由Mapbox于2010年开发，作为MapboxGLStyles的前身。它与网页的层叠（Cascading）样式表(CSS)非常相似。目前由Carto的TileMill使用。

• 地理样式表——最早的规范之一，在卡塔根项目中使用。类似于CSS，但从未在主要库中建立。

• MapCSS——用于对来自OpenStreetMap(OSM)的数据进行样式设置的开放规范，同样基于CSS。它使用来自OSM的标签（严格）。

3. 试验研究的部署

3.1 数据和前端接口

试验研究证明了地图数据作为栅格或矢量瓦片的潜在用途。有地图应用程序（在前端）都使用MapboxGLJS库。只有三个地图库完全支持矢量和栅格瓦片的可视化：OpenLayersv3、MapboxGL和Esri的ArcGISAPIforJS。因为Esri的解决方案实施起来更复杂，并且在其学术许可下可能有一些法律限制，所以OpenLayers和Mapbox具有可比性。作者使用Mapbox是因为它有更好的文档，但除此之外，所有应用程序的用户界面(UI)和数据集都是相同的（图3）。前端界面在右上角包含基本的地图控件（放大/缩小、方向和全屏按钮），在左上角包含四个交互步骤的四个项目（参见第4.1节），在右下角和当前缩放级别指示器。在右下角是一个比例尺和一个当前缩放级别指示器。然而，后端技术和数据存储有很大不同。该数据集包含三层：来自OpenMapTiles(OMT)项目的捷克共和国瓦片你图层、捷克共和国市政边界图层和机场图层（来源OpenStreetMap）。选择数据是为了涵盖所有三个级别的范围：国家（OMT）、区域（边界）和地方（机场）。创建了八个应用程序（表1）。使用了三种不同的服务器数据存储主机（MapboxStudio Web应用程序托管、Wedos商业托管、亚马逊网络服务EC2云）。栅格瓦片以两种不同的文件格式（PNG和WebP）创建。其中两个栅格瓦片应用程序使用主机存储的预生成瓦片，另外两个应用程序根据请求从矢量数据生成栅格瓦片。

3.2 基于MapboxStudio的试验研究

MapboxStudio是一个Web应用程序，用于使用矢量或栅格瓦片创建地图，并使用新的MapboxGLStyles开放标准来绘制地图样式。MapboxStudio包含三个部分：样式、瓦片集（矢量或栅格瓦片的集合）和数据集（特征及其属性的集合）。基本的默认地图数据也可从Mapbox获得。要使用自定义数据集，可以使用一种受支持的格式创建或上传数据。然后这些数据在编辑后保存为瓦片集。上传数据后，将应用地图样式（样式）。样式是根据MapboxGL样式规范创建的。表格参数可以通过图形界面进行编辑，也可以通过编辑JSON配置文件（style.json），样式获得一个唯一的ID，格式为“user.ID”。Web地图应用程序使用MapboxGLJS技术[33]，通过将对象“mapboxgl.Map”分配给变量“varmap”来初始化地图。然后属性指定样式ID和访问键。

在这项试验研究中，三个数据层作为Tileset上传：一组来自OpenMapTiles项目的MBTiles格式的捷克共和国瓦片、一个GeoJSON格式的机场数据层和一个GeoJSON格式的边界层。将Klokantech基本样式应用于试点研究，最后，创建配置文件并分配定义的样式（存储在Mapbox内部存储中：mapbox：//styles/francimor94/cjs5xhdis1zvj1glmsfnhqaax）。

3.3 基于瓦片服务器GL的试验研究

瓦片服务器GL是一个服务器应用程序，用于渲染矢量和光栅图块，编写在JavaScript并在Node.js中运行。尽管瓦片你服务器GL通常用作服务器或云应用程序，但TileServerGL可用作Docker容器在本地主机上进行部署。除了提前渲染和瓦片服务外，瓦片服务器GL还可根据请求提供瓦片生成。瓦片服务器GL在config.json配置文件中配置，该文件定义了样式、字体和数据目录。瓦片是根据谷歌方案命名和存储的（参见第2.1节），为了在地图应用程序中访问瓦片，“瓦片”参数包含以“{z}/{x}/{y}.png或“{z}/{x}/{y}.webp”结尾的完整URL路径”。由于栅格瓦片的特性，不可能连续更改样式，任何样式的更改都需要重新生成整个瓦片集。

其中三项试验研究使用了KlokanTechnologies的开源瓦片服务器GL。第一项试验研究使用了MBTiles格式的预先生成的矢量瓦片，而另外两项试验研究涵盖了栅格瓦片的按需渲染并创建了PNG和WebP格式的栅格瓦片。瓦片以256×256像素的分辨率渲染，具有32位色深和0-14缩放级别。

在这些研究中，使用Maputnik网络编辑器来定义地图样式。Klokantech基本样式文件与服务器源文件和地图数据保存在同一文件夹中，并且每个资源的URL参数未填充精确的URL，而是使用字符串“mbtiles://{resourceID}”。研究中使用了具有以下规格：IntelXeon2.5GHz处理器、1GBRAM、8GB存储容量和Linux操作系统的亚马逊云EC2。一个正在运行的容器可以在公共地址上访问，尽管只使用单个容器，但是端口和数据目录因此显而易见。

3.4 基于瓦片服务器PHP的实验研究

TileServerPHP是一个开源项目，同时提供栅格和矢量瓦片，类似于TileServerGL，但运行PHP。TileServerPHP将样式本地存储在与地图数据相同的文件夹中。不需要使用访问密钥，样式参数指定Web主机存储的JSON样式的路径。

该试验研究使用了网络托管和开源地图服务器瓦片服务器PHP。来自OpenMapTiles的整个捷克共和国的MBTiles数据也被放在网络主机上，而OSM机场和边界数据集使用Tippecanoe工具[38]从GeoJSON转换为MBTiles。为了渲染数据，使用了Maputnik编辑器生成的Klokantech基本样式。地图应用程序使用基于MapboxGLJS技术的简单JavaScript应用程序显示。其余参数的设置与之前的应用程序一样。发布地图的最后一步是允许来自其他域的跨域资源共享(CORS)请求。CORS允许在某个域上运行的应用程序访问位于另一个域上的资源，然而这是不可能的，因为出于安全原因，浏览器本身不允许跨域请求。

3.5 基于文件夹结构Z/X/Y的试验研究

发布地图瓦片的另一种方法是包含地图瓦片文件的文件夹目录。这种方法不需要任何服务器基础设施，并且网络托管就足够了。与其他试验研究不同，样式没有存储在JSON文件中，而是直接在“样式”变量下的网页代码中定义。瓦片文件夹的URL文件格式以“{z}/{x}/{y}.pbf”结尾。必须输入包含协议的绝对地址。字符串“{z}/{x}/{y}.pbf”定义了文件夹结构和瓦片格式，其中Z表示缩放级别，X和Y表示地图瓦片的坐标（行和列）。

其中三个试验研究是使用这些目录结构创建的。第一个试验研究使用MBTiles格式的矢量瓦片，而另外两个使用栅格瓦片，因此一个试验应用程序提供PNG栅格瓦片，另一个提供WebP栅格瓦片。在这些试验研究中，来自OpenMapTiles项目的捷克共和国瓦片和使用他们自己的数据创建的瓦片从MBTiles压缩中提取到PBF（协议缓冲区）文件中。然后将这些文件上传到网络主机。本研究中使用的样式与TileServerPHP和TileServerGL使用的样式相同。

4. 性能测试

多项研究工作应用并检查了性能测试。加西亚等人描述了管理由缓存测试支持的WMTS方案，但该研究的结果发表已经有十年了，而且研究结果已经过时了。Fabry和Feciskanin最近进行的工作是评估栅格和矢量瓦片并记录每个缩放级别的比例和加载时间。其他几篇学术论文也讨论了地图瓦片的性能。藤村等人检查了矢量瓦片工具包并审查了优化和比较问题。Kefaloukos等人介绍了基于缓存瓦片集减少请求的方法。英根桑德等人描述了一个关于植入矢量瓦片的案例研究，并讨论了标准化过程的影响。布拉加等人通过应用矢量瓦片研究了使用web地图的用户行为。Mapbox和Maptiler作为地图瓦片应用的先驱公司，也进行了性能测试。Maptiler更专注于技术实现，而Mapbox则研究优化。[49]中的研究描述了一个性能模型以及用于提高性能的后续策略。一些性能主题也可以在Github存储库中找到。Cadell提供了一项最有用的研究，比较了Leaflet和Google地图库之间瓦片层的平均加载时间。根据[53]，“LeafletJS加载基础层更快”，然而，遗憾的是，这篇文章没有提供对方法和测试设计的调查。Giscloud使用基准测试方法比较了矢量和栅格瓦片，并在三个测试步骤（1、5和25个并发进程）中观察了三个指标（请求数、大小、加载时间）。这些指标和并发步骤方案被用作测试设计工作流程的基础。

两个子目标被指定用来补充主要目标：在试验研究中测试技术选项的可能组合，以及确定每种解决方案的优缺点。

测试根据应用技术、数据存储、数据格式和瓦片生成方法对应用程序进行了比较。本篇文章检查了服务器端和网络测试。

4.1 测试设计

在这项研究中，选择了Adamec描述的半自动测试方法进行性能测试，目的是模拟用户通常如何与地图应用程序交互。测试假设典型的用户行为与地图应用程序，工作流程的灵感来自Giscloud。任务涉及查找特定对象（城市、地址、兴趣点等）的位置并放大/缩小这些对象。位于奥洛穆茨的帕拉克大学地理信息学系大楼被选为默认对象。下一步需要在地图上平移，穿过主广场。然后用户缩小三个级别以显示两个对象（以说明位置的差异）。最后一步是再缩小一个级别。添加它是为了与之前的交互进行比较。表2总结了测试工作流程中的所有交互和缩放级别。每次交互都有固定的持续时间，这可以防止交互过程中的瓦片加载以及所有交互随机和顺序发生。

根据Schon的调查，2017年捷克共和国的平均互联网连接为34MBit/s。测试是在具有不同互联网连接速度的两个地点进行的：(1)在大学的网络(400+MBit/s)上，这可能被认为是高速互联网，以及(2)在家庭连接上(~12Mbit/s），这可能被认为是慢速互联网。两个位置均在同一台22英寸显示器上进行评估，分辨率为1650×1080像素，以进行直接比较。显示器连接到运行IntelCorei73.5GHz、8GBRAM和Windows10操作系统的计算机。

八个应用程序中的每一个都具有相同的控件，由四个按钮组成，用于控制交互动作（表2）。这些任务是按顺序执行的，每次交互的持续时间（以毫秒为单位）是固定的，不包括初始加载时间。如果没有此过程，交互将按顺序发生，并且不会在交互期间加载所有瓦片。持续时间是根据作者的估计和专家知识设置的，尽可能接近典型的用户控制，与用户通常与地图交互的实际速度相对应。

使用GoogleChrome控制台(ChromeDevTools)记录结果。缓存也被关闭以确保每次重新加载所有切片，并选中“保留日志”选项以记录在每次测量交互期间发送到服务器的所有先前请求的数据。对于八个应用程序中的每一个，在Internet连接速度较慢的站点执行了10次测量，在连接速度较快的站点执行了另外10次测量。每十次测量中有五次在早上（7：30-8：30）和晚上（18：00-19：00）进行五次，以消除网络连接波动。控制台记录在测试后导出为HAR（HTTPArchive）格式，然后转换为CSV文件。统计记录包含17个属性。本实验最重要的属性是请求URL、请求开始时间、请求持续时间、服务器对请求的响应、接收到的数据类型和接收到的数据量。对于每次交互，从交互持续时间、下载的数据量、点击次数、成功点击次数和每个瓦片的平均下载时间获取数据。时间精确到毫秒，数据以字节尽管以兆字节表示但以单位下载。分别处理慢速和快速互联网连接以及早晚时段的结果。测量值也单独处理，然后转换为平均值。为了消除极值，计算并给出了所获得的十个测量值的中值。

4.2 早上vs晚上

第一个测试方案检查了每个交互的加载时间的早晚测量值之间的差异（表3）。为此，在两个时间段（在慢速连接上）进行了额外的30次测量。Mapbox Studio是比较中唯一应用的解决方案。分别从这5个交互作用中的每一个时间段进行测量。

第一种比较方法是计算中值。选择中值以消除测量期间出现的任何极端值。仅选择平均值会使极值扭曲结果。除了初始负载（早上和晚上测量值的中位数之间的差异约为39毫秒）外，所有值仅相差几毫秒。因此，进行了统计测试以确定两个样本是否相似。在本研究中应用了比较两个数据集的方差的F检验。该测试通常用于确定测量数据中的任何干预是否具有统计学意义。在这种情况下，F检验检查晚上的测量值是否与早上的测量值不同。第一个测试步骤是确定假设H0。第一个测试步骤是确定假设H0。我们假设两个数据集的变化——早上和晚上的加载时间——是相同的。在F检验中，假设H0由下式给出：

通过比较标准F与临界值来解释测试。如果F>F的临界值，则假设（1）被拒绝，并且可以得出结论，根据所选的显着性水平，两个检查集在统计学上存在差异。。如果F<F的临界值，那么假设（1）没有被拒绝，并且可以得出结论，检查的文件在统计上没有差异。对五种相互作用中的每一种的测量值进行F检验。结果如表3所示。

F<F临界值，F在剩余的两次测量中，假设(1)被拒绝。测试结果显示，在初始加载和缩小时，早晚读数之间没有统计差异，尽管“放大部门”和“平移到广场”的统计差异很明显。然而，也可以看出，“放大部门”交互的数据分散方差主要是极端的（早上测量的30个中有4个）。对于晚上的测量，结果只有一个极值。这也可以在“PantotheSquare”中看到，晚上出现了更多的极端值。虽然这些极端影响了数据分散，但后来对测量结果的分析并未受到影响。使用了测量值的中值，并没有用极端值扭曲呈现的值。基于这些测试结果，测量值的使用与记录时间无关。结果显示，早上（互联网非高峰时段）加载数据时间和晚上（互联网高峰时段）加载数据时间没有显着差异。峰值不影响互联网使用期间传输的数据量。

4.3 地图加载时间

第一个检测到的值是每次请求后的地图加载时间。这被定义为：

其中最终瓦片加载时间是最后一次请求完成的时间。获得的值受执行请求的指定时间的影响。所达到的时间如图4和图5所示。最初加载测量值时，还加载了MapboxGL库、地图数据、样式和网络图标（favicon）。

对于第一个初始负载指标，具有预生成栅格瓦片的应用程序更快。在慢速和快速Internet连接下，基于WebP的应用程序返回的结果略好于PNG瓦片应用程序。按需生成的栅格图块的初始加载时间比预生成的等效图块慢约一秒。然而，这个时间仍然与矢量瓦片加载时间相当（图4）。

在快速互联网连接的所有被测程序中，按需生成的栅格瓦片最慢（图5）。预生成的栅格的加载速度比基于矢量的解决方案快约400毫秒。结果表明，按需生成的栅格瓦片在与地图的所有交互中具有最差的结果。在放大三个缩放级别时，观察到大约3秒的延迟。在“放大部门”交互中更快地检索栅格瓦片的原因是矢量瓦片还加载了根据复杂算法生成的字体和标签。然而，结果是一个具有简洁且不重叠的描述的地图。因此，按需生成的栅格瓦片加载时间较长的原因是显而易见的；与仅从存储下载的其他图块相比，在服务器上生成需要额外的时间。客户端（Web浏览器）也需要更多的矢量瓦片计算，这可能是矢量瓦片加载时间较长的原因。

4.4 一块瓦片的下载时间

由于在大多数交互中地图加载时间比较受到持续时间参数的阻碍，因此还比较了单个图块的平均下载时间。总时间是几何图形和字体加载时间的总和，因为它们同时加载。结果时间仅根据下载成功完成时的请求计算。结果如图6和图7所示，这表明基于TileServerGL（在亚马逊云上运行）的矢量解决方案是最快的。最慢的矢量瓦片来自将数据存储在WedosWeb主机上的PBF格式的文件夹结构中的解决方案。栅格瓦片的平均下载时间具有可比性。从矢量按需生成的栅格瓦片在该指标中明显较差，当用户缩小超过三个级别时，差异会高达十倍。下载时间指标存在特定问题。矢量瓦片由两部分组成：几何图形和字体，它们同时加载。视觉分析显示，字体的下载时间与几何图形的下载时间相差不大。。此外，字体（用于制作标签）是瓦片的组成部分，没有字体，数据将不完整。

4.5 服务器请求数

除了每个瓦片的加载时间外，瓦片下载方式的差异也可以用每次交互的点击数来表示。这些请求的数量对应于下载瓦片的尝试次数。在初始加载时，请求数还包括下载MapboxGL库、样式和站点图标的请求。图8和图9以红色显示所有请求的数量，以绿色显示成功完成的请求数（即正确下载和显示的瓦片的数量）。完全绿色的列表示所有请求都因数据下载而终止。

初始加载和“PantotheSquare”交互中的值与Internet连接无关（即每次加载相同数量的瓦片）。对于其余的交互，值是不同的。在大多数情况下，在较慢的连接上发送的请求比在较快的连接（图9）上发送的请求更少（图8），其原因是在一个较慢的连接（在用户缩放到下一级之前）上，每个缩放级的请求只有一小部分可以跨越缩放级的范围传送。

两个数据文件的使用导致“放大部门”中更多的矢量请求失败。加载地图后，应用程序会显示来自OpenMapTiles、机场和边界图层的瓦片。但是，仅创建了包含数据的瓦片，而其他瓦片不可用。服务器对这些瓦片的请求的响应是“204-无内容”，这是没有数据的成功请求的通知。因此，具有大量失败请求的应用程序不是由错误引起的。MapboxStudio仅使用一个文件，因此发出的请求数量是其他矢量瓦片程序的一半。

请求的数量是一个指标，它令人满意地揭示了在15或更高的缩放级别下数据检索（retrieval）的差异。虽然MapboxStudio只下载一个新瓦片，而其他矢量应用程序下载两个瓦片，但栅格应用程序需要为同一请求下载40个瓦片。在从17级到14级的缩放移动中，Mapbox下载了6个瓦片，而具有预生成栅格瓦片的应用程序发送了76-85个请求并下载了68-80个瓦片，具体取决于连接速度。因此，栅格瓦片解决方案的服务器负载要高出许多倍，原因是基于矢量瓦片的应用程序在级别14检索到最详细的几何图形，然后显示相同的数据（否则可能已被样式化）。对于栅格解决方案，必须在每个级别提供并下载相应的瓦片；如果不是，则图像模糊。高速和慢速Internet连接上的多个请求之间存在差异的原因是由于使用了缓存。通过更快的连接，客户端有更多时间发送额外的请求以将周围的瓦片下载到缓存中。

下载数据的大小

最终测量的指标是每次交互下载数据的大小。测量值对应于所有成功下载的瓦块的大小之和，包括在交互期间矢量瓦块的情况下用于标记的字体。

图10和图11显示，在基于矢量的解决方案中，所有请求的下载数据量相当。结果显示服务器上有相应数量的成功请求。栅格瓦片表现出很大的差异。除非在初始加载期间，使用WebP瓦片的应用程序下载的数据总是比使用PNG瓦片的应用程序少三倍。与动态生成的瓦片应用程序相比，具有预生成瓦片的应用程序在所有交互中捕获的数据更多。矢量瓦片下载数据量更大的原因是因为大部分整体大小都分配给了标签，尤其是在初始加载期间，字体大小占下载数据的一半以上。

栅格瓦片显示出对Internet连接的依赖性，其中Internet速度反映在下载的数据量中：Internet速度越快，可以传输的图块越多，因此下载的数据量就越大。与慢速连接（图10）相比，使用矢量瓦片在快速连接（图11）上下载的数据也更多，成功完成的请求数量与慢速连接相当甚至更多。与之前的测试一样，原因是使用了网络缓存。

4.7 浏览器和设备

本节提供了全面的概述。根据[57]，浏览器和设备的范围“是Web开发中的巨大挑战之一”。各种浏览器和设备可能以有限的能力运行。跨浏览器（跨设备）测试是确保Web应用程序在多个浏览器（设备）上得到支持的实践。作者进行了特设的跨浏览器和跨设备测试，但一般来说，用户端负载测试是整体测试的一个复杂且独立的部分。要进行一个精心准备的用户负载测试，需要一种不同于本文描述的本实验中使用的方法、工作流、工具和硬件。因此，作者决定继续他们的研究，并包括新的指标，如用户端加载和浏览器/设备/操作系统，未来将分享进一步的结果。另一方面，本章讨论了对先前发现进行更广泛分析的初步比较。

在快速互联网连接上测试了几个稳定的浏览器：Chrome（78.0.3904.108），MicrosoftEdge(42.17134.1098.0)、Firefox(69.0.1)和Opera(65.0)。地图在Windows版Safari上根本没有加载。硬件规格与第4.1节中提到的相同。该实验记录了加载时间指标，以便在浏览器之间进行比较。栅格（TileserverGLPNG）和矢量（MapboxGLJS）格式的初始加载时间和大小使用每个浏览器中的本机开发控制台测量了十次。图12中的结果表明，不同的浏览器对负载指标有部分贡献。MicrosoftEdge传输的数据明显少于其他浏览器。MicrosoftEdge控制台不以与其他浏览器控制台相同的方式捕获和测量传输的数据，因此传输数据指标（图12b）不具有可比性。原因是尽管禁用缓存已打开，所有文件的大小都没有显示和完全计数。除MicrosoftEdge外，所有浏览器的记录时间几乎相同，变化仅为几十毫秒。与Chrome和Opera相比，Firefox传输的数据更少，而且几乎是PNG瓦片数据的一半。由于相同的浏览器引擎，Chrome和Opera展示了相同的结果。Web浏览器引擎也会影响视觉印象和性能、分布，并且在市场上占多数关键贡献。由于Chrome和Opera在相同的引擎上运行，MicrosoftEdge将很快切换到Chromium引擎[58]并且不再受支持，并且主要Web浏览器的行为趋向于尽可能相同。最后，Firefox（Gecko引擎）以类似于Chrome的方式渲染地图瓦片，但速度更快。

比浏览器更重要的因素是使用的硬件或设备。跨设备测试在Chrome浏览器中的三台设备上进行：具有通用规范的个人计算机（请参阅第4.1节）、较旧的三星GalaxyTab3平板电脑（ARMCortex1GHz、1GBRAM、Android4）和新的Redmi8智能手机（八核2GHz，4GBRAM，Android9）。与之前的测试一样，跨设备测试测量了加载时间指标，以直接比较三个设备。使用针对Android设备的远程调试对栅格和矢量瓦片的初始加载时间和大小进行了十次测量。图13显示平板电脑上的加载时间大约是智能手机上的两倍。虽然传输的数据度量取决于显示器尺寸（更宽的显示器覆盖更大的区域并需要更多的数据），但加载时间不存在类似的依赖性，原因是硬件和软件参数的组合，例如处理器（CPU)、内存(RAM)和Android版本。作者假设足够的内存对于加载时间是必不可少的，但是，此时任何深入的检验都无法支持这一假设。如上所述，这需要结合几个测试，这可能是进一步研究的桥梁。

4.8 不可衡量的方面

栅格和矢量解决方案在某些用户和技术方面存在差异，但无法客观衡量。如果地图图层未正确加载，则用户方面对于网站使用变得尤为重要。从技术角度来看，加载矢量和栅格瓦片是不同的。矢量瓦片加载新几何图形（以及用于标注的字体集）时，栅格瓦片加载新图像。这导致在地图浏览期间的体验完全不同。通常，用户（而不是机器，如前几节）在地图上的快速放大/缩小移动可能会显着影响用户体验和基本制图原则（图4）。在从矢量图块加载适当缩放级别的几何之前，尽管过渡是平滑且连续的，上一个地图步骤中使用的广义几何形状仍然可见。同时，地图上的描述/标签在完全加载之前往往会丢失。但是，当加载栅格瓦片时，用户可能会观察到先前加载的图像仍保留在监视器上的现象，并且在放大时会慢慢被新图像替换，如图14所示。在“全点”比例级别（参见第2.2节），也会暂时出现可见的模糊，与先前显示的图块的标题重叠。

用户可能会注意到的第二个负面方面是位于图块边缘的部分标签缺失（图15）。这种现象只发生在栅格瓦片上，并且是与OpenMapTiles项目生成的图块相关的问题。矢量瓦片不能解决这个问题，因为描述是作为地图数据上方的单独对象呈现的。此外，它基于一种复杂的算法，可以计算应该显示哪些标签以及在哪里避免过度填充地图。

5. 结果

对八个试验应用程序进行了测试，以测量使用不同格式和后端技术的栅格和矢量瓦片之间在速度和加载方面的差异。为此，设计了半自动测试来模拟用户对地图的处理。除了初始加载之外，该设计还包括四个交互：放大模拟兴趣点的特定建筑物（地理信息学系建筑物）；将地图平移到主广场；缩小三个缩放级别；并缩小一个缩放级别以进行比较。测试是在GoogleChrome控制台环境中进行并记录的，该环境允许记录与地图的所有交互。然后将数据导出到HAR格式的列表中。对于每个应用程序，在一天中的两个不同时间在慢速(12MBit/s)和快速(400+MBit/s)互联网连接上记录十次测量。早上（7：30-8：30）记录了五次测量，下午（18：00-19：00）记录了五次。在所有交互中测量了五个属性：总地图加载时间、点击次数、成功完成的点击次数、每个瓦片的平均下载时间和下载大小。

第一步是验证早上和晚上采集的样本是否有统计学差异。异。为了实现这一点，在MapboxStudio中创建的应用程序中，在一天中的两个时间对慢速Internet连接进行了额外的30次测量。获得了所有五种交互作用的值，并对所有交互作用进行了数据分散的F检验，以比较早上和晚上测量的结果。假设H0是根据两个统计集的变化相同来定义的。结果表明，五种相互作用中的三种在统计学上是不同的。其他两个交互（“放大部门”和“平移到正方形”）也显示出统计学上的显着差异。经过视觉分析，发现这种差异主要是由于其中一个时间段内的极值数量较多。基于这些测试结果，因此选择测量数据的中位数作为平均值，以避免极值对呈现结果的影响。因此，上午和晚上的测量也没有进一步区分，被认为独立用于数据评估。

测试结果根据检查的各个指标进行分组。总共执行和评估了五个指标（四个可衡量的和一个不可衡量的）。表4总结了栅格或矢量瓦片是否在每个指标中提供了更好的结果的一般指示。

检查的第一个指标是每次交互的总地图加载时间。设置持续时间可能会部分影响该指标。因此指定了持续时间（表2）。预先生成的栅格瓦片（“平移到广场”交互除外）在该指标中显示出最佳结果。但是，根据请求生成栅格瓦片的应用程序速度明显较慢。在缩小三个级别的情况下，带有栅格瓦片的应用程序速度要慢五倍。字体和地图标签对基于矢量的解决方案产生了很大影响，并将总地图加载时间延长了2500毫秒。如果字体加载速度更快，矢量瓦片应用程序甚至会胜过预先生成的栅格瓦片。

由于上述效果，因此也测量了一个瓦片的平均下载速度。对于矢量瓦片，瓦片标签的字体加载速度也有影响。对于矢量瓦片，瓦片标签的字体加载速度也有影响。这两个类别的平均瓦片片下载率与其他类别相当，除了“放大部门”（下载矢量切片的速度大约是预生成栅格的两倍）。按需生成的栅格瓦片再次显示出更差的结果，尤其是PNG格式。WebP格式更快（在连接速度较慢的情况下，速度高达两倍），但与其他应用程序相比仍然落后。对于缩小三个级别，一个瓦片的平均下载时间比按需生成的栅格瓦片的平均下载时间长十倍。

检查的第三个指标是服务器上的请求数。这与请求的数量一起呈现，从而导致了瓦片下载。该指标的结果表明，矢量瓦片应用程序在大多数交互中下载的瓦片比光栅瓦片应用程序少。最显着的区别是“平移到广场”交互，其中下载了1-2个瓦片用于矢量，而下载了40个瓦片用于栅格。由于对按需生成的栅格瓦片执行服务器端栅格化的持续时间较长，因此这些应用程序的请求数量通常低于预先生成的瓦片。然而，这对最终应用速度的影响可以忽略不计。一些矢量瓦片应用程序的大量请求最终没有下载瓦片是由于第二个瓦片文件中的数据量。边界层和机场层在大多数图块上不可见，服务器响应成功请求的通知而无需下载任何数据。

检查的第三个指标是服务器上的请求数。这与请求的数量一起呈现，从而导致了瓦片下载。该指标的结果表明，矢量瓦片应用程序在大多数交互中下载的瓦片比光栅瓦片应用程序少。最显着的区别是“平移到广场”交互，其中下载了1-2个瓦片用于矢量，而下载了40个瓦片用于栅格。由于对按需生成的栅格瓦片执行服务器端栅格化的持续时间较长，因此这些应用程序的请求数量通常低于预先生成的瓦片。然而，这对最终应用速度的影响可以忽略不计。一些矢量瓦片应用程序的大量请求最终没有下载瓦片是由于第二个瓦片文件中的数据量。边界层和机场层在大多数图块上不可见，服务器响应成功请求的通知而无需下载任何数据。

在最终测试中，描述了浏览应用程序的不可衡量的方面，包括用户和技术方面。浏览地图时记录的示例演示了不同的加载方法并描述了栅格瓦片的问题。这些方面在使用地图时发挥着美学作用，尽管可能是用户选择使用哪个地图应用程序的重要因素。

6. 讨论

作者认为，测试设计和序列全面涵盖了主要的负载指标。它遵循相关研究[53]和[54]，其中通常使用加载时间和数据大小。本文中包含的基本指标由其他人补充，以涵盖来自服务器端和网络测试的最预期指标。进行了基本的跨浏览器和跨设备比较。没有涉及硬件配置和不同的格式/库，因为比较主要不是针对用户端测试，这是本研究的一个潜在缺点。临时测试表明，软件（浏览器引擎）和硬件（内存）参数的组合显着影响了结果。这项比较研究有几个优点（+）和缺点（-），如下所示：

(+)比较研究作为综合性能测试；

(+)栅格和矢量瓦片实现之间的差异；

(+)最常用指标的实施；

(+)技术/格式/数据存储比较；

(+)工作流程/指标/结果作为进一步研究的建议；

(+)测试反映Internet连接（慢速和快速连接；早上和晚上）

(-)仅MapboxVectorTiles规范（用于矢量瓦片）；

(-)次要指标未实施；

(-)未考虑互联网连接的波动；

(-)不考虑计算机性能（不同的软件和硬件配置）

获得的结果表明，矢量瓦片可能并不适用于所有类型的数据。主要挑战在于不同缩放级别的数据集样式。例如，默认的MapboxStreets样式包含大约120个需要渲染的图层。缩放过程中的处理和优化样式会影响传输的数据量以及所有指标的时间。事实证明，在生成PNG和WebP格式的栅格瓦片时，栅格瓦片和矢量瓦片之间的差异至关重要。在某些应用程序中，捷克共和国的瓦片最多只能存储到14的缩放级别。超出此级别，将不再有可用的瓦片，并且最后一个可用的瓦片会变得模糊。原因是在更高级别生成栅格瓦片所需的硬件。捷克共和国在第14级时共有55,490块瓦片。在每一级，它是四倍。例如，在第15级，它是221,960个图块。在15-21的缩放范围内，总共有1,212,123,560个瓦片，仅覆盖捷克共和国。因此，瓦片只生成并测试到14级，与矢量瓦片一样。

对结果的深入分析可以揭示本研究方法之间差异的原因。根据调查结果，提出了一些关于Web应用程序设计的建议。测试的指标之一是加载时间。显然，对于这两种技术（栅格、矢量），预先生成的瓦片的加载时间明显少于按需生成的瓦片的加载时间（与仅从存储中下载的瓦片相比，在服务器上生成需要额外的时间）。使用按需生成的瓦片的主要原因是节省磁盘空间。使用这两种方法的组合似乎是理想的。对于低缩放级别和频繁访问的区域，最好使用预先生成的瓦片。然而，详细的缩放级别和外围区域（海洋、森林）可以令人满意地使用预先生成的瓦片。

检查的另一个指标是下载数据的大小。如果用户频繁更改缩放级别，矢量瓦片的优点是无需重新下载，客户端浏览器可以更改其分辨率。另一方面，如果用户以相同的缩放级别浏览地图，则使用栅格瓦片地图下载的数据会更少。根据下载的数据量度，更好的方法是矢量瓦片图。对于只有几个缩放级别的专用地图，使用栅格瓦片似乎更好。

Internet连接的速度对使用地图的便利性有显着影响。更快的Internet连接允许更快地加载地图，但另一个因素也受Internet连接速度的影响。通过更快的Internet连接速度，服务器可以发送更多请求，从而可以下载当前显示区域的更大周边区域的瓦片。因此，由于使用了填充了更多下载瓦片的缓存，因此地图浏览起来更加流畅。

最初的目标是使用Leaflet库，它是最流行的网络地图库之一。然而，很明显，通过Leaflet库使用矢量瓦片的可能性非常有限。尽管如此，至少还有两个其他库默认支持矢量数据：OpenLayers和ArcGISAPI。毫无疑问，矢量瓦片支持将很快得到改善，其他最初设计为使用栅格瓦片操作的地图库只能在未来实现矢量瓦片支持。

可以假设对测量值的影响比简单的应用技术和互联网连接速度的影响更大。通常，将应用程序移动到HTTPS服务器而不是HTTP可能会对下载时间产生有益的影响。

7. 结论

Web应用程序的快速发展也改变了背景地图的呈现方式。栅格瓦片目前可以被视为常规解决方案，而矢量瓦片的使用正变得越来越普遍。这项工作的主要目的是通过比较栅格和矢量瓦片的不同方法来研究负载指标。测试表明，矢量瓦片的加载速度并不总是比栅格瓦片快。但是，它们的主要优势在于减少服务器负载和下载数据量，并为浏览地图应用程序提供更友好的用户体验。由于软件库动态地将标签放置在地图上，因此标签不会重叠并且地图不会变得更密集，这更有效地适用于移动设备。我们的负载测试结果表明，按需生成栅格瓦片的过程比显示预生成的瓦片要慢几倍。为了使应用程序至少实现与矢量切片应用程序类似的性能，必须在用户请求之前生成显示区域中的切片。这些测试表明，在大多数情况下，矢量瓦片具有更好的加载时间。栅格瓦片可能更适合假设从Internet连接速度较慢的站点进行访问的应用程序。虽然栅格瓦片是当今底图的事实标准，但是可以预期矢量瓦片在不久的将来也会同样流行。