移動端H5地圖矢量SHP網格切分打包方案

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1.背景

與離線瓦片方案同樣，一樣是爲了解決移動端網速和流量問題，可是卻不只僅於此。傳統的矢量數據的展現通常分爲兩種方案：

• 經過WMS動態獲取範圍內的矢量數據圖片（矢量數據由後臺處理成一張圖片返回），在前端疊加展現。
  優勢——渲染壓力在後端，前端無壓力。後臺對圖片更容易作緩存（前端把地圖切分紅格網，以WMS請求模擬WMTS請求）。
  缺點——當前端須要交互時，必須進行動態的根據座標查詢地理服務器（I查詢）。響應稍慢，對後端壓力大。
• 經過WFS服務獲取範圍內的矢量數據文本（geojson、pbf等格式），前端解析返回數據動態渲染。
  優勢——因爲是前端渲染展現，交互便捷，而且能夠在前段只有控制樣式。
  缺點——後臺和前端在獲取數據和展現數據上均有壓力，當數據量特別大時，前端渲染耗費性能容易卡頓。

而該方案上，當咱們將SHP矢量數據以必定算法處理成文本文件存放到移動端後，既能夠避免動態獲取數據對服務端的壓力，也能夠擁有WFS方案上在前端實時渲染數據時的樣式制定和交互便捷的優勢。
整個方案優勢總結爲：

• 規避手機網速問題
• 規避手機流量問題
• 減小服務端壓力
• 前端要素展現樣式可定製
• 要素交互快速響應

2.兩種離線算法，兩種離線矢量數據處理方案的描述對比

2.1方案一（分級矢量切片方案）

方案描述

矢量切片方案在我以前的文章中均有描述：項目角度談矢量切片運用以及Geoserver處理自定義規格矢量切片方案以及WebGIS中矢量切圖的初步研究。簡單敘述爲：

• 把矢量數據當作瓦片處理，根據切圖原點、瓦片大小、各級別分辨率，先在不一樣級別對SHP進行抽稀簡化，而後將該級別的SHP切分紅對應矢量數據塊，再處理成文本格式。
• 將矢量切片上傳至移動端，H5地圖請求獲取本地矢量切片，解析渲染。

方案分析

• 優勢: 各級別數據抽稀切片，使得各級別數據量加載都可控制，前端渲染數量也處於可控狀態。
• 缺點：因爲要切不一樣級別下的數據，矢量切片比較耗費時間，並且切圖數據量大。不利於快速實施。

2.2方案二（固定網格切片方案）

方案描述

• 以固定幾何大小的網格對SHP數據切片處理成文本。
• 前端實時根據此時的可視範圍，基於預製的網格切片大小，算出此時範圍下對應的各切片，請求加載，解析渲染。

方案分析

• 優勢：只需根據預製的網格大小將矢量數據一次切割生成，效率比較高。
• 缺點：在地圖級別很小顯示全圖時，加載的切片數量過多致使前端渲染壓力很是大。

2.3方案選型

• 方案二優於方案一最大的地方在於實施更快速。
• 方案二最大的缺點是在低地圖級別時顯示的數據過量問題，這裏能夠經過兩個手段規避。
  控制顯示層級——即只讓地圖縮放至某個級別上時才加載該矢量數據。
  控制顯示數量——將網格數據進一步以責任網格打包，固定人員只展現固定責任網格範圍內的數據。

3.矢量數據網格切分打包工具的實現

3.1SHP數據網格切分詳細描述

• 得到該圖層的幾何範圍，依據切圖原點、網格大小，算出該圖層對應的網格數量（colnums、rownums）以及網格的起始切片的行列編號(startcolnum、startrownum）。
• 以colnums和rownums做爲雙循環遍歷結束點，依次將圖層中的要素切片，處理成文本文件。
  代碼描述：

//計算格網行列號 int colNums = 0, rowNums = 0; colNums = Convert.ToInt32(Math.Ceiling((_maxX - _minX) / inputGridSize)); rowNums = Convert.ToInt32(Math.Ceiling((_maxY - _minY) / inputGridSize));

3.2基於單元網格的已有切片打包描述

選用單元網格圖層進行打包，主要緣由爲單元網格爲最小劃分網格，變更相對較少，減小實施次數。利用網格將已有的切片再進行整合打包，可進一步控制前端展現時的矢量數據數量。

• 遍歷獲取網格圖層中的網格要素，獲得各要素的幾何範圍。
• 依據幾何範圍、網格大小、切圖原點，算出該範圍內包含的瓦片編號。
• 將這些瓦片拷貝至以（要素編碼\部件類型編號)命名的文件夾中。
• 遍歷處理完全部數據拷貝後，進行總體的文件壓縮。

注意：
瓦片的打包路徑規範爲：

工具界面爲:

4.H5地圖前端展現實現

4.1詳細描述

前端展現所用算法與網格打包時所用算法相同。JS獲取本地數據的思想方法也與我在移動端H5地圖離線瓦片方案中描述的移動端讀取本地瓦片的方法相同。不作累述，核心代碼以下:

var originx=parseFloat(gridClipParams[0]); var originy=parseFloat(gridClipParams[1]); var size=parseFloat(gridClipParams[2]); var vectorSource = new VectorSource({ format:format, url:function(extent) { var temurl=GeosService.queryContent(url,servicelayerid,where,extent); if(useMobileCache){ var col=Math.floor(Math.abs((extent[0]-originx))/size); var row=Math.floor(Math.abs((extent[1]-originy))/size); //本地測試url //temurl="http://192.168.32.135:8080/gis/tilemap/11010100100907/"+subtypeid+"/"+row+"/"+col+".json"; temurl =self.offlineURL+encodeURIComponent(temurl)+"&row="+row+"&col="+ col+"&layername="+subtypeid; } return temurl; }, strategy: function(extent,resolution){ var minx=extent[0]-size; var miny=extent[1]-size; var maxx=extent[2]+size; var maxy=extent[3]+size; var m=Math.ceil((maxx-minx)/size); var n=Math.ceil((maxy-miny)/size); var extentArr=new Array(); for(var i=0;i<m;i++){ for(var j=0;j<n;j++){ var temextent=[]; var temminx=minx+i*size; var temminy=miny+j*size; var temmaxx=minx+(i+1)*size; var temmaxy=miny+(j+1)*size; temextent=[temminx,temminy,temmaxx,temmaxy]; extentArr.push(temextent); } } return extentArr; } });

4.2成果展現

因爲部件打包是以1000米的網格進行劃分後再打包，能夠看見有的不在單元網格區劃內的部件也展現在了地圖上。因此網格切分的大小是一個必須根據項目進行調整的參數。

5.移動端打包上傳詳細描述

我將打包上傳單獨進行描述，是由於這一塊整合時須要格外注意文件的合併方式。

• 手機服務端獲取到責任網格與單元網格的對應關係。
• 將責任網格對應的全部單元網格下的文件進行合併。合併規則爲增蓋方式。合併後的文件夾名稱爲責任網格命名。

責任網格打包文件夾的路徑說明: \責任網格編碼\部件小類\行號\列號.json

 

　　　　　　　　　　　　　　　　　　　　　  　-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                        　　    若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^