ArcGIS Server 10中的切圖/緩存機制深刻【轉】

http://blog.newnaw.com/?p=789

兩年前我寫過一篇關於ArcGIS地圖切圖/緩存原理的文章，《ArcGIS Server的切圖原理深刻》，裏面以tiling scheme爲主，講了緩存圖片的存儲結構以及相關座標的計算。那時仍是ArcGIS 9.3版本，如今ArcGIS 10已經推出快一年多了，地圖緩存/切圖方面有了很大改進，好比增長了compact緩存格式，增長了import/export map server cache工具，增長了mixed圖片模式等。此次就在上篇文章的基礎上，以ArcGIS 10爲例，看看其中地圖切圖/緩存製做的工做機制。
　　注：本文旨在深刻了解ArcGIS目前切圖（即製做地圖服務的緩存）的機制，以幫助工做中有須要的朋友們提升工做效率，由於切圖，尤爲是大比例尺，耗時耗資源，實在是一件傷不起的工做。這裏已經假設你知道了如何爲緩存地圖服務配置地圖，如何檢查發佈地圖服務的地圖文檔的性能，開始動手前務必進行小範圍、全比例尺切圖試驗等等注意事項，如否，請查閱相關資料。

supertile和bundle

　　要深刻了解ArcGIS在切圖時的工做機制，有兩個概念必須明白，就是supertile和bundle。
　　假設一個tile（切片）的大小是256*256，在切圖時若是按照這個大小直接exportmap，開啓了動態標註的地圖服務上線圖層和麪圖層就會有不少重複的標註。由於exportmap時，每一個tile都會包含一個要素的標註，若是一個要素橫跨了多個tile（這在大比例尺下基本是確定的），那麼這些tile上就會出現相同的標註，exportmap時並不知道相鄰的tile上已經有了該要素的標註。

　　爲了解決這個問題，ArcGIS在切圖時引入了supertile的概念，開啓抗鋸齒時supertile大小爲2048*2048，反之爲4096*4096。真正切圖時會首先exportmap出一個supertile，而後將它們分割成指定大小的tile。對於每一個要素，每一個supertile中只包含一次標註，這樣保證一個superfile大小的範圍內不會出現重複標註。事實上在繪製supertile時，會盡量多地包含周圍的標註，因此在每一個supertile的邊界周圍仍會有重複標註。解決重複標註的根本辦法就是使用annotation，而不是label。
　　ArcGIS 10中推出了新的compact緩存格式，將原來離散的每一個tile圖片（exploded格式），保存成連續的二進制文件（.bundle），每一個.bundle文件最多可存儲128*128個tile。相比之前成千上萬的tile文件，這樣作有明顯的好處：易於緩存遷移，減小佔用磁盤空間，減小硬盤i/o等，esri在任什麼時候候都推薦使用compact格式來建立緩存，除非你須要本身讀取每一個tile（技術上來講這點能夠不成立）。ArcGIS 10在切圖時，也採用了bundle的概念：對於每一級比例尺，首先從tiling scheme origin開始，將切圖範圍分紅若干個bundle，每一個bundle覆蓋的範圍是128*128個tile大小。好比在1:4096比例尺時，若是tile大小是256*256，DPI爲96，那麼每一個bundle範圍的大小是：((4096*2.54/96)/100/1000*256*128)^2=1261.086平方公里。以後，有且僅有（這麼作是爲了不多個進程同時讀寫一個磁盤文件）一個服務實例/一個arcsoc.exe進程（若是是high isolated）來負責此bundle範圍的切圖，先輸出supertile，而後再切成tile。即便選擇了exploded緩存格式，ArcGIS 10中也會採用這種機制來切圖。

　　9.3.1及之前版本中，每一個服務實例工做的單位是supertile。即一個arcsoc.exe負責生成一個supertile，而後切成tile，再繼續生成下一個supertile……相比supertile這種處理單位來講，採用bundle做爲處理單位的ArcGIS 10中的服務實例能夠將更多精力投入到連續切圖中去，而不是頻繁切換本身負責的範圍。在大比例尺切圖中，這種新機制能很大程度上減小切圖時間；但在小比例尺切圖中，這種新機制有可能反而增長切圖時間。由於小比例尺時可能全圖範圍只有不到一個bundle範圍大小，這樣只會有一個服務實例來切圖，其餘實例都處於空閒狀態，而9.3.1及之前版本中，全部服務實例都會「一擁而上」。

網格切圖和按featureclass範圍切圖

　　有過大比例尺範圍切圖經驗的朋友確定會知道，通常切圖策略是：小比例尺全圖直接切，較小比例尺可能按照某個featureclass範圍來切，而大比例尺通常是按照包含網格（grid）的featureclass範圍來切。以我國全範圍切圖爲例，小比例尺時全圖切沒有問題，大比例尺時若是仍然全圖範圍（包絡矩形）切的話，會將周邊其餘的國家也包含進來，這並不須要的額外工做量在大比例尺時會是一場噩夢。

　　而之因此不只要按指定featureclass範圍切圖，並且featureclass裏要包含網格的緣由在於，便於細化和跟蹤切圖進度。切圖工具會給你指定的featureclass建立一個新的Cached字段，將已經切好的feature標記爲YES，以便在選擇Recreate Empty Cache時避免重複切圖，從而能夠將切圖工做分爲屢次來進行，或者以便在切圖失敗後排查緣由，繼續切圖工做。
　　在指定featureclass範圍切圖時，是順序處理該featureclass中的全部feature的。全部的服務實例會首先集體處理一個feature範圍，切出該feature範圍內全部要求的比例尺級別的結果。此時ArcGIS Server會重啓該服務。而後全部服務實例再去切下一個feature範圍……因此與每一個feature邊界相交的supertile可能會被建立兩次或屢次（多個feature的相交處），這也是爲何在使用featureclass切圖前，須要分別對它進行Generalize，Aggregate和Dissolve的緣由。

　　結合以前bundle的機制咱們知道，若是一個feature範圍剛好只包含一個bundle，那麼就杯具了，由於對該feature切圖時，只會有一個服務實例進行工做（一個bundle同時由且僅由一個服務實例處理），其餘服務實例所有處於空閒狀態。所以，比較理想的狀況是，每一個feature至少包含比服務實例數更多的bundle時，才能充分利用硬件資源來對其切圖。
　　這就會引出一個問題，就是如何來肯定某個比例尺下一個bundle的大小，從而生成這樣的featureclass呢？ArcGIS 10中，給咱們提供了一個新的GP工具Map Server Cache Tiling Scheme To Polygons，利用它，咱們能夠針對某個地圖服務，生成每一個須要切圖比例尺下全部的supertile，進而獲得以每一個supertile爲一個feature的featureclass。以全國地圖爲例，在1:288,895比例尺（ArcGIS Online Tiling Scheme的第12級）下生成的supertile是這樣的：

　　咱們須要的是某個比例尺下bundle的範圍，如何根據supertile來肯定bundle的大小呢？在N級比例尺時，一個supertile是16*16個tile，第N+1級比例尺時，該supertile會覆蓋32*32個tile，第N+2級比例尺時，覆蓋64*64個tile，第N+3級比例尺時，這個第N級的supertile會覆蓋128*128個tile，眼熟吧，這正是一個bundle的大小。因爲supertile和bundle都是從tiling scheme origin往右下角算起的，所以第N級一個supertile的範圍正是第N+3級一個bundle的範圍。由此若是咱們要生成第15級的bundle網格，只須要用Map Server Cache Tiling Scheme To Polygons工具生成第12級supertile的網格便可，如上圖。
　　以此爲例，咱們來講明如何有效進行大比例尺切圖的問題。假設咱們須要對1:36,111（ArcGIS Online Tiling Scheme的第15級）這個比例尺進行切圖，咱們首先生成該範圍的bundle網格，剛好是第12級的supertile網格，如上圖。爲了簡便起見，咱們只取其中8個feature來作說明，地圖服務的最大實例數是4個（機器是單cpu，4核）。若是每一個feature剛好是一個bundle，那麼一個feature只能被一個arcsoc.exe處理，而其餘3個服務實例均處在空閒狀態(佔用內存最少的那個arcsoc.exe是用來清空工做目錄的，與具體服務無關)：

　　而咱們對這個featureclass作一個處理，將4個feature（剛好是一個bundle）合併成一個feature（bundle cluster），這樣每一個feature就剛好包含了4個bundle，如此咱們所開啓的4個服務實例就可全速工做了，發揮了機器的最大性能：

　　ps：Map Server Cache Tiling Scheme To Polygons工具生成的supertile是從tiling scheme origin開始計算的，而不是地圖服務的fullextent左上角，所以利用它生成的supertile合併出來的bundle是最合理的，剛好與理想的bundle分界處一致。所以在大比例尺下利用featureclass切圖時，應當利用Map Server Cache Tiling Scheme To Polygons來生成網格，而不是fishnet工具。在ArcGIS 10.1中，將會推出新的GP工具，會根據cpu核數來生成合理的包含bundle cluster大小feature的featureclass。
　　其餘方面還有一些問題，好比切圖時最大服務實例數設置多少爲好（通常是cpu核數+1），即便全部實例所有工做cpu佔用率依然低於90%（有多是內存不足）等問題，與切圖機制無關，就不在此討論了。
　　總之，切圖是一個技術活，要求還比較高，須要考慮的問題不少。若是你只把它當一項體力活來看的話，只能說明認識還不夠全面，那就不能怪ArcGIS Server很差。畢竟，人家ArcGIS Online全球的19級緩存都7*24小時上線兩年了，還有什麼理由說產品很差呢？