文章版權由作者李曉暉和博客園共有，若轉載請於明顯處標明出處：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/
如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^
