摘要

網路地圖應用程式的最新發展對背景地圖（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連線速度較慢的站點進行訪問的應用程式。雖然柵格瓦片是當今底圖的事實標準，但是可以預期向量瓦片在不久的將來也會同樣流行。