摘要

針對大眾 ＧＩＳ 應用與服務對線上地圖表達和效能要求越來越高，向量瓦片成為地圖引擎的首選，該文從地圖向量切片模型、編碼規則、技術流程與跨平臺應用研究等多角度，以主流的切片工具 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ 、 ＧｅｏＳｅｒｖｅｒ 、 ＡｒｃＧＩＳ　Ｐｒｏ 為例，對不同的地圖向量切片方案，從自定義向量製圖、切片環境、切片機制等方面進行了定性定量對比分析。結果表明：不同切片工具由於其切片環境和機制的不同，切片效率各有不同，適用於各自不同的應用場景，為線上網路地圖引擎設計、開發和應用提供了技術參考。同時，該文提出通過自定義微服務閘道器的方式實現多套向量瓦片服務對應多客戶端呼叫需求，實現向量瓦片跨平臺應用。

關鍵詞

網路地圖服務；向量瓦片；切片編碼；切片效能

０. 引言

隨著網際網路時代的飛速發展和人們生活水平的不斷提高，傳統紙質地圖已經慢慢退出歷史舞臺，電子地圖已經成為人們工作和生活不可缺少的重要工具，從出差遠行到生活購物，對地圖的應用無處不在。地圖瓦片的出現，使得谷歌、高德、百度地圖等地圖產品迅速發展壯大，通過金字塔模型生成的柵格瓦片資料，提高了地圖的影響速度，大大改善了地圖實用性。隨著技術的不斷髮展，地圖呼叫不再拘泥於原始的預先生成的柵格瓦片，向量瓦片開始興起，充分利用前端渲染的靈活性和互動性，向量瓦片成為當前地圖應用的熱點 ［１ － ２ ］ 。

目前，關於向量瓦片的研究並不十分成熟，相關標準並不統一，其應用尤其在專業應用方面也並不十分廣泛。文獻 ［３ ］基於網路的向量瓦片技術研究，指出了向量瓦片地圖在互動性、渲染效果方面的優勢，但是對於離線環境下的應用並未研究。文獻 ［４ ］通過開發線上互動視覺化工具，對向量瓦片的動態視覺化渲染進行了深入研究，豐富和簡便了地圖視覺化表達。文獻 ［５ ］針對向量瓦片的點狀要素註記處理也進行了深入研究，解決了動態渲染過程中傳統註記壓蓋問題。文獻 ［６ ］基於 Ｍａｐｂｏｘ對向量瓦片資料組織、編碼規則等關鍵技術進行了深入研究。文獻 ［７ ］基於 Ｍａｐｂｏｘ向量瓦片的應用也做了較為深入的開發研究。

本文對當前主流的向量瓦片解決方案進行了
深入歸納和探討，並對各解決方案進行了實驗測
試和優劣勢對比分 析，提 出 一 種 跨 平 臺 使 用 方
法，為地理資訊開發者使用向量瓦片服務提供了
參考。

１. 向量切片

當前，電子地圖瓦片主要分為柵格瓦片和向量瓦片，但隨著地圖資料更新頻率的提升，傳統柵格瓦片地圖由於切片速度慢、不易更新等問題日益凸顯，使得向量瓦片的應用越來越受到使用者的青睞。

如表１所示，在切片大小方面，向量切片有較大的優勢；以青島全市域現狀電子地圖為例，採用柵格瓦片切圖， ９～２０級全瓦片總量約３６．５ＧＢ ，切片時間需３～５ｄ ，且對儲存空間、網路頻寬的佔用非常大；而同樣範圍向量瓦片包有２００ ＭＢ左右，約２００倍的壓縮空間，不到１ｈ即可完成切片任務。視網膜螢幕是蘋果公司推出的解析度超過人眼識別極限的高解析度螢幕，對於在客戶端渲染的向量切片，其顯示效果更好。

目前，網際網路地圖服務商除了ＢｉｎｇＭａｐ 、搜狗地圖、 ＯｐｅｎＳｔｒｅｅｔＭａｐ 仍然使用柵格瓦片服務外，百度、高德、谷歌地圖已經全面採用向量瓦片引擎作為優選地圖渲染引擎。

1.1 向量瓦片原理

傳統柵格瓦片切片原理是以四叉樹金字塔模型直接切割地圖圖片，最終表現為金字塔分層的２５６畫素×２５６畫素的 ＰＮＧ 圖片，或相應的基於圖片的壓縮包格式。向量瓦片切片原理同樣是基於四叉 樹 金 字塔 模 型，不 過，切 割 的 不 再 是 柵格圖片，而 是矢 量 數 據 的 描 述 性 文 件，存 儲 的是投影範 圍 內 所 屬的 幾何資訊和 屬 性 信 息，表現為向量 瓦 片 能 力文 檔，最 終客戶 端 根 據 地 圖顯示範圍 從 服 務 器獲 取相應的矢 量 信 息，通 過讀取圖層的樣式檔案ｓｔｙｌｅ在客戶端實現地圖的實時繪製 ［８ － １１ ］（圖１）。

1.2 向量切片格式

當前應用較廣的儲存格式主要有 ＧｅｏＪＳＯＮ 、ＴｏｐｏＪＳＯＮ和 Ｇｏｏｇｌｅ　Ｐｒｏｔｏｃｏｌ　Ｂｕｆｆｅｒｓ （ ＰＢＦ ）。ＧｅｏＪＳＯＮ是一種對各種地理資料結構進行編碼的格式，基於ＪａｖａＳｃｒｉｐｔ物件表示法的地理空間資訊資料交換格式。 ＧｅｏＪＳＯＮ物件可以表示幾何、特徵或者特徵集合。 ＧｅｏＪＳＯＮ支援下面幾何型別：點、線、 面、 多 點、 多 線、 多 面 和 幾 何 集 合。ＧｅｏＪＳＯＮ裡的特徵包含一個幾何物件和其他屬性，特徵集合表示一系列特徵 ［１２ － １３ ］ 。 ＧｅｏＪＳＯＮ 易讀性好、但冗餘度最大，幾乎所有主流的 ＧＩＳ引擎都支援 ＧｅｏＪＳＯＮ格式動態渲染電子地圖資料。

ＴｏｐｏＪＳＯＮ是 ＧｅｏＪＳＯＮ 按拓撲學編碼後的擴充套件形式，相比 ＧｅｏＪＳＯＮ 直接使用 Ｐｏｌｙｇｏｎ 、 Ｐｏｉｎｔ之類的幾何體來表示圖形的方法， ＴｏｐｏＪＳＯＮ 中的每一個幾何體都是通過將共享邊（被稱為ａｒｃｓ ）整合後組成的。由於 ＴｏｐｏＪＳＯＮ 邊界線只記錄一次，地理座標使用整數不使用浮點數，因此大幅消除了冗餘，檔案大小縮小了８０％ 。但 ＴｏｐｏＪＳＯＮ 易讀性較差，需要專門工具根據規則進行轉換，支援該格式的軟體並不多，其中最著名的是目前開源 Ｗｅｂ三維的代表ＣｅｓｉｕｍＪＳ［ １４ ］ 。Ｇｏｏｇｌｅ　Ｐｒｏｔｏｃｏｌ　Ｂｕｆｆｅｒｓ是一種節省儲存空間的向量瓦片資料編碼格式，是相容多語言、多平臺、易擴充套件的資料序列化格式，這種格式應用於客戶端或服務端高效渲染或查詢要素資訊。依據其標準制作的向量瓦片標準目前幾乎成為向量瓦片的行業標準，當前主流的 Ｍａｐｂｏｘ採用的向量瓦片 就 是 基 於 ＰＢＦ 編 碼 ［１５ － １６ ］ ， 超 圖、 ＡｒｃＧＩＳ ＯｐｅｎＬａｙｅｒｓ 、 ＧｅｏＳｅｒｖｅｒ都支援該種格式。

目前，百度、高德、谷歌等都採用自定義瓦片格式，本文不做重點介紹。

1.3 向量瓦片編碼

1.3.1 幾何圖形編碼

ＧｅｏＪＳＯＮ和 ＴｏｐｏＪＳＯＮ 中，向量瓦片中的幾何資料記錄的都是原始的座標。對於 ＰＢＦ編碼方
案，向量瓦片中的幾何資料被定義為螢幕座標系。以瓦片的左上角定義為（顯示預設如此）座標系的原點。 Ｘ 軸向右為正， Ｙ 軸向下為正。幾何圖形中的座標必須為整數。幾何圖形被編碼為要素的ｇｅｏｍｅｔｒｙ 欄位的一個３２位無符號型整數序列。每個整 數 是 ＣｏｍｍａｎｄＩｎｔｅｇｅｒ 或 者 ＰａｒａｍｅｔｅｒＩｎｔｅｇｅｒ 。解碼器解析這些整數序列作為生成幾何圖形的一系列有序操作。指令涉及的位置是相對於 “遊標”的，即一個可重定義的點。對於要素中的第一條指令，遊標位於座標系中的位置是（０ ， ０ ）。有些指定能夠移動遊標，因而會影響到接下來執行的指令。

以圖２幾何要素的儲存面要素為例，面要素的３個座標依次是（３ ， ６ ）、（ ８ ， １２ ）、（ ２０ ， ３４ ），在編碼過程中，首先將座標資訊轉化為指令集，最後將指令集編碼儲存為PBF檔案。

1.3.2 要素屬性編碼

ＧｅｏＪＳＯＮ 和 ＴｏｐｏＪＳＯＮ 中， 矢 量 瓦 片 中 的屬性資訊直接在檔案中以物件陣列的形式儲存，
內容本身並未進行壓縮。而 ＰＢＦ 格式檔案，要素屬性被編碼為 ｔａｇ 欄位中的一對對整數。在每對ｔａｇ
中，第一個整數表示ｋｅｙ 在其所屬的ｌａｙｅｒ的ｋｅｙｓ列表的中索引號。第二個整數表示 ｖａｌｕｅ
在其所屬的ｌａｙｅｒ的 ｖａｌｕｅｓ列表的中索引號。一個要素的所有 ｋｅｙ 索引必須唯一，以保證要素中
沒有重複的 屬 性 項。每 個 要 素 的 ｔａｇ 字 段 必 須為偶數。要 素 中 的ｔａｇ 字 段 包 含 的 ｋｅｙ 索 引 號
或 ｖａｌｕｅ 索引 號 必 須 不 能 大 於 或 等 於 相 應 圖 層中 ｋｅｙｓ或 ｖａｌｕｅｓ列 表 中 的 元 素 數 目， 如 圖 ３所示

2. 向量切片方案

當前，向量 切片工具主要 有 Ｍａｐｂｏｘ 、 ＧｅｏＳｅｒｖｅｒ 、 ＡｒｃＧＩＳ　Ｐｒｏ 等，各 種 工 具 運 行 環 境 不一，面向物件也各有不同。但向量瓦片的總體切片技術流程基本一致，首先就是向量資料的準備，如Ｓｈａｐｅｆｉｌｅ 、 ＪＳＯＮ 等資料格式；矢 量 瓦 片 的 製作，基於各自不同的切片機制進行，但切片原理都遵循向量四叉樹金字塔模型，最終表現為各自向量瓦片格式包；向量瓦片的釋出工具眾多，如ＳｐａｔｉａｌＳｅｒｖｅｒ 、 ＡｒｃＧＩＳ　Ｓｅｖｅｒ 、 ＧｅｏＳｅｒｖｅｒ ，都 是 成熟的向量瓦片釋出工具，客戶端基於 ＷｅｂＧＬ進行矢 量 地 圖 的 渲 染 顯 示，總 體 技 術 流 程 如 圖 ４所示。

2.1 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ

Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ［ １７ ］ 是 Ｍａｐｂｏｘ推出的向量地圖製作和釋出的工具，提供標準的專業化製圖方案。Ｍａｐｂｏｘ 目前線上提供 ６ 種風格底圖滿足不同的場景需求；但 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ是一個線上工具，即對於釋出自己的地圖資料，需要註冊使用者、購買空間並將資料上傳到 Ｍａｐｂｏｘ ，採用 Ｍａｐｂｏｘ線上配圖工具配置自己的地圖。

2.2 ＧｅｏＳｅｒｖｅｒ

ＧｅｏＳｅｒｖｅｒ［ １８ ］ 是 ＯｐｅｎＧＩＳ　Ｗｅｂ 伺服器規範的開源 ＧＩＳ伺服器，可以對包括向量資料在內的各類 ＯＧＣ標準 ＧＩＳ資料進行快取切片和服務釋出。作為完全開源的 ＧＩＳ伺服器，無論是柵格還是向量， ＧｅｏＳｅｒｖｅｒ都可以很好的支援。

2.3 ＡｒｃＧＩＳ　Ｐｒｏ

ＡｒｃＧＩＳ　Ｐｒｏ［ １９ ］ 作為 ＥＳＲＩ新推出的桌面端製圖軟體，支援向量配圖和切片，而且 ＡｒｃＧＩＳ　Ｐｒｏ向量瓦片方案已經基本達到電子地圖柵格瓦片顯示效果。不同於 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ和ＧｅｏＳｅｒｖｅｒ向量瓦片的ＰＢＦ格式， ＡｒｃＧＩＳ　Ｐｒｏ推出緊湊型快取的儲存格式ｂｕｎｄｌｅ ，相比ＰＢＦ ，瓦片遷移更加方便、建立更快、減少儲存空間，便於區域性區域更新的實現。

3. 方案對比

各種向量切片方案都有各自的應用場景和適用物件，本文從自定義向量製圖、切片環境、切片機制３個角度進行對比分析。實驗採用的資料為青島市 全 域 電 子 地 圖。測 試 環 境 為 ＴｈｉｎｋＰａｄＴ４８０膝上型電腦，作業系統是 Ｗｉｎ１０ ， ＣＰＵ 為Ｉ５ － ８２５０Ｕ＠１．６ＧＨｚ ， ３２ＧＢ記憶體，採用 ＮＶＩＤＩＡ
Ｇｅｆｏｒｃｅ　ＭＸ１５０顯示卡。

3.1 自定義向量製圖

ＧｅｏＳｅｒｖｅｒ的自定義向量配圖沒有任何的配置檔案可供參考，相對難度較高。 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ線上提供眾多成熟的字型、圖示、風格等樣式檔案，可以供開發者很好的參考，在自定義過程中可以減少很多標準配置的問題。 ＡｒｃＧＩＳ　Ｐｒｏ相對成熟，提供成熟的樣式風格檔案作參考，在自定義過程中有章可循。

3.2 切片環境

Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ是線上工具，因此需要網際網路的支援，離線環境下不能使用； ＧｅｏＳｅｒｖｅｒ提供開源包，可以部署離線 Ｂ ／ Ｓ執行環境； ＡｒｃＧＩＳ　Ｐｒｏ是ＥＳＲＩ新一代桌面端軟體，同樣可以在離線環境下執行。

3.3 切片機制

在處理向量化資料時，記錄中往往會存在許多重複資料，對進一步資料處理帶來諸多不便。多餘的資料，一方面浪費了較多的儲存空間；另一方面造成所要表達的圖形不光滑或不符合標準。為保證資料壓縮和效能優化的問題，需要進行資料的抽稀，保證反映原圖形或曲線的基本形狀特徵同時，能夠為進一步的處理節省空間和時間。

對於 ＧｅｏＳｅｒｖｅｒ ，在小比例尺階段需要進行資料抽稀，但抽稀過程中由於相鄰資料抽稀規則不完全一致，導致面狀資料出現拓撲混亂，最終部分級別顯示效果較亂。同樣，在較大比例尺階段，很多資料要素已經達到飽和，不再需要抽稀，但ＧｅｏＳｅｒｖｅｒ依舊會生成同上一級一樣的未抽稀的向量瓦片資料，最終導致資料量很大。

ＡｒｃＧＩＳ　Ｐｒｏ向量切片採取相對智慧的策略，不會根據地圖顯示級別一切到底，比如０～１９級別地圖，由於１５級資料已近似沒有資料抽稀的情況，能夠支撐後面更大比例尺地圖顯示需要，這樣１６～１９級資料無須再進行抽稀。這種策略可以大幅減少地圖瓦片包的容量，但要求調圖客戶端同樣支援這種策略，在 ＡｒｃＧＩＳ　ｆｏｒ　ＪａｖａＳｃｒｉｐｔ　ＡＰＩ系列版本中，目前只有最新版本４．ｘ系列適應這種策略。因 Ｍａｐｂｏｘ　Ｓｔｕｄｉｏ需要聯網上傳資料，因資料精度較高、資料保密性等原因沒有開展該項測試。實驗中，對青島市全域向量電子地圖分別使用 ＧｅｏＳｅｒｖｅｒ 、 ＡｒｃＧＩＳ　Ｐｒｏ進行向量切片，切片級別為０～１９級，各級別比例設定及切片各級別大小、所需時間如表２所示。

實驗切片快取大小結果對比如圖 ５ 所示，橫軸表示切片級別，縱軸表示總切片大小，由於抽稀策略的不同，發現 ＡｒｃＧＩＳ　Ｐｒｏ切出的青島市全域向量切片包只有２００ ＭＢ ；使用 ＧｅｏＳｅｒｖｅｒ的向量切片包約是１．８ＧＢ ， ＧｅｏＳｅｒｖｅｒ向量切片保留了原始資料的所有屬性資訊，因此導致資料冗餘度高，向量瓦片包較大。切片時間對比如圖 ６ 所示，橫軸表示切 片 級 別，縱 軸 表 示 每 級 切 片 時 間，由 於ＧｅｏＳｅｒｖｅｒ的每級快取包更大，因此在切片時間上也相對較長。

綜上所述，受不同的切片機制的影響，不同切片方案的差別主要表現在向量切片包大小、資料抽稀、資料屬性３個方面，具體如表３所示。

4. 跨平臺應用

通過上述實驗可以看出，相比柵格電子地圖瓦片，向量切片方案可以大大提高切片效率，上述３種向量切片方案各有其侷限性和應用場景，比如 ＭａｐＢｏｘ僅支援網際網路環境、 ＧｅｏＳｅｒｖｅｒ配置複雜優化不足、 ＡｒｃＧＩＳ　Ｐｒｏ需要 ＡｒｃＧＩＳ企業版釋出等。在實際應用中，一般來說每個平臺軟體自帶客戶端 ＡＰＩ都支援各自向量瓦片訪問規則。為實現客戶端 ＡＰＩ相容其他瓦片格式從而達到向量地圖瓦片跨平臺應用，常規解決辦法是客戶端自行擴充套件 ＡＰＩ ，比如開源地圖引擎Ｌｅａｆｌｅｔ．ＪＳ即通過定製 ＡＰＩ方式實現了對 ＭａｐＢｏｘ和ＥＳＲＩ向量瓦片的呼叫。但該種方式需要客戶端開發人員充分了解每種瓦片的編碼規則，且給客戶端開發造成額外工作量，提升了客戶端複雜度。本文研究過程中嘗試了另一種思路解決了向量瓦片跨平臺應用，即在不改變向量瓦片原始儲存和服務規則的情況下，通過自定義微服務閘道器的方式實現多套向量瓦片服務對應多客戶端呼叫需求。

4.1 實現思路與過程

採用ＰＢＦ格式的向量瓦片服務規則稍有差別，以ＥＳＲＩ和 ＭａｐＢｏｘ向量瓦片為例，兩者向量瓦片訪問樣式 ［２０ ］ 分別為：

除向量瓦片伺服器基本路徑規則外行列號也相反，為實現服務相容性，本文開發了微服務閘道器接收不同客戶端訪問樣式，並在後臺進行轉換成另一種樣式後向實際瓦片伺服器傳送請求獲取實際資料後再轉發給客戶端。如圖７所示，實現服務 － 資料請求，從１對１到 ｎ 對 ｎ 的轉變。

4.2 應用效果與侷限

通過微服務閘道器中轉方式，從原客戶端到伺服器１對１的請求與響應變成了多對多的請求相應，從而實現了不需客戶端做任何調整的真正跨平臺的向量瓦片呼叫。但該種方式目前僅實現了ＰＢＦ格式的轉發，如進一步實現ＪＳＯＮ 、 ＴｏｐｏＪ －ＳＯＮ 、 ＰＢＦ多種資料格式的轉發尚需進一步開發資料底層編碼的轉換方法，對伺服器端運算資源是一筆不小的開銷。

5. 結束語

雖然柵格瓦片仍有其不可忽視的優勢，但隨著網際網路和移動 ＧＩＳ的發展，向量瓦片已漸漸成為 ＧＩＳ應用和地圖視覺化的主流；高效的切片和快速應用是 ＧＩＳ發展的趨勢。本文對向量切片的原理進行了深入分析，並從自定義切圖、切片環境、切片 機 制 等 角 度 重 點 對 比 分 析 了 ＭａｐｂｏｘＳｔｕｄｉｏ 、 ＧｅｏＳｅｒｖｅｒ 、 ＡｒｃＧＩＳ　Ｐｒｏ　３個主流向量切片工具的異同，提出了跨平臺應用方法。不足之處，本文對於３個方案的交叉研究不夠深入，如基於ＧｅｏＳｅｒｖｅｒ釋出工具 ＋ Ｍａｐｂｏｘ －ｇｌ－ ｊｓ　ＡＰＩ前端渲染，徹底實現離線化的研究，還有待於進一步突破。