項目角度談矢量切片運用以及Geoserver處理自定義規格矢量切片方案

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

1. 背景

矢量切圖方案目前已是很常見的一個方案，在2016年時團隊基於Sharpmap開發了支持不一樣座標系、不一樣切圖參數、任意矢量數據（點、線、面）的工具。也着手開發了支持矢量切圖瀏覽器前端配圖的工具。在當時研究以前，也寫過一篇初步研究的文章：WebGIS中矢量切圖的初步研究（http://www.cnblogs.com/naaoveGIS/p/4982549.html）。

2.實際項目中的問題

可是回過頭看這兩年的運用場景，着實不多。究其緣由大體幾個方面：

a.大數據量狀況下，基於要素繪製的矢量切片雖然在前端能夠實現更好的交互效果，可是項目中因爲矢量數據量級每每達不到，徹底能夠直接處理爲一個文本一次性加載於前端展現。

b.即便大數據量狀況下，基於WMS或者WMTS以圖片形式展現要素也是基本方案。對於交互，雖然會多一次後臺查詢，可是項目產品每每沒有互聯網產品的極致交互要求。

c.矢量切圖的實施比較耗時，須要對圖層要素分別切圖、分別設置樣式，實施成本太大。而基於arcmap等工具統一配圖再一次性切圖，實施效率會大大提升。雖然各圖層樣式咱們能夠設置默認樣式，可是不免遇到各類新增或修改。並且因爲工具須要提早分別切好各矢量圖層，很是耗時。

d.矢量切片的更新問題。一樣因爲咱們對數據須要提早切片緩存，致使數據更新後，又得從新切片，無法作到實時。

3.解決思路

在項目的實際運用中，咱們最須要解決的是瓦片預處理致使的切圖耗時和沒法實時更新問題。只有實施問題解決了，才能更好的推進在大數據量狀況下使用矢量切片。

回到2016年，當時已經預研到Geoserver和一些開源工具能夠支持矢量切片，可是爲何最後仍是選擇本身開發工具了呢？
a.當時Geoserver最新的版本是2.8，矢量切片支持的不是很好，面的切片上邊界會不重合。

b.開源工具TileStache，不只僅是安裝不方便，並且只支持了WGS84座標系（包含墨卡託投影）。

因此只好讓團隊專人着手開發了矢量切片工具。

再回到如今2018年，Geoserver已經出到了2.12版本，矢量切片的面處理問題已經解決。因此目前採用Geoserver方案是更爲便捷的方案，它能夠很好的解決上面提到的實施問題和更新問題。

a.能夠經過udig等提早配置好圖層的樣式，造成模板，方便部署配置樣式。

b.Geoserver能夠在Geowebcache中配置好對矢量切片格式的支持，而且能夠分別設置是否預處理，或者實時切片。這樣，減小工程實施時須要預處理的耗時。

c.數據的更新問題，能夠經過設置緩存的時效性進行控制，避免以前從新切圖。

4.GeoWebCache的進一步介紹

一樣，在很早以前的一篇文章中，我對GeoWebCache作了一個預研：利用GeoWebCache實現WebGIS地形圖展現的緩存優化（http://www.cnblogs.com/naaoveGIS/p/4195008.html）。這裏，我作進一步補充。

a.下載對應插件。

 

注意安裝時，tomcat得是8系列。若是本地已經裝有jdk1.7，則須要再裝一個jdk1.8，而後在tomcat8的bin目錄下的setclasspath.bat文件中，直接寫定jdk的指向路徑：

 

b.官網地址：http://geowebcache.org/docs/current/concepts/index.html

c.GeoWebCache的導航頁包含功能：

 

 

點擊TMS（Tile Map Server），能夠查看服務列表：

d.預覽功能

 

e.切圖功能

點擊seed this layer。

 

f.查看正在切圖的進程

 

5.Geoserver發佈自定義規格矢量切片步驟

5.1增長自定義GridSets

5.1.1建立GridSets

 

默認的GridSet中只包含了4326和900913座標系。點擊，create gridsets,咱們以2379座標系來示例。

5.1.2各參數配置

 

a.經過查找選定座標系。

b.填寫瓦片大小。

c.切圖比例尺。這裏提供兩種填寫方式，以分辨率填寫，或以比例尺填寫。

5.1.3切圖範圍配置

這個配置十分重要，在咱們切圖中，有原點這個概念，而gridsets中咱們沒有發現與切圖原點有關的配置項。而其實，這個切圖範圍，咱們即可以將其視做原點配置。

假設此時原點爲：-5123200，10002100。

咱們便將切圖範圍設置爲：

 

5.1.4Geoserver中產生的配置文件

在Geoserver的GWC文件夾中，咱們能夠看見保存gridsets後生成的對應配置文件：

 

5.2圖層關聯上gridsets

最後，咱們點擊圖層欄，選擇tilecaching

5.2.1選擇切圖格式

當安裝了矢量切圖插件後，在切圖格式上即可以選擇矢量切片相關格式。目前插件提供的矢量切片有三種格式：geojson、topojson、pbf。Geojson可讀性高，topojson比前者小一些，可是不可讀。而pbf格式壓縮性更好，一樣也不可讀。Pbf在插件中爲type=mapbox-vector，格式爲x-protobuf。意思是，其數據組織採用的mapbox提供的mvt格式，該格式對地圖不一樣級別下的要素會採用道格拉斯-普克算法進行抽稀，而後再以谷歌提供的pbf格式進行存儲。因此，pbf壓縮性更好，可是一樣是不可讀的。

 

5.2.2添加切圖參數

把咱們設置好的gridsets加入，並選定好須要切圖的級別。

 

5.2.3其餘參數

5.2.3.1Metatiling factors

 

經過設置可讓WMS請求時的範圍擴大，減小因爲瓦片過小致使的出如今不一樣瓦片重複動態註記過多問題。可是肯定就是請求範圍變大後，每次請求耗時變長，併發性下降。

5.2.3.2緩存時效

 

5.2.3.3瓦片間隙

 

6.OL加載矢量切片服務

6.1代碼編寫

 

其中，TILEMATRIXSET對應咱們設置的GRIDSETS名稱，而TILEMATRIX對應各個級別時的切片級別名稱。

6.2效果展現

 

7.遺留問題

雖然目前已經展現出矢量切片，可是其切片又明顯位移：

 

若是咱們是基於已有的4326或者900913座標系，則不會有這個問題。可是基於自定義座標系和切圖參數時便發生了偏移。

若是隻談解決思路：由於是線性偏移，咱們能夠代碼中對不一樣級別設置不一樣的切圖原點。可是這是很是不科學的。

我的推測，這可能與DPI有關係，及每英寸的像素數有關係。咱們的地圖是ArcGIS發佈，其切圖參數使用的DPI是96，換算出來的屏幕一像素所表明的實際地理位置爲：

1英寸=2.54釐米

1英寸=96像素

那麼屏幕的一像素具備（2.54/96=2.6458E-4）釐米/像素。

可是，咱們Geoserver中默認的是：

 

將該配置修改後，重啓Geoserver，偏移問題依然存在。

 

 

不知道各位讀者遇到過該問題否，是否有其餘解決思路。

 

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

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