ArcGIS 10.0紧凑型切片读写方法

首先介绍一下ArcGIS10.0的缓存机制：

切片方案

切片方案包括缓存的比例级别、切片尺寸和切片原点。这些属性定义缓存边界的存在位置，在某些客户端中叠加缓存时匹配这些属性十分重要。图像格式和抗锯齿等其他属性也会写入切片方案，但对于客户端应用程序能否成功叠加切片没有影响。

切片方案原点

切片方案原点是指切片方案格网的左上角，默认原点为地图文档定义的坐标参考的左上点。原点不一定代表创建切片的起始点；只有在达到地图全图范围时才是这样。进行缓存时使用公用切片方案原点可确保所创建的缓存能够在 Web 应用程序中相互叠加。注意，切片是从地图的全图开始切的，不是从切片方案原点（切片方案原点落在地图原点右下方另算）。

另外一点，我经过试验，发现切片的行列号是从0开始算起的。

切片宽度和高度

切片的默认宽度和高度为 256 像素。

DPI

每英寸点数 (Dot Per Inch) ，是指服务器将生成的缓存切片的分辨率。即生成的图片每英寸长度内的像素点数。默认为96。

切片方案缓存文件结构

缓存目录 －> 地图服务名 －>地图数据框名称(DataFrame) －>如果是所有图层一起切割就是_alllayers，否则就是各个图层的名称 －> 各比例尺等级文件夹。如下图

地图数据框文件夹里放着conf.cdi和conf.xml两个标识缓存范围、以及切片方案的配置信息：

conf.cdi存储了切片的范围：

conf.xml存储了切片方案配置信息：

TileOrigin表示切片方案原点。

TileCols和TileRows表示单张切片所占的像素长度。

DPI表示生成切片的一英寸长度的像素数。

LODInfos里则存储了切片的各级信息。

PacketSize表示单个bundle文件（下一小节将介绍）里存储的行/列数。

LODInfo的Resolution表示的是地图上每个像素表示的实际长度（地图单位）。比如说50万的比例尺,96的dpi，可以这么计算：

500000 / 100 * 2.54 / 96 = 132.2913125052919

bundle和bundlx文件

bundle文件中存储的是图片文件，bundlx文件中则存储了各个图片文件在bundle文件中的偏移量。

命名规则

bundle文件的命名都是：R数字C数字。R代表起始的Row，C代表起始的Column。数字均为16进制。

行和列如果不满4位，则前面补0，位数多了不限。如R22e80C14400，表示这个bundle文件的起始切片是0x22e80行0x14400列。

bundlx文件结构

每个bundlx文件的大小都是81,952 字节（我这里PacketSize是128），前面16字节 + 每个图片偏移量5字节 * (128 * 128)个切片 + 结尾16字节。

这里注意一下，不管是bundlx还是bundle文件里写位置信息都是从低位到高位写的，比如说你看见这样一段代表位置的字节：10 32 a8 d7 54，这个代表的就是16进制的0x54d7a83210

我比较了一下各个bundlx文件，发现起止16字节都一样，开始和结束字节分别是：

byte[] bdxBts = new byte[16] { 0x03, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00 };

byte[] bdlxEndBts = new byte[16] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

bundlx文件切片的写入顺序是按列写入的。也就是说，先是1列1行、1列2行……2行1行、2列2行……这样写的位置。还拿R22e80C14400来说：

先是开始16字节，然后5个字节22e80行14400列、5个字节的22e81行14400列……

bundle文件结构

这个文件我比较了好半天才找到这些规则。

首先是文件的开头，从0x00到0x3b的这些位置都是bundle文件的描述信息：(还是以R22e80C14380.bundle为例)

这里多谢不做懒人的改正：

“

为了让arcgis能读取我们生成的紧凑型格式，bundle文件的前60个字节的数据，还需要完善。
其中：
8-11位，表示第一个非空，非全透明图片的大小
16-19位，表示非空文件个数*4

”

开头以后紧接着从0x3c开始就定入图像文件。

但如果某一处不在地图的全图范围内，也就是说我这个bundle文件中是包含很多块切片的，其中有好多是正好是空的，没有图像。这时会怎么办呢，难不成全写成空Image存进去？

开始我是这么写的，但写了一个就感觉不对了，一级的切片里一个bundle几十兆大小了，后来我比对发现，所有bundle文件从0x3c到0x1003c都是空的，正好＝4*16384个字节。然后找到arcgis生成的bundlx文件验证一下，第一级的开始一列切片正好都是空的，bundlx里的偏移量是从0x3c开始的。也就是说，bundle文件里从0x3c－>0x1003c这些位置是为空切片预留了偏移位置，依次按照bundlx里的位置顺序开始写切片，如果遇到空的，就指向这里的空位置段，比如第r行第c列切片是空的，对应的位置就是 0x3c + ((c - colStart) * this.m_packetSize + (r - rowStart)) * 4。

非空切片在bundle文件里是从0x1003c开始写的。

找到非空切片存储的偏移位置，接下来的4个字节是该image的长度，然后在这4个字节之后取这些长度的字节就组合成了一副图像，如果要查找的话返回即可。

简单写入算法

读取时直接按照level和row、column计算出bundle文件名，按照上面的计算方法找到对应Image返回即可，这里只说明一下我自己的切片的方法。针对单个LODInfo

1. 计算map的Tile范围

   long ltRow = (int)((this.m_tilingOriginY - m_mapMaxY) / (info.Resolution * this.m_tileHeight));
   long ltCol = (int)((m_mapMinX - this.m_tilingOriginX) / (info.Resolution * this.m_tileWidth));
   //右下角的切片行列号 9.0 = 第9个是结束
   long rbRow = (int)((this.m_tilingOriginY - m_mapMinY) / (info.Resolution * this.m_tileHeight));
   long rbCol = (int)((m_mapMaxX - this.m_tilingOriginX) / (info.Resolution * this.m_tileWidth));

2. map跨越的bundle文件范围

   //左上角的bundle文件开始行列号
   long ltBundleRow = this.m_packetSize * (ltRow / this.m_packetSize);
   long ltBundleCol = this.m_packetSize * (ltCol / this.m_packetSize);

   //右下角（最后一个）的bundle文件开始行列号（由于上面的第9.0行已经归为第9行，所以直接算就是对的）
   long rbBundleRow = this.m_packetSize * (rbRow / this.m_packetSize);
   long rbBundleCol = this.m_packetSize * (rbCol / this.m_packetSize);

3. 写单个bundle文件
   针对单个bundle文件，先写好bundle和bundlx的起始段字节，找好四角对应的实际坐标点
   按列写切片
   如果切片在图外，写到0x3c-0x1003c的位置，否则把地图控件调整到单个切片的尺寸，Map缩放到该范围，导出图片
   把此时的偏移量写入bundlx文件，img写入bundle
4. 写完结束部分后修改bundle中的0x18--0x1b的文件大小信息。

经测试，我用DotSpatial的DotSpatial.Controls.Map控件 按照已经用ArcGIS发布好的服务的参数来配置 来切割一副地图，切割好后删除ArcGIS的切片并替换成我自己切割的，展现效果完全相同。

切片多时速度还是比较慢的。为了提速，可以对每级切片都新建一个线程，为了监视进度也可以自定义一个进度变化的事件，每次写入一个切片就计算进度并触发事件。为了提高IO效率还可以用Buffer等，这里测试读写文本文档的速度还是不怎么慢的。。。