· 金字塔
在對前面一些因素的分析中，我們始終採用了未建立金字塔的儲存資料進行討論。這並非是對金字塔可以提高瀏覽速度作用的故意無視，而是我們希望排除掉金字塔的影響來獲取我們需要的單個角度的資訊。
現在，讓我們來看一下金字塔的原理。金字塔通過在不同的比例尺下預先進行重取樣並儲存結果，避免了原始的柵格資料在小比例尺下實時重取樣的過程，因此，此舉能大大提高小比例尺下柵格資料的瀏覽效率。
圖 8 柵格金字塔的原理
但是，從金字塔的原理可以知道，在與資料實際解析度相近的比例尺下，金字塔並不能起任何加速顯示的過程，因此，前面的章節中分析了沒有金字塔情況下的各種現象，在這種情況下完全符合。同時，在建立了金字塔的比例尺下，前面的討論也並非沒有意義，它們同樣也可以對金字塔本身的效率提供參考的價值。
· 分幅
乙個大的柵格資料，到底是用單幅儲存比較好呢，還是存為多幅較小的資料較好？換句話說，有時候拿到很多分幅的柵格資料，是不是有必要將它們都拼接起來？這裡也進行乙個比較。
比如用上面使用過的4.72g的大tiff資料，分割成16幅同樣以tiff格式儲存的柵格檔案，分別進行全圖預覽和小範圍預覽的效率比較：
壓縮格式/壓縮比
全圖預覽耗時
某小範圍預覽耗時單幅
26.7秒
0.08秒
多幅（16幅）
17.7秒
0.08秒
可見，適度的分幅有助於提高大範圍資料訪問的效率。不過，如果建立了金字塔，兩者的效率應該區別不大。另外，在實際情況中，本身分幅的影像應該會有壓蓋和色差的問題，通過拼接也可能減小儲存的空間和提高訪問效率。
· 併發訪問
對於使用檔案形式儲存的柵格，或許有人會對其在併發訪問環境下的能力有所懷疑。在這裡，分別使用檔案、file geodatabase和arcsde儲存相同的資料，在arcgis server上發布服務執行 20個例項，然後比較他們在50個使用者併發訪問下的效能：
壓縮格式/壓縮比
單使用者訪問耗時
併發訪問響應時間
檔案（tiff）
2.2秒
0.76秒
託管filegdb（jpeg/75%）
20.3秒
2.13秒
arcsde（jpeg/75%）
20.3秒
1.78秒
可見，使用檔案儲存的柵格資料在併發訪問的環境下不會有任何問題，其效能和單使用者訪問時一樣都是比較好的。同時，雖然單使用者訪問下file geodatabase和arcsde的效能差不多，但是在多使用者併發情況下arcsde的效能會更好一些，這應該和資料庫的快取有關。
· 其它因素
在考慮柵格資料如何儲存的時候，除了一些效能上的考慮，還必須考慮許多其它方面的因素。
比如，雖然在一些情況下不將柵格資料入庫的效率可能較好，但是有些場合下可能還必須使用arcsde儲存，因為arcsde可以提供安全、多使用者訪問、資料共享等方面的特性。
另外，比如mosaic dataset有時候效能不一定有預先鑲嵌的raster dataset好，但是使用它可以保留所有的原始影像資訊、同時使用各種型別多時相多解析度的資料、方便地使用柵格計算函式、可以直接發布為image service，這些功能性的優勢在很多場合下比單純的訪問效能好一點要重要得多。
圖 9 使用mosaic dataset的柵格函式
海量空間資料庫實施策略 柵格資料 4
mosaic dataset 在arcgis 10中出現了一種新的資料模型mosaic dataset，它在某種程度上有點類似raster catalog，可以管理多個柵格。並且，不管是在file geodatabase還是在arcsde中，mosaic dataset都可以將資料保留在外部而僅在g...
海量空間資料庫實施策略 柵格資料 6
柵格切片尺寸 在匯入柵格到arcsde中的時候 1 從 ii.柵格資料模型 中可以知道，柵格實際上是被切割成一塊塊儲存在sde blk 表中，每條記錄代表了乙個切片。預設這個切片的尺寸大小是128 128畫素，對於這個切片在資料庫中的儲存在這裡進行一下更深入的討論。如果我們在匯入柵格的時候選擇的壓縮...
海量空間資料庫實施策略 柵格資料 6
柵格切片尺寸 在匯入柵格到arcsde中的時候 1 從 ii.柵格資料模型 中可以知道，柵格實際上是被切割成一塊塊儲存在sde blk 表中，每條記錄代表了乙個切片。預設這個切片的尺寸大小是128 128畫素，對於這個切片在資料庫中的儲存在這裡進行一下更深入的討論。如果我們在匯入柵格的時候選擇的壓縮...