GoogleMap，VirtualEarth，YahooMap等，目前所有的WebGIS都使用了緩存機制以提高地圖訪問速度。原理都是將地圖設定為多個比例尺，對于每個比例尺提前將地圖分成若干小圖片，存在服務器上，客戶端訪問時直接獲取需要的小圖片拼接成地圖，而不是由服務器動態創建出一幅圖片來送到客戶端，極大程度的提高了反問速度。好比外面賣菠蘿，和自己買一整個回家吃不同，提前把一個菠蘿等分成四份（js可能會分成6份），你只需買一份來吃，體積小，方便吃，而不是對著整個菠蘿咬下去，弄一臉菠蘿汁。
??????? 本文中來詳細了解一下ArcGIS Server目前為地圖服務建立緩存（切圖）的原理。先來了解一個概念：
Tiling Scheme：創建地圖緩存時使用的一系列參數的總稱。包括比例尺級別，圖片格式，圖片大小等等。
TilingScheme Origin：是tiling schemegrid的左上角。默認情況下就是由mxd文檔使用的坐標系的原點。而切圖的范圍通常是mxd文檔中full extent的范圍，即從fullextent的左上角（map origin）到右下角。注意區分map origin與tiling scheme origin。


對于不同的地圖服務（mxd文檔），如果使用相同的坐標系，那么就有相同的tiling scheme origin，即使他們的fullextent不同（map origin不同），也能處于同一參考系中。如果full extent相同，則可以輕松地疊加在一起，這也是tilingscheme origin設計的初衷。默認情況下，切圖的范圍是mxd文檔的full extent。如果手工設置了tiling schemeorigin，那么切圖的范圍只能是地圖范圍中tiling scheme origin右下角的部分：如果tiling schemeorigin在map origin的左上角，那么切圖范圍還是full extent；如果tiling schemeorigin落在地圖中，那么切圖的范圍就是從tiling scheme origin到fullextent的右下角。這也就是為什么建議通過設置特定的矩形范圍（92中）或直接使用featureclass（93中）來改變切圖范圍，而不是利用tiling scheme origin來限制切圖范圍的原因。
??????? 那么地圖到底是怎么切出來的？切多少塊呢？通過一個例子深入淺出吧。一個中國地圖，采用了自定義的坐標系：



切圖時設置如下：


看看切圖完成后的文件夾結構：


??????? 在緩存目錄中，首先是地圖服務命名的文件夾china；之后是切圖的DataFrame命名的文件夾Layers；由于采用的是fused方式，下來就是_alllayers，如果是multi-layer切圖，那么就是每個圖層的序號文件夾；下來就是切圖設置的多個比例尺級別（Level ofDetail，LOD），從小到大，對應前面設置的5個比例尺；一個比例尺文件夾下，是切圖的“行”文件夾，命名規則是R加上8位行號（16進制），不足補0。比如圖中的R0000000a，表示此比例尺中第10行（16進制中的a）；每行文件夾下就是該行的所有tile文件了，命名規則是C加上8位列號（16進制），不足補0。為什么這個比例尺下（L01）中只有8,9,10,11行呢？前面說過切圖的范圍是fullextent，說明在該比例尺下，從tiling schemeorigin算起，中國地圖的范圍只占到了這幾行，其余沒有，不切。同理，對于上面的第九行文件夾中，只有7，8兩列，其余的沒有，不切。
??????? 再打開和_alllayers文件夾同級的conf.xml看看吧，里面保存了整個tiling scheme參數。


可以看出地圖服務使用的坐標系信息，tile圖片的DPI（96），每個tile的長度和寬度（512），以及tiling scheme origin。
??????? 現在來計算某個比例尺中，地圖上一個點所在的tile圖片的行列號了。比如計算L01中，烏魯木齊市所在tile的行列號。需要收集三個信息：
1、獲得烏市的地理坐標：在本地圖中是x=-1341070，y=5343697；
2、獲得tiling scheme：x=-35331700，y=46619300；
3、獲得當前比例尺的resolution，即一個像素所占的地圖單位長度：在L01比例尺上是8466.68360003387。


烏市所在的行號：(35331700-1341070)/(8466.6836*512)=7.84=8
烏市所在的列號：(46619300-5343697)/(8466.6836*512)=9.52=10
??????? 所以烏魯木齊在切圖的第二個比例尺中，處于第10行，第8列的tile。