ArcGIS 10.0紧凑型切片读写方法

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

切片方案

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

 

切片方案原点

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

 

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

ArcGIS 10.0紧凑型切片读写方法_第1张图片

切片宽度和高度

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

ArcGIS 10.0紧凑型切片读写方法_第2张图片

DPI

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

 

切片方案缓存文件结构

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

ArcGIS 10.0紧凑型切片读写方法_第3张图片

 

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

 ArcGIS 10.0紧凑型切片读写方法_第4张图片

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

ArcGIS 10.0紧凑型切片读写方法_第5张图片

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

TileOrigin表示切片方案原点。

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

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

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

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

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

500000 / 100 * 2.54 / 96 = 132.2913125052919

ArcGIS 10.0紧凑型切片读写方法_第6张图片

 

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 10.0紧凑型切片读写方法_第7张图片

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

为了让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等,这里测试读写文本文档的速度还是不怎么慢的。。。

你可能感兴趣的:(arcgis)