Cache directory

The server cache directory is the folder on disk where your cache tiles are stored. One server cache directory can hold multiple caches; however, you can add more than one server cache directory to your server. When you create an ArcGIS Server site, a server cache directory is created for you at a location you specify. For more information, see Server directories.

If you plan to add another GIS server machine to your site, you need to enable file sharing on the server cache directory so it can be seen by all participating machines. For more information, see Add a server directory in Server Manager and Configure a multiple-machine deployment. Be sure to give the ArcGIS Server account write access to the server cache directory so that the server can successfully place the tiles in the directory. You can optionally remove write access when you finish creating your caches.

You can open the server cache directory to examine the cache tiles and tiling scheme file conf.xml. Another file, conf.cdi, contains the default extent information of the service and is required for viewing caches as raster datasets in ArcMap. A geodatabase named status.gdb contains information that ArcGIS shows in its cache status reports.

The tiles are organized into a directory hierarchy. The top-level directory has the same name as the map service unless the service was created in a GIS server folder. If the map service is in a folder, the top-level directory is named <folder name>_<map service name>.

The top-level directory contains a subdirectory for the particular data frame in the map being cached, which contains a single subdirectory, _alllayers. Within that, there are subdirectories for each level of detail. The structure of these level-of-detail subdirectories varies depending on whether you're using compact storage format or exploded storage format.

• If you're using the compact cache format (which is recommended), you see bundle files immediately within the level folders. These bundle files contain the tiles.
• If you're using the exploded cache format, you see subdirectories for each tile row, and finally, the actual image files that represent a particular column in the row.

Learn more about the compact cache format

Tiling scheme

The tiling scheme defines where tile boundaries will exist. It is important to match the tiling scheme when your cached service will overlay other caches in client applications.

You can choose a preset for your cache's tiling scheme, or provide a custom file. You can further modify the tiling scheme to fit your cached service using the options in the Tiling Scheme settings group.

Tile format

This setting determines what output image format the map service will use when it creates the tiles. Your choice of image format is important, because it determines the size on disk of the tiles, the image quality, and the ability to make the tile background transparent.

When you initialize a new cache, ArcGIS examines the layers in your map and selects a default image format for you. If your map contains only vector layers, the default is PNG. If at least one raster layer is detected, the default is MIXED.

You should examine this default and determine if it makes sense based on the purpose of your map. The following is a summary of the available image formats and their appropriate uses:

• PNG—For each tile, this format determines the PNG bit depth that will minimize tile storage space without sacrificing visual quality. It is appropriate for many vector maps, especially maps with few colors, maps with large swaths of one color, or overlay networks. If you're not sure which PNG format to use, try this first.
• PNG8—You can use PNG 8 for overlay services that need to have a transparent background, such as roads and boundaries. PNG 8 creates tiles of very small size on disk with no loss of information.

  If your map uses antialiasing, you'll see higher quality of lines and labels if you use PNG or PNG 32 instead of PNG 8. If your map has a large number of colors due to gradient fills or hillshades, you may also want to use PNG or PNG 32.

• PNG24—You can use PNG 24 for overlay services, such as roads and boundaries, that have more than 256 colors (if fewer than 256 colors, use PNG 8). Do not use PNG 24 if your tiles will be viewed in Internet Explorer version 6 or earlier.
• PNG32—You can use PNG 32 for overlay services, such as roads and boundaries, that have more than 256 colors. PNG 32 is an especially good choice for overlay services that have antialiasing enabled on lines or text. PNG 32 creates larger tiles on disk than PNG 24, but the tiles are fully supported in all browsers.
• JPEG—Use this format for basemap services that have large color variation and do not need to have a transparent background. For example, raster imagery and very detailed vector basemaps tend to work well with JPEG.

  JPEG is a lossy image format. It attempts to selectively remove data without affecting the appearance of the image. This can cause very small tile sizes on disk, but if your map contains vector line work or labels, it may produce too much noise or blurry area around the lines. If this is the case, you can attempt to raise the compression value from the default of 75. A higher value, such as 90, may balance an acceptable quality of line work with the small tile size benefit of the JPEG.

  It's up to you to decide what image quality you consider acceptable. If you're willing to accept a minor amount of noise in the images, you could save large amounts of disk space by choosing JPEG. The smaller tile size also means the browser can download the tiles faster.

• MIXED—A mixed cache uses JPEG in the center of the cache with PNG 32 on the edge of the cache. Use the mixed mode when you want to cleanly overlay raster caches on other layers.

  When a mixed cache is created, PNG 32 tiles are created anywhere that transparency is detected (in other words, anywhere that the data frame background is visible). The rest of the tiles are built using JPEG. This keeps the average file size down while providing you with a clean overlay on top of other caches. If you do not use the mixed mode cache in this scenario, you'll see an opaque collar around the periphery of your image where it overlaps the other cache.

• LERC—Limited Error Raster Compression (LERC) is an efficient lossy compression method recommended for single-band or elevation data with a large pixel depth, such as float, 32-bit, 16-bit, or 12-bit data. LERC compresses 5 to 10 times better and 5 to 10 times faster than LZ77 for float data. LERC is also better with integer data. When using integer data, and the error limit specified is 0.99 or less, LERC is considered a lossless compression.

  Note:

  Limited Error Raster Compression (LERC) is only available for image services; map services are not supported.

  Elevation data, or surfaces, is mostly used in 3D views to represent the ground, such as a terrain model. You can have surfaces that do not represent the ground, such as the ozone layer, which is above the ground surface, or geological substrates, which are below the ground surface. When using a LERC compression method to serve surfaces that are not at ground level, it is strongly recommended that you publish the data with all the levels of detail. This ensures that when you view the data, you do not zoom out beyond the coarsest resolution, which would stop rendering the content. This is less of an issue for elevation content that is contributing to the ground surface, because the surface can be used to fill in any gaps that may exist.

  • If you select LERC, specify the compression value using the Compression input dialog box. The compression represents the maximum tolerated error value that is applicable per pixel (not an average for the image). This value is specified in the units of the mosaic dataset. For example, if the error is 10 centimeters and the mosaic dataset is in meters, enter 0.1.
  • LERC-based cache services do not resample to draw if the source data is not supported at a given scale or if overviews are not present. LERC-based cache services also contain a properties file that lists whether or not the service contains elevation data. To provide full coverage while drawing 3D scenes, LERC-based caches use a cache tile size half a pixel more than the standard 256 x 256.
  • The LERC format uses a non-transform compression algorithm, therefore the compression value or maximum error allowable value varies from 0 to 1,000.

Before committing to an image format for a large cache, build a small cache of a representative area of your map and examine the tile quality and performance in a test application. If you are working with multiple caches, build a small test cache for each, and add them to a test application to make sure they overlay as expected. This allows you to make adjustments before you create the entire cache.

To make a small test cache, use the editing tools in ArcMap to create a feature class consisting of a small rectangle around the area you want to test. Then use the option at the bottom of the Manage Map Server Cache Tiles tool dialog box that allows you to create tiles based on the boundary of a feature class. Browse to the feature class containing your test area, and create the tiles.

Compression

Compression refers to the amount of JPEG compression that takes place when using JPEG or mixed image format caches. Higher values signify higher JPEG quality and therefore less compression. For imagery, values of 55 to 75 are usually sufficient without causing any visible loss of quality. For vectors and other sharply defined features or regions, a higher quality of 90 is recommended as a starting point.

Storage format

You can choose whether to group your tiles for more efficient storage and mobility or store each tile as a single file. The following are the storage options:

• Compact—In compact format, each file in the cache contains a bundle of tiles. The bundles are 128 tiles wide by 128 tiles high, containing a maximum of 16,384 tiles. Compact caches copy much faster than exploded caches, and they take less space on disk. Learn more about compact caches
• Exploded—In exploded format, each tile is stored as a file on disk. This makes it easier to see the tiles in your cache; however, it results in larger caches that take longer to create and can be cumbersome to copy. For this reason, it's no longer recommended to use the exploded format.

The enormous number of files and folders in the cache can sometimes cause inefficiencies in copying utilities, including copy and paste in Windows. For this reason, compact caches greatly reduce cache copying time. If you have an automatic cache update workflow that creates tiles on a staging server and copies them to a production server, it's recommended that you use compact caches. Additionally, if you have limited disk space available, you should use compact caches.

Levels of detail

Tiling schemes often contain many levels of detail between which users can zoom. You can modify the list of Levels of detail for your cached service. Depending on your map, you may want to forego caching extremely close or distant scales in your tiling scheme to conserve disk space and reduce generation time. ArcGIS examines the scale dependencies in your map and attempts to suggest a range of levels of detail to cache. You can adjust this range using the Minimum level of detail and Maximum level of detail parameters.

The remaining levels of detail are not removed from your tiling scheme, but you cannot to create tiles for them unless you return to the Caching tab and include them in the range.

Tile origin in map units

The tiling scheme origin is the upper left corner of the tiling scheme grid. The origin does not necessarily represent the coordinate point at which tiles begin to be created; that happens when the full extent of the map or area of interest feature class is reached. Using a common tiling scheme origin for your caches ensures that they can overlay each other in web apps.

In most cases, you should keep the default tiling scheme origin of the software. The default is the upper left point of the coordinate reference defined by the map document. If no coordinate reference is defined in the map document, the upper left point of two times the union of extents of all the layers in the map is used.

If you change the tiling scheme origin to something other than the default, be aware that tiles can be created only in the map area to the lower right of the tiling scheme origin. If you want to cache only a certain area of your map, creating tiles based on a feature class boundary is a better option than changing the tiling scheme origin.

Dots per inch (DPI)

Dots per inch (DPI) refers to the resolution of the cache tiles that the server generates. The default value of 96 is almost always sufficient unless you are working primarily on a network where the majority of your client machines have a different DPI. Be aware that adjusting the DPI affects the scale of the tiles.

Tile height and tile width

The default tile width and height is 256 pixels. It's recommended that you use 256 or 512. If you're building a cache that overlays another cache, be sure to use the same tile width and height for both caches.

Choosing a smaller tile width and height may improve performance of the application requesting tiles from the cache, as less data needs to be transferred. However, with exploded caches, a smaller tile size results in a larger cache size and longer creation time.

Create tiles on demand

When this box is checked, tiles for previously uncached areas are added to the cache when they're first requested by a client. This is a good way to ensure that people always see a map when viewing your cache, even if you didn't have time to initially create all the tiles at every level of detail.

Learn more about when to use on-demand caching

Allow clients to cache tiles locally

When this box is checked, Esri client applications such as the ArcGIS Enterprise Map Viewer Classic are allowed to keep a local cache of any tiles they retrieve from the server. This can help the client view the tiles more quickly when returning to the area. Clients must manually clear their cache to get any newer tiles from the server. Therefore, consider unchecking this box if you'll be updating your cache frequently.

Resampling

To save disk space and time spent generating caches, you may have chosen not to include certain map areas from particular levels of detail in your cached service. For example, if your service provides information about cities in your country, you may have excluded rural areas from being cached in lower levels of detail (further zoomed out). For these map areas where cached tiles are sparse or unavailable, the optional process of resampling existing cache at lower levels can fill in these gaps for users.

Resampling, which is disabled by default, redraws your cached service in map areas where you have not generated tiles at that scale, based on the closest level of detail generated on the server. You can enable it on your cached service by checking the Resampling box.

While resampling provides a smoother experience for users, its output can be blurry, particularly when the level of detail being resampled is far from the source level of detail. For example, if your cached service's maximum scale where tiles are present in a certain map area is 1:5000 and a user zooms to 1:100 in that area, the resampled cache will likely lose clarity and accuracy. It's therefore recommended to use caution with resampling.

If you enable resampling on your cached service, you can specify a Minimum level of detail and Maximum level of detail at which the service can perform resampling. Consider the levels of detail included in your cache's range when setting these parameters.