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連接速度較慢的站點進行訪問的應用程序。雖然柵格瓦片是當今底圖的事實標准，但是可以預期矢量瓦片在不久的將來也會同樣流行。