ArcGIS Server Development Tutorial Series (3) slices

Slicing work, we can cut at the first level, or we can, all the pieces cut, recreate all tiles this is to say, in the absence of any slicing work, you can choose this; recreate Empty tiles This is to say that if a certain level has been sliced before, When you re-slice, you can choose this, you can check the Help; Delete Tiles This can delete the previously cut slices, for example, our computer is transduction, suddenly power off, cut a few days, dozens of g of the map slices, how to do? We can't start cutting again, we can choose recreate Empty Tiles, and fill up the remaining map slices.

The slice parameter settings can be made when the service is published or in the catalog by clicking on the published Service modification service Properties

Here set the text anti-aliasing, preferably set to normal or above, otherwise easy to appear text is not clear

Set the cache directory: This is important, because we sometimes cut graph data can be dozens of g, hundreds of g, or even on T, so we can not put the slice default to the directory: C:\arcgisserver\directories\arcgiscache directory, We need to add a disk that is larger in size

Set the CPU core number of slices, native 4 cpu,4 threads, so we set the maximum with a few CPU slices, that is 3, if you set to 5, then the final release is unsuccessful.

The number of CPU threads determines how many processes you are going to instantiate, the general maximum is set to the number of CPU threads-1, so that the CPU utilization is around 50%, if the setting is too large, will cause CPU utilization at 100%, the hardware usage has been 100% may lead to overloading, This can cause problems with the system.

Set the following parameters separately according to the requirements, slicing several levels

Select Suggest, popup input box input set several levels, here set to 5

Follow the diagram settings below

You can add or remove a custom bar (this place has been sliced so it's gray), you can set the slice format to PNG32, save the format

Advanced Settings Select here as needed

The following information is referenced in http://blog.csdn.net/warrenwyf/article/details/6069711

A new tile cache file format has emerged in ArcGIS 10: Compact storage. Compared to previous loose storage (exploded), it has many advantages, such as easy migration, faster creation, reduced storage space, and has become the default format for creating tile caches. There is no difference between accessing compact storage and accessing loose storage for a product of its own ArcGIS, but if a third-party app wants to access the new tiling format, the official "no " response is now available:

The internal architecture of the bundle is not publicly documented by ESRI. If you've coded your own logic to pulling tiles out of a virtual directory, you should continue to use the "exploded" format which stores each tile as a single file and is the only option at ArcGIS Server versions 9.3.1 and previous.

I Google a bit, there is no relevant information, so simply self-reliance, self-analysis of the compact storage format, I believe this is the only information available on the compact storage internal format.

• principle of compact storage

The two most important files for compact storage are bundle and bundlx files, where bundle files are used to store tile data, andBUNDLX is the index file for slicing data in bundle files.

you can store up to 128x128 (16384) slices in a bundle file, but creating a tile cache is not a single slice, but it is rendered with 4096 pixels (no antialiasing) or 2048 pixels (with antialiasing) as the edge length. , if the slice edge we select is 256 pixels long and anti-aliasing is turned on, each time the ARCSOC process creates a large image that is stitched into 8x8 (64) slices and then cut back into the bundle file.

, the blue border represents the bundle file, the black lattice is the tile when creating a large image, each slice in the black lattice, the figure is not shown.

L Analysis of storage formats

Before I analyze the compact storage format, I first ask myself, if you want to store content in a bundle file, what should you do with an index in a BUNDLX file? The best way is to refer to the database bitmap index, in the BUNDLX file with a fixed number of bytes to identify a slice in the bundle file state (the stored offset and length).

Observe the BUNDLX files generated by ArcGIS , each file is the same size:81952 bytes. As mentioned above, a maximum of 16,384 slices per bundle file is stored , although there may not be so many slices in the bundle file, I guess the bundlx file must have retained the index position of the owner's 16,384 slices. Roughly estimate that each slice will occupy about 5 bytes,16384x5=81920 bytes, and 32 more bytes, guessing the identity information of the stored BUNDLX file.

By observing and guessing the regularity of a BUNDLX file that is very sparse to store slices, it is determined that the file starting in Bundlx is 16 bytes and the end of the file is 16 bytes independent of the index, and the remaining 81920 bytes of data are A repetition of 5 bytes of frequency constitutes an index to the bundle file.

I thought that these 5 bytes would save the offset and length of the slice data in the bundle file, but it might not be enough to find 5 bytes of information, so I made an analysis of the slice data in the bundle at the same time.

I suspect that the file is not compressed, so search the file for the file header of the PNG file 0x89504e47 (I chose the PNG24 format when I created the cache ) and I found it. At the same time, each of the 2 slice data is separated by 4 bytes (slice data I was directly compared with exploded pictures), by guessing, try to find that the 4 bytes is exactly low to high level of the way the subsequent slice of the length of the data.

Since the length of the slice data is recorded in the bundle file, the index in the BUNDLX file must include only the offset of the slice data, whichhas been experimentally found to be BUNDLX 5 bytes also indicate the offset of the data at low to high levels.

The slice data length and the data offset conjecture should be unsigned integers, as demonstrated in the following practice.

Another question is, whatis the data offset for each of the 5 bytes in the BUNDLX that is labeled exactly which slice? The result of my experiment was: Sort by column:

1	129	...	...
2	130
3	131
...	...
...	...
128	256		16384

From the above analysis, if we know the level of a slice, line number, column number, we can first find the bundle in the content of the tile offset, and then remove 4 bytes of length data from the bundle file, The actual slice data is then read according to this length. about how to calculate the line number of the slice, column number, and the name of the bundle file, relatively simple, here is not described in detail.

Then you start slicing automatically in the catalog to see the progress of the slices.

ArcGIS Server Development Tutorial Series (3) slices