矢量瓦片：一种通过Web进行矢量传输的方法外文翻译资料

 2022-04-28 22:32:13

英语原文共 17 页，剩余内容已隐藏，支付完成后下载完整资料

矢量瓦片：一种通过Web进行矢量传输的方法

Vyron Antoniou1，Jeremy Morley2和Mordechai（Muki）Haklay1

1伦敦大学学院土木，环境与地质工程系

Gower St.，WC1E 6BT，伦敦，英国

2诺丁汉大学公园地理空间科学中心NG7 2RD，英国诺丁汉

{v.antoniou，m.haklay} @ ucl.ac.uk， jeremy.morley@nottingham.ac.uk

摘要：通过Web传输矢量数据是一个具有挑战性的问题。Web上矢量传输的方法主要集中在逐行传输技术上。动态泛化的形式化以及复杂算法所需的长时间导致其不能在实际应用中实现。我们提出了一种基于瓦片的Web上数据传输的的新方法。我们认为，在客户端-服务器架构中，协调所有的相关部分是创建传输矢量的有效方式。我们阐述了实现光栅数据的成功方法，即通过基于瓦片的方法来处理矢量数据传输的特殊性。

关键词：矢量数据，地理信息，Web地图，AJAX。

1.引言

从万维网（或万维网）早期开始，这种新媒体就很明显地可以促进空间信息的传播。事实上，新媒介已经大大改变了地图和地理信息的呈现和使用方式，并因此改变了制图人员设计，制作和交付地图的方式[1]。在Web 2.0的发展的帮助下，映射应用程序和空间信息现在在网络上无处不在。有趣的是，今天Web上的绝大多数地图都是基于栅格的。这是因为通过Web传输栅格数据的方法已经很完善并且易于实现。

不过，有些情况下光栅图像确实有些不足。研究人员[2] [3]指出了仅靠栅格映射应用的局限性，并且在许多情况下，Web地图应用要求用户能够直接与地图上呈现的制图实体进行交互。在探索性空间数据分析中，交互性和直接对象操作也是必不可少的[4]，[5]，[6]，[7]。

尽管映射应用程序能够托管矢量数据，但矢量地图仍然在广泛实施上遇到了困难。这些问题源自矢量数据的庞大性，还有固有缺点是每种格式到矢量编码的限制（例如通过网上的即时和高效传输）。为了解决后一个问题，经过大量的努力和试图模仿,我在在实际应用中只取得有限的成功，即用于矢量传输问题的渐进式栅格数据传输方法。

本文提出了一种通过Web进行XML和文本编码的矢量数据传输的新方法。 我们建议将矢量数据的异步平铺部分从服务器发送到客户端,这样可以帮助构建交互式Web映射应用程序，而不是创建渐进式传输技术。 主要的地图提供商如谷歌，雅虎和微软，已经成功实施了用于栅格数据传输的基于图块的方法。事实上，Web上的地图应用程序已经出现爆炸式增长,地图混搭，新地理等连续现象接连出现。[8]和VGI [9]体现出了基于瓦片技术的栅格数据传输的效率和易用性。 在本文中，我们根据矢量数据的特性进行特意提出了一种基于瓦片的数据传输方法，该文件的结构如下：在第2节中，我们介绍有关该主题的相关工作。 所提出的方法在第3部分中进行了解释，随后在第4部分中进行了评估。

2.相关工作

2.1栅格数据传输

许多用于栅格数据的渐进式传输技术已经被引入了。[2],[10]和[3]提供了这些技术的评论，并简要介绍了他们的主要特点。一般来说，高度复杂的压缩算法和交错传输方法使栅格格式适合通过Web传输数据。这些方法的效率使地理信息（GI）社区能够使用栅格数据构建大多数Web地图应用程序，从而轻松地向用户提供空间信息。

Web的发展以及追求更高的响应能力并提高Web应用程序的可用性导致我们开发新的编程技术，如AJAX（异步JavaScript和XML），以及一种使用平铺的栅格图像和不同的栅格图像的新的栅格数据传输方法详细程度（LoD）。根据这种方法，映射区域的最高LoD被分成许多象限（瓦片）。这些象限中的每一个都被进一步细分成新的瓦片，形成下一个LoD。这个过程一直持续到达到最低的LoD。尽管这可能会导致大量数据集中的大量图块，但是对于光栅文件的存储，索引和处理非常简单，特别是在数据存储变得更便宜的情况下。

当给定的LoD的地图被请求时，多个瓦片被发送给用户。这些图块作为矩阵被加载到Web浏览器窗口中，从用户的角度来看，它似乎是连续的图像。对于任何后续的请求，如平移、缩放或管理图层，在客户端的Web浏览器上运行的应用程序发出新的请求，并且服务器仅向客户端发送除了当前在客户端缓存中所需的图块之外所需的图块。由于使用AJAX技术通过与服务器进行通信而不需要用户实际注意到它，可以减少应用程序的响应时间，这种方法使得应用程序更快速，响应更快。

2.2 矢量数据传输

矢量数据量和通过Web传输它的难度一直是Web地图和WebGIS长期存在的问题。渐进式光栅数据传输方法的成功将研究重点转向开发类似于矢量编码的相似技术。

针对矢量数据的特定情况，我们已经引入了渐进式传输的有效方法：三角形网格。三角形网格通常用于描述数字地形模型或3D对象的表面。相反，尽管作出了许多努力，但网络上地图矢量数据的逐步传输仍然存在问题（参见[2]，[3]和[11]进行审查）。根据渐进式传输方法，最初发送给用户较粗略的地图版本，并根据用户的要求发送连续的数据包以改善地图。较粗略的地图版本可以在请求时动态生成（即时），也可以通过泛化过程预先计算。即时通用化是制图的一个未解决的问题。一些研究人员专注于动态泛化（[12]，[13]，[14]）以加强渐进式矢量传输，但由于没有形式化的制图泛化原理和适用的泛化操作符[15]，自动动态泛化仍然是一个挑战。而且，现有的泛化算法需要时间，因此不适用于真实的Web应用程序。 动态泛化的另一个缺点是它在保留拓扑和几何属性方面会产生不一致的结果，因此往往需要对其一致性进行后验评估。根据文献[11]，他人已经提出了一种拓扑一致的方法，除了面积小于给定阈值的孤立多边形和属于最小类别的线（例如河网中的一阶流）。

另一方面，离线泛化和创建不同的LoD是测绘机构的日常工作。在这种情况下，泛化的时间是不敏感的，通常由专业制图人员在专业软件的帮助下交互式地执行[12]。 有人[2]提出了一种用于预先计算和存储适合于逐步传输给用户的多个地图表示的方法，但没有进一步的实施。尽管维护不同的LoD非常麻烦，但离线泛化会产生拓扑和几何精度较高的产品，而用于维护多LoD栅格数据库的类似数据管理技术可应用于此类矢量数据库。

渐进式数据传输的优势依赖于用户即使在较粗糙的地图版本上也可以执行初步操作，或者他们可以评估所请求的地图的适用性，并且可能在不等待的情况下更改请求为整个数据集下载。该过程如图1所示，其中A，B，C，D1和D2是该过程的各个时间段。期间A是鼠标移动期间的时间，B是用户等待加载地图的较粗版本的时间，C是服务器需要提取数据的时间。D1是用户观察地图的时间，而D2则是用户观察完整详细地图的时间。渐进式传输使用户能够在整个地图下载之前开始观测地图。

图1.逐步传输矢量数据的步骤和时间段

认识到需要更高效的传输方法，一些关于矢量平铺的早期工作（[16]，[17]）已经被引入了。这些方法基于矢量图块的离线准备，它在地图准备和维护中引入了额外的步骤（即为每个LoD创建和维护图块）。主要的缺点在于所提出的方法主要集中在简单的地图可视化上，而不提供客户端瓷砖的合并机制。因此，向用户呈现由在瓦片的边缘处的分割实体组成的地图，这导致真实实体与呈现给用户的地图实体之间的语义不一致。相反，在[18]中，我们建议为服务器上的数据实时平铺和合并客户端上的磁贴提供解决方案的机制，这样做会更加合适。

3.方法

这里介绍的方法不是试图实现适合矢量数据需求的渐进式传输技术，而是采用基于瓦片的方法。简而言之，根据这个方法，只有当数据尚未发送给用户时才将异步数据请求提交给服务器，否则从浏览器的高速缓存中读取数据。当用户的请求到达服务器时，数据将被分割为多个区块，然后发送到用户的浏览器。在用户的机器上，瓷砖被合并，并且最终地图被呈现给用户（在典型地图请求之后的步骤参见表1）。这种方法提供了一种使用AJAX向客户端传输矢量数据的方法，但它不能解决动态矢量泛化的问题。因此，这种方法适用于我们预先准备好多分辨率空间数据库的情况。可以理解的是，基于客户端服务器架构的方法的有效实施需要所有参与部分（空间数据库，服务器，用户浏览器和地图文档本身）的协调。在接下来的内容中，我们将重点介绍地图文档的结构，地图文档与浏览器和服务器的交互以及地图准备（即图块合并）等方法的体系结构。

3.1地图文件

地图文件结构上的作用是方法论的核心。地图文档有三个不同的层（图2）。第一层由一个5x5的瓷砖网格（背景区域）组成。该图层对用户不可见，但用于保存由服务器或浏览器的缓存存储器发送到地图文档的平铺数据。此外，此图层还将数据提供给地图文档的下一层。第二层（可视区域）由3x3的瓷砖网格组成。这些瓷砖是从背景区域（第一层）克隆的。它的作用是保存要合并的数据，然后分配给文档下一层的专题图层。第三层（地图区域）由一个瓦片组成。该图层是用户请求的实际地图，并根据制图规则从专题图层进行编译。

图2.地图文件的结构

将文档的一部分数据克隆到另一部分是由用户的操作触发的。 当用户请求查看（通过平移地图）更多数据时，已经存储在文档隐藏区域的图块将被克隆到合并区域，合并区域会发生几何合并（参见下一段），并最终被分配给正确的专题图层，作为最终地图呈现给用户。与此同时，地图文档通过从浏览器的缓存或服务器请求新数据，为下一次用户操作做好准备。

3.2合并

整个方法学的一个重要步骤是在客户端进行合并过程。存储在可视区域的9个图块中的每个图块中的几何图形在被分配到正确的专题图层之前被合并。这一步是需要的，因为提交给用户的地图实体应该与存储在数据库中的实体逻辑一致。例如，如果一个多边形在从数据库中提取的过程中被分成两个多边形（每个多边形都存储在不同的图块中），那么当呈现给用户时，这些多边形应该合并回一个实体。这将允许用户与地图元素正确交互。由于专题图层可以保持点，线或多边形的几何形状，因此每种类型的几何图形都需要合并机制。

3.2.1点

点的合并是微不足道的，因为唯一需要的是克服从瓦片到最终专题图层的所有点。Javascript可以轻松解析XML文档的文档对象模型（DOM）并将数据从文档的一部分克隆到另一部分。

3.2.2 线

行的合并基于使用唯一的功能ID。 ID用作在可视区域的9个区块内搜索的键。具有相同ID的线段被分组，然后加入单个实体。这样的连接可能会导致一个多段线特征具有共同点时，或者在具有相同ID的段之间没有共同点的情况下，如何拆分为块（图3）取决于数据库中存储的原始线。

图3.合并不同拼贴中的线会导致：（a）折线元素或（b）多折线元素

3.2.3 多边形

唯一ID也用于合并多边形。 再一次地，共享相同ID的多边形被分组，然后合并成多边形或多边形实体。 尽管存在多边形合并的情况，但为了消除所有可能的情况而提出了更大的难度。主要障碍是存在在拼贴过程中产生的不需要的边界线（参见[19]第3章关于空间操作的详细信息以及如何通过拼接相交过程生成新的线段）。例如，图4a和4b显示了边界线外观的两种不同情况。在图4a中，需要在拼贴过程中生成的多边形边界线，以实现呈现给用户的多边形的正确着色。相反，在图4b中，相同的边界线导致不希望的视觉效果。在图4c中显示了在4b中渲染多边形的合并部分的正确方法。

图4.在多边形合并期间处理边界线

尽管如此，在合并阶段拼接过程中产生的边界线也是必要的，因为它们有助于阐明多边形的渲染。例如，图5显示当边界线不存在时，多边形应如何着色并不确定。

图5.多边形着色的模糊情况

为了解决这个问题，我们需要同时拥有多边形的边界线和关于在合并过程中何时应该使用每条边界线的指示。由于边界线是由多边形和平铺的交叉点产生的，因此这些边界线几乎与平铺的轮廓重合。我们需要记录瓷砖的哪一侧（1，2，3或4）（见图6）有创建的边界线。 这个元素允许我们在合并过程中创建一组关于是否包含边界线的规则。 例如，只有在瓦片放置在3x3网格的（0，j）位置时，与瓦片的数字1边重合的边界线才应包含在该过程中。 在任何其他情况下，边界线应被排除在外。

图6.将指标分配给边界线的方法

通过这样做，在图4a所示的情况下，边界线将被用于形成多边形的轮廓，但是在图4b所示的情况下，边界将在合并过程中被排除。 这种方法已经在所有可能的多边形例如环形多边形，岛状多边形或多部分多边形中成功地进行了测试。最后，表1描述了在地图文档中发生的步骤。

表 剩余内容已隐藏，支付完成后下载完整资料

资料编号：[464942]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章