GoogleMap, Virtual Earth, YahooMap, etc. Currently, all WebGIS uses a cache mechanism to speed up map access. The principle is to set the map to multiple scales. For each scale, the map is divided into several small images in advance, which exist on the server. When the client accesses the map, it directly obtains the desired small image and concatenates it into a map, instead of dynamically creating an image on the server to deliver the image to the client, this greatly improves the reverse query speed. For example, if you want to sell pineapple outside, it is different from buying one for your own home. In advance, you can divide one pineapple into four portions (js may be divided into six portions). You only need to buy one for your food, small size, easy to eat, instead of biting the entire radish, get a face of pineapple juice. In this article, we will take a closer look at the principle that ArcGIS Server currently creates a cache (cut graph) for the map service. First, let's take a look at the concept: Tiling Scheme: a general term for a series of parameters used when creating a map cache. This includes the scale level, image format, and image size. Tiling Scheme Origin: the upper left corner of tiling scheme grid. By default, it is the origin of the coordinate system used by the mxd document. The range of a cut is usually the range of full extent in mxd documents, that is, from the upper left corner (map origin) of full extent to the lower right corner. Note that map origin and tiling scheme origin are differentiated. For different map services (mxd documentation), if the same coordinate system is used, there will be the same tiling scheme origin, even if their full extent is different (map origin is different ), it can also be in the same reference system. If full extent is the same, it can be easily combined, which is also the original design of tiling scheme origin. By default, the range of the cut graph is the full extent of the mxd document. If tiling scheme origin is set manually, the range of the cut graph can only be the lower-right part of the tiling scheme origin in the map range: If tiling scheme origin is in the upper-left corner of the map origin, the cut range is still full extent. If the tiling scheme origin falls into the map, the cut range is from the tiling scheme origin to the bottom right corner of the full extent. This is why we recommend that you change the cut image range by setting a specific rectangular range (in 92) or directly using featureclass (in 93), rather than using tiling scheme origin to limit the cut image range. So how did the map be cut out? How many chunks are cut? Let's go through an example. A map of china uses a custom coordinate system. When cropping a map, the settings are as follows: Check the folder structure after the graph is cut: in the cache directory, the folder named by the map service is china; it is followed by the folder Layers named by the DataFrame of the cut graph. Because it adopts the fused method, it is _ alllayers. If it is a multi-layer cut graph, it is the serial number folder of each layer; below is the Level of Detail, which is set by the cut chart, from small to large, corresponding to the preceding five scales; under a scale folder, it is the "row" folder of the cut graph. The naming rule is "R" plus an 8-bit row number (hexadecimal). If it is not enough, add 0. R0000000a in ratio indicates 10th rows in this scale (a in hexadecimal notation); All tile files in this row are in each folder, the naming rule is C plus the 8-digit number (in hexadecimal notation). If the number is less than 0. Why is there only 8, 9, 10, and 11 rows in this scale (L01? As mentioned above, the range of the cut graph is full extent, indicating that at this scale, the range of the map in China only occupies the rows starting from the tiling scheme origin. Similarly, for the ninth row folder above, there are only columns and the rest are not. Open conf. xml at the same level as the _ alllayers folder, and save the entire tiling scheme parameter. We can see the coordinate system information used by the map service, DPI (96) of the tile image, length and width of each tile (512), and tiling scheme origin. Now we can calculate the row and column numbers of the tile image where the point on the map is located in a certain scale. For example, in L01, the ID of the tile in Urumqi is calculated. Three pieces of information need to be collected: 1. Obtain the geographic coordinates of the region: x =-1341070, y = 5343697 in the local graph; 2. Obtain tiling scheme: x =-35331700, y = 46619300; 3. Obtain the resolution of the current scale, that is, the unit length of a pixel map: 8466.68360003387 on the L01 scale. Row number of the region: (35331700-1341070)/(8466.6836*512) = 7.84 = column number of the 8 region: (46619300-5343697)/(8466.6836*512) = 9.52 = 10 so in the second scale of the cut graph, Urumqi is in the tile of 10th rows and 8th columns.
Please indicate the source for reprinting. If you have any technical questions, please contact each other or leave a message .________________________________________________________________________________________________
Arcgis server map slicing format classification: Flex ArcGis2013-03-13 170 people read comments (0)
I. Slice rules
In the same coordinate system, the slice origin is the same by default. Of course, you can set this start point when slicing.
However, the starting point and range of a map are different. If the coordinates of the two mxd maps are the same and under the same coordinate system, the two slices can perfectly overlap. At first, I wondered why the origin of the slice is not the starting point of the map but the coordinate origin? Starting from the coordinate origin, will the image be cut into a lot of useless data, because there is no map range or data? The answer is: with a unified starting point, map slices of different ranges in the same coordinate system can be perfectly spliced together. These are all planned in advance. If it is not within the range of the map's start point, it will be ignored during slicing. This is not a waste of resources.
Each slice is uniquely identified by the hierarchy, row number, and column, which is an algorithm.
Ii. configuration file config. xml
Each slice cache corresponds to a configuration file that describes the information of the cached slice in detail. when reading the cache, you also need to read the configuration information before reading the correct picture.
It contains coordinate information, slice coordinate origin, and slice size;
It is the coordinate origin of the slice, which is a good start point for calculating the slice row and column.
LOGInfos indicates the slice information at each level, ID indicates the level, Scale indicates the Scale, and Resolution indicates the actual length of each pixel of the slice at the current Scale level;
TileImageInfo is the segment description, which is in the format of transparency and anti-aliasing;
CacheStorageInfo is the shard storage format description. EsriMapCacheStorageModeCompact indicates that the slice storage mode is the tightening mode, and 128 indicates the maximum number of slices in each data packet.
3. row and column computing
For a simple calculation question, we know the starting point coordinates and divide the map coordinates into N equal parts based on the starting point coordinates. Know the pixel size of each small block and the length of each pixel, and find the row and column numbers at any point on the map at a certain level?
Assume that the coordinate of the requested vertex is P (X, Y). Now, we need the row and column numbers in the first level.
Slice origin coordinates (-20037508.342787001, 20037508.342787001 );
The length of each pixel at level 1: 2116.670900008467;
The size of each slice is 256*256 pixels;
The width of each slice is 256*2116.670900008467;
Starting from the cluster origin, a row is arranged to the P point. The row number is calculated based on the height;
The row number of the P point: (20037508.342787001-P. Y)/(256*2116.670900008467)
So the column number of the P-point sitting: (-20037508.342787001-P. X)/(256*2116.670900008467)
Negative values may be calculated. The result is rounded up and the absolute value is the row and column number where P is located.
GoogleMap, Virtual Earth, YahooMap, etc. Currently, all WebGIS uses a cache mechanism to speed up map access. The principle is to set the map to multiple scales. For each scale, the map is divided into several small images in advance, which exist on the server. When the client accesses the map, it directly obtains the desired small image and concatenates it into a map, instead of dynamically creating an image on the server to deliver the image to the client, this greatly improves the reverse query speed. For example, if you want to sell pineapple outside, it is different from buying one for your own home. In advance, you can divide one pineapple into four portions (js may be divided into six portions). You only need to buy one for your food, small size, easy to eat, instead of biting the entire radish, get a face of pineapple juice. In this article, we will take a closer look at the principle that ArcGIS Server currently creates a cache (cut graph) for the map service. First, let's take a look at the concept: Tiling Scheme: a general term for a series of parameters used when creating a map cache. This includes the scale level, image format, and image size. Tiling Scheme Origin: the upper left corner of tiling scheme grid. By default, it is the origin of the coordinate system used by the mxd document. The range of a cut is usually the range of full extent in mxd documents, that is, from the upper left corner (map origin) of full extent to the lower right corner. Note that map origin and tiling scheme origin are differentiated. For different map services (mxd documentation), if the same coordinate system is used, there will be the same tiling scheme origin, even if their full extent is different (map origin is different ), it can also be in the same reference system. If full extent is the same, it can be easily combined, which is also the original design of tiling scheme origin. By default, the range of the cut graph is the full extent of the mxd document. If tiling scheme origin is set manually, the range of the cut graph can only be the lower-right part of the tiling scheme origin in the map range: If tiling scheme origin is in the upper-left corner of the map origin, the cut range is still full extent. If the tiling scheme origin falls into the map, the cut range is from the tiling scheme origin to the bottom right corner of the full extent. This is why we recommend that you change the cut image range by setting a specific rectangular range (in 92) or directly using featureclass (in 93), rather than using tiling scheme origin to limit the cut image range. So how did the map be cut out? How many chunks are cut? Let's go through an example. A map of china uses a custom coordinate system. When cropping a map, the settings are as follows: Check the folder structure after the graph is cut: in the cache directory, the folder named by the map service is china; it is followed by the folder Layers named by the DataFrame of the cut graph. Because it adopts the fused method, it is _ alllayers. If it is a multi-layer cut graph, it is the serial number folder of each layer; below is the Level of Detail, which is set by the cut chart, from small to large, corresponding to the preceding five scales; under a scale folder, it is the "row" folder of the cut graph. The naming rule is "R" plus an 8-bit row number (hexadecimal). If it is not enough, add 0. R0000000a in ratio indicates 10th rows in this scale (a in hexadecimal notation); All tile files in this row are in each folder, the naming rule is C plus the 8-digit number (in hexadecimal notation). If the number is less than 0. Why is there only 8, 9, 10, and 11 rows in this scale (L01? As mentioned above, the range of the cut graph is full extent, indicating that at this scale, the range of the map in China only occupies the rows starting from the tiling scheme origin. Similarly, for the ninth row folder above, there are only columns and the rest are not. Open conf. xml at the same level as the _ alllayers folder, and save the entire tiling scheme parameter. We can see the coordinate system information used by the map service, DPI (96) of the tile image, length and width of each tile (512), and tiling scheme origin. Now we can calculate the row and column numbers of the tile image where the point on the map is located in a certain scale. For example, in L01, the ID of the tile in Urumqi is calculated. Three pieces of information need to be collected: 1. Obtain the geographic coordinates of the region: x =-1341070, y = 5343697 in the local graph; 2. Obtain tiling scheme: x =-35331700, y = 46619300; 3. Obtain the resolution of the current scale, that is, the unit length of a pixel map: 8466.68360003387 on the L01 scale. Row number of the region: (35331700-1341070)/(8466.6836*512) = 7.84 = column number of the 8 region: (46619300-5343697)/(8466.6836*512) = 9.52 = 10 so in the second scale of the cut graph, Urumqi is in the tile of 10th rows and 8th columns.