背景
近期開發以MongoDB為基礎的分布式地理數據管理平台系統，被要求做一個簡單的demo給客戶進行演示。於是筆者便打算向數據庫中存儲一部分瓦片數據，寫一個簡單的存取服務器，使用Openlayers客戶端加載瓦片進行展示。本來是個挺簡單的功能，可是誰曾想，“打了一輩子鷹，卻被鷹啄瞎了眼”。在使用Openlayers客戶端進行瓦片加載時，出現了加載的瓦片偏移、行列號不正確的問題。
問題描述
如圖所示，地圖出現了上下偏移的問題，並且，這些瓦片的實際行列號與當前Openlayers計算的行列號並不一致。
Arcgis Server切出的行列號分別是
上面一行瓦片是：104/50,105/50,106/50/107/50
下面一行瓦片是：104/49,105/49,106/49/107/49
Openlayers計算得到的行列號分別是
上面一行瓦片是：104/18,108/18,108/18/107/18
下面一行瓦片是：104/19,105/19,106/19/107/19
猜測及思路
看到行列號及瓦片的偏移，筆者的第一反應是切片方案存在問題。經過排查此次使用的ArcGIS Server采用的切片方案時Google切片方案（EPSG3857，web mercator投影坐標系）。而Openlayers默認采用的坐標系也是EPSG3857，正好吻合，按道理說應該毫無問題。可是既然出現了錯誤，那就要排查問題，修改錯誤。既然Arcgis Server的切片方案沒問題，那就是Openlayers手動設置了不正確的坐標系。仔細觀察果然發現，在Layer的source處將數據源的投影坐標設置為了EPSG4326。何其低級的錯誤，竟然花費了將近一個小時來排查。
解決方案
將Layer的source投影坐標系設置為3857即可。
補充說明
（一）出現上述錯誤的原因是Arcgis Server中發布的切片緩存使用了Google切片方案，該切片方案采用Web Mercator投影坐標系，以[-20037508，20037508]作為坐標原點，瓦片大小是256像素（具體的切片方案描述可以在ArcGIS Server Manager的相應服務中看到詳細信息）。而本次出錯的前端代碼中將數據源的投影設置為EPSG:4326,與所發布服務的投影坐標系不匹配，導致Openlayers在計算行列號時無法計算出正確的結果，所以出現了加載錯誤。
Openlayers（2/3/4）默認采用EPSG：3857作為數據源的投影坐標系，該參數需要與后端的地圖服務所采用的投影坐標系匹配才可正常加載地圖，所以當我們采用Google的切片方案時（Web Mercator，也就是EPSG：3857），即使不設置Openlayers數據源的投影坐標系，也可正常加載。
Openlayers3的View中也有一個Projection參數，該參數為顯示地圖的坐標系，設置EPSG：4326或者EPSG：3857都可以，不影響數據的加載。唯一的不同就是，EPSG4326是WGS84地理坐標系，以經緯度為單位；EPSG3857是Web Mercator投影坐標系，以米為單位。如果將坐標系設置成4326，那么你是用openlayer從地圖上獲得的坐標數據都是經緯度坐標，向地圖添加坐標點時，坐標點的數據也應該是經緯度坐標。如果不幸的你設置了4326坐標系，而手上的數據確是3857的投影坐標系數據，那么你有比較簡便的方案解決這個問題：
1、 將View的Projection設置成epsg3857
2、 使用Openlayers提供的ol.proj.transform(coordinate, source, destination)方法，將3857坐標系的數據動態的轉換成4326坐標系的數據。
（二）
地圖服務的坐標系取決於切片方案里的設置，而非原tiff數據或者shp數據本身的坐標系。Google的切片方案采用的就是EPSG3857的投影，讀者也可以自行定義切片方案，把坐標系設置為EPSG4326，或者GCJ2000都可以，只要你正確的設置切片方案的參數即可。