ArcGIS for Server 10.3.X New compact cache interpretation and application

As early as the end of 2010, Ox Demon King the compact cache format introduced in ArcGIS 10 in the workshop of his blog Space Ox Demon King , as described in "ArcGIS Tile cache compact file format analysis and use." In the following 4 years, ArcGIS for server itself has undergone a gradual turnover of 10, 10.1.X, and 10.2.X versions, especially software architectures that have undergone significant changes. However, in terms of the compact cache itself, the interpretation of King Ox Demon King is always applicable. Sincerely salute to our Daniel!

Until the end of 2014, when ArcGIS 10.3 was officially released, ESRI introduced a new compact cache format to enhance the user's access experience. The key difference under the new cache format is that ESRI will cache the index information. BUNDLX is included in the cached tile file. Bundle.

Next, let's take a quick look at this new compact cache format. As the saying goes, original aim. Now that the cache folder contains only bundle files, you can imagine that the index of the slices, the offset of the slices, and the picture stream of the slices must be included in this file. Based on experience, the cache itself follows the form of a 16 binary. According to this idea, use UltraEdit to open the bundle file and view it in 16 binary format.

l00 level and lang= >ultraedit "en-us" in r0000c0000.bundle file under l00 level.

Through the analysis of the law of information storage in this paper, the following conclusions can be drawn: (1) The file contains a large number of 04 00 00 00 00 00 00 00 of the 16-byte group, a total of 16893 groups; (2) The file contains only one PNG24 header byte group 89504E47, That is, the first column of the first row of slices, bundle file in the only one picture. The picture stream immediately follows the byte group mentioned in (1), but is offset by 4 bytes, and (3) (2) The value of the 4 byte offset is exactly equal to the length of the picture stream; (4) The beginning of the 5th line of the file 4 bytes 44 00 02 00 The value is equal to 131140 from low to High, and (2) The location of the PNG file header is exactly the same as described in.

Comprehensive analysis: (1) The first 4 lines is the bundle header information, can be ignored, (2) The bundle's file header records 16384 slices of the slice position, only 4 bytes, from low to high, after 4 bytes can be ignored, (3) After the location information, for the slice of the record, The length of the slice is recorded in 4 bytes, followed by the picture flow information. Here, the bundle ends.

Next, we will choose a long and narrow rectangular polygon feature publishing Service and graph to analyze the specific storage pattern of column slices in bundle files.

By comparing the bundle file and the corresponding loose cache at the L02 level, it can be inferred that: (1) The storage of the index in the bundle is stored in rows, that is, 1 to 128 on line 1th, 1 to 128 on line 2nd, and so on, until the last slice is 128th row 128 column; (2) The storage of the picture stream in the bundle contains only non-empty slices. Furthermore, the analysis of this more complex map cache proves the previous inference.

Now that the above analysis is complete, the above analysis will be validated. In this case, I will use the ArcGIS Runtime SDK for Android to implement the abstract theory of practical work. The core of this verification is that by extending the Tiledservicelayer, the gettile (int mlevel, int mcolumn, int mrow) methods are covered according to the above storage inference.

The first step is to locate the bundle file according to the scale level, column number, and line number in the parameter.

1String level =integer.tostring (mlevel);2     intLevellength =level.length (); 3     if(Levellength = = 1){                        4Level = "0" +Level ;5     }6Level = "L" +Level ;7             8     intRowgroup = 128* (mrow/128);9String row =integer.tohexstring (Rowgroup); Ten     intRowlength =row.length (); One     if(Rowlength < 4){ A          for(inti=0; i<4-rowlength; i++){ -row = "0" +Row;  -         } the     } -row = "R" +Row; -              -     intColumngroup = 128* (mcolumn/128); +String column =integer.tohexstring (columngroup); -     intColumnlength =column.length (); +     if(Columnlength < 4) { A          for(inti=0; i<4-columnlength; i++){ atColumn = "0" +column; -         } -     } -Column = "C" +column; -      -String bundlename = String.Format ("%s/%s/%s%s", Compacttileloc, Level, row, column) + ". Bundle";

View Code

In the second step, the bundle file is read and the corresponding slice is obtained and returned according to the starting position and the length of the slice inferred from the previous analysis.

1     intindex = 128* (mrow-rowgroup) + (mcolumn-columngroup);2     3Randomaccessfile Isbundle =NewRandomaccessfile (Bundlefilename, "R");4Isbundle.skipbytes (64 + 8*index);5     6     //get position index and calculate slice position offset7     byte[] Indexbytes =New byte[4];8Isbundle.read (indexbytes, 0, 4); 9     LongOffset = (Long) (INDEXBYTES[0]&0XFF) + (Long) (INDEXBYTES[1]&0XFF) *256 + (Long) (INDEXBYTES[2]&0XFF) *65536Ten+ (Long) (INDEXBYTES[3]&0XFF) *16777216;  One                      A     //get the slice length index and calculate the slice length -     LongStartoffset = offset-4;  - Isbundle.seek (startoffset); the     byte[] Lengthbytes =New byte[4]; -Isbundle.read (lengthbytes, 0, 4); -     intLength = (int) (Lengthbytes[0] & 0xff) + (int) (Lengthbytes[1] & 0xff) *256 + (int) (Lengthbytes[2] & 0xff) * 65536 -+ (int) (Lengthbytes[3] & 0xff) * 16777216; +      -   //get slices based on slice position and slice length +Bytearrayoutputstream BOS =NewBytearrayoutputstream (); A      at     byte[] Tilebytes =New byte[length]; -     intBytesread = 0; -     if(Length > 0){ -Bytesread = Isbundle.read (tilebytes, 0, tilebytes.length); -         if(Bytesread > 0){ -Bos.write (tilebytes, 0, bytesread); in         } -     } to              +Tile = Bos.tobytearray ();

View Code

Hehe, successful realization. Directly on the Android side of the display effect it.

　　

Tips:

About compact sectioning I still can't help but ask: (1) New compact tiles cannot be used directly for previous versions of ArcGIS for Server, (2) New compact slices can be obtained by exporting slices that export tiles to the previous format of the cache; (3) Older versions of the compact tiles can be reused directly in the new version of ArcGIS for server, but can be updated to the new compact tile format by upgrading the storage format, upgrade Storage format.

ArcGIS for Server 10.3.X New compact cache interpretation and application