Common caching questions

Below are common questions that have been asked about map and globe caching. The question subjects range from easy to advanced. In many cases, the answers restate information that is found elsewhere in the help. However, this topic may provide an answer to your specific question faster than searching the help.

General caching questions

• Why do the caching tools restart my services?

Map caching questions

• How do I generate a full cache at some scales and a partial cache at other scales?
• What's the best way to generate the cache at only a few of the scales in my tiling scheme?
• Why does map caching sometimes take longer at version 10.0 than with version 9.x?
• How do I display a "Data not available" tile for empty cache areas?
• How do I avoid duplicate labels in my cache?
• When creating a cache based on a feature class boundary, why do I see extra tiles created outside the features?
• When creating tiles on demand, why do extra tiles get created outside the user's map extent?

Globe caching questions

• What tiling scheme should I use for globe services?

Why do the caching tools restart my services?

Manage Map Server Cache Tiles and other caching tools do several things behind the scenes that require a restart of the service before and after the tool runs. For example, before creating tiles, Manage Map Server Cache Tiles extends the timeout value of the service to avoid timeouts during large caching jobs, then after the tiles are created, it sets the timeout length back to the original value.

Also, if the caching tools alter the conf.xml tiling scheme file, a restart is required for the map service to pick up the changes. For example, if you used Manage Map Server Cache Scales to add or delete scales from your cache, a restart would be required for the map service to recognize the changes to the tiling scheme.

The service will be briefly unavailable during the restart.

How do I generate a full cache at some scales and a partial cache at other scales?

At large scales, it's often a good practice to precreate the tiles that you anticipate will be the most popular and set the rest of the tiles to be created on demand. In contrast, at small scales, you might want to create a full cache because the small scales require fewer tiles and will be frequently viewed by clients when they initially see the map.

You can run the Manage Map Server Cache Tiles tool multiple times to build a partial cache at some levels of your map and a full cache at other levels.

Suppose you have a map that you want to cache at these scales:

• 1:128000
• 1:64000
• 1:32000
• 1:16000
• 1:8000
• 1:4000

You could run Manage Map Server Cache Tiles and check only the 1:128000, 1:64000, and 1:32000 boxes. By default, the full extent of those scales will be cached.

Then you could run the tool again and check only the 1:16000, 1:8000, and 1:4000 boxes. Also, you could choose to cache these scale levels based on the extent of features in a feature class, such as a city or county boundary, instead of caching the full extent of the map. This creates a partial cache at those three scale levels. Optionally, you could choose to have the rest of the tiles at those scales be created on demand.

What's the best way to generate the cache at only a few of the scales in my tiling scheme?

The Manage Map Server Cache Tiles tool lists all of the scales in your tiling scheme, with check boxes next to each one. If you only want to generate a cache at a few of the levels in your tiling scheme, uncheck the scales that you do not want to cache before you execute the tool.

Building a cache at only a subset of the levels of your tiling scheme is a common workflow when overlaying caches with ArcGIS Online, Bing Maps, or Google Maps services. In many cases, you may want to overlay your data with these basemaps, but you may not have the time or disk space to match all of the scales that those services use. You can use the same tiling scheme as these services and just uncheck the large scales before you run the tool.

Why does map caching sometimes take longer at version 10.0 than with version 9.x?

To answer this question, it's helpful to have some background on how the server approaches a caching job at 10.0.

In ArcGIS 10, the service instances dedicated to building the cache (ArcSOC.exe processes) are assigned a much larger unit of area to work on uninterrupted than was used at 9.x. Each ArcSOC.exe process works on an area 128 x 128 tiles in dimension before moving to the next area. For simplicity's sake, we'll call this a "bundle", even though it doesn't necessarily have to create a bundle file if you're making an exploded cache.

During caching, each ArcSOC.exe works on a bundle, then moves on to the next available bundle. Only one ArcSOC.exe process can work on a bundle at any given time.

At 9.x, the unit of work for an ArcSOC.exe process was a "supertile", whose dimensions of 2048 x 2048 pixels (4096 x 4096 pixels without antialiasing) are much smaller than a bundle's. The switch to bundles as a unit of work optimizes disk I/O and network throughput, and results in significant performance gain. The ArcSOC.exe processes change assignments less often and can concentrate their efforts on creating tiles.

The use of the bundle has a side effect though: when working with smaller caches, or when caching based on very small feature boundaries, the cache creation may take slightly longer than it would with 9.x. This is simply because there may be fewer bundles available than available ArcSOC.exe processes. If you have eight ArcSOC.exe processes available to work on caching and only one bundle intersecting your area of interest, only one ArcSOC.exe process will be used. This is a small tradeoff for the improved efficiency of the caching tools while handling larger cache jobs.

The best way to avoid this situation for large caches is to cache based on large feature boundaries that would encompass more bundles than available ArcSOC.exe processes.

How do I display a "Data not available" tile for empty cache areas?

If an area of your cache does not exist, you can either create the tile on demand or configure your Web server to return a "Data not available" tile. The "Data not available" tile is also useful if someone pans to the edge of the map or navigates to an area that you have not completed caching. Configuring your server to return a "Data not available" tile can in some cases yield a better user experience than returning nothing.

Instructions when no virtual cache directory is used (includes all JavaScript, Flex, and Silverlight applications)

For REST-based applications such as those you build with the ArcGIS APIs for JavaScript, Flex, or Silverlight, you configure a "Data not available" tile by placing an empty tile missing.png, missing.jpg, or blank.png at the root level of your cache. The tile handler service will default to this tile if a tile cannot be found in the cache. This technique is also valid for Web ADF applications where a virtual cache directory is not used or is disabled for the cache. Here are the instructions:

1. Create an image of the same dimensions and image format as a tile in your tiling scheme. Name it missing.png or missing.jpg. If a clear blank tile is needed (such as for overlay services that require transparency), use blank.png instead.To download an example tile, see ESRI Knowledge Base article 36939.
2. Save the file missing.png, missing.jpg, or blank.png under the _alllayers folder for the map service. For example: C:\arcgisserver\arcgiscache\MyMapService\Layers\_alllayers\missing.png.

The ArcGIS Server tile handler automatically handles missing tiles by replacing the expected but missing tiles with the special "missing" or "blank" tile at the root level of the cache.

IIS example for creating a custom error response if your Web ADF application uses a virtual cache directory

If you're building a Web ADF application that uses a virtual cache directory, you can create a custom error response on your virtual cache directory for HTTP Error 404: Not Found. Instead of an error message, the Web server returns the tile. Here's an example for IIS 6:

1. Open Windows Control Panel and click Administrative Tools > Internet Information Services (IIS) Manager.
2. Navigate to the virtual cache directory and find the folder containing your map cache. Right-click the folder and click Properties.
3. Click the Custom Errors tab, scroll down, then choose the 404 error code.
4. Click the Edit button. In the URL box, specify the tile that IIS should return whenever a tile is missing. Use a relative URL and not just a path to a file.
5. Click OK to close the dialog boxes.

How do I avoid duplicate labels in my cache?

If you are using a dynamic labeling engine in your map document to place labels (as opposed to annotation), you might occasionally see duplicate labels in your cache tiles. These should not occur any more frequently than 4096 x 4096 pixels in any direction. You can eliminate all duplicate labels by using annotation. When you use annotation, labels are associated with one point on the map and duplicates do not occur.

The above recommendation applies to fused caches. When you use multilayer caches, labels are not included in the cached images. The labels are drawn dynamically on top of the cached images

Legacy:

If you used multilayer caches with the 9.2 .NET Web ADF, you probably saw many duplicate labels because a dynamic set of labels was drawn for each tile. This behavior was improved in 9.3 and beyond; however, for performance reasons, you should generally only use multilayer caches with ArcMap as a client.

When creating a cache based on a feature class boundary, why do I see extra tiles created outside the features?

To avoid duplicate labels on tiles, the caching tools originally draw areas of 4096 pixels by 4096 pixels (256 tiles of the default 256 x 256 pixel tile size), which are then cut into tiles of the size that you requested in your tiling scheme. Depending on the tiling scheme, as well as the location and shape of your feature class, some tiles in the 4096 x 4096 area might fall outside the boundary of the feature class. This is expected behavior. You should not see tiles created outside the boundary of your feature class beyond 4,096 pixels in any direction.

When creating tiles on demand, why do extra tiles get created outside the user's map extent?

When you request new tiles (either on demand or using the caching tools), the tiles are always created in groups. The caching mechanism will never create just one tile at a time. If it did, you would see many duplicate labels because the server would not be aware of the labels on adjacent tiles.

When you have on-demand caching enabled and you pan to an uncached area, a 4096 x 4096 pixel area is drawn by the server, then cut into tiles. Therefore, if your tiles are 256 x 256 pixels in dimension, you could expect up to 256 tiles to be created. If your map contains many layers or complex symbols, this could result in long wait times for the client.

For this reason, it's strongly recommended that you precreate tiles for popular areas of your map and use on-demand caching only in the less-popular areas. Avoid building your entire cache on demand if you have a complex source map document.

What tiling scheme should I use for globe services?

Unlike map services, all globe services use the same tiling scheme, therefore you don't have to do anything to set up a tiling scheme for globe services. Your data will automatically be cached at the levels of the built-in globe tiling scheme.

If you look closely, you can see these levels reflected in ArcGlobe or ArcGIS Explorer. As you zoom in on the globe, you'll notice that the picture gets slightly sharper or fuzzier as you pass various altitudes.

The scales in the ArcGIS Online/Bing Maps/Google Maps tiling scheme roughly match the built-in scale levels in ArcGlobe. This tiling scheme is often a good choice if you plan to drape your 2D map service over the surface of your globe. Besides the tiling scheme being ideal for appearance, ArcGlobe is engineered to draw 2D services with this tiling scheme very quickly.