12. 基于Web的大数据可视化地理空间矢量数据

摘要

今天，大数据是计算机科学中最具挑战性的课题之一。为了让客户、开发人员或领域专家了解他们的数据，需要将其可视化。如果数据包含地理空间信息，则变得更加困难，因为大多数用户都拥有如何探索地理信息的训练有素的经验。一个通用的地图界面允许用户缩放和平移来探索整个数据集。本文重点介绍一种在现代Web浏览器中可视化大量地理空间数据集以及维护动态瓦片树的方法。这项工作的贡献在于，使用2DVector瓦片可以渲染集成在现代Web应用程序中的超过一百万个多边形。一个主要挑战是地图界面提供交互功能，例如数据驱动的过滤和矢量数据的样式，以进行直观的数据探索。Web应用程序请求、处理和渲染向量瓦片。这样的应用程序必须保持其响应能力以获得更好的用户体验。我们构建和维护瓦片树数据库的方法提供了一个导入新数据的接口，更有价值的是一种灵活的方式来请求Vector瓦片。这对于面对现代Web应用程序中的内存分配问题很重要。

关键词

大数据、·可视化、·矢量平铺、·地理空间数据、Web

1. 介绍

利用现代技术，计算机科学家能够存储大量各种数据。数据用于创建统计数据并分析机器、人类、自然等的行为。应用从数据聚合到机器学习的算法来获取更多信息并解释这些数据量。

为数据添加地理空间引用使其更有价值。在地球上的地理环境中处理数据时，用户、领域专家、开发人员和科学家对数据有更好的直觉。不仅将数据可视化为统计图或复杂的交互式图表，这是一个重要的主题。地理空间数据应在地图上可视化，以与地理环境相关联。用户可以像GoogleMaps或OpenStreetMap等应用程序一样通过平移和缩放来探索数据。用户在使用这些界面探索国家、街道、城市、建筑物或卫星图像方面受过良好培训。

为了构建这样的地图界面，现代应用程序利用了OpenLayers等Web技术框架。他们采用两种不同的技术。街道地图最常用的方法是将世界切片，渲染栅格图像并将它们传输到浏览器。另一个选项是加载矢量数据，并使用应用程序或用户定义的样式动态渲染它。这样，更多的交互应用成为可能，例如直接过滤和修改特征。这里的主要挑战是在不损失渲染性能和界面响应能力的情况下可视化大量几何图形，从而降低用户体验。

最先进的解决方案主要处理静态数据，这使得可视化变得更加容易，因为街道或建筑物很少发生变化。他们预先渲染整个世界，这是一项非常耗时的任务，而且这种方法不能应用于快速变化的数据。

将矢量数据加载到浏览器的现有标准解决方案是Web特性服务( WFS )实现。。用户明确定义他们想要探索的世界的哪个部分以及哪种类型的数据。使用该技术无法交互式地探索分布在大范围内的空间密集数据，因为加载初始地图会查询整个世界的数据。一个高级示例是可视化分布在全国各地的数百万个包裹中的作物种植信息。生长的植物、树木和谷物类型的信息会定期更新，从而使数据动态化。主要挑战是提供一个地图界面，以使用基于矢量的方法探索大量密集数据。

这项工作的贡献是一种方法，它产生了前面提到的两种解决方案的好处。提供交互功能非常重要，例如探索时间数据集或应用数据驱动的样式，而无需从服务器上面下载。特别是，我们的方法可以渲染集成在现代Web应用程序中的超过一百万个多边形以及用户定义的样式。

这项工作侧重于基于矢量的瓦片方法和适用于基于图层的地图应用程序的JavaScript框架。它不是为网络引入地理信息系统或实施云处理解决方案。

该解决方案提供了三个基本步骤。首先，数据必须以一种有效的地理空间访问方式存储。这是通过使用地理空间索引以及快速且可扩展的分布式文件系统来实现的。

其次，必须针对可视化目的优化数据。这是通过实现平铺算法并将数据转换为专门的格式来完成的。这种格式具有更快的可视化和网络传输的好处，同时有效地节省了存储空间

最后，必须将数据传输到在现代Web浏览器中运行的Web应用程序。然后使用WebGL地图应用程序框架对几何图形进行渲染。此外，还可以添加交互概念，例如过滤器和用户定义的样式。此外，这个想法是直接操作、删除和添加几何图形。

要处理和可视化的地理空间数据以文本格式的文件形式出现。使用真实世界的用例清楚地说明了这些方法。农艺师和保险公司必须监测作物的生长过程才能做出重要决策。Topperformwell，为整个国家的地块获取数据。这些巨大的数据集包含描述农业地块边界和属性的几何图形，描述地块的类型和实际健康状况。这些数据需要以非地理专家也可以探索的方式进行可视化。除此之外，还应实施交互，例如基于时间范围的过滤器或包裹的数据驱动着色。

2. 相关工作

瓦片内容的研究主要集中在制作基于图像的方法，而不是Web应用程序可访问的大矢量数据。本节概述了在地理空间环境中存储、处理和可视化矢量数据的现有方法。Vitolo等人。（2015年）撰写了一份关于如何使用网络技术处理大数据的调查。在计算机科学的发展过程中，数据集合扩展得非常快。为了处理如此大量的数据，需要新技术。他描述了这必须在该数据集内的分析、工作流和交互的背景下成为可能。本文讨论了当前用于处理简单数据集的网络技术，这些技术可以非常直接地使用。此外，目前由开放地理空间联盟https://www.opengeospatial.org/.维持的执行标准的网络技术缺乏灵活性和可扩展性。

虽然Vitolo专注于大数据和Web技术（YueandJiang2014），但在地理空间信息系统的背景下讨论了大数据。在他看来，支持地理空间领域非常重要，因为尤其是GIS软件应该能够处理包含地理空间数据的巨大数据集。 Horak等人的概念（2010年）在用于地理空间数据管理的Web工具中侧重于提供基于XML并且也由OGC定义的远程接口。他讨论了从数据库或文件到基于Web的应用程序的数据流。但它并没有真正关注大数据和使用可视化探索数据的方面。

用于存储和传输数据的格式很重要。标准是使用JSON和XML等纯文本格式定义的。如果没有压缩和编码，这些存储或传输效率不高。数据格式研究主要是为了在网络上更快地传输空间数据。Yang和Li(2009)的一种方法是通过聚类数据进行数据压缩。这些想法是压缩数据，但不是为了可视化目的。在使用基于XML或JSON的数据中也讨论了瓦片，这些数据被传输和合并以使用SVG渲染矢量数据（Antoniouetal.2009）。在瓦片的内容中，缓存是一个被广泛提及的话题（Liuetal.2007）。此外，Blower（2010）正在讨论云中的GIS（栅格瓦片）和GIS缓存。 Ingensand等人(n.d.)和vandenBrink等人。(2017)以及许多其他专注于栅格图像瓦片的人。在服务器端创建栅格瓦片也是一个巨大的话题。Olasz等人(2016)撰写了一份关于使用服务器端渲染的可能性的调查。特别是，他使用GeoTrellis和几种不同的存储解决方案来评估可以在哪些环境中使用这些技术。大数据方式的可视化在这里是一个小话题。刚刚提到了使用网格图像创建平铺树。正如目前所描述的，目前最先进的技术是在服务器上渲染瓦片并接受缺乏交互的可能性。这种瓦片和存储栅格图像的概念必须适应即将到来的利用矢量瓦片特征的需求。

瓦片提供地图用户界面的想法实际上是专注于瓦片，而不是尝试以矢量格式压缩、缓存瓦片，而不增加工作流中任一点的内存使用量。

目前唯一稳定的二维矢量切片数据格式是MapboxVector瓦片。Eriksson和Rydkvist(2015)对Mapbox实现的地图渲染框架MapboxGLJS进行了审查。它专注于Mapbox实现的渲染引擎的大量功能和性能。瓦片的生成是在从PostGIS导出GeoJSON文件后使用命令行工具完成的。它依赖于一次构建一个瓦片集，而不提供添加数据等功能。瓦片本身是重点，而不是优化矢量瓦片的压缩、编码和缓存。

Mapbox推出的Vector瓦片使用的是GoogleProtobuf。这是一种通过网络序列化和传输结构化数据的有效方式。FengandLi(2013)描述了在线游戏背景下的用法。Mapbox提供了使用Protobuf编码的Vector瓦片的详细规范。一个应该更进一步，评估是否有更好的解决方案，以便在处理矢量瓦片和动态数据时更加灵活。这对于构建应用程序处理和动态创建向量瓦片是很重要的。

可缩放矢量图形(SVG)被用作浏览器中空间数据可视化开发的一部分。使用SVG(Langfeldetal.2008)的可视化想法很简单，因为渲染任务是由浏览器的引擎处理的。但SVG无法处理大量几何图形，因为所有内容都加载到浏览器文档对象模型(DOM)中。直接在画布上渲染效率更高，并且已经取代了SVG技术，主要用于渲染目的。

总而言之，有很多工作专注于数据标准和使用最先进的技术存储数据。服务器组件主要关注栅格数据。以地理空间可视化和大数据集的方式评估矢量数据的使用非常重要。

接下来的段落简要概述了地理空间数据最常用的标准数据库和发布服务。这是一个相关主题，因为处理和优化数据依赖于数据存储解决方案。

2.1 PostGIS

除了普通文件系统之外，关系数据库是存储结构化数据最广泛和最传统的方式。SQL用于PostgreSQL中的数据维护和访问数据库。它支持自定义函数的定义和扩展的实现。必须专门为PostgreSQL编写扩展。这些是使用SQL语句、C代码片段和配置文件的组合编写的。由于复杂性和架构的限制，维护和扩展基于PostgreSQL的应用程序很难管理。

PostGIS是一个功能丰富且复杂的PostgreSQL数据库扩展，用于存储和索引地理空间数据。PostGIS将几何图形存储在WellKnownText格式的空间索引中以及给定的属性中。评估部分将展示PostGIS如何通过动态转换为WKT导入巨大的GeoJSON文件。

SQL语法中有许多函数可以查询、聚合和转换存储在此类数据库中的数据。MapboxVector瓦片格式也是支持的导出格式。每个瓦片都是按需创建的，这在每个瓦片数千个多边形上缺乏性能。为了创建瓦片，必须嵌套三个主要的PostGIS函数。创建这样一个自定义的SQL函数来直接从数据库中获取瓦片是一种非常不常见的方式。附加功能必须以提供处理SQL查询的接口的中间件的形式实现。下一段描述了为此目的实现的GeoServer的功能。

2.2 GeoServer

基于PostGIS数据库，GeoServer可以通过提供多个标准化接口来发布数据。支持OGC标准WFS、WMTS和WMS。Web地图平铺服务(WMTS)还提供Vector瓦片格式的瓦片。它使用自己的实现来服务Vector瓦片并创建缓存。它在请求瓦片时所做的只是创建一个查询，包括所请求瓦片的边界框，然后使用电子图表中心的矢量瓦片实现对其进行剪辑和编码。这些瓦片直接缓存在文件系统中。令人惊讶的是，创建矢量瓦片比实际栅格图像花费的时间更长。多年来，矢量瓦片并未像创建网格瓦片那样进行优化。根据数据量，创建瓦片可能需要几分钟时间。

使用GeoServer，无法控制向量瓦片中包含哪些数据。存储在特定PostGIS表中的每个属性都附加到几何图形。在缓存方式中，只有两种控制机制可以使瓦片失效。第一个是定义一个固定的超时时间，另一个选项是手动触发整个世界或特定区域的重建。

3. 我们的方法

本节详细描述了我们的实现方法。这个想法由三个基本组成部分组成。

• 存储3.1

• 瓦片方法

• • 几何图形处理3.2.1
  • 矢量瓦片编码和存储3.2.2

• 可视化3.3

数据保存在存储组件中。这项工作的主要贡献是执行为构建、扩展矢量瓦片并提供API来请求这些瓦片而完成的处理。最后，重点是使用可靠的地图应用程序框架可视化几何图形，同时添加交互功能来探索数据。

所有使用的技术和库都是用JVM语言编写的，我们的实现也是如此。重点是面对研究目标，而不是处理技术细节。为此，使用高级语言Kotlin进行实现。Kotlin是由Jetbrains创建的一种相对较新的语言，它将Java和Scala的优势结合在一起。Kotlin支持面向对象和函数式编程技术。

接下来的段落将详细描述这些组件。

3.1 储存

为了导入、查询和聚合地理空间数据，该方法使用GeoRocket作为存储技术。GeoRocket是用于地理空间文件的高性能数据存储。它使用MongoDB来持久化数据，使用Elasticsearch为数据查询和聚合任务构建空间索引。GeoJSON可以直接导入，无需转换。

3.2 瓦片方法

这里面临以下两个矢量瓦片方式的目标。假设新数据被导入数据存储。瓦片组件必须获取此数据并将其合并到现有的瓦片树数据库中。其次，必须在合理的时间内处理对瓦片的请求。这些请求包含瓦片的实际坐标和一个查询，这些信息应该明确地集成到瓦片中。这也是我们方法的核心贡献。

3.2.1. 几何图形处理

假设一个GeoJSON文件读取到工作内存准备好进行处理。本节介绍如何处理一组地理空间特征以创建实际的瓦片。

为了进一步处理，几何图形坐标是墨卡托投影到从零到一的值[0,1]。首先计算所有几何图形的边界框。这种计算很重要，因为它最终节省了大量的处理时间。为了最大化并行计算的能力，每个缩放级别都可以在我们的算法中独立处理。在每个缩放级别上，边界框用于确定必须创建哪些瓦片。迭代开始创建边界框覆盖的左上角瓦片，可以针对某个缩放级别z和左上角边界框坐标x、y计算（参见公式1）。

对于每个覆盖的瓦片，都会创建一个特征集合。所有几何图形都在瓦片边缘处剪裁。裁剪定义了在某些边界处切割几何图形以节省磁盘空间并提高渲染性能的过程。为了降低多边形复杂度，可以应用Dougles和Peucker(1973)的线简化算法。这是一个使用精度参数去除尖峰和小角的轻量级过程。在较低的缩放级别上，这些太小而无法被用户识别。构建实际瓦片之前的最后一步将通用世界坐标转换为瓦片扩展，默认为0到4096。等式2显示了转换是如何完成的。

清单1说明了该算法。这里所说的算法不应该提供一个高度优化的解决方案，而不是表明即使是我们的简单方法在创建瓦片方面也表现得非常好。参见评估部分。4了解详情。我们的实现提供了线性可伸缩性，因为每个缩放级别处理都在自己的线程中运行。

3.2.2 矢量瓦片编码与存储

瓦片组件的第二个也是最重要的子组件是存储和服务向量瓦片的实现。矢量瓦片使用GoogleProtobuf编码，然后使用GZip压缩。实现了一个存储接口，支持多种后端技术，例如MongoDB、SQLite以及使用本机文件系统的简单目录结构。二进制编码的瓦片既可以使用三重主键模式（z，x，y）存储，也可以存储到MongoDB集合中时使用唯一的散列值。

下面描述了一个完整的GeoJSON集合是如何编码和存储的。几何图形已经在瓦片边界处被剪裁，并且坐标被相应地转换为矢量瓦片规范。为了以Protobuf格式编码数据，必须转换属性。简单的键值映射被转换为标签集。标记集是由包含键和值的不同集合组成的数据结构。然后利用该集合中的索引对特征进行标记。存在多个开源库，例如ECCVector瓦片Encode，用于将内存数据解析为Protobuf模式。多边形被转换为折线，这也节省了磁盘空间和渲染时间。折线只存储实际矢量而不是绝对坐标。这个官方的Protobuf编码器编写了实际的二进制文件，使用GZip压缩并存储到数据库中。

将特征集合插入现有的瓦片树需要更多解释。需要检查是否存在瓦片，以防止被新的瓦片覆盖。当旧的瓦片存在时，它被加载到内存中。根据功能和附加属性的数量，这可能会消耗大量内存。然后几何图形列表被连接起来，两个标签集都必须合并。要合并两个标签集，必须对标签和索引进行迭代。这就是将整个瓦片提取到内存中的原因。完成此操作后，Protobuf编码器将完成对瓦片的编码工作，并且可以覆盖旧的。这个过程使我们能够将新数据插入到向量瓦片树中，这是一个重要而简单的特征。这里的主要好处是，Web浏览器的地图界面框架的状态能够直接读取这种格式而无需任何修改。

我们的瓦片r提供了一个REST接口来导入文件，清空瓦片数据库，请求多种格式的单个瓦片。以下端点可用。

使用这个瓦片端点可以提供一个完整的瓦片，包括所有的几何图形和属性。根据每个瓦片的特征数量，即使经过编码和压缩，它们的大小也可能超过几兆字节。占用空间的瓦片的另一个主要原因是几何图形属性。为了只获取必要的数据，只有每个特征的唯一标识符和实际几何图形包含在瓦片中。需要标识符来引用存储中的实际数据。瓦片请求的以下参数可以用于更灵活的瓦片请求。

• filters—一个键值映射，只包含与这些属性值相匹配的特征。

• bounding_boxes—WGS84中的边界框（ bounding_boxes）数组。只提供与这些盒子匹配或相交的瓦片和几何。

• fields—一个属性键数组，在任何情况下都应该包含在特征中。

一旦请求一个瓦片，它就会从数据库加载到内存中，然后解析成一个对象模型，以便于处理。然后，与过滤器和边界框中的条件匹配的特征以及仅收集请求的属性字段。然后编码器完成其工作并将压缩后的瓦片流式传输到客户端。这种瓦片处理对于节省浏览器的传输时间和内存空间非常重要。图1说明了请求过程。下一部分描述了可视化本身，并说明了为什么这个昂贵的过程很重要。

3.3 可视化

最后，创建的瓦片可以集成到为现代网络浏览器实现的地图界面中。大多数JavaScript框架用于提供这样的界面。最常见和最稳定的框架是OpenLayers和MapboxGLJS。OpenLayers中年轻的向量瓦片实现有很多问题，最关键的是内存泄漏、没有数据驱动的样式以及没有WebGL对向量瓦片的支持。因此，使用MapboxGLJS进行评估。作为基础层，我们添加了OpenStreetMap默认的栅格图层。

在我们的用例中，向量瓦片包含仅由多边形组成的一层。我们以z/x/y格式实现的瓦片端点只是作为附加层添加到我们的地图界面中。现在瓦片被渲染在OpenStreetMap基础层之上。此时用户已经可以使用地图界面探索他们的数据。我们设法渲染了大约200万个多边形，这在大多数用例中已经足够了。人类无法区分在街道地图上渲染的这么多多边形，但它提供了一个很好的概览。对于更详细的数据，我们提供交互功能。用户可以选择单个几何图形来检查其属性。这些是使用前面提到的存储解决方案中的标识符加载的。此外，此用户界面还扩展了过滤和着色功能。可以按不同的条件过滤数据，例如时间范围、数值或离散关键字。数据驱动的样式可以应用于与数字属性相关的几何图形填充物。为此，将特定属性的最小值和最大值之间的范围内插到用户定义的颜色渐变上。用户界面还允许绘制添加为边界框过滤条件的矩形。这可以最小化每个瓦片的特征数量和每个特征的属性数量。如前所述，该系统非常灵活。任何用户界面都可以建立在我们的端点之上，这一点很重要。图2显示了用于评估的数据集的可视化，其中应用了数据驱动的着色。

4. 评估

我们方法中的每个组件都需要评估。评估以下测量和核心贡献特征。

• 存储导入时间4.1
• 瓦片过程测量4.2
• 可视化和灵活的瓦片请求4.3

4.1 导入存储

出于我们的目的，GeoJSON文件被导入PostGIS和GeoRocket，每个都包含固定数量的特征。每个要素都有一个唯一标识符和一个中等复杂的多边形。它还包含十个属性，包括数字、日期和字符串值。表1比较了两种技术的处理时间。这些数据库用于维护数据、查询原始数据部分以及执行聚合等数据分析任务。在此上下文中提及存储很重要，因为它对于正确的数据管理至关重要。导入时间随数据库导入和索引数据的特征而呈线性关系。这些时间很重要，因为它显示了数据库在实际可视化构建过程开始之前需要多长时间。

导入一个文件后，GeoServer必须完全重建覆盖区域。重要的是要了解，我们仅将GeoRocket用作维护目的的存储，另外还用于显式加载特征信息或执行聚合等数据分析任务。瓦片过程在导入时直接开始。因此，用户将比等待PostGIS数据库更快地看到第一个缩放级别。

4.2 瓦片过程测量

为了比较GeoServer和我们的拼接方法，性能测量是在GeoJSON文件上进行的，如导入过程Sect . 4.1所述。对于每个文件，配置了不同的缩放级别范围，以显示处理更高缩放级别所需的时间。创建高于15的缩放级别结果要慢得多。这样做的原因是，在更高的缩放级别上，必须将大量的瓦片或文件存储到磁盘中。根据所覆盖的区域，第17级可能达到数十亿。此评估使用两个线程线程来创建一个缩放级别。此外，每个线程处理500,000个特征的批量大小，这会阻止系统分配大量内存。一旦一个特征集合准备好构建一个实际的向量瓦片，它就会被传递给编码器，将实际的二进制文件写入瓦片数据库。图3比较了使用我们的方法和GeoServer的瓦片集创建时间。对于较小的数据集，使用我们的方法可以更快地创建或合并瓦片。当连续导入较小的数据部分时，这是一个好处。除此之外，我们的方法是灵活的。通过调整批量插入大小，可以根据数据导入流程决定缓冲更多或更少。

4.3. 可视化和灵活的瓦片请求

重要的部分是通过网络传输瓦片并提供可视化几何图形的地图界面。首先要提到的是，我们的界面使用矢量瓦片可以处理多达200万个多边形。这是足够的数量，因为人类将无法在地图界面中区分这些许多对象。这仅概述了地球上的哪些部分被数据覆盖。我们数据集中最大的瓦片，包括数千个特征和前面提到的十个属性，压缩后大小达到约15兆字节。

在这项工作中，主要贡献不仅是处理瓦片，而且还应要求提供这些服务。用户界面可以提供数据概览，而用户随后决定进一步探索哪些数据。在我们的例子中，用户对一个属性应用过滤条件，并根据两个属性启用自定义样式。此信息附在瓦片请求中。图1说明了这个请求和进一步的处理。然后瓦片服务器解码请求的瓦片，应用过滤器并仅包含标识符以及每个特征的样式所需的两个属性，然后在将瓦片提供给客户端之前对其进行编码。好处是，这个系统非常灵活。它允许用户或界面开发人员决定哪些数据应该包含在瓦片中，除了根据需要设置几何形状。可以随时使用对存储的引用来请求所有功能信息。使特征与许多属性保持清晰可加快传输时间，并使浏览器中的内存分配保持在较低水平。在我们的界面中渲染大量的几何图形是没有问题的，但是在内存中为每个特征保存许多关键字属性，例如作物类型，是非常昂贵的。如果需要，可以从空间索引数据库中按需加载这些属性。这也揭示了将完整的瓦片加载到现代浏览器中时的局限性。过滤、造型和几何图形检查等所有交互功能都可以在不重新加载数据的情况下完成，但这也会分配太多内存。这显示了大数据和现代Web浏览器的背景下的贡献。这很容易达到超过2GB，这也是大多数浏览器在一个选项卡中分配的硬性限制。其次，处理巨大的瓦片来应用过滤条件是一项成本很高的任务，也需要更深入的洞察力。

5. 结论

总而言之，我们的方法表明可以快速地连续处理数据以创建矢量瓦片数据库，而无需在每次将新数据导入存储时重新创建整个瓦片树部分。此外，我们展示了渲染大量几何图形的可能性。为了提供完整的交互，必须进行更多处理，但这也显示了系统的灵活性。

GeoServer和我们的平铺组件中的处理时间非常相似，可以同时处理大量功能。但真正的效益依赖于瓦片如何处理的工作流。首先，GeoServer在数据导入PostGIS数据库后开始构建瓦片（见表1）。在我们的方法中，用户会更早地看到第一个缩放级别，因为导入可以立即完成。我们发现缩放级别2到15足以满足大多数用例。缩放级别2提供了很好的概览，而15则有足够的细节。使用GeoServer的第二个也是更重要的限制是，必须为新导入的数据覆盖的区域完全重建瓦片。向PostGIS请求查询瓦片特定区域的所有要素以创建瓦片。我们的方法不仅可以扩展瓦片树，还可以扩展瓦片本身。在我们的用例中，数据每两周导入一次。重新创建一个完整的瓦片将导致一项耗时的任务。在我们的方法中，更新了瓦片。一旦特征集合准备好，最后保存的瓦片就会被加载，并与新数据合并。最后，它再次保存到磁盘。由于编码是处理过程中最快的部分，因此创建新的瓦片并将数据合并到现有的瓦片中并没有太大的区别。这里的限制因素是未压缩的瓦片合并或重新创建它们所需的内存空间。我们的实现还没有进行太多优化，尤其是在内存使用方面。它表明可以在合理的时间内维护矢量瓦片数据库。

仅使用矢量数据的另一个巨大好处是，图像分辨率的限制不再是问题。矢量数据传输速度更快，渲染不缺质量。

所有性能测量均在13英寸MacBookPro（2017年，16GB内存，Corei53.1Ghz处理器）上完成。该硬件应代表平均中级硬件。它具有高分辨率显示，这也使使用矢量数据的渲染质量的优势可见。

6. 未来的工作

评估部分揭示了使用最先进的矢量瓦片技术的局限性。这个想法是跟踪我们加快向量瓦片创建过程的方法，这对瓦片树的初始创建和为瓦片服务都很重要。整个瓦片解码期间的内存分配是巨大的限制。这很容易达到每瓦片5GB。GoogleProtobuf是概念设计的，必须解码整个消息才能阅读它。我们的下一步可能是有一个内部编码，以便在阅读时跳过我们的瓦片的部分内容。然后跳过未请求的功能或属性。此外，利用这种快速处理可以让我们选择应用剔除。我们发现，特别是在时间序列数据中，许多几何形状是相同的，因此会重叠。默认情况下也可以跳过这些。在可视化方面，我们希望以空间方式快速简单地概述数据。这里的主要思想是在低层次的细节上做更多的简化。我们考虑应用几何的聚类和合并。此外，在更详细的几个方面，想法是使甚至直接和持久的几何操作成为可能。我们还致力于对我们的算法和技术进行技术优化。